|« November 2005||January 2006 »|
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
firstname.lastname@example.org 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
# FanConcert: Stale Scores
FanConcert's scoring system allows people to positively or negatively score other people's posts.
When someone looks at a scored post, like a concert date, they'll be able to see how many people agree or disagree with the post. With this information they'll be able to make a better casual determination of the quality of that information.
Why casual determination? Well, just because a dozen people agree with something doesn't make it true. However it's fair to say it's more likely to be true. In theory all 12 of those people could be malicious but in practise they probably aren't.
I'd like to also look into score weighting in the future. The idea being that the better reputation you have of submitting good information to FanConcert, the greater weight your opinion should have on scoring and editing.
A reputation points calculation for each user is in place for FanConcert right now but it's in the early stages. Many other websites use a reputation point system to gauge how much you should trust a user, like eBay. If you're a FanConcert user your reputation points are on your personal home page.
Back to scoring: a venue could have a negative score because its name is incorrect. What if the person who created that venue fixes the name? The score would still say the name is wrong. This is a problem.
So I'm proposing what I call stale scores. The idea is that all scores submitted before the correction would be marked as stale and the venue's score reset to 0.
The users that submitted those scores would be able to see a list of their stale scores and go back and either re-score the posts or do nothing.
Right now you get reputation points for scoring other people's posts. Stale scores could be worth less than non-stale scores, giving people incentive to revisit stale scores and score the posts again.
# FanConcert is Presentable (Just in Time)
For the first time since I started FanConcert I'm working on how it looks. Why wait so long to do that? FanConcert has been live for five months, since the first week I started it.
It comes back to an agile/XP/pragmatic software development practise called YAGNI (You Ain't Gonna Need It). The way I interpret YAGNI is directed at user feedback: solve bigger and more important problems first, narrowing the focus as you go. This way you are less likely to make large mistakes later in the process.
When I use YAGNI to "design" a user interface, how the app works is the first step. In one way, how the app works goes hand in hand with what the app can do. But in another way, how the app works actually depends on what the app can do. What the app can do is determined by the users who are giving feedback as you iterate, who also give feedback on how the app does the what.
A part of how the app does the what is how it looks. Some of the time the shapes and colours are just window dressing, other times they are tightly coupled to how the app works. Colours, icons and shapes can be given special functional significance instead of just looking nice.
I've got a bit of a dependency list going on with YAGNI, which over the iterations narrows big problems down into small tweaks. That's what iterating is all about to me. The whole idea is to make the big mistakes early when you're working on the big ideas.
The last step, tweaking, is small stuff that can take hours and hours of refinements. Eventually you have to draw the line -- and that line can be determined by time, money or both. Tweaking too early can be an absolutely disasterous waste of time because a big change can come along and nuke hours of tweaks. That's what YAGNI aims to avoid.
On a project like FanConcert with limited resources (my own time) I'm especially conscious of premature tweaking. I don't have any time to waste.
Working on big things early means that the users and customer are giving feedback about big things, instead of focusing on small details like colours and button placement. Sometimes I have to do some UI work so the UI is not a distraction from bigger issues but most of the time I like to try to focus the user's feedback on the same level of detail I'm working on.
In FanConcert's case, I thought that the function is nailed down sufficiently enough to work on how the site looked. I'm very happy with the initial run at it but tweaking is inevitable as I start getting feedback on it. Again, I will try to delay some of the minor things until the last possible moment by prioritizing my efforts.
I'm being lazy by delaying things as much as I can but in a calculated, constructive way. That's YAGNI.
# FanConcert Links to Google Music Search
Google has enhanced its search results for musical artist and album names. Thanks to my bro Derek for the heads up and Dave Winer for the link.
It's interesting that Google is partnering with online music stores like Amazon and iTunes instead of trying to take over yet another online business. It's a good way to get into the music business but it makes you wonder if Google will eventually try to sell music themselves. I like that for now Google is sticking with what they do best.
I've already linked to GMS from FanConcert. The artist and release pages have "Google Music Search for this" links which take you to the search results for that artist name or release title.
An interesting little gotcha was ampersands in the artist or album name, like Coldplay's album X&Y or the artist Iron & Wine. Ruby's
I couldn't quickly find a Ruby
# Updated Articles Become Summaries
The most frustrating thing to me about the news media is that it's always current, it's always on the bleeding edge. That might sound a little counter-intuitive, so allow me to explain.
When you read about something that's happened recently, there might be a little bit of background information along with it. That background information is there to serve the new stuff, not to tell the whole story necessarily. To save time and space, news sources often assume you know a lot of the background information already.
Imagine trying to compile a complete picture of some event or issue. In the past you'd have to dig through newspaper archives, go through the stories, take out the stale information that was correct at the time and replace it with the facts as we know them now. It's a lot of work to keep up with an entire story as it happens.
It's also frustrating when you want to know how something turned out. Yesterday you read an article about a 20 car pile-up on the 401. What happened to those people? What caused the accident? To find out, you have to find the last article written on the subject, hoping it will provide some answers. If the event happened over a week ago, good luck!
Well, the media might be changing. What if a news article could change as the facts were exposed or the event continued? You'd not only be provided with up-to-date information at any time during the event but by the end you'd have a pretty good summary as well.
Television and print media have the disadvantage that their news delivery is a snapshot, it's what we know right now. The reports cannot be updated, only re-reported as long as it's interesting -- the news is a business after all. The original reports or newspaper articles live on forever as snapshots of time, even though later on they may found to be incomplete or inaccurate.
The internet is starting to change the rules of reporting and wikis like Wikipedia are a great example. Consider the Wikipedia article about the recent race riots in Australia. It's constantly being updated with information from various sources and at any given time gives a pretty good summary of the events that have transpired. I was equally impressed with Wikipedia's coverage of Hurricane Katrina and many other current events covered on Wikipedia.
Let's not forget that Wikipedia has its faults and shouldn't be considered a primary resource of information. But these summaries are great for people that want to catch up with a particular story right after it happens -- before the documentaries come out explaining the whole thing in detail. Just don't believe everything you read. :)
It would be great if a trusted major media company, like the CBC or CNN, wrote updated articles/summaries like this for major news stories. Sure, they'll update their articles online but they'll write a new article the next day.
Yep, this does relate to FanConcert, where I'm compiling information about artists/bands. The information about future events can be the news. The rest becomes sort of an encyclopedia-like resource of what's happened with that artist. Today's news is tomorrow's resource.
# FanConcert Supporting Syndication
I'm still very busy working on FanConcert full time. This week I've been working on the search results, mostly their look and usability.
Short tangent: Wikipedia has been taking a lot of slack (even in the mainstream media) recently about the quality of some of its articles. I agree with some people who have said that the main problem is that the public thinks that Wikipedia is actually a reliable encyclopedia. It's a perception problem and I don't see Wikipedia doing much to educate the public (a predominant disclaimer on every article might help).
With FanConcert I want to improve on the wiki concept of massive online collaboration by controlling user's input into moderated object attributes and tying contributions to users with reputation scores. Submissions will be weighted based on the reputation of the user which will make FanConcert harder to arbitrarily vandalize, unlike Wikipedia. Users could also be given increased weight for specific things if they are experts on the subject (like an artist or venue) or a direct source, like a band member that contributes concert dates for his own band. You can read my blog archives for more of my thoughts.
OK, we're back: The nice thing about having all of FanConcert's object lists as search results is that all of the list code is consolidated and lists can be modified very easily by changing the search parameters, either on the search form on directly in the (relatively human-readable) URL.
Another nice aspect of consolidation is that it's easier to provide lists in different file formats. As a proof of concept I've made initial implementations of concert search results in RSS, Atom and OPML.
You can "subscribe" to RSS search results with a newsreader, which will check for updates at regular intervals throughout the day for new concerts that match the criteria. Then you don't have to keep checking the website, you just check your newsreader for updates. You could subscribe to an RSS feed that monitors a specific artist or venue for new concerts. This is process is known as syndication.
Syndication is also possible with the Atom syndication format which was recently given RFC number 4287. RSS and Atom do pretty much the same thing but including the extra format is not too hard, so I'm hoping it will make Atom zealots like Tim Bray happy. :) I've been following the Atom/RSS debate a little bit, but as a content provider I'm quite happy to stay neutral and support both formats.
OPML is a format that's been gaining steam lately. Dave Winer contributed to the development of RSS and OPML and is a community leader when it comes to syndication. Incidentally he also had a hand in podcasting, which is getting a lot of buzz lately and has been embraced by Apple and some mainstream radio programs.
OPML could be very useful for storing a list of a user's favourite artists on FanConcert. Users could save their OPML lists as backups and I could allow them to import. OPML could also be used to give lists of RSS feeds (directory in OPML parlance) of upcoming types of events for all of the user's favourite artists.
For example, an artist could have a separate RSS feeds for upcoming concert dates, upcoming album releases and other events. In the future a user could subscribe to all of these feeds en-masse using an OPML list containing all of those RSS feeds. The "directory" grouping of feeds seems to be a very promising feature of OPML but how well will that scale if a user has over 100 favourite artists like I do?
In the future all of FanConcert's search results will probably be available in these formats, as well as other formats that people need. What would be really cool is if I could let people create their own templates so they can make their own outputs from the search results. Then users can support whatever file format they like or use the template support as a custom web service API to FanConcert.
As easy as it is to write templates (views) for Ruby on Rails I can't let users do this because of security concerns (direct use of Ruby
# TODO Lists to Cue Cards
I have moved FanConcert's TODO list from plain paper to cue cards. There are 106 items right now, consisting of known defects and new feature ideas. I've gone through lots of items on paper already over the last few months, crossing them off as I went.
Why is this change significant? I'm trying to match my development process -- however informal it may be -- to the tools I'm using. This is the kind of thing Software Engineers should be doing.
With limited resources (my time) I need to minimize process overhead and maintainance of tools. Sometimes too much process is overkill. Sometimes tools aren't needed when pen and paper will do.
I like the approach a lot of other people have taken: start simple and don't change until something really starts to hurt. Such as: don't make a new hire until you really need to fill the position.
I moved to cue cards after the number of items got unmanagable. I ended up with many sheets of paper, most with half of the items crossed off and it was difficult to see what was high priority. Now I can just sort the cards into "buckets".
I'll probably move to a digital tracking system when I start working with someone else in a team.
# 913 CO Code Causes Problems for 911
I wrote a blog post about telephone central office codes almost two years ago and mentioned how 911 and the numbers around it (912, 914, 915) are not used in case people misdial.
Now 911 operators in Smiths Falls are dealing with people misdialing 913 as 911. These phone numbers look like (613) 913-yyyy and were allocated to TELUS Mobility.
How is this interesting to technophiles and people who study usability? The telephone system connects to a number as soon as it is recognized. As soon as 9-1-1 is dialed on a phone it's put through. Consider how easy it is to push 1 twice by accident and you can see the problem with using 913 (or any 91x). I missed this point in my previous blog post: I thought 3 was far enough away from the 1 to prevent misdials.
This may seem trivial at first but consider how the 911 system works, especially in rural areas. There are only a few operators to take emergency 911 calls. If these people are constantly dealing with misdials they could be too busy to respond to actual emergencies.
It seems like a trivial thing at first -- but when real lives are at stake trivial technical problems can lead to big consequences. Being more familiar with technology and usability, engineers have a duty to alert managers above us about possible problems like these.
Clearly the 913 CO code should not be used at all.