VoodooPad and Subversion

Yeah, Git and Hg are the new hotness, but for some projects I’m still using subversion.

A also like keeping my project documentation in VoodooPad. By keeping a narrative of development in an ever-growing VP, I can go back and figure out where certain “design” “decisions” came from that are currently causing me problems. Not that it ever happens to me. *cough*.

Anyway, I’m moving into a new 13″ MacBookPro (sweet sweet little machine), and I’m taking the nuke-from-orbit approach: only installing software and data files on-demand. So now I need to be able to commit VoodooPad doc changes. This is complicated by VP docs being a bundle with files coming and going as the file is edited.

VooDooPad has nice Script Plugin support, including some sample LUA scripts. Oooh! “Commit changes to subversion”. Perfect!

Getting it set up correctly isn’t 100% obvious – here’s how I do it:

1. Snarf the “Commit changes to subversion” code” and paste it into a new file living at.

   ~/Library/Application Support/VoodooPad/Script PlugIns/Svn Commit.lua

2. Subversion now lives in /usr/bin, so edit the /usr/local/bin references accordingly. Here’s my version:

   --[[
   VPLanguage = lua
   VPScriptMenuTitle = Subversion Commit
   VPEndConfig
   ]]
   -- we assume subversion is located in /usr/bin/svn
    
   posix.chdir(document:fileName())
    
   -- add new files
   os.execute("/usr/bin/svn st | " ..
   	       "/usr/bin/grep '^\?' | " ..
   	       "/usr/bin/sed -e 's/\?[ ]*//g' | " ..
   	       "/usr/bin/xargs /usr/bin/svn add")
    
   -- clean up deleted pages
   os.execute("/usr/bin/svn st | " ..
   	       "/usr/bin/grep '^\!' | " ..
   	       "/usr/bin/sed -e 's/\![ ]*//g' | " ..
   	       "/usr/bin/xargs /usr/bin/svn rm")
    
   os.execute("/usr/bin/svn ci -m'auto commit'")
   os.execute("/usr/bin/svn st")
   vpconsole("Commit complete.")
   

   


3. Set up your favorite form of passwordless access. I’ve been using ssh’s authorized keys: passwordless access quickie.
4. Restart VoodooPad to get the new menu item.
5. Make changes, and no longer fear commitment.

AppEngine Launcher

One of the cool things about working at the GOOG is you can spend 20% of your time on projects unrelated your usual work. It’s the responsibility of each engineer to actually find or make a project, and to take the time to do it. But it’s really nice having the opportunity.

Over the last 9 months or so, I’ve thrown in my 20% time on the App Engine Launcher for Windows. Even though it says Windows, I did most of my work on the Mac, since the project is in Python and uses wxWidgets. Because of this, the Launcher works on Linux too.

And now it’s shipping. Woo! And it’s open sourced.

What is the Launcher? It’s a little dashboard where you can create new App Engine projects, run them locally, look at the logs, and deploy to appspot.com.

So, why this particular project? Good question, since I haven’t done much with AppEngine, outside of a small Photo Software Quickies database, similar to the Borkware Quickies. There were two reasons.

The first was to keep working on a project with the Launcher tech lead, John Grabowski. I worked with him on a previous project and had a lot of fun. If you ever get a chance to hear him talking about brewing beer or raising his six kids, you should.

The second was to have an excuse to expand my horizons. I’ve never really used Python before, and I need an actual project to work on before I really learn something. Here was a project that folks have been wanting and I could learn a new language and toolkit. Perfect fit. I absorbed a huge amount about Python, particularly during the code reviews from our Python expert Dave Symonds in Australia. Every code review I had to fix stuff, but I learned a bunch.

So now the technical take-aways.

Python is a nice language. self.There() are a self.few() annoying self.things() about self.python() self.that() self.KindOf() self.drove_me_nuts(). Whitespace indentation wasn’t one of them. I still program it with a C accent (and my C still has a Pascal accent), but through code review I fixed the most egregious anachronisms.

As a cross-platform toolkit, Wx is adequate. If I *had* to use a cross-platform toolkit, I’d use Qt, and also look at CocoaTron. And then weep for the demise of Galaxy. Wx actually looks and behaves well on Windows and Linux, but it doesn’t even reach the Uncanny Valley on the Mac.

We decided to use wxglade for creating the user interface components. That was probably the only big mistake of the project. It was nearly unusable on the Mac, frequently neglecting to save changes. Sometimes it took 5 edit/ok/save/generate-code cycles for menu bar edits to actually stick. Oh, and it’s a code generator. We hateses code generators, my precious. For some reason, wxglade kept on trying to make the main window huge. And finally, the code generator occasionally decides it wants to generate the same code twice. It doesn’t break anything, but still messy.

So, go check out the Launcher, now included with the App Engine SDK for Windows and Linux. There is a Mac version (which I didn’t work on) which has been shipping with the App Engine SDK for Mac for awhile.