Yesterday I was able to take part in a nice event about software development. I had the opportunity to hear ThoughtWorks‘ chief scientist Martin Fowler talk about three current trending topics in our industry: Domain Specific Languages (DSLs), REST and Continuous Integration and Delivery. All topics were in one way or the other familiar to me (expect for continuous deployment which I just had heard of) and I quite liked the way Fowler conveyed the overall idea of each one.
Domain Specific languages
Domain specific languages have been around for quite a while, but it seems the software community has not yet taken full advantage of them. DSLs are everywhere and examples include CSS, Rake, SQL, EasyMock, FIT and Graphviz, just to mention a few. Fowler used an example based on the design of a state machine to illustrate where a DSL might come in hand. He showed some code for the machine in plain-old-object-oriented-java style and explained the shortcomings of that approach: poor code expressiveness and lack of flexibility due to static typing. To be able to change the state machine at runtime, he then showed the design using XML. That way, one could be able to declaratively specify the machine’s behavior and the code would be more readable. The drawback of the XML approach is its verbosity (opening and closing tags). He then went on to explain how a DSL (either external or internal [he used Ruby as host language]) could be used to better model the machine. Fowler gave his definition for a DSL: a computer programming language of limited expressiveness focused on a particular domain. DSLs should come with a strong semantic model. He stressed that the value of a DSL lies in its readability rather than writability, thus allowing domain experts to be able to read and strike a rich conversation.
Steps to REST
Fowler’s next short talk was about REST. He used the Richardson Maturity Model, describing the three levels of improvement toward better RESTful architectures. The idea of REST is to expose web services as resources using the infrastructure already provided by the HTTP protocol. He commented on the fact that it is foolish to turn everything into resources and we should think about the principles of object orientation (such as encapsulation) when choosing which resources are important to be exposed. The contents of the presentation are here.
Continuous Integration and Delivery
The last talk was about Continuous Integration and Delivery. In all but the simplest software projects several people are simultaneously working on the code base (many times in isolated feature branches) and, as a result, sometime down the road the need for integration arises and Big Scary Merge is on his way. Powerful merging tools are available, but they only address textual problems and cannot tackle the semantic integration problems. The fact is: integration is hard… so we should be doing it often. Fowler’s rule of thumb is: every one on the team should be integrating with the main line at least once a day. As a result, merge problems are rare and we guarantee integrated working software in the development area. That’s pretty good, but the software is only useful when it is in production. So, how we come into production quicker? The key concept is the notion of a build pipeline which can also minimize human intervention for software deployment.
The following books were recommended: