A summary of design patterns for GUI applications that is, at the very least, comprehensive. Again, none of them convince my gut.

Interesting blog that gives a peek about Google's deployment system. While some things are obviously not relevant to smaller companies, other ideas (such as finding 'hot zones' in code bases) are almost trivial to implement in any organisation.

Article that suggests Indian culture might be more open to open source philosophy than the west.

Summary: Android supports the same offline access tags as the iPhone

" ... Using XPCOM in JavaScript (also known as XPConnect) is an environment where memory management issues are not obvious. There are no calls to malloc and free and no reference counting. Despite this, it's easy to write JavaScript code that leaks. It's easy to write leaky code in any garbage-collected language. But it's even easier in this environment because some of the objects you're dealing with are reference-counted behind the scenes. ... "

" ... This Firefox extension detects one very specific type of memory leak in chrome JavaScript and in Web pages. (Not in JavaScript components, though.) It detects when JavaScript objects in the chrome or Web page are still held by native code after the window is closed. It notifies the user after the first full garbage collection (i.e., cycle collection) after the window has been closed, so that the user is most likely to be able to correlate the notification with the action that caused it. ... "

Discusses several approaches for using multiple major-modes in a single buffer (for, for example, literate programming). 'multi-mode' seems to be the most promising approach, as it maintains several 'shadow' buffers behind the scenes to avoid switching modes and keymaps all the time. It is incompatible with nXML font-locking and (presumably) js2-mode, though.

Recursive-descent parser based XML editing mode. Syntax highlighting, and more importantly, support XHTML very well.

Recursive-descent parser-based editing mode for emacs. Does syntax highlighting, shows warnings. Not as comprehensive as espresso-mode + flymake + jslint, probably, but good enough.

" ... Let's be honest. Your tests mostly follow the “happy path”. Sure, on occasion you remember to test “the failure case”—the caller passed in null or a negative integer as an argument—mostly because you just got done writing that check and wouldn't it be a waste not to write a test to show how clever you were? Never mind that null or a negative argument is an assertable precondition that could never happen in production anyways. ... " The way I've felt for years. Roland Backhouse had an even more damning critique of testing as a method for catching bugs in one of his books.

" ... Whilst we may muse about engineering, architectural or craft metaphors for software development, there is no denying that, in essence, programming is writing. It is a form of communication that has two distinct audiences: us and the machine. Although there are times when it might not feel this way, the machine is easily pleased, demanding little more than well-formed code. We, however, are a little more complex and discerning: we demand that our communication communicate ... " A strange, almost political essay about coding style

" ... The conclusion I draw from this is that you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something. ..." He's right. His conceptual explanation does make git a lot easier to understand.