Coco boulot

Background While updating a messaging system we decided to move all the unstructured content out of a relational database to a dedicated document store. Keeping only an Identifier for a document considerably reduces the size of the database thus making savings in storage and facilitating the database administration work. Driven by criteria of ease of management, security and cost, the chosen document store was a Software as a service solution: SharePoint online which runs on the Microsoft cloud Azure . Problem to solve Very briefly: move 21 million documents from our in premise to the cloud in less than 30 days . In more detail As for all migrations we need to move the data and map the source identifier and the ID in the new location. This is to allow references to the migrated to be updated. The stages high level for this move were ... Scan the eligible items to be migrated and store their identification and details to access their content in a single table. This table a

When writing a loop using a paging API to fetch data for an Angular app, I felt so frustrated  that I was very close to going back to Promises. I came across lot of questions on the web but no convincing answers: some even proposing to subscribe to an Observable within the service implementation. However, I did not abandon  Observables to return using Promises thanks to this very informative comparison . From there I picked an  excellent article on reactive programming  with RxJava which gave me hope. So I kept on trying... Achieving both reactivity and recursivity without understanding the fundamentals of RxJs operators, was a struggle. After focussing on the use of the map and mergeMap operators, I managed a first implementation very similar to how I would write a solution to the same problem using Promises. To help me and others who have the same questions, I created a repository of angular code snippets . One is about  RxJs Recursive Observable . Expand operator to the

14 months ago I was not feeling very comfortable with the 2000ish approach of web apps development: see post  looking-for-web-framework   Namely having a backend web framework which spits HTML to the browser with a bit of javascript as icing sugar to give a bit of interactivity. Using Flex on a large scale project gave me a very good impression: Having a front end dedicated framework that you can test by itself without a backend was very productive I find the idea of discussing the API between the backend and front-end very sound With the nowadays processing power of end user devices, I like the idea of shifting the rendering processing load to the end user's terminal. At the time, June 2012, I wanted to evaluate some options for web development but pure Javascript did not even came to my mind. On a comparative article from JavaSPEKTRUM - Java Rich Client , Wicket was qualified as the technology that would allow to build a powerful user interface for the least complex

To choose is to live... Jacques Brel said "choisir c'est perdre": to choose is to loose. There would indeed be no choice to make if an option was definitely superior to the others. If you choose you will have to balance pros and cons and you will then have to loose. My great colleague, Achilleas Voutsas , reacted on less than a split second on that one. He straight away answered that: "To choose is to LIVE". He is right: if you have no choice, it is monotone. Choice is creativity. Choice is life. Going back to the theme. In 2005 Romain Eude and Gonzague Huet devised a solution allowing one to run an OpenLDAP server on a windows PC. That was brilliant and it helped tremendously the development of an LDAP based system. I could run an entire system on my laptop: database, application sever and OpenLDAP with 20000 entries. If you run Linux, OpenLDAP is no brainer choice to use. On Windows, the setup from that we used in 2005 is very easy but was not

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