The server will shortly be going down (at roughly 10 AM EST, Tuesday 6 January 2009) for routine maintenance. Expected downtime should be approximately half an hour.
Update: The server is now back online. In the end, downtime was less than two minutes because the anticipated automatic file-system check didn't take place.
As a follow-up to the comments on Emacs that I posted earlier, I thought I'd check out how BBEdit is doing lately, seeing as a new version is out (9.1) and that latest I'd seen was 8.7.2.
Well, there's been big progress in a lot of areas.
Disk browsers and multi-file find results are now much more useful, and on a par with TextMate because you can finally edit files in-place rather than spawn editors in new windows. The interface is still clunky in some ways (the preferences, for example, are overly complicated, and the multifile find suffers from having an overly large initial dialog and a separate results window), but things like the addition of Projects really are a leap forward.
But there's one area in which BBEdit continues to suck, and badly: syntax coloring. Witness the following comparison between BBEdit, Emacs, and TextMate.
TextMate is a great editor, but there are two things which annoy me about it.
The first is really just a missing feature: the inability to split editor views. Having spent a lot of time in Xcode one becomes used to these split views. They are a fantastic way to increase your productivity by allowing you to simultaneously view headers and implementations, class files and tests, log or test output and code, and so on.
But they're not a deal-breaker. You can live without them. It's a bit more cumbersome, but you can still work by switching back and forth between tabs, or by actually creating and juggling separate windows when required.
The second issue, however, is more than a feature problem; depending on how generous you feel you'd either have to call it a fatal design flaw or a terrible bug. I'm referring, of course, to the memory-hogging behaviour of the "Find in project" functionality.
From comments by the author, my understanding is that TextMate implements this feature by reading the contents of all files in the project into memory... and leaving them there forever. The inevitable consequence of this is that TextMate really only performs well on toy projects; if you throw something heavy at it it will rapidly swell up in memory like one of those spikey, bloated fish that the OpenBSD guys use in their logos. Best case scenario is that you have to perform periodic relaunches to reset the memory footprint. Worst case scenario is that you'll suffer spinning beachballs, thrashing disks, and your machine will be reduced to an unusable crawl.
Seeing as I was living under a rock at the time I only heard about this one a few days ago, well over a week after it was announced. What a bombshell.
To sum it up in a nutshell, it's a "win win" situation. "Win win" because the Rails community has suddenly got onboard a motivated cadre of highly professional, elite developers. And "win win" because the Rails community is going to get some nice, free goodies like improved performance, better modularization, and possibly even a stable API to work with at last.
That last one, the API stablity, is the one which I'm having the most trouble believing is true. This is the one which is going to actually make the most difference to developers' quality of life. I'm pinching myself. Wake up, you're dreaming, I say. This is too good to be true. I've been living for too long with the pain of shifting-sands APIs and the mindless busywork of fixing code-churn-induced breakage at every point release.
But I digress.
You'll notice that there's one side in this deal which is getting most of the benefit in this "win win" situation. Rails wins, and, er, Rails wins too!
Rails has basically nothing to lose and everything to gain from this transaction. It's basically impossible for the code quality to get worse as a result of this deal; it can only get better and it seems likely that it will. For Merb, on the other hand, it's not so clear.
Somewhat of an "anti-milestone", just had another kernel panic, the 25th for this machine and the 50th involuntary reboot.
First we had a power cut and the which led to the interruption of the supposedly UPS, then another kernel panic.
Another kernel panic. If there's one thing that's reliable about this machine it's the clock-like precision with which it produces kernel panics, roughly every 20 days.
Hot on the heels of the server maintenance (an operating system update) earlier today we have an application-level update to the software that powers this website. Should only be down for a few minutes. Please report any anomalies you find using the issue tracker.
Update: We're back.
The website and other services will be going down shortly for maintenance. Downtime should hopefully be only a few minutes or less, while the server reboots and comes back online.
Update: The server is now back up and I'm performing checks to make sure everything is operating correctly.
Another kernel panic.
