Posts Tagged: architecture

Apr 10

Agile dilemma

The time has come to truly retire the word agile. I like the word. I love the idea of agility. But I’m starting to dislike how it’s starting to constrain software development and how it’s endlessly used in software literature these days for the lack of anything else to talk about I guess.

What was supposed to be as phrased in the agile manifesto:

Individuals and interactions over processes and tools

has become infested with these non-developer type parasites who at any sign of anything having a chance of making mainstream, inject their bureaucratic venom into it forcing a self preservation act by most smart developers. That act is to run for the hills.

So what happens next? Well, its a never ending lifecycle. Agile will reincarnate as something very similar to where its origins once lie, but in smaller development circles, until it’s crippled again. This cycle will repeat indefinitely. This cycle is not only apparent in software development lifecycle methodologies, but also in programming languages, frameworks, etc…

Software development is as much art as it is science and engineering. I think when some hear engineering, they think bridge engineering or what today has almost become a ubiquitous term for anyone doing anything. In engineering a bridge, one can reproduce rather predictable set of results. In developing software, one can’t. Engineering is as American Engineers’ Council for Professional Development put it: The creative application of scientific principles to design… Creative is the keyword here. Not constrained by process the kills creativity. We as professionals should be able to discerns these things and stop applying absolutes to the creative process. Just because we have successfully applied processes in the manufacturing discipline, doesn’t mean that same processes or processes at all, can be applied to software engineering. Sorry folks, no software factories for you.

Useful precise estimation is a delusion, and the sooner we realize it, the faster we can get back to developing quality software. Process is disadvantageous. All designed to give the businesses a warm fuzzy feeling of certainty around something that’s not certain. So why are there some that can give good estimates? There are only two reasons. One is that they are lucky. No really, they are lucky at predicting the unpredictable. This happens, trust me. Just ask someone who has a financial advisor and trusts them to set up their financial investment portfolio. Do you trust your financial advisor? If you do, please read Fooled by Randomness and The Black Swan. Also, there is actually one other reason for good estimation. Sorry developers for exposing this to your managers. This reason is overestimation. Yes, you heard it right. You overestimate, then you finish your task early, but instead of looking good by marking it as done early, which will in turn screw up estimation reports at the end of the sprint by showing that you chronically overestimate, you choose not to and though find something else to do to kill time or start on another task in case that one turns out to be underestimated. At the end of the project, you have accumulated so much time, that your friends have to ignore you on facebook and un-follow you on twitter.

One might say it doesn’t matter, as long as the overall estimates are close. Well, whatever makes you sleep better at night. Just know, software estimation is not science, it’s gambling.

Ah, one other thing, mostly related to XP. My favorite topic, Pair Programming. Sorry folks, this one’s not really for me. There are many issues with it. First, it’s disruptive in the way I think and to my personal creative process (I’m sure it’s not just me either). When I think, I don’t want anyone interrupting my train of thought just because they have an idea. Great, but if your idea doesn’t pan out, my idea just got lost in the shuffle, thanks for the context switch partner. In any other field that requires critical thinking, people work alone a lot (maybe not all the time). Just ask all the researchers. They come up with their best ideas/research and when ready, share those with colleagues or other researchers. They don’t gather up in a room and participate in committee based research. That would never work. One might say it’s because they are egotists. That might be true, but that’s not necessarily a bad quality being that it drives them to outperform someone else. At the end of the day, most innovations come from these weird acting egotists.

In pair programming, we have to be on the same schedule. When my brain doesn’t click, I like to go for a walk or pace around the room to get me into the creative process again. A lot of my ideas come not when I’m sitting at the desk writing code. Now, do I have to coordinate that schedule with my pairing partner? Should we hold hands and skip together? What about if I want to use the bathroom or grab a cup of tea? Should I be conscious as to ensure our bathroom/tea schedules are in synch? Are you kidding me? What is this, grade school all over again or a software factory (laughably some actually like that term).

Well here it goes. I’m a software artist/developer. I write code because I love to, not only because someone’s paying me big bucks to do it. I get aroused by solution revelations and enjoy compliments when I solve hard problems before others, or that others couldn’t, or in a more elegant/concise way than others. Software development is a creative process. It brings with it the ability to create a masterpiece. It’s also a process that requires critical thinking, reflection, and most of all “quite”. Private offices are great, but sometimes not realistic depending on the company’s financial situation. The office doesn’t have to be private, as long as what ever your arrangement is, it’s quite enough and not distracting for you to do your work without having to context switch every 10 minutes to hear some rant going on around you and/or answer questions. There are time for questions, but not when you’re in the zone.

I’d like to see Michelangelo or da Vinci create masterpieces under the constraints of a process. Better yet, I’d love to see those two pair paint.

We all don’t think or work the same. We’re humans. The key to good software is to hire great smart developers that can hold their own. Keep the teams small. The rest will be worked out as a team not as a process. It’s about common sense and good people, not processes.

Jan 10

Annoying exception

This exception has to be the most annoying one I’ve faced over the years with Java. I’m not sure which moron’s wrote the SSL library, but did they think about providing an option to disable ssl certificate validation? I wasn’t sure it was a requirement to have a valid certificate. I mean sure, it’s nice and provides that worm fuzzy security feeling, but when I’m developing and/or testing, can you please provide some way to disable this annoying thing? Either way, I dug into this today and figured it out. It’s actually as anything else in standard JDK, 100+ lines of code which they could of provided out of the box a simple boolean switch, instead your have to implement factories, interfaces, etc… WTF? Just to turn off certificate validation? Talk about over-engineering stuff.

So here is the code, which you can copy and paste into your project, instructions on how to use it are below…

import org.apache.commons.httpclient.protocol.Protocol;
import org.apache.commons.httpclient.protocol.ProtocolSocketFactory;




import org.apache.commons.httpclient.ConnectTimeoutException;
import org.apache.commons.httpclient.HttpClientError;
import org.apache.commons.httpclient.params.HttpConnectionParams;
import org.apache.commons.httpclient.protocol.SecureProtocolSocketFactory;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public static class TrustAllSSLProtocolSocketFactory implements ProtocolSocketFactory {

    public static void initialize() {
        Protocol.registerProtocol("https", new Protocol("https", new TrustAllSSLProtocolSocketFactory(), 443));

    private SSLContext sslcontext = null;

    private static TrustManager trustAllCerts =
            new X509TrustManager() {
                public[] getAcceptedIssuers() { return null; }
                public void checkClientTrusted([] certs, String authType) {}
                public void checkServerTrusted([] certs, String authType) {}

     * Constructor for TrustAllSSLProtocolSocketFactory.
    private TrustAllSSLProtocolSocketFactory() {

    private static SSLContext createSSLContext() {
        try {
            SSLContext context = SSLContext.getInstance("SSL");
            context.init(null, new TrustManager[]{trustAllCerts}, null);
            return context;
        } catch (Exception e) {
            throw new HttpClientError(e.toString());

    private SSLContext getSSLContext() {
        if (this.sslcontext == null) {
            this.sslcontext = createSSLContext();
        return this.sslcontext;

    public Socket createSocket(String host, int port, InetAddress clientHost, int clientPort)
            throws IOException, UnknownHostException {
        return getSSLContext().getSocketFactory().createSocket(host, port, clientHost, clientPort);

    public Socket createSocket(final String host, final int port, final InetAddress localAddress,
                               final int localPort, final HttpConnectionParams params
    ) throws IOException, UnknownHostException, ConnectTimeoutException {
        if (params == null) throw new IllegalArgumentException("Parameters may not be null");
        int timeout = params.getConnectionTimeout();
        SocketFactory socketfactory = getSSLContext().getSocketFactory();
        if (timeout == 0) return socketfactory.createSocket(host, port, localAddress, localPort);
        else {
            Socket socket = socketfactory.createSocket();
            SocketAddress localaddr = new InetSocketAddress(localAddress, localPort);
            SocketAddress remoteaddr = new InetSocketAddress(host, port);
            socket.connect(remoteaddr, timeout);
            return socket;

    public Socket createSocket(String host, int port) throws IOException, UnknownHostException {
        return getSSLContext().getSocketFactory().createSocket(host, port);

    public Socket createSocket(Socket socket, String host, int port, boolean autoClose)
            throws IOException, UnknownHostException {
        return getSSLContext().getSocketFactory().createSocket(socket, host, port, autoClose);

    public boolean equals(Object obj) {
        return ((obj != null) && obj.getClass().equals(TrustAllSSLProtocolSocketFactory.class));

    public int hashCode() {
        return TrustAllSSLProtocolSocketFactory.class.hashCode();

Now all you have to do is call TrustAllSSLProtocolSocketFactory.initialize() anywhere in your application initialization code or right before you access any https resources, either through the URL class or through any other library, like HttpClient.

Hope this helps, though it’s still a pretty ugly hack IMO.

Aug 09

RESTfully insane or insanely RESTful

First let me say, I love REST. I really enjoy its implementation simplicity and the fact that it’s mostly based on HTTP, for which frameworks have been developed and bullet tested for quite some time. I can’t same the same for SOAP and its convoluted related set of standards. Complexity is never good, but its especially not good when it’s not needed to accomplish a particular task at hand. That’s how SOAP and WS-* feels to me. Out of hundreds of times that I was forced to use it, there might have been a handful of valid scenarios when a simpler solution wouldn’t suffice.

So now that I got the fact that I enjoy REST out in the open, I feel that RESTful architectures need more time to evolve and develop a set of patterns. There just isn’t enough empirical information at this point to truly come up wit a set of patterns. Yes, there are books that are great and various other sources of information which help, but I wouldn’t per say call them real architectural patterns at this point, more like a set of experiences developing one or two applications that are labeled as patterns because of its buzzword status and ability to sell books. Patterns are extracted through years and years of empirical information gathering.

Today I was working on an interface, and trying to follow the good ol’ RESTful idioms to design a RESTful API for a particular service. I quickly realized that the constraints of destructive and non-destructive operations bound to particular verbs is a beauty when in its pure form, but don’t always elegantly allow you to model a use-case.

Take my use case as an example. We have a graphing services API which provides graphs to application clients. These clients can be a web front end, or any other client of choosing. Graphs take time to generate, so we want to create the graph resource on a PUT request and then expose a URI with which this graph can be accessed. Easy enough, sure, this is programming REST 101. But here is a catch. Depending on the resource, its lifecycle state changes based on various constraints. One of those resources has a constraint that it can only ever be viewed once and must be destroyed or not allowed to be accessed ever again. So for each graph request, we PUT and GET. But that means that the GET operation is now a destructible operation, which is supposedly against RESTful principals. Someone mentioned to me that such operations should be put behind a POST request, though you generate and return the resource. That’s fine, except there are constraints. If this resource is an image, which is what it is in the graph’s case, it must be embedded in the src=”uri” attribute of the image element in the html page. So can’t POST there. But even if we can use a POST in this case, what about the case where we want a resource accessed a certain amount of times, or what if we want to track the amount of time this resource is accessed, or what if accessing the resource is a stateful operation which modifies other state, whether its own resource’s state or some other resource’s state. One will say that something’s amiss here, but that’s not true. In imperative languages, state is king (not that it’s a good thing), but it’s really easy to model real world interaction scenarios. Where looking at something, or someone, changes some property about what ever you’re looking at. If a pretty lady looks at a guys (who’s a resource), his state will change or it will trigger an action, he will either perform an action, like going over and talking to the lady, or get nervous and start sweating, either one of these actions where triggered by resource view operation. Sorry, maybe it’s not the best example, but the only one that popped into my head at this time of night.

Now, you get my point? I think REST is great, but the lesson here is that you should approach it just like anything else, with caution. When you see something that can’t be done with RESTful purity, don’t beat yourself up. REST is not yet fully mature and we are yet to discover things we can and cannot do with it given today’s interpretation of what it should be. Things change with time, so just do what makes sense today.