https://alexkappa.com/Ghost 0.5Tue, 26 Sep 2017 21:32:09 GMT60Recently I've been working on a Trie implementation and I was a surprised and delighted from the simpicity of the data structure.

The first time I came across the Trie data structure, I was looking to solve a problem where a typeahead field had a really large dictionary to query and would chocke every time the search was triggered. After stumbling upon John Resig's JavaScript implementation I wanted to see how it would translate in Go.

So without further ado, I'd like to share with what I found interresting about the Go version.

The data type

type Node map[rune]Node

Using self-referential type definition we are able to describe our tree nodes with nothing more than just built-in types.

Building an index

Some parts are omited from the following example but this is where the magic happens.

Notice how we walk down the tree for every rune in the string with node = node[r].

You've probably noticed the node.End() near the end. This inserts an invalid UTF8 character at the current node marking the end of a word.

Search

Searching is as simple as walking down the tree matching each letter in the search term to a key in each node. When we reach the end of the search term we have found a match, so the string indexed by the current node plus the strings from all its child nodes should be returned as results to the query.

The code is available on GitHub and the API docs at the usual place. I would love to hear your feedback. Enjoy!

]]>https://alexkappa.com/go-trie/9477e2d5-343a-4105-ad76-91fdea14f36eSat, 03 Jan 2015 20:41:22 GMTI've been hearing a lot of positive feedback about Google's new programming language for some time now. Interfaces, simplicity, concurrency are some of the things you will definitely hear being praised as you get involved with the community.

However my favourite thing about the language is something that isn't your typical praising point. Testing is often one of those things you know you need, but keep neglecting because it isn't easy and it's value is not immediatelly clear from a business perspective.

During my short career in making software, I found that people really struggle when it comes to testing their code. I struggled myself when faced with the intricacies of testing object oriented code. The concept of test stubs and mocks was something that is challenging to most newcomers.

Testing in Go is remarkably powerful and it promotes high quality testable code by making it extremely easy to write tests. Now I'm not going to go through the elementary hello and test_hello introduction, rather start off with something that probably most Go developers have worked on at least once. An http handler.

This handler listens for HTTP calls to /foo and responds with "bar". Specifically "bar" is written to w which is an http.ResponseWriter. In order to verify what has been written to the response we need to examine w after the call to handleFoo.

Of course this example is hardly complex and it doesn't have any dependencies. Typically an HTTP handler would read/write something from a database, log something to a file, or render a template. In that case, we would probably prefer to implement an http.Handler instead of an http.HandlerFunc which is what handleFoo is, so we can define these dependencies.

I'll describe a way to define these dependencies in an upcoming post.

Thanks for reading!

]]>https://alexkappa.com/testing-in-go/2a6f75ae-467f-44ba-a6f4-46bdbe966641Fri, 31 Oct 2014 21:10:48 GMTRecently, I found myself trying to implement a mechanism, able to evaluate expressions. Essentially what I needed was a binary expression tree. I used Go for this project, and quickly came to a delightful surprise that using Go's extremely powerful interface mechanisms, it became extremely easy to implement and extend.

Before we dive in

From Wikipedia:

A binary expression tree is a specific application of a binary tree to evaluate certain expressions. Two common types of expressions that a binary expression tree can represent are algebraic and boolean. These trees can represent expressions that contain both unary and binary operators.

The leaves of a binary expression tree are operands, such as constants or variable names, and the other nodes contain operators.

These particular trees happen to be binary, because all of the operations are binary, and although this is the simplest case, it is possible for nodes to have more than two children. It is also possible for a node to have only one child, as is the case with the unary minus operator. An expression tree, T, can be evaluated by applying the operator at the root to the values obtained by recursively evaluating the left and right subtrees.

So how are we going to use them?

Our need for binary expression trees arose by wanting to evaluate whether a set of url query parameters matches a particular pattern. So the pattern date >= 2014-01-01 should evaluate for /path?date=2014-10-10 but should not evaluate for /path?date=2013-12-12. Alright that was too easy. How about combining conditions together with logical operators?

(date >= 2014-01-01) AND (lang == "EN")

And a little more complex expressions by combining logical operators:

(date >= 2014-01-01) AND ((lang == "EN") OR NOT (foo = bar))

How do we go on from here? Well lets construct a boolean expression tree that represents this arbitrary handwritten expressions.

Okay, lets code

To get things started, it makes sense to see every node in the tree as an object, whose children are themselves objects. Starting from the top, the AND node could look like this:

type And struct {
Left, Right interface{}
}

Now, although this looks simple enough, we haven't yet addressed the trees functionality, which is why we need such a tree in the first place. Remeber we need to evaluate a set of query parameters against this tree and the response would be a simple true or false.

So lets add this to the topmost node we just created.

func (a And) Eval(p map[string]string) bool {
// ...
}

The And struct has a method called Eval which we can supply with parameters and it should tell us if the parameters match the conditions or not.

Now we need to write the implementation of the Eval method which should evaluate it's children.

Can you already see where I'm going with this? Struct And is a node in the tree, which has two children, themselves nodes in the tree. All of them have an Eval that take parameters as arguments and return a boolean.

If And, Or, Not and all the operators need to have an Eval function, we can group them by a common interface? Let's call that interface Node.

type Node interface{
Eval(p map[string]string) bool
}

Let's change the And struct to use Nodes as it's children instead of arbitrary interfaces.

type And struct {
Left, Right Node
}

Now the Eval method we defined on And is correct and would compile and run correctly. However our tree is incomplete as we haven't defined Or, Not or any operators yet.

With the above code we are able to construct and evaluate boolean expressions. To showcase an example, we'll need a couple of helper structs, True and False which always evaluate to true and false respectively.

I've published the examples on GitHub, so feel free to fork the repo and adapt it to your needs.

Final thoughts

Go's interfaces made tree nodes easliy interchangeable and extremely easy to construct. Additionally, tree nodes can be added without any additions to the package. If you need to create your own operators (for example >=, <=, before, after) all you have to do is define an Eval method for it and it implicitly becomes a Node.

I've tried to keep the examples easy to follow, so I haven't talked at all about operator values and type casting. For example you might want to implement a before or after operator that acts on dates, or a contains operator that acts on strings. The implementation of an operator is completely up to you, so if you need to type cast, or parse a date you are free to do so. A quick example:

Another thing I didn't mention is that parameters in my use case came from the requests URL query parameters, meaning their type is url.Values. url.Values is a map itself with additional getter and setter methods. So I adapted the Node interface's arguments from map[string]string to Parameters. And Parameters is an interface defined like so:

type Parameters interface {
Get(key string) string
}

So instead of transforming a requests query parameters into a map before evaluating, I can simply pass a url.Values to Eval instead.

Update: The source code is available on GitHub although it's fairly modified and the API is changed quite heavily.