Recently, I put together a Ruby script to update a bunch of poorly formed HTML fragments into clean XHTML fragments.

My initial naive implementation used Nokogiri’s DocumentFragment class to parse the HTML and output XHTML. This approach worked fairly well for cases that involved tags that were not properly closed.

However, in other cases, like RHTML and Javascript, this approach proved too aggressive.

Next, I tried Hpricot.

This is a little better, but the Javascript is still not properly escaped so the result is not XHTML compatible.

Finally, I tried Tidy. In this implementation I used the command line tool directly.

Tidy solved all my problems!

In a New York Times article on lean startups, Steve Lohr describes how VC-scale money (say $5M) can isolate a startup from potential customers. The idea of a lean startup is to get a minimal viable product in the hands of customers as quickly as possible, learning as you go and adapting the product to find what customers really value. Agile software development practices support doing exactly that, and are a key component of the lean startup approach.

This is the approach Atomic has been preaching and applying for years with our startup customers. When you live and work in the Midwest you don’t often meet VC-funded startups. Our entrepreneurial customers are self-funded or angel-funded. The Common, Circle Builder, Realius and most recently Bloomfire are Atomic customers that exemplify the lean startup approach.

Reducing the cost of a startup from $5,000,000 to $500,000, assuming similar success rates, should ultimately create 10x the value. That would be significant for our economy and the pace of innovation. It makes me wonder… is there another order of magnitude improvement possible here? Can we take the next step to the $50,000 startup? Does first building a $50k application increase the success rate of $500k startups? Or does $50k just get you a prototype, not a company?

I don’t know all the answers to these questions, but I do know we’re wrestling with them every day. Maybe I should be smart this time and think of some good branding for the $50k startup. How’s “shoe-string startup” sound?

One of the things I find myself yearning for in a lot of programming languages is a powerful pattern matching system. I wrote one for ruby, but ruby's syntax just wasn't flexible enough to make something as elegant as I'd like. When I started using clojure, it seemed like a great little project for getting to know clojure's macro facilities as well as clojure itself. I set out to build a kickass pattern matching library for clojure that fit in with the language's way of doing things and was at least as expressive than any other pattern matching facility I've used.

The outcome of this effort, is matchure (github, clojars), a pattern matching library for clojure featuring

• equality checks,
• sequence destructuring,
• map destructuring,
• regexp matches,
• variable binding,
• "instance of" checking,
• arbitrary clojure expressions,
• and boolean operators (and, or, not).

All of which compile down to high performance clojure.

Introduction

Clojure, like most lisps, has a built-in facility which gets you part of the way there: destructuring in most variable-binding contexts. For example,

1
2
3

(let [a 1]
  a) 
; returns 1

binds 1 to the variable a. You can just as easily grab the first value out of a sequence:

1
2
3

(let [[fst & rst] (list 1 2 3)]
  [fst rst])
; returns [1 (2 3)]

This facility is even more powerful. You can also destructure maps as well. There's just one problem: let doesn't work well as a way of testing values.

1
2
3

(let [[fst & rst] (list)]
  [fst rst])
; returns [nil nil]

This is, in part, why I wrote matchure. Matchure provides a pattern matching facility that makes it really easy to perform complex tests against values and bind parts of them to variables.

Syntax and Examples

Like any lisp, clojure is homoiconic - clojure code is represented by clojure data structures. Unlike other lisps, however, clojure has a rich set of data structures with literal representations. '(1 2 3) is a linked list, [1 2 3] is a vector, with fast random access, and {:a 1, :b 2} is a hash map. Furthermore, these syntaxes have special places within clojure itself. Lists are clojure function or macro calls and vectors are used anywhere variables are bound or sequences are destructured. Aside from being a literal representation in code, the hash syntax is used for destructuring maps in let bindings.

Matchure takes this rich set of literal representations and uses it as a natural way to match patterns. At the moment, there are three main forms, if-match, when-match, and cond-match. They work similarly to the clojure built-ins, but match values.

At the most basic level, matchure can be used to test for equality.

1
2
3
4
5

(if-match [nil nil] true) ;=> true
(if-match [1 1] true) ;=> true
(if-match ["asdf" "asdf"] true) ;=> true
(let [s "asdf"]
  (if-match ["asdf" s] true)) ;=> true

Regular expression literals test for a match

(if-match [#"hello" "hello world"] true) ;=> true

and fully qualified class names test for instance? relationships.

1
2

(if-match [java.lang.String "foo"] true) ;=> true
(if-match [java.lang.Comparable "foo"] true) ;=> true

Matchure supports _ and ? as wildcards, so both of these match anything

1
2

(if-match [_ "foo"] true) ;=> true
(if-match [? "foo"] true) ;=> true

_ is idiomatic in clojure when you want to ignore a value. In matchure, ? has special meaning. ? can be thought of as "the thing this part of the pattern is matching against". As such, ? always matches successfully. It is also used in binding variables. ?foo matches successfully and stores the matched value in the variable foo.

(if-match [?foo "bar"] foo) ;=> "bar"

just like regular clojure, list literals represent clojure code. Here, too, the special meaning of ? comes into play. You can perform arbitrary tests this way using ? to represent the matched against value:

(if-match [(odd? ?) 1] true) ;=> true

Just like with let, you can destructure sequences

(if-match [[?fst & ?rst] [1 2 3]] [fst rst]) ;=> [1 (2 3)]

and maps

(if-match [{:foo (even? ?)} {:foo 2}] true) ;=> true

Finally, unlike any other pattern matching facility I've seen, matchure has support for boolean operators.

1
2

(if-match [[(and ?fst (even? ?)) & ?rst] [2 3 4]] [fst rst]) ;=> [2 (3 4)]
(if-match [[(and ?fst (even? ?)) & ?rst] [1 2 3]] [fst rst] :failed-match) ;=>:failed-match

or and not are also supported.

You can get the code from github, or use it in your clojure project by grabbing it from clojars.

Without digressing into a discussion of object-oriented versus procedural programming, we can at least admit that “one size” does not fit all. In any event, use the paradigm which best applies to the problem you are trying to solve. With that said, in the cases where we want to write procedural code, how can we test it? With RSpec, this is not really much different than testing objects.

When the time came to create our newest company t-shirt, one atom thought it would be cool to include some fun and/or telling statistics about our company, such as the number of bikes owned while working here (41), index cards used (11,294), and cups of popcorn popped (lots). I immediately thought of an interesting info-graphic I had seen during my college days.

When I was a philosophy student at Calvin College, I remember seeing a chart that displayed all the philosophers who taught in the department over the years. It was an efficient and visually compelling (and thus memorable) representation of what would otherwise be a series of boring range dates. In an instant, this chart showed periods of department expansion, faculty members with particularly lengthy or short tenures, and snapshots of entire departments within a given year.

In a moment of serendipity, that very weekend Karlin came across a certain “Chart of Biography,” created by Joseph Priestley, a British polymath who lived in the latter eighteenth century. The chart, which dates to 1765, contains the names of 2000 figures of history on an ambitious 3,000 year timeline (1200 BCE to 1800 CE). Below is the redacted version.

We decided to use this as an inspiration for our t-shirt back. We wanted to include the names of atoms anyway, and it fit perfectly with the shirt’s statistical bent. I’m not sure what it means to have a “specimen of a chart” of anything, but we decided to stick with the original language; after all, the language, script and style evoke a sort of Enlightenment charm that resonates with our company name. The gaps indicate that an employee left and then came back, or had three or four internships before finally joining the molecule (as is the case with Andrew W). Here is the t-shirt on Kyle.

Hi, I’m one of the new guys at Atomic Object. Now that we’ve met, I’d like to share a discovery I’ve made in my first weeks of working here.

One of the lessons learned from the movie Office Space is that we aren’t meant for cubes. Atomic Object employs this lesson very well. There are no cubes! The “office” is almost exclusively located on the second floor and consists of groups of tables and chairs.

This wasn’t so much a shock as it was a relief. Prior to working for Atomic Object, I worked in a cube. Anytime I needed to work with another developer, or discuss a matter with a project leader, it consisted of navigating a maze of cubes only to discover that the individual I was looking for wasn’t even sitting at their cube. Depending on how urgent the issue was, locating the individual often meant walking up and down each row, and even then there was no guarantee of success.

Cube life was further complicated by the fact that we never switched or moved cubes. Rather than encourage knowledge transfer, this creates islands of information. New ideas are slow to spread, and the assistance from the person who is effectively permanently located next to you diminishes with time.

While an open environment continuously engenders collaboration, there is a possible downside. It could be difficult to focus on a particular task depending on the ambiance of the room. I have discovered that this isn’t as much of a problem as it might first appear. When I am focused on a task, I am practically oblivious to what is going on around me. It’s only when I encounter an obstacle that I start to take note of what is happening. I believe that if I am struggling with a problem so much that it breaks my focus, it is time to collaborate with others and find a solution together.

Related post: Benefits of an Open Office Environment

Designing with film:

In these experiments we designed and invented spaces, objects, movements and audiovisual techniques that map and visualise the interactive phenomena of RFID. Many of the visual/cinematic concepts for Nearness and Immaterials were invented by exploring and experimenting with film.

Rather than investing time in creating complex software and hardware prototypes, the interactive experience can be quickly explored inside film compositing applications. These experiments have shown us that there is great value in having tools that offer efficient prototyping of interactions at an experiential level, that don’t need to rely on complex electronics or physical design. There is also value in working within a medium that is not tied to a specific location or a unique demonstrator, and that is editable, reproducible and transmissible allowing it to be shared freely and widely amongst a research group and across the internet.

The sample videos, in my opinion, aren’t particularly compelling. That said, the essential idea itself has a good deal of merit—use digital video and post production tools to mock up concepts, interactions, and experiences.

Post production video tools are powerful. Design experiments in video could provide rich, meaningful feedback and move far beyond 2D, static mock ups. Creating the video itself is an exercise in working through the essential design challenges. Because it’s video there is opportunity to confront issues like transitions and movement of elements that is difficult to do with static mock ups. Using this approach could apply equally well to user interface development and physical product design.

Apple introduced closure support with the release of Snow Leopard. Plausible Labs has since created a framework and a drop-in runtime that provides closure support for both MacOS X 10.5 and the iPhone SDK. Closure support is a fundamental and important change to the Objective-C language. Functions are now first-class citizens in the runtime environment; they can be saved, copied, and passed around just like any other object.

That being said, much of the existing API in both MacOS X and the iPhone SDK rely on callbacks, selectors, and delegate patterns to cope with lack of first-class functions. But don’t let that stop you from using closures. It is relatively easy to create small intermediary wrappers that bridge the gap between callbacks and closures.

This week one of our customers asked us to create a small, single-purpose tool to help support one of our JRuby desktop applications. The requirement was simple: make it easy to input minimum, maximum, and beta values into a beta distribution function for a few thousand samples and visualize the results.

After a few hours of work we produced this:

1. We brought in JFreeChart, a powerful, yet easy-to-use charting library for Java.
2. We used the beta distribution functionality from the Bayesian Logic (BLOG) Inference Engine project.
3. We had prior experience with these two libraries from our JRuby projects.
4. The NetBeans visual Swing editor made it trivial to get some simple widgets on the screen.
5. As always, JarJar Links allows us to distribute this application as a single jar file.

Factor #1, JFreeChart, is far and away the most significant. Our experiences with JFreeChart are all positive: getting data into a nice looking chart has always been straightforward. The API is relatively easy to work with in that it strikes a good balance between configurability and getting a chart on the screen with minimal hassle.

The next time you’re looking to visualize data in your JRuby or Java application, don’t overlook JFreeChart.