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.

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.

Thanks to Marcus Zarra’s excellent Core Data book for this little tidbit.

Hate Interface Builder when dealing with table views, having to clicky-clicky to get down to the table column, and frequently clicking the Wrong Thing and having to start over?

If you hold down the shift key while performing the contextual menu gesture of your choice, you get a menu that lets you go straight to your intended victim:

Scotty, over at the Mac Developer Network, is putting on a C4/WWDC-style independent Mac Developer Conference in England this April called NSConference. I won’t be able to make it, but it looks like a huge amount of fun. I’ve recorded a couple of podcasts with Scotty, and he’s top-notch, and I expect the conference to be excellent.

It’s been awhile since I last used a two-monitor setup. Usually I do all of my work on a 15″ MacBookPro or one of the plastic MacBooks. But I wanted a better monitor for the desktop when I’m doing photostuff, so now I have two monitors again. Last time was in 2002 when I was doing contracting, and the client’s product I was working on wouldn’t fit on a laptop screen. I used a secondary monitor for running the software.

Even back in the Mac II days I always got really annoyed with the “traditional” way of setting up multiple monitors: having it so the desktop areas had large coincidental areas of vertical or horizontal border, so you could have one window span both screens and have it look non-horrible. My problem was I would always overshoot one monitor and end up on the other. I had really come to depend on Fitts’s Law. So why not use that for the monitors too?

I use my monitors as distinct playgrounds: Code and whatnot on one and the client’s big-assed program on the other. Lightroom’s Develop pane on one, and the Library grid on the other. Photoshop’s editing area on one, palettes on the other. I never have one big window that straddles both screens. Hence, my arrangement, seen above, connects the monitors at one corner.

This gives me my sides as big Fitts’s Law targets, as shown in the cute kitty picture. I can slam the mouse to the side to get to the tools. The menu bar at the top remains a nice big target. If I want to go to the other monitor, I throw the mouse to the bottom-left corner.

This makes the mouse enter the second screen at the top-right, and I keep my Photoshop palettes and Nik plugins panel up near that corner for easy access. I twiddle what I want, then throw the mouse into the upper-right corner to get to the main screen. If I lose my mouse, I can just keep mousing up and to the right until I see it on the main screen.

Why not put the other screen to the right? I keep my Dock hidden on the right. With today’s wide-screen displays, horizontal real estate is cheap, vertical real estate is still precious (six more lines of code! woo!). Having the Dock Fitts-style on the right makes it very easy to access.

Why not off the bottom? I use the hard border of the screen when resizing windows large – grab the corner, resize larger quickly until hitting the bottom of the screen. Unfortunately the green jellybean rarely does what I want it to do.

I’m not saying this is the best way for everybody, but it works very well for me. If you get frustrated with your multiple-monitor setup by accidentally mousing into the other screen, give the corner-connection a try.

It’s finally seen the light of day. Learn Objective-C on the Mac is currently in dead-trees form, and available at amazon and other fine retailers.

I’m rather proud of the work that Scott Knaster and I have done on this second edition. It is the contents of the first edition from Spiderworks, but with about 100 new pages of goodies, including NSPredicate and Key Value Coding. There’s also a whole new chapter on Xcode tips and tricks.

The book is designed to sit between Dave Mark’s updated Learn C on the Mac and Dave’s and Jeff Lamarche’s most-excellent Beginning iPhone Development (exploding exploring the iPhone SDK). We go into things figuring you’ve met C and programming, so no “for loops are fun! ooh! variables!” kinds of rehashing. Instead we cover what’s been added by Objective-C, as well as some software engineering topics like indirection, object-oriented programming, the Open/Closed principle, and refactoring.

Plus the book is written to be fun. The English language is one of my favorite playthings. But the humor isn’t over the top and in your face. (at least I hope so)

On the AMOSXP front, we’ve added about 100 new pages of material, such as Objective-C 2.0 goodies (including some perversions of NSFastEnumeration), 64-bit programming, FSEvents, Dtrace and instruments, and NSOperation; and have also been removing some of the old and obsolete classic Mac information since it’s not relevant.

Fourteen students at the Big Nerd Ranch’s Advanced Mac OS X Bootcamp got a first crack at the new material. There is a second bootcamp scheduled for February in Frankfurt. The actual publishing of the next edition (and its ultimate contents) will hinge on Snow Leopard’s schedule. Hopefully MacWorld will give us some schedule insight there.

Hi!

Pittsburgh Cocoaheads tonight will feature Sean McCune talking about Git, the groovy distributed revision control system thingie.

7:30 on the CMU campus.

Cheers,
++md

James Summers has posted a very thoughtful review of Learn Objective-C on the Mac.

The redoubtable AnneKate™ tagged me with a narcissitic brain-dump meme, How I Got Started Programming, so I figured I’d chime in. Usually I don’t do that stuff here, but hey, it’s my blog, I can me me me me if I want to.

How old were you when you started programming?

Sixth grade. Which would put me around 12 years old maybe? My dad brought home an Apple ][ (amazing how many stories like this start off with that machine), intending to do Typical Computer Things like track finances and write simulations of radiation-resistent DNA (my Dad's awesome), but I noticed that it could play GAMES, and I glommed on to it. Dad got occasional visitation rights, but for the most part, the machine was all mine.

It was a super spiffy version, too. It had 48K, plus Applesoft BASIC on a card (Integer BASIC on the motherboard). To switch between languages, you powered-down, flipped the switch, and powered back up. (this was before DOS 3.3). Eventually the machine got a Language Card (16K expansion).

How did you get started in programming?

Typing in programs from magazines and books. This was the time when print publications (remember those?) would have complete program listings. I learn best by by eye -> hands -> screen -> eye -> brain, and this is how I learned programming. Actually, where I learned debugging, since you learn more by making (and finding, and fixing) misteaks than you do by doing things perfectly the first time. At least that's what I keep telling myself.

What was your first language?

Apple ][ Integer BASIC. Later Applesoft, and then the UCSD Pascal system.

What was the first real program you wrote?

Where "real" is something non-trivial, and not something I typed in from a magazine. It was one my Dad designed, and I implemented. It was essentially a quality assurance database system for a Radiology department. Diagnoses could be entered, and then later correlated with reports from Pathology. Or something like that. As far as I was concerned, it was "type stuff in, save it to disk", and then periodically run the worlds most inefficient multi-device sort. But it was cool seeing three Disk ][ units hooked up to a machine, all running.

It was at this time I learned what flowcharts were (remember those?), sigma notation, and basic algorithms and data structures.

What languages have you used since you started programming?

Roughly chronoillogical order, favorites starred

Integer BASIC (*), AppleSoft BASIC (*), UCSD Pascal (*), FORTRAN IV (under UCSD Pascal), VAX FORTRAN, VAX assembly, VAX BASIC, VMS DCL, Dbase ///, Turbo BASIC, Mac/TML Pascal (*), Hypertalk, Object Pascal, C (*), C++, Newtonscript, /bin/sh, /bin/csh, emacs lisp, Tcl (*), Perl, Oracle SQL, PL/SQL, PHP, Objective-C (*), /bin/bash, Javascript, Pythong, Java, Sawzall. HTML (XML and generic SGML) if you count those as langauges.

Badgers, or Wombats?

Badgers, definitely.

What was your first professional programming gig?

Visix Software (R.I.P.) We did a cross-platform toolkit called “Galaxy”. It ruled™, and was definitely ahead of its time. Its geometry management system has not been approached by anything I’ve seen since.

I started off in tech support answering questions about network configuration for our license server and X11 Font Paths for our Looking Glass product. Eventually worked my way up to Señor Software Engineer working on some important parts of the product. Also, because of Visix, I spent four months on Wall Street.

My first “will program for food” was a couple of summers and Christmas vacations during college at the Little Rock VA Hospital, assembling PC-clones from spare parts, and building some software tools for the department. One was an elaboration of the previous medical system (this time in a “real” database, Dbase ///), and an isotope tracking system. I couldn’t really be paid, so I was officially a volunteer. If I was there for four or more hours, I got a cafeteria meal voucher, which was *just enough* for a cheeseburger, onion rings, and a coke. It was the only non-lethal thing there.

If you knew then what you know now, would you have started programming?

Hell yes! I’m having the time of my life, and I get paid for it.

If there is one thing you learned along the way that you would tell new developers, what would it be?

This is more generic life advice, but something I feel strongly about: Surround yourself with people that are smarter and more talented than you, and learn from them. See what they do, figure out why they do it. Ask questions. Bask in their greatness and absorb everything.

At Visix, I spent a big chunk of time hours and three whiteboards going through the Galaxy “Class Manager”, figuring out how it worked (which was a combination of C++-style vtables and Objective-C runtime lookup, but all in vanilla C, with a lot of macro magic).

What’s the most fun you’ve ever had programming?

At Visix, in the bootstrap days of Galaxy. I wrote a lot of demo programs and sample code, in addition to doing the “List Manager” (think Excel, but without the calculation engine). There were a lot of times I’d be working all night on some fun thing (like a graphics demo that needed scrolling, but we didn’t have scroll bars implemented yet, so I wrote a little joystick thingie). My favorite times were hacking on something fun, looking out the window, and watching the sun rise. It was magical.

Thanks AnneKate, that was a fun stroll down memory lane. Now get off my lawn.

Next CoocaHeads/Pittsburgh is Thursday July 3, 2008, 7:30 at Newell Simon Hall 3001 on the CMU campus. No set agenda, but we’ll have the usual snacks and geeky discourse.

P.S. I’m on twitter as “borkware”, still working on revisions to AMOSXP, plus doing some work on LoC.