Clean Hacking Stations

Posted on Published by Eugene Eric Kim

Fun Fact About Eugene #322: I’m obsessed with cooking shows. There’s nothing I like better on a Saturday morning than rolling out of bed, turning on PBS, and watching Jacques Pepin work his magic. What’s amazing about these chefs is that they always have a clean cooking station. Always. It’s apparently a principle they teach at cooking school, and it makes a lot of sense. It also seems to apply to other areas of life. Getting Things Done. Project Management. And of course, hacking.    (K95)

Ingy dot Net (The Hacker Formerly Known as Brian Ingerson) was in town this past week, and we hacked a little bit on Wednesday night. “Hacking” with Ingy for me so far has mostly consisted of me watching him in action, catching a typo here or there and occasionally pursuing some philosophical disagreement. But it’s cool, because I enjoy watching other folks code, especially folks who are better than me.    (K96)

(Earlier this month, while working on the Ruby YADIS library with Brian Ellin, I learned for the first time about command completion in Emacs using meta-backslash. Emacs has been my primary programming environment for about 15 years, and yet, I never knew about this. Very embarrassing.)    (K97)

One thing that surprised me about Ingy is that he doesn’t code very fast. On the other hand, one thing he does incredibly well is that he always has a “clean hacking station.” Even when he creates temporary directories or inserts debug statements in his code, he does it in a very clean way. It’s a practice I’d like to do a better job of emulating.    (K98)

The Thrill of Pair Programming

Posted on Published by Eugene Eric Kim

I have a lot of different passions, which is lucky in a lot of ways, and unlucky in others. It’s lucky because it makes life incredibly fun. It’s unlucky, because life is finite, and I don’t have time to delve as deeply into things as I would like. It’s why I knew I would never become a professional programmer.    (JZB)

This past year, I spent most of my time doing field work and thinking about social processes. When I switched into technical mode, it was as an architect or a pundit, not as a programmer. And that’s the way it should be. It’s the right mode for me professionally and personally. Besides, the less time in front of a computer, the better.    (JZC)

However, that’s changed these past few months, as I’ve had to wear my coding hat for a variety of reasons. And I have to admit, it still gets me going. My skills have degraded a lot over the years, more from disuse than age, but I can still get it done. It makes me feel like one of those clean-cut, Midwestern types who comes home from his nine-to-five job, then plays poker all night at some seedy underground club. It’s liberating.    (JZD)

In particular, I had fun Pair Programming with Peter Kaminski a few weeks ago and with Brian Ingerson last night. Both of those efforts were toy one-offs, but they were great fun nevertheless, and it got me thinking. Coding with others, and pairing in particular, is one of the most intense, enjoyable collaborative experiences one can have. Read Evan Henshaw-Plath‘s account of his recent Ruby On Rails sprint with Blaine Cook and Kellan Elliott-McCrea, and you’ll see what I mean. It’s the sort of thing I never get to do anymore.    (JZE)

I know a lot of great coders, and I love talking shop. And, I still want to spend as little time as possible in front of a computer. But, I’m going to make a concerted effort to pair with folks at least once every few months. If you’re in the Bay Area and are in the mood to code up something that is small, cool, and will improve collaboration some way, somehow, let me know.    (JZF)

Purple Numbers and WIKIWYG

Posted on Published by Eugene Eric Kim

For a while, it was looking like I was going to break another personal blogging record last month, then things got so busy I had zero time to blog whatsoever. That means I’m in catch up mode again, so as usual, I’ll post in reverse chronological order (which in the blogosphere is really reverse reverse chronological order).    (JYN)

Yesterday, I spent the afternoon at Socialtext, where they were having an all-hands meeting. They graciously invited me to participate in the Open Space segment of their gathering, which meant quality time with Chris Dent and a rare opportunity to evangelize the Church Of Purple together. Of course, Chris has been spreading the Purple religion at Socialtext for a while now, so it wasn’t as much about evangelism as it was about next steps.    (JYO)

As I’ve mentioned many times before, browser-based WYSIWYG editors are an exciting development because they allow us to make Purple Numbers transparent in the authoring process. Right now, when you edit a PurpleWiki page, you see the node ID tags (e.g. {nid 123}). This is impossible to get around with the default browser text-editing widget. However, with a WYSIWYG editor, you can hide the Purple Numbers while still maintaining their associations with a node behind the scenes.    (JYP)

That’s the theory, anyway. In particular, I’ve been excited about WIKIWYG ever since Ross Mayfield showed me an early prototype last August. I had a personal bias, since Chris Dent and Matt Liggett helped write it, as did Casey West and the inimitable Brian Ingerson, whom I finally met last weekend at Tag Camp.    (JYQ)

Yesterday afternoon, we discussed Purple Numbers and WIKIWYG, and it was good. Then in the evening, Ingy and I spent a few hours trying to get WIKIWYG integrated into PurpleWiki.    (JYR)

We didn’t quite make it. Our biggest roadblock was a bug we discovered in Mozilla’s design mode that we can’t do much about. (My days of statically typed languages are well behind me.) But, we got something somewhat working, and I learned a heckuvalot. You can play with our semi-working demo.    (JYS)

WIKIWYG seems well-architected and is easy to customize. For folks with relatively standard Wiki editing requirements, I highly encourage you to play with it. PurpleWiki has some special formatting funkiness (mainly due to the Purple Numbers), but we were able to get around this fairly easily. (This was also true thanks to PurpleWiki‘s model of parsing to an intermediate data structure, then using view drivers to serialize. I wish more Wiki engines did this. I know Magnus Manske is thinking about doing this for Mediawiki, and I think Janne Jalkanen is already doing it with JSPWiki.)    (JYT)

The Mozilla bug annoyed me, because it’s a show-stopper in some ways, and there’s not much I can do about it. I didn’t realize it, but all of the JavaScript WYSIWYG widgets actually switch to the browser’s “design mode” in order to handle WYSIWYG editing. As with many HTML editors, design mode does not handle structure cleanly, and you end up getting weird artifacts such as spurious break tags. Our problem was that we serialize node ID information as id attributes in the HTML tags. However, Firefox does not maintain those attributes correctly when you move content around.    (JYU)

I’ll report the bug (if folks have suggestions as to the best way to bring this to the right people’s attention, let me know), but it also puts the kibosh on my hopes for WIKIWYG and Purple Numbers. Even if the bug is fixed in the next version of Firefox, we’re still prey to all the folks using older versions as well as Internet Explorer or Safari, which have their own problems with design mode.    (JYV)

Chris and I discussed one workaround that I’m still pondering: render the Purple Number and have users be responsible for maintaining the association with the nodes. That’s the status quo, except users are doing it in WikiText rather than in WYSIWYG. Doing it in WYSIWYG certainly lowers the bar, and it’s probably the next best thing for us to do.    (JYW)