Apparently there is still a gap between the short form and blogging even at a moderate scale. In the Twitter era, my browser tab count grows frighteningly large, simply because I get out of the Sweeping habit. Some of these are months old. Some are extremely long, others frighteningly deep. Consider this as being placed under your virtual Christmas tree to help make up your geek holiday reading.
Presented in no particular order, sorry.
FreeBSD · The whole world isn’t just Linux, or even Linux, Solaris, and Windows. Don’t forget FreeBSD. Haven’t used it that much, but every time I have it’s been a good experience.
Ruby Stuff · There are all these different versions of Ruby bubbling up, and while MagLev isn’t quite the flavor-of-the-week it was for a few weeks last year, it looks like being a really interesting alternative.
Over in Ruby-land, the central news is the continuing progress on Ruby 1.9.*, which is intended to lead in an orderly way to Ruby 2.0. One of Ruby.next’s key features is Multilingualization (M17n); Ruby historically having been somewhat behind in its internationalized character and text handling. The course they’ve chosen is quite different from Python’s Unicode-defines-reality, and while I would have probably preferred the Pythonic approach, M17n seems well thought through. Yoko Harada has provided an English translation of The design and implementation of Ruby M17N originally by Yui Naruse. It’s not short and not shallow. If you want something a little more punchy, try Don't use String#force_encoding from Yugui, whom I previously wrote about and photographed here.
ORM Blecch · My relationship with relational databases has always been chilly, but that’s a lot better than my relationship with object-relational mapping, which has never given me anything but pain. The one route to unambiguous success in ORM seems to be the Rails’ tactic of slashing flexibility; just Do It Like Rails Wants and you’ll be OK. I think that world needs regular reminders that this is far from a solved problem in the general case; Aido Cortesi’s A Farewell to ORMs is a good one.
REST/Web Stuff · Here’s the first major official change in HTTP in a long, long time: The PATCH method is now officially blessed. It’s going to take years to discover what if anything the big-picture impacts are.
William Vambenepe is maybe the most interesting online writer over at Oracle; possibly I see it that way because he’s always covering things I care about. I thought his recent REST in practice for IT and Cloud management (part 3: wrap-up) was terrific. It covers a lot of related subjects and says smart things about all of them; smart things I disagree with in a few cases (“Linked Data”, are you sure?), but in every case worth reading.
Colour! · They’re talking about standardizing colour, in some part as a reaction to the Pantone hegemony. I’d say “I hate to say I told you so” but I don’t.
Measuring Virtualization · It’s really important to understand our computers’ workloads, and as the number of layers in the workload grows and grows, it gets harder. One of the more complex layers is virtualization, of course. Recently, Sun gleefully announced record performance on a SAP benchmark, and then a blog post called Virtual Overhead? caught my eye. Among the usual benchmarkers’ chest-pounding (they feed those guys raw meat for breakfast) there’s what looks like a weird virtualization performance anomaly. The industry needs to understand this stuff a whole lot better than we do.
You Can Never Climb the Same Tree Twice · There’s a pattern out there that I’d been noticing at the back of my mind, but Manual Woelker throws it into sharp relief with Persistent Trees in git, Clojure and CouchDB. There are a large and increasing number of situations in which you want to do non-destructive updates; that is to say, accept additions, changes, and deletions to your data, reflect them as appropriate, but never lose the previous state. This has tons of implications for reliability, consistency, and especially concurrency. It’s starting to look as though there’s emerging consensus on The Right Way To Do It. Which is how Engineering is supposed to work, and Software Engineering too rarely does.
TDD Yes/No? · Speaking of consensus, when it comes to Test-Driven Development, at the current moment we basically don’t have any. Consider for example It's OK Not to Write Unit Tests by Chris Ashton. I actually agree with some of his points; my opinion has moderated a bit and is now something like “TDD should be compulsory wherever it can be made to work”; but we really need to have a serious extended focused discussion here in this profession so we can get some agreement on where that is and isn’t.
Strengthen Your Brain · Sit back. Clear the next half-hour, get yourself a strong cup of coffee, and read The Continuation Monad in Clojure by Jim Duey. It’s not quite as hairy as the title suggests, but it’s about as good an explanation of a few core concepts as I’ve read anywhere. I also like the way that it just uses monads without veering into the theory, and suspect that this may be a really good way to approach that famously-difficult subject. A nice piece.
Best O’ The Season · May you geek out in a warm glow of peace, love, and over-eating.
Comment feed for ongoing:
From: Daniel Haran (Dec 18 2009, at 13:01)
Re: Chris Ashton on TDD. His About page mentions that he does "mostly just a lot of bugfixing".
I still find unit tests helpful. Maybe I'm not a good enough developer yet - at least according to the condescending writings by Ashton. Instead of hot air and ad hominem, it would be nice to have some empirical data.
Not that data's ever stopped people from fighting their religious wars :)
[link]
From: Elliotte Rusty Harold (Dec 19 2009, at 11:10)
Tim,
I was all ready to rip Chris Aston a new one, but then I read his blog post and realized he wasn't saying anything like what you said he was saying. Chris is objecting to unit tests, not to test driven development. His objections are little strong, and there are few things he misses; but he really isn't arguing one way or the other about test driven development.
In 2009, soon 2010, there is consensus about test driven development. It works. It is a far more effective way of building software. Some programmers don't like to do it, but all the evidence is that it works, and works better than anything else we have ever tried.
[link]
From: Ken Cavanaugh (Dec 19 2009, at 12:02)
Re: "You Can Never Climb the Same Tree Twice"
This technique is much older than the cited references. The earliest reference I know is in Fridrich and Older "The Felix File Server" which was published in the 8th ACM SOSP in 1981. I worked on the system at Bell Northern Research back in the mid-80s. I think the shadow copy tree approach probably dates back to at least the 70s either in IBM mainframe work or in OS shadow paging, but I don't have any references for this.
I think the most important characteristic of these ideas is that multicore makes formerly more expensive ways of implementing data structures more attratctive, since immutable data structures are easier to use and scale better.
[link]
From: Jim Duey (Dec 19 2009, at 13:42)
Wow! I was just catching up on your blog and saw your link to my piece on the continuation monad. Thanks very much for the compliment. It means a lot to me.
[link]
From: Tim (but not THE Tim) (Dec 19 2009, at 19:40)
I think I've beaten this particular horse before - but everyone working on virtualization should be sure to study their history: specifically, IBM's VM (Virtual Machine) that's been around since 1967, continually updated to work with IBM's newer hardware architectures.
While obviously there are architectural differences, I think that a lot of the problems in virtualization and sharing hardware are the same from platform to platform, and studying VM's solutions, or lack of solutions, to them might be instructive.
[link]
From: John Hart (Dec 23 2009, at 10:20)
I'm surprised the persistent trees article talks about journaling & NILFS, but doesn't mention ZFS or btrfs. While journaling isn't necessarily linked to persistent trees, but atomic-root-update trees (or immutable trees, or copy-on-write trees) are the heart of ZFS and btrfs.
Persistent trees: RAM is the new disk.
[link]
From: Chris Jaynes (Dec 27 2009, at 22:10)
The problem with finding consensus on TDD is that very few developers have bothered to sort out the differences between terms like "unit test", "acceptance test", or "test-driven development". Many teams I've worked with are forced by management or development leads to blindly follow a testing approach plucked at random from a blog post or a book.
When it comes right down to it, blindly following any rigid, dogmatic approach to testing (or any other part of development) is likely to get a team into trouble.
With that said, the best teams I've worked with have NOT strictly adhered to TDD practices, but they have had one thing in common: they have a solid suite of automated tests that does 2 things...
1) Acts as a safety net to improve confidence when making changes.
2) Insulates the development team from nuisance defects generated by the test team.
Most of the really good tests I've seen have NOT been traditional unit tests, but what most developers would call integration tests, or acceptance tests. I just call them "developer tests".
"Developer tests" make sure the software can still handle the basics after changes are made to the code base. "Tester tests" find bugs that developers can't/don't think about.
[link]
From: Avi Flax (Dec 29 2009, at 14:52)
Hi Tim, could you clarify how PATCH has been "blessed"? Reading the draft you linked to, it looks like just another version of the draft, v16.
It still has this language: "Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
and: "This Internet-Draft will expire on May 29, 2010."
[link]
From: Nico (Jan 07 2010, at 12:27)
Re: never climb the same tree twice.
This is also known as COW. It's not new! ZFS is but one of many recent examples of it. In Clojure and similar languages we have zippers -- really neat.
The more interesting new pattern here, and it's not really that new either -- just more baked into a language -- is Clojure's approach to threading. In Clojure "variables" (bindings) are read-only, and you can only establish new bindings, except for special global variables that have to be modifiable, and can be shared with threads, with the caveat that all changes to shared state have to be synchronized via a transactional interface. This is key because if you have lots of closures then you have potentially more shared state than you might realize, and the fix in Clojure was to make binding immutable. But you can't make the root state immutable, thus transactions are part of the solution.
Would that we could write C programs that way (hey, some of us have to write C). Well, we can, actually. You can do anything in C that you can do in HLLs, just not as neatly. Think: ZFS is written in C, yet it does COW; closures are function pointers + heap-allocated structures containing some state; OO, functional programming, Erlang-style threading -- all of it can be done in C (with discipline).
[link]
From: Seth W. Klein (Jan 07 2010, at 16:46)
Thank you for this post. Your tab sweep posts were always a pleasure to read. Strangely, I don't find the same with the short form fragments, although I would expect to.
[link]
From: Sam Penrose (Jan 07 2010, at 22:25)
You've probably seen Andrew Dalke (and Maria Siniaalto) on TDD: http://www.dalkescientific.com/writings/diary/archive/2009/12/29/problems_with_tdd.html
When I made this comment:
http://dalkescientific.blogspot.com/2009/12/problems-with-tdd.html?showComment=1262189401221#c6186059459961398988
I was thinking of you, and if not specifically of Eliotte (whom I also admire very much) ... well, I'm not surprised to see him turn up here with a vociferous brief for TDD. In a nutshell, fields in creative tumult seem to drive their brightest practitioners to band together around a simple, coherent model of The Right Way. In economics it led to disaster (see http://www.nytimes.com/2009/09/06/magazine/06Economic-t.html?pagewanted=all). TDD reminds me of the rational markets hypothesis in the way it combines a social sorting function with an intellectual ferment and "advances" which are seen most clearly by practitioners. In short, it looks like a fad. A genuine advance (which it may also be!) can become a fad, but the faddishness tends to make it hard to evaluate until things have calmed down a bit.
Note that however silly you may think this perspective, you can't refute it by citing the intelligence or accomplishments of the TDD crowd or by e.g. choosing Chicago over Krugman. BOTH sides in Krugman's piece featured intellectual giants of Knuth/Joy/Ritchie etc. stature, and at least one sides' partisans are completely wrong about the fundamentals of their field and have been committing professional malpractice for decades. I trust you can come up with similar examples from other fields (or maybe our own -- your recent "Doing It Wrong" will serve).
There's more to say about why these things become fads, but I think your recent comment about only being willing to hire TDDers is pretty much all anyone needs to know.
[link]