I'm not one of those people for whom the task of composition is a somewhat mechanical extension of increasingly detailed outlines. Nonetheless, research consumes between 80-90% of the time I spend on a technical article (note I said time and not effort -- subjectively, writing text is two or three times …

Some d00d named Leppie has written a \<a href="http://xacc.wordpress.com/"" target="_blank" rel="noopener noreferrer">Lisp for the DLR [via Jason Bock]

Alan Zeichick deserves a fortune in Amazon referral fees for \<a href="http://www.amazon.com/Cables-Go-35507-Connector-Cable/dp/B000JG3WBY"" target="_blank" rel="noopener noreferrer">this: iPod connector to RCA plugs. 

Probably the biggest difference between academic and commercial writing is this: academic writing is almost always concerned with algorithms and process, commercial writing is almost always driven by a specific set of technologies. In this case, I'm being paid by AMD to explain integration of CodeAnalyst and Eclipse CDT. So …

I'm on .NET Rocks this week talking about concurrency -- a sure sign that Carl and Richard have run out of interesting people to talk to. Nonetheless, I try to not make too many mistakes when explaining Shared Memory Parallel, Software Transactional Memory, Message Passing, etc.

If you are interested in concurrent programming, you'll eventually come across the Byzantine Generals problem. Mark Nelson has a good post explaining it.

I thought I'd try blogging the development of a technical article; it might prove interesting to, I dunno', 3 people in the world.

I've been contracted to write a 2,500-words-plus-listings article on using AMD's CodeAnalyst profiler with Eclipse, especially relating to multithreaded / multicore development. So that's a pretty beefy …

Following the lead of the SFWA, which issued a takedown to a fan site based on nothing but the existence of the strings "Asimov" or "Silverberg" in a text file, I've demanded that NBA.com remove all pages that refer to "Larry O'Brien." Those bastards have been distributing my source …

The key to content-aware image resizing (and other recent image algorithms) is the discovery of "seams" -- paths of pixels that don't differ much from each other. Such seams are   places where the picture can be "pulled apart" gracefully. In image resizing, the seam is discarded and the two remaining pieces …

The good news is that I got a contract to write an article in which to discuss content-aware resizing (or rather, I got a contract for an article on performance tuning; I'll use the resizing algorithm as the sample).

The bad news is that the profiler I'll be discussing is …