Tuesday, October 23, 2012

Working with Gremlin

If you want to learn more about graphs or graph databases you might want to check out Gremlin.

Gremlin is a graph traversal language that can be used for graph query, analysis, and manipulation. 

As a simple example, if we have this simple graph:

And we want to answer the question "Who are marko's codevelopers?" then we could write the following query in Gremlin:

That would give us "peter and josh"

With Gremlin it's possible to work with any graph (database) that implements the blueprints property graph data model., i.e Neo4J which is probably the most popular graph database right now.

The easiest way to start working with Neo4J is to start it in embedded more but a more production-like scenario would be to send Gremlin queries to a Neo4J server using the REST API and Spring's Neo4J template.

Check out Gremlin's Web Console if you want to try out Gremlin without installing anything.

Tuesday, October 9, 2012

Empty rituals

Most so-called "agile" teams follow the following routine every morning: they gather round and, one by one, answer the following questions:

* What did you do yesterday?
* What are you going to do today?
* Is there anything hindering you?

Actually most teams that I've encountered just ignore that third question completely.

In the worst case (people sitting during the meeting), what you see is that this meeting becomes almost absurd, people just answer the questions and go back to their smart phones when their turn has passed. In the meantime, the scrum master, team lead, etc writes/types ferociously trying to capture what people are saying. These notes will kept/posted somewhere where no one (other than the scrum master) will ever look.

If asked why they do it I guess the answer would be the same as when you ask people why they chose a relational database.

Anyway, here's a way to make this hopefully less meaningless by Jeff Sutherland.

Starting with the highest priority Sprint Backlog Item (SBI) that is not yet completed in each Daily Stand-Up, the entire Team discusses their collective contribution toward completing that SBI. They then estimate their collective contribution’s complexity in Story Points as if the previous day’s contribution had been presented during the Sprint Planning meeting as the entire goal of the body of work. The Team then collectively plans the fastest and most effective way to share the work in order to move that SBI into the Done column as quickly as possible. Finally, we discuss anything that blocks the work or has the potential to slow it down for any reason.  
So the restructured Daily Stand-Up questions become:  
1. What did WE achieve yesterday on Priority 1?
2. What was OUR contribution on Priority 1 worth in Story Points?
3. What is OUR plan for completing Priority 1 today?
4. What, if anything, is blocking US or has the potential to slow US down today?  
These questions are then repeated for each lower Priority remaining in the Sprint Backlog until either all SBIs have been discussed or the 15 minute allotted time has elapsed, whichever comes first. 
These modifications serve several purposes. Shifting the focus from the individual to backlog priorities helps people to function more as a Team. It encourages consideration of how to effectively subdivide the work for quicker completion, overcoming the technical silos that specialists tend to prefer. We also find better quality updates and more attentive participation from all Team Members as a result of question 2. 
Because each Team Member now has a need to understand the complexity that has been resolved in order to vote on it, updates on the order of “Yesterday, I worked on SBI 1. Today, I will keep working on SBI 1. No impediments.” are no longer tolerated by the Team. 
They become a self-policing group, both demanding quality updates and full attention from all Team Members to keep the meeting efficient.

Tuesday, September 11, 2012

Imperative vs functional programming style (Part II)

In the previous post we saw how it's much nicer (and much easier to test) when we break up our functionality in small chunks that we can easily reuse in different contexts. Let's spice up the same example a bit, this time using Groovy:

Now we are going through a much bigger list of artists and it actually would make a huge difference if we could parallelize the work as much as possible.
Fortunately, this is quite easy with Groovy and the GPars library:
Dealing with data frequently involves manipulating collections. Lists, arrays, sets, maps, iterators, strings and lot of other data types can be viewed as collections of items. The common pattern to process such collections is to take elements sequentially, one-by-one, and make an action for each of the items in row. 
Take, for example, the min() function, which is supposed to return the smallest element of a collection. When you call the min() method on a collection of numbers, the caller thread will create an accumulator or so-far-the-smallest-value initialized to the minimum value of the given type, let say to zero. And then the thread will iterate through the elements of the collection and compare them with the value in the accumulator . Once all elements have been processed, the minimum value is stored in the accumulator . 
This algorithm, however simple, is totally wrong on multi-core hardware. Running the min() function on a dual-core chip can leverage at most 50% of the computing power of the chip. On a quad-core it would be only 25%. Correct, this algorithm effectively wastes 75% of the computing power of the chip.

Now, each query is invoked asynchronously which makes the processing much faster and efficient without making the code more complex.

Sunday, September 2, 2012

Imperative vs functional programming style (Part I)

In computer science,  functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids state and mutable data

Imperative programming, on the other hand, is a programming paradigm that describes computation in terms of statements that change a program state.

As an example we could would write a program that helps us pick the most popular song by U2 that is longer than 5 minutes.

Let's try it using Spotify's Web API. First, we declare the base functions that we're going to use for our example.

Next, let's write an imperative program that finds the song using those functions.

Using this programming style we mutate state using a series of steps until we get the desired result.

An alternative to this, rather messy, approach is to not mutate any state. Instead, the state goes through transformations as it flows through the composed functions.

Here it is.

Using this style, there's some copy overhead but the code is much more concise, easier to read and...beautiful?

Use the style that works best for you but be aware of the choices. If you are stuck with Java then Lambdaj might  help you accomplish something similar to the above code.

Btw, U2's most popular track that is longer than 5 minutes is Magnificent.

Saturday, March 31, 2012

REST versioning, an example

It's not exactly news anymore that the most appropriate way to handle versioning of a REST API is by using the Accept and Content-Type headers.  A simple example would be:

GET /customer/1 HTTP/1.1 Accept: application/vnd.mycompany.myapp-v2+json

Notice that we are using a vendor MIME type since this is not any kind of JSON, it's v2 :)

The important thing is that we always have one URI to represent our resource and still can version it appropriately. A URI expresses identity and therefore it doesn't change when a new version is introduced.

Still, some people insist in handling versioning using the URI. This would give us:

GET /customer/v2/1 HTTP/1.1

This is pretty bad because you end up having different URIs pointing at the same resource which could be a maintenance headache. The version is leaking into the interface when it should not. 

To sum it up: the Accept header solves the versioning problem for GET and the Content-Type header solves it for POST so use them.

I have created a simple example of REST versioning using Groovy, Jersey and REST-assured that shows this concept in action.