Unless you’re a web publishing nerd, you should probably stop reading here.

Back in college I wrote an awful lot - one of the advantages of a liberal arts education - but since then I’ve fallen woefully out of practice. I’m pretty sure at least part of the problem is the unpleasant experience that is composing thoughts in WordPress, and my previous attempts to hack together an emacs2WordPress workflow just haven’t panned out.

I’m happy to report, then, that I’m preliminarily very excited about Jekyll, a “blog aware static content generator” written by one of the GitHub guys. Static content generation is certainly nothing new, but the implementation is slick, and some simple Rakefile hacks and git orchestration makes the whole thing really smooth.

So now, writing moves from snippets collected in org files, OmniFocus notes and emacs buffers to Markdown formatted files in my Jekyll tree, and finally gets pushed via Git to a repository on my server, where a post-receive hook runs runs Jekyll. Jekyll works its magic and dumps the results into a directory served by httpd, and that’s what you see. This seems to work pretty well, and lets me keep my text editing where I like it, in emacs. Some handy Jekyll editing functions from Alex Payne metajack help tie things together.

I originally wanted to take advantage of GitHub’s free hosting of Jekyll sites, but ended up wanting a bit more flexibility than they currently provide, mainly around feed generation and serving.

To celebrate the occasion, and just in time for the start of the work year, I’ve also started publishing at a different URL. The luxury of an unusual name keeps me at the top of ”g travis vachon”, so I don’t feel bad about going with something a little more fanciful. combinate is nice and succinct and captures a lot of what I like in the world and technology in particular and, most importantly, wasn’t taken.

So, Happy New Year, and here’s to writing more.

Tim Bray tonight:

I think the concurrency problem is pretty well solved for one class of application: the Web server and most of what runs in it.

And coincidentally, a new web framework that aims to help you saturate those cores, from my pal Evan Miller:

You will write clean, synchronous, sequential code. Chicago Boss takes care of the rest.

This strikes me as the reason my web dev friends don't get very excited about the current crop of concurrency focused languages. The framework takes care of all that! Which is great!

When you aren't riding the HTML highway though, I'd definitely recommend checking out Clojure. There's been an upswing in interest in my circles lately - Programming Clojure's fantastic, the community is lively and Rich Hickey appears to be a genius.

I attended the Scala Lift Off a few weekends ago and I'm really glad I went. This was my first unconference and my first major Scala event (outside BASE talks) but even as a relative outsider attending alone I felt really welcome and had a great time.

Keynote

Martin Odersky started off the day with the keynote address, entitled "Scala - The Next 5 Years." The big picture is that he wants "to make Scala the primary choice for concurrent and parallel programming on the JVM in 5 years," which is no doubt a worthy goal (though not one that's likely going to go uncontested). While he touched briefly on a number of the concurrency paradigms he plans on exploring and potentially introducing to further this goal, he pointed out that some of the most important fundamentals of concurrent programming are already supported. One of the keys in his mind is mutable state, which "becomes a liability when you want to be concurrent." Scala's strategy of easing traditional Java programmers into immutability by advocating the use of val and providing support for pure functional programming is particularly useful here. Even though a Java programmer's first pass at high performance concurrent programming in Scala might introduce inefficiencies via mutable state, fixing these problems can be a matter refactoring rather than wholesale rewrites. This fundamental strength combined with Odersky's plans to further explore actors, transactions, join patterns, and stream processing is very exciting.

A second highlight of the keynote was a discussion of static typing. Bucking the industry trend toward dynamically typed languages like Python, Ruby and Groovy over the past few years, Scala is statically typed - though I'd note that Scala's static typing feels like a Ferrari to Java's Gremlin. In Odersky's words, "static typing is a key ingredient for reliable concurrent programs, yet programs are annoyingly hard to get right." Even with the advances in the type system, compiler errors can be cryptic, and I can say with personal experience that decisions like co vs contra variance are practically a matter of guess and check to the non-expert. The solution proposed here was better tools: type browsers, type debuggers, and better communication from the compiler. Type systems can be a huge win, and save time in the long run by producing code that works as expected once it compiles. The delicate balancing of designing systems of typed objects that work really well and don't get in the way is perhaps not as well understood or supported as it should be, and it was great to hear Professor Odersky advocating practical solutions that have the potential to really help engineers produce robust software.

The talk also helped further the impression that Scala is beginning to really come into its own as a serious industrial strength language. The list of adopters - including Twitter, eBay, Siemens, and Xerox - was impressive for a young language, and the general tone was confident, upbeat and focused.

Sessions

After the necessary unconference planning session, we broke off into smaller sessions around the room for the rest of the day. I ended up on a fairly practical track, though I would have liked to get to a few more "cutting edge applications of functional techniques" style sessions, as they looked pretty interesting.

Development Environments

Scala development, if this session at LiftOff is any indication, is currently pretty heavily skewed toward IDEs like Eclipse and IntelliJ and almost always uses Maven. I suspect the Maven skew is largely due to the fact that Lift's documentation speaks Maven. The one very notable exception to this was Twitter. During Alex Payne's talk later in the day he explained the "Simple Build Tool" developed in-house to encourage similar project structure and development practices. Essentially a wrapper around Ant and Ivy, it appears to be a lightweight alternative to the often unwieldy Maven.

Collections

There was quite a bit of buzz around the next release of Scala - 2.8 - which is due in the fall, and for good reason. One of the most exciting pieces of work that will make it into this release is the cleanup and reorganization of the collection libraries. While Scala's current collection library is pretty extensive, covering both immutable and mutable collections, strict and lazy collections, along with a (sometimes) usable Java conversion library, the whole package feels a little gooky and inconsistent. It turns out this is largely a result of an organic development process, and the Scala team has given this key part of the standard library some serious love with an eye toward consistent, coherent design and usability.

Scala @twitter

Twitter made big waves this year in the Scala community by talking quite a bit about its transition away from Ruby backend services in favor of Scala based solutions like Kestrel. As a result, Alex Payne's session on how Scala is being used within Twitter attracted a big audience, even during lunch. He ran through a presentation I hadn't seen, but which is pretty widely available (I think it was this one) and talked a little about the various pieces of open and closed source infrastructure they've built out. Sadly, lunch took priority over my laptop at that point, and I didn't take the best notes.

Scala Tips

The last session I attended was Jorge Ortiz's "Scala Tips," which provided a good summary of some of the best practices being discovered by the community. The talk itself was basically some in-depth discussion of this blog, but various luminaries were on hand to provide commentary and more discussion. One of the more interesting parts of this discussion was an item noting the dichotomy between API and client programming in Scala. While this type of programming is generally stylistically different in any language, I've noticed - and Jorge reinforced - that Scala really enhances these differences. API design tends to be a lot more about thinking carefully about types and the relationships between them, and involves lots of type declaration - even when not technically necessary - and iteration with the compiler to make sure everything makes sense. Client programming, on the other hand, feels almost like a dynamic language. Type declarations are few and far between, structural types provide duck typing-like flexibility, and the REPL allows for convenient exploratory programming.

Community

At Dogpatch Studios today in a neighborhood I visit very rarely - Potrero Hill - for Scala LiftOff. As I write, Martin Odersky is setting up for the keynote entitled "Scala - The Next 5 Years," which should be interesting. Based on the BASE meeting earlier this week I know the punch line - "to make Scala the primary choice for concurrent and parallel programming on the JVM in 5 years" - but I'm looking forward to more details about the plan to get there.

I'll likely be twittering the hell out of this thing, and hashing with #scalaliftoff, so feel free to drop a filter on that for the rest of the day of you don't care. I'll do my best to post a wrapup in this space afterwards.

This is some powerful shit:

What's really striking is how innocuous the procedure looks to the observer - as I was watching it I thought "oh, that doesn't look so bad." Clearly, this is precisely the opposite of the experience Mancow had. While it's good to see the general momentum of public opinion moving back toward sanity on this issue, I really do think the worst is yet to come in accounting for this disgrace.