Technomancy

in which three programming methods are compared

2012-05-16T16:07:43Z

There are, roughly speaking, three ways to develop large user-facing programs, which we will refer to here as 0) the Unix way, 1) the Emacs way, and 2) the wrong way.

The Unix way has been expounded upon at length many times. It consists of many small programs which communicate by sending text over pipes or using the occasional signal. If you can get away with using this model, the simplicity and universality it offers is very compelling. You hook into a rich ecosystem of text-based processes with a long history of well-understood conventions. Anyone can tie into it with programs written in any language. But it's not well-suited for everything: sometimes the requirement of keeping each part of the system in its own process is too high a price to pay, and sometimes circumstances require a richer communication channel than just a stream of text.

This is where the Emacs way shines. A small core written in a low-level language implements a higher-level language in which most of the rest of the program is implemented. Not only does the higher-level language ease the development of the trickier parts of the program, but it also makes it much easier to implement a good extension system since extensions are placed on even ground with the original program itself. I wrote about this in an earlier post on the live-development model Emacs offers:

If you have to use some tacked-on "plugin mechanism" to customize it, then you’re going to be limited at the very least by the imagination of the author of the plugin mechanism; only the things he thought you would want to do with it are doable. But if you’re using the exact same tools as the original authors were using to write the program in the first place, you can bet they put all their effort into making that a seamless, powerful experience, and you'll be able to access things on an entirely new level.

-in which a subject is attempted to be approached objectively, though such a thing is actually impossible

It's worth noting that this is the model under which Mozilla is developed. The core Mozilla platform is implemented mostly in a gnarly mash of C++, but applications like Firefox and Conkeror are primarily written in JavaScript, as are extensions. Following the Emacs way accounted for Firefox's continuing popularity even back when it was getting trounced by competitors in terms of JavaScript performance. Chrome's extension mechanism is laughably simplistic in comparison.

Finally for completeness sake, the wrong way is simply to write a large monolithic application in a low-level language, usually C++. Often half-hearted attempts at extension mechanisms are bolted on to programs developed this way, (usually in order to check off another box on a features list) but they are invariably frustrating and primitive and don't end up offering extension developers the same access to program internals that the developers of the original program itself have.

The Unix way makes particularly explicit the notion of composing small programs, but the Emacs way shines when a single runtime process plays host to a number of independent programs that can interact with each other gracefully. For instance, the Magit version control interface can run in the same Emacs instance as a SLIME session controlling a lisp project. They coexist in a complimentary way and compose together without interference. So rather than saying there are three ways to write large user-facing programs, it might be more accurate to say that there are zero good ways to write large user-facing programs and two ways to compose a number of small programs into a coherent system.

This is especially interesting to me right now since it has come to my attention that when it was rewritten in the transition from version 2 to version 3, GNOME has switched to the second way via an embedded JavaScript runtime, which means things are about to get very interesting.

in which korean hardware pleases

2012-05-09T04:25:14Z

I just got a new laptop, and while I wouldn't post about it normally I've had a number of people ask me what I thought of it. For the last five years or so I've been a Thinkpad user exclusively, but the latest models of their lightweight X series have offered disappointing screens with 1366x786 being the only resolution option. Since my dignity prevents me from buying a laptop with fewer vertical pixels than my phone, I broadened my search this time around and came across the 13-inch Samsung Series 9, aka NP900X3B.

At first the most striking thing about it is its thin profile, but once you've started using it you realize it's the screen that really sets it apart. Samsung is the largest manufacturer of LCDs in the world, so it makes sense that the screen would be the distinguishing factor on their high-end models. The resolution is 1600x900, which I couldn't find in anything else smaller than 14 inches, but it's the 400 cd/m² of brightness that really sets it apart. With summer right around the corner, this perfect for working outdoors.

While I'm pretty thrilled with the new machine, the thin profile forces some difficult compromises with the keyboard. It's of the standard chicklet design, which is a drag coming from the Thinkpad. The X200s Thinkpad I was using previously had a very comfortable response and depth to it that you don't find with chicklet keybords. The Samsung also lacks a trackpoint, drainage tray, and dedicated volume buttons. The X200s isn't appreciably heavier than the Samsung; (only ½ a pound more) but it is over twice as thick. Personally if it's light enough I don't find thickness to be a problem; I'd much rather have a comfortable keyboard than a 0.4-inch profile. But it does turn heads.

The speakers on ultraportable laptops like the X200s typically come across as a token effort to fill a feature checkbox, but the Samsung's are fairly respectable. I was pleased to see the lack of the hardware wifi kill switch that plagued me on my Thinkpad. It's also got a bigger selection of ports than you'd expect with the slim profile: USB 2, USB 3, micro-HDMI, combined mic/headphones, and Ethernet, though the latter must be used with the provided adapter.

I'm running Debian Wheezy on it because I read on a blog post that a newer kernel was needed for the wifi drivers, but apparently this was only the case with an earlier model of the Series 9 that used the Broadcom chipset; The NP900X3B uses an Intel chipset that has been well-supported for some time. Everything worked perfectly out of the box except the keys for adjusting the keyboard backlight. The camera, external monitor port, and multitouch trackpad work as you'd expect. The suspend functionality, which has traditionally lagged behind Mac OS X, resumes in a couple short seconds.

While I would love to see this same screen on a laptop with the luxurious keyboard, carbon fiber body, and replaceable battery of a Thinkpad, the Series 9 is quite slick and should keep me happy for a number of years.

in which we plot an escape from the quagmire of equality

2012-04-27T05:45:01Z

If you follow happenings in the Clojure world, you may have noticed that the announcement of clojure-py brings the number of runtimes targeted by Clojure up to four. While it's great to see the language expand beyond the JVM, it's not too exciting to me personally since the runtime I spend the most time in by far is that of Emacs. Of course, Emacs can already be programmed with lisp, but the dialect it uses leaves much to be desired. I miss first-class functions[1], destructuring, literals for associative data, and immutability whenever I find myself writing nontrivial Emacs Lisp code, and the lack of these features makes me reluctant to write in it even though it offers an environment with live feedback unmatched by anything but the Smalltalk images and Lisp Machines of yore.

Part of what makes ClojureScript interesting is that it has distilled the number of primitives needed to port Clojure to a new runtime down to a small number due to its push towards self-hosting. One of the Summer of Code projects for this year is to allow for pluggable backends in the ClojureScript compiler, with Lua as a proof of concept. I started to think through what would be necessary for this to happen on the Emacs runtime, but I ran into an interesting quandary regarding referential transparency.

A function is referentially transparent when it is guaranteed to return the same value every time it is called with a given set of arguments. This is a great guarantee to be able to make about your functions as it reduces the number of things you need to keep in your head. Referentially transparent functions really can be thought of as black boxes: always deterministic and predictable. But a function that operates on mutable objects cannot be referentially transparent—it cannot make any guarantees that future calls involving that same object will result in the same value since that object could have a different value at any time.

Since Emacs Lisp does not provide any immutable data types other than numbers, only functions that operate on numbers alone can be referentially transparent. This is a shame, since referential transparency allows you to have much greater confidence that your code is correct. Without it, the best you can say is "as long as the rest of this program behaves itself, this function should work". This works a lot like older OSes with cooperative multitasking and no process memory isolation, which is to say not very well.

But arguably the worst thing about lacking referential transparency is that you can't check for equality in a meaningful way. Henry Baker's paper "Equal Rights for Functional Objects" addresses the problem of equality in Common Lisp[2], which is notable for having a plethora of equality predicates depending on what level of coarseness you want:

EQ: are both arguments the same object in memory?
EQL: like EQ, but compares value for non-immediate numbers like tagged fixnums and bignums.
EQUAL: do both arguments have the same structure and contents?
EQUALP: like EQUAL, but allows integers to equal floats and ignores string case.
=: are both numbers of equal value?
CHAR=, STRING=, STRING-EQUAL, ad nauseum.

Baker argues that this confusion is due to a muddled notion of object identity. Everything would be so much simpler if we could think in terms of operational equivalence:

Two objects are "operationally equivalent" if and only if there is no way that they can be distinguished, using ... primitives other than [equality primitives].[RNRS]

Asking "Are these two objects stored in the same memory location?" lets implementation details leak into your code. Equality should really be about "Can these two objects behave differently in any observable way?". Baker's paper implements the egal function in terms of this question; it's an equality predicate that defines object identity as a transitive closure of immutable attributes of an object. So without immutability, egal always returns false.

Of course, with a compiler that targets Emacs Lisp, you can work around this by implementing your own immutable types. But this makes any form of interop much more cumbersome; close integration with its host platform is one of the core design tenets of Clojure, and having to perform conversions on basic types like strings just to call native elisp functions would be too cumbersome to be practical. So with the Emacs runtime as it is, you have to choose between getting equality right and seamless interop. Damned if you do; damned if you don't.

There are two possible solutions to this. There has been an ongoing effort to get Emacs Lisp running on the Guile VM. As it comes from a Scheme background, Guile provides the immutable data types we need. Update: the immutable types offered in Guile do not actually come from the Scheme standard, but they are present nonetheless. However, Emacs Lisp is very different from Scheme, and the Guile implementors have an enormous task ahead of them to get even the basics working; the amount of work needed to achieve compatibility with the bulk of quirky extant Emacs Lisp code is daunting. But it would be wonderful if it were possible.

The more realistic option is to add immutable data types to the existing Emacs implementation. I suggested in passing on the emacs-devel mailing list that I would be interested in financially supporting such a feature, which led to a discussion of its pros and cons. It turns out there is very little code that would break if Emacs strings became immutable; even though it's possible to change strings it happens rarely enough in real code to not pose serious problems. Changing lists to be immutable would break huge amounts of code though, so a more reasonable approach would be to offer an alternate list constructor for immutable lists so that functional code could have access to immutability without wreaking havoc on existing functionality. Ideally libraries could opt-in to having the reader return immutable lists, but I don't know enough about Emacs's reader to know how feasible this is.

Unfortunately I'm not the one calling the shots; I don't have the C skills necessary to make it happen even if the Emacs maintainers were favourable to the idea. But it's interesting to think about, especially as concurrency may be introduced in Emacs 25. One certainly can dream.

[1] Common Lisp fans claim that lisp-2s have first-class functions, but the way they are kept separate from other first-class values in their own namespace ghetto brings to mind claims of "separate but equal"—at best it is Jim Crow functional programming.

[2] Emacs Lisp is not Common Lisp, but the two dialects are very closely related, and for the purposes of this post share the same problems.

in which we coin a term which is the opposite of deprecate

2012-02-29T00:57:50Z

Earlier this month I published the results of a survey I had posted for Leiningen users. I got a lot of great data, but I especially appreciated the free-form "other comments" section that let people just ramble. I was happy to see that many of the suggestions have already been implemented in the ongoing work on Leiningen 2.

I still think lein-multi should be rolled into core so people can be encouraged to test cross-version.

Profiles

This brings me to what is probably the biggest feature in Leiningen 2.0: profiles. In Leiningen 1 we had some special cases to segregate out "dev" mode from the rest so you would only have certain dependencies or directories available during development. This is useful to have, but the implementation was pretty ad-hoc and riddled with special cases. During some discussion with the Cake developers we talked about whether that could be generalized, which turned into the idea of profiles.

So now rather than a handful of project configuration keys that are only active during development time, we have a :dev profile that's active by default where you can keep your additional test-only :dependencies and :resource-paths. You can also keep all your :plugins that you want active across all projects in the :user profile rather than using lein plugin install. That way there is only ever one plugin list active at a time, meaning it can be de-duplicated, avoiding messy conflicts.

But you can also create profiles for other situations:

(defproject clj-http "0.3.3-SNAPSHOT"
  :description "A Clojure HTTP library"
  :url "https://github.com/dakrone/clj-http/"
  :min-lein-version "2.0.0"
  :dependencies [[org.clojure/clojure "1.3.0"] ; elided below...
                 [org.apache.httpcomponents/httpclient "4.1.2"]
                 [cheshire "2.2.0"]]
  :profiles {:dev {:dependencies [[ring/ring-jetty-adapter "1.0.2"]
                                  [ring/ring-devel "1.0.2"]]}
             :1.2 {:dependencies [[org.clojure/clojure "1.2.1"]]}
             :1.4 {:dependencies [[org.clojure/clojure "1.4.0-beta1"]]}}
  :aliases {"all" ["with-profile" "dev,1.2:dev:dev,1.4"]})

Here you can see the :dev profile with some handy dependencies used for testing, but there are also profiles for :1.2 and :1.4 that can be used like lein multi. The with-profile task is used to apply alternate profiles to a given task run:

$ lein with-profile dev,1.2 test
Performing task 'test' with profile(s): 'dev,1.2'

Testing clj-http.test.client

Testing clj-http.test.cookies

Testing clj-http.test.core

Ran 47 tests containing 175 assertions.
0 failures, 0 errors.

You can see that commas allow multiple profiles to be specified at once. You can also use colons to chain together profile sets sequentially:

$ lein with-profile dev:dev,1.2:dev,1.4 test
Performing task 'test' with profile(s): 'dev'
[...]
Performing task 'test' with profile(s): 'dev,1.2'
[...]
Performing task 'test' with profile(s): 'dev,1.4'
[...]

Of course, since with-profile is a higher-order task, it can accept any other task as an argument, not just test. So you could use it for deploying to different environments or any place where you'd want an alternate set of project configuration values.

Aliases

You'll also notice that the :aliases entry in the defproject above maps a string to a vector. This is a new feature about which I am unreasonably pleased. You've always been able to add aliases for Leiningen tasks; this is how lein halp has worked. But now you can actually alias a string to a partial application of a task:

:aliases {"all" ["with-profile" "dev,1.2:dev:dev,1.4"]}

This means that all test translates into calling with-profile dev,1.2:dev:dev,1.4 test. But partially-applied aliases have other uses as well:

:aliases {"reflect" ["assoc" ":warn-on-reflection" "true" "compile"]}

This allows you to invoke lein reflect to get a list of all your reflection warnings. Note that in this case assoc refers to the task that comes from the lein-assoc plugin, not the clojure.core/assoc function. Each string in the alias vector is interpreted the same way as if it were a direct command-line argument to the lein script, which is why strings must be used. In this case reading it into keywords and booleans happens inside the assoc task.

And that's one of the neat things about having tasks as functions.

Preview

By this point I'm sure you're thinking to yourself, "Gosh, that sounds super; I wish I could use it now!" In fact, Leiningen 2 is already pretty usable and stable if you don't mind running from git. You need a copy of Leiningen 1.x around to bootstrap it, but running lein install inside the leiningen-core directory should get you to the point where you can symlink bin/lein to somewhere on your path and have it work. I recommend linking it as lein2 for the time being since you'll probably still need an installation of 1.x easily accessible.

Of course, being a major version increment it's got some backwards-incompatibilities. Fresh from witnessing the very bumpy transition to Clojure 1.3, I'd rather avoid that for Leiningen 2, so taking a cue from golang's gofix tool, I've released the lein-precate plugin.

Precate, obviously, is the opposite of deprecate. The idea is that you could run it on your project and have it spit out a new project.clj which would be compatible with Leiningen 2. It's not perfect, but it should provide you with a starting point for your transition:

$ lein plugin install lein-precate 0.3.0
$ cat project.clj # the original 1.x-compatible version:
(defproject clojure-http-client "1.1.1-SNAPSHOT"
  :description "An HTTP client for Clojure."
  :source-path "src/clj"
  :extra-classpath-dirs ["dumb-stuff"]
  :dev-dependencies [[swank-clojure "1.3.4"]]
  :dependencies [[org.clojure/clojure "1.2.1"]
                 [org.clojure/clojure-contrib "1.2.0"]])

$ lein precate # let's see how that would look for Leiningen 2
(defproject clojure-http-client "1.1.1-SNAPSHOT"
  :description "An HTTP client for Clojure."
  :source-paths ["src/clj"]
  :dependencies {org.clojure/clojure "1.2.1", 
                 org.clojure/clojure-contrib "1.2.0"}
  :profiles {:dev
              {:resource-paths ["dumb-stuff"],
               :dependencies {swank-clojure "1.3.4"}}}
  :min-lein-version "2.0.0")

Unfortunately that output had to be manually edited a bit for cosmetic reasons; Clojure's pretty-printer doesn't really know what to do with defproject forms. But it should cover most of the changes necessary to take your project into the exciting new world of Leiningen 2. The biggest changes will come from the move from :dev-dependencies to :dependencies in the :dev profile. But this is not a foolproof translation since in Leiningen 2 :dependencies only run in the context of the project itself, while in Leiningen 1 :dev-dependencies ran in both Leiningen and the project. In retrospect this was a design mistake, but there are a number of plugins out there that take advantage of this fact and will need to be split into separate artifacts for the parts that run in Leiningen vs the parts that run in the project. I've taken some time to adapt some of the most commonly-used plugins for this change, but I'm sure I missed some of the more obscure ones.

The plan from here is to polish off a few more features and cut a preview release. The preview will still be missing a handful of the more obscure features from Leiningen 1 like shell wrappers and selective transitive class file cleaning, but for the vast majority of projects it should be usable for everyday work. See the "post-preview" section of the todo file for details on what's remaining. The hope is to have it ready at latest by the Clojure/West conference. Enjoy!

Update: Leiningen 2.0.0-preview3 has been released! See the upgrade guide.

in which an interview is posted

2012-01-27T03:58:25Z

The folks over at The Setup just posted an interview with me wherein I rant about hardware, interactivity, and Emacs.

Note: this was written up over a month ago; if I were interviewed today I couldn't help but mention the Nix package manager. I use it on my Debian Squeeze system to complement apt-get; I get all the system-level stuff that has to be stable from Debian and anything that needs to be fresh from Nix.

in which local hacking locations are surveyed

2011-12-31T02:25:58Z

I'm lucky to have the chance to do my job remotely from wherever I like. Half the time I work out of my code lab, which is a converted shed in my back yard. But I venture out fairly frequently to local coffee shops. Here are a few of my favourites. I should mention that I'm a big fan of single-origin pour-over brews, so the list is biased in favour of places which serve that well rather than the more traditional espresso drinks. All these have at least one location in North Seattle.

Neptune

I'm here a lot because it's the only one on this list I don't need to get on the freeway for. The decor is a bit sparse, but they're quite friendly here and serve a mean pour-over. They've been known to even serve syphon-brewed coffee, which is always a treat to watch when they fire up the bunsen burner. The proprietor also runs tehcoffee.com, a (Heroku-hosted) site for competition-level baristas can rank and review others. The Greenwood neighborhood is great too; lots of lunch options and bookstores to browse. Bonus fact: Allie, the inventor of the mythical Alot beast has a blend here named after her.

Milstead & Co.

This one has only opened relatively recently, but it's made a splash for a number of things, not the least of which is the spectacular waterfront view from under the Aurora bridge. The selection here is excellent; this is the only place on this list that serves beans from multiple roasters, and they offer plenty of variety in brewing methods. The interior is spacious with high ceilings; it's very inviting. Mr. Milstead himself is usually around, and his excitement about his craft is infectious and obvious once you get him talking. I'd be here all the time if it weren't the furthest (south) from where I live.

Zoka

This one is my go-to place. I often run into people I know here, (and sometimes people I don't), and we hold the Seattle Clojure group meetings here as well. The University District location in particular works well for meetings just because it's so spacious; I don't think I've ever seen a larger coffee shop. It's a popular place for students to study, so it's pretty quiet in the back. It can be crowded at times though, probably based on the school schedule. They've got a great selection sourced from all over the world that rotates every so often. It's always fun to read their blog posts about traveling to visit the growers. The "Zoka bars" they serve here are a ridiculously rich treat. The decor here is very warm and comfortable with wood paneling everywhere.

Trabant

I don't come here often because the parking situation is awful, but if you are in the area (or taking the bus), definitely check out Trabant. They've got good chai, but the thing that keeps bringing me back here is the Clover machine. This contraption is capable of extracting rich flavours out of a bean like nothing else. Unfortunately Starbucks purchased the company that sold them, so there aren't very many places with Clovers that offer good beans. (As the owner of Trabant said about the acquisition, "wearing Air Jordans doesn't make you play like Michael Jordan.") Anyway, the downtown Trabant is very spare, minimalist, and quiet, while the one in the University district (pictured) is bustling and quirky.

Honorable Mentions

Vivace: I'm of the opinion that Vivace has the best espresso in Seattle. It's too far for me to visit regularly, but members of the famed Seattle Ruby Brigade can often be found working here in the afternoon.
Seattle Coffee Works: I've only been here a couple times, but I was floored by their Yirgacheffe both times. They serve their pour-overs at a separate "slow bar" where the baristas are happy to geek out over their creations if you show interest. Again, this one's too far away (Pike St.) to make me a regular.
Green Bean: This one is actually a non-profit which supports a number of other non-profits on a rotating basis. The staff here are really friendly. I like to come here early and get breakfast with my family since they've got a kids' corner.
Chocolati: I don't even come here for their coffee, but their hot chocolate is superb. They've also got great truffles. The Greenwood location is a converted house that offers plenty of space to work, while the Greenlake location is a lot smaller but has nice views of the water.

in which version two seems a treacherous stage

2011-12-01T07:15:11Z

I recently got back from the Clojure Conj conference in Raleigh. The sessions were great, but the main highlight for me was meeting with the developers of Cake (an alternate Clojure build tool) and discussing how we could collaborate on the future of build tools in Clojure. As was announced elsewhere, we will be taking some features from Cake and merging them into Leiningen 2.0 as well as just having more hackers involved in development efforts.

The development of Leiningen 1.x pretty much just fell out of the usage patterns we saw during my time at Sonian as an early adopter of Clojure. We used Maven for eight months, tried to make it work, and then took our experience from the pain we saw there to Leiningen. Some features (especially checkout dependencies) arose directly from finding certain operations with multi-module Maven builds extremely cumbersome. But in general nearly everything about Leiningen so far has been obvious. I wouldn't say it practically wrote itself, but once the central model of a project map and resolving/applying tasks from defns was established, the only really tricky thing was being strict about establishing a narrow scope and knowing when to avoid adding features.

"Version 2" is the most dangerous phase in a software project's life.

— Chas Emerick

So now we're digging into the question of what bigger-picture changes could be made to improve Leiningen if we leave backwards-compatibility out of it. The biggest improvement we've seen implemented so far is switching over dependency resolution to the Aether library via Chas Emerick's Pomegranate library. Aether is a library that contains all the dependency management features from Maven extracted into an independent module—basically designed with exactly Leiningen's use case in mind.

But there's more coming. Cake has had the ability to run project code in the same process as the build tool, significantly speeding up many operations, which is in the process of being ported over to Leiningen. I've been working on explicitly delimiting the parts of Leiningen that comprise its public API as part of a separate "leiningen-core" library which other tools can depend upon. We're looking at adding something like "profiles" do bundle up configuration sets which can be activated in given contexts.

With all these ideas flying around I hope we can buckle down and get some solid design discussions resulting in well-factored features. If you've been looking to contribute, now is a great time. Join the #leiningen channel on Freenode and hop on the mailing list.

in which the lesser-known are brought to the forefront

2011-10-28T17:21:54Z

In my time hacking in Clojure I've found a bunch of under-appreciated Clojure libraries of which I'm rather fond. I thought it'd be helpful to share, so here they are:

lein-multi

As support for Clojure 1.3 becomes widespread, it becomes more important for projects to think about backwards compatibility. You can specify a range of versions for Clojure in project.clj with [org.clojure/clojure "[1.2.0,1.3.0]"], but when you're developing, it will just find the latest and pull that in, so it's easy for dependence on 1.3-specific features to sneak in.

Enter lein-multi, a plugin for running arbitrary tasks against multiple dependency sets. It's most commonly used with the test task, but it's a general higher-order task that can be applied to any other just as well. Seeing lein-multi in someone's project.clj is a good indicator that they take backwards-compatibility seriously.

[lein-multi "1.0.0"]

clj-stacktrace

The most common complaint I hear about developing in Clojure is the fact that its error messages often obscure the true cause of the problem. While practice helps here, it's still true that there's a lot of irrelevant detail here that can overwhelm the trained eye. Mark McGranaghan's clj-stacktrace library does a great job at summarizing stack traces by aligning each frame, making the namespace distinct from the function name, and even coloring frames differently based on whether they come from Clojure, Java, or user code. The next version should let you filter out frames that are deemed irrelevant on a per-project basis.

The web framework Noir uses clj-stacktrace for its HTML error pages in development mode. To use it in your project's repl as well as in clojure.test error reporting, place this code in ~/.lein/init.clj after running $ lein plugin install clj-stacktrace 0.2.4:

(require 'leiningen.hooks.clj-stacktrace-test)

(def settings {:repl-options [:init (require 'clj-stacktrace.repl)
                              :caught 'clj-stacktrace.repl/pst+]})

slingshot

Another common question you hear is "How do I generate custom exception classes?". It's awkward and somewhat un-idiomatic to do this, so people generally try to get by with the Exception classes that ship with the JDK. But why shouldn't exceptions get the same level of dynamicity and flexibility that Clojure affords other data types?

This is basically the question Slingshot addresses. It provides enhanced try+ and throw+ counterparts to the built-in error mechanisms that let you throw arbitrary data types like maps. Then rather than dispatching in your catch blocks based on class, you can use arbitrary predicates. You can even perform destructuring on maps that are thrown. It's a big step up in expressiveness:

(defn asplode! []
  (throw+ {:bad? true :tachyon-level 21}))

(defn ignorable? [e]
  (and (:silent e) (not (:fatal? e))))

(try+ (asplode!)
  (catch ignorable? _)
  (catch :bad? e
    (log/warn "Bummer dude!" e))
  (catch :fatal? {:keys [exit-code]}
    (System/exit exit-code)))

[slingshot "0.8.0"]

lein-difftest

If you've ever written a test where you expect two lengthy data structures to be equal, you'll remember how annoying it is to try to compare the failure message where "expected" and "actual" are each spat out on a single line and you're supposed to try to hunt down the difference. Using lein difftest makes it easy:

It also uses clj-stacktrace to report errors. This one is better off installed as a user-level plugin since you're likely to want to be able to use the difftest task across all your projects:

$ lein plugin install lein-difftest 1.3.7

robert-bruce

From the do-one-thing-and-do-it-well department, we have Robert Bruce, which concerns itself only with determinedly retrying a given function. It provides all the options you could imagine for how to perform the retries, including pausing between them (with exponential decay on backoffs), retry limits, callbacks on failure, and so on.

[robert/bruce "0.7.1"]

Happy hacking!

Do you have a favourite that I've missed here? Leave a comment about it. Remember that the version numbers provided here are current as of the time of this writing but may be outdated when you read this.

in which version two turns the inside out

2011-09-28T04:12:54Z

I just got back last week from the Strange Loop conference in St. Louis. The conference showcased some really quality keynotes and session talks, but I had been invited to give a workshop teaching Emacs, which was a blast. The workshop was three hours long, but I still felt like I was zooming through. My outline is available, though it may not be all that useful unless you were there.

The talk focused on the task of crafting your own set of dotfiles. Naturally I did talk some about the Emacs Starter Kit, though my approach there has changed fairly radically. I've been developing version 2 of the Starter Kit since the beginning of the summer, but now I think it's time to make the release official and give it wider exposure.

The Emacs Starter Kit, version 2

Version 2 of the Starter Kit turns things inside out. The original version was very prescriptive; you used it by cloning a git repo to use as your entire ~/.emacs.d directory, and you fit your own customizations inside the structure it provided. This was mostly due to the fact that when it was released the packaging story for elisp was very immature. Use of package.el was not very widespread, so the Starter Kit had to include a copy as well as bundle a bunch of libraries that had not been packaged yet. As it turned out, I think the Starter Kit had a role in helping popularize package.el.

A lot has changed since 2008—primarily that package.el has been included in Emacs and Marmalade has picked up lots of steam, becoming the de-facto community package source with over 250 packages. It's now feasible for the Starter Kit to be distributed as just another package, leaving you free to structure your dotfiles however you like. All it takes is setting yourself up to get packages from Marmalade:

(require 'package)
(add-to-list 'package-archives
             '("marmalade" . "http://marmalade-repo.org/packages/"))
(package-initialize)

Place that in ~/.emacs.d/init.el and evaluate it with M-x eval-buffer. From there you can run M-x package-refresh-contents to pull in the latest package lists (analogous to apt-get update) followed by M-x package-install starter-kit. And then you're set.

However, it's unlikely that the starter-kit is the only package you're interested in. Rather than picking packages by hand, I'm a fan of keeping a list of all the packages you use in your dotfiles. That way when you move to a new machine, you won't have to remember what packages you've come to depend upon; checking out your dotfiles on a new machine will pull in everything you've specified. Here's my list along with some code to handle it:

(when (not package-archive-contents)
  (package-refresh-contents))

(defvar my-packages '(starter-kit starter-kit-lisp starter-kit-eshell
                                  starter-kit-bindings scpaste
                                  clojure-mode clojure-test-mode
                                  markdown-mode yaml-mode tuareg
                                  marmalade oddmuse scpaste))

(dolist (p my-packages)
  (when (not (package-installed-p p))
    (package-install p)))

What's Changed

Being a 2.0 release, you can't expect 100% backwards compatibility with the old Starter Kit. In particular, it is much more modular. The base of the Starter Kit simply gives you better default settings and a few new commands. There are separate modules supporting various languages like Ruby, Lisp (Clojure, Emacs Lisp, Scheme, and Common Lisp), and Javascript, though right now the Lisp one is the most polished. If anyone is interested in helping maintain alternate language modules, please contact me on Github. Key bindings have also been spun out into their own module since they don't follow Emacs binding conventions strictly.

There is also no more elpa-to-submit directory; if you rely on packages that aren't on Marmalade yet, it's up to you to either check them into your own dotfiles or better yet upload them yourself. There's also no more explicit recentf support since a new feature called ido-use-virtual-buffers allows recent files to show up in the regular C-x b buffer switcher, simplifying things. The addition of the ido-ubiquitous package makes it so regular completion gets enhanced with ido magic, so functionality like ido-imenu is no longer needed.

The other breakage is that the Starter Kit is now intended only for use with Emacs 24 onward. Yes, technically Emacs 24 has not yet been released, but it's in active pretest and is readily available for most platforms.[1]. I've been using it since 23 was released and have had no trouble with it.

[1] It's not hard to compile from source, but precompiled versions are readily available for Debian-based systems, Mac OS X, and Windows.

in which static types are friends, not foes

2011-08-15T01:37:00Z

I'm a big fan of composability in user interfaces. Unix has traditionally been strong in this area with its culture of pipes and standard in/out, making it easy to chain together small tools with orthogonal purposes. Unfortunately this usually does not extend to GUI tools which often tend towards monolithic globs of functionality. There are a few exceptions, my favourites including xbindkeys and mpd.

The most versatile of these I've found has been dmenu, a graphical option chooser in the style of Emacs' ido-mode: it presents a list of options, and as you type it narrows to just the options which match the input that's been entered so far. I've built a number of tools on top of this including a music frontend to mpd and a script that allows me to perform a number of Skype actions from the keyboard.

The problem is that dmenu is pretty minimalistic compared to ido. The main annoyance to me is that it doesn't support flex matching—in other words, only exact matches are shown. In Emacs, ido lets me match a few characters against the front of the string and a few against the tail. Any input is accepted as long as it uniquely identifies one of the choices. Since dmenu is written in C I didn't exactly relish the idea of picking up skills in that language to add this functionality, so I wrote a replacement in OCaml instead:

let rec read_lines lines =
  try read_lines (read_line () :: lines)
  with End_of_file -> lines

let lines = read_lines []

let lines_matching pattern matched line =
  try let _ = Str.search_forward pattern line 0 in 
      line :: matched
    with Not_found -> matched

let escape = function
  | ' ' -> ".*"
  | c -> Char.escaped c

let pattern input =
  Str.regexp (String.concat "" (List.map escape input))

let matched input lines =
  List.fold_left (lines_matching (pattern input)) [] lines

let rec draw_matches matches =
  Graphics.open_graph " 1440x15";
  Graphics.set_window_title "erythrina";
  Graphics.draw_string (String.concat " | " matches)

let finish input lines =
  Graphics.close_graph ();
  match matched input lines with
    | f :: _ -> print_string f
    | [] -> ()

let butlast input =
  match List.rev input with
    | [] -> []
    | _ :: rest -> List.rev rest

let rec main input =
  draw_matches (matched input lines);
  match Graphics.read_key ()  with
    | (* enter *) '\r' -> finish input lines
    | (* escape *) '\027' -> Graphics.close_graph ()
    | (* backspace *) '\b' -> main (butlast input)
    | (* any other *) c -> main (List.append input [c])

let _ = main []

In 39 lines of OCaml I've achieved near feature-parity to the 700 lines of C that make up dmenu. The only missing features are tab-completion and font/color customization, though I have added the flex-matching feature mentioned above that dmenu lacks, which makes tab completion less important.

This is my second foray back into the land of static typing since university. (Supposedly I learned C++ in school, but I've long since mercifully forgotten it all.) I picked up Mirah last year and spent a little more time hacking in it earlier this year for an Android app. While Mirah is a huge improvement over Java, its type inference unfortunately only extends to locals, (a common shortcoming of most JVM-hosted type systems from what I gather) meaning if you tend to write small methods you end up specifying all your types anyway. OCaml on the other hand infers all types using Hindley Milner inference, allowing the types to be effectively invisible.

I've only spent a few days writing OCaml, but I've got to say I'm impressed. The type system stayed out of the way, only making a fuss when I'd clearly made an error. Pattern matching is a dream: you'll notice that all the conditionals in the code above come from match rather than if. It's fast, it's pleasantly interactive, (especially via tuareg and Emacs) and the executables produced by the compiler are tiny and quick to start, which is valuable for anyone who spends a lot of time on the JVM and is looking for something to fill those pesky gaps for which the JVM is admittedly lousy.

My only real complaints surround the fact that the standard library is slim and quirky. It throws exceptions in places you wouldn't expect, like hitting the end of the file while reading or searching for a regex when the text contains no match. The regex support is a bit odd, but that's not too surprising considering how old the language is.

Of course the standard library is augmented by a number of third-party libraries. It seems like up until recently it's been assumed that you'll use either apt-get as the main way to pull these in or run make install from source. As I've blogged about recently, apt-get is a bit of a drag for libraries that are obscure or change frequently. It looks like Oasis is making it easier to build projects while ODB is the beginning of a rich library dependency system, though it's still got a long way to go. My needs have been simple enough that I've been able to stick with the standard library for my current project, but it's great to see progress in this direction.

Anyway, it's always a bit disorienting to toss yourself into a new environment like this. But OCaml has proven to be quite a treat. I recommend starting with this OCaml Tutorial which also links off to many other helpful resources. Have fun!

in which an operating system makes trade-offs

2011-07-29T19:27:51Z

I've been a user of Debian's apt-get package manager for nearly as long as I've been serious about computers, and I love it. Going back to a system that lacked apt's depth and stability would be like having to write with my non-dominant hand or worse—going back to typing on a QWERTY layout. I have seamless access to everything I need[1], and it never breaks unless I do something crazy like add unsupported third-party repositories or run the unstable distribution. Who could ask for more? So I'm quite proud to see Leiningen getting packaged for Debian with lots of help from the Java Maintainers team.

It's interesting to get a look inside the sausage factory of packaging. The biggest hurdle for me as I was learning the ropes was that all the packaging introductions assume you are building a C program and have familiarity with makefiles. You can tell that the packaging culture has its roots in C, and packages from other runtimes feel a bit foreign.[2] Even more so with a language like Clojure... you're off into unexplored territory, blazing your own trail.

The biggest change from what I'm used to is the notion that only a single version of a package can be installed at a time. I think I understand the motivation here: it's crucial that when a security vulnerability is reported the affected packages and all those that depend on them have access to the fix. I'm used to developer-focused package managers that allow many versions to be installed side-by-side, but that places the burden of security updates on the developers using it since it's common for packages to depend on exact versions rather than allowing bugfix versions to sneak in. It's a lot more work to track down security issues, but this is not a big deal in the context of developer-centric systems since these particular users are less likely to mind having to pay attention to that sort of detail; it's what they're paid to do.

So there's a real tension here; end users want packages to just work and be safe without thinking about them while developers demand repeatability and control. Developers need the flexibility to choose exactly when they want to pull in new versions of libraries, while end users want things to hum along out of sight.

The problem is that the one-version-of-a-package-at-a-time policy doesn't always work in practice. Over time backwards compatibility is the exception rather than the rule; in many cases there simply is no substitute for having multiple versions of a package installed simultaneously. And apt's answer here is just to create a new package with the incompatible version number as part of the package name. There's no clue that these packages are related, and upgrades won't pick the new versions up. This is quite a shame, because I love everything else about apt. I look at complicated production deployment schemes and think to myself how much simpler things would be if deploying were just a matter of adding our internal apt repository and running apt-get install, but... versions.

Of course, these gripes are not really relevant to having Leiningen in Debian.[3] Users of Debian-based systems will be well-served by getting Leiningen through their OS, and once it's on their system, they're free to use it to solve their developer-centric problems. This plays to the strengths of each system, and everybody wins.

Update: Leiningen has been accepted into Debian.

[1] Except Emacs; that's the only thing I still build myself from source. Though http://emacs.naquadah.org looks like it delivers perfectly passable builds of 24 if you're not interested in any of the experimental branches.

[2] It's especially noticeable with Ruby and the JVM. Part of this is due to the fact that the JVM has only been free software for a relatively short period of time, and a lot of the existing culture around Java distribution goes against the grain of repeatable builds by ignoring source and shuttling binary bytecode around everywhere.

[3] And it's looking like it'll make it into Ubuntu 11.10 as well.

in which systems are captured

2011-06-29T15:42:38Z

When working on a project, I try to take care that a dev environment can be brought up with as little fuss as possible. This requires some discipline even with simple programs, but once you get into the realm of systems, more up-front effort is required for repeatability.

We've all been in the position of being the new hire on the team. On some teams you're lucky if you can get to actually running code on your machine in your first week. You think to yourself that it could surely be simplified, but once you're all set up there's not a lot of incentive to come back and make it easy for the next time.

It's easy enough to track language-level dependencies using Leiningen, Rubygems, or whatever is standard for your language, but very few large systems end there. You almost always have further external dependencies that are best handled by the system-level package manager, be they databases, message queues, or even your language runtime itself.

I've found the best way to make sure this stuff is kept up is to make it the status quo. At work nearly everyone develops in a VM, and when a new dependency is needed, instead of everyone having to hunt down and install it, it just gets added to the setup script. This reduces redundancy as well as helping to eliminate Works on My Machine issues.

Recently I've found Vagrant to be a really helpful tool for streamlining this process even further. Before I was using raw VirtualBox, which was all right for launching fresh VMs, though the interface was always a little awkward. Vagrant streamlines this greatly, making it trivial to configure, suspend, and rebuild VMs. It also helps keep the configuration of the VM alongside the project for which it's meant.

Vagrant allows you to provision new VMs with Chef. While this is pretty handy if you've already got recipes written, it's a bit intimidating as the mental model needed to operate Chef is quite baroque. But it's easy enough to bypass Chef and provide an arbitrary shell script as a provisioner. You need to take a bit of care to ensure the script is idempotent as it's much more useful if you can re-run it whenever the dependencies change, but it's a great way to get started.

There are a few gotchas. Vagrant is rather particular about what version of Virtualbox (and the VBox extension pack) you use, and reinstalling Virtualbox only makes it confused. The OSS edition isn't supported, but thankfully an apt repository is available:

$ sudo apt-add-repository "deb http://download.virtualbox.org/virtualbox/debian $(lsb_release -cs) contrib"
$ wget -q -O - http://download.virtualbox.org/virtualbox/debian/oracle_vbox.asc | sudo apt-key add -
$ sudo apt-get update && sudo apt-get install virtualbox-4.0
$ sudo gem install vagrant

On a related note, I've had had a couple people ask what a good project to get started with Clojure web programming would be. The most widely-used Clojure web app that I know of is Clojars, the community repository. But it's been pretty dormant recently; there are plenty of great features just waiting to be implemented, but getting it set up is hard work given all the moving parts.

Vagrant is perfect for smoothing this over. I've got a vagrant branch of clojars that makes it as simple as vagrant up (modulo a small issue with the nailgun scp server I'm still working out). So this should allow folks to contribute to the codebase more easily.

I've also helped out with Justin Lilly's Clojure/Emacs environment which provides a fully-configured Emacs 24 install intended to help facilitate our Seajure hackfests. Give it a try if you've had trouble configuring Emacs for Clojure hacking. And feel free to crib from these setups for automating your own projects.

in which radical simplification ensues

2011-05-17T04:02:23Z

While Emacs support has come a long way since I first got started with Clojure, I'm reminded every time I help newbies get set up that there are still way too many moving parts. This is in part due to the fact that things center around SLIME, a tool which was originally developed to work with Common Lisp. SLIME doesn't have stable releases; the developers expect everyone to run from CVS trunk (I wish I were joking), so I had to do some ad-hoc packaging just in order to prevent constant breakage. But synchronizing compatible versions between two separate package managers on two separate runtimes is a headache.

I've cooked up something much simpler for the next swank-clojure release:

[download video]

This makes it possible for a single piece of elisp to bootstrap an entire SLIME environment. It's also set up so it can be extensible—if a project like Slamhound wants to distribute an elisp library, it will be able to be loaded automatically upon connecting SLIME. The number of steps is reduced to three:

Install clojure-mode via Marmalade or from git.
lein plugin install swank-clojure 1.3.1
Invoke M-x clojure-jack-in from a project

The video uses swank-clojure 1.4.0-SNAPSHOT, which includes some new debugging features, but the most stable release (1.3.1 as noted above) will also work. Hopefully this eases a few headaches!

Update: Right now there are known issues with having multiple versions of swank-clojure present, both in lib/dev and ~/.lein/plugins, so check to make sure they aren't conflicting. This will be fixed in the next version of Leiningen. It's probably best to remove swank-clojure from :dev-dependencies in project.clj entirely and have each user who wants to use swank install it as a local plugin instead.

If you have issues, please post to the swank-clojure mailing list or open a github issue. Blog comments are a lousy place for bug reports.

in which a violent metaphor features prominently

2011-05-01T06:05:12Z

This past week I've had a lot of fun with Slamhound, my most recent project. Often times when writing Clojure, your namespace declarations are a pain to keep in order—you've got to specify all the namespaces you depend upon, and once you've got a lot of them in there, it's hard to keep them straight; often duplicates sneak in and things just get really messy. So Slamhound takes a source file, discards the namespace declaration, and tries to determine how to reconstruct it from the code alone. I had a lot of fun putting it together, so here's a little walk-through of how it works.

A big part of why it was so much fun is that the code is very functional. It takes a file as input, throws it into a pipeline, and spits out an answer. The only impure part is the reading of the file.[1] The pipeline is built in the slam.hound/reconstruct function:

(defn reconstruct [filename]
  (-> (io/reader filename)
      asplode
      regrow
      stitch-up))

But first a little back-story: Slamhound is named after the explosive device from William Gibson's novel Count Zero. At the start of the story, the main character Turner has an encounter with one, after which he spends three months in surgery while his skin and organs are regrown before he's stitched back together. Files in Slamhound go through the same process: asplode, re-grow, stitch-up. (I've quoted code selections inline, but for the complete listing a link is given for each phase.)

Phase 1: asplode

(defn asplode [rdr]
  (let [rdr (PushbackReader. rdr)
        ns-map (ns-to-map (read rdr))
        stripped-ns (apply dissoc ns-map [:use :require :import])
        body (take-while #(not= ::done %)
                         (repeatedly #(read rdr false ::done)))]
    [stripped-ns body]))

Like its counterpart in the book, the first phase is quick, simple, and messy. First we need to construct a PushbackReader in order for clojure.core/read to operate. This gives us the ns form as a list. Then in ns-to-map (not shown) we perform the translation into a map by splitting each clause (:use, :require, and :import) out, since the map form is a lot easier to operate on in during the regrow stage. But often times you have left-over clauses from earlier revisions, so we dissoc them out in order to start from scratch. Then we repeatedly read until EOF to get the body. The stripped ns and body are passed to the next phase.

Phase 2: regrow

(defn regrow
  ([[ns-map body]]
     (force pre-load)
     (regrow [ns-map body] nil))
  ([[ns-map body] last-missing]
     (if-let [{:keys [missing type]} (check-for-failure ns-map body)]
       (if (= last-missing missing)
         (throw (Exception. (str "Couldn't resolve " missing)))
         (recur [(grow-step missing type ns-map) body] missing))
       ns-map)))

The re-grow phase is where the pain-staking progress is made. The first arity forces the pre-load delay which ensures all the source is loaded for compilation purposes, then hands off to the second arity. There's a recursive loop here: we attempt to compile the body with the current ns-map in check-for-failure (see below.) If it fails, we analyze the problematic missing piece in grow-step, which searches for all possible candidates, sorts in disambiguate, and picks one. Then the compilation is retried by recurring.

Right now if the retry results in the same failure, it gives up, though there's no reason in the future it couldn't continue down the list of candidates. Of course, if compilation succeeds, the re-grow process is finished, and it returns the ns-map with the new clauses for the next phase, stitch-up.

But check-for-failure deserves special attention as it's where the meat of the process happens:

(defn check-for-failure [ns-map body]
  (let [sandbox-ns `slamhound.sandbox#
        ns-form (stitch/ns-from-map (assoc ns-map :name sandbox-ns))]
    (binding [*ns* (create-ns sandbox-ns)]
      (try
        (eval `(do ~ns-form ~@body nil))
        (catch Exception e
          (or (failure-details (.getMessage e))
              (throw e)))
        (finally
         (remove-ns (.name *ns*)))))))

Here we see that a unique sandbox namespace is created using auto-gensym. Next we reach ahead a bit into the next stitch-up phase for the ns-from-map function, which takes our map representation and turns it back into an executable ns declaration. Stepping into this sandbox namespace with binding, we attempt to eval the body. If it fails, we analyze the exception with failure-details. This tells us whether it was a :use, :require, or :import clause that caused the failure as well as the name of the missing class or var. These details are used by candidates to determine the ns-map for the next attempt.

(defmethod candidates :require [type missing]
  (for [n (all-ns)
        :when (= missing (last (.split (name (ns-name n)) "\\.")))]
    [(ns-name n) :as (symbol missing)]))

The candidates multimethod operates on each of the three clause types (:use/:require/:import), but they're all slight variations on the same theme. The :require version is given here: it simply loops through all the available namespaces and returns the ones which match the missing name from the compilation failure.

Phase 3: stitch up

(defn stitch-up [ns-map]
  (-> ns-map
      collapse-clauses
      sort-subclauses
      ns-from-map
      prettify))

Once we've got a successful compilation, we have what we need. All that's left is to turn it back from a map into code form, which is handled by the stitch phase. Technically only the the ns-from-map function we saw used above is necessary, but the ns declaration looks a lot nicer if you collapse all the clauses down first:

(:use [clojure.test :only [deftest]]
      [clojure.test :only [testing]]
      [clojure.test :only [is]]
      [clojure.test :only [are]])

;; after collapsing becomes:

(:use [clojure.test :only [deftest testing is are]])

Sorting subclauses doesn't hurt either, though it's strictly cosmetic. Finally we turn it back into code form and pretty-print it using clojure.pprint/pprint. And that's it!

1: Technically there's one exception to this; see if you can spot it.

in which secrets are kept

2011-04-01T03:03:55Z

Back when Leiningen was first launched it coincided with the launch of Clojars, the public community repository for Clojure projects. This worked out really well for Clojure as far as the timing was concerned—it allowed the ecosystem to grow quickly.

But Clojars doesn't work for everything; some situations call for libraries to be shared on a team without making them public. For cases like this it's necessary to publish to private repositories. This has been a really common question with Leiningen that hasn't had a good answer until recently; some folks bite the bullet and run lein install on every development machine while others set up shared static-file repositories maintained mostly by hand. At work we've nginx'd up a directory that gets deployed to from our Hudson (soon to be Jenkins) jobs.

But the 1.5.0 release of Leiningen has added the deploy task along with a deploy guide. Now you can deploy to private repositories like instances of Archiva and Nexus. Just configure your :repositories in project.clj with the URL and credentials for uploading:

  :repositories {"snapshots" {:url "http://blueant.com/archiva/snapshots"
                              :username "milgrim" :password "locative.1"}
                 "releases" "http://blueant.com/archiva/internal"}

If you're shy about checking passwords into project.clj, you can put them in ~/.lein/init.clj as mentioned in the deploy guide. Note that the naming is significant; if you are deploying a SNAPSHOT version, it will go to the "snapshots" repository, while stable versions will go to the "releases" repository. Hopefully this is useful for teams collaborating on multiple projects in private.

in which the local meeting celebrates a year

2011-03-01T05:08:38Z

This month marks the first anniversary of Seajure, the Seattle Clojure group. I've had a lot of fun conducting these meetings. It sounds like our group is a little different from the way most people run things, so I thought I'd write a bit about what has worked for us.

One thing I knew I wanted from the start was for meetings to be very code-centric. The Seattle Ruby group used to have talks regularly, and they found that in that kind of situation after a few months things usually fall into patterns of just having the same person present over and over.

So we focus on code instead. We try to come up with a small project that's somewhat useful on its own but not too ambitious to build in a couple hours. Everyone logs into a shared tmux session running Emacs and can all collaborate on the code as it's being written. Of course still only one person can type at a time, but it's a lot less hassle than having to set up a projector, and it's much more interactive.

This only really works because we have a small group; with larger attendance levels the group may need to be divided somehow. We have swarm-coding sessions for only about half of our meetings when we have a good idea for a project. Other times we'll just discuss new features of Clojure or specific tools; one meeting we had an Emacs workshop to get people started. We also spend about half an hour starting out just chatting and making sure everyone has been introduced.

Normally I stress the importance of keeping the same location consistently since people have an easier time planning for it if it doesn't shift around, but the coffee shop in which we hold our meetings is closing early for winter hours, so we're in the University District Trabant for our March meeting. If you're in the Seattle area, join the join the mailing list and come on by!