PyCon Poster Session will be Amazing

January 23, 2011

As the poster session chair, I’ve been watching poster proposals come in for PyCon over the past several weeks. I was very happy with the posters last year, but this year we have a truly amazing collection. Since the submission deadline has been extended until Tuesday, January 25, (which is also the Early Bird registration deadline) I won’t name specific posters yet, but the submissions cover the spectrum.

There are posters on Python in the sciences and bio-informatics, on Python for education and citizenship, on new packages and uses of Python, and even a couple of posters that showcase Python as a tool for hardware hacking “makers”.ย  And every single one of them looks great. Every. Single. One.

As I recall the excitement in the room last year for the first PyCon poster session ever, I can only smile as I think of what the reaction will be to this collection. I promise you, people will be wishing that the poster session could last all day to give them enough time to inspect each poster and chat with every presenter.

Better yet, you still have a chance to join this impressive company. If you want to submit a poster, just swing by the poster session CFP on the PyCon site by Tuesday to submit a poster proposal.

See you at PyCon!


Not Python – AppInventor doesn’t quite do Life

January 10, 2011

AppInventor Test Drive

I’ve always been sort of fascinated by drag and drop programming schemes – the sort of thing where you use little graphical blocks to represent code structures. The simplicity of it appeals to me as a teacher of programming for one thing. And I’m not alone – this idea is used in languages/environments like Scratch, which is gaining popularity in the school world right now.  The problem with languages like those is that they always seem to be limited – they’re too cumbersome to write much of a program. And for teaching languages, sometimes that’s OK.

Recently, I decided to try a drag and drop language with at least somewhat higher expectations – Google AppInventor. I’d written a few little test apps using AppInventor – a clock, some tests of location, buttons and colors, and one where I could “roll” a ball around the screen by tilting the phone, and it looked like it had some real potential.

A Real Test – Life

That led me to try writing Conway’s Life. I like Life because it’s fairly easy to write (I make my AP Comp Sci students write it every year), it’s fun to look at, and yet it asks a certain amount from a language – 2 dimension arrays, a fair amount of processing, some screen redrawing, etc.  I know that following a discussion of Alice, our tech support specialist, Simรณn, wrote a version of Life in Alice, which was painful – it required huge contortions to create a 2 dimension array of cells, and was painfully slow with even a 10 by 10 world.

So New Year’s day (yeah, I don’t really follow bowl games ๐Ÿ˜‰ ) I started on it and made a fair amount of progress. Some things were actually easier than I expected. Creating a 2 dimension array as a list of lists was obvious for a Pythonista like me, and drawing the cells on the canvas was also dead easy.

Other things were not quite so straightforward, but still no real problem. For example, AppInventor doesn’t have a “counting” for loop, but only a “for each item in a list” loop. That meant to get the indexes I needed to check surrounding cells I had to use while loops and manual increment counters, but that was no big deal.

So after an evening of messing with it and looking at the documentation, I was in pretty good shape – I had a 20 by 20 “world” or cells which I could randomly set as alive or dead and I could iterate through that world and draw dots on the screen for the live cells.

Frustrations

At that point frustrations started to set in. The first frustration wasn’t really AppInventor’s fault entirely, but rather just the nature of the coding by blocks interface. I soon found the process of coding by blocks very irritating. Switch to the right block pallet, drag out the block you want, set initial values, then drag into place, rinse and repeat. It doesn’t seem so bad when you first start out, but keep in mind that everything is a block. For an if statement comparing two items, you need four blocks – the if, the comparison, and each item. When you know what you want to do, repeating that process gets very tedious very fast. In fact, I started wishing I could just open a window and type in the code. Of course, a little tedium never stopped me, so I pushed forward.

The second frustration ended up being a bit more of dealbreaker. In its current incarnation, AppInventor allots a fixed size panel for assembling blocks. As my logic got more complex, my stacks of blocks grew until they spilled off of the panel. That could have been survivable, but then I found I couldn’t edit the parts off the panel, and I couldn’t move the stack so that the bottom end would stay on the panel. You can zoom in and out, but that doesn’t change the relative size of the blocks compared to the panel.

At that point, just short of getting the rule processing finished, I gave up. I suppose I could have gone back and tried to break things down into smaller functions or pulled my stacks apart for editing and the stuck them back together, but I had simply had enough. And I had already broken things down so that the functions would have been under 30 lines of Java or so. It’s not an intrinsic limitation, of course, but for the moment it does limit the code you can write. That was the issue that made me give up, although I might have struggled on a bit if there hadn’t been one other issue.

And speed…

I also ran into a issue with processing speed. There isn’t any. Running on a Droid Incredible, it took 2-4 seconds to process and draw a 20 by 20 world. That’s pretty shocking. After I gave up on the AppInventor, I wrote a similar implementation of Life in Java and doing the same processing and drawing seemed to be nearly instantaneous, to the point that I needed a 200 ms. delay in the processing loop. (For the record, I never got to the point where the AppInventor version was looping to update, instead I was starting each generation with a button press.)

Conclusions

In spite of the fact that it failed my Life test, I find AppInventor an interesting tool. As a teacher, I can see it being useful for introducing programming to non-programmers. The blocks should make things easier to manage and understand, and the coolness factor of writing an app for your phone would boost motivation. It also is good as GUI-based “glue” for the OS, which I’m sure was one its primary purposes – you can tie several different bits of the phone’s functionality together pretty quickly. Building on this I can see a use as almost as an interface generator – whipping up a quick UI that then calls other code (maybe written in Python for the ASE?) and grabs the results. As I get time, I’m going to experiment with this.


Python in the news

December 12, 2010

How we got a Python story published

This past Monday, the unlikely occurred. The morning newspaper here in Fort Wayne, Indiana ran a small article on high school kids using Python. That’s unlikely for a few reasons – first, while “tech” school programs around here tend to get news coverage, you almost never hear about programming (that’s because even in “tech” high schools, very little programming is taught). And when programming is taught in high schools, the language tends to be Java or Visual Basic. (I know, I know… don’t even get me started on that topic.) And most people around here, reporters included, have never heard of Python.

The story was about my Python class, and it wasn’t an accident. The class is a project based class intended to be accessible to non-programmers, where we’ve been exploring the capabilities of Georgia Tech’s combo of a Scribbler robot with their Fluke bluetooth board. If you missed Jay Summet’s poster at PyCon, the cool thing about this pairing is that you can run Python on a laptop and use it to control and interact with the bot by way of the bluetooth connection. So my kids have been drawing shapes, solving obstacle courses, taking and processing images, playing music, etc. with the little guys. Along the way they’ve also learned about looping, branching, functions, modules, documentation and sharing code, among other things. It’s probably been one of the cooler classes I’ve ever taught, and I’ve been enthusiastic about promoting it internally here at school – to the school newspaper, the school web site, teachers, the school administrators, really anyone who would listen. 

It’s a great bunch of kids and they’re doing some fun and interesting projects, but I know from experience that alone won’t get you much press. In this case I think we did some things right to get the word out about my class and Python. Since I’m pretty sure that my class isn’t the only bunch of people in the country doing newsworthy things with Python, I thought I’d outline what we did in the hope that it might make a small contribution to the Python advocacy front.

What we did

I’m not a publicity expert, but here is my take on how we got our 15 seconds of fame.

The first thing I did right was the internal promotion. Maybe it’s having a book to promote, maybe it’s just advancing age, but I’m getting less shy about promoting projects these days, and it does make a difference. If even the people you work with don’t know you’re doing something cool, how can you expect anyone else to care?  By making sure that everyone internally knew about my class, I got the support of our administration and the even more valuable support of our publications director. Having her help made things easier for me, although if you don’t have that help, some time and research can cover a lot of the same ground.

Getting our story published came down to 3 main pieces:

  1. knowing who to contact
  2. knowing what they want/need
  3. giving it to them

Who to contact

In my limited experience, just sending out press releases to the newspaper is rather like cold sales calling, resume carpet bombing, or handing out leaflets on a street corner – the return is vanishingly tiny. Instead, you have to make personal contact with the right person.

These days newspapers departments in particular are understaffed and overworked, so  don’t even begin to think that anyone on the other end will take the time to figure out where your news belongs. It’s your job to make things easy for them – before you do anything else, figure out what kind of story you have, where it would go, and who would write it. In my case, it’s our publications director’s job is to help find the answer to those questions, but even without that help our situation would have been pretty straightforward. The paper does a weekly “Education Notebook”, with a small education feature and education announcements, all done by the same person. She writes education stories, we have an education story. That’s the person we contact.

What do they need?

As I said, newspapers are under pressure these days – falling circulation, staffing cuts, and so on. For example, these days in Fort Wayne, with over 200,000 residents there are now a total of only four full-time newspaper photographers, and they are on the run all day. So if I want a reporter to run my story, she has to be able to see easily what the story is and how it fits in her section. So we had to tell the reporter what Python was, what our kids were doing with it, and why she (and her readers) might care. For us, that came down to 3 things:

  1. High school kids were using the same programming language as Google and NASA.
  2. Robots make for a more beginner-friendly approach to learning programming.
  3. Kids were doing some seriously cool stuff, like programming “intelligent” behavior in robots.

Give it to them

The story was good enough that the reporter and a photographer came to visit the class. Here again we made every effort to give the the story they came for. I spent a little time before class giving the photographer some background info, and once the class started they had full access to talk to the kids as they were working, and to ask me more questions for background. It’s a bit of hassle, but worth the 45 minutes or so of time it takes.

Follow up

Finally, after the article appeared, I made sure to send a quick thank you email, which is not only polite, it helps keep the connection open for the next time. And I also made sure to circulate the article link to the Python education community and other interested parties. Oh, yeah, then I blogged about the whole thing here… making sure to get the absolute maximum mileage out of one tiny article. ๐Ÿ˜‰

So that’s it – I hope our experience inspires other efforts to publicize interesting Python projects in their communities.


Ohio LinuxFest

September 13, 2010

I’m recovering from the 2010 Ohio LinuxFest. Between talking about Python to Linux sysadmins for a solid day, the evening gatherings, the hallway track, and everything else, I very nearly lost my voice. But that was a small price to pay.

For my “Python for Linux System Admistrators” tutorials everything went quite well. There was a minor delay waiting for a projector, but otherwise the venue was fine and I had a good turnout – some 20-25 people who (in addition to being sysadmins) were a joy to teach. By the end of the day, everyone was tired, but I was pretty happy that we’d covered a core of Python that would a) let them get going on their own and b) was particularly relevant to their jobs. If anyone is interested some materials for the course are here. The slides are just as I used them, meaning that in some cases they are just prompts to remind me of where I’m going, rather than a standalone resource. But anyway, they might be of some use.

In addition, the bookstore sold a few copies of Quick Python Book, 2e, I caught a few good talks, and more important, I got to talk to several interesting people – maddog, Jorge Castro and Amber Graner from the Ubuntu community, Linux scribe Brian Profitt, Robert Blackwell from the Perl community (I promise I’ll be nicer when I talk about Perl from now on), and several others, not to mention a rather inebriated Buckeye fan and even my high school girlfriend. How can you beat that?


Python for Linux at OLF

September 1, 2010

I’m in the final (but not as final as I would like) stages of preparing for my day-long tutorial at Ohio LinuxFest. OLF, as we call it, is a great event, with some good keynotes, interesting talks, and even maddog. Not to mention first rate tutorials, such as, oh… “Python for Linux System Administration”.

The morning session I’ll spend on basics – writing scripts that illustrate control flow, lists, dictionaries, strings, etc. from the point of view some basic sysadmin scenarios. I’ll also introduce the basics of the subprocess module to call other Linux tools.

Then in the afternoon session, we’ll look at some more involved tasks, like traversing files systems, regular expresssions, daemons, using the network, etc.

I’m looking forward to it – I think it will be a blast.

So if anyone has any cool intersections between Python and Linux sysadmin you wouldn’t mind me stealing, or any other suggestions or words of wisdom, by all means let me know.


IndyPy Meetup and Python 3

June 26, 2010

This past Thursday, I gave a talk to the Indianapolis Python Meetup. It was, in a word, a blast. The venue was “The Boardroom” at Scotty’s Brewhouse, which was really nice – a big table, with centrally located connections to a 42″ flat panel monitor on the wall. And Scotty’s also has good burgers and beer, so it has to be the most comfortable place I’ve ever given a talk.

There were 14 of us, and both the Python knowledge and interest level were high. The guys from sixfeetup.com provide a certain amount of support, particularly co-organizers Calvin Hendryx-Parker and self-designated PEP-8 nazi ๐Ÿ˜‰ Clayton Parker. I talked about Python 3, hitting both the features that I consider improvements to the language and the changes that cause the most pain in porting old code.

The talk was well received, the burgers and beers were great, and I was delighted to find such a vibrant group of Pyhtonistas in Indy. I hope to return.


Seven Languages, Seven Weeks – Io

April 18, 2010

I’ve fallen behind, but not given up, on my seven week tour of different languages as I read Bruce Tate’s Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages. The second language in the tour is Io, a prototype-based language created by Steve Dekorte. Io is not mainstream, and perhaps not yet fully production ready, but it is interesting. In fact, part of my delay has been in digesting the very different paradigm that Io presents.

In a language like Io there are no classes – to create an instance, you clone something – either Object or something else that has ultimately been created by cloning Object or something else that has been created by cloning Object or something else… well, you get the idea. And everything about an object can be overridden, since those attributes are “slots” that can be arbitrarily assigned.

In Io everything is handled as messages passed to objects, and the way that any object handles any message (a slot, again) can be overridden. So in Io, ‘hello world’ becomes:

“Hello, world” print

That is, send the print message to the “Hello, world” object. And what’s in the print slot can be redefined. Once you get in the habit of looking at things that way a lot of options open up. Add to that some pretty slick concurrency handling and Io starts to look pretty intriguing.

I can’t describe Io in the small space of a blog post, so I’m not going to try. And in fact that would be exactly my criticism of Seven Languages. For such a different (from the procedural/OO norm) language, the text gets the reader in to deep water very fast. The thinness of explanation in the text quickly lead me to the web, which is sort of what the author intended. The problem is that looking at Io material on the web quickly became more absorbing than the text (what’s this? Python bindings for Io?) and it was only belatedly that I came back and played with the books’ examples.

And since I carped about it in an earlier post, I have to mention that I found it a little irritating that the author had to describe overriding an object’s forward method (the mechanism for searching prototypes to find a method) as being equivalent to Ruby’s method_missing, which seems to be a bit of a stretch (and a bit Ruby-centric). Io isn’t Ruby, and while it can be made to do something equivalent, it simply doesn’t have the same features.

On the other hand, I found the choice of Io to be a good one, and completely in line with the intention of the book. I didn’t really have any feel for prototype-base languages before, and now I feel I do.

One of the comments on my post about the Ruby chapter suggested that if I was upset about Ruby, Io would give me a heart attack. In fact, my heart rate ended up being quite low. I had quite a bit of fun playing around with Io and figuring out how to create a DSL to produce XML. I think the reason is Io’s consistency and simplicity. EVERYTHING is objects with slots being passed messages, and that’s pretty much it. Once you accept that, Io behaves as you would expect.

While I’m not entirely sure that Io is ready for production use, I can definitely see implementing a DSL in it, and I may well be be back to experiment more.


Python and recovering Firefox sessions

April 11, 2010

First let me confess, I am a tab-aholic…

I tend to have several Firefox windows open at once, with several tabs in each. And I leave them open for… well… weeks. And usually that’s fine – it restores everything if I have to reboot or restart Firefox, and all is well. Except when it doesn’t.

Sometimes, for whatever reason, the sessions aren’t restored, and all of those tabs, as in “hey, I wasn’t quite done with that!”, are lost.

When this happened to me last night, I took a look in my Firefox profile directory and discovered something about the way Firefox stores it’s sessions. I’m sure it’s well-known to many, but it was news to me.

When I looked at sessionstore.bak (the automatically created backup of sessionstore.js) I saw something like:

({"windows":[{"tabs":[{"entries":[{"url":"http://stoa.canterburyschool.org:9080
/stoa/courses/Faculty/TechnologyGuides/VoIPandSkypeinForeignLanguage
/document_edit_form","title":": VoIP and Skype in Foreign Language","ID":2528274837}...

Hmmmm… I know that’s Javascript, but it also looks a lot like a Python dictionary. Why not see if Python could eval() it to a dictionary? My first try failed on the unknown identifiers “true” and “false”, but after defining true and false as equal to Python’s True and False, it worked. Now I had a nested set of dictionaries containing all of my previous session’s info. Not bad.

[Edit: Not being a regular JSON user, and since the file extension was .js, not .json, I never considered that this might be JSON. It turns that it’s not QUITE JSON and the Python JSON library won’t decode it (without at least stripping off the leading and trailing parentheses). Check out this discussion for more info.]

From there it was easy to create some code that would grab the URL’s from an unrecoverable session and put them into an HTML page for easy access later.

Warning: this code uses eval() on arbitrary strings loaded from an arbitrary file, so it is not secureuse with great caution. If it wipes your hard drive, sells your house and absconds with the money, and kicks your dog on the way out, you have been warned.

In any case, below is my session recovery code, which I’ve already used a couple of times.


import sys
""" this code is released to the public domain and meant only for illustration. It is not
    warranted as being safe or suitable for any particular purpose at all.

    in particular, this program evaluates (and potentially executes) arbitrary code,
    so use with caution.
"""

def get_session(infilename, outfilename):
    true = True
    false = False
    sessionstring = open(infilename).read()
    session = eval(sessionstring)

    outfile = open(outfilename, "w")
    for window in session['windows']:
        outfile.write("---------------Window-----------------<p>\n")
        outfile.write("<ul>\n")
        for tab in window['tabs']:
          outfile.write( '<li><a href="%s" \="">%s</a> - %s</li> \n' %
                         (tab['entries'][0]['url'],tab['entries'][0]['url'],
                          tab['entries'][0]['title']))
        outfile.write("</ul>\n")
    outfile.close()

if __name__ == '__main__':
    infile = sys.argv[1]
    if len(sys.argv) == 3:
        outfile = sys.argv[2]
    else:
        outfile = "sessionsave.html"

    get_session(infile, outfile)

Seven Languages, Seven Weeks – Ruby

April 1, 2010

I just finished the first stop on my seven language tour. Ruby was in some ways an easy start, although not as easy as I would have thought. While Ruby is enough like Python to seem familiar, I was still surprised by some of the differences I found.

The author of the book, Bruce Tate, is a Rubyist as I understand it, and he was definitely pushing metaprogramming as one of Ruby’s cool features. And in that department (and in others) Ruby definitely has some cool tricks.

After some easy build-ups, including arrays and hashes (pretty much equivalent to lists and dictionaries in Python), a sort of slick implementation of a Roman numeral class, and using inject to cumulatively operate on all of the elements of an array, the final problem to be solved in Ruby is creating a module which creates a class to read a CSV file. The file is opened automatically when an object of the class is instantiated, assuming a filename derived from the class name. That is, if the class is ‘ActAsCsv’, it will open a file ‘actascsv.txt’.

The first line of the CSV file is assumed to be a header containing the names of the fields, and one is supposed to create a CsvRow class which supplies accessor methods corresponding to each field. So if the first line contains “one, two, three”, you should be able to access the third field of any row with ‘row.three’.

A few things in this exercise left me feeling uncomfortable. First of all, the automatic opening of a file based on the class name, struck me more a parlor trick to illustrate Ruby’s capabilities for introspection, than a practical strategy. While I can do the same thing in Python, I can’t think of a single instance, even in simple scripts, where I would be happy linking all instances of a class to a single file, or even constraining what file is opened. I try to write my classes to handle arbitrary file names instead. I may be making too much of this, but as a teacher I’ve come to really dislike teaching examples which make you say “huh?” right at the beginning.

I’ve always advocated to my programming students that they write programs in such a way that runtime errors are obvious. If an error matters, it should be as obvious as possible, so that you can find and fix it. so I was surprised and a little uneasy to discover that Ruby seems to be taking the opposite approach – if a field or method or array slot is missing, just return nil and carry on. That’s right, no index out of bounds exceptions… ever.

In fact, Ruby takes things one step further. Objects have a overridable method ‘method_missing’ which gets called whenever you try to access a method that the class doesn’t actually have. The default version raises a NoMethodError exception, but once you override it, the behavior is up to you. This is powerful – if you construct your method correctly you can do some interesting things, including dynamically supplying field accessors for rows in CSV file. OTOH, if you don’t construct it right, if you don’t remember to raise a NoMethodError for the truly unexpected values, you run the risk of masking important information.

In my solution, the contents of the row are a hash in the CsvRow, and the method_missing implementation of the accessors is really just syntactic sugar hiding a key, value hash lookup. Add to that the fact that Ruby returns a nil rather than raising an exception if a key isn’t found, and my code can’t tell the difference between an empty field and a missing one. I freely admit my solution may not be the “Ruby way”, but I would argue it’s at least plausible.

So while I’m glad I had the chance to play with a bit of Ruby, and I’m still liking the books approach, I end up with two issues, one regarding Ruby and the other with the example problem. The first is what I’ve just mentioned – I was guided into using Ruby in a way that I think conceals potential bugs, and Ruby was complicit in that.

The second issue is with the exercise. While I’ll certainly concede that Ruby has some syntactic flexibility that Python doesn’t, this problem doesn’t really present a convincing use case. I don’t intend to make my reading of this book into just a ‘so what, I can do that in Python’ response, but in this case it does seem to me that a Pythonic version takes care of the problem more efficiently. If I’m OK with using dictionary access rather than accessor methods – saying ‘row[“one”]’ rather than ‘row.one’ – this example is a non-problem in Python, thanks to the csv module in the standard library.

[Edit: Yes, I know that you can override __getattr__ in Python to provide the same functionality. See the comments for suggested versions. My point was that Ruby’s method_missing approach was what made me uneasy. And it’s more inviting – in Ruby you would override the method_missing method of a class derived from hash, and nothing else. In Python, I would argue, the surgery is a bit more serious.]


Seven Languages, Seven Weeks, the beginning

March 26, 2010

A couple of days ago I got an ad for a new book, still in beta, from the Pragmatic Bookshelf – Seven Languages in Seven Weeks: A Pragmatic Guide to Learning Programming Languages, by Bruce Tate. The book covers some key concepts in seven different languages (Clojure, Haskell, Io, Prolog, Scala, Erlang, and Ruby) over the course of seven weeks, with the discussion of each language broken up into bite-size “days” of discussion, examples, and coding assignments. The idea (which I totally buy into) is that seeing how different languages with different programming paradigms handle various problems will improve one’s understanding of programming overall.

According to the author, he used an online poll to choose the languages, and then made a few tweaks – JavaScript was just too popular, Python was too like Ruby, etc. While it’s not exactly the list I would have chosen – Io? Prolog? – it’s a pretty buzz-worthy collection. Since I already know Python, I’m happy enough that it didn’t win out over Ruby.

The seven in seven thing is sort of a gimmick, I suppose, but a darned good one. I’ve always liked the idea of learning different languages, both human and programming, and this will give me a framework to hit some of the programming languages I’ve had on my list for a while.

My plan is to post my reactions as I work through this grand tour of languages, particularly from a Python perspective. It begins with Ruby, which unsurprisingly seems pretty familiar, but then I’ve only covered one “day” so far.

Now if only someone will come up with a similar book for human languages that includes Hindi, Mandarin and Finnish, I’ll be set for the rest of the year…