On May 16th, I ran in the 7th annual Mississauga Marathon. This was my fourth marathon, and I’d decided to run it sometime back in March, after being unhappy with my result in the Toronto Good Life Marathon in October of last year. (Which I had run only two months after the Edmonton Marathon)

Though I had qualified for Boston during the Edmonton Marathon with a time of 3:02:50, I decided not to register for Boston after my poor performance in the Toronto Good Life race. I wasn’t sure I’d be ready again for another marathon in mid-April, and the timing with my schedule wasn’t ideal either.

However, by the start of February I was feeling better and started getting back into training mode. I had a May marathon in mind, which would give me a solid three months of training – more than enough considering the base level of training I’d maintained over the winter. However, I didn’t want to push myself and commit to something I couldn’t do – so I did not register until the end of March, when my condition was more certain.

And so when May 16th came, I was feeling pretty confident. I’d run the Sporting Life 10K two weeks before, finishing in 39:38, within my target time of a sub-40 minute run. I had a target time for this marathon of anything under 3:20, not enough to qualify for Boston since I didn’t want to push myself, since this was partly the result of why I’d done poorly at the Good Life Marathon last year.

The first three-quarters of the race went well, and I was able to maintain a fairly even pace, passing the halfway point at 1:33:55. While things went smoothly for the first 30 km, at about the 35 km mark I started feeling some slight leg cramps and had to slow things down. I lost quite a bit of time in the last 7 km, and managed to finish in 3:13:06, less than three minutes away from qualifying for Boston again.

While I was disappointed at coming so close to a qualifying time, overall I was happy with the result, having met my original target and improved substantially from my previous marathon. Despite this being my fourth marathon, I still feel that I’m very much a beginner at this, as I need to work on my overall race strategy, pacing and training if I want get more consistent results. I’ve thought about doing another marathon in the fall, perhaps the Toronto Waterfront Marathon (thus completing the GTA marathon three-pack), but I don’t want to push myself. I’ll see how the summer plays out.

Review of the Mississauga Marathon

While the above is more of a personal anecdote, I’d like to point out some of the pros and cons of this race in case you’re interested in it. I decided to run this race because of its close location to me. The other obvious choice for a May marathon would’ve been the Ottawa Marathon, but I didn’t want to deal with the extra headaches of travel and staying overnight. Driving to the race took me only about 40-45 minutes, and would’ve been faster if the Gardiner Expressway wasn’t closed that weekend for repairs. (What timing!)

The course itself was a point-to-point race, with a net elevation loss of 80 m from start to finish, resulting in a gentle slope along the way. I’d say most of that drop came in the first half, with the last part mostly flat. There’s a few rolling hills along the way, but nothing steep and unexpected. Overall, the elevation profile was quite forgiving. In my experience, large elevation gains or drops aren’t ideal for marathons; running downhill for long periods of time will kill your quads, and running uphill is hard for obvious reasons. My ideal course would be flat – but the gentle downhill route of the Mississauga Marathon was still quite runnable.

The course starts at the Square One shopping mall, which ought to mean a lot of parking – after all, suburbs are the land of the automobile – but unfortunately only certain sections were available since the mall was open for business that day. Considering that around 7,000 people were running the marathon or half-marathon that day, that adds up to a lot of cars since that was the only real way to get to the race. As expected, parking was a nightmare – I got there about 30 minutes before the race start at 7:30 AM, and that was just enough time to find a parking spot and get ready for the run. My advice is to arrive early – earlier than you think necessary – to avoid rushing.

I had to park some distance away, probably around 500 m, but this wasn’t a problem – I used the travel distance as a warm-up for the race. However, by then the lineups for the porta-potties were too long and I didn’t get a chance to go before the race start. This wasn’t really a problem for me either as I just went at the first opportunity at around the 4 km mark.

The course scenery was pretty relaxing and the atmosphere nice. Spectators were out in full force even in the first half, adding a nice touch to the calm suburban setting of the race. The nice thing about the suburban course is that the roads were generally in better shape than the road races I’ve run in cities. However, there were some drawbacks.

Potential drawbacks

Firstly, some parts of the course were on single-lane roads, with only one side available for runners and the other open to traffic. Only a sparse line of pylons marked this, and some confused drivers didn’t seem to understand their meaning. Traffic control along these stretches could have been better. This isn’t to say that police and volunteers didn’t do a good job – I just think there could have been more of them along these sections.

Secondly, some of the sections went along the trails at the waterfront. While these gave a nice few of the downtown Toronto skyline, (made better by the sunny and clear weather that day), the trails limited the width available for runners and really required people to obey proper etiquette. This didn’t really bother me, but it’s something to be aware of.

Lastly, since it’s a point-to-point course, the marathon organizers had to recruit some public transit buses to get people back to the start from the finish. With over 7,000 participants, you can immediately see the problems with this. The wait times were quite long and made worse by the understandably bad traffic in getting back to the start. Being cramped into a bus full of sweaty runners (myself included in that group) could not have been nice either. Make sure you have water or are hydrated before lining up to get on the bus, as it took about 45mins-1hr to get back.

Timing

The weather was great that day, with a starting temperature of about 9C, rising to 16-17C by the time I finished. It was sunny, fairly clear and the wind was not bad. I couldn’t have asked for better conditions, considering that the weather in May had been a rollercoaster ride – two weeks ago during the Sporting Life 10K, the temperature had been near 20C with high humidity, while the week before the marathon the temperature hovered just above freezing and I had to wear winter running gear for my last long run!

Considering that the following week temperatures pushed into record highs, I think we were quite lucky with the weather timing of the Mississauga Marathon.

In general, this is a problem with spring marathon, in that the weather can be unpredictable. If it’s hot, things are made worse by the fact that you’ve done most your training during the colder preceding months, limiting your exposure and tolerance for hot weather running.

Overall, I was pleased with the Mississauga Marathon. The aid stations were well-organized, and the crowd support was great, with one nice lady even setting up her own lemonade aid station outside her house! I’d very much consider doing this again and think it makes a great choice for a first marathon or half-marathon.

Opera had previously announced that it had submitted its browser to the App Store for approval back on March 23rd, in an effort to drum up support for its inclusion in the App Store. Back then, many suspected it would likely be rejected on the basis of it duplicating built-in functionality on the iPhone, namely the included Safari web browser. (Though some questioned this analysis)

Whatever the reason, this comes as a surprise to many, especially given Apple’s most recent behaviour towards potential competitors and development on the iPhone in general. Nonetheless, let’s give Opera Mini for iPhone a quick test drive!

The Opera Mini advantage

To begin, it’s worthwhile to understand that Opera Mini is not a regular web browser, in that it does not make direct connections to websites to retrieve their content, unlike Safari on the iPhone or any other desktop web browser. Instead, all requests are handed through a proxy server that Opera controls. This proxy server retrieves the remote web page, reformats the content for better display on a mobile screen and finally compressed for delivery to the end device. The format used is Opera’s own, called OBML, and furthermore the pages need not be delivered to your device over HTTP. (More information on this Opera Mini infrastructure is available here.)

Ostensibly, all of this work is done to improve the mobile browsing experience in at least two ways. Firstly, the size of each webpage is reduced, thus speeding load times. Secondly, the content is reformatted by Opera’s servers to allow for mobiles to better display content that was only designed with computer monitors in mind.

These features certainly made sense for a phone like the Samsung M510, my first mobile. But what about the iPhone 3GS and its larger, high-quality screen and faster HSDPA access speeds? In this case, are these optimizations even needed or helpful?

The iPhone Experience

The Opera Mini browser has the same general UI layout as Mobile Safari, which is unsurprisingly given the smaller real-estate of mobile screens – there are only so many UI configurations for a web browser on such a space and even fewer potential effective ones. There’s the address bar up top, with a web search field in the upper right corner. The list of search engines is also configurable. Standard browser buttons such as back/forward, reload and tabs are at the bottom of the screen.

When opening Opera Mini the previous state of the app is restored, so the current page you’re on as well as any open tabs you had when you closed the browser remain. This was pretty much expected – anything less would be a huge mark against the app. Opera Mini has a unique tab switcher, one that’s arguably better than Safari’s. When activated, it allows you see to quite a few more tabs than Safari, which just shows you the previous and next. Switching between them is pretty easy, as is opening a new tab.

When opening a new tab, the default page is Opera’s “Speed Dial” feature, something a heck of a lot more useful than the blank tab Safari gives you. It’s easy to configure what pages show up here.

Reading webpages with Opera Mini

The standard tasks of scrolling and zooming were okay, though there are some differences from Safari. In particular, it didn’t appear possible to click a link based on “small” text without zooming into the appropriate section; zooming is also accomplished with a single-tap, not a double-tap. I suspect the two changes go hand-in-hand. This is actually a decrease in functionality from Safari – Safari had some pretty good detection for helping you click smaller links with fat fingers without having to resort to zooming in on the area. Opera now forces the issue.

Opera also implements double-tap to zoom out. But it’s a bit more sensitive as to exactly what constitutes a “double-tap”. In Safari, you don’t have to double-tap exactly in the same spot in order to trigger the zoom out action. Opera Mini seems to be a bit more sensitive to exactly where you double-tap before it zooms out. This impairs usability somewhat.

Selecting text was straightforward; simply tap and hold a section and you can select text using a resizable box. The text can then be copied or used to search.

Other features

Because Opera Mini was going through a proxy server and dynamically reformatting the content before passing it to your device, I had some worries that websites would not properly detect the user-agent of the iPhone and thus would not redirect to iPhone-specific sites. But during my testing, thankfully this was not the case. Most redirected properly to their mobile versions, if available.

Opera Mini also two other features of note: Full screen and Mobile view. Full screen (see below for The Globe and Mail’s website) simply removes the bottom bar and gives you only the minimum amount of browser UI you’d need, saving you a little more space for the actual website.

Mobile view, which is far less useful, causes Opera Mini to reformat the entire website to “fit” the layout of the screen, rather than just text. I use quotes with the term “fit”, because the reformatting of Mobile view is in general, quite awful and results in a mangled look. Perhaps it made sense to do this kind of reformatting on the extremely small screens of older mobiles, but it simply makes no sense on the iPhone. You can see the results of this by comparing the CBC News website in normal versus mobile rending mode below.

Comparison with Safari

The real question, however, is how does Opera Mini compare with Mobile Safari? After all, this is its main and perhaps only competition it faces on the iPhone, and furthermore Safari is entrenched with most users simply because of its strong tie-in with the iPhone platform. If Opera Mini hopes to win any market share, it can’t just be as good as Safari – it has to be a lot better so people will switch.

Unfortunately, this isn’t the case. In my opinion, Opera Mini is actually behind Mobile Safari in many areas. Furthermore, the main benefits of Opera Mini actually don’t matter that much on the iPhone.

Opera Mini uses its proxy server setup in order to speed access by compressing pages before they’re sent to your device. During testing, this benefit was minimal over 3G or Wi-Fi networks and in fact Opera Mini may have been slower in some cases due to the delay induced by having to wait for page compression on Opera’s servers. To be fair, Opera focuses on the comparative speed advantage on 2G/EDGE data networks, so if you’re in that situation it may have some real benefit.

But even considering this, the entire model that Opera Mini uses completely breaks end-to-end security, so accessing HTTPS sites no longer guarantees confidentiality unless you completely trust Opera and trust that Opera’s servers won’t be compromised.

But these might be implementation details – what do they matter? Unfortunately, the end user experience also suffers in the way text is rendered and formatted by Opera Mini. See the comparison of Engadget’s site below in Opera Mini and Mobile Safari:

At the fully-zoomed out level, all text is basically unreadable in Opera Mini, while in Safari this is not the case. Some images also looked aliased, owing to Opera’s compression of the page.

Even zooming in, we can see some differences. Firstly, Opera Mini seemingly switches the rendering of the website-specified font to a sans-serif one, while Safari maintains the actual font for the text. Safari also keep the original layout, allowing the text to flow around the image and still be readable. Opera Mini seems to just reformat the text to fit the width of the screen without regard for maintaining the overall layout of the site. In this respect, Safari better preserves the original look and feel.

But perhaps the biggest hit against Opera Mini is its lack of fully supporting JavaScript. This is again due to the proxy model it is using. Because of this, the functionality of web applications is severely impaired or even blocked. Meanwhile, Safari is a fully-featured browser supporting Ajax techniques and even subsets of HTML5. These differences are most apparent when looking at how Gmail renders in each browser:

Opera Mini cause Gmail to step down to a primitive version, something you’d expect to see on older mobiles. Safari, however, has access to an iPhone-optimized version of the web application, which Google has been available for some time, is being constantly improved and arguably better than the built-in Mail app.

The fact that Safari works so well for the web should be no surprise, since Apple’s original plan was for their WebKit browser to be the only “SDK” for the iPhone. That is, web applications would be the way developers would make apps for the iPhone – no App Store involved. With this in mind, Apple engineers put a lot of work in to Safari to make sure it would not only be a good web browser, but one that would be able to run the future of web applications, and look good doing so.

Because of this, Opera Mini had a formidable opponent to go up against. The fact that it couldn’t beat it is not a reflection of Opera’s ability, but more a reflection of the time Apple spent on Mobile Safari.

Conclusion

I may have seemed a bit harsh and some of the criticism of Opera Mini may have been unwarranted. After all, it’s a free download, so can you really complain? I just don’t think I’ll be using it to replace Safari any time soon and that its current popularity is simply a result of the drama played out in the App Store and exaggerated by blogs.

If you’re using jQuery, you’ll no doubt be aware of the click() method which can be used to trigger that event on an object. One would think that executing click() on an anchor element would cause the browser to navigate to the URL, but this isn’t the case. You cannot use jQuery’s click() method to fully trigger or simulate a user clicking on a link.

Instead, click(), when executed on links, only seems to trigger any event handlers attached to the DOM element rather than any default behaviour. I’m not sure if this is the case with other event methods or other DOM elements.

The solution

Instead, the solution is to directly manipulate the window.location object from JavaScript. One would think that since preventing the default action is quite simple (with jQuery’s event.preventDefault()), triggering the default action of a link click would also be. But this isn’t the case. Here’s a simple example on how to simulate a user clicking on a link.

In this contrived example, we have an ordered list of links that we’ve prevented the default action from executing on each. Instead, to activate a link we’ve provided an input box for the user to input the link number and then hit ‘Go’. When this happens, we grab the identified link and assign the href attribute value of the link to window.location, effectively recreating the default action of clicking the link.

HTML Source:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

  <title>jQuery Demos</title>
  <link rel="stylesheet" href="styles.css" media="all" />
  <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
  <script type="text/javascript" src="scripts.js"></script>
</head>
<body>

<h1>jQuery Demos</h1>

<ol id="outboundLinks">
  <li><a href="http://www.google.com">Google</a></li>
  <li><a href="http://www.theglobeandmail.com/">The Globe and Mail</a></li>
  <li><a href="http://stackoverflow.com/">Stack Overflow</a></li>
</ol>

<p>
Link Number to activate:
<input id="linkNumber" type="text" size="3" />
<input id="activateLink" type="button" value="Go" />
</p>

</body>
</html>

JavaScript in scripts.js:

jQuery(function(e)
{
  jQuery("#outboundLinks").click(function(e)
  {
    e.preventDefault();
  });

  jQuery("#activateLink").click(function(e)
  {
    var links = jQuery("#outboundLinks li a");
    var value = parseInt(jQuery("#linkNumber").val());

    if (!isValidNumber(value, links))
    {
      window.alert("Invalid link number.");
      return;
    }
    else
    {
      // This won't work.  We cannot trigger the default
      // behaviour of clicking on a link this way.
      // links.eq(value - 1).click();

      // Instead, manipulate window.location directly.
      window.location = links.eq(value - 1).attr("href");
    }
  });
});

function isValidNumber(value, links)
{
    if (isNaN(value))
    {
      return false;
    }
    else if (value <= 0 || value > links.size())
    {
      return false;
    }
    else {
      return true;
    }
}

Note that window.location is not a regular property; it’s a special object that when assigned to, changes the URL in the address bar of the browser. There’s some debate over whether to directly use the location object or to use the window.location.href property.

This accomplishes the task of triggering the default action of clicking on a link, albeit in a roundabout fashion. Note that this example will only work for regular links that use href attributes as the source of the new URL. If you have links doing more complicated things via the use of event handlers (i.e. Ajax), then you’re better off using click() or directly invoking the JavaScript methods involved.

I’m a bit of an information pack rat. When I have an idea or something I need to keep track of, I have an immediate need to write it down or record it. In the past this has resulted in an assortment of post-it notes, notebooks or even loose papers lying around my desk, all used to document my thoughts. Eventually, I tried to move my note-taking over to the PC in an attempt to make it easier to manage, but over time the notes became spread over a variety of formats and storage mediums, from text files on my local PC to online services such as Google Calendar and Dropbox.

This sort of digital storage Balkanization was becoming a nightmare to manage and effectively neutralizing any benefit from taking notes, since finding and keeping track of what I’d written down was becoming a chore by itself. Clearly, a unified solution was needed. Ever since I got my iPhone last year, I’d been looking for an app or service that would allow me to easily keep track of todo and shopping lists (what most of my notes amounted to), while storing the the data online so that it could be synced or updated from my PC as well.

I think I’ve finally found that with Awesome Note.

What I was looking for

As mentioned, I love keeping lists. So what I needed was an app that could allow me to easily keep track of lists as well as allow me to backup or sync the underlying data in such a way that I could also work with the lists on my PC or online. The built-in Notes app didn’t meet my needs because you could only sync it with certain supported software, such as Outlook, which I didn’t use or care to use at home.

Browsing through the App Store was almost an exercise in futility. Trying to find a decent note-taking app (or any app, for that matter) is a time-consuming activity; I didn’t want to shell out any money without being able to first try the app out, so many apps were immediately ruled out.

The first one I tried was one aptly named Lists. While it was functional and had support for lists and lists-within-lists, it was buggy and the UI left a lot to be desired. The next one I tried was Evernote’s app; while Evernote is a nice service, the iPhone app left a lot to be desired. While the web application or the PC software allowed you to take all sorts of notes, only basic editing functionality was available on the app, and it was suited for a more general note-taking approach rather than one for lists and the like.

I stumbled upon the free version of Awesome Note soon after, which thankfully was fully-featured but limited you to only a few notes. Nonetheless, I was immediately impressed.

Just felt right

Right off the bat, I was impressed by how easy it was to create a list and add items. When creating an item, you can use the “quick-add” functionality that allows you to nicely add a new item while staying on the same screen; if necessary you can later add a longer description on a separate screen. Furthermore, it’s easy to sort items by date, name or priority; more importantly, there’s a robust search function as well. Swipe-to-delete functionality is also nicely handled.

You can create multiple folders, each to store separate items, for example, a shopping list and a todo list. Each folder has its own view options, either thumbnail, lists or todo view, store separately so you can sort through different lists in different ways, each remembered by the app. Furthermore, it’s easy to convert an item to a todo item; you simply tap a box next to an item to change its state from done/not done and there’s no need to navigate complicated setup screens to change this.

There’s also a “Quick Memo” feature, which gives you a notepad to quickly jot down ideas that you can later convert into a fully-fledged note or item. It basically replicates the functionality of the built-in Notes app, all while providing some other nice features such as adjustable fonts, just like the rest of the app.

Furthermore, the UI was very polished; each folder can be identified by colour and an icon of your choosing. A nice assortment of these icons/backgrounds is provided, all of them looking great. In short, everything looks very well refined and well thought out, making list and note management very easy.

But most importantly, the sync worked great out of the box. I tied it to my Evernote account, and as a result I now have the unified access to my notes that I so badly wanted. I’d previously used Dropbox or even my own SVN server to get some semblance of cloud-based storage and access to my notes, but but neither was sufficient to properly work with my iPhone. Awesome Note now provides that functionality, with a great UI/front-end making list/note management a breeze.

I strongly recommend giving it a try if you find yourself using your iPhone/iPod Touch to take notes.

Back on November 2nd, the City of Toronto launched their toronto.ca/open service – a project aimed to be the “official data set catalogue” of the city. Part of the OpenTO initiative to make various data that the city has collected available to developers in formats that make them easy to manipulate, toronto.ca/open is the first step to making the city and its services more “open and accessible”.

The hope is that if the city makes this information available in a readily-usable form, developers will take the time to create various services around them, helping citizens enjoy and take advantage of what Toronto has to offer. For example, data on garbage collection, public transit or upcoming city events could be used to create a service that would alert users through various means of communication. But at present, the amount and types of data available are fairly limited.

Announced back in April at the Mesh Conference in Toronto by Mayor David Miller, the openness initiative had a lot to live up to in the half-year following up to its release earlier this month at the Toronto Innovation Showcase.

Several cities have already implemented similar projects, leaving Toronto to play catch-up. Vancouver, for example, launched their own Open Data initiative earlier this year, and Toronto’s data catalogue appears to be modeled after it. Edmonton, a much smaller and less dense city than Toronto, has also recently begun an initiative to open their city’s data to the public in a similar manner, with promising results.

But the data is better late than never, so I applaud the City’s effort to democratize and help keep citizens better informed.

The data itself

Looking at what’s offered, you can see that most of the data sets or services have a geographical component to them. This only makes sense, as hyperlocal information is always of great interest to most people.

The data is presented in a variety of formats, but the most popular seems to be an ESRI Shapefile, a file format used by a popular suite of GIS software. With much of the data having a geospatial aspect to them, this makes sense as the data likely didn’t require much conversion before being released by the City. (I.E., they probably use ESRI’s application for city planning, etc.)

Thankfully, the format has been well-documented by its developer, and Wikipedia as well. All of these ESRI Shapefiles are intended to be downloaded for offline use, as they are typically made available inside of a zip file. Thus, the process of keeping them up to date may prove tedious, though I’m sure an enterprising developer could automate it nicely.

Other data has been made available in various XML formats. Some are intended to be accessed as online services, with a link to the XML document and the corresponding XSD file, while at least one is presumably meant to be used offline since it’s zipped up. Some of the XML “Feeds” are also in a format without a defined schema and are not RSS or Atom feeds. For example, the feed of City-sponsored events would be better served by an RSS or Atom feed, which would not only allow developers to integrate it into an application, but also regular users to sign up to the feed using any newsreader.

There are also some web services explicitly offered. The first is a geocoder service that can be used to validate addresses and other place names within the City. It is a WSDL service, and there is a full PDF file to document the input parameters and expected output.

The second is a series of services that provide access to “live geospatial data from the City of Toronto“. These are all Web Map Services that conform to a protocol specification developed by the Open Geospatial Consortium. It would have been nice if they had linked to the WMS Specification (PDF document) that explained how to query the services, instead of forcing you to find out the information yourself. (See page 14 and onwards of the mentioned document)

Lastly, some of the data is offered in plain old text files. In particular, the TTC Routes and Schedules is only available as a series of zipped text files that are periodically updated, presumably manually. This may be a bit backwards, but thankfully the formatting is well-defined.

Drawbacks

Though it may not be fair to criticize at this point, there are some clear limitations to the data. Firstly, much of the data is intended to be downloaded and then used in an “offline” capacity, that is, without further communication between the application and the City’s servers that host the data. Though this was probably done due to technical limitations (i.e. reducing bandwidth usage), it limits the ability of an application to stay up to date with the latest data. For things like the TTC Route and Schedules and the list of Apartment Bylaw Infractions, this severely reduced their effectiveness as the data will likely need to be periodically manually updated.

Furthermore, the current data set is somewhat limited and may impede the usefulness of any applications or services that can be developed. For example, making real-time TTC updates and other data available would be an immense benefit, yet the only TTC data currently available are in zipped text files that are only periodically updated. Thankfully, the City has setup a site to allow users to request more data, and there are already many requests for more TTC data.

It would also be nice if crime statistics for Toronto could be made available in an easy to use format. In particular, the underlying data used by the TPS to produce their crime maps and statistics could be beneficial in developing all sorts of interesting maps. In fact, this is what the Toronto Star has been doing for some time, but they had to get the data through an explicit request under access-to-information legislation. Since then, they’ve produced some very interesting maps and it would be beneficial if everyone had access to the same data so that the maps could be improved upon and kept up to date.

Producing such crime-based maps can provide people with one more factor to help them determine what part of the City they’d like to live in, or just allow them to have access to accurate statistics on crime. Not all of this is negative – as any study of crime in Toronto will show that it’s been following a downward trend for quite some time, so such information could help ward off any potential negative spin that media may put on crime. However, I do realize the privacy implications that come with releasing such data, so time should be taken to ensure that it is released in a manner where anonymity is preserved as best as possible.

Lastly, it’s important to note that the OpenTO initiative is still at a very early stage. Even with the way things move at City Hall, things will eventually improve. It’s also very important to give your feedback, either at DataTO or directly by email to opendata@toronto.ca. Additionally, if you’re a developer, the corresponding Google Group is a good place to get started. Even with the current limitations, I am sure we’ll see some great applications developed based on the data. One need only to look at MyTTC to see what can be done with some effort and ingenuity – and this was done well before the City officially released any data!

After much delay, possibly due to government meddling, Google Street View finally went live in select Canadian cities last week! Most of the GTA is covered, along with Kitchener/Waterloo, Ottawa, Montreal, Quebec City, Halifax, Calgary and Vancouver. This likely ensures coverage for a majority of Canada’s population, if only a very small minority of its geographical area.

This is a welcome move, since street view has been available for our neighbours to the south for the past two years.

According to some reports, Street View was supposed to launch in Canada earlier this year, and some of the imagery was collected as early as 2007. (Though the images around my area seem to be from early this year) Oh well, this is better late than never!

I’m speculating that the government’s concern with Google Street View may have slowed deployment, as in 2007 the privacy commissioner voiced strong concerns against the technology. I’ve never believed any of that FUD, but it seems that their concerns have been addressed with Google’s automatic detection and blurring of faces and license plates, along with new straightforwards processes to request that your image be removed from the service.

But it’s still been much ado about nothing, not really like the conflict between the government and Facebook earlier this year, which was also subsequently resolved. In the case with Facebook, privacy settings were often complicated and unclear; with Google Street view, they’re merely providing public views of public places, so I don’t see what the problem with that is.

Also available on the iPhone/iPod Touch

You can also use Street View on the built in Maps app for the iPhone OS, though it’s a bit convoluted since there’s no “Street View” button to toggle. Instead, you must first drop a pin (click on the “layer peel back” icon in the lower right corner) and then bring up the dialog box for that pin. If it’s in an area with Street View present, the little guy icon on the left will be lit up and you should be able to click it to bring up Street View.

Street View only works in landscape mode but it’s still pretty useful for getting to know an area before you visit it for the first time. Sometimes an actual image can convey sense better than just a map.

Competition?

It remains to be seen how the launch of Street View in Canada will fare for the similar service launched by Canpages in BC. That service only covers Vancouver, Whistler and Squamish but was launched back in March.

Nonetheless, it’s very neat technology, even if it was originally unveiled over two years ago. Witness this by the fact that reporters are still drooling over it by embedding the service in every article covering the launch.

Well, I finally gave in and joined the cult of iPhone. At the beginning of this month, I decided to splurge and get an iPhone through Fido, Rogers discount brand. Why? I suppose it had something to do with the extension of the 6GB/$30 “promotion” or the fact that I was able to find a 3GS for sale locally, but mostly it had to do with the fact that I needed a new toy. (Note that the iPhone is hardly a novelty item, with >21 million of them out there)

Keep in mind that I didn’t have a mobile phone until late 2007, and even then I decided to only go with a prepaid provider (Virgin Mobile) because I didn’t have much of a need for a phone, but really just wanted Internet access. However, this past summer my phone got more use than usual, especially with regard to Internet access. With Internet browsing being anemic on most non-smartphones, I decided it was time to upgrade.

I narrowed my choices down to two: Either the Palm Pre or the iPhone 3GS. However, I wasn’t very pleased with what plans Bell had to offer and wasn’t sure if the Pre developer ecosystem (and thus the applications available) would turn out to be as varied as the iPhone. So, I decided to join the cult.

Another reason that led me down this path was the fact that I already had an iPod Touch from earlier in the year, and so I was already used to the iPhone interface. (I’ve since sold the Touch) And yes, I do realize in that very article I berated the monthly cost of the iPhone only to now end up doing a complete 180 on the situation. It’s not that I’m happy with what I’m paying, but rather that I’m willing to suck it up. Such is the power of the cult, and perhaps one of the reasons for the iPod Touch’s existence – to suck users into getting an iPhone. After all, Steve Jobs did describe it as “training wheels for the iPhone”, but perhaps “gateway drug to the iPhone” would be more accurate.

Fido actually had some okay plans; okay for Canada that is. In the end, I’m paying just about $80 CAD a month. (including taxes) It’s about $50 more than I was paying for my old phone, which is quite a bit, but the iPhone has been invaluable in the intervening period after moving where I didn’t have Internet access at home. We’ll see if it doesn’t lose its appeal in the coming months.

In the meantime, however, it’s been a blast. There are literally too many apps out there to try, so I’ve only had a chance to play with the more popular ones. Some of my favourites include the AllRecipies dinner spinner, Wikipanion, Restaurantica (which I’m surprised isn’t promoted more on their website), and of course, Shazam, the accuracy of which continues to amaze me!

But the most useful features for me have been the always-available easy-to-use Internet access and the access to Google Maps overlaid with GPS. It’s been invaluable, especially after moving to a new city. Without it, I’d literally have been lost more than once.

Despite all the positive features, there are still some sore points. Firstly, battery life on the 3GS is atrocious, as reports have indicated. On a full charge, I can barely last two days with moderate data usage, some music playback and hardly any YouTube/video usage. Be prepared for the daily recharge should you get this phone.

Additionally, being an Apple product the iPhone looks very attractive but is a dirt/dust/fingerprint magnet. Even with the new oleophobic coating (fancy word for anti-fingerprint) you’ll still probably want to get a screen protector and case for this device. I’ve opted for the Speck PixelSkin, which I believe is one of the better cases out there, as it’s tough, rigid and adds a nice grip to the iPhone.

Lastly, there are no good default ringtones supplied with the iPhone! I don’t need some fancy pop-music ringtone, I just want something that sounds normal. Thankfully, a coworker directed me to the perfect iPhone ringtone, and I’ve since been happy with it.

I’ll leave you with some comparison pictures of the iPhone 3GS and the iPod Touch 2nd generation.

With JavaScript there are actually two concepts at play when using logical operators: What is actually returned from the result of a logical operation, and how variables are converted to boolean values when the context requires it.

Undergoing a conversion

Firstly, we’ll look at how variables in JavaScript are converted to boolean values. One way to explicitly convert a non-boolean value to a boolean one in JavaScript is to use the global Boolean object as a function. By using the following code, you can explicitly get the boolean conversion of a variable or expression:

var asBoolean = Boolean(someVariable);

The variable asBoolean is now guaranteed to have a boolean value. Note that this is not the same as the expression new Boolean(someVariable), as that returns a Boolean (wrapper) object representing the converted value of someVariable, not a boolean primitive.

So what values of someVariable will result in true being returned, and which ones will result in false? The following values will evaluate to false, while all others will evaluate to true:

• 0 or -0 (Most floating-point implementations have positive and negative zero, due to the IEEE 754 standard)
• null
• undefined
• NaN
• The empty string (“”)
• false itself

This means that all other expressions or values, including any non-null object (including the Boolean object for false!) and the string “false” will be converted to true.

Note that using the Boolean function isn’t the only way to explicitly convert a variable to its boolean equivalent. You could also apply the logical NOT operator twice, like so:

var asBoolean = !(!someVariable);

This is because the contract of the logical NOT operator in JavaScript is to return false if the operand can be converted to true and true otherwise. The second NOT simply reverses the negation done by the first NOT operator. While all of this may seem dead simple, it will be important to note as we move on to how other logical operators work.

Logical conversion

This is perhaps the most important difference with JavaScript. Although the logical NOT operator (!) is guaranteed to return a boolean value, the logical AND (&&) and logical OR (||) operators are not. This is by design, and although it might be a bit of a change for some developers, the feature can actually be quite useful.

Consider the following code examples:

var result = a && b

In this example of using logical AND, a is returned if it can be converted to false; otherwise b is returned.

var result = a || b

In this example of using logical OR, a is returned if it can be converted to true; otherwise b is returned.

This means that one of the original operands or expressions used with the logical operators will be returned as a result of the evaluation. You will not always get an actual boolean value, unless both of the operands were booleans to begin with. Usually, this doesn’t matter, since if you use the result in a boolean context, it will get converted to the expected value. For example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (result)
{
  window.alert("At least one string was not empty");
  window.alert(result);
}

This example will output “At least one string was empty”, and then “a string that is not empty”. This is because the logical OR operator first converts string1 to a boolean, which results in false. Thus, the result of the logical OR returns string2 into the result. Since the result is now a non-empty string, it converts to true for the if-conditional.

This also highlights a convenient way of using logical OR – give me the first expression if it evaluates to true, otherwise give me the second. This is usually used to test for the availability of built-in objects in a particular JavaScript environment.

However, consider the following example:

var string1 = "";
var string2 = "a string that is not empty";
var result = string1 || string2;
if (true == result)
{
  // We will never get here.
  window.alert("At least one string was not empty");
  window.alert(result);
}

In this slightly changed example, instead of directly supplying the result to the if-conditional, we test whether it is equal to true. In this case, it fails, since when using the equality operator, operands are not converted to booleans. (Using the strict equality operator also would not work)

This underscores an important point: If you actually want a boolean value to work with, you will have to explicitly convert it, using either the Boolean function or a double application of the logical NOT operator, like so:

result = Boolean(result);
// Or, we could do this:
result = !(!result);

Conclusion

JavaScript offers some neat features due to its dynamic typing and these can help speed development, but you just need to be aware of how they work so that you don’t get tripped up. This is especially true when dealing with implicit type conversion and how logical operators work. I hope you found this helpful and as always, any feedback is appreciated!

References

1. Logical Operators
2. Boolean Object
3. Boolean Description
4. Comparison Operators

To me, a lot of this UI complexity stems directly from a lack of separation between the UI and business logic layers.

Proper separation

As developers, we’re accustomed to the best practices of modularity and separating the implementation from the interface. This has lead to such patterns as MVC and Interface Oriented Design. However, when it comes to designing the UI layer, these rules sometimes aren’t followed. This is why we end up with overly complex “Search” pages, offering every option under the Sun, and configuration dialogs/screens with a one-to-one relationship to settings files or some other underlying implementation detail under the guise of “letting the user decide what they want”.

Without clear UI planning, this one-to-one relationship tends to rear its ugly head more often. Take our first example of a “Search” page. In most applications, the search functionality is interacting with some sort of a database backend, most likely a SQL RDBMS. The lazy approach is to design the search form based on the format of the SQL query itself. This is how we get search forms with multiple fields, drop-down boxes and so forth – because this format translates almost directly into a SQL query; i.e. of the form WHERE col1 LIKE... AND col2 LIKE...

Just because this is easier for the developer, doesn’t mean it’s the best solution for the end user. In fact, it’s often the case that this is the exact opposite.

Thinking like a user

In general, users don’t care about the implementation of your application or how it stores data. They shouldn’t have to know about the columns of the table where the data is stored, so why make a search form that exposes this? Instead, you need to understand what your users want and how they’re most likely to use your application. This isn’t an easy task, as many have pointed out.

This is where I think most UI problems come from – a misunderstanding of what users want. This isn’t to say that these developers are dumb or careless; but just that when it comes to empathizing with their users, they often are unable to because they know their own software and have such an intimate view of it from a coder’s perspective.

Take the example of QTTabBar, a Windows Explorer extension written in .NET that adds many useful features such as tabs, etc. to the interface. It is an excellent extension and does things very well, but the options page is a complete nightmare.

There are just too many options on this one page; what do they all mean? Furthermore, there are nine more tabs, each with roughly the same number of additional options! This is far too complicated, and I’m guessing most people will never have a use for all of these options.

Of course, it’s completely unfair of me to pick on QTTabBar in this manner, considering it’s written by one guy who has chosen to give it away for free. And, as I mentioned before, it’s a very useful utility that I can wholeheartedly recommend.

A simple story

Take a simply example, where we want to search a set of items, each of which have four separate properties – name, description, URL and tags. The items are displayed on screen with all of the four properties shown. The naive way would be to provide a search form that had fields for each property and allow users to search that way.

But with this simple (albeit contrived) example, there is an obviously simpler solution. Since all of the four pieces of information about an item are shown onscreen, it would be much better just to provide a single search field whose input would be used to search all four properties, returning all items that had a match in any of the properties. From a user’s point of view, this makes sense, since they are searching through what they know they can see and interact with.

If an advanced search was needed, it could be added later, but I would only do this if I knew it was absolutely needed by users, since the simple case is likely good for >90% of your users.

Motivation and Usage

There are numerous reasons for using the user’s location to improve the quality of a service. For example, the restaurant guide and review site, Restaurantica, automatically makes a guess as to your location and populates the “Search” field so that you are one click away from finding information tailored to your geographic area.

This determination is based on the user’s IP address. Usually, the lookup is done based on a static set of mappings from IP addresses to geographical locations, like cities. In fact, this is exactly what the IP address geolocation database (that we’ll use) does. It has the advantage of being easy to understand but unfortunately the accuracy can degrade over time, as IP addresses are usually not hardwired to specific locations. For example, most DSL users are subject to DHCP, so the same IP address may be re-used across different cities. (The IP address database from IPInfoDB is updated periodically to help reduce this inaccuracy)

Thus, you should not rely on the information provided to be 100% accurate; it should only be used as a suggestion. This is why Restaurantica only populates the search field with your estimated location, rather than giving you the results for that location right away; if it was wrong, the results for a different location would certainly be confusing to a user. This gives the user a chance to correct any inaccurate lookups.

Using the IP Address geolocation database

The first step is to download the database and import it into your local database; for this example I’ll use MySQL. Note that the site also offers an IP location Lookup API, which has the advantage of not requiring a local database but may be subject to usage limits; if you’ll be getting a lot of traffic you’ll be better off using the local database.

Import the contents into MySQL

I downloaded the Complete (City) database as one table in SQL format. Extracting the file from the archive, you’ll see that it’s well over 300 MB in size. If you’re fond of using phpMyAdmin, you unfortunately won’t be able to import such a large file using that tool, so we’ll have to rely on the command line to import the contents. Go to your mysql/bin folder and enter the following command, assuming you extracted the SQL file to the same location:

mysql -u root -p [name of database] < ipinfodb_one_table_full.sql

Running this command will take some time, as it won’t be fast having to import such a huge table. Take a break and come back in a few minutes. (You may want to create a new database to hold just this table, do that before running this command) After that’s done, you should be able to see the contents in phpMyAdmin, like below:

Using the database

Querying the database is straightforward, and the IP Info DB website has plenty of examples at the bottom of the download page. Basically, once you have the user’s IP, you can use a query like this to find the most likely city it originated from:

SELECT *
FROM `ip_group_city`
WHERE `ip_start` <= INET_ATON([ip address as a string])
ORDER BY ip_start DESC
LIMIT 1;

The INET_ATON function converts a string that is the dotted-quad octet form of an IP address (the form you’re most used to seeing) into a 32-bit unsigned integer. This integer is then used to locate the record that most likely corresponds to the geographical location. The database is structured such that row with the highest ip_start value not greater than the given IP address is deemed to be the most likely location.

An example:

SELECT * FROM `ip_group_city` WHERE `ip_start` <= INET_ATON('69.156.150.155') ORDER BY ip_start DESC limit 1;

(This returns the city of Toronto, Ontario, Canada) If you want to get a list of likely locations, just increase the LIMIT argument to something like 10, and this will return 10 locations that are likely close to where the IP address is located. Note that there may be duplicates in this list.

A simple example

Here’s a simple PHP script that takes the user’s IP address and displays their most likely location on a map using the Google Static Maps API.

<?php
$ipGeolocationDatabaseName = 'ip_geolocation';

$link = mysql_connect('localhost', 'root', '');
$ipAddress = mysql_real_escape_string($_SERVER['REMOTE_ADDR']);

echo $ipAddress;

mysql_select_db($ipGeolocationDatabaseName, $link);

$query = "SELECT * FROM `ip_group_city` " .
         "WHERE `ip_start` <= INET_ATON( '$ipAddress' ) " .
         "ORDER BY ip_start DESC " .
         "LIMIT 1";
$resultLocation = mysql_query($query);

$numRows = mysql_num_rows($resultLocation);

if (0 == $numRows)
{
  echo "No likely locations found.";
}

while ($row = mysql_fetch_array($resultLocation))
{
  echo "<pre>";
  print_r($row);
  echo "</pre>";

  $lat = urlencode($row['latitude']);
  $lng = urlencode($row['longitude']);
  if (!empty($lat) && !empty($lng))
  {
    // NOTE: Replace the `key` parameter with your own, obtained from:
    // http://code.google.com/apis/maps/signup.html
    // (The one in use is only good for URLs on `localhost`)
    $queryString = "center=$lat,$lng";
    $queryString .= "&zoom=10";
    $queryString .= "&size=300x300";
    $queryString .= "&markers=$lat,$lng,blue";
    $queryString .= "&key=ABQIAAAAicCf6MqoHlR-MsfivtVWPRT2yXp_ZAY8_ufC3CFXhHIE1NvwkxTNmqRdvnM9orG9QdyALHoUZfmFuQ";
    $queryString .= "&sensor=false";

    echo '<img src="http://maps.google.com/staticmap?' . htmlentities($queryString) . '" alt="location" />';
  }
}
?>

Here’s what it display for my IP address:

As you can see, it’s not always accurate, but it’s a good start to enhancing your website to offer localized services and features.