Truer Words - A Journal

An Entirely Other Day - Wide vs. Deep

seth@macrobyte.net — Wed, 21 Nov 2007 22:31:25 GMT

So here’s my theory: Managers must work shallow and wide, while programmers must work narrow and deep. People who are naturally tuned to one particular method of work will not only enjoy their jobs a lot more, but be better at them. I’m a deep guy, I should be doing deep work.

This article and his theory remind me of something (er, someone) which seems to be completely unrelated: Michael Jordan. When he retired from the Bulls for the first time (shortly after his Dad died) to see if he could play Major League Baseball, he found it very difficult to hit those legendary pitches.

What's the connection? The pitching coach (of either the White Sox or the AA team where he played... the Barons?) said his problem was one of focus. When you play basketball, you have to be aware of everything going on around you all the time. Peripheral vision is key. When you're trying to hit a 90-mile-per-hour baseball, you need absolute tunnel vision, total focus on that one task.

That's the difference between managing and programming.

Like the author of "Wide vs. Deep," I've done both and I prefer programming. (Managing my crew at Macrobyte during its heyday was fine, but I'm referring to my time at RR Donnelley in the mid-90's.)

(Thanks to DF for the original link.)

Faster Code (Converting HTML to Text)

seth@macrobyte.net — Mon, 12 Nov 2007 15:01:17 GMT

Over the years I've written this code in a few different languages: take some HTML input, process it according to some of the basic rules a browser would use, and spit out plain text (no tags or HTML entities). By "basic rules a browser would use," I mean that e.g. a series of <p> tags should not result in a long blank gap, but a series of <br /> tags should. Line breaks (\r or \n) don't matter except within a pre-formatted section. Etc., etc.

My first attempt, I think, was in straight UserTalk. Then i rewrote it a couple of times with regular expressions (still UserTalk) to make it faster. Then a client needed it in a language that could be used on any Mac OS X box, so I rewrote it in Perl, which was faster still (and was much better about converting the HTML entities to UniCode).

The Perl script uses lots of regular expressions, and so makes many passes over the input, changing the text in place. It worked well enough for most HTML, but long documents with a very high ratio of tags-to-text (that is, very tag heavy) would process very slowly. Unfortunately the script was run automatically in the background by a "regular" GUI application, and so the app would seem to freeze up for a little while as it processed one of these pathological cases.

Over the last week I rewrote it again, this time in pure C++. It's a command line tool with the same basic interface that the Perl script had: you can pass it an argument to specify the input file and output files. Omitting either one causes it to use standard input and/or output.

The new tool makes a single pass through the text, doesn't use any regular expressions, and generates slightly better output. Actually, it's more honest to say that it makes three passes through the text: first it converts UTF-8 to UTF-16 (but that's an OS API service), then it processes the UTF-16, then it converts back to UTF-8 (again, just done by the OS) for output.

The timing results speak for themselves. These tests use the worst, most pathological example we had. It's a 200 KB file that's about 90% tags (specifically, it's a long email exchange where everybody top-posted and quoted everything else, and everyone used HTML messages.)

$ time striphtmltags.pl - < ./striphtmltags.input.html > ./striphtmltags.output.txt # old one
 
real    0m20.201s
user    0m19.774s
sys     0m0.352s
 
$ time newstriphtml < ./striphtmltags.input.html > ./striphtmltags.output.txt # new one
 
real    0m0.048s
user    0m0.039s
sys     0m0.010s

They wanted it faster. For this worst-case scenario, it's 420 times faster. Zoom.

My First Core Image Filter (for Acorn)

seth@macrobyte.net — Fri, 28 Sep 2007 03:32:42 GMT

While playing with Acorn, I was trying to figure out how to make a scan of some black and white line art appear as black-and-transparent, so it would look as though it was "drawn" directly onto whatever background over which it was placed.

Not *quite* as easy as it sounds, for a couple of reasons. The biggest problem is that you can't just give all white pixels an opacity of 0% (or 100% transparency). Black and white line art "scans" are not just black and white, even after you clean them up: the edges of the black have a sort of anti-aliasing: light gray pixels that help to smooth out the image. The second problem is that Acorn doesn't support channel-based editing. You can change opacity and color all you want to, but you can't just view and edit the image's alpha channel.

I asked Gus if he thought I should do an Acorn plugin (and described what I was trying to accomplish). See, years ago I wrote a little plugin for a little company called Adobe, for their little app called Photoshop (v.4, I think). The money was good, and we still have the B&W G3 and 17" display that they sent me along with the check. Anyway, I figured if I could write a Photoshop plugin for Adobe, I could write an Acorn plugin for my own use, right? Right!?

Gus said I would be better served writing a Core Image Filter. It's like a filter/plugin, but it's for the OS instead of a specific app.

I didn't make time to work on it until today. It took a couple of hours to find the right documentation and actually write the filter. Gus had sent me the heart of the filter in the form of a single, very short function that just manipulated the alpha value of a pixel based on the channel's combined r/g/b values.

Apple's docs for this stuff are surprisingly bad. I found one tutorial that helped a bit, and then in the end I just had to try a few things to make it work.

Three Images, Three Backgrounds

Plain black and white image, no transparency.

White converted to 100% transparency. The 'halo' comes from the light gray pixels that smooth out the black lines when the image is over a white background.

Image after applying the 'White to Alpha' filter in Acorn.

Plain black and white image, no transparency.

White converted to 100% transparency. The 'halo' comes from the light gray pixels that smooth out the black lines when the image is over a white background.

Image after applying the 'White to Alpha' filter in Acorn.

Plain black and white image, no transparency.

White converted to 100% transparency. The 'halo' comes from the light gray pixels that smooth out the black lines when the image is over a white background.

Image after applying the 'White to Alpha' filter in Acorn.

So what does it do, exactly? Well, the idea was to display black-and-white line art so that it would look "good" on any background (not just white). In Photoshop, the easiest way to do this is to copy the artwork to the alpha channel, invert the channel (100% -> 0%, 0% -> 100%, 25% -> 75%, etc.), go back to the main image (either the RGB channels or the Gray channel) and bring the brightness way down and the contrast way up so that any pixels which were anything other than pure white are now pure black.

(Why? Because their "gray" levels will now be opacity levels, so they will blend against any background. What was light gray is now solid black but mostly transparent.)

That's how I'd do it in Photoshop. Now I can do it in Acorn with a single click. :-D

If you want it, feel free to download a copy of the filter. Copy it to /Libryar/Graphics/Image Units/ or ~/Library/Graphics/Image Units/. I've used it in Acorn, Core Image Fun House, and Quartz Composer… so I can assure you that it works on my machine. ;-)

Update: If you install it, you'll find it in Acorn under the Filters->Stylize menu. Maybe not the best place for it, but I'm not sure where it should be.

PMC Software Auction 8: Web Developer's Paradise

seth@macrobyte.net — Tue, 28 Aug 2007 18:40:46 GMT

The eighth auction is running, and is called “Mac Software Bundle: Web Developer's Paradise.”

This is the most ‘focused’ auction to date. These are tools for web (site or app) developers, and include high-end apps like BBEdit for source editing, Coda and Sandvox for designing, SQLGrinder for databases, Interarchy for FTP, and Screen Mimic for screencasts. (I do this work for a living, and seriously wish I had all of these apps!) Also included Daylite and Billings, to help on the business side of being a web developer.

Yeah, ok, that last sentence sounded like a lame attempt at marketing, but it wasn't. I'm serious. I don't have Coda, Sandvox, SQLGrinder, or Screen Mimic, and could certainly use them. (So maybe it's not a good idea for me to sell a sweet bundle like this to my competition!)

Two last details: there's no reserve this time, and it's a seven day auction instead of five.

GarageSale and the PMC Software Auctions

seth@macrobyte.net — Sun, 19 Aug 2007 02:25:30 GMT

I'm taking a minute to post a big "Thank You" to the folks at iwascoding, the makers of GarageSale.

They didn't "just" donate five licenses of GarageSale to the auction. They also gave me a license of my own to use for the auctions, AND... no, wait, this deserves it's own paragraph.

AND... they added a feature to GarageSale specifically because I needed it!

Here's the deal: if you're doing charity auctions on eBay, you need to have an account with MissionFish, who guarantees that the charity receives the money. When you create the auction, you need to provide your Mission Fish info, choose your charity (out of a list of thousands), and specify what percentage of the final sale will go to the charity.

It's a serious pain in the neck, just like everything else related to setting up an auction on eBay (IMO).

With GarageSale, though, it's easy. They remember my MissionFish account in the prefs. They remember my choice of charities. I can create new auctions almost instantly, based on previous auction templates. Plus, the software has this practically endless list of aucton styles!

This project will always be a huge amount of work, but I'm whittling away at the process and it's growing easier all the time. GarageSale and it's charity-friendliness is my number-one biggest time saver, though. (Next year, my Rails app for managing all the data for this project will be the number one time-saver. I'm already using it this year, and it's saving me time, but I also wrote it this year so the real savings won't start until next year.)

Um... "P.S." Last time I did this, I got free copies of Knox, VoodooPad, FlySketch and FlyGesture, but I forgot to thank Marko and Gus. Thanks guys!

Working On Tools

seth@macrobyte.net — Tue, 31 Jul 2007 22:17:03 GMT

Immediately after "retiring" from the Prototype Core Team, I became active (for the first time!) on the group and finally did what I was there to do in the first place. The next version of Prototype (1.6) will have custom events. The custom events code in 1.6 doesn't look much like the code I described in my essay a year ago, but it's built on the same idea: piggyback custom events on one of the browser's built-in events. (The custom events code in 1.6 was written by a number of people, not just me.)

Anyway, the real point here is that I use Prototype for nearly all of my web projects now, and I contribute to its development. That's working on my own tools.

Plus, immediately after finishing my side of Prototype's new events code, I realized that the next version of Prototype didn't look quite right in BBEdit's function popup. (Some objects were listed as [anonymous] when they should have had names, and some class methods were listed as though they weren't contained by anything.)

So, I updated BBEdit's JavaScript module to fix that problem.

I'm rather proud of the JavaScript support in BBEdit, but (again) the real point here is that I love being able to work on my own tools! (See the BBEdit Disclaimer...)

The same is true for Conversant, which currently runs on Frontier, and which runs my site (and lots of others).

Being a tool-builder makes me feel like a real craftsman.

Apple, On Custom JavaScript Events

seth@macrobyte.net — Wed, 04 Jul 2007 17:45:40 GMT

This morning when I checked my Gmail account, I read a message (from someone named "Filippelli Christophe") that said Apple seemed to be using my Custom JavaScript Events code on the iPhone page. (In case anyone misunderstands: this is a very good thing in my opinion.)

"Yeah right," I thought.

But it's true, at least at the moment. You can see it for yourself:

Go to the iPhone home page
View the source.
About 20 lines down (in the source) there's an indented bundle of <script> tags, the first of which points to “/global/scripts/lib/event_mixins.js”. Copy that path, and load it up in your browser.
See? Third line down says, “(c) 2006 Seth Dillingham …”. How cool is that?

Boring Mac Programmer Stuff

The irony is that my custom events code is based on Apple's own work.

Huh?

Well, in the early 90's, Apple pushed the Mac application developers to make their applications scriptable and recordable.

Scriptable meant you could automate (control) the application with AppleScript scripts.
Recordable meant you could tell your script editor to start recording, then do something in the application and your actions would be translated to a re-usable applescript in the script editor.

The way it worked was that a button click or menu selection (to name just two examples) in the application would cause the application to send an AppleEvent (the tech on which AppleScript was built) to itself. So it was like you had two applications in one: the one the user interacts with, and the "engine room" where all the real work was done, and the UI communicated with the engine room by sending AppleEvents.

Many well-written applications already “decoupled” the UI from the rest of the code anyway. If the application was also going to be scriptable, then also making it recordable (with the above approach) was at least a realistic consideration (though it was still a lot of work.)

My "Custom Events for JavaScript" article uses the word ‘decoupling’ in the title for exactly that reason: the intent is to allow you to decouple the UI of a web application from the data processing you do in JavaScript, and/or on the server side. It's not identical to Apple's recordability model, but it's inspired by it.

Blah blah blah... most people don't care about that stuff, I know.

Anyway, I told Rich about this and he said Apple owes me an iPhone. Hah.

“Dear Apple: my friend Rich Siegel — you've heard of him, right? — says you owe me an iPhone. Love, Seth”

(Of course, they don't actually owe me anything. I did release the code for free, after all...)

Rich had a funny response to the above (in the form of a faux letter back from Apple), but I'll leave it to him to post (or not). ;-)

I told Flip about it, too (hey, I was excited!), and he said he's going to tell his friends that he knows someone who made the iPhone possible. Hear that popping sound? That was my ego. ;-)

Update: forgot to mention that the custom events stuff is what landed me on the Prototype Core team in the first place... and they (the rest of the team) expect me to roll some form of the custom events code into Prototype itself. Have to do it soon, or Sam is going to send me a Howler...

Creating Custom Events with, uh... me?

seth@macrobyte.net — Wed, 28 Feb 2007 15:08:05 GMT

Last year I was working on a Conversant-based RSS aggregator. It was very AJAXy, with a responsive UI which acted as much like a traditional desktop aggregator as I could manage in the limited time I had to work on this project.

In the process, I created the Custom Events mix-in (extension) classes for Prototype. Then, a little later, I attended RubyConf '06 and met Sam, who was impressed enough with my work that he asked me to join the Prototype Core team a few months later when it was formed. (Which is something I've neglected to mention here.)

Those custom events classes have received some attention... except from me. My write-up that described my approach is one of the most-frequently-hit pages on the site, and a number of people have linked to it (including A List Apart, which generated a lot of traffic).

Most of the links, though, were in passing. Comments like, "this looks interesting," or, "here's an alternative approach to doing custom events," etc., etc., etc. That was fine... I'd heard from people who I know are using it, and some have even reported bugs (which I've fixed) that they ran into while implementing custom events in their own projects.

Yesterday, Daniel wrote “Creating Custom Events with Seth”, wherein he documented not only the struggles that led his team to using Custom Events in the first place, but also the benefits they've seen as a result.

So toggling is screaming to be refactored since the wiring is painful to behold. It’s far too interwingled with the other stuff on the page and we know it. I had looked at Seth’s work a while back, and shoved it into my back pocket… and today it worked out perfectly. We did a little spike, got the basic code working, and then applied our new found knowledge to the problem. Now we have excellent separation of concerns. The toggle dispatches a custom event, and various things listen for it via a broker. Nice. Any other widgets or tools can tie in just as easily. Since we were already using Prototype.js and our own classes, it took only about 15 minutes to mixin the Event classes and set up a broker. Most excellent Seth!

Very cool, Daniel, I'm really glad this worked out for you.

He also mentioned a documentation bug, which doesn't surprise me at all. I should really rewrite and reconfigure that page into a small collection of more approachable pages, and review it all for accuracy. Just one more thing for the to-do list.

Writing Hardware

seth@macrobyte.net — Tue, 13 Feb 2007 20:42:49 GMT

Reading Planet Mozilla this afternoon, as I do every day, I saw this in Brendan Eich's article, Threads Suck:

Threads violate abstractions six ways to Sunday. Mainly by creating race conditions, deadlock hazards, and pessimistic locking overhead. And still they don't scale up to handle the megacore teraflop future.

We can hope for better static analyses to find all races. In the real world, the code is C or C++ and there's no hope for static salvation. Sure, some languages try to put deadlocks in a syntactic cage, but that walks right into the overhead problem, in spite of heroic VM-based optimizations. Unexpected costs, even if constant or linear, can sink any abstraction. For example (still piquant to Mozilla hackers busy deCOMtaminating), virtual method calls cost; they should be avoided where you're writing hardware. The same goes for locks: not all abstractions must be MT-safe; some must be ST and fast.

So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"

I'm all in favor of not having threads in JavaScript. We already have pretend threads... we certainly don't need preemptive multitasking in our web scripting. KISS, you know?

Anyway, my real reason for posting this? I just wanted to point out that I knew where that "writing hardware" link was going to point even before I checked it.

That Steve Yegge, man. Quite the writer.

Chat with Brian Regarding Lexers and Parser Generators

seth@macrobyte.net — Fri, 02 Feb 2007 18:10:30 GMT

(I'm sure with that subject, everybody's just dying to read this one...)

I had a (third) chat with Brian Andresen today about Lexers and Parser Generators, a type of software that's working overtime to suck worse than most email clients.

Brian Andresen 11:06:49

remember we were looking for Unicode-savvy parsing tools a while back?

Seth Dillingham 11:06:59

I do

Brian Andresen 11:07:04

I'm looking for new parser-generator tools for my project at work

came across this: http://www.devincook.com/goldparser/about/why-use-gold.htm

Seth Dillingham 11:09:23

oh man, very interesting

Brian Andresen 11:09:51

I suspect that the author is more mindful of capability than performance

still, I plan to download it and try a small grammar with GOLD

I'll also try out ANTLR (again) and ACCENT (http://accent.compilertools.net/)

(why do all of these tools use all-caps names? dunno.)

Seth Dillingham 11:11:18

ANTLR is an acronym, I don't know about the rest

not that it matters much

Brian Andresen 11:11:40

yeah

Seth Dillingham 11:12:00

I know ANTLR made some more progress, but I haven't played with it.

heh. Check out the first News Item on the ANTLR home page

Brian Andresen 11:12:59

bah, GOLD is Win32-only.

Seth Dillingham 11:13:07

Grr.

This whole class of software is a joke.

Brian Andresen 11:13:24

2009?! we're going to have to wait a long time for that next beta.

Seth Dillingham 11:14:09

But the news is in past tense! I think they're probably just thousands of timezones ahead of us. That would explain it.

Brian Andresen 11:14:17

heh

yeah, there's not much out there that's free. I've found a bunch of commercial tools, but none of them have even inspired me to request a trial version

Seth Dillingham 11:24:57

again, I see that ANTLR's C++ target is dormant. http://www.antlr.org:8080/pipermail/antlr-interest/2007-January/019001.html

Brian Andresen 11:25:11

that's very relevant, thank you

Seth Dillingham 11:25:32

Looking at this stuff never makes me happy. :-(

Brian Andresen 11:25:40

no kiddin'

well, that just left me with a grand total of zero tools to investigate. lame.

Seth Dillingham 11:26:18

I think, "I could devote a ton of my time to learning the issues and helping to fix these problems. Or I could make a living and have a life, and make do with what I already have."

Brian Andresen 11:26:31

yep

Seth Dillingham 11:26:58

But it still makes me nuts. My work could really benefit from a good, Unicode-savvy parser generator.

with a C++ target

Brian Andresen 11:28:01

yeah. the thing that got me started on this (for Agilent) was how poorly designed lex/yacc (and flex/bison) are for providing code to be part of a larger project

they were designed for making a standalone executable that doesn't need to do much more beyond the parsing, it seems

Seth Dillingham 11:28:56

they're specifically for feeding a compiler, right?

Brian Andresen 11:29:22

our simulator already has six lex/yacc-based parsers in the code, and we end up having to mangle the yy___ symbols and other globals to even just make it link

Seth Dillingham 11:29:57

(a particular kind of compiler/builder, I mean)

Brian Andresen 11:30:06

yeah

Seth Dillingham 11:30:17

Hey, do you mind if I post this conversation on [tw]? I'll hide your handle.

Brian Andresen 11:31:36

oh right, and my other gripe was memory management. Suppose we're parsing through a line and allocating memory for various things as we go. Then we hit a syntax error. There are ways to design the rules to do error recovery, but designing the rules to allow error recovery to clean up all allocated memory is not obvious at all.

go for it

Seth Dillingham 11:32:48

thanks

Steve Yegge on Living Software, Reminds me of Something...

seth@macrobyte.net — Thu, 25 Jan 2007 19:05:33 GMT

Steve Yegge has written another fantastic rant, this time about designing for living software.

He starts out by reiterating something I've said before: all software is crap. (I usually say it all sucks, and then follow it up with a comment about all email software sucking infinitely.) He goes on to talk about the traits that make some software suck the least.

I got a small thrill as I read it, and I think some of my friends will, also, if they take the time to read it (specifically, those friends who spent time working on Conversant, or a lot of time using it).

We did the UI all wrong (something which I hope to remedy), but this article has reminded me that the design principles we followed in building Conversant's core — and many of its plugins — were pretty good.

Moving right along, world-class software systems always have an extension language and a plug-in system — a way for programmers to extend the base functionality of the application. Sometimes plugins are called "mods". It's a way for your users to grow the system in ways the designer didn't anticipate.

…

The very best plug-in systems are powerful enough to build the entire application in its own plug-in system. This has been the core philosophy behind both Emacs and Eclipse. There's a minimal bootstrap layer, which as we will see functions as the system's hardware, and the rest of the system, to the greatest extent possible (as dictated by performance, usually), is written in the extension language.

Certainly, there are aspects of Conversant's core we should have done better, or at lesat should have re-done by now. Also, there are a couple of things on his checklist which we barely even considered. Still... go read his rant, and see if it doesn't sound familiar to you.

Inline-Block, Coming Soon to a Firefox Near You

seth@macrobyte.net — Wed, 13 Dec 2006 17:21:47 GMT

I'm surprised and happy to see that dbaron (one of the most experienced and "lowest level" (as in plumbing, not importance) Mozilla contributors) is finally working on an implementation of CSS 'display: inline-block'. I've been subscribed to the Bugzilla bug for inline-block for years and years, so I was amazed to see it finally get some official attention a couple days ago.

Apparently he's also implementing inline-table.

What Is In that Bread Pudding, Anyway!?

seth@macrobyte.net — Thu, 16 Nov 2006 17:08:26 GMT

By now most everybody knows that Macrobyte is doing some work for Bare Bones on BBEdit. I've also become friends with Rich Siegel, the president at BB.

How did this come about? Rich tells the story in short form, and along the way heaps praise on me, Corinne for her cooking, and even does appropriate obeisance before the telekinetic bread pudding.

Rich is awesome to work with, has proven himself a true friend on at lest one occasion already, and (frankly) I'm benefitting massively from his years of experience in this field. All this praise from him could go to my head, though, if I didn't know it was really the bread pudding influencing his thoughts. ;-)

My favorite line:

… she obviously enjoys cooking: big family events, small catering jobs, to say nothing of keeping Seth appropriately fed and watered. Which brings us to the sentient bread pudding …

TextMate’s Undo, and the New Editor Wars

seth@macrobyte.net — Fri, 10 Nov 2006 17:18:05 GMT

Erik Barzeski on TextMate’s Undo

Recently I conducted another of these experiments. I got so far as trying to modify one of the files in the theme I use on this site. I typed a line or two, uploaded the changes, and realized I'd edited the wrong file. I hit cmd-Z to undo and… yeah. TextMate users know what I found. Undo only "undoes" one character at a time.

I love it. Why do I love it? Check out this snippet from a chat I had with Greg back in July:

Seth:

You had seven items. BBEdit can already do 6.5 of them, almost exactly the same way that TM does it. BBEdit's problem is that they don't present their features very well.

Greg:

y.

Seth:

Actually, 5.5 of them. Their prefs are certainly more complex than TM's. They can reduce them, but they can't eliminate them.

Greg:

i'm not surprised

Seth:

I can't stand TM's undo feature, though. Undoing one character at a time is nuts.

Seth:

At least you can hold it down for fast repeat.

All that just to point out that I've felt exactly the same way for a long time.

There's way more to this story, though. Erik's post touched off another battle in the editor wars, which have raged for decades. Unfortunately for Erik, it doesn't seem that he knew people would get so fired up about it. (See the comments on Erik's page.)

Allan, TextMate's creator, responded there on the site. As did a zillion other people. Back and forth, back and forth. Someone named MJD said:

Something that really turns me off TextMate is the way Allan Odgaard is constantly attacks BBEdit, Barebones, and Rich Siegel. There is no need for it. Especially the attacks on Rich. Try standing on the merits of your own program rather than belittling another.

Allan and his friend Jacob Rus both denied that Allan has attacked BBEdit, Bare Bones, or Rich.

Has anybody read Allan's weblog's version of an acceptance speech for his Apple Design Award? You could say this is his definitive link, it's where he tells the story of winning the award — an award which is a huge honor for any mac developer. In it, he points to a picture of himself that also happens to include a man getting sick, and he says, "no, the guy getting sick is not Mr. Siegel."

I know of plenty of other little bashes on BBEdit, Bare Bones, and Rich. Some published, some not, but that comment in his weblog post is probably the most telling. It looks to this outsider like Allan wants TextMate to succeed almost as much as he wants BBEdit to fail and Rich to be hurt somehow.

Allan: the mac platform is doing well, but the developer community is still pretty small. You have to assume that if you say something, it's going to be quoted and re-quoted. Is your business plan really based around mocking Rich, claiming that Bare Bones is just a sales-oriented company that contracts out all the hard work, and poking fun at other independent developers?

OK, I'm tired of this battle already. It's time for this code monkey to climb back into his tree and finish the next language module.

(Note: please see the BBEdit Disclaimer.)

Programmers (and Their Bosses) Should Take Note

seth@macrobyte.net — Tue, 03 Oct 2006 19:45:43 GMT

Every programmer ("software developer") with whom I've discussed Steve Yegge's recent article, Good Agile, Bad Agile, has had a similar comment: "I think I'd like to work there."

Further discussion usually reveals that the person (myself included) might not want to actually work at Google, but most definitely wants to work in an environment like Steve describes.

Steve describes what I love about being self-employed. Most of the time, I'm working on software that I care about, and when business is going well I'm able to work at my own pace. (When I'm really interested in or enthused about the project or product I'm developing, "my own pace" could mean "almost non-stop for days on end" or something a little healthier.) I even have those food-related perks that Steve mentions!

Attitudes about software development, such as Steve ascribes to Google, could transform our industry if enough of us read and retell stories like Steve's and decide that we won't settle for (much) less.

To be clear: I don't mean "transform our industry" in the sense of giving us all cushy jobs where we can eat all we want and be spoiled rotten. That's simply a means to the real end, the real transformation. The real transformation is that the quality of the software will improve because more of us will be creating something we care about, and releasing it when it's done rather than simply when it's usable.

An Example from My Own Recent Experience

Bare Bones recently allowed me (as a contractor) to work on an important feature until it was done. I smile every time I think about that, even though I finished it over a week ago! Yes, there were some scheduling constraints (Meaning I couldn't keep working on it forever. Obviously.), but they wanted something of high enough quality that we could all say, "It's done." (We've since had ideas for some new features that could be added in future revisions, but that's a train that just never stops rolling...) When's the last time you wrote software for someone else (employer or client), and didn't have to release it until you felt it was DONE? It feels good, let me tell you.

Google's definitely on to something, and I hope it catches on.

Loopy Humor

seth@macrobyte.net — Mon, 18 Sep 2006 19:16:06 GMT

Bare Bones has been persuaded to dip their toes in the water of public beta releases. That means one of my hands, previously bound behind my back, has been freed up to let me write about what's in the public betas.

I won't bore you with much technobabble, but I felt this clipping from the release notes was funny:

    -   Fixed the infinite loop in the YAML module caused by some uses
        of the vertical pipe '|' (because Macs only need 1 Infinite
        Loop)

Note: YAML is a markup language based almost entirely on indentation. That has nothing to do with the reason for reprinting the above note, though.

If you don't get it, methinks you may not be a mac user (or have absolutely no idea what an infinite loop is)..

Somebody felt funny that day...

Postscript: yes, I confess, it was me.

BBEdit 8.5 (short version)

seth@macrobyte.net — Thu, 07 Sep 2006 20:43:15 GMT

Today Bare Bones announced the release of BBEdit 8.5, my favorite Mac text editor.

I'm quite psyched about this release for two reasons: it has loads of new features (many that I've been hoping for, in fact), and because I played a small part in its production.

See, this is the project I worked on non-stop for two months. My contributions are minor compared to those from within the walls of Bare Bones itself, but it was still two months of my time. And more than that, I really (really, really) enjoyed this project, so much that I feel a sense of ownership and real contribution. Last night I joked with Rich that I've made myself a Bare Bones employee, but it would have been better to say "Bare Bones Fellow". ;-) (No, Macrobyte's not going anywhere, anytime soon.)

Of course, what are bound to be the most generally popular new features (most notably Code Folding) had nothing to do with me. I wish I could take credit for that one. ;-)

Like Michael and many others have already done, I plan to go into a lot more detail about this new release, and I'll even (finally!) be able to talk about what I did. Unfortunately it's going to have to wait until tomorrow. Just couldn't let the whole day go by without saying *something* about it.

Congratulations to everybody at Bare Bones, especially Rich. 8.5 is a fantastic update!

Oh, and yes... Bare Bones president Rich Siegel is who I went with to the MacTechGroup meeting, yesterday.

Jim C. from Bare [space] Bones has reminded me for the second time in three years that there is a space in their company name, and that they "paid good money for that space." Oops. Fixed!

New API Docs for Custom JavaScript Events

seth@macrobyte.net — Wed, 06 Sep 2006 19:31:59 GMT

With some major new interest (more about that later) in the Custom JavaScript Events stuff I wrote a couple months ago, I've been prompted to write some simple API docs for my Custom Events code (which is an addition to Prototype.js). (What, you don't have time to read 3500 words on why you should be using custom events in your JavaScript apps to save your own time? Come on! ;-)

YAML Made Me Feel Stupid

seth@macrobyte.net — Tue, 15 Aug 2006 17:17:35 GMT

It has taken me three full days to figure out how to write a scanner/almost-parser for this totally generic, relatively-simple data serialization language, in C++. Most of that time was spent trying to decipher the darn documentation.

Spec authors need to get a clue. Specificity is not the only — nor always the best — route to clarity. And examples with little or no context requires too much thinking, and it's that much harder to be sure you're right.

Every time I thought I had it figured out, another special case would crop up that broke my mental model.

This morning, right before lunch, I grabbed a piece of paper and furiously scribbled down the steps for doing it right. There are still special cases, but they're called out in the docs so they're not my fault!

It took me about the same amount of time to (figure out how to) write a scanner for one of my favorite scripting languages, which is much more complicated than this mini-language. Like I said, I'm feeling stupid.

The Wizard Schools

seth@macrobyte.net — Sat, 01 Jul 2006 18:37:18 GMT

Oh my word.

How much of this can you read before you start laughing?

[SPOILER AHEAD]

I've lost my voice due to some sort of head cold or sinus infection, so I sound ridiculous... but Stevey's latest blog rant is so hilarious it had me choking and laughing out loud, over and over again.

One wonders how long it takes the average reader to realize it's not entirely serious. ;-)

The best part is its recursiveness. Man, what a writer. Stevey is cool.

Creating Custom Events with JavaScript: Decoupling

seth@macrobyte.net — Fri, 30 Jun 2006 20:50:36 GMT

Many "Web 2.0" applications suffer from too-tight-coupling between the various javascript objects used to model the data and control the interface. This has always been seen as a necessary evil because there seemed to be no good alternative.

One common solution in desktop applications is called "event driven programming." Not just user-supplied events like mouse clicks, hovers, and window scrolls (obviously, we do all of that in our javascript apps already), but actual data-driven or state-driven events such as "message selected" or "preference changed".

Truly custom events, when used correctly, allow you to decouple many of the JS objects in your application. This leads to better self-containment and much better maintainability.

It has generally been considered impossible — or at least too difficult — to create truly custom events in our applications. There is a W3C spec for custom events, but it's not supported by most of the browsers so is really of no use to us.

Read the full essay and together we'll examine the problem a little more closely, and consider my solution. (There may be others, but all I found was attempt after attempt to duplicate the features already provided by the browser.)

RailsConf 2006: Highs and Lows

seth@macrobyte.net — Tue, 27 Jun 2006 16:49:31 GMT

RailsConf (the first 'official' Ruby on Rails conference) ended Sunday afternoon. I'm very glad I went.

Highlights:

Having Corinne there with me, for a lot of reasons.
Meeting Greg and hanging out like old friends, making plans for future work, and getting help with problems in one of my projects (he has more Rails experience than I do).
Watching one of my clients (M.C.) scurry around with a big backpack, and talk to anybody who would listen about his project. The man really seems to love his work.
The jets taking off right over the hotel, and the huge trains rumbling by on the tracks across the street.
Dave Thomas's keynote on Friday morning, throwing down the gauntlet.
All the keynote speakers bluntly disagreeing with all of the others, without hostility.
DHH's keynote on Saturday night
The Homesteader's Guide, by Nethaniel Talbott
The code-related sections of the "performance" by "Why the Lucky Stiff"
Meeting with Sam Stephenson, author of Prototype, for an hour on Sunday, and being told that he loved what I showed him. It seems I really did figure out something NEW in JavaScript, and wasn't actually deluding myself. (Note: JS-related validation from Sam is a bit like Ruby-related validation from DHH. That is, he didn't write the language, but he is considered one of the elite and there are many, many thousands of people following his lead.)

(Yes, I'll have a LOT more to say about this soon.)
An email I received from a brand new client. I had to work for this one, but in this case that's a very good thing. I can't wait to say more about this!
The macs. It was totally nuts. 550 attendees, and I've seen estimates between 80% and 95% mac coverage. Some joked that "in the future, everyone uses macs." I parried that this wasn't the future, it was the alternate universe where things had worked out like we always knew they were supposed to.

Check out some of the pictures. I'm even in one of them, from the neck down. ;-)
Giving the (other) last remaining mac geeks (about twelve of them) in the bar just off the hotel lobby a whole pizza (our leftovers after we ordered two smalls). They couldn't believe their good fortune! I told them they could have it if they promised not to get any on their MacBooks. They looked at me funny, one guy said that his runs better with pizza. I said, "you don't need to put it on the macbook, the pizza is already cooked." Took them all a second to figure that one out. :-)

Now the lowlights:

My babe being bored out of her mind. The conference kept us so busy that there was no time for us to do much of anything, and who wants to play tourist by oneself? (Not her!) Lesson learned. For future conferences, we'll be able to make a more informed decision about whether or not she goes with me.
Some of the sessions were desperately boring and lacking in any useful technical information. Some were good, many were not.
All the rest of Why's performance. Some people totally loved it. I'm not one of them.
Paul Graham's keynote presentation. He has this awesome rep, and I truly enjoy most of his essays, but all he did was read it! Dude. Look at your audience more often than when you're making a joke. (It was funny, though, that he kept saying, “I’m going to leave THAT part ouf of the essay on the site.”)
That it ended so soon. Sigh.

Back to work!

New Fixture: The Next Best Thing

seth@macrobyte.net — Sun, 18 Jun 2006 02:33:10 GMT

Some of you may remember that I started a new section on the site, last year, called Fixtures. I added one cycling-related fixture and then never bothered with it again.

A new fixture has finally bounced it's way out of my head, and has been, well, affixed on the site. This one is called The Next Best Thing, and is related to technology.

Xcode 2.3 is Ready

seth@macrobyte.net — Wed, 24 May 2006 15:22:58 GMT

Apple has released Xcode 2.3.

You may even be able to get it now if you're patient. It's freakin' huge. 915 Megabytes. (Those darn universal binaries!)

Version 2.3 includes two major changes and a bunch of little changes. The big ones are DWARF support for debugging, and Distributed Network Builds for those who have dedicated build farms. DWARF looks very promising... DNB not so much for my needs.

Xcode 2.3 introduces support for the DWARF debugging format in GCC and the Xcode debugger. Because the DWARF format eliminates duplication of debugging symbols, Xcode builds using DWARF often take up significantly less space on disk and in memory while providing even greater debugging fidelity. For the users of Xcode, this will mean lowered system requirements to build large projects, as well as noticeable improvements in the debugging experience itself.

Pretty cool. They cite some performance improvements, too. I wonder how fast I'll be able to build Frontier/Conversant now. ;-)

An Old New Member Helping with the Frontier Kernel

seth@macrobyte.net — Wed, 10 May 2006 22:47:49 GMT

Doug Baron just announced his presence on the Frontier Kernel mailing list.

Andre just stepped in to help close the loop that Seth opened last week when he dropped me an email out of nowhere. I fished his [that is, Seth's --ed] message out of my Junk mail folder, and a flurry of email exchanges later I find myself here, introducing myself to the list. :)

Reading the names of recent senders makes me feel as though I'm already amongst friends: Henri Asseily, David Gewirtz, David Gewirtz, Scott Lawton, Seth Dillingham, Andre Radke, Matt Neuburg. Greetings to all of you. To those who don't know me, I was one of the lead developers of the Frontier kernel, but have not been involved with it since before it went open source.

My intention in joining this list is primarily to make myself available to developers who need help working with the kernel. Time permitting, I may contribute to the build. In any case, I look forward to re-connecting with Frontier and this community.

Don't know who Doug is? He's the person second-most responsible for the existence of Frontier, after Dave Winer. Doug programmed the kernel from 1990 through sometime in the early 2000's. (I did a search in the source code: his initials appear 4,314 times!)

He was a huge part of the community, and universally liked.

I find that I'm still quite attached to Frontier, in spite of my long term intention to the contrary. Having realized that, and that I was learning quite a bit about lower-level programming by working on the kernel, it was clear that what I really want is for the kernel to keep improving. For that, we need more volunteers, which would have to come from the pool of (old) Frontier users.

That happens to be a group of people I understand quite well. Among other things, it's a group that has a collective (if small) emotional scar over the perceived "loss" of Frontier and the amazing community that had built up around it in the 90's. Virtually everyone in the community has moved on... and bringing any of them back would be difficult.

Doug is likely to be a great resource for the current, small group of kernel developers, even if he never gets very involved in coding. (He'll be the "Oracle at Austin.") Anything beyond that — like actual coding time or drawing in more of the "old ranch hands" — is gravy.

Blah blah blah... my point is that I've accepted a personal mission with the Frontier kernel. I want to build up a bright new community like we had in the late-mid 90's, around a modern, ever-improving Frontier. Doug's joining the group is a big, important first step.