JenkinsCI Cloud Formation Plugin

Lately I have been very busy working mainly in automation stuff. JenkinsCI is an awesome CI server that we are using for pretty much every automation activity we do. What makes JenkinsCI such a good tool is, among other things, how easy it is to extend. This is the primary reason why there are so many plugins that let you use the tool in the most unexpected ways.
Amazon Cloud Formation is a service that allows you to express your application stack in the form of a json document (assuming you application is being deployed to AWS). This is indeed a very nice service as it allows you to treat you AWS stack definitions as code.
The combination of these 2 tools/services can be extremely powerful. One use case that comes to mind right away is to be able to create a brand new stack, run tests against it, collect test results for publishing/reporting and then take the whole stack down to save money. Another use case could be to implement BLUE/GREEN deployments.
Use cases like these are possible using the Amazon CLI tools by running ad hoc commands from a JenkinsCI Shell builder. However, getting such a set up to work reliably can be extremely challenging, specially due to the fact that calls to the AWS API are not guaranteed to work all the time and need clever ways to check for its completion and success. Achieving this in a shell script is doable, but tricky to say the least.
Enter the JenkinsCI Cloud Formation Plugin. This plugin allows for the creation of AWS Stacks in a declarative way. All is needed is a stack document (json) and the parameters that you wish to pass into the stack. The plugin allows for the use of build environment variables as values to stack parameters so that the stack creation is not isolated from the rest of the build. Another nice feature is the ability to "chain" stacks by passing outputs from one stack as parameters to another stack further down.
The plugin is in its early stages but it is fully functional. Please give it a try and let me know how it goes. If you find problems please log an issue here.

From Java to PHP - Impressions.

So,
I am now gonna be working on PHP for the next few months. I have been tasked with bringing continuous integration into a set of products that my company is building. Because my last few years I have spent working mostly in java; I decided that before doing any thing about CI in these projects I will spend a few weeks working side by side with the other developers to gain and understanding of PHP as a language and more importantly, the mind set of seasoned PHP developers that have never had any interactions with things like CI, unit testing, continuous deployments and stuff like that. 
Today I just got my first PHP project up and going. It is a web app that exposes some rest end points. While getting it up and running I ran into a few problems as any one should expect but it was 1 particular problem that threw me for a loop. I Still can't find an explanation for it and if someone out there can explain it I'll appreciate it.
Here is how it goes. The particular code I was trying to execute was doing nothing; literally nothing, not even giving me an error message. After a few minutes of fiddleing around I got to a point in the code that looked like this:

try{
    $this->execute();
} catch (Exception $e){
     echo $e;
}

So, the execute method was failing. The funny thing is that an error was being generated inside of it and the execution was completely halted; that is, no exception was getting caught in the catch block and the execute method was never returning. Now, I am new to PHP. I have previously worked with java, c#, javascript, c, c++, delphi and a few others I can't remember, and they all had predictable exception handling; so must likely there is something about PHP error handling that I am not quite grasping yet.
The problem turned out to be that I did not have the phpmysqli driver installed.

API design.

I find this entry very useful. So much so that it is worth printing and sticking somewhere it can be read while coding APIs.

Evil Ike

If this is how Ike, being a category 2 hurricane, left Texas; I can't think if the disaster it left across Cuba where it hit as a category 3 hurricane. Very impressive pictures of Texas though.

Hibernate & maven.

Some time ago a blogged about some annoyances in the, at the time, current pom.xml for hibernate. At that time the maven metadata for hibernate was maintained by the maven community who could not keep up with the amount of work generated by updating dependencies to hundreds of software libraries.
Well, things have changed quite a bit since then. 2 of the most important java open source projects of all times have started maintaining and publishing their own maven artifacts!! Spring Framework announced it here on January/2008 and more recently Hibernate did it here.
It is clear that maven is gaining ground in the build market when projects of this caliber start supporting it. In the case of Hibernate they totally migrated their build from ant to maven.
I am glad that maven has gotten to this point.

Consistency vs Improvement

On every medium to large software system, consistency becomes critical.
By consistency I mean the application of certain architectural patterns that are considered the standard way of "doing things" in a software organization. Consistency helps keep the system understandable to all programmers currently involved, and to those that may come in the future. Consistency also helps when solving known problems as established patterns can be applied with ease. Consistency attempts to keep the entropy of the system under control.
On the other hand, it can also make improving a system hard. How can you change the standard without introducing inconsistencies? In a large project there is probably no good reason to change existing code that is already working for new code that does the same in a different way. No matter how better the new approach is; it just isn't cost effective.
In my opinion, consistency can not be taken in an absolute way. Consistency is never a good reason not to improve a design. If this wasn't true there would be no legacy code ever. Instead new valuable ideas should be embraced and considered the new consistent way. No new code should be written following the old way. Changing the old code should be considered technical debt if it merits the effort which very likely it will. Resistance to changes that improve the quality of a system overall is irresponsible.
How is this issue dealt with in your organization? Is consistency used as a reason to reject changes?

YubNob is kinda cool

This is a nice idea for shell like search commands from within firefox.