Plunkett

A Taste of Scala

2011-08-30T20:33:00Z

Recently at the Queensland JVM Meetup group I gave a Scala introduction presentation, with some good 'ol Java bashing to boot.

Check it out. Slides here.

Java is the new COBOL

2011-08-03T20:00:00Z

Apart from complaining about Clearcase I have actually done some real work the past few years.

Chapter 1: How we converted our entire COBOL code-base to Java (sort-of).

Already you might start to feel a sick feeling in the back of your throat. That's normal and should pass shortly after you finish reading.

COBOL? WTF?!? This is usually the first thing people say to me when I tell them about what I've been working on. I'm sad to say that COBOL is still very much in use.

The dilemma that our company faced was that our main product has been around for many years and over time we have built up a unbelievably large code-base of COBOL, consisting of millions of lines. Re-writing this is both costly and time-consuming, not to mention risky. We needed another option.

Another serious problem is that the upfront cost of CICS, the COBOL 'application server' if you will, running on dedicated Mainframe hardware, plus the cost of Micro Focus licenses, for compiling COBOL, is bloody expensive. If we could run on a 100% Java stack, using open source technologies, we could save ourselves, and our customers, cold, hard cash.

At this point I need to mention something 'special' about how we use COBOL. To support a wide-range of transaction systems and databases we developed a custom variation of the language, which included custom-built 'macros' which generate unique code depending on the environment. While not especially relevant to this article, this leads to larger-than-expected COBOL (which is large enough as it is). The size of the program is significant for a few reasons, which I'll discuss below.

Initially we started with LegacyJ, a commercial product that advertised productive COBOL to Java conversion. What was nice about using LegacyJ was that we quickly discovered that it was, in fact, possible to convert our code successfully and have a running system. However, we ran into a few serious problems that made us hesitate.

Firstly, the Java generated by LegacyJ was quite lengthy and often didn't compile due to the length of some methods and number of fields. Apparently Java has a limit, not that you would ever conceivably reach it. To work around this I had to re-parse the Java to break these methods into smaller chunks and introduce a hierarchy of classes to work-around the field limit. Yuck.

Secondly, the classes generated by LegacyJ didn't separate the idea of 'meta' information such as variable types from runtime data. For each instance of a program, variables had effectively duplicate copies of type information, resulting in an extra-large memory footprint.

The other issue, and perhaps the most compelling, was that of money; LegacyJ was not cheap. We were trading one expensive platform, CICS, with another.

At the same time the following article appeared, introducing an open-source COBOL to Java converter called NACA. I tried it almost immediately but quickly found that many of our COBOL programs didn't compile due to some commands that NACA hadn't implemented. At first I gave up and went back to our LegacyJ integration. It was only later, after taking a second look, that I realised there was much more potential on NACA's generated Java and general approach.

The most obvious was that the Java was actually readable! At least if you count this as readable. NACA actually checked-in their Java files after the conversion, so the code had to be both readable and maintainable. This also had the nice side-effect of allowing our absolutely massive generated COBOL programs to compile (in 99% of cases anyway).

In addition there was a separate and static class structure representing the program definition, meaning that each program required less memory.

I was given some time to investigate the possibility of making NACA work with our unique flavour of COBOL. Fortunately it turned out there wasn't too much missing and I managed to get a working prototype in a reasonably short period of time. After that the decision to switch to a cheaper and open-source alternative which we could control wasn't hard to make and we haven't looked back since.

To avoid making this post longer that it already is I might save the important discussion of performance for another day. In short our pure-Java application runs surprisingly quickly. The biggest bottleneck is, without a doubt, one of memory. Running an entire-COBOL runtime within the JVM is obviously costly in terms of memory, not helped by our generated COBOL and vast code-base.

Do I recommend this approach to others? Absolutely, without a doubt. There seems to be people advising against a direct port, or at least re-thinking the problem first. For us the issue is one of scale. There simply isn't enough time/money to re-write everything, at least not in this decade. We needed to do something now; something we could guarantee would continue to work.

The benefits of running a pure-Java stack are, alone, compelling. One example that springs to mind is that of tracing. Once upon a time we would need to ask customers with a bug to recompile specific applications in trace mode in the vain hope that we actually knew where the problem was. Now we can leverage powerful Java logging (no, not that useless java.util.logging) and have full tracing across the entire stack; something that is invaluable for customer support.

So, while I hate the idea of granting further life to our hideous COBOL demon, from a business point-of-view it has been crucial in the continued success and evolution of our product; giving us breathing room to slowly migrate COBOL logic to 'normal' Java applications while guaranteeing our business logic continues to serve our customers. Or at least that's what our marketing brochures say; for me it was fun.

Blogofile

2011-06-02T20:21:00Z

Inspired by my friend OJ, I've decided to make the switch to Blogofile. I guess I have too much time on my hands.

There isn't much I can say on this subject that hasn't already been said. This script came in handy to convert my Blogger posts across.

My biggest hurdle was finding a new host and being a complete cheapskate. I couldn't seem to find a free and simple HTML site. I started to think about Dropbox, until I realised that they don't respect index.html files. Fortunately someone had a neat idea - host it on GitHub!

One thing would have been nice is a selection of out-the-box themes; but completely understandable that there isn't. In the meantime I ported my current Blogger theme, which was surprisingly painless.

I'll probably be tweaking bits-and-pieces of the site in the next few weeks, like a child playing with a new toy. Procrastinating instead of, say, writing new blog posts.

Who needs documentation anyway?

2011-05-20T19:41:18Z

So, we have a dilemma at work. How do the developers and documentation teams collaborate on a single set of documentation files while using familiar tools? Is such a thing possible or am I dreaming?

Currently the documentation team at our work uses Author-it, a full-blown authoring 'solution'. For some time we, the developers, were been sent Word documents which we updated and emailed back. At this point the source control fanatic in me started to twitch. It's a document - just like source code - can I see who did what changes? How do two people work on the same document at the same time, and what about conflicts? Can I have multiple version of the same document? The other problem was one of cost; Author-it is too expensive to justify individual licenses for developers.

We had talked about switching to a more text-based documentation system on-and-off for some time. Finally I cracked and decided to just do it.

Latex was the first possibility that surfaced. However, as I thought about it more the idea of everyone having to learn obtuse Latex syntax before writing a single-line of documentation was a little off-putting. Note: I really do like Latex, but I felt like it might have been overly complicated for our situation.

The second alternative was to use a publication format like Docbook or DITA. While certainly a powerful way to group content, the prospect of living in XML hell didn't enthuse me all that much. I already get enough of that in Java-land thank you very much.

My final option was to use a lightweight markup langague, like Markdown or reStructureText (ReST), which GitHub actively promotes for their README files. This felt like the right fit for us, and without further consultation I converted our current internal word documents to ReST, added them to Git and created a Jenkin job to output PDF and HTML files. Bam!

At this point us developers were happy again. We were back to using our favourite source control for collaboration, without have to stuff around with emailing Word documents. We could quickly edit text files, use source control to track/merge changes and didn't have to worry any more about niggling presentation issues. My manager, on the other hand, who was away at the time, was not so pleased. (I swear this had nothing to do with the timing of my rash decision).

For us developers the idea of using a text editor to edit a document is a fairly comfortable one. For people used to - and who enjoy using - Word this was in some ways a big step backwards. No spell checking, no auto-complete, no drag 'n' drop. All that good stuff. Another complaint he had was about presentation - the PDF output wasn't slick enough to be used officially. Finally, if we wanted to switch to something else, ReST seemed to lack in some of the more powerful concepts required to support single-source publishing.

I could definitely be wrong but it feels like nothing has quite nailed this space in the space, at least in the OSS community. What would certainly help is a powerful and easy to use editor. Perhaps a plugin for Open Office would do the trick? Alternatively a browser-based editor, not too unlike this.

We're currently in a holding pattern at the moment. Developers are still (happily) using ReST, but the 'official' stuff is being written by the documentation team. Us and them.

I see a couple of available options:

What am I talking about, emailing Word documents around is fine - stop complaining.
Embrace Author-it and see if it can support more collaborators. Just looking at their website briefly it seems like they have an online review mode.
Meet my boss half-way, he can live without the nice GUI but we switch to a singe-source markup language like DocBook/DITA.
Everyone else be damned; developers rule; reStructuredText it is!

I'm curious what other people have done in similar situations.

Java logging and per-user tracing

2011-05-14T06:32:31Z

This is a fairly short post about my brief experiences with logging in Java. I realise it's 2011 and logging is very unsexy, but I thought I'd share anyway.

Let me just say this straight-up - Java Logging you are completely fucking useless. It boggles the mind how badly Sun screwed up the implementation of something so simple but yet so fundamental. It's logging for Christ's sake; how hard can it be?!? This captures the essence of my feelings, so I'll leave it at that.

One thing I did want to mention is Logback and the awesome SiftingAppender. Logback is the successor to the much loved Log4J, written by the same dude and addressing some of the problems with the original.

My manager wanted a way for our users to enable individual logging on the server and not require any meddling on the server by an administrator. A quick Google revealed this and from there it wasn't hard to implement a start/stop trace button on each page which harnesses MDC for per-user logging. On completion the trace can either be downloaded or emailed directly from the server to the system administrator or bug tracker.

Honestly, if/when I ever work on another online application I will almost certainly re-implement something very similar again. Being able to capture a trace of everything from the server for a single user session has proven to be an invaluable tool for diagnosing bugs. Give it a whirl!

Death of a Clearcase

2011-05-14T06:33:02Z

Well it's been quite some time since my last post. Time has moved on in many respects, and yet it also feels like very little has changed. Someone at work suggested that I should add a final post to the saga of migrating away from Clearcase at work.

The good news is: we won!

That is to say that we now use Git for a majority of projects at work, with the last few being migrated as we speak. Huzzah!

How did it happen?

Sadly my persistent nagging made very little difference in the end. Fortunately, however, money did; the cost of continued licensing of Clearcase was not attractive to the bean counters upstairs. Combined with the increasing globalisation of our team meant that Git, or at least a free DVCS, became a very real option (free being the operative word). Mercurial was the first choice, but by those who didn't have any hands-on experience with either; a mistake I have blogged about earlier. Given that my team and I had been using Git in-anger for at least 6 months we fortunately (or unfortunately) managed to convince them to think again.

We decided to host our source in The Cloud; specifically on GitHub. Now GitHub is an impressive site and I use it for all my open source projects. However, I do have one minor gripe: sadly GitHub has not yet implemented fine-grained security for Organisations. Given that the majority of users are open source and would most likely fork-on-write this makes sense. In our environment where we effectively work on a single repository it would be nicer if we could delegate a project leader or leaders and have them add/remove users for their team. Add the moment only 'Owners' can appear to do that, who can then also see billing information. The other problem is that with push authorisation you get force-push as well, which can be extremely dangerous in the hands of some. Not an ideal situation to be sure. Before the official migration we used the awesome gitolite which handled security beautifully, even down the branch/force push level. I would hope that at some point GitHub will adopt something more like that; but for now things are still 1 millions time better than using you-know-what and we can't complain too much.

I should add that the obvious rebuttal to this complaint is that we probably need to consider switching to a more distributed/pull-model of collaboration, where everyone has their own repository. I don't disagree with this necessarily, but having a push model gives us high visibility of changes and a quick development cycle. A discussion for another day perhaps.

And how about the users? Are they happy?

As much as I love Git, I'm not finding it any easier to teach some of the finer points of Git and DVCS, and people still ask me for help on a daily basis. It does take a while for the difference between checkout and reset to sink-in, which I can emphasise with. Also multiple branches from within one repositories is something that causes confusion to begin with. Finally I am definitely well past getting to the point where I think overriding rebase as a default of pull is more hassle than its worth. Especially when people merge a support branch and then pull again, resulting in both the merge being undone and a duplicate commit being made. It doesn't help that Git does all this without a single warning or message.

I guess what I've leant is that some developers just want to get their work done in peace. They don't really care about the finer points of source control, and they especially don't care about indexes, rebasing, DAGs or any other such nonsense. Perhaps in this respect Mercurial might have been a better choice? Less sharp edges for people to run into, and I could always run hg-git locally to keep me happy. Who knows at this point. The decision has been made; the ship most definitely sailed. On the upside, I'm fairly sure most, if not all, people are happy about the switch away from Clearcase. The world is a better place for it too.

My next obsession? Scala!

The DVCS Wars

2009-08-02T16:31:57Z

What is it about us nerds that dictates every discussion must be a war of some description? It isn't enough that we have two (or more) great technologies at our disposal, we also have to fight about it and of-course we have to be right. For example the age-old conflict between Vi and Emacs seems to continue today, as passionately as ever. And why not? There's nothing like a good ol' fashioned flame war to get the blood pumping.

This post, in all fairness, should really be called "Why I switched from Mercurial to Git". I actually quite like Mercurial and it was the original DVCS that opened my eyes to a world beyond SVN. Upon first hearing about the exciting concept of DVCS I knew that I needed to get my hands on one ASAP. But of course it couldn't just be any DVCS, it had to be the best one. So I did some more reading, scoured blogs for any material I could find on the topic so I could make the perfect choice. And I did. Only I picked the wrong perfect one...

Mercurial has so many good things going for it. The command line is clean and simple, and for SVN escapees feels very much like home. It's written in Python, which helps on Windows, and has a nice plugin architecture. In addition it has a good balance of speed and size, not requiring any silly garbage collection. Oh how I used to laugh at those poor Git fools, why couldn't they see the folly of their ways. So what changed? I guess curiosity got the better of me. I read one too many pro-Git articles and realised I might just be missing something.

What makes Git worth switching too then? In short, the repository format. Everything else, in my opinion, is just porcelain. The defining moment for me was when I learnt about reflog. So anything I commit is safely backed-up for 90 days regardless of what I do to the visible history? Count me in!

The safety net of Git's repository format in this respect is liberating. Commands like rebase are not so much 'modifying history' as modifying your view of history, because you can always retrieve the old version (within 90 days) if you need it again. On the other hand when you modify the history in Mercurial you really are modifying the history. Whoops you've just stripped that commit from your repository; I hope you made a backup. This is one of those fundamental differences between Git and Mercurial, carefully considered and implemented by their original designers. It means that in Git you have the trade-off of having to run a gc occasionally to remove those pesky unused objects. I'm cool with that if it means I get my reflog and a rebase that is 100% refundable, no questions asked. I should hastily add that I've never 'lost' a commit and I'm certainly not trying to suggest that Mercurial is unsafe. For me personally it's about that extra layer of comfort and freedom that Git provides.

After that everything else seemed to just fall into place. I'd never really liked Mercurial's (previous) answer to local branches: MQ. Having to learn a whole new set of commands to essentially do the same thing. I kept forgetting which 'q' command did what. Why should I even have to remember different commands, why can't I just commit and rebase later? Of course I'm being simplistic here, and MQ is a very powerful tool, but what I really wanted was a way to work as normal and decide later how to sync my changes.

I find something strangely fascinating about version control, and I don't think I'm the only one either. It seems to be a topic that draws an unusual amount of attention, much to the continual annoyance of their creators I'm sure. Like everything in life, there is no absolute right or wrong in regards to version control, as much as we'd like to argue there is [1]. What is perfect for someone may be hell for another. Many people have happily switched from Git to Mercurial, and while I think they're crazy I think I understand why. My rookie mistake was not playing with all the alternatives in the beginning. Git has turned out to be the ideal tool for me; it compliments the way I work and think in a way that Mercurial didn't or can't by design.

[1] Unless of course you prefer Clearcase, in which case you're ugly and stupid. :-P

ClearCase strikes back

2009-07-13T04:05:55Z

So it's been almost a year since my last post and I obviously haven't had much to say. I'm back to talk about the exact same thing, again. I really need to find something other than version control to obsess about...

Recently I made the switch to Ubuntu at work. This left me without ClearCase, as it requires some derivative of enterprise Redhat or SUSE, which didn't interest me in the slightest. I can only assume this is partially due to the complexities of managing a separate binary kernel module required by MVFS, their virtual filesystem. As an alternative Rational seem to be pushing their Java implementation ClearCase Remote Client (CCRC). CCRC is essentially an Eclipse plugin communicating to a server - via a mixture of Web Services and RPC, which in turn has the 'real' client installed. As you would expect this seems to have some performance trade-offs, and it also feels to me quite unstable at the moment, often throwing strange errors unrelated to ClearCase. It's certainly better than nothing though.

This, of course, raised immediate problems for me as I refuse to go back to using ClearCase directly now that I've tasted the good (and fast) Git life. Because I obviously can't seem to help myself I ported the gitcc to Java to use their new libraries, although it's definitely the last time.

One good thing to come out of this new version is the cross-platform ability to login as any user, bypassing the domain-specific authentication that is normally used. At least in my situation ClearCase was authenticated via our Windows domain and I could see no quick and safe way to switch between users. This was/is essential for us to preserve the identity of the author of each commit in ClearCase. I strongly suspect there is a way around this, but for the life of me I couldn't think of any. The one alternative that occured to me would have been to run gitcc on something other than Windows configured with NFS and 'sudo su' to each user as required. For reasons I am unable to articulate I wasn't all that happy with the idea and never bothered.

I've been running a gitcc daemon at work for the past week with great success. It's funny how the speed difference of pushing/pulling affects your work habits. Before I used to watch the checkin and rebase console output, like being glued to TV. Especially because we're using UCM this could take up to a few minutes to do it's rebase/deliver business, which would distract me and I would often 'hold off' on pushing or pulling because I wanted to do it all in one hit to save time. I no longer have that problem, being able to 'fetch' whenever I like, knowing it only takes (literally) a second to complete. Of course in the background the daemon is chugging away, syncing with ClearCase at its own slow-and-steady pace.

Git seems to be finally taking off at work, after a slow and bumpy start. Personally I'm thrilled to be using Git at work regardless of what anyone else is doing. However some part of me isn't satisfied with just stopping there. It pains me to see others at work using a sub-par tool when I know there is a much better one available. The worst part is that most of them don't even know what they're missing, having never used anything else. Having originally come from SVN I couldn't bear to have to checkout files every time I wanted to make a change and I knew it didn't have to be that way. A co-worker even commented that they 'like' knowing when they're modifying files just in case they accidentally typed something without realising it. That may be true, but I strongly suspect after using Git for a few days they would be unlikely to revert. That's not even taking into consideration the many other benefits of using a DVCS - like local branching.

What remains is the biggest hurdle: taking it to the 'next level'. A handful of developers are currently using it individually, but now that we have daemon available we can start to look at essentially ditching ClearCase, at least for our team. Part of the problem with working for a 'largish' company is their slow and cautious approach when introducing new technologies. From their perspective they have to consider what happens if I get run over by a bus tomorrow (those damn buses - always threatening to run us over). No one else really has the same intimate knowledge of gitcc and its inner workings. How much time and money would be wasted having to fix it, or revert to ClearCase if I was no longer there? The other issue is one of training and expertise. Now you have the problem of supporting two completely different source control systems, including training for, and maintenance of, both.

The final problem that I face is one of Git's maturity. I love Git. Without a doubt it is the most advanced version control system available today. Sure it's got more than its fair share of warts, but I wouldn't use anything else (yes I know about Mercurial, and in any other universe without Git I would be using it quite happily). Unfortunately what it lacks at the moment is all that boring Windows GUI and administration tools that managers and non-technical people need (and I don't just mean TortoiseGit). I'm sure they'll be here soon enough, but in the meantime I would still hesitate if asked 'is Git ready'. The problem is that the viable alternative, at this very second in time, would most likely be SVN, which isn't a bad system, but when compared to any modern DVCS it looks increasingly archaic. If we switched to SVN now I strongly suspect there would be pressure to switch (again) to something more powerful in the not-too-distant future.

I'd love to use Git at work as our sole version control. Unfortunately as a developer I don't really have the time or patience to play politics and ensure that all aspects of a migration are planned for. However, it seems silly to me that if a majority of your developers start to use an alternative system for any aspect of work then there isn't some reflection on your current one and how you can make your working environment that much more productive. I'm not suggesting for a second that we replace ClearCase tomorrow. Instead I am simply proposing a gradual adoption, or at least trial, of Git over ClearCase. Hell, we're pretty much doing that now anyway, just not officially.

Finally, the other revelation to come out of this is how truly entrenched in Java I have become. I found with the Python implementation I would often worry about making changes because I would have to spend part of the time investigating how to implement something 'in Python' rather than just being able to focus on the problem at hand. This has nothing to do with Python, it still remains a fantastic language, but perhaps says something about me getting older and less adaptable when learning new things. I hope I never reach that point where I'm too afraid to try something new, although I'm certainly becoming far less likely to (at least seriously) learn a new language in my spare time. I'm just hoping one of these days I get to use Haskell at work. :)

A Clearcase for Git

2008-11-10T13:23:37Z

My introduction to Clearcase began about two years again at my now current current job. Coming from SVN it seemed, and still is, so overly complicated and slow. What is this "config spec" you speak of? Anyway, I could write essays devoted to my loathing of Clearcase but this is not what this is about.

I've been tempted for quite some time to introduce a DVCS, any DVCS, into the mix to make my life easier. However, I was concerned it may end up being just as much work as just sticking with Clearcase. I certainly didn't want to have to stuff around with manually deleting and adding files and native moving/renaming was also essential.

I found some helpful scripts, but nothing that really just worked.

Anyway, I finally got my act together and put together a simple bridge which can push and pull changes into Git. About bloody time!

http://github.com/charleso/git-cc/tree/master

The README is probably a good place to start for anyone interested.

Please note: It's still very much a work in progress. However, I'm already using it at work to much joy and relief. Not more pointless checking out on private branches. No more VOB locking or stupid branch renaming for releases. Just sweet, sweet Gitness.

A few basic examples:

    python gitcc.py init
    d:\views\your_clearcase_view
    python gitcc.py rebase
    # Obligatory comment about getting coffee and doing work
    python gitcc.py checkin

That's about it really. I'm interested to see if anyone else finds this useful or has any suggestions.

Finally, it was so refreshing to finally work with Python again. I'd forgotten how simple and concise it is to use. I'm so entrenched in Java that, like an addiction, it's too easy to fall back on. That's not to say I'm addicted to Java, nor do I hate it particularly, but it's just so comfortable and I just don't have to think about it anymore. Sad really.

Flex-o-matic

2008-08-07T06:03:16Z

A few weeks ago I investigated Flex automated testing to determine it's feasibility for our new Flex project. On Wednesday my boss has asked me to follow through with that original investigation and get it up-and-running on our build loop ASAP.

The tools I originally looked at:

HP QuickTest Professional or QTP. This is the big daddy of Flex automation testing, and costs an arm and a leg. The funny thing is I couldn't seem to get this working last time. That and it looks like an old Windows 95 app (superficial I know).
RIATest. In many ways this is the nicest of the tools. Quick, simple and it just works (TM). However it's in very early stages, has its own IDE/language and only works on Windows.
Rational Functional Tester or RFT, a set of Rational plugins for Eclipse. The business preferred option as we use this for other products as well.
Custom Automated Agents, the adobe sample for automation testing. It's worth noting that all the above products are essentially just rebadged versions of this. This has the most power of all these tools, but is very bare bones and quite complicated to understand.

Originally I had decided on RFT a few weeks ago and wrote some basic tests. However, today I spent some more time with it and ran into a few snags.

Firstly our toolbar is a Flex MenuBar, which (for some stupid reason) doesn't handle ItemClick events for root items. Without this you can't perform the simplest of actions like searching. To get this working we would have to use something else. Strike one.

Secondly the Grid data verification points were now returning blanks in every cell. After some snooping it turns out setting a custom itemRenderer for columns (ie combobox or checkbox) causes this to happen. Sadly we need to do this and I couldn't seem to fix the problem. Strike two.

While none of these are show stoppers it made me realise I really didn't like using RFT, it felt flaky, so I thought I'd better re-examine my options.

The other, as of yet unexplored option, was Selenium. Just the other day (literally) the new flex API was released. Behind the scenes this is simply an exposed API via the Flex ExternalInterface (basically a Flex/Javascript bridge). As I was looking at this I realised we could just expose our own custom API to compliment Selenium's.

For some reason this latest option appeals to me as it potentially grants the most power and least amount of headaches. Using the above tools feels like we're getting locked into a specific way of using Flex. When something doesn't work, like it did today, there isn't much we can do except change our application to fit the required mold. Instead it would be nice if the automated tools were as flexible as we need them to be.

What we loose is the recording capability, which I don't think is a huge loss (but sad). Some of our other functional tests at work are also written by hand. It will also require some more initial tweaking while we flesh out our own internal API. My other concern is that it's not exactly the same as users interacting with the app, but then again neither are the above tools.

I'm still not sure at this stage which option I'm going to settle on. Time is of the essence, and I really need to have something to show by next week. I'm hoping with some more testing tomorrow, Selenium will be just what the doctor ordered.