How important is the programming language?

 Python, typescript, java, kotlin, C#, .net…

Which is your technology of choice? Which one are you currently working in and which do you want to work in?

These have been questions I have faced in recent times. 

After spending almost 20 years immersed in the java space, banging out umpteen lines of java, many feature requests and multiple successful software projects; late in 2019 I was lucky enough to land a job doing python. Even though I hadn’t ever written a line of code in python for real money. I counted myself lucky.

Then after a year and a half spent mastering python I got the same opportunity in the C#/dotnet space, and I found myself contributing to c# code bases, and then after a year in that it was the turn of typescript to take the fore.

Every time I come to a new technology I am excited by the prospect of potentially putting behind me all the challenges and headaches that I experienced in the previous language. Maybe this next one will be the platform that will streamline my coding and deliver business solutions without hiccup and roadblock. 

Initially there is much excitement as I learn the new features and techniques of the new language. How it has creative solutions to some of the problems. How it takes a novel and clever approach to some of the other areas. But it doesn’t take long before I come back down to earth and realise anew that simply switching to a different language is not suddenly clear the runway for the delivery of software, on time, on budget and with all the features that were asked for - and without frustration and continue to do this as the project matures.

Let me cut to the chase…

Again and again I have learnt that the language is secondary.

When doing carpentry it is obvious that simply switching to a different tool is not going to suddenly make you into master craftsman. Yes, tools help, but they cannot replace effort, creativity, discipline and diligence and they cannot replace years of experience in the trenches.

And the same goes for software development.

Languages are not unimportant and do play a role in how productive we are as developers but they are not the primary driver of whether our software meets expectations, whether our environment is a rewarding one to work in and whether or not we deliver on the business case.

In modern software development, old familiar aspects like commitment to quality, testing regime, using SDLC best practices, using the best tools and the best processes and working with the best people are more important than whether you’re using typescript, java, kotlin, c# or python. Do you keep up to date, do you test? Do you use CI, do you commit regularly? Do you have up to date documentation, is your code “clean” and does it subscribe to best of breed architectural guidelines are far more important metrics of whether you are going to be successful or not.

Thus for my next opportunity, the language will be secondary.

Guava's Collections...

Oh the names developers come up with...

Guava is the new name for the amalgamated set of lightweight java libraries google has produced. It includes what used be google collections.

In a nutshell, guava's collections are commons collections built with 1.5 language features. Generics and other syntactic sugar.

If you're a java developer and haven't seen them or are not using them, then you're wasting a lot of time.

Especially in testing.

You need to create a small list, of say, 3 elements to pass into a SIT.

Typical solution:

List list = Arrays.asList(new Object[]{"1", "2", "3"});

Solution when using guava:

Lists.newArrayList("1", "2", "3");

 Eminently more readable, succinct and to the point.

The other useful commons collections features are also supported... e.g. filtering.

One example I'll supply is a filter which submits to the generic type:

example...


    public Iterable getSquares() {
return Iterables.filter(shapes, Square.class);
    }

With a more ordinary filter, the return type of the filter would have to be the same as the type that is passed in (in this case the shapes collection). Not with this funky mechanism. Unfortunately, guava does not have the same feature when working with sets and lists. I guess you could just wrap this Iterable in a set, but that would mean having to iterate over the collection up front.

Maven... for uninitiated

Having been around the java landscape for a while, I couldn't help but run into the tool known as maven. It is fairly accurate to say that maven is ubuiquitous. Having tried maven briefly in the past and given up I decided to bite the bullet and get down and learn maven.

I had help in the form of the book, Maven, a Definitive guide which eased my passage into maven.

A few weeks ago I thought I'd give maven a try. I tried it out, hit a few problems and then gave up. That I refer to as my firstcoming to maven. Then after another few weeks I thought I'd give maven a second chance, this time I was a lot more successful. So having been using maven for more than a few weeks now, and especially having had two bites of the cherry, it is safe to say that although I am not a fan boy and a maven evangelist, I am a convert in the sense that I would want to use it on the applications I build. Let me say that this opinion can change as I mature in my thinking on maven as I extend into more areas of maven's capability.

Firstly, Why use Maven?

1. Dependency management - what a pleasure it has been to simply right click (since I'm using m2eclipse) on my project, select add dependency, type in a few letters of the dependency, and select the dependency and it is automatically downloaded and available. No more trawling the internet for that lost dependency... it's right there when you need it.

2. It provides a platform for adding value. This sounds a little nebulous, I understand, but once you've created all the maven infrastructure you can easily build on top of that through plugins. My test case was a back end app offering a bunch of services exposed through REST. I discovered the jetty plugin for maven - with this plugin, I simply checkout the code, run the maven build and then execute the plugin. Maven starts jetty and deploys my application to it. A very simple way for other developers who need to call into my web app to get access to it. A few command line intructions and my app is running


Some important considerations when starting the journey:

1. Take it slow. Maven, is complicated. It's not good rushing into it, trying a few things, getting frustrated and then backing out. That was the mistake I made initially dived head long into maven, and hit my head more than a few times. There are a number of irritations which should not actually be there, which put me off. These irritations had work arounds which I have since found, but at the same I found them very irritating.

2. Use a local repository - a lot of the irritations of using maven can be resolved if you run a local repository. One of the major changes in thinking when coming the ant or the IDE build world is that with maven _all_ dependencies are imported, no dependencies are placed with the source code _at all_. So if you need to just quickly add this dependency to your build... don't go there. Maven coerces you to put that dependency into a repository and then reference it from elsewhere. Yes, you can install it to your local repo but the command to do this is clunky. Rather just install it on your local repository.

3. Don't try and do it the non maven way - maven is _very_ opinionated. It expects your code to be arranged in a very particular way. Do not try and fight with this. Resistance is futile. Standards are good and work well because they are used by all, not necessarily because they are the best way of doing things. You might think you know better than maven, that's fine - try and be different and you'll soon hit a wall.

A few of the problems I had, and will still need to deal with:

1. I think one of the problems with maven is that not all the code libraries int he world are available via maven repositories. If this were the case, chances are there would be a lot less pain. In my first coming to maven I quickly hit a problem when I added log4j as a dependency. Log4j supports jms based connectors etc and since these libraries have a more restrictive license they are not available from the primary maven repository. So when you add log4j as a dependency, the build simply fails. One work around is to download these artifacts manually and install them - something I wasn't willing to do as what's the point of using maven if I have to download dependencies manually right? At my second coming to maven I discovered that you can configure your dependencies to not include certain transitive dependencies. I excluded these unavailable via maven repository dependencies and my frustration was removed.

2. Handling third party dependencies - I had to make a connection to a mysql database. The mysql jdbc jar is obviously not available in a maven repository. This is where the local repository, artifactory or nexus come in. I figured out how to deploy this jar to this repository and no more problems. I was now doing things the maven way.

In summary, for now I am using maven. It has filled a big gap in my arsenal. A replacement for maven would have very big shoes to fill that I'm not sure I will go back.

But we will see...

New Things Ahead

Hi Everyone...

As you know I have not posted in a very long time. The primary reason for this is that I have not really been doing anything particularly interesting over the last year. This is about to change, as of next week, I will be joining a new startup development company that specialises in mobile and internet applications... This promises to be fertile ground for more posts.

I will also be looking at redesigning this blog - giving blogger.com's templates a run around.

Headless Build, who needs it?

Yes, who would need a build that does not have a Head? That sounds like it's out of a horror story.

What I mean however is a build which does not require an IDE and is not invoked by the IDE, so is thus probably ant though it could potentially be maven, or a shell script or an msbuild invocation - you can do headless builds with something other than ant.

To my mind having a headless build is a no brainer, but you'd be surprised how many development contexts do not have this. So why is a headless build so important and why do some context not have one?

1. Headless builds do not require the IDE

Why is this important? It's probably more an architectural/soft advantage. I mean why would you spend time replicating offline what you can do in an IDE. The primary advantage here is that it means that it allows a whole slew of other tweaks, so this is not valuable in and of itself but it is what allows other advantages.

2. Headless builds are repeatable - this is the no brainer reason why you want headless build - so that you can have repeatable builds. The problem with building from the IDE is that you never actually know what code the developer had in his workspace when he made the build. If you don't know what code is in a build you don't know where to go to fix the problems. Maybe the problem stems from that random code the developer was working on when he made the build. I would go so far as to say that a build made from a developers workstation is about as much use as old chewing gum.
3. Headless builds do not require a developer - the last thing I want as a developer is to be keep getting queries saying, please come and do a build for us. I don't think the downstream entities (testers, deployment people) want to do this, but in a context with no headless build they are forced into doing this. What is more is these people cannot do more than click a "build" link to make a build. They certainly cannot start the IDE, check the code out, select the project, select build all, then do an export etc. They certainly, since they are not developers, cannot use an IDE to make their own build.
4. Headless builds are automated - once you have headless build infrastructure in place, be it ant, msbuild or shell scripting, you can build on that basis by adding things like tagging of the code, tagging of the generated artifact. Maybe even include in the built artifact some mechanism to show the tester the version tag. No uncertainty as far as which version of the code you're running.

You might be saying, surely in some cases, in some small cases that it is not necessary to do the work of creating a headless build mechanism. I'm not so sure. Yes, developers could be disciplined and make sure whenever they build that the code has no changes, but even with that, it is still not clear what version of the code is deployed. On a recent project we did not have a headless build and there was always a degree of uncertainty as to what version of the code was deployed, what version of the code is running. I regret not being allocated enough time to implement a headless build for that context. It caused us pain, even if the project was really small. If it is automated by a script it will happen _every_ time and it can be trusted. I cannot trust a developer to always follow the steps they're supposed to - not because they're not trustworthy, but because the developer cannot prove to me after the fact that they did all the steps they were supposed to.

Annotations or XML

I just commented on a post at stackoverflow asking for suggestions of criteria which should be used to compare the annotation or xml approach when configuring classes for hibernate or spring. Saying then that a decision will be reached on which one is "better".

I responded to the post and you can see it here.

While an interesting academic exercise, I don't foresee it having any real value. The decision on whether to go annotations or xml is made solely on a case by case basis.

But then I asked myself, what are the conditions under which xml/annotations are used with reference to configuring spring beans.

I was on a project where we had hundreds of beans - we were working under Java 1.4 so could not use annotations. We went so far as to use xdoclet where you add the annotation information as javadoc tags in an attempt to account for this constraint. It wasn't ideal as you have to generate the xml from the source code and thus the xml can easily be out of sync - don't have to do that when using annotations.

So in that context, annotations won, and to my mind, for many "workhorse" beans it's a no brainer. Maintaining the xml for hundreds of beans where no custom configuration is required, annotations is definitely better. Annotations handle refactoring, method name changes, classname changes, even certain structural changes require no adjustment to the annotations.

So is xml now defunct, have annotations killed the xml star?

No - there are two contexts where I am essentially forced to use xml.

1. Where I want to customise configuration.

So I want to be able to specify different values for beans, or if I want to change the bean I'm injecting into another bean. I want to be able change property values. Doing this with annotations though possible would be too unwieldy. While it's possible to run Windows Vista, that doesn't make it a good idea.

2. Where I don't have access to the source code of the classes I want to create as beans i.e. where I want to re-use classes from other libraries.

Because I don't have access to the source code and/or I want to potentially create more than one bean from the same class, xml is the preferred approach here. The key difference between xml and annotations it that when using annotations I do not have to specify the details of the class, i.e. I do not have to contextualise the information I'm adding, it is already contextualised because it is connected with a class, field or method. With xml I always have to add this contextualising information.

In my current project I have a small xml file which has all the beans created from re-usable components in it, and that's all. Everything else is done via annotations.

That's how it should be?

If I had R10 or a dollar, for the amount of times developers assume something because they say it "should" be like that, I would be rich.

I must admit, I find it a bit weird that they assume things because it is how it "should" be as if the computer is morally obliged to be like that. We say things like "It should rain tomorrow" or "You should not steal"... implying either that there is some uncertainty to the statement or that it is a recommended thing to do.

Notice that with the use of "should" there is NO certainty - why I find it strange that developers even use the word "should" with reference to code. Developers should only be talking in absolutes when talking about code behaviour, and until they can talk in absolutes they should keep their mouth shut.

After all, they have the code in front of them; they can look at it - if it's a spec they're looking at, yes, the behaviour specified in the spec "should" (correct use) be what the code does. That is how things are setup, but if you have the code in front of you, I don't want to hear "should". Why take the risk of the "should".

Just today this is what happened. A method was taking a string and the string was called "status". Now there is also an Enum called "status", and the developer figured well, that "status" and the enum status should both have the same "toString". iow, the toString of the enum should map to the valid strings that the method understands... a big should. If that is the case then why does the method not take an enum.

Now, yes, it should be like that, but is it? In this context I'm not interested in should. This shouldn't cause a bug is just not good enough.

A cursory glance at the code should, oh sorry, can, often lead to the resolution of the doubt, and in this case, the assumption was proved wrong, causing a time wasting bug.

So in a development environment when one is asking how is the code behaving, one should never hear "should".