Category Archives: Work

Software, Work

The cruel young men and their DSLs

When faced with the question about how people are meant to learn more and more languages some pundits say that perhaps people shouldn’t be programmers if they cannot learn new languages. When you’re young, bright and brilliant that may seem a reasonable answer. However the truth is that no matter how high you try to set the bar on programming, the amount of programming to be done is far in excess of the capacity of the relatively small number of brilliant people in the world who are inclined to do it. Telling the people who make a living trying to answer this demand, with less stellar qualifications perhaps, that they should shape up or ship out isn’t going to win any friends.

It’s also pointlessly antagonistic. Getting to learn many languages should be seen as a chance to broaden and enhance skills. However that is not going to be attractive if organisations continue to provide incentives in terms of pay and opportunities to specialists. To respond negatively to the suggestion that you discard your hard-won investment in your language of choice is both natural and rational if you run the risk of earning less than the single-focus individual. DSLs will die a death unless they can be incorporated within the scope of an existing big beast language or employers adopt a capability rather than knowledge-based metric for pay rewards.

I also think that DSL aficionados often fail to point out to the broader audience of programmers that learning a DSL or even a variety of languages (most probably meaning at least one functional, dynamic and object-orientated language) will not be the same experience as the current depth learning of languages. Since a DSL should be for a specific purpose and have a small syntax or grammar customised to a particular problem or domain it will not be the same as being able to answer trivia such as what the problems with the Date API are in Java and what the Calendar class sets out to address and whether it succeeds or not. Interview questions may have to revolve around applying a new syntax for dealing with a particular problem instead of the usual language pop quiz.

Advocating languages as solutions should also involve advocating changes in employer priorities. If you don’t link the two then threatening someone’s livelihood actually makes it harder to achieve the DSL’ers joyful Babel of languages that matches tool to problem.

Standard
Java, Work

We don’t need no stinking relational data

A friend recently told me that the Java developers at his company treated the database as a datastore from which they took data and if they were in a good mood they might put it back too. Ah how we laughed… however secretly I thought that was rather unfair. Java developers generally have a tough time with databases and sometimes the things they do to them makes you want to scream but overall I think most respect the fact that an object-orientated language does one thing and an implementation of relational data does another, very different thing. After all you wouldn’t try to write an MP3 player in SQL… oh, hold on bad example you might not want to try that in Java either…

Anyway, any situation where you want to compare and relate data is likely to be a situation where you want to use SQL. Handling things like threaded programming, IO, cross-platform GUIs, scalable web applications are all likely to involve Java. This was proven to me by a Business Analyst who was cross-matching the output of two different systems. I tried to solve the problem by writing a Java application that essentially built up hash maps of various keys and then compared them. I thought it was pretty nifty but it was hard work and drilling down into why the failed matches failed was hard work.

The analyst, damn her, insisted that the output of the two programs be loaded into a database. She then took days to complete the entire reconcilation and was entirely capable of explaining and proving matches and non-matches. My method would probably have taken weeks and a lot of the output would probably have to be taken on trust.

It one of those moments where you can choose to be humble or humilated. Well it sounds bigger if you’re humble anyway but I think I learned an important lesson as a result. If people have spent twenty years or more perfecting a tool for a specific task don’t flatter yourself that you’ll do a better job from first principles with your preferred tool. It’s just a case of Golden Hammer syndrome.

However there are still a lot of Java developers who do think of the database as a datastore. And it is utter madness. If you are using Berkley DB you maybe have a point. But the minute you have a relational framework to your data then the database is not a datastore. It is a monstrously potent way of making data your bitch. Hundreds of developers have tried to move data processing out of the database and into the application layer. I have never witnessed one who has actually succeeded in doing anything than replicating a relational database in memory and the majority just created a catastrophic mess.

If you think the database is a datastore then step away from the database and do something else. Don’t try to bastardise relational algebra, like a lot of things in life it’ll just end in tears.

Standard
Java, Software, Work

Eclipse 3.3 M6

So I had a coding assignment to do the other day (it’s job seeking time again unfortunately) and I decided to to take the opportunity to test drive Eclipse 3.3M6 and Ant 1.7. Trying out software while also trying to make a good coding impression is probably a dumb idea and I don’t think I’ll be doing it again but still there’s never any better time than the present.

NetBeans has overtaken Eclipse as far as I am concerned, simply because Sun has managed to live up to the cross-platform hype with their Swing interface and seems to have lots of different interfaces to projects from other IDEs and various deployment platforms.

On the other hand I wouldn’t try and corral a legacy project into NetBeans. Eclipse is still my fave for that (and while things like the Web Tools project can be a mare to install and get running they do bring Enterprise functionality to an IDE that previously made you pay for it). So then is it worth getting excited about Eclipse Europa?

Sadly the answer seems to be no. There are a couple of nice tweaks to the interface but nothing major. In fact although I’ve used M6 at home a couple of times now I’m hard pressed to bring to mind what exactly is different (the refactoring dialog is a bit better for example). Stranger still, some aspects actually seem worse. Code Intelligence and Completion used to be Eclipse piece de resistance with NetBeans being a distinct second. This time though I had exactly the same issues with Eclipse as I did with NetBeans, wacky suggestions from obscure packages rather than the more obvious choices from, say, java.util or even the project I was working on. The good news is that Eclipse seems to learn quickly from previous choices and after an evening of coding was back to it’s usual self. Only some of the code templating seems to still be quirky.

Overall though after a years worth of feverish competition between NetBeans and Eclipse I was disappointed that Eclipse seems to be running out of steam or perhaps new ideas. Now my first thought was that perhaps there are only so many features that an IDE needs and perhaps we’re getting close to completion on them. That seems disappointing unambitious though and if there was nothing else to do I would say that some of the basics could do with a thorough revamping. Eclipse’s text editors are nothing to write home about with a lack of features that are standard in normal programmer’s editors (drag and drop seems particularly weird although there might be progress in 3.3) and options for the editors are still accessed via the labyrinthine preference menu rather than the intuitive right-clicking of the editor tab.

I’m not sure where Eclipse is going at the moment but I would be disappointed to see it just stand still, that’s good for no-one. Oh and before NetBeans gets all the love I do have to say that I was completely baffled by some Swing programming I was doing the other day in the NetBeans (not via Matisse), the problem turned out to be that I was running my class rather than the project and one rebuilds the application jar while the other doesn’t. There’s probably some logic in that but I don’t quite see it (probably because it’s tucked away in the run profile somewhere).

Standard
Java, Software, Work

Transfer Objects versus Value Objects

What are Transfer Objects and what are Value Objects? This is a question that has plagued me since I started Enterprise Java Programming. While Transfer Objects actually have a nice definition in the J2EE Design Patterns Value Objects are a different beast and various companies, individuals and organisations seem to have different ideas about what they are.

Some are naturally pretty hilarious (as are the implementations of most nebulous ideas in IT) the most ridiculous so far is that a Value Object is a collection of public fields. Pretty much like a struct in C. I think that came from a misunderstanding of the blueprint definition that states: the members in the Transfer Object are defined as public, thus eliminating the need for get and set methods. Of course you still need to make the fields final if the object is to be immutable and a value object by definition is immutable.

Now though I feel I have enough of a working understand of the ideas to offer the following definitions.

Firstly a Value Object must be immutable, serializable and it’s content must be publicly accessible.  The content of a Value Object can be accessible via public final fields but to avoid the internal data becoming part of the public interface access should ideally be abstracted via getter methods. A value object should always be initialised entirely via its constructor; nesting value objects if necessary to avoid excessively long constructors.

A Value Object can only be changed and persisted by the creation of a new Value Object based on the values of the original Value Object obtained.

A Transfer Object while similar in most respects is mutable. In addition there is a reasonable expectation that the Transfer Object will be persisted if it is returned to the originating layer. So for example if a Session Bean provides a Transfer Object as the return value of one of its methods it is reasonable to expect the API to also provide a method that accepts an instance of the same Transfer Object. Any changes communicated to the Bean will be persisted and consistent so that if the original method that obtained the instance is called again it returns the values that have been returned to the layer and not the original object.

In this respect a Transfer Object is more the statement of expected behaviour on a Java Bean. I went to a talk about EJB3 where the speaker mentioned the detached object anti-pattern and I couldn’t agree more. Value Objects and Transfer Objects are really only useful in situations where the recipient layer is not really going to modify the objects that much. As soon as you allow POJO clones of entities to change value during a user transaction then you tend to get into all kinds of problems. It is exactly this kind of situation that ORMs and Hibernate clones tend to fall apart. They are great at obtaining Value Lists and dreadful at the kind of heavy lifting that is actually difficult and is where Entity Beans came a cropper in the first place.

Standard
Java, Work

Eclipse Parameter Prediction

I’ve switched back to Eclipse as my IDE for work for various reasons (but the major one being that I know more about coercing existing source bases into Eclipse than how to do the corresponding project buggery in NetBeans).

I decided to rack up the Code Assistance, Auto-Completion and templating. To my delight in short methods I now sometimes feel that the machine is actually writing the code rather than me. The predictive parameter completion rarely makes totally wacko choices and the only real glitch I feel is that there is no way to suggest that certain String parameters are actually intended to be literals.

Since switching it on I feel a lot more productive!

Standard
Java, Web Applications, Work

Configuration Woes

I’ve had two big problems recently that both stemmed from configuration files. During my first weeks at my new job I just couldn’t get JSP Expression Language (commonly known just as EL) to work. Despite following the examples and the tutorial to the letter the results were always garbled and never quite what was described. However when I generated a new web application and deployed it the EL worked fine.

The answer turned out to be the servlet version specified in the web.xml (which is generated by XDoclet rather than being a single file that could have been checked immediately). Specifying version 2.3 in a version 2.4 container apparently just results in flaky rather than disabled behaviour.

Failing at the time to get EL to work I decided to stick with the Struts Tag Libraries as while I was no more familiar with them than the new JSP functionality, it is more likely that an entirely container-independent solution will work across platforms and containers.

However Struts gave me my second problem with the issue of having a 1.1 Struts jar but a DTD specifying 1.0. What I noticed about both problems is that there was no clear kind of error message or clue as to what was going wrong. I only noticed the issue with the Struts config when I had a clear example of 1.1 compliant behaviour that was not present in the app. With EL it was almost entirely random as I was actually looking at the construction of the Security element of the Descriptor.

My latest example of configuration creating as many headaches as it can solve come from a very simple source. I forgot one word (“jsp”, if you are curious) from the URI of a Tag Library and as a result wasted an afternoon trying to get something as simple as Number formatting to work. Apparently JSTL 1.0 didn’t allow you to specify an EL expression as a value to format. Which is both silly and confusing. The syntax for both was identical and because I was using a 1.1 implementation the code introspection implied I had the whole tag correct, it just threw a massive exception trail at runtime.

In all these cases what I found frustrating was that there was no issue at all during the build and development of the application. All the issues were found at runtime with a need for the whole system to be configured and functioning before I could test whether I could locate a variable or not. The other is that there was no real error message that conveyed the fact that I was trying to do something that was illegal for the version declared but possible for at least one of the versions available. Instead the developer has to have a strong knowledge of the feature set of each standard version and the way each feature is configured in either the container or the application.

Configuration of application runtime via XML is a powerful tool but without a way of validating that what you are specifying is correct prior to actually using the application it is actually a massive hindrance.

Standard
Work

New Job!

Woohoo! The big news is: new job. I started a couple of weeks ago and it is a welcome change from the old place. For a start the commute is not as big and while it is still a programming job the sector is very different and the “department” consists of exactly four people. Which is quite a bit different from the corporate jobs I’ve had before.

It’s also great not to be working in an industrial estate bounded by a dual carriageway and a railway. After two years of amenity drought I keep forgetting that I can pop into a supermarket, bank or post office if I need something done now.

Standard
Software, Work

Good enough never is

In my recent job I have come across an attitude of “good enough” more than once from various people. It’s never one I have subscribed to or agree with. I have a healthy agreement with the idea that perfection is the enemy of action but that is a different argument. Better something than nothing but once you have something more than nothing I don’t see the point in giving up and doing nothing more.

In fact I don’t understand the mentality that leads to the idea of good enough. There is a touch of the fatalistic about it, that we shouldn’t try and expect more than what has been achieved so far. Then again this could also be a variation of Panglossian pessimism: in this imperfect world we have the best imperfect solution we can hope for.

Personally I’m rarely satisfied with my work and the urge to revisit it and improve it is one of the attractions of permanent employment rather than contract work. Sometimes the revisitation is to fix issues of time and resource constraint during the initial work. Other times it is to revisit old work in the light of new experiences, to transfer the lessons of work done well to earlier projects. Sometimes it is just pure dissatisfaction, the knowledge that something could be better than it is. I always like to build in huge margins of performance and capacity (in fact some of my recent software has perhaps a 200 to 300% margin) which some people might criticise as being over-engineered however the important thing is that if you had a choice of a margin of 30% or 100% for the same budget, which would you choose? Ambition is what drives the search for that additional 70% and people who believe in “good enough” don’t have the ambition to find that little bit extra from their work.

My views are formed by my experience with SMS billing where no-one really foresaw or predicted the phenomenal growth in texting and text services. It took us all by surprise and if the software had a margin of 100% excess then it could be used in a quarter with exponentially more needed for the next quarter.

I think it is worth approaching every project as if it has the potential for being a huge success. I don’t think every project should be budgeted as if it might be a huge success because 90% of ideas never pan out quite the way anyone hopes (WAP is a good example of this). If you don’t think a project might result in a big success then there is a question about why you are doing it in the first place. If you, the implementer, don’t believe in a project then why the hell would else believe in it?

Even if you design for success you should always be prepared to return to a project and make improvements. My favourite example are web-based applications. Every time I come to a web application project it seems that the technology involved has evolved and all manner of new solutions to previously difficult problems are now available. What took weeks of effort in the past is now part of some standard library or tool, the weeks of effort can now be spent on getting way beyond the basics of the app and providing some reason why your application is going to stand out from the rest. I always enjoy ripping out some half-hearted custom solution to a problem that was written in-house with a standard piece of technology. For me change is progress and progress requires change.

Ultimately in business software you have to provide your own impetus for change and innovation or your competitors will. Someone will come and eat your lunch if you give them the chance. Perhaps that my problem with “good enough” is that it smacks of the fatal complacency that leads to losing contracts, losing jobs to cheaper labour countries and ultimately losing the lead in innovation and ideas.

Standard
Work

It’s not you it’s me…

In addition to getting Java Certified today I also had the weird experience of turning down a job offer. This is something I have never done before and more unusually still it was a bloody good job offer too.

As a first born child I tend to cling to convention, conservatism and safe choices. Despite this my supposedly safe career choices often turn out to be much more fraught with risk than I had realised. So I decided to do something risky for once, turn down the safe job that I could easily have done and try for something more risky, something that I might fail at. There are other reasons of course and most of them shouldn’t really go on a public blog. Still the main point is that it was a thoroughly good offer but it wasn’t really right for me. I think that passing the exam today definitely helped me think that I can afford to take a risk and enjoy what comes out of it.

Standard