The Advantage of Being Non-Agile
Sometimes being not so agile prevents you from adding crap to your system
Agile software development has been en vogue in this decade. It started with the popularity of Extreme Programming (XP) and Kent Beck's series of books on the topic.
One of the values stated in the Agile Manifesto is "Responding to change over following a plan" and is accompanied by the principle
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
While I generally consider most agile practices as common sense, some of they may also cause trouble.
Being agile encourages customers to feed the development team with ideas on the spur of the moment while non-agile processes enforce proper planning. As a result of the slower time to market more formal processes prevent short-run ideas from being implemented and consuming resources that were better spent working on future-proof core requirements. Besides this those short-run requirements clutter the system if not properly removed once they are no longer needed.
A nice solution is to use differnt processes for differnt systems. Agile processes are best deployed for systems with a short lifetime and requirements that are not fully understood upfront. Examples for this kind of systems are public facing web applications like web stores. More formal processes are well suited for core systems with a long lifetime where maintenance cost is an important factor and stability is key.
This separation allows new ideas to be tested in an agile environment and move them to core systems once they become mature and turn out to be important features in the long run. When they will finally reach the core system the requirements are well understood and can easily be specified in a formal way - so the formal process is not a burden but a line of defense for feature creep.
Which systems belong to which category depends on the type of your business. If you are a bank your accounting systems will probably fit the "core" category as will the systems needed for compliance and trading. The public facing systems and systems mainly used for sales could benefit from an agile process.
The following questions may help you when you classify your own systems:
- How long do you expect the system to live?
- How stable are the requirements for the system?
- Will your system undergo frequent changes?
- How important is the system for your company in the long run?
If you are planning new systems you can also use this classification to define your system boundaries.
The specified call count is not a number: null
Acegi + DWR + IE6 - ActiveX = Boom!
Today we had an interesting bug in a small web application developed for a customer in the financial industry. The application is based on the Spring Framework, secured by Acegi Security and makes heavy use of AJAX (powered by DWR).
Everything went fine while testing with different browsers from Firefox to Safari and Internet Explorer in different versions. Finally we have started testing in the target environment - well locked down and without support for ActiveX controls from untrusted sites. IE6 needs ActiveX for its implementation of XMLHttpRequest (XHR) - the heart of AJAX. If XHR is not available DWR automatically switches to using IFrames to emulate XHR. This usually works well and has already been used in the previous version. Nevertheless the application just didn't work: Every remote call failed with a not so user friendly error message: "The specified call count is not a number: null".
Remote debugging of Tomcat showed that DWR is trying the read the request data using req.getInputStream() to parse it. When using IFrames reading from the request's input stream fails immediately and returns null, when using XHR it works fine. The main difference is the content type of the requests "application/x-www-form-urlencoded" for IFrames and "text/plain" for XHR. As IFrames do work without Acegi but fail with the Acegi filters in place I guess Acegi does mess with the requests when it wraps them in its SavedRequestAwareWrapper.
I didn't have the time to further track it down, but I created a small workaround that falls back to using req.getParameter() if reading the stream fails.
The following snippet shows the modification made to DWR's ParseUtil.java:
in = new BufferedReader(new InputStreamReader(req.getInputStream()));
while (true)
{
String line = in.readLine();
if (line == null)
{
if (paramMap.isEmpty())
{
Enumeration nameEnum = req.getParameterNames();
while(nameEnum.hasMoreElements())
{
String name = (String) nameEnum.nextElement();
paramMap.put(name, req.getParameter(name));
}
}
break;
}
...
And who is to blame? Well, as with many interesting problems that's hard to decide. It's just a combination of multiple pieces of software mixed with environment constraints. I guess it's something that just happens and reminds us that testing is not useless.
Update 2008-02-22
Joe has just released DWR 2.0.3 that includes a fix for this issue.
Will the BEA Acquisition Push Spring Framework?
Alternative stacks may gain more attention in response to Oracle's acquisition of BEA
BEA is well known for its J2EE application server Weblogic and recently extended its product line to a SOA stack branded Liquid. Oracle has its own J2EE compontents mainly derived from Orion Server and branded as OC4J. They also have a SOA stack called Fusion.
So you might ask what the future of these products will be.
Oracle already acquired three different business application suites in the past: J. D. Edwards, PeopleSoft and Siebel. Does it make sense to develop three different product lines of business application suites and at least two different product lines of Java EE and SOA middleware? Probably not.
This uncertain future may make companies reevaluate their current technology stack for middleware applications. They will notice that there is an alternative beyond the IBM Websphere dinosaur and JBoss which is now RedHat. The alternative is Apache Tomcat and Spring Framework mixed with some Terracotta if you need distributed shared data.
Spring basically allows you to assemble your own application server. Transaction management, security, remoting, O/R mapping, clustering – just add what you need when you need it. Basically there is not much left where Spring does not offer a proven solution. On the other hand the features where commercial J2EE servers have been strong in the past (compared to other stacks) are becoming less important:
- EJB remoting will be replaced by web services
- entity bean style O/R mapping has already been replaced by Hibernate (where EJB3 tries to catch on)
- load distribution and fail-over is easy in a world of HTTP or JMS based web services
- clustering of data is less important in the stateless world of services
In the end the uncertainty caused by Oracle's acquisition of BEA could very well further increase the growth of Spring and the open source components it makes so easy to combine.
Yahoo! Supports OpenID and AOL Plays With XMPP
Increased Awareness of Open Standards?
Yahoo! officially announced support for OpenID for all its users. OpenID is a decentralized single sign-on protocol already supported by an increasing number of web sites like LiveJournal, Zooomr and Blogger. Yahoo!'s OpenID service will be available in public beta on January 30th.
There have been rumors about AOL playing with XMPP. They've setup a test server at xmpp.oscar.aol.com that allows connections with most Jabber clients out there. You can try to log in to ICQ with the username icqnumber@aol.com on server xmpp.oscar.aol.com on port 5222. TLS is required.
The server is a bit overloaded right now so you might encounter connection problemns. As far as I know there hasn't been an official announcement for the new service from AOL.
It seems they do not (yet?) support server to server connections so you can't add AOL contacts to your XMPP buddy list of another provider, but maybe they change this later on.
The increased awareness of big sites with regard to open standards looks really promising. Let's see what 2008 will bring us.
MobileKnox: Your Mobile Password Safe
Do you also tend to forget your passwords?
Though there are some great ideas around to provide a global single sign-on infrastructure for web applications like OpenID today's reality is different:
- usually one account per web site - hopefully with different passwords
- IMAP accounts for email
- accounts for instant messaging networks (MSN, ICQ, Jabber)
- accounts for your workstations at work, at home and for your notebook
- PINs for your various credit and debit cards
- account numbers and PINs for online and telephone banking
- access codes for door locks and physical access control
- and you probably can think of a lot more...
MobileKnox aims to make your life a bit easier by providing a secure store for your account data on your mobile phone.
If you are like me your mobile will always be with you. That means you will always have access to your credentials whether you are at work, at home or on the road.
MobileKnox runs on most Java-enabled mobiles and PDAs and is accompanied with a small desktop application that runs on all major platforms (Windows, Mac, Linux) to synchronize passwords with your device.
References
Tips for Honest Programming
Keep your code moral
Chalain blogged about Dishonest Programming and provides a few tips on how to write moral code by being honest with yourself, with the compiler, and with your coworkers.
I think the first ones are most important:
- Name functions for what they really do.
Make sure your functions do what the name implies. Review your code to identify large parts that are doing different things like checking for preconditions or handling errors and extract them. - Let your yea mean yea and your nil mean nil.
If you write a function called createLink() it should create a link or clearly indicate failure (e.g. by throwing an exception). Side effects that are not reflected by the name should be well documented.
Few code is ever written to be dishonest but as new features are added and bugs get fixed in a hurry it is easy to become immoral.
References
Sin-Yaw Wang: A Theory in Compensation
Learning new skills pays off
Sin-Yaw Wang put up a nice Theory in Compensation:
Your earned pay reflects the improvements of your skills. Companies do this in a zig-zag way: sometime over-paying and sometime under. The gap between these two lines cannot be too wide for too long. Either you will find a new job that pays your market rate, or the company will fire you for not giving your money's worth.
He concludes:
Ask first, when you are thinking of a new job, if you will be learning new skills. Don't ask if it pays better. You compensation will keep up with your skills, sooner or later. If you are not learning new skills, then you are simply being harvested.
Well said. I guess many companies out there just find it easier to pay more than to make sure their employees gain a real chance to develop their skills.
My experience is that even if they deploy formal processes for career planning, they often miss the point in what really matters to increase the value of their employees.
References
- Sin-Yaw Wang: A Theory in Compensation