Robey Pointer has made programming with SSH attainable for several years now. However, if you are slow to pick things up like me, the demos only get you about halfway there. I needed a little extra boost to understand how to use Paramiko. I just happened to run across the Command Line Warriors blog today which has this little tidbit. Not only is it brain dead simple to create a little ssh script with this, but looking inside ssh.py has given me a great demo that shows how to use the Paramiko suite for different things that I wanted to try. I just wrote a file transfer program in four lines. I’m sure the jokes on me for being a little dense, but I’m excited because this has given me the extra help I needed to start using Paramiko.

Steve Yegge talked about programs that you don’t have to restart in his blog post on the Pinocchio Problem. Firefox is stable enough now, that the biggest need for restarts is messing with extensions (installing, enabling, uninstalling, disabling, updating).
You can do your own Firefox Extension Development after first setting up the environment. This gives you some ability to rework extensions without the Firefox restart. There is also a nifty extension boilerplate generator tool that can bootstrap that first extension in less than a minute.

More exciting is GreaseMonkey, where you can do a lot of damage without restarting. Greasemonkey scripts can then be turned into extensions after you have perfected them.

While having lunch with one of my brothers, we discussed the best way to find places that served Guinness. I had read about Beer Menus, but I figure it will be a while before something like this comes to town. So, I decided to make my own map. Google Maps work OK. How can I get the push pins populated? I assumed I could hook some sort of GPS module up to my iPhone. Then I could have a button on the phone that would send GPS coordinates to a remote server when I pressed a button on the phone. However, I don’t really want to pay the fees for SMS messages. Geotagging of photos is becoming more popular. After reading about yet another geotagging device (the Sellgino GS-200), I decided that pictures of each place could be really cool as well. I could just take a picture of each place with the iPhone while carrying the geotagger around with me. At some point, I could offload the pictures, sync them with GPS info matching the EXIF data, and push each bar up to a map. In theory the software would be easier to write when used in batch mode like this as well. I could just write a simple client that runs on a local machine. OK, so I don’t end up with a Guinness button, but I might end up with something easier to build, which always improves the chances that this will get done. In addition, I can leave myself with another challenge to finish the tighter integration at some later date.

Stefan Brands has quite a list of issues with OpenID. I would think that the nature of Yubikey could solve some of the phishing issues. Since the password changes every time, capturing the password gives the bad guy one free login, but doesn’t hand off the keys to the kingdom. The privacy and web activity tracking issues won’t be solved this way. Running your own OpenID server on an SSL protected domain would help a lot, but not everybody can afford (financially or technically) to do that. Stefan points out a lot more issues that have made me reconsider OpenID and whether it is the right idea.

I like to listen to Security Now! when I’m out walking. Episode 143 had an explanation of a new product called Yubikey. The basic idea is that you have a device that plugs into a USB port and is recognized as a keyboard. Pushing the only button on the device causes it to type a 44 character string which acts essentially like a One-Time Password. Combining this idea with something like OpenID, you can have a relatively secure authenticator. It could be combined with a password/passphrase challenge to provide two-factor authentication. This isn’t anything new, as VeriSign and Paypal have tokens. The same limitations of physical tokens exist, mainly that your Yubikey could be lost. In the case of the USB interface, the interface on the USB could be physically damaged or worn down.

The pros of this device are where my interest lies. Yubico has opened up the specification and is providing SDK’s to make this work. Ubico has provided an OpenID provider that can use a Yubikey or you can host your own authentication server. For anybody who wanted to build their own system or experiment, this seems incredible. VeriSign is not likely to give you their code and let you set up your own token server to use with their tokens. That is Yubico’s business model. They want you to set up your own system and are working to help you do so. The second big pro is ease of use. It is not hard to see the 6 digit key on a VeriSign token and type this in to an input box, but the 6 digit key is pretty limited. Yubikey on the other hand has enough digits to play with that it can build some smarts in. The key is uniquely identified by the string it sends. It can now function as your id/username. The string as a whole is a unique string that acts as a One-Time Password. So with one string, I can provide a name/password pair to identify myself. The server can take the name piece of this to look up and check against my password. This string is generated by inserting the USB device and pressing a button. This is esentially one-button login. Combined with OpenID, it is essentially one-button login to a lot of websites. On top of that, you can’t “give your password away” to a phisher. You could lose the Yubikey, which is why I would recommend using it in conjunction with another password, but someone can’t sniff out a physical key. This is pretty cool. I recommend checking out the Yubikey link for more info.

Although there are a lot of options for Python editors on the Internet, I have been using some version of VI for far too long to give up my muscle memory of modal editing that VI uses. Wing IDE actually has decent VI keystroke support, but it doesn’t go quite far enough, or I haven’t figured out how to make it do what I want. For instance, I use all sorts of ed commands, and like my macros and buffers. It looks like the Wing authors are interested in improving the VI personality of the editor, but I’m impatient. I think I’ll have to work at using Wing and file a view bug reports, although I’m not sure they aren’t really enhancement reports.

In the meantime, there is a lot of information on the web about how to set up VI to use as a decent Python editor. This article by John M. Anderson was helpful to cover a bunch of the basics. I also found a great 6 easy steps process to get ctags working on Windows. Maybe this isn’t such a big deal to you, but I have jumped through a lot more steps before to get this going. The value here is in the conciseness of the information presented.

I don’t have my perfect vimrc set up yet, but I am a lot closer after adding BufExplorer, NerdTree, and Snippets. I plan on figuring out more cool stuff that I can post about Vim and Python.

I read a blog entry recently that Steve Yegge wrote last year about what makes great software. Coincidentally, I have recently been working on better Python integration with Vim and better Vim integration with Firefox. Steve’s blog post gives several major criteria for good systems, not that completing the list makes a piece of software good. Instead good systems should have all point in the list covered.

1) systems should not reboot
2) systems must be able to grow (without rebooting)
3) a system should have a command shell
4) a system should have integration hooks (Steve calls this advice, and it is probably more subtle than “hooks”
5) systems should have an extension language and a plug-in system
6) perhaps the hardest today, systems should be introspective

The article spent a good amount of the space on Firefox. I think he spent a lot of time trying to explain how to improve Firefox because he would like to use it. This seems like a win for the Mozilla group to me. If Firefox was beyond hope, it wouldn’t take more than a couple sentences to write it off.

The newest release candidate of Firefox 3 does not fix the need to reboot, but less memory leaks are a good step in the right direction. I’m not to worried about murdering my programs, but is definitely an inconvenience to me when I’m forced to restart Firefox. I think working towards no restarts would help stability during normal use. I would think that all of this stuff should be figured out in the OS anyway, but as Firefox gets more complicated, I supposed it has to take on more aspects of an OS such as proper process and memory management. It should have a good response to a lack of resources. The dialog that tells me a script is not responding is a start, but the browser should have better built-in health monitoring if possible.

Steve gives the example of Greasemonkey as a way to extend Firefox without rebooting. I wonder if add-ons could be written as strictly JavaScript, considering one can specify CSS and write HTML elements along with program logic. I have also been playing around with Chickenfoot. It has a limited set of extension scripts, but I think we need more access to UI elements with Greasemonkey. For right now, that is held back because of security concerns.

If security is going to be the limiting factor, then we still need a way to install extensions without restarting. I don’t know if there is a good way to distinguish whether changes to chrome are safe or not. Once XUL runner is fully functional and hosting Firefox as an application, maybe the problem will be changed. Firefox will act like a virtual machine, which might make for seamless restarts, rather than no restarts.

Brendan Eich also wants to let Firefox be extended with Python. If this actually becomes a reality, I anticipate the number and kind of extensions skyrocketing. JavaScript is pretty easy to work with, but Python seems even better to me.

As far as command shell. I have been using yubnub, which gets you part of the way there. I recently discovered vimperator, which provides not only a command-line, but a partial Vim-like environment. If you don’t have the piece you already want, just add something to yubnub or vimperator to extend your shell. Again, I hope that adding python to the mix will allow this to reach even farther and be easier to extend. I haven’t become practiced with vimperator yet, but already I can see it’s usefulness in navigating by keyboard.

I recently started playing with Python again. It is amazing how fast you can pick up information on how to create a service or compile Python into standalone applications for OSX or Windows.

Python also has quite a few GUI frameworks as well as a good number of python web frameworks.

After looking at portability, pre-built binaries, ease of building a program, and ease of compiling, I have settled on wxpython as a GUI framework for now, although I have used all of these except pyxul to build different applications. Either Python(x,y) or Enthought provides a pretty comprehensive Windows package including WxPython. The former also has PyQT as well.

The web framework question is a lot tougher. I have played around with Turbogears, Pylons, Django, and web.py (if that can be called a framework), but I haven’t built anything serious with any of these. I recently came across web2py. I like that it seems to give a built-in tool to add new applications. It also seems to have some of the built-in administration screens like Django. I am working on building a sample website with it now, both to teach myself and to show others a framework example. Since web2py was built with education in mind, it seems a more natural fit for this last purpose. A long time ago, I was messing around with Zope. Although Zope and Plone are pretty powerful, I dont’ think I would use them as teaching examples.

More exciting for me than playing around with Python, I have been attempting to teach it to other people. It just seems to flow naturally, both to CS students who have had experiences with other languages, and with complete newbies. I really like Dive into Python, but have been looking at other sources such as Byte of Python, a starter wiki, and Wikibooks as well.

Eventually, I hope to be able to apply some of this knowledge to Sugar which has really intrigued me. Perl had a project to recreate a lot of the Unix tools in Perl. I have a Perl OS archive saved for years now. I think a lot of these can be recreated in Python, but the idea of creating a whole interface in Python seems to be an even greater amount of work with a possibly greater payoff.