Posted on

Go back to REST

I like REST.  It seemed to gel with me more than SOAP did.  I think the overall simplicity of it, reduced the barrier to entry.  Whilst I love well defined schemas and protocols, SOAP got some of my most respected and senior colleagues bewildered and frustrated, realising that the real SOAPy world that promised vendor neutral interoperability between OS and even XML framework level didnt materialise.  Too many times at my previous employer, we were stuck between a rock and a hard place when one supplier wanted to use one form of XML serialisation, but we already had another framework in our classpath do deal with another suppliers (competing supplier funnily enough) that clashed.

So if you want to spread the word of REST, these resources seem to be ok:

Addressing Doubts about REST from InfoQ Explores: REST

Stefan Tilkov Talks REST, Web Services and More

Edit: Good news, the Jersey JAX-RS (rest api for Java) implementation v1.2 was released recently.  Jersey 1.2 User Guide

Posted on

Lambdas are not closures

A λ (lambda) is an anonymous function. In addition to Closures, Oracle are looking at including lambdas in JDK 7, which would bring more functional goodness to the feature stagnant Java. This InfoQ article sums up the situation nicely.  It talks about the difference between lambdas and closures – a closure is a function that doesn’t rely on any external arguments – it is a closed function.  However, a lamda is an open function. 

λx. x + y   (open function, depends on y)

λy. λx. x+y (closed function, the inner open lambda is satisfied by y being supplied in the external function)

The former reminds me of Groovy’s closure currying

The proposed syntax looks something like this

inc = #(int x) (x+1); // single expression
inc2 = #(int x) { return x+1; }; // block

The rest of the article talks about the proposed syntax for lambdas and the concerns with implementing in various code constructs that potentially conflict with existing Java language syntax and rules.

Posted on

Graph Databases

A great article on the NoSQL movement, focusing on Graph Databases and the Neo4J implementation appeared on InfoQ.

Graph databases store a Node (aka vertex), that has properties (aka attributes), that is then linked to another node.  The relationship (aka edge) between the nodes also has properties and has a direction and a type.

The article demonstrates that syntactically these databases look easy to manipulate. In Ruby (and presumably Grails) they map directly to classes and with the use of metaclasses and operator overloading, to allow the domain objects to be quickly in a neatly expressive way.   For Groovy/Grails/Griffon, there is info on the Neo4j wiki

Because OO models are graphs, the need for ORM layer is removed.  They map directly to the classes we are trying to store.  Additionally the pain of upgrading the data in a class is reduced since adding a new column is less painful.  More benefits can be found on the Neo4J website.

Neo4J is free for open source projects and there is an unsupported free single instance Basic edition for startups, but is paid for everyone else.  There are 3 commercial editions, basic, advanced and enterprise priced at $588, $5,988 and $23,998 per annum (billed as monthly subscription).  The free Basic is a good move, small companies who may elect a free alternative such as MySQL, Postgres or even the Oracle Express Edition.  For the Basic & Advanced editions, you could argue that the development time saved would more than cover the fees charged. 

The basic edition lacks monitoring which in my opinion should be included, especially if you are only going to get 2 support incidents per year with that package.  However the advanced edition has that feature plus monitoring, a management console and allows hot backup and failover to a 2nd running node. It only differs itself from the high end one due to lack of high availability features and longer support response times.  If you were using it for a production enterprise system, you’d probably want the 24/7 support and I think this pricing is comparable to a support subscription for any of the larger RDBMS vendors and with no upfront capex fees to note, though keeping in mind that at the enterprise level you’d be paying for multiple running nodes costs may run up quickly —- there is always negotiation though in this space.

Posted on

Facebook: Moving Fast at Scale

Facebook: Moving Fast at Scale

“Robert Johnson talks about: the need to prepare for horizontal scalability, very short release cycles associated with a streamlined deploying process, and making the entire process faster every day.”

The neatest thing I got from this presentation was how agile Facebook were.  They do daily releases.  To be able to do this, they’ve put control of QA and deployment back to the engineers.  The engineers are responsible for making sure the rollout happens slowly and to keep an eye for post release bugs.

There are still operations people to assist, but they avoid the common scenario where the operations team gets burnt with some bad deploys and then refuses to roll out further updates, which in turn delays the release cycle, time to get feedback for developers, etc.

The presenter claimed that once they got in the habbit of this, the cycle continued to reinforce itself.  Instead of doing a release every 3-4 weeks, 12 a year, and having 12 lessons learnt a year, by doing em dailyish, you get plenty more lessons learnt from each release and the feedback can be used to improve themselves.

Other neat things they talked about were how they scaled – horizontally across their tiers (web server, index/memcache, persistence/mysql).  It seems a common problem of how to find a way to cluster the information in Facebook in any kind of domain centric database or geographic location since FB users are friends all over the world, in different groups, and ‘like’ different things.  The content on your own FB page is dynamic and pulled from sources all over the world.

He also talked about deploying challenges, in particular getting different versions of php and javascript to interact when different versions of FB code were in the wild (different web servers).  Basically by having a repository lib they wrote called GateKeeper that tells the FB code what version it is running on and essentially which code to follow.  Their code looks a bit yuk on the outset – if this version, do this, if that version, do that – but by doing this they bring the problem of inconsistent behaviour due to having different data structures and code for different versions of the software in the wild back into the hands of the developers to manage.  The code doesn’t cry when different versions interact, it knows what to do which means that they can worry about more pressing things.

Not too technical but a great mix of software practice for distributed systems and something that will hopefully get discussed more and more (and hopefully even taught to undergraduates some day)

Posted on

Another great IDEA presentation

My favourite IDEA presenter, Vaclav Pech is talking about code analysis tools in IDEA.  He talks about

  • Code Inspections (live and on demand)
  • Abstract Syntax Tree
  • The structural code inspection – AST context helps understand the Structure search and replace dialog and how you can use its functionality to make an Idea warning with autofix
  • language analysis
  • the annotations like @NotNull, @Pattern in new JSRs and the IntelliJ specific annotations @Language for analysis of strings
  • stacktrace detection
  • dataflow to/from this
  • duplicate detection
  • dependency analysis
Posted on

My Interpretation of the Signals and Slots Pattern

BasicWiring

What happens

An ObservableClass ‘emits‘ signals when something interesting happens.

Examples of interesting things:

a property change in a bean;

a new db connection up;

a window closes

Emitting a signal is something that has to be done manually by the programmer after they’ve done the interested thing

Example

setProperty(Object newValue) {

this.property = newValue;

emit(newValue);

}

It means tell all the InterestedClasses to check out the signal and optional newValues passed and do something with it in a slot method

To let the ObservableClass know which InterestedClass methods to call (slots) when we emit the signal, we must connect them to each other.

We could also connect multiple slots to signals

Once connected however, the connection is quite loose.

The slot method is usually referred to as a string (though we could use closures in future). Thus slot or slots to execute when a signal is emitted is determined at runtime, by looking at the parameters in the emit and matching them to the parameters of the connected slots (methods).

Implementation Use Case:

  1. We are interested in one or more discrete events that happens in the lifetime of the Observable Class.
  2. We create Signal objects to represent each of these events that could ever be emitted by the ObservableClass. We usually do this in the constructor of the ObservableClass
  3. We update our methods to emit signals (call the emit method straight after the interesting thing has occured)
  4. If we want to send some event context data to any interested listeners (slots), we can pass parameters to the emit to pass on when the Signal is fired.
  5. In another class (or maybe even same one?) we write a method to execute when the interesting thing happens. This is called a slot
  6. We connect the signal to the slot via a connect method
  7. When the interesting thing happens, the emit method on the Signal object is called. emit is responsible for letting all the connected slot methods to know to fire.

    Other Notes (extentions)

  • A signal can be connected to multiple slots (methods) in any number of different classes
  • You can chain signals together
  • Communication is one way from the Signal event to the InterestedClass.
  • The params in emited in the Signal can be more than the slot method (but not the other way around)

Comparison to the usual way done in Java Swing (Observer Pattern)

In Java, an Observable Event occurs. InterestedClasses must register their interest with the observable class.

The ObservableClass must keep track of who is listening and notify each of them when the event occurs.

The InterestedClasses must all implement the same notification method (and full method signature) in order to use the event. Potentially less runtime mistakes because the IDE will pick up at compile time

Remember the Signals and Slots pattern doesn’t care about the method signatures of who is listening and effectively can fire updates to different methods of different types.

Posted on

Design your own DSL with Groovy

http://www.infoq.com/presentations/Design-Your-Own-DSL-with-Groovy

This presentation is by Guillaume Laforge, one of the Groovy founders, who does quite an interesting presentation about how Groovy supports Domain Specific Languages.

In short he starts with a simple example of how the Groovyisms in the language such as method calls without the need for parenthesis, named params and maps and list param injection into method arguments make for readable DSLs, all without touching any of the fancy meta-programming functions provided.  Very impressive. Other Groovy features that we sometimes forget about are ranges and operator overloading which were demonstrated here and  improve readability.

Then he scratches the surface a little deeper showing an example of how to add methods to existing classes using the metaClass property.  He takes the Number class and dynamically adds a method that constructs an object representing a measure – 6.pills or 6.euros which call a method Dosage getPills() that you inject into Number.  

   1: Number.metaClass.getPills = {

   2:     return new Dosage( numOfPills: delegate );

   3: }

When combined with the previous readability of maps representing method args and parenthesis less method calls, it can lead to some readable code

   1:  take  1.pills

   2:   of: SomeDrug,

   3: after: 6.hours // Number.metaClass.getHours = { 
 }

take is defined as 

   1: def take(Map m, Dosage d)

This is a great intro to metaClass object protocol for those who haven’t come across it in Groovy.

The last part of the presentation talks about Abstract Syntax Tree transformations and how you can inject syntax into the Groovy language using annotations.  He uses the example of the Spock testing framework and how the @Speck annotation injects behaviours that wouldn’t normally be allowed in Groovy or Java, such as method names which are “strings with spaces and question marks?” and other neat stuff.  He also talks about how its important to limit what your DSLs can do in the JVM if you are giving them off to

I think in summary Groovy is a great language for supporting DSLs and the presentation gives a valuable insight into some of the more advanced groovy features, a worthwhile watch.