Tagged with Alertzy

Manually generating #yeg trash data

Unfortunately Alertzy is running out of the garbage pickup data that was published by the City of Edmonton on their open data catalogue.  I’ve been assured that the data will be up shortly, but our data was set to run out on May 31st and that was starting to get a little too close for my comfort.


I wrote a quick rake task (Alertzy runs on Rails) to generate the data for June 2011 while we wait for the data catalogue to get up and running.  I encourage anyone to borrow the code (and point out any mistakes they find!) if they are in a similar position.  The code can be found here:
namespace :alertzy do
  desc "Populate June 2011 data"
  task :populate_june => :environment do

def generate_june_data
  mondays = [6,13,20,27]
  tuesdays = [7,14,21,28]
  wednesdays = [1,8,15,22,29]
  thursdays = [2,9,16,23,30]
  fridays = [3,10,17,24]

  mondays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  tuesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  wednesdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  thursdays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}
  fridays.map! {|day| DateTime.parse("June #{day}, 2011 7:00:00")}

  mondays.each do |date|
    [{:zone => "D", :day => 5},
     {:zone => "D", :day => 6},
     {:zone => "D", :day => 7}].each do |zone|
       GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
  tuesdays.each do |date|
    [{:zone => "E", :day => 7},
     {:zone => "E", :day => 8}].each do |zone|
       GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
  wednesdays.each do |date|
    [{:zone => "A", :day => 1},
     {:zone => "A", :day => 2}].each do |zone|
       GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
  thursdays.each do |date|
    [{:zone => "B", :day => 2},
     {:zone => "B", :day => 3},
     {:zone => "B", :day => 4}].each do |zone|
       GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
  fridays.each do |date|
    [{:zone => "C", :day => 4},
     {:zone => "C", :day => 5}].each do |zone|
       GarbagePickup.create(:zone => zone[:zone], :day => zone[:day], :pickup_date => date)
Tagged , , , , ,

Apps4Edmonton – Open Data App Competition

If you follow my blog than you’re already aware that I entered an application called Alertzy in the City of Edmonton‘s Apps4Edmonton competition.  Tomorrow Chris Moore (@chrisj_moore), Edmonton’s CIO will be announcing the winners to the competition.  I thought this would be a good time for me to express some of my personal views on the competition, so that it’s clear that my opinions aren’t influenced by any of the outcomes.  I’d also like to take this opportunity to express my gratitude to the City of Edmonton for holding the competition, and for all the developers involved in the competition for showing what a creative and vibrant development community Edmonton has.

What worked!

Lots of submissions

I’m sure I’m not the only one who was both surprised and impressed with the number of applications submitted into the competition.  There are a wide variety of applications, on a wide variety of platforms.  Some of them showed some great creativity, and I’m sure will continue to grow into successful applications.  

Great prizes

This was likely one of the contributing factors to the number of submissions into the competition.  I really applaud the City of Edmonton for their progressive IT policy, and the vision to take a risk and invest $50,000 in prizes into the competition.  It would be nice to believe that the same quality and quantity of applications would have been possible without the monetary incentive, but there’s nothing like a little cash to motivate!

Good use of social media

For those active on twitter there was an almost constant flow of traffic on the #apps4edmonton hash tag both by administrators, developers, users, etc.  It was great to see this temporary community pop-up around this competition.

Where things might be improved

Community Voting System

Having community voting as part of the competition might have seemed like a good idea on paper, but didn’t really seem to pan out in reality.  Due to the limited size of the sample size of votes, it really did devolve into a “popularity contest”.  For Alertzy I can testify that we beat the pavement to recruit anyone and everyone we knew or used to know in Edmonton to vote for us.  I can only assume other competitors went through similar processes.  I would suggest that having a separate mini-competition with a small prize for the “community favorite” to be awarded to the App with the most votes would have removed the “popularity contest” from the main competition.


The current contest used categories consistent with the plans of the City of Edmonton’s new City Vision.  This was a cool idea, but unfortunately we only had access to certain data sets, and consequently it was much more difficult to develop applicable apps for many of the categories.  I think categories aligned along other lines (for example technology such as Web App, iPhone App, Android App, etc) would allow for a more balanced distribution.

Clarity of Rules

The rules for the competition in regards to dates were often somewhat vague, and adhered to.  The community votes are the best example of this issue.  The voting was said to end on FRIDAY, SEPTEMBER 10, 2010″, without clearly specifying when during this day this voting would end.  This time also came and went without any indication of a closing of voting on the site.  There was also no clear indication that the “likes” on the contest website were the “community votes” referred to in the rules. 

Another issue of contention was whether modification of applications during the two weeks of voting and judging was allowed within the rules.  For those who looked closely the following could be found in the FAQ:

 Feel free to change the app through the course of the competition. Just remembered that you will be judged on the app that exits at the close of the competition (11:59:59 a.m. MDT on Friday, August 27, 2010).

However, the ability of the judges to be able to judge an application based on what was there exactly at a given time is questionable.  



  I want to make it cear that I’m not complaining about the competition.  I applaud the City for it’s efforts and for providing this platform for Edmonton developers to create and share.  I hope that my feedback can help improve the competition if the City chooses to offer a similar event again, or that it may help other city’s or organizations in similar competitions.

Best of luck to all entries.  I’ll see everyone at the event tomorrow evening!

Tagged , , , , , , , , ,

Rails Host Review – (the good) SliceHost

As I explained in my earlier post berating HostingRails, I built a project for the City of Edmonton’s Apps4Edmonton contest in Ruby on Rails called Alertzy.  In order to make our project live, we needed to find a host for it.  Our initial host fell incredibly flat, so in our second iteration we made sure to perform more research into our available options.  We were initially looking for what I would call a “Rails Host”, as in a hosting provider who gives you an out of the box solution ready for rails hosting.  Under this criteria we found a few potential options, but then we stumbled upon SliceHost.

SliceHost Review

I’ll summarize my impressions of slicehost here:

Pros: Very fast setup, very good performance, very professional

Cons: Start from a blank image on a VPS

Our intention was not to use a VPS provider who didn’t provide an out of the box rails compatible solution.  The reviews for SliceHost, however, were just too good to ignore.  All the reviews which we were able to find for this hosting provider were positive, so we decided we had to give them a shot.

It is important to understand that SliceHost is not so much a Rails hosting provider, as a generic VPS hosting provider.  They simply provide you with a “slice” which has certain performance metrics and a blank OS install on it, and then it is up to you to configure the server to do what you would like it to do.  This has the advantage of complete freedom (SliceHost would prove as effective a PHP host as they are a Rails host), but comes at the cost of configuration.

With our decision to give SliceHost a try, we proceeded to go through SliceHost’s registration and payment process.  Their cheapest slice starts at $20, but we opted to go for their $25 plan which got us 384 MB of RAM, 15GB of storage, and 225GB of bandwidth.  For some reason we flagged something in their system and had to go through an additional verification step.  This process was completed promptly by SliceHost, and our account was online and operational within 45 minutes of the start of the process.  

With our account in place we now had access to their control panel, where you are able to configure your DNS as well as choose an operating system for your Slice and launch it.  The speed with which a new slice comes online impressed me greatly.  From the time of choosing the operating system and launching it, it takes only ~20 seconds before you are ready to start connect to and start configuring your slice.

Unfortunately the next step of this process involving configuring our Slice to run Rails proved to be very difficult.  This was in no way SliceHost’s fault as this process is exactly the same as configuring Rails to run on any system, but the convenience of having a ready made image to use would be an advantage of using another Rails specific host.  The tutorials that I was able to find for configuring Rails to run on a SliceHost VPS were out of date and didn’t work with the more recent versions of Ruby and Rails.  (I will try and put a tutorial outlining my own experiences online in the near future).  I opted to use Capistrano and Deprec to deploy Rails on the new server, and due to the same shifts in versions this proved to be quite a headache to deploy on the Ubuntu 10.04 server we had opted to run.  It took me approximately 10 hours to resolve all the bugs in the deprec scripts to where the deployment could fully run.

Once I had Capistrano and Deprec functioning I was able to deploy our site to SliceHost.  Finally being able to access our site on a good host with great performance was more than sufficient reward for the past day of struggle deploying Rails!  The difference between HostingRails and SliceHost was truly night and day, and we’ve received very good feedback on the responsiveness of our site. 

In conclusion, I had a hard time deploying Rails, but in no way was this the fault of SliceHost.  In everything that is their responsibility, SliceHost has so far delivered either up to, or more often exceeding my expectations.  I intend to use them as my default host for similar projects going forward.  If you would like to check the responsiveness of our site, go check out www.alertzy.com which is running off our slice.

Tagged , , , , , , , , , , , , ,