We are hiring a ClojureScript developer in Africa

The InGrower Mobile App has been put to the test in the hands of a few smallholder chicken farmers in Mozambique since January 2016. We have learnt what's needed and is proceeding to the next stage of development. That's why we're looking to hire a ClojureScript developer to build the next version of our mobile app.

One of my longer term goals is to grow a distributed technical team in East Africa that can tackle various social impact challenges in the region. This first hire will play an important role in setting the direction for the team.

Link to job description

InGrower Mobile is a side business that I've been working on since September 2015. We are an early stage social enterprise in the I.C.T. for Development (smallholder farming) space. InGrower Mobile came about from my co-founder's experience operating an agri-business incubator in Mozambique since 2010. We admit unemployed individuals, then provide training and support to help them start their own agriculture business to make money. For InGrower Mobile, our product is a mobile application that takes what we learned from the past 7 years running our agri-business incubator and applying them online to make our training and support available for a wider audience across East Africa.

Posted 29 May 2017 in startup.

Simple, easy, quick: using Go along with Clojure

We had questions about how Go compares with Clojure at the Boston Clojure Meetup earlier this week. My default answer to any this-vs-that technology debate is -- it depends. But it just so happens that our backend system at Glassy Media consists of an even split of services written between Go and Clojure. However, this isn't due to any technical reasoning. It’s just that using the two languages together feels right for our particular needs.

Rich Hickey made clear the distinction between simple and easy in his famous talk, Simple Made Easy. Clojure makes simple easy. But sometimes I don't want simple and easy. I want quick and easy. That is exactly where Go comes in to complement Clojure.

Simple, Easy, Quick

How Clojure made simple easy is a path well-beaten. The rest of this post is about why I think Go is quick and easy.

Our path to Go

Once upon a time (i.e. a few months ago) our backend cogs and gears consisted of a bunch of command line programs that we would run on our laptop every now and then to churn our data. We then distributed those tools to our non-developer helpers to serve our clients. Those command line tools started out in Python or Node.js. But distributing, maintaining, and updating those programs to other people's laptops eventually became a real pain. So one weekend I rewrote one of our command line programs in Go. On the Monday, I shared a link to a single executable file on Dropbox and people were able to run it directly from there. No more asking people to go on command line and typing pip install or npm install. That was how we started using Go at Glassy Media.

I had no prior experience with Go before that. The fact that I was able to learn the language and then produce something useful over a weekend was not to my credit but lies in the smart tooling, the clear documentation, and the practicality of the language. These features make Go easy to ramp up.

Language Practicality

Take the for loop as an example, you can iterate over a map like so. (code sample taken from Effective Go)

for key, value := range oldMap {
    newMap[key] = value

The same range can be used to iterate over an array:

sum := 0
for _, value := range array {
    sum += value

No need for additional syntax to do the same thing. And there are no while or do loops either. for, alone does all of that, as shown:

// complete `for` struct
for init; condition; post { }

// only check condition like a `while`
for condition { }

// or, nothing like a `do`
for { }

The Go core syntax is consistently minimal like this.

Clear Documentation

From The Go Programming Language,

 The Go project takes documentation seriously. Documentation is a huge part
 of making software accessible and maintainable. Of course it must be
 well-written and accurate, but it also must be easy to write and to
 maintain. Ideally, it should be coupled to the code itself so the
 documentation evolves along with the code. The easier it is for
 programmers to produce good documentation, the better for everyone.

Go's source code documentation has simple convention and automatic publishing. Take our trivial go-arrays library for manipulating arrays. Here is one of the functions and its docstring:

// Contains check if 's' is in 'coll' string array
func Contains(s string, coll []string) bool {

What's amazing is that a corresponding project documentation page is automatically scraped from our source code and hosted on GoDoc.org with no extra work needed on our part. So as soon as you push a project onto Github, you can request your project documentation on GoDoc.org website. Here is a screenshot of one:

Godoc.org for go-arrays

Because software documentation is baked into the process, I find most of the Go libraries are less frustrating to pick up.

Smart Tooling

I don't know why GoFmt isn't more common in programming. GoFmt is a tool that automatically formats Go source code. It is like jshint or pyflakes but goes a step further and actually fixes your code styling for you too. No more gg=G in Vim.

Consistent source code styling makes life so much easier when digging into other people's projects.

Overall, I enjoy the workflow developing in Go. There is no interactive REPL. What you get is an almost instant go test and go run execution time. After doing everything in Vim, switching between my editor and the command line isn't as annoying as I would have expected.

One reason for this relative ease is that the workflow is different when developing in Go. GoFmt is integrated in Vim (and other typical editors). A second reason is that Go is statically typed, by the time when your code passes GoFmt without error, most of the time it would work as expected. So it's not very often that I need to resort to doing go test to check my code.

Go for web services

Having had Go in production for only a few months, our experience with it is limited. Still, what stands out most with Go is using it to build web services. Take our SMTP callback verification service, for example. The HTTP server code for it is under 50 lines using go-json-rest and a couple core packages. Not only that, Go has mock HTTP server testing functionality built right in.

I am aware that this is subjective. But having used a handful of languages and frameworks to build RESTful web services, Go is by far the easiest for getting a server up and running.

Complementing Clojure with Go

The one time I had to choose between Go vs. Clojure was when the Boston Go Meetup happened on the same night as the Boston Clojure Meetup.

Otherwise, there is no reason why Go and Clojure can't work alongside each other as part of a toolset suite.

Everyone has their tools of choice. Your taste and circumstance are probably different from mine. What matters is that the tools in your toolbox fit the problems that you face. Go and Clojure each answer different needs for us.

Posted 12 May 2014 in computing.

Event-driven finite state machine for a distributed trading system

One problem I had when building my distributed trading system is managing states asynchronously from multiple triggers. For example, when the alpha engine say buy, it needs confirmation from the position engine to see if it is safe to enter a new position. I could chain one check after another imperatively or via callbacks. However, the underlying constraint is that these triggers:

  1. are resource-intensive to generate,
  2. might need to compose many of them,
  3. not sequential or have one-to-one depencency, and
  4. most importantly, they are in separate programs or different machines

Thus I've opted to abstract this problem out into its own module of the system as an event-driven finite state machine (FSM) to keep track of state transitions. Intimidating term, but my first implementation was just if-else statements to qualify as such. The benefit is that each of my system's components only need to push signals and pull states from a central interface without having to worry about what should it call next or poll anything else to see if the stars are aligned. That drastically simplified development and maintenance.

The responsiblities of my FSM module are to:

  1. listen to all the signals,
  2. figure out all the transitions, and
  3. publish the latest states for the rest of the system.

Handling asynchronous events

I use RabbitMQ as the message transport layer between my system's modules. All I need to do here is to associate an appropriate message handler to each triggering input for the FSM. Here's one example of the event handlers using the Clojure RabbitMQ library, Langohr. The rest of this part are just standard RabbitMQ publish/subscribe stuff.

(defn- event-message-handler [ch {:keys [headers delivery-tag redelivery?]} ^bytes payload]
  (let [{:keys [message-type user-id instrument quantity]} (read-payload payload)]
    (when (= :position-event message-type)
      (-> (get-cached-states user-id)
          (update-position-state instrument quantity)
          (cache-states user-id))))
  (lbc/ack ch delivery-tag))

This is called when a position event is received with information such as user, instrument, and quantity. This handler would thread these information by fetching current states for that user, evaluate next state with input, and then cache the new states for the user.

State transitions

Below is one of my system's state transition diagrams.

state transition example

There are 4 states represented by 4 colours with 4 triggers signalling state transition. The program is expected to handle up to hundreds of independent states concurrently with event triggers coming in a couple times per second.

As I was saying, my first implementation is just a set of if-else methods. For example, an engage trigger would call the engaging method to determine the next state given the implicit input engage and current state.

(defn engaging
  (condp = current
    "white" "yellow"
    "yellow" "white"
    "green" "red"
    "red" "green"))

There were a handful of these boilerplate code. So after I deployed my system I came back to refactor them. I've been meaning to give core.logic a try for a while so this seem like a good place to start using it.

Before we can ask the logic solver question we need to define relations. Here I define a transition relation to specify all the state transition definition conveniently in one place.

(defrel transition from input to)
(facts transition [[nil :open :green]
                   [nil :close :white]
                   [:white :engage :yellow]
                   [:white :disengage :white]
                   [:white :open :green]
                   [:white :close :white]
                   [:yellow :engage :white]
                   [:yellow :disengage :white]
                   [:yellow :open :green]
                   [:yellow :close :yellow]
                   [:green :engage :red]
                   [:green :disengage :red]
                   [:green :open :green]
                   [:green :close :yellow]
                   [:red :engage :green]
                   [:red :disengage :red]
                   [:red :open :red]
                   [:red :close :white]])

And the event handler methods are just wrappers for a one-liner logic expression asking the question -- given current stage, cur-state, and input trigger, input, what state can q take to satisfy this constraint?

(defn next-state 
  "Solver for next state"
  [input cur-state]
  (first (run 1 [q] (transition cur-state input q))))

(def colour-clicked (partial next-state :engage))
(def colour-deactivate (partial next-state :disengage))
(defn next-position-colour [cur open?]
  (if open?
    (next-state :open cur)
    (next-state :close cur)))

Not the most illustrative core.logic example but it does the job.

Getting started with core.logic is surprisingly easy. I went through the Primer and tutorial and got this working in one try.

State caching and sharing

Now that the state transition have been taken care of, states are cached and served on Redis for other parts of the system. I use Redis for this because it is fast and easy. Values are stored in edn format instead of something more popular like JSON to maintain data structure through the wire.

This is my first time using edn in production. All inter-process messages in this trading system are edn formatted. It works seamlessly with Clojure by simply using str to write and clojure.edn/read-string to read. Besides my other Clojure components in the system, my trade broker interface is written in Java. My Java program use edn-java to parse and unparse complex Clojure data structures (e.g. nested maps with keywords).

(def pool         (car/make-conn-pool))
(def spec-server1 (car/make-conn-spec))
(defmacro with-car [& body] `(car/with-conn pool spec-server1 [email protected]body))

(defn get-cached-states
  "Generate edn from database."
  (edn/read-string (with-car (car/get (str "states:" id)))))

(defn cache-states [m id]
  (with-car (car/set (str "states:" id) (str m))))

I find coupling edn with Redis is a fantastic choice as it's almost like working with Clojure's native concurrency data structures, such as atom, but also enable external programs to access the data.

Simple and quick

The entire event-driven FSM program is less than 200 lines of Clojure code and took no more than a few hours to do. However, I did give it some pondering time for a few days. I haven't done any benchmark to estimate performance result. So all I can say is that this setup can handle my simplistic use case with barely any load on the server so I'm happy with it.

A few years ago, I would have set a whole bunch of flags to switch states. In fact, that's what I did. The biggest satisfaction here for me isn't the implementation or technologies, it is seeing through the underlying problem at hand and solving it with a common pattern that made my work simpler.

Posted 20 May 2013 in computing.

Unlock Lisp sorcery in your data structure by implementing Clojure ISeq

People that has gone through The Little Schemer might not find this exciting. One of the things that I discovered while patching Clatrix is that implementing clojure.lang.ISeq interface in your custom data structure unlocks the magic of Lisp composition. By enabling primative operators such as first, next, more, cons, higher-level operations such as map and reduce would just work when operating on your data structure. I find it fascinating that a native Fortran matrix object (through jBLAS) can be made clojury with a few magic operations implemented.

However, getting a deftype implementation of Matrix correct took some effort as these operators are not as simple as they seem.

public interface ISeq extends IPersistentCollection {
    Object first();
    ISeq next();
    ISeq more();
    ISeq cons(Object o);

For example, say we have a matrix M like so.

=> (def M (matrix [[1 2 3] [4 5 6] [7 8 9]]))
=> M
A 3x3 matrix
1.00e+00  2.00e+00  3.00e+00 
4.00e+00  5.00e+00  6.00e+00 
7.00e+00  8.00e+00  9.00e+00

Reducing M across its maps is equivalent to a column-wise operation.

=> (reduce #(map + %1 %2) M)
(12.0 15.0 18.0)

Yet for a while this doesn't work because I wasn't careful on my implementation of first.

Consider the case of a 2x2 matrix. A 2x2 matrix is structurally equivalent to a nested vector. Calling first on these would yield:

=> (first [[1 2] [3 4]])
[1 2]
=> (first (matrix [[1 2] [3 4]]))
A 1x2 matrix
1.00e+00  2.00e+00

And for a 3x1 vector matrix, i.e. one-dimensional, it is equivalent to a regular vector.

=> (first [1 2 3])
=> (first (matrix [1 2 3]))

But here's a tricky bit. What happens during reduce as it keeps recurring next and first?

Let's step this through for (reduce #(map + %1 %2) M). %1 is basically the result so far and %2 is the first of the remaining collection to be processed.

iterationaccumulated (%1)first (%2)remaining
0nil[1 2 3][[1 2 3] [4 5 6] [7 8 9]]
1[1 2 3][4 5 6][[4 5 6] [7 8 9]]
2, bad[5 7 9]7[[7 8 9]]
2, good[5 7 9][7 8 9][[7 8 9]]

The problem arises in the second iteration. Calling (rest [[4 5 6] [7 8 9]]) returns [[7 8 9]]. However, (matrix [[7 8 9]]) is a row vector and (matrix [7 8 9]) is a column vector. Both are considered one dimensional. In either case, first of a vector should return the first element, which is a number. Thus at this iteration, reduce breaks because you can't map a sequence with a number, (map + [5 7 9] 7), to get an accumulated value.

What we want though, is for the second iteration to return [7 8 9] instead because the original matrix is not a vector. Luckily, this particular problem has been solved by my colleague Antonio Garrote when he did this in Java a year ago by keeping a predicate field signifying is this matrix supposed to be vector or not.

So there you have it. If you find yourself needing to implement deftype to build your own data structure in Clojure. Do consider implementing clojure.lang.ISeq to leverage high-level Clojure functions but be careful about those seemingly simplistic primitive operators.

continue   →