Like all the other Mac-toting fashion hounds, I've been playing with Ruby on Rails of late. I have the good fortune of having a buddy who has a paying gig building a Rails site and he is kind enough to give me commit rights so I can use it in a meaningful way without giving up my day job as a J2EE guy, and without having to find an excuse to use it at work.
Without getting all hysterical about it, there are many things in Rails that should give pause to the J2EE crowd. When I switched from C++ to Java, the thing I liked most about coding in Java was the much improved signal-to-noise ratio compared with C++. I found I spent much less time thinking about computer stuff and much more time thinking about the problem at hand and the concepts of the problem space, largely ignoring the problems of the implementation space. This was partly the language, partly the libraries, and partly the community around Java at the time, but when you add it all up, the result was better software faster, which is really all I want.
Now, having used the classic J2EE stack for a while (Struts/Tiles/Hibernate, et al), and having watched J2EE vendors bloat their products to the point of collapse, using Rails has given me the same feeling. No struts-config.xml, no tiles-defs.xml, no *.hbm.xml files, and much less time thinking about the machine and its implementation layers. The signal-to-noise ratio is simply better than in the form of J2EE I've learned. Ruby/Rails also appear to have the libraries and the community to make the whole stack work. The whole setup feels more supple and malleable than Java, and, since that feeling was what attracted me to Java, that has to be a concern for those who think Java is some kind of universal maximum, rather than just a local one, as all technologies are.
There are some things in Rails about which I retain mixed feelings. ActiveRecord seems to me to be less of an O/R mapping layer, and more of an O/R unification layer. This caused me severe brain ache for a while, but I'm suspending disbelief for the moment. The unit testing model involves database access (and lots of it), which is a definition of unit testing I've always disliked strongly. The functional testing model (so far as I have looked) doesn't use a model based on parsing and filling out and submitting the HTML forms served by the running application. It appears to be more a controller-testing setup than what I would call a functional testing setup. But I'm only a newbie and might have missed some stuff.
Saturday, December 24, 2005
Tuesday, November 22, 2005
Brain Fade?
How can the most important application I have be so neglected by its creators? I've been waiting a year and a half for a new version of Personal Brain and this is what I get - half a dozen fixes to bugs I hadn't noticed and not a single new feature. One of the highlights is that they've updated their phone number because they moved offices! I don't know if this company is starved for resources, but if ever there was a company that deserves some, this is it. I hope I don't jinx them and they get snapped up by Microsoft and ruined, but this slow death is possibly worse!
Friday, October 28, 2005
Now we're cooking
I've only recently started using a laptop all day every day, so I thought it was time to put to use a trick shown to me by some buddies for making the all-day laptop experience a lot more ergonomic. So a quick trip to the homewares store for a cook book stand, and bingo! You've got the screen at eye level. Check out the picture for an idea of how it works. You need to invest in an external keyboard and mouse, of course, but it's the poor man's docking station. Start a fashion trend in your cube farm today!

Thursday, October 27, 2005
Flat Out in First
Imagine you're driving from one side of the city to the other with a friend and you're in a big hurry. You're running really late and you're desperate to get where you're going. To your amazement, your friend sets off down the road and puts the pedal to the metal in first gear. He's gripping the wheel, concentrating fiercely, the engine is screaming, and you're being overtaken by every car on the road, doing about 30kph.
You say to your friend, "Hey, don't you want to go into second gear?"
But your friend says, "Don't interrupt me, man, I'm going as fast as I can and I really need to concentrate here"
You try again. "But we'll get there faster if you change gears!"
But your friend says, "No we won't! I tried that before and putting in the clutch __definitely__ slows you down, silly! And the last thing I can do now is slow down when we're running so late!"
The problem with development teams is that you can't actually hear the engine screaming and see the car shaking and feel the lack of speed. But it seems to me a lot of development teams are flat out in first gear. Agile development has a lot of practices that are all about changing gears.
You say to your friend, "Hey, don't you want to go into second gear?"
But your friend says, "Don't interrupt me, man, I'm going as fast as I can and I really need to concentrate here"
You try again. "But we'll get there faster if you change gears!"
But your friend says, "No we won't! I tried that before and putting in the clutch __definitely__ slows you down, silly! And the last thing I can do now is slow down when we're running so late!"
The problem with development teams is that you can't actually hear the engine screaming and see the car shaking and feel the lack of speed. But it seems to me a lot of development teams are flat out in first gear. Agile development has a lot of practices that are all about changing gears.
Saturday, October 22, 2005
An Agile Requirements Parable
In my current role I'm trying to introduce agile development into a team of about 30 people. One of the challenges is the approach to requirements. The incumbent process is pretty standard waterfall with requirements documents that are both too big to read and too short to be used as the only input for development, as well as being written from an implementation perspective rather than a user perspective. As well as being written up front in their entirety before coding begins. So no news here.
But the biggest issue is (as usual) not a technical one but a human one, in this case the implicit belief that requirements can be 'captured' if you just think hard enough (and long enough) as opposed to the agile view that requirements need to be trawled for constantly, starting at a high level and increasing the resolution as implementation approaches, leaving the resolution lower for far-off things.
I unwittingly stumbled on a requirements parable the other day when, of all things, I attempted to buy a new pen. I succeeded in purchasing a pen, but I failed to get one that met all my requirements. I'm serious; I couldn't even buy a pen for myself that satisfied all my requirements. Read on if you are still on your chair.
So, why did I need this pen? I carry around a pocket notebook and a pen wherever I go, having learned from experience that freeing my brain from minutiae leaves it free to dream and create. I've tried other tools, PDA's, dictaphones, etc, but the good old pen and notebook just works. The definition of 'works' here is that the time and effort between being confronted with something that I need to remember but that I don't want to deal with emmediately must be minimised. I even have a kind of code for the notes I take to speed it up, and recently spent half an hour in a stationery shop buying just the right notebook (with high end features like one of those built in straps to mark your page). So I'm pretty serious about this pen. It has to be able to be connected to the notebook firmly so they can't be separated accidentally, and it has to have a broad enough point that my dim eyes can see what I've written.
So how did I go wrong? Well, the pen I've used for a long time started to become unreliable, so I had to replace it. It literally did not occur to me that the fact it was one of those ones that you press the top to extend the ballpoint was important. I was thinking maybe I'd try a felt tip pen rather than a ballpoint as the nibs come in wider formats. So I looked at the mountains of pens in the store and picked a broad-nib felt tip number with a clip that attached snugly to my notebook. So how long did it take to realise my error? The first thought I had that I wanted to write down, I pulled the unit out of my pocket, separated the pen and instinctively went to push the button to extend the ballpoint with one hand while flipping to the current page with the other. Only there was no button. There was a cap! That requires two hands (or one hand far more dextrous than mine) to pull off and put somewhere else, probably on the butt of the body of the pen. I was stupefied. I was now thinking about the damned pen and not the brilliant idea I'd just had.. If there is something you just want to stay out of your way, it's the thing between you and your great ideas.
So what's the moral of the story? I guess it's something like this: Assuming you are capable of defining requirements up front without exposing users to the solution is bogus. Even if the system is well established. Even if it's as simple as a pen. Even if you're so clever that you can read the customer's mind. :P
But the biggest issue is (as usual) not a technical one but a human one, in this case the implicit belief that requirements can be 'captured' if you just think hard enough (and long enough) as opposed to the agile view that requirements need to be trawled for constantly, starting at a high level and increasing the resolution as implementation approaches, leaving the resolution lower for far-off things.
I unwittingly stumbled on a requirements parable the other day when, of all things, I attempted to buy a new pen. I succeeded in purchasing a pen, but I failed to get one that met all my requirements. I'm serious; I couldn't even buy a pen for myself that satisfied all my requirements. Read on if you are still on your chair.
So, why did I need this pen? I carry around a pocket notebook and a pen wherever I go, having learned from experience that freeing my brain from minutiae leaves it free to dream and create. I've tried other tools, PDA's, dictaphones, etc, but the good old pen and notebook just works. The definition of 'works' here is that the time and effort between being confronted with something that I need to remember but that I don't want to deal with emmediately must be minimised. I even have a kind of code for the notes I take to speed it up, and recently spent half an hour in a stationery shop buying just the right notebook (with high end features like one of those built in straps to mark your page). So I'm pretty serious about this pen. It has to be able to be connected to the notebook firmly so they can't be separated accidentally, and it has to have a broad enough point that my dim eyes can see what I've written.
So how did I go wrong? Well, the pen I've used for a long time started to become unreliable, so I had to replace it. It literally did not occur to me that the fact it was one of those ones that you press the top to extend the ballpoint was important. I was thinking maybe I'd try a felt tip pen rather than a ballpoint as the nibs come in wider formats. So I looked at the mountains of pens in the store and picked a broad-nib felt tip number with a clip that attached snugly to my notebook. So how long did it take to realise my error? The first thought I had that I wanted to write down, I pulled the unit out of my pocket, separated the pen and instinctively went to push the button to extend the ballpoint with one hand while flipping to the current page with the other. Only there was no button. There was a cap! That requires two hands (or one hand far more dextrous than mine) to pull off and put somewhere else, probably on the butt of the body of the pen. I was stupefied. I was now thinking about the damned pen and not the brilliant idea I'd just had.. If there is something you just want to stay out of your way, it's the thing between you and your great ideas.
So what's the moral of the story? I guess it's something like this: Assuming you are capable of defining requirements up front without exposing users to the solution is bogus. Even if the system is well established. Even if it's as simple as a pen. Even if you're so clever that you can read the customer's mind. :P
Saturday, September 3, 2005
Back in the iLife
When I started my new job a few weeks ago, I had to wait a while before my new laptop arrived from Dell. So I turned up on the first day with my Powerbook and plugged in. I was very pleased to find that Apple Mail knows all about Exchange servers out of the box, so I was up and running with no problems and went on happily for a couple of weeks. When the Dell arrived, I spent a couple of days with both machines on the desk while getting it all set up. It was only after switching the Mac back to home use mode and starting to use the Dell for work that I was struck by an obvious solution to a problem I'd been facing for a long time. One of the reasons I switched jobs was in pursuit of a better work/life balance. To me this means drawing a sharper line between the two something I've struggled with in recent years. And here I was looking at the solution: use one computer for work and another for life. Sounds simple, but I missed it until now. So now the Dell stays off over the weekend (it stays on long enough to check the week's work in to CVS at home), and doesn't get looked at until Monday morning. The Mac, with photos, videos, electronic books, music software and fun geek stuff like Ruby and Objective C stays on all weekend and is nothing but fun. Nice.
Thursday, August 18, 2005
It's Mac time now...for my old man
It's been a while since I blogged at all, having been a little busy switching jobs, having recently also switched computers (to a Mac Powerbook) and having tried to switch programming languages (learning some Objective C, which is lots of fun). But I'm convinced enough by my Mac experience to have convinced my dear old dad to jump as well (to a Mac Mini) on the demise of his old PC. So does that make me an official cult member? I've also started thinking that one of those flat panel iMacs will look pretty good next to the espresso machine for my wife and daughters to use......:P
Subscribe to:
Posts (Atom)