The SquizLogKeith Pitty takes a squiz at the world. |
|
The SquizLogKeith Pitty takes a squiz at the world. |
|
Thanks to Larry Williams for alerting me to the fact that version 0.6.0 of the Ruby plugin for Eclipse has been released.
Which is good because I love using Eclipse. But the main reason I currently use Ruby is for Rails development. TextMate suits me better for that purpose because it recognises ERB files and Rails in particular.
I wonder if anyone has given thought to developing an Eclipse plugin for Rails?
Ah, it feels good when I've refactored some ugly code. I can reflect on how smelly the code used to be and how it is now much more elegant. It now clearly communicates to the developer and has a structure that will allow much easier adaptation.
As I mentioned earlier this month, the twin topics of Refactoring and Design Patterns have been occupying my thoughts recently. In the last week or two I have been exploring Joshua Kerievksy's Refactoring to Patterns book. I can't recommend it highly enough.
Fortunately I've had the opportunity to put some of the ideas into practice. A few years ago I developed a Java application that reads cricket fixtures from a database and, based on an HTML template, generates two sets of pages. One shows the season's fixtures for each team in the club. The other set contains a page for each playing day of the season showing all the matches the club is involved in.
Anyway, I am now in the position where I want to hand this code over to someone else.
A couple of days ago on the train, whilst I was looking at the code in a class called FixtureList I noticed some smelly code. One method in particular, createTeamFixtureList contained far too much logic and it was by no means immediately apparent what that logic was doing. So I had a Long Method smell. The Compose Method refactoring, essentially a succession of Extract Method refactorings, came to my rescue. Nothing extraordinary about that but at least I ended up with a much shorter method that called other methods with names that improved the code communication.
Of course, before I started any refactoring, I made sure that I had some JUnit tests that I could rerun to ensure that the behaviour of the code was preserved.
Moving on, I noticed another code smell: Conditional Complexity. Thinking about the FixtureList class, it became apparent to me that it really should be divided into two classes: DateFixtureList and TeamFixtureList with an abstract FixtureList superclass. But there was also a getFixtureListAsHtml method to consider. This method contained the same sequence of steps regardless of whether the list of fixtures was by team or date. Some of those steps were the same but others were different. Without going into all the details, I ended using the Replace Conditional Logic with Strategy and Form Template Method refactorings.
Now I am much happier with the state of the code. Of course there is more refactoring that I could do but I've got rid of the worst of the smells and will find it much easier to explain the code to someone who will also be learning Java for the first time.
I love golf. However, sometimes, like life, the game just doesn't seem fair!
I've been playing golf fairly freqently for more than 30 years and, whilst I've come close, I have never achieved that miracle shot: a hole-in-one. Indeed these days I'm pretty happy to hit the green let alone get it close.
Yesterday I arrived home to be greeted by a big grin on the face of my 13-year-old son. Yes, it transpired that he had not just been enjoying the school holidays but had indeed aced the short 17th at Wyong. Recovering from the shock, I informed him that many a golfer goes to their grave without getting a hole-in-one. And he had managed to fluke one only a few months after graduating to full-sized clubs!
Do I sound jealous? You bet!
It's that time of the year again. The cricket season is about to start in Australia.
This Saturday the Sydney Grade Cricket competition starts. And the following week the local comp begins here on the Central Coast. But I won't be playing.
I could have taken the hint last year. I vividly recall the moment during a pre-season training session when perhaps I should have realised that it was time to move aside and hang up my boots. I had just finished batting in the nets, rather poorly, and my son gave a cruel assessment of what he had just witnessed.
"Dad, you batted crap! The ball was hitting the back of the net before your bat was swinging through."
The best retort I could summon was: "You'll be 43 one day, son."
So in 2005/06 I'll be watching and coaching. Which brings to mind a comforting slogan: "The older you get, the better you were..."
"What's that serialVersionUID all about? And do I have to type in that long number?", a student asked.
We were discussing Serialization in the context of JavaBeans yesterday in a J2EE class that I'm teaching here in Canberra. It was one of those moments when I knew I should have been able to provide a good answer there and then but my mind was blank. So I gave the "I'll have to get back to you on that one" answer.
I had some vague recollection about the serialVersionUID (universal version identifier) being important for versioning of JavaBeans. This forum item confirmed my suspicion as well as highlighting the performance hit if serialVersionUID is not declared. If it isn't, each time the class is loaded reflection and hashing is used to generate it.
And with regard to versioning, there may be times when you want to change a class but still enable old versions to be loaded. Declaring a serialVersionUID will allow this. Otherwise an InvalidClassException will result.
The answer to the second question could be: use the serialver tool that comes with the JDK. But when you're working within an IDE like RAD or Eclipse that goes against the grain.
It turns out that in Eclipse 3.1, by default a warning will be issued by the compiler (listed under Potential programming problems in Window --> Preferences --> Java --> Compiler --> Errors/Warnings) if no serialVersionUID exists for a Serializable class. Then a quick fix can be used to easily generate one.
In RAD (based on Eclipse 3.0) all is not lost. The Code Review function allows a similar quick fix to be used to generate the serialVersionUID declaration.
Update (7th October): See this later post for clarification on performance issues.
Yes, after 16 years the urn has turned. England have drawn the final Test and won the Ashes.
But it took a dominant innings from former Sydney University player Kevin Pietersen to ensure that Shane Warne and Glenn McGrath did not convert the tantalising position of 5/126 into an Australian victory.
Oh well. Congratulations England. You were the better team.
Nothing earth shattering to report here. Merely that I'm in Canberra to do a week's teaching and, unlike last time, it's bloody freezing this time ('twas forecast to reach a whole 11 degrees Celcius today).
As much as it pains me to admit it, thanks to yesterday's gloomy weather and another inspired contribution from Flintoff, the Ashes have all but been relinquished from Australia's grasp.
Matty Hayden joined Justin Langer as a centurion on the third day of the final Ashes Test. It was a timely and welcome return to form.
The opening 185 run partnership between Hayden and Langer is just what Australia has been looking for all series. So many of Australia's batting successes in the past four years have been built upon a solid start from these two lefties.
The inclement weather has not left Australia with much time up their sleeve but if they can add another 300 to their score today Warne may be an irrepressible force on the final day that will deny England their party.
Two days left and plenty of possible twists and turns remain.
When England were 0 for 70 after the first hour's play of the final Test I wrote off Australia's chances of retaining the Ashes.
But I hadn't reckoned on Shane Warne's continuing psychological hold over the English batsmen. Not to mention his remarkable skill. His five wickets on the first day have kept Australia in with a chance.
Day two promises more enthralling Test match cricket. Will Australia be able to wrap up the tail quickly and then, more crucially, will Australia's batsmen finally stand up and be counted in their first innings?
The fifth and final Test of what has been an enthralling Ashes series is almost upon us.
England are rightfully confident of regaining the little urn that they lost back in 1989. Their fans have gone cricket mad to the extent that the English players have become sex symbols!
I can relate to the English desire to restore pride in their national cricket team. In 1989 I happened to be living in England when the visiting Australians were greeted by the English tabloids as "the worst Australian team to visit these shores". How quickly things changed. I well remember one day in the office when I was asked the score during the opening day of the Test at Trent Bridge. My reply of "none for 280", no doubt delivered with a grin, was greeted with the response: "You smug bastard!"
Now it would appear that the boot is on the other foot. Well almost. Australia can still escape with the Ashes if they win at The Oval. McGrath has been passed fit and England are still deciding who will replace Simon Jones.
Hopefully for Australia, they will win the toss and Hayden and Langer can return to their glory days by posting a big partnership to set up a platform for their team to push for victory.
Whatever happens, this series has been the best thing to happen to Test cricket for many years.
I love your technology, especially the iBook and iPod that I have been enjoying for the past year. But your customer service leaves something to be desired.
Today I received my AppleCare Protection Plan in the mail, having faxed off the purchase last Friday, the day before the initial warranty expired. The letter enclosed advised me that I now needed to register and that is would be an easy process. It then went on to describe my two alternatives, to fill in and post an "enrollment card" or to register over the phone "which may prove to be simpler and quicker". Ignoring the word may, I chose the latter.
What a mistake! When I realised that I was connected to a call centre on the subcontinent, I began to suspect that I may have chosen the wrong option. (No racism intended, it's just that I have become tired of having my time wasted by direct marketing calls from India.)
So I patiently answered the gentleman's questions. Just when I thought the process was complete, he advised me that because it was beyond the original 12 month warranty period I needed to fax proof of purchase to another department.
"But you've already billed me!", I replied in exasperation. The Special Extended Warranty Offer letter had the purchase date, model number and serial number on it. Why should I, a customer, need to fax a copy of such a document when I've responded to an extended warranty offer obviously based on the original purchase details?
Please Apple, show me that your quality of customer service matches your wonderful technology.
A couple of factors at work recently have led me to refocus my thoughts on Design Patterns.
Firstly, a Java course I was teaching the week before last included a brief topic introducing Design Patterns and Refactoring. Even though it only included enough detail to give the students an awareness, I was left with a desire to improve my own ability to apply design patterns and refactoring when I'm coding.
Secondly, the codebase that I'm contributing to in a J2EE project has reached an interesting stage. It is in production and would appear to be meeting the customer requirements pretty well. However, without going into details here, it could clearly do with some judicious refactoring.
Personally I think I have a reasonable understanding of the essence of design patterns and refactoring. It is the practice of applying them that I know I can improve. In this quest I have access to the two original books, Design Patterns: Elements of Reusable Object-Oriented Software (the GoF book) and Refactoring: Improving the Design of Existing Code.
There are a couple of other books I have my eye on:
And in doing so I'll try to remember Erich Gamma's advice on how to use design patterns.