|« July 2003||September 2003 »|
I'm Ryan Lowe, a Software Engineering graduate living in Ottawa, Canada. I like agile software development and Ruby on Rails.
I write this blog in Canadian English and don't use a spell checker. Typos happen.
» Full-time Ruby on Rails freelancer
» Full-time with Rails since May 2005
» Former committer for RadRails (now Aptana)
» I also have a few Rails side-projects in development:
1. wheretogoinTO.com Toronto nightlife
2. Hey Heads Up! TODO list and sharing
3. Layered Genealogy family history research
4. foos for foosball scoring
5. fanconcert for music fans (on hold)
Hiring Rails developers? I can telecommute by the hour from Ottawa, Canada
»» Email: rails AT ryanlowe DOT ca
Now hosted on Hey! Heads Up -- check it out!
Derek Lowe's (Ryan's older brother) words at Ryan's funeral
[email protected] no more
Forging Email Headers: Good, Bad or Ugly?
Sarcastic Dictionary (Part 1 of Many)
Twisting Rails is Risky Business
Risky Business? My Take on Early Alphas
Whoa, it's August 2007
A Postscript to "Growth at the grassroots"
»» All Blog Posts
David Heinemeier Hansson
James Duncan Davidson
Signal vs. Noise
Amy Hoy: (24)slash7
Luis de la Rosa
# Dog Days of Vacation
In order to conserve power, the Canadian government has decided to close buildings and let civil servants stay home -- so I've been on vacation for the past week. Odds are I'll be back to work by next Monday. Maybe then I'll have something to blog about. :|
# Radiohead @ Parc Jean Drapeau, Montreal
I'm tempted to go into detail how the blackout affected this technophile's life but ... it didn't. I decided to desert my home province for the electricity of Quebec. I've been to Montreal a few times but never in a situation where I could do what I wanted (twice with parents and the other time with a drunken bus tour, but that's another blog ...) so my friend and I walked up and down St. Catharine Street waiting for the concert to start ...
... oh I didn't mention the concert? Radiohead at Parc Jean Drapeau!! After going to see Red Hot Chili Peppers in May, this concert was a lot different. To be fair it was an outdoor concert so I should have expected it to be more like Lollapalooza or something.
Before the concert they played a rock-reggae blend band from CD I'd never heard before. Stephen Malkmus and the Jicks was the sole opening act. They were alright, nothing too special or original, so I don't have much to say about them. :) It was hard to see the stage, because the sun was setting right behind it so I mostly just listened.
Half the crowd wandered around until Radiohead came on. A lot of pot was smoked, which wasn't a big surprise I guess ... you could see wafts of it coming off the crowd ... we drove home that night reeking of pot and we didn't smoke.
Unlike Lollapalooza, there were no beer tents. Beer was served in the audience and everywhere courtesy of our friends at Molson. Not too many people were drunk either. The typical Radiohead crowd isn't going to get into a drunken riot like say, hmmmm, a drunken Limp Bizkit crowd. So I guess no one was worried about it.
Radiohead came on about 8 o'clock and started out playing songs from the new album (see the set list). The newer songs were faithful to the album versions, which was kind of disappointing ... I like to see some creativity on live versions. However, the way that the album was recorded (quickly and less-produced than Kid A or Amnesiac) meant that the songs sound more like the live versions they practised before recording I guess. They have years to improvise the new songs.
The older songs they played were improvised mostly by Thom and Johnny. Thom's dancing was incredible -- he has so much energy on stage. Sometimes it was full out dancing and other times it was gyrating at the mic or his patented head-bobbing. Johnny went into some wildly improvised solos with strange guitar effects. The other guys even cut Johnny off, when he soloed too long -- which started the crowd chanting Johnny's name in appreciation.
They used looping a few times to create backgrounds sounds. At the start of the song Thom would sing a few words into the mic and they'd be mixed (sometimes unrecognizably) into the background of the song, like you're watching/hearing the song being "assembled".
My favourite song of the night was an up-tempo version of "Everything is in Its Right Place" during the second encore. Before that, the crowd sang the chorus to Karma Police so well (and loud) that Thom decided to sing the chorus again a capella with the audience, which was cool.
The crowd never got wild, even in front of the stage during songs like 2+2=5 or Just. They were mostly subdued and relaxed ... but I guess that's the typical Radiohead fan for ya. Half of the concert was slower stuff from HTTT, Kid A and Amnesiac. Don't get me wrong, I didn't expect people to go crazy ... it was just different from other concerts I've been to.
So it was definitely worth the money -- a jolly good show. The t-shirts at 40 bucks a pop were not though. I will definitely see them again .... maybe they will come to Ottawa next tour. :) heh
# No www DNS Entry
I'm amused by Jim's rant, which reads in part:
"... the address pointing to their site is something like http://www.someurl.org and they want the www removed because it is "wrong" and they have gotten a customer complaint!"
In case you are wondering, this is a DNS (domain name server) problem. I learned this while maintaining DNS entries in France a few years back.
DNS entries are configured on a DNS server -- usually close to the web server -- which trickles updates up the DNS hierarchy to one of the main DNS servers on the Internet and then back down again. This happens continuously until all of the world's DNS servers knows the right mapping of http://www.someurl.org to some IP address. Otherwise, no one can find your server because we depend on these DNS servers to translate addresses. The propagation usually takes a day or so.
Convention dictates that the administrator usually makes the mapping for http://www.someurl.org to the web server as well as http://someurl.org. Some DNS maintainers forget the entry without "www" and as a result it doesn't translate for people. Smart browsers realise this and get around the problem. If you put in http://someurl.org and the browser gets no response, it will also check http://www.someurl.org automatically for you.
# Roy Learns the Easy Way
Roy is learning about software development the easy way, by making mistakes. The downside is that making all of these mistakes is time consuming. People have made them a million times over. So Roy, let me give you a few tips ...
First of all your observations about event-driven software are correct but it can be cleaned up. The solution involves a strict separation of GUI and logic code. Sometimes this can look strange -- why am I making another function way over here when I can just plop the two lines in that call the database? But you can't have UI code and logic tangled (coupled) like that. Every time you want to make a change to either, you break the other. Bad, bad news for maintainability.
So here's what you do -- make one or several APIs (a fancy word for a group of methods or functions) that your UI can call. Never pass UI objects to this API directly, only the information contained in them. A trivial example would be instead of passing the UI object that was clicked, pass its label or value. Another would be instead of passing a SelectBox back up to the UI, pass back an array of Strings that the UI can make a SelectBox from instead. BTW, I don't remember the exact names of UI elements in VB but they are simple things like that.
Your database problem has the same sort of solution. If your application has many defined layers, you don't have to worry about other people being done -- you can fake it by returning dummy data that works in the UI. This is called stubbing.
So you have at least three layers in this situation: the UI, the logic and a layer to talk to the database. SQL code and recordsets never leave the database layer, just like UI widget objects never leave the UI layer. Your UI never knows about SQL, it just deals with arrays. If you design this way, your coupling is low -- you could replace your UI without touching your logic layer, for example. You could optimize your database queries without touching your logic layer as well.
This solution has one drawback however: you may need an intermediate data object -- it depends on what type of data you are passing between the UI and the database. If you are just doing simple String arrays then no problem. If you are returning multi-row recordsets from the database to the UI, these have to be converted to arrays of Objects that can hold all of the recordset data.
Of course, software engineering is about trade-offs. You could, as a compromise, use the recordset format as the transport format. The risk you take is that the guy doing the GUI has to deal with a recordset instead of objects, and if you ever change the columns in the database -- which changes the recordsets that are returned -- you may break the GUI. Yeah, ick.
When the SQL database stuff is done, you rewrite the stub so that it works using the data in the database. Since you already wrote the connecting code from the UI down to the database layer everything is already connected and should *just work*. Stubbing works really well when different team members are working on different layers and the people at higher layers want to keep going when the lower layers aren't complete. You can even unit test stubbed functions to be clear about what they actually do.
Which reminds me -- unit testing. With the logic carefully separated from the UI like this, more of the application's logic can be unit tested. In fact it's not unreasonable to expect that all code from the logic level down should be completely unit tested. If you have logic poluting your UI, you cannot test it as easily and that could lead to bugs and regressions. Keep the UI code as simple as possible.
I'm glad you realised that letting the "QA department" find bugs is not the answer. Developers don't learn to code better that way. Write your own tests, find your own bugs and learn from them. More importantly, the time (=MONEY) to fix a bug that a developer finds himself is several orders of magnitude faster than if a QA department has to find it, report it and verify that it is fixed. I can't stress that enough, it's ridiculous to do it any other way.
Bad code treated badly only gets worse. You can't make a mansion out of band-aids and popsicle sticks. You need some cement (tests) to hold the structure up. Good luck Roy!
# Band-Aids to Brilliance
Roy reminded me about one of the fundamental things about iterative development: keeping your bug fixes around. Otherwise you'll just make the same mistakes over and over again as you refactor. OK, so that means gathering cruft and band-aids, right? Nope ... that means knowing absolutely 100% when something is fixed. Right now the fix may be a band-aid, but later it may not. You don't really care as long as it is works. But how do you know the fix works?
Testing the API is the only way to be sure ... and since manual testing is a PITA, unit testing is the way to go. These tests become bug fix regression tests and bugs you've seen before won't creep back without you knowing about it.
# Put Out to Pasture Myth
Traditional "waterfal method" developed software goes through a number of defined stages but usually ends abruptly. The developers, having created their masterpiece, want to create something from scratch again. The suits bow to the pressure, give them a new project and assign the task of maintaining the masterpiece to less-experienced developers.
So what's the problem? The software rots. Sure, bugs are fixed as best they can but no real improvements are made unless the suits come back for another version. The problems are fixed with band-aid after band-aid instead of addressing larger design issues -- mostly because the maintenance developers don't know enough about the system to screw with it that much. If it ain't broke, right?
So the suits come back for another version. Many new features are planned out on the old architecture specs. But what to do with the band-aids? You definitely can't throw them away, so it's just built over them ... development changes hands again back to the senior developers ... and this continues ...
This is what I'm going to call the put out to pasture myth. Some say that as soon as software is finished it's outdated -- but software has to be released sometime. The mistake is thinking that it is finished. It almost never is.
Apple is developing their operating system in a relatively new way for a commercial company ... and it borrows from open source development practises of projects like the Linux kernel, Mozilla and Eclipse. Instead of years and years of development with a final release and service packs, they release a new version every year at a lower price. The advantages: developers don't want to leave the operating system team because it's never put out to pasture. It's been in active development for years. This is great not only for the suits, but for developer morale. There's less stale software around that some 'poor sap' has to maintain at the derision of his Apple development peers.
But it's really the users that benefit the most. Small bug fixes and performance improvements are sent via the Internet as they are needed and larger feature-driven updates are delivered once a year. Apple can listen to the feedback of its users and respond within a year's time. That's pretty impressive for a commercial operating system.
I see this type of development strategy as being win-win for developers and users. The only hard to fit piece of the puzzle is the suits who ultimately make the calls and for better or worse, deal with the customers. They have to think not in terms of a single product delivered at such and such a date with features X,Y and Z but more in milestones.
Ironically, milestones are less risky for suits and their customers which makes this poor developer wonder why they haven't been more widely adopted. The risk I am referring to is time lost, which usually translates to money spent. Time and money are almost equally important in the business world, so we are pretty much talking about the same thing.
Milestones are less risky because the time to market is shorter, which dictates how quickly you will get feedback from customers and respond to their needs better. If you go off track a bit, the worst-case scenario is a lost milestone, not a useless product or vapourware. The faster you get something usable out there, the better. There will always be bleeding-edgers to tear your software apart. Listen to them.
As your software gathers users it will start to be used in situations you didn't imagine. Obscure bugs are found. Features are added and usability problems are solved from user feedback. This is how software should be developed. How can anyone be expected to read the minds of millions from day one?
# Web Server Upgrade
Hey folks, my web server was upgraded on Friday and the blogs on both domains were read-only. Everything should be OK now. Welcome back.