<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi, Sebastian<br>
<br>
You must remember that I am an old curmudgeon. For me, simplicity
was programming in assembler as opposed to typing in octal code. I
entered a more complex world with Fortran and Cobol, simplified by
Basic. Programs for the IBM 1401 started at position 333 since the
only operating system was a load button and the only debugging tool
was a button that dumped memory contents to a printer. Every program
we wrote was complete. Today, there are few programmers who have
ever written anything more complicated that 'Hello World' as a
complete program. Today, virtually all programming is 'own code' to
a pre-existing program. I think that the phrase 'own code' is now
part of a curmudgeon's history - in the day it meant a subroutine
written to be used in an existing program.<br>
<br>
My main concern with full IDEs is that the user may not be able to
write a real program to execute in a real environment. On the other
hand, the beginning programmer shouldn't get bogged down in
boilerplate. The programming languages have essentially no
boilerplate (shebang?). It is a web page that requires a fixed
skeleton. However, Richa's solution hides that from the user. It
can't be completely hidden since the learner needs to know how to
build a web page independently of the tool. This is covered by the
Pocket HTML lessons.<br>
<br>
The Explore section of the School Server content is organized in the
form of a course with units and lessons. Amazingly, it now includes
not one, not two, but three programming languages: Python,
Javascript, and Shell Scripting. Javascript is intended to build on
a knowledge of HTML and CSS although the text, Eloquent Javascript
actually introduces Javascript as a programming language and
connects it to the web only in the second part (the third introduces
node.js). Incidentally, the course based on Eloquent Javascript
provides a 'take no mercy' approach to introducing all of these
essential programming concepts. I am sure it would not be available
to our students without Richa's tool. Anyone who fully understands
the concepts in this text is 'good to go' at any level of
programming.<br>
<br>
The first prerequisite course, introduces the Terminal Activity, the
file system, and the nano text editor. With this basis, the learner
has a basis for saving programs and web pages as files and executing
them from the command line (or displaying in the Browse activity
with <a class="moz-txt-link-freetext" href="file://">file://</a> and a path. The courses Terminal 1 and Terminal 2 (from
William Shotts - <a class="moz-txt-link-freetext" href="http://linuxcommand.org/tlcl.php">http://linuxcommand.org/tlcl.php</a>) continues into
more on the shell and writing shell scripts.<br>
<br>
My curmudgeon past also included putting the programs from David
Ahl's Basic Computer Games (<a class="moz-txt-link-freetext" href="http://atariarchives.org/basicgames/">http://atariarchives.org/basicgames/</a>) on
a Commodore 64. <br>
The first Python course from Al Sweigart's Invent Your Own Computer
Games With Python (<a class="moz-txt-link-freetext" href="http://inventwithpython.com/">http://inventwithpython.com/</a>) shows how to
program similar text games in Python. The second Python course from
Al Sweigart's Hacking Secret Ciphers With Python is also
introductory and text-based but in the domain of cryptography. The <br>
third course also based on a book by Al Sweigart, Making Games with
Python and Pygame, depends on the material covered in the first two
courses. <br>
<br>
WIth regard to the proposed fourth Python course, you are right on
target. However, the introduction to Pygame does not relate it to
objects. An important goal to this course is to develop
understanding of these essential programming concepts: programming
to an event-driven environment and organizing a large program to be
understood for ease of maintenance and debugging. An important
corollary is learning to read programs written by others.<br>
<br>
I think that Hello World is a good starting point since the learners
will have already built Hello World as a standalone program. This
allows the discussion to focus on what is required to run it as a
Sugar Activity. For example, despite the complex folder that is the
HelloWorld activity, everything is boilerplate except the
'activity.info' and 'activity.svg' files. The 'HelloWorld' Python
program is in activity.py file. There the actual label('Hello
World') is one line as print 'Hello World!' is in the original. This
presents the opportunity to explain the rest of the file in the
Sugar context. This also gives a good incentive for the learner to
convert the Toolbar code to a module<br>
<br>
The BlockParty activity has been a favorite (I like Tetris), but it
demonstrates a technique to build the activiity as a standalone
executable file (__main__) and yet have it called by the framework
in the Sugar context. This, of course, is a valuable capability of
Python.<br>
<br>
This can motivate the learner to learn how to make the Python
programs from Swegart's texts into Sugar activities.<br>
<br>
One unavoidable boilerplate issue in this course is the difference
between sugar and sugar3. Given the direction of later Sugar builds,
this topic is inevitable. The course will also have to cover
olpcgame as a wrapper to pygame.<br>
<br>
The course will also include challenges to work with and improve
Sugar Activities from ASLO. One example is converting Toolbars to
the new standard. Another is fixing activities with Hulahop to use
webkit or WebKit. At a more difficult level, fix InfoSlice to access
the wikipediae on the school server. One section of the course
should be to build a 'collaborative' Sugar activity. For example,
convert a two player game where both players play on the same XO to
one where the players are on different XOs. I hope to show how to
make a 'king of the hill activity' where the two players play the
game and others watch. The loser becomes a watcher and the longest
waiting watcher becomes the challenger.<br>
<br>
Tony<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/15/2015 02:39 AM, Sebastian Silva
wrote:<br>
</div>
<blockquote cite="mid:55048062.9000103@fuentelibre.org" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
I find this discussion very interesting.<br>
<br>
It is hard for me not to think of a full IDE like creature when
thinking of the jsfiddle tool.<br>
<br>
Perhaps I'm failing to see exactly the point or the inteded "Use
Case".<br>
<br>
On my side, as a self-taught-as-a-child programmer, I appreciate
abstraction layers very much because they allow me to think of the
actual thing I want to implement.<br>
<br>
What I do not appreciate is boilerplate code.<br>
<br>
To really understand Hello World activity, you must understand
some basic concepts of Object Orientation, the notion of what is
GTK, event-driven programming, etc.<br>
<br>
Even Hello Web carries a lot of boilerplate with it.<br>
<br>
In my humble opinion it's not so bad when the boilerplate code is
not seen (i.e. part of the toolchain, or at least, in a template).<br>
<br>
Perhaps we've exhausted the discussion and it will come to a
matter of the design chosen by the implementors for its first
iteration.<br>
<br>
Perhaps it's a good time to remember our core design ideas:
Simplicity, Collaboration, Reflection, and try to apply them to
this design.<br>
<br>
Sounds like a fun project.<br>
<br>
Regards,<br>
Sebastian<br>
<br>
<br>
<div class="moz-cite-prefix">El 11/03/15 a las 00:34, Richa Sehgal
escibió:<br>
</div>
<blockquote
cite="mid:CAPYWsU9LE7G6GcausU5Y8rVaTk+ZM_-8Ew+CTKi2Mrd7OG2+sA@mail.gmail.com"
type="cite">
<div dir="ltr">Hi,<br>
<br>
Regarding inclusion of libraries such as Jquery, maybe we can
let students create templates which we can save in their web
folders. The objective is the following: As Tony mentioned,
providing them with templates might not make them learn the
basics, but essential parts of programming. For example, in my
initial days of coding, I used Eclipse which started a new
file in a nice template. During my first exam, I realized that
I have forgotten the signature of the function main (the
arguments type and number of arguments). Since then, for any
new language that I pick up, I start from scratch. So what we
can do is that students can create templates for shortcuts,
but at least they would have some hands-on experience. This
can then serve like what Sebastian mentions.<br>
<br>
As for the performance, after we develop the tool, we can do a
performance benchmark and publish the numbers for different
libraries, and CSS functionalities. These numbers can also be
used by other developers as the basis for their algorithms,
and we can see how to improve on them and also study how they
change as XO and Sugar evolves.<br>
<br>
Thanks<br>
Richa</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Mar 10, 2015 at 5:05 PM, Tony
Anderson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tony_anderson@usa.net" target="_blank">tony_anderson@usa.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
Sebastian<br>
<br>
I am using Zim Desktop Wiki to reformat the book into
digestible lessons (actually done). This makes it all
html. My plan is to put this on the school server so that
a<br>
student can download a chapter to view locally while
working on it. I added a button to the Browse toolbar that
displays a Journal object chooser and then displays the
selected Journal object - a zip file which contains the
web site in a compressed folder.<br>
<br>
I also provide a prerequisite course introducting the
Terminal Activity and the nano editor. The model is that
students would have a directory in /home/olpc/Documents
named web. This directory would be used to hold thier web
pages. At some point when they learn about links, they can
set up a main page with links to the others. All<br>
of this is accessible from the Browse activity by <a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="file:///home/olpc/Documents/web/index.html">file:///home/olpc/Documents/web/index.html</a>.<br>
<br>
The student should learn to add jquery by reference in the
head of their web page. The actual js files can be
downloaded from the school server (or installed with Sugar
by usb stick). One problem with ide approaches is that it
hides some of what we are trying to have the students
learn. For example, I seriously considered using pippy to
teach Python, but concluded that it would hide how to save
Python programs, how to make them executable, and how to
share them. In a course on making Sugar Activities, pippy
can actually export the python code in a Sugar Activity
wrapper, but what does the student learn about the
construction of a Sugar Activity from that? I would rather
they begin with the HelloWorld Activity.<br>
<br>
I have used a localhost for years with no problem. Since
switching from Firefox to Webkit, I haven't been using it
but primarily because I haven't tried to implement the
features that required it. I am not sure it will be
relevant at the intial web level. In any case, jquery did
not cause any performance problems on an XO1.<br>
<br>
As regards Webkit, my concern is that in the Browse
Activity it does not seem to support flexible boxes, the
modern way to do web layout, and in many ways the key to
reponsive web design.<span class="HOEnZb"><font
color="#888888"><br>
<br>
Tony</font></span>
<div>
<div class="h5"><br>
<br>
On 03/10/2015 10:11 PM, Sebastian Silva wrote:<br>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div class="h5"> El 10/03/15 a las 04:58, Tony
Anderson escibió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I am working on a course based on Pocket HTML<br>
(<a moz-do-not-send="true"
href="http://www.goer.org/HTML/" target="_blank">http://www.goer.org/HTML/</a>)
which is available via CC. At the<br>
javascript level, I think Eloquent Javascript
would be a good base and<br>
is also CC.<br>
</blockquote>
Hi Tony,<br>
<br>
This is wonderful. I have had my eye on that
tutorial ever since I<br>
started to think about Web activities a long time
ago.<br>
<br>
My first attempt at a Web Activity was called WebSDK
and was an IDE for<br>
doing web apps [1].<br>
Those were old-style web apps, the ones that had a
Python mini-server<br>
running in the background.<br>
I still consider this a good approach to access
Python infrastructure<br>
from Javascript, but I'm not sure how (or if) the
new Web API<br>
infrastructure has replaced this mechanism.<br>
<br>
I think, in any case, for a GSOC student working on
dev tools for JS on<br>
Sugar, should consider the entire IDE scenario, not
just the "fiddle"<br>
part. I.e. it should be possible to deploy a mini
app (or content!) from<br>
this activity.<br>
<br>
About embedding JQuery and other libraries, I would
favor a "Wizard"<br>
approach. I.E. a form that will allow you to have a
basic project from a<br>
template (w/ or without optional toys such as
Jquery). I like the<br>
hand-holding approach especially since low
performance machines can't do<br>
multi-tasking very well (so looking up docs is not
easy). Therefore a<br>
version of the JS tutorial that Tony referenced
would be great to have<br>
embedded, IMHO, or included somehow. (Tony do you
have an offline copy?)<br>
<br>
In order to avoid slow pages on older machines,
including XO, it should<br>
be super lightweight, i.e. utilizing as little CSS3,
transformations,<br>
transparency, SVG rendering, and animation as
possible. At least a<br>
couple of templates should be able to run on the XO1
without issues.<br>
Hopefully some profiling feedback would be shown
inline during<br>
development (such as at least load time for the
"fiddle").<br>
<br>
Also, there are wrappers for web activities for
versions of Sugar that<br>
don't include the Web Activities framework. Maybe
include those as<br>
options in the templates. Finally, a good editor
goes a long way for a<br>
good development environment (I used Ace editor
component and it ran<br>
well on XO1, back in the day).<br>
<br>
The way I think of this is that you should be able
to develop something<br>
relatively basic without resorting to the Internet
either for sensible<br>
libraries or their respective documentation. If done
really well,<br>
perhaps we could even offer an alternative to Pippy
and Develop?<br>
<br>
Finally, I don't think the Webkit or even old
Firefox rendering engine<br>
are a severe limitation. It's not worse than
targetting Internet<br>
Explorer 6 and most web developers had to do that
only a couple of years<br>
ago. I suggest you download Firefox 3.6 (from like
10 years ago) as that<br>
is the rendering engine found on Sugar 0.94 and
limit yourself by what<br>
it can do. I havben't looked for a reference browser
for the Webkit1<br>
engines, except Browse itself. It would be good to
find out what our<br>
current engine equivalent is and document it (along
with more<br>
contributions) to <a moz-do-not-send="true"
href="http://developer.sugarlabs.org/"
target="_blank">http://developer.sugarlabs.org/</a><br>
<br>
Regards and good luck.<br>
<br>
[1] <a moz-do-not-send="true"
href="http://somosazucar.org/files/2011/07/WebSDK1.png"
target="_blank">http://somosazucar.org/files/2011/07/WebSDK1.png</a><br>
<a moz-do-not-send="true"
href="http://somosazucar.org/files/2011/07/WebSDK2.png"
target="_blank">http://somosazucar.org/files/2011/07/WebSDK2.png</a><br>
</div>
</div>
.<br>
<br>
</blockquote>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>