Clojure utility functions – part I

Cross-posted from Zolo Labs.


I kept using an extra line of code for this, so I decided to create the following function:

(defn domap [function coll]
(->> coll (map function) doall))

view raw
hosted with ❤ by GitHub

Another extra line of code can similarly be removed using this function:

(defn doeach [function coll]
(doseq [c coll]
(function c)))

view raw
hosted with ❤ by GitHub

Obviously, the raw forms (i.e. using doseq or map) can be far more powerful when used with more arguments. Still, these simple versions cover 99.9% of my use-cases.

I keep both these (and a few more) in a handy utils.clojure namespace I created for just such functions.

Product/Market Fit to include a minimally viable business

(Via Zolo Labs)

Product/Market Fit to include a minimally viable business:

Yesterday, Siva and I had coffee with Bradford Cross, the co-founder of Prismatic. We caught up on all the things we’re up to recently, mainly about the startups we’re involved with. As you’re probably aware, he’s doing amazing work at Prismatic, and they’re totally blowing up. He had a ton of great advice for folks getting started on new stuff, but here’s one thing that really stood out.


For some context, distribution is the answer to the question of “what is the plan to acquire users?” The typical Lean Startup process focuses first on product/market fit, and you don’t worry about scaling distribution until you actually have something that users get value from. Which makes sense; if you don’t have a product that delivers value to at least some people, you can’t have a viable business.

However, Brad’s point was that that is rather late in the process to start thinking about distribution. Folks should be paying attention to distribution right from the beginning, even during MVP development. One part of that is thinking about your voice and your conversation with your potential audience, your outbound marketing, campaign-based user-acquisition, and so on. But it also means planning (and maybe even implementing) features for your product that can organically increase sign ups. 

The common feature people add to address this (and in fact, hope to become “viral” from it), is social publishing and sharing. The problem with this is that there is too much of it – most applications let you share/invite others, and the question becomes why anyone would want to do this with your product. And why would the person on the receiving end even care.

The  answer is obvious – in order for there to be a successful outcome, there needs to be explicit value to both sides. It is your job to figure out what these features are for your product.

Minimal Viable Business = MVP + Distribution

So here’s the bottom line: it’s as important to figure out your product/market fit as it is to figure out that you have a viable (scalable) business. After all, you may have a lifestyle business, and just not know it. By thinking about this  as early in the game as possible, you’ll be better positioned to plan a blow up.

Tagged: distribution, mvp, startup

Make it right, then make it fast

Cross-posted to Zolo Labs

Alan Perlis once said: A Lisp programmer knows the value of everything, but the cost of nothing.

I re-discovered this maxim this past week. 

As many of you may know, we’re using Clojure, Datomic, and Storm to build Zolodeck. (I’ve described my ideal tech stack here). I’m quite excited about the leverage these technologies can provide. And I’m a big believer in getting something to work whichever way I can, as fast as I can, and then worrying about performance and so on. I never want to fall under the evil of premature optimization and all that… In fact, on this project, I keep telling my colleague (and everyone else who listens) how awesome (and fast) Datomic is, and how its built-in cache will make us stop worrying about database calls. 

A function I wrote (that does some fairly involved computation involving relationship graphs and so on) was taking 910 seconds to complete. Yes, more than 15 minutes. Of course, I immediately suspected the database calls, thinking my enthusiasm was somehow misplaced or that I didn’t really understand the costs. As it turned out, Datomic is plenty fast. And my algorithm was naive and basically sucked… I had knowingly  glossed over a lot of functions that weren’t exactly performant, and when called within an intensive set of tight loops, they added up fast.

After profiling with Yourkit, I was able to bring down the time to about 900 ms. At nearly a second, this is still quite an expensive call, but certainly less so than when it was ~ 1000x slower earlier.

I relearnt that tools are great and can help in many ways, just not in making up for my stupidity 🙂