I developed the following ideas about how to teach computer programming during a recent conversation with Daniel Rocco, a professor at the University of West Georgia, and Georgia Tech grad student Derek Richardson, and I wanted to expand on the ideas here on my blog. I have been heavily influenced by reading Greg Wilson, and, for all I know, he or someone else may have already put these ideas together into something like the outline below.

The first day of class

To teach computer programming, a professor ought to stride into the room on the semester’s first day, explain that a computer program is a text file full of instructions for the computer to follow, and then proceed to check out an example from version control. His desktop should be displayed on a big screen in front of the class. He should read through the example program with them, discuss it — it should be a Python program that does something requiring two or three dozen lines, like opening a window and displaying the message, “Hello, world!” — and then run it. He should demonstrate how to edit the program so that it prints something else instead (perhaps “Hello, professor!”), run the altered version for them, and, finally, check the modified program into version control.

The class now has the tools they need to complete their first assignment. The students are told that a version-control repository has been created for each of them; that they have each been subscribed to their repository’s email notification list; and that, upon returning home from class, their email inbox will already hold a message informing them that their first assignment — the “Hello, world!” program itself — has been checked into their repository by the course software. By the next class period they are to have checked the assignment out, altered it so that it prints “Hello” followed by their own name, and submitted the assignment by checking the program back in.

Entertainment wants only to satisfy its audience;
but Art will teach us new desires.

(Penned after pondering the talk that Dana Gioia gave at Oxbridge 2008)

I have decided to give my PyEphem astronomy library for Python a public source code repository, an open forum for user questions, and a bug tracker where my users can see the progress of their bug reports out in the open rather than having them scattered across our email inboxes. To accomplish all of this, I simply registered PyEphem with Launchpad, a site built to host software projects that is already used by several projects for which I have great respect.

Because users might become confused now that PyEphem is spread across three web sites — the home page is here at rhodesmill.org, releases are posted over at the Python Package Index, and, again, the development project is now hosted at Launchpad — I have completely redesigned the PyEphem home page with the goal of making the three-site distinction clear, coherent, and easy to navigate. The new home page and documentation are generated by the wonderful Sphinx documentation engine, and I am still thrilled about how pretty my code samples look (check out the one on the PyEphem home page!) now that Sphinx is coloring them in with the renowned Pygments system.

I have simultaneously released a new version of PyEphem that includes the new Sphinx-based documentation, along with several important fixes to the software itself. From now on, rather than cluttering my own blog with every minor version of PyEphem that I might release, fans of the software should visit its News and announcements page on Launchpad and subscribe themselves to its Atom/RSS feed. You will still see the project mentioned here whenever a technical or scientific issue becomes interesting enough for me to write about; but the audience of astronomers and hobbyists who just need to know when the next version is released should not have to wade through my blog to do so!

My users have already begun transferring their questions and problems to Lauchpad, and I look forward to offering much greater accountability through a fully public development process.

What fun! An application has been placed on the Web named Wordle which, given some paragraphs of text as input, produces very striking images by drawing the most important words from your document so that they are largest. The basic idea is a long-standing one on the Web, as exemplified in dozens of sites with busy and ugly tag clouds whose halfhearted attempt to create interest by varying their font size barely makes the idea worthwhile. But viewing Wordle, I am simply startled that word frequency analysis can produce something so beautiful! Here, as an example, someone has submitted the Constitution:

United States Constitution

One can spend several minutes just staring at the words so basic to our national life, and pondering the significance of their relative sizes! To make my own contribution to the burgeoning world of Wordle documents, I created a program to extract the memorial messages from the Marshall Booth Guest Book on legacy.com, and then submitted the result to Wordle. After several tries, and after experimenting with the color options, I came up with something I find quite satisfactory:

Marshall Booth memorial

I am sure that Wordle documents will look rather formulaic once everyone has used them to generate Christmas cards one or two years in a row. But they are without question of much greater visual interest than any other tag cloud I have ever seen, and are therefore a big step forward simply by making word frequency something worth staring at.

It would be fun to submit novels, or theological treatises, or each of the books of Paul, to Wordle and then see whether students of English literature or Biblical exegesis could identify the original document simply by which words appeared the most often. I think there would be interesting surprises! Could people tell apart the five acts of Hamlet?

I have delivered my “Zope 3 Component Architecture” talk to the 2008 North American Plone Symposium meeting here in New Orleans. I want to thank the folks at Enfold Systems both for hosting the Symposium, inviting me to speak, and for generously making it possible for me to attend! Here are my slides:

Download slides as PDF

They had asked me to attend so that I could present the Using Grok to Walk Like a Duck talk that I gave at PyCon 2008 back in March. They changed the title, I suppose, to better highlight why it would be of interest to the Plone community; but the change actually helped me to rethink the presentation. I wound up using only the first half of my PyCon slides. For the second half of the talk, which at PyCon had consisted of a crazy sequence of hints and tips about using adapters in your own applications, I instead did a much more successful series of slides about how adapters are actually used in Zope 3 to suit up objects for presentation on the web. I think this made the idea more concrete, and thus much easier to understand for people seeing adapters for the first time.

The talk was well enough received that I should perhaps think seriously about finding further opportunities to share Zope 3 technologies with the Plone community.

I am enjoying my first weeks of using the Tomato Firmware. I purchased a Linksys WRT54GL wireless router because of its admirable support for third-party firmware like Tomato, which replaces the traditional Linksys setup screens with an alterative system with many more configuration options. I can also connect directly to Tomato over SSH and use it as a very small Linux system! This opens endless possibilities for writing fancy firewall rules and running small embedded applications right at the border of my home network.

The Tomato firmware uses a small DNS server named dnsmasq to answer the steady stream of domain name requests from my home computers. It converts domain names that I type, like rhodesmill.org or google.com, into the low-level IP addresses with which computers identify each other.

But I also like using hostnames for the machines sitting right in my home, even though they do not have “real names” out on the Internet. I recommend placing local hostnames inside of a top-level domain that is local to your own network. Choose a suffix that differs from all of the top-level domains that exist out on the Internet — avoid .com, .net, or .uk, for example, in favor of something like .home or .myhouse instead. How, I wondered, could I add extra host names to dnsmasq?

(more…)

Learning how to create Linux screencasts has been the most frustrating technical challenge that I have tackled for a very long time. I should have been worried when a search for “Linux video editing” returned, as its top hit, a bare and completely unstyled web page from 2002 which concludes that “video editing on Linux hasn’t really arrived yet.”

My efforts were, in the end, successful, and you can see the result — my first two screencasts — in my previous blog entry, which I posted earlier this week.

In the hope that my toil can benefit others, let me outline the details of the process that I have worked out for creating, editing, and posting Linux screencasts. For the impatient, here are the three most important things I learned:

• Linux tools have great difficulty keeping audio and video from gradually going out of sync over several minutes. To avoid problems, always run recordmydesktop with its “on-the-fly encoding” option, and never let “ffmpeg” anywhere near your audio! This not only means that you have to use “mencoder” instead when converting between video formats, but even within mencoder you must avoid the “lavc” audio module, since its code seems to have the same problems.
• Do not attempt to directly edit the resulting Ogg/Theora video! Instead, convert first to the Digial Video (DV) format, and perform your editing there. Be prepared for the fact that DV files are enormous, and that DV pixels are not square.
• Finally, convert to something like AVI for submission to Google Video. Avoid submitting a raw Ogg/Theora file, since even though Google can decode it, their decoders will waste valuable screen space by placing an empty border around the result.

For those interested in more details, I have more to share. Keep reading!

(more…)

After several frustrating weeks learning how to create, edit, and publish a screencast under Linux (about which I will write a separate post), I have now published screencasts of both presentations that I gave at the PyAtl meetup in January. I opened with a talk about the import statement, and where Python packages lived before egg files were invented:

The audience seemed most interested in the last section of the talk, where I discuss three techiques for debugging problems with Python’s import statement; fast-forward to around 3:00 if you want to catch that part by itself.

Next, Jeremy Jones spoke about eggs, Noah Gift introduced virtualenv, and, finally, I got back up to talk about buildout. This was probably my own favorite among the recent presentations I have given, and it’s the one I’ve worked hardest to adapt to a competent screencast:

I have prepared a supplement to the above screencast that gives additional hints and tips about using buildout, as well as a link to the source code of the module that I use as my example.

Finally, if you’re ready to see something a little less polished — something that instead of being a screencast is actually a film of me talking in front of a live audience, and gesturing and jumping around — I filled a vacant lightning-talk slot at our February PyAtl meeting with an impromptu introduction to Kinetic Style Sheets (KSS), using an example application that was still sitting on my laptop after at a Georgia Tech developer’s luncheon earlier that week:

Now I can finally turn my attention to preparing for my upcoming talk at PyCon 2008 in Chicago! I will be talking about the basic “adapter” design pattern, and how a framework like Zope 3 can facilitate its use. Stay tuned for more information!

On Sunday afternoon I released a new version of PyEphem, which is available from the Python Package Index as version 3.7.2.2! I want to thank the users who spurred its development — in particular, John Duchek of the Astronomical Society of Eastern Missouri encouraged me both to create the new moon-phase functions, and, as I announced several weeks ago, to finally make PyEphem available in binary form for Windows. Thanks, John!

PyEphem now also includes a small database of world cities, so that people living near one can simply call ephem.city(’Boston’) to get their longitude, latitude, and elevation, rather than having to look up the numbers themselves.

Download the source for my GraphViz database symbol featured in this article: DatabaseShape.ps

I have started using the GraphViz application, which accepts a list of nodes and arrows, and figures out how to attractively arrange them in a diagram. For example, you can very nearly produce this output:

by supplying this rather modest input file to GraphViz (most of whose length comes from my wanting particular colors)::

 digraph Application {
    rankdir=LR;
    node [shape=box,style=filled,fillcolor="#C0D0C0"];
    subgraph clusterClient {
       label=”Client”; style=filled; bgcolor=”#D0C0A0″;
       “Browser”;
    };
    subgraph clusterServer {
       label=”Server”; style=filled; bgcolor=”#D0C0A0″;
       “App”;
       “Database” [shape=DatabaseShape,peripheries=0];
    };
    “Browser” -> “App” [label="HTTP"];
    “App” -> “Database” [label="SQL"];
 }

I used the words “very nearly” because, in fact, GraphViz only knows how to draw simple shapes like rectangles, and is ignorant of the standard cylinder-shaped database symbol that I have used here by asking for a DatabaseShape. Submitting the above code to GraphViz will, normally, produce three nodes that are all rectangles. To teach it about the database shape, I had to write some PostScript.

(more…)