I first heard about Datomic shortly after it was initially released. I think I almost immediately went and read all of the documents that Relevance Cognitect released about it’s architecture. I was duly impressed, and really interested in using it. In particular, the potential for time-travelling was really interesting and exciting to me.

At the time I had been tasked with writing some code to determine usage metrics for our system. One of my boss’s hopes was that we could generate usage data from some time ago as well to compare with our current levels. Because we were using traditional relational databases and hadn’t planned for this use case, that turned out to be impossible. However, if we had been using Datomic, that back-dated query would have been absolutely trivial.

Since I’ve been an apprentice at 8th Light, I’ve been focusing on really trying to get TDD as a practice and a discipline. As part of that I’ve done a lot of reading and reflecting on past reading’s about TDD. One thing that jumped out at me about the way that Martin Fowler, Kent Beck and Bob Martin all talk about TDD: the all tend to say minorly self-deprecating things like: “I’m just not smart enough to hold all that complexity in my head. TDD helps me get away with not seeing the big picture.” But I think this statement is fundamentally misleading.

The first [problem] is stuckness, a mental stuckness that accompanies the physical stuckness of whatever it is you’re working on. A screw sticks, for example, on a side cover assembly. You check the manual to see if there might be any special cause for this screw to come off so hard, but all it says is “Remove side cover plate” in that wonderful terse technical style that never tells you what you want to know. There’s no earlier procedure left undone that might cause the cover screws to stick.

If you’re experienced you’d probably apply a penetrating liquid and an impact driver at this point. But suppose you’re inexperienced and you attach a self-locking plier wrench to the shank of your screwdriver and really twist it hard, a procedure you’ve had success with in the past, but which this time succeeds only in tearing the slot of the screw.

Your mind was already thinking ahead to what you would do when the cover plate was off, and so it takes a little time to realize that this irritating minor annoyance of a torn screw slot isn’t just irritating and minor. You’re stuck. Stopped. Terminated. It’s absolutely stopped you from fixing the motorcycle.

-Robert Pirsig, Zen and the Art of Motorcycle Maintenance

There is so much interesting material here it could take a while to dig into all of it.

At a high-level, when storing secrets like passwords, the standard best practice is to never store the plain-text version of the password in the system. Instead, you store some information that is uniquely and repeatably derived from the password in an irreversible fashion. This is often called a “digest.”

This preserves the ability to check whether someone has entered the correct password for an account in order to authenticate them (you simply recalculate the derived value and check those for equality), but it prevents an attacker who somehow obtains the password digest from immediately having access to the plain-text version of a user’s password. That’s the process at a very high-level.

I’ve been reading Domain Driven Design by Eric Evans for the past month or so, and thinking about the ideas and concepts in it has been consuming a lot of my mental space and time. One thing in particular that I’ve found to be really interesting is his concept of developing a Ubiquitous Language for the project.

At a very high level, the idea of having a Ubiquitous Language for a project just means that there is specific vocabulary and jargon that is used to describe certain key concepts about the domain of the project and the particular implementation that the team is developing. Or to put it even more simply, that when someone on the team uses a word or a phrase, everyone else knows what they are talking about.

Last week I spent quite a lot of time working closely with my a fellow apprentice on refactoring a Rails application away from direct usage of ActiveRecord for data persistence, and towards some incarnation of the Repository Pattern. Now that we’ve finished, I thought some reflection on the different possible implementations that we considered, and what we ended up implementing might be in order.

I’m coming up on the end of my first iteration at 8th Light where I was asked to estimate how long each of my stories was going to take. For the three stories that make up the majority of converting my rack Tic-Tac-Toe from a multi-page vanilla HTML/CSS app, to a SPA (Single Page App) that uses AJAX to communicate with the server I came up with a total of about 11 points. Given that at 8th Light we want to be nominally doing about 9 points per week that meant that I estimated it would take me just a touch over one iteration to complete that transformation. But looking at it right now, I don’t think I’m on track to meet that goal.

I’ve been reading an excellent book recently: Domain Driven Design by Eric Evans. I just finished the section on Entities and Value Objects, and it’s caused me to start thinking about Clojure and the “sane state management model” that language advocates/enforces.

For the past two weeks or so I’ve been grappling with trying to build a simple HTTP front-end for my ruby Tic-Tac-Toe program. There have been some non-technical hurdles with scheduling and other projects demanding my time, but I’ve also spent a fair amount of time simply struggling to put the pieces together with how the Rack libraries work.

A Note about version numbers

At the time of this writing, there were several newer versions of many of the dependencies used in Chestnut. In particular, the ClojureScript core team had fairly recently released a new version with vastly simplified REPL setup requirements which triggered changes to many of the related ClojureScript tooling libraries (Piggieback, and Weasel especially). So PLEASE! Use the latest version of Chestnut, or if you’re setting up your own project then look up the latest versions on Clojars

On to the Annotating!

As I wrote recently, I recently dove head first into doing web development with Clojure and Clojurescript. Along the way I learned a whole heck of a lot about how to actually set up a Leiningen project to support a nice workflow for such a project. However, most of my new-found knowledge has already been put together into a very nice package called Chestnut. However, at first glance (and second and third glance really) Chestnut projects are complex and intimidating.

This post is an annotated walkthrough of the configuration that a new Chestnut comes with. The best way to follow along would be to start off by running lein new chestnut tour in shell and then exploring the files as I talk about them.