Grammar of systems

Many ideas behind software architecture has been developed from the fundamentals of mechanical and building construction experiences, because “building software” had analogies in construction of buildings. There is an idea of what the system should do (building spec or functional requirements), how the system should look (design), what the system is internally represented as (blueprint) and how to go about constructing it (waterfall methodology). Many theories stem from this base – architecture, blueprints, waterfall, strategy, review – all these are terminologies that go back to construction work.

Somewhere along the way, a realization dawned that software architecture is not really like house construction. The analogies break down pretty soon as the analysis go deep – software does change as it is built, building a house does not. You cannot plan software to the absolute last detail, but the house construction is. The obvious reason is, in creating a software, change is less expensive and damaging than the house creation, during the construction phase. It is easy to change a variable, name, algorithm compared to breaking the drywall and replacing that electric wire. At best, software development is like building a Lego model – add, remove, swap pieces until you feel its right, the expense of rebuilding is limited – only about the labor and not much about the materials.

From this realization, alternative approaches have sprung – agile, scrum etc. where change to software is presumed as a necessity and the efforts is not to curtail the change, but to apply them in a controlled manner. With that also comes the extrapolation in thought that software design is not a predecessor to development, but happens along with its development. Also the thought that architecture is emergent, evolving and is felt to be finished only as a time-bound specification.

I think the fundamentals of software architecture is much closer to another field – Linguistics. Spoken language is a remarkably fascinating system where humans learn how to communicate effectively with each other. Think about it – two persons, growing up in completely different parts of the world, different culture, different backgrounds and different thought processes are still able to exchange their thoughts, as long as their communication channel is the same language, like English for example. Well, except for the accents.

What is it that makes two people understand what they say to each other? Let me rephrase that in a more elaborate way – What is it that makes one person think that he (she) ensured that the intention in what was spoken is what the second person really understood as intended? In other words, what is behind the reasoning, that you understood what I intended?

That reasoning of a sentence is provided by grammar of the language. Grammar did not evolve before the language, instead it evolved from the language, but once evolved, it scaffolds the language and ensures that it stays valid. The intention behind what I want to say and ensure that it is understood by the second person as intended, is reasoned by the grammar of the language – by how I use the language’s Quality Attributes – nouns, verbs, prepositions, objects, adverbs, adjectives etc. – these scaffold the language for that intention. When I make a grammatical error, it is immediately evident that something is not valid. In effect, the grammar puts a constraint around a language to justify and reason so that it makes sense.

Software Architecture should behave exactly the same way – it should evolve from the underlying systems (from programming languages to os to network protocols etc.) and then in-turn scaffold the system by constraints. Just like there is little room for the language to evolve arbitrarily, because grammar provides the check, once a software system is developed, its architecture should provide the reasoning and justification on how the system should behave. But languages do change overtime (albeit slowly) and acquire new meanings and new constructs. Nouns become verbs, new verbs are created and then the new constructs are justified by expanding the grammar. Similarly a system does change overtime and its architecture should expand to provide scaffolding back to the system and justify it. An effective communication is established with a well defined style of writing (good grammar), a software architecture is well communicated only when it is well documented. Yet, just like even a well defined style of writing is not sufficient to ensure that the intention is understood, a good documentation alone is not sufficient to ensure that a system will be understood correctly. Only experience enhances the understanding.

Software architecture is an abstraction of underlying systems, just like grammar is the abstraction of a language. If product is a book, application the story, modules the chapters, marketing the cover, development the language, unit testing the spell-check, testing the proof-reading, printing the production, architecture is the grammar of software systems.

Grails plugin dependency issues

Ran into a few problems with Grails plugin dependencies here are some solutions.

Applies to Stack

Grails 2.3.0, cache:1.1.1, asset-pipeline:1.0.4, mongodb:1.3.0, shiro:1.2.0, hibernate:3.6.10.1, database-migration:1.3.5

Problem 1:

Conditions: Using cache:1.1.1

grails compile fails with error:

| Error Compilation error: startup failed:
Compile error during compilation with javac.
C:\Grails\MyProject\target\work\plugins\cache-1.1.1\src\java\grails\plugin\cache\web\filter\PageFragmentCachingFilter.java:46: error: package net.sf.ehcache.constructs.blocking does not exist
import net.sf.ehcache.constructs.blocking.LockTimeoutException;

Solution 1:

Add the following in the BuildConfig dependencies section (if mongodb is used by a plugin, this should go into plugin’s BuildConfig dependencies)

dependencies {
 compile "net.sf.ehcache:ehcache-core:2.4.6"
 }</code>


Verification 1:

Delete target/* from any plugin and project sources
grails compile

Problem 2:

Conditions: You are using shiro:1.2.0 + Servlet API v3.0. Shiro includes servelt-api 2.5 by default and is causing a conflict.

grails compile fails with error:

C:\Grails\MyProject\target\work\plugins\cache-1.1.1\src\java\grails\plugin\cache\web\GenericResponseWrapper.java:154: error: method does not override or implement a method from a supertype
@Override
^
C:\Grails\MyProject\target\work\plugins\cache-1.1.1\src\java\grails\plugin\cache\web\filter\PageFragmentCachingFilter.java:398: error: cannot find symbol
contentType = response.getContentType();

^
Solution 2:

To eliminate this problem, exclude servlet-api from Shiro for shiro-cas:

dependencies {
compile("org.apache.shiro:shiro-cas:1.2.2") {
excludes "servlet-api"
}
}

Verification 2:

Delete target/*
grails compile

Problem 3:

Conditions: You are using shiro:1.2.0 + mongodb:1.0.3 – hibernate:3.6.10.1 – database-migration:1.3.5 (ie hibernate and database-migration are not included)

grails compile fails with error:

| Error Fatal error during compilation org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
C:\Grails\MyProject\target\work\plugins\hibernate-2.2.4\.\HibernateGrailsPlugin.groovy: 18: unable to resolve class org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport
@ line 18, column 1.
import org.codehaus.groovy.grails.plugins.orm.hibernate.HibernatePluginSupport
^

IntelliJ IDEA 13 may also throw a “IDEA hook: Grails not found!” error.

This is due to a dependency of shiro on hibernate-2.2.4 api.

Soution 3:

runtime (":shiro:1.2.0") {
excludes "hibernate"
}

Verification 3:

Delete target/*
grails compile

One way to sort out such errors is to run the grails dependency-report and look for the jar file which causes the problem. Trace back from jar file to the actual included plugin or dependency and add the excludes in either dependencies section or plugins section appropriately.

The GAME Stack

The GAME stack

Alright, you know what LAMP stack is. You may have also heard about the MEAN stack (Mongo, Express, Angular, Node), that is gaining popularity. So many stacks are popping up and I wonder when we would get a stack overflow of stack names. The advantage of MEAN is, everything is javascript and your team needs to know only one language throughout. Good and Bad, I guess. Good because your team skillset is only one language. Bad because your team skillset may have just one language. Future of software is unpredictable and if/when Javascript goes out of favor, you and your team will be considered legacy.

While all-javascript is attractive, there is already a solid base built on the server side stacks, especially around security. I’m proposing a new stack name – GAME – Grails, AngularJS, MongoDB as all of them are equally impressive. Of course, nothing novel about this and this stack is already being used by many, but not many know that the ‘E’ stands for ‘Eh?’ pronounced with a Scottish accent. So when you use this stack, you get to tell your friends – “We use GAME in our company – Grails, AngularJS, MongoDB, Eh?” (perhaps with a quirkly smile).

Though Grails and AngularJS seem to compete on what they do, I prefer to keep some things on server-side, because Grails is a joy to code with configuration and business logic. The nice thing is AngularJS syntax is very much Grails-y. There are a few good online examples of using these two, but I didnt find a step-by-step quick start guide anywhere. So if you are planning to introduce AngularJS into your Grails projects, try these steps:

Notes:

1. It is not really required to use angularjs grails plugin. You can directly use your preferred angular.js version
2. If you are using IntelliJ, enable the AngularJS plugin. This gives you intellisense for angularjs directives
3. You can use angularjs with both resources and asset-pipeline plugin. I am starting to prefer asset-pipeline plugin, because all dependencies are kept within js itself (instead of ApplicationResources.groovy). The asset-pipeline gsps are a bit simpler to use than the resources.

Step 1: BuildConfig.groovy

plugins {
runtime “:asset-pipeline:1.0.4”
}

Step 2: Asset-pipeline directories

grails refresh-dependencies will create grails-app/assets/* directories. Move your existing resources from web-app into this directory appropriately.

Step 3: Add angularjs library and application.js

grails-app/assets/images/*
grails-app/assets/javascripts/angular/angular-1.0.8.js //AngularJS library
grails-app/assets/javascripts/my-angular.js //My AngularJS code (controllers, unit test etc)
grails-app/assets/javascripts/application.js //Application.js that wires all JS libraries

application.js

In asset-pipeline, all dependencies can be declared within the js itself. Here is the application.js (the root of js files):

//=require jquery
//=require angular/angular-1.0.8.js
//=require angular/my-angular.js
//=require_tree views
//=require_self

Step 4: Update main.gsp layout page

The layouts, main.gsp is slightly different using asset tags.

<head>
… meta tags …
<asset:link rel=”shortcut-icon” href=”favicon.ico” type=”image/x-icon”/>
<asset:link rel=”apple-touch-icon” href=”apple-touch-icon.png” />
<asset:link rel=”apple-touch-icon” href=”apple-touch-icon.png” sizes=”114×114″/>

<asset:javascript src=”application.js” />
<asset:stylesheet href=”main.css”/>
<asset:stylesheet href=”mobile.css” />
<g:layoutHead/>
</head>

<div id=”grailsLogo” role=”banner” style=”float: left”>
<asset:image src=”mylogo.jpg” alt=”MyLogo” height=”100″ />
%{–<img src=”${resource(dir: ‘images’, file: ‘grails_logo.jpg’)}” alt=”grails-logo” height=”100″/>–}%
</div>

Step 5: Add sample angularjs code:

grails-app/assets/javascripts/my-angular.js

function HomeController($scope) {
$scope.myDate = new Date();
}

grails-app/views/angularsample/index.gsp

<%@ page contentType=”text/html;charset=UTF-8″ %>
<html ng-app>
<head>
<meta name=”layout” content=”main”>
<title></title>
</head>

<body>
<div id=”page-body” role=”main”>
<div ng-controller=”HomeController” >
{{myDate}}
</div>
</body>
</html>

Step 6: Verify

Goto http://localhost:8080/app/angularsample/index