We are completing work on caching and routing tier we added to a lived-in system. The performance increase is very substantial and I will write a lot more about how we achieved this next week.
For now, I’ll wet your appetite with a screenshot that says it all
Service node statistics
RDTSC and System.nanoTime()!
Our new open-source project, Jeabu, is on its way. If you are very adventurous and interested in the earliest code, pull it from http://github.com/janm399/jeabu/tree/master.
This year I have entered the Rails Rumble. I am entering as a Solo developer and will be competing with over 200 teams of up to 4 people.
For those of you who don’t know what the Rails Rumble is, it’s a coding competition that lasts for 48 hours. The aim is to design and build a web application in Ruby and Rails within this 48 hour slot. No digital assets are to produced before the competition.
I have previously entered a web-2.0y-mashup competition for Film 4 and came runner up… so I am feeling optimistic!
The competition is this coming weekend. Wish me luck!
“Location, Location, Location” may not be enough.
Having property files loaded using ProperyPlaceholderConfigurer bean or the modern <context:property-placeholder> can become a real pain when the placeholders are distributed among the jars.
<context:property-placeholder location=”classpath*:*.properties”/>
Well, only location can be set here, the rest is default. Pretty cool, but it is not doing it… We look back to the old fashion bean
<bean class=”org.springframework.beans.factory.config.PropertyPlaceholderConfigurer”>
<property name=”locations” value=”classpath:*.properties”/>
</bean>
The hack comes here: change from the default placeholderPrefix to a specific one, unique among jars used and everything is gonna be alright.
<property name=”placeholderPrefix” value=”£{”/>
Don’t forget now to change the references to the properties (from ${…} to £{…}).
Not today, of course, COBOL celebrated its fiftieth birthday in April. It is the hidden language, no one will openly admit that they have COBOL systems, yet there are millions of lines of COBOL code that no one dares to throw away. The number one reason is “if it ain’t broke, don’t fix it”, closely followed by the fact that software rewrites usually end in tears. Joel Spolsky gives excellent evidence on his blog.
So, how come COBOL has survived for so long? It is an old, cumbersome language; yet, it has modern compilers and runtime environments. You can compile your COBOL program on 32bit Windows, on 32 and 64bit Linux, HP-UX, Solaris, AIX, and many others.
Seven years ago, I worked in Ortex and they (not me, I was the cool new dude) were churning out thousands of lines of COBOL code every day.
I helped replace the aging Windows 3.1-style user interface with something that looked a bit more modern, but underneath the pretty UI, we were still talking to green-screen UNIX COBOL monster. And there lies the key to COBOL’s continued success.
It did not use complex binary protocols, it relied on the XML of the seventies — fixed width text messages. This simple data exchange format lends itself to easy integration with other systems. As long as your system can read and write fixed-width text, you can talk to COBOL-based systems — OK, I know I’m leaving out details, but bare with me.
Fast forward to 2006 and watch the WS-* approach. Why, did the WS-* people ask, are our systems talking to each other in closed binary formats; why can’t we use an easy to read and write format? Why aren’t we using XML? It turns out that WS-* approach is still cumbersome. For example, you cannot determine what a WS-* call will do just by looking at the endpoint, you need to examine the payload. Hmmf!
Enter REST. Again, we are sending structured plain text, but this time around, we’re making the most of the HTTP protocol. We use the HTTP methods properly and we give meanings to the URIs.
The ice has been broken. The first step on the path to future speeches has been taken.
First of all I would like to thank each and every one in the audience for the great support. You can now download the demo source code and the OSGi presentation material.
You can also download Dr David Syer’s Spring Batch presentation.
Videos and photos from the event will be uploaded to our website and to the upcoming Cake blogs, so keep an eye on us.
If you are in charge of a garden-variety Linux system, you’ll probably like nmon. It is a performance monitoring tool that combines statistics for the core kernel objects. You can see process list (similar to top), memory, network, block I/O and many other statistics, all in nice ncurses-based environment.
nmon screenshot
Now that the news that VMWare bought SpringSource for a lot of money is out, let’s think about what it means for Spring developers. This post is pure speculation, something I would like to happen; the only satisfaction I will have if it does is being able to say “I said so”.
I do not expect anything to happen to SpringSource’s open source products; in other words, the entire Spring Portfolio, tc Server and dm Server will remain free for us to explore and use.
So, what new can SpringSource offer? Well, VMWare are in the virtualisation game, therefore I think they will offer virtualised enterprise solutions built on the Spring Portfolio and either tc Server or dm Server.
Imagine being able to download (still for free) a pre-configured dm Server or tc Server appliance. Download it, start it, and presto, you have a pre-configured enterprise-ready application server. Now, let’s take it up a notch. Imagine that these appliances allow themselves to be automatically discovered. All you need now is a central appliance (call it orchestrator, manager or clever load balancer). This central appliance would discover the tc Server or dm Server appliances on the network, monitor them, and provide a central point for deploying your applications.
Such approach would take away most of the pain of today’s enterprise deployment. You deploy to the orchestrator appliance and it then propagates the new version of the application to its worker appliances. Now, the orchestrator appliance may have access to a pool of shutdown worker appliances and it may be able to start them up if the load suddenly increases.
I think this is where the big money is: enterprises will be happy to pay licenses for the orchestrator appliance, because it solves so many headaches.
So, when is this exciting future coming? I don’t know — in fact, I have no idea. But one thing is certain: if SpringSource do not start working on the orchestrator appliance, we at Cake Solutions will.
Some of you may know that I teach the 4 day Core Ruby on Rails Course which includes BDD with Cucumber.
After delivering a passionate course I was invited to be the Web & RIA Community Leader at Skills Matter, which invitation I accepted.
Some of the responsibilities of the position is to review course material and suggest new courses in the Web & RIA areana.
If you want to suggest a course or even deliver one feel free to contact me at andrewc@cakesolutions.net