SpringOne 2012 essence

So what to take away from the SpringOne 2012 conference?
The overall theme of this conference is the changing world we as developer find ourselves in. As we all know the world of software development is always evolving at a rapid pace. This evolution always leads to changes in requirements and new solutions to breach the gap. In some cases these evolutions require a new way of thinking. The essence of this SpringOne is about the latter. The current evolution is driven by:

  • increases in data quantity
  • the explosion of browser enabled devices
  • the request for higher quality of service (an application needs to be able to survive outage of a data center)
  • near real time delivery of contextual information and social integration in frontends.

The combination of these new demands and requirements leads us to a so-called paradigm shift. These problems cannot be solved with past (or current) architecture. So we need to look at our applications in a new way. Building and modularizing them to account for scalability because that seems to be the answer to the questions asked.

We need to start thinking in federations to persist information across cloud instances. Size and package application modules so they can be scaled separately.
At his SpringOne conference the tools and the methods needed to do this were show cased. Adrian Colyer’s keynote on day two gives us a good idea of what Spring offers to help us cope with these changes and as always make our life easier.

You can view the full keynote here:
http://www.springsource.org/SpringOne2GX2012
or download the sheets: http://springone2012.s3-us-west-1.amazonaws.com/SpringOne2GX_2012_Keynote-Day-2_Final.pdf

As for some examples of tools that help you deal with these impending changes check out the VMware en SpringSource projects below:

JavaScript: console logging (with IE safety)

Every once in a while I work on a site which has some or copious amounts of javascript. Now I do not mind this at all. But it’s pretty tedious stuff writing the code and putting in loggers. And when you’re working on something and you have to test it on IE. Well let’s just say the console may cause some problems.

But rather then removing all the logging i’ve found there’s an easy solution. Building yourself a logger like structure which checks the existence of the console before writing. That way you can add logging statements without crashing the entire application. Continue reading

Safe-guarding AngularJS scopes with ECMAScript 5 “Strict Mode”

Having a history as a Java developer I prefer declaring the complete JavaScript object at once through an object literal; in a similar fashion as your would declare a class in Java.
In my opinion adding new properties “on the fly” to a JavaScript object is a very bad practice:

For the same reasons I dislike how properties are declared in an AngularJS application:

Consume REST JSON webservices easily using Spring Web!

Spring made it very easy to consume JSON webservices. In this article I describe how to receive and parse JSON and how to send your Java objects as JSON.

First we need to include the required dependencies. If you use maven, include the following dependencies:

Spring web has a RestTemplate class which can be used to call the REST webservices. The Jackson dependency supplies a message converter class which can be used to send and receive Java objects which are automatically converted to JSON en reversed from JSON.

Continue reading

Javascript, keeping it clear

Note that this blog is in no way written as a “best practice” or “do it this way” kind of blog. I am not, nor do I aspire to be, the worlds greatest javascript programmer. I do however like my code clear and structured. Now lately some collegues have asked me how I write my code and that in turn prompted this blog.

In short the best way to keep your javascript clear is using namespaces. The use of namespacing is very simple and should cause you no problems. As you will come to see it will be both easy and clear for fellow developers to read and modify your code. So yes, if you wish to remain the javascript magician with obscure code that no other developer wants to touch feel free to not use them. Continue reading