Coco boulot

Maven archetype to generate project (found by googling maven jpa 2 google app engine Archetype ): http://webapplicationdeveloper.blogspot.co.uk/2012/07/google-datastore-with-jpa-and-spring.html For Maven and Google App Engine, see also: http://code.google.com/p/maven-gae-plugin/ Google App engine documentation about JPA 2 support: https://developers.google.com/appengine/docs/java/datastore/jpa/overview-dn2 Google App engine documentation about the java datastore: https://developers.google.com/appengine/docs/java/gettingstarted/usingdatastore Another cool article but not to JPA or google app engine: https://code.google.com/p/guava-libraries/wiki/CachesExplained  

I recently attended the Rich Web Applications course given by Spring Source, and I was surprised that the technology stack employed in the course was "equivalent" to what I used 8 years ago! It's equivalent in the sense that: Struts 1.2 was then the framework for implementing the Front Controller pattern Tiles with JSPs and JSTL was the view mechanism The course used Spring MVC which is the MODERN equivalent of Struts. Spring MVC is much more powerful but the functionality it provides is about the same as Struts. The element that really surprised me was the fact that Tiles was the proposed mechanism for the view layer. I personally find Tiles to be powerful but given the elapsed time, I was expecting something new to replace it. Why Tiles may not be so appropriate these days? It relies on JSPs which are not trivial to test outside a web container. The tiles XML where definitions go, is very similar to a Spring beans file. Nowadays you could expect a n...

I attended today a one day training at QCon London about Continuous delivery. The session was generally interesting until the topic of treating infrastructure as software started tools such as puppet, chef ... Is this really a good idea? Points noted during the presentation: Excellent points: Everyone should be testing, and,  Need to help each other out Location where binaries are stored to avoid rebuilding binaries from source is called "Artifact repository" Using the same artifacts to deploy across environments is a good practice. It allows to cross potential sources of issues out if things go wrong One should not use SNAPSHOTS in Maven dependencies With management, it is important to agree on an outcome. After that a solution can be proposed. Find the constraint you are having right now and then do the necessary to remove it. Dark Launch is a very good way to de-risk a deployment. Suggested good reads (available on the web) were: Eric Ries, The Lean Startup B...

While waiting for dinner, I created this new blog for recording my ICT experiments. My son Eric and Alicia are sitting next to me to watch this event. And let's publish!!! Et voilà.