Crazy Or Genius?: Category Programming

Google App Engine

Sean — Tue, 08 Apr 2008 23:56:00 +0200

Today Google announced Google App Engine, a free (within certain limits) deployment environment in which people can develop, deploy and host web apps. Currently, the offering is for python only, and you are kind of tied to Google’s data store, but in return you don’t have to worry about server management, infrastructure, or paying money. Additionally, they have a pre-packaged SDK to give developers an identical development sandbox, as well as a method to deploy local code to the production environment.

However, I think they missed a way to make it even MORE awesome. Imagine, if you will, that they had integrated this package with Google Code. Suddenly, developers have an entire managed development and deploy framework. Develop on your workstation with an environment that is identical to the production environment, check in code so that it is managed, have a web interface that manages deployment from the repository so that you could deploy specific revisions/branches to either a staging area for testing or the production environment, with easy rollbacks if a problem is noticed…... since one of App Engine’s goals appears to be to lower the total cost of entry into the app development world, this just seems like it would make sense and work so well.

FreeBSD, Ruby And The Case Of The Failing Gems

Sean — Tue, 06 Mar 2007 14:34:00 +0100

The server I happen to host some of my stuff (ie. this site) happens to be running FreeBSD. In most cases, this doesn’t cause any problems. However, in the case of installing certain ruby gems, I would get an error when compiling native extensions. In particular, with the fastthread gem (I was trying to upgrade Mongrel), I received the output:


make install
/usr/bin/install -c -o root -g wheel -m 0755 fastthread.so /home/ssmith/gems/gems/fastthread-0.6.4.1/lib
install: /home/ssmith/gems/gems/fastthread-0.6.4.1/lib/fastthread.so: chown/chgrp: Operation not permitted

I received a similar error a while back when trying to install mongrel, and at the time I had asked one of the friendly admins to just install it as root. However, I like installing my gems locally, so they are easy to update, and this was preventing that. Additionally, I wasn’t experiencing this on another machine running Debian, so what was going on?

Some investigation showed that on Debian, install wasn’t being told to change the owner and group, while for some reason it was on the FreeBSD machine. So where was this being set?

Turns out that rbconfig.rb, a part of the actual Ruby distribution, was the culprit. A collection of configuration variables for Ruby, it had the following line:


  CONFIG["INSTALL"] = '/usr/bin/install -c -o root -g wheel'

while on Debian we only had:


  CONFIG["INSTALL"] = '/usr/bin/install -c'

Apparently, the FreeBSD Ruby port sets things a little bit differently, which causes pain for local installation of gems. I’ve currently had the problem fixed by having that line set to the same values as Debian. However, as that file is automatically generated each time Ruby is updated, hopefully the root issue will be fixed in the next version for FreeBSD.

Formats, Microformats, and Exporting, Oh My!

Sean — Sun, 01 Oct 2006 19:27:00 +0200

The other day, I came across this Microformat Bookmarklet, designed to extract hcard and hCalendar markup from a website and into a format that people can use. ‘Hey’, I though, ‘that’s pretty cool, why don’t I use those in places’.

It was the motivator that finally got me to fix a long open feature request for TigerEvents. Now, the event view has hCalendar markup for those who care.

Once that was done, I thought, since I had already done hCal, why not figure out iCal export? Easier than I would have thought, thanks to the iCalendar gem and the send_data method. Now people can grab iCalender export by individual event, group, or category. People should even be able to subscribe to iCal files and have events automatically shown in their calendar app (if said app has this feature). Only future events are shown, however, in order to cut down on file size.

Finally, while I was working on the above, a friend stopped by, saw what I was doing and commented, ‘you know… it would be awesome if I could click on a link and have the event loaded into my google calendar’. So, quickly scouring the web came up with Google Calendar event publishing guide and after a few minutes, I managed to add that functionality as well.

Now for RSS feeds…

Sneaking Ruby Into The System

Sean — Tue, 05 Sep 2006 15:47:00 +0200

Many of you may know of my love for the Ruby language. Used for most of my own projects and quick scripts, but have never been able to use it in any of my paid work. Until now.

It started a few weeks ago with a script I wanted to write. As I am the ‘translator guy’ at work, from time to time I need to convert the XML files that store the English text to something that a non-technical translator can easily read (I thought the XML was readable, but apparently I need to hand over Excel spreadsheets). As Ruby has nice XML library included, I just quickly whipped something up, and away I went. Never intending this to be anything more than a tool for myself and knowing my boss wouldn’t care as long as it got done without me having to spend a few hours, it seemed like the thing to do at the time.

Fast forward another two weeks. I overheard a few of my coworkers talking about how they can’t manipulate XML files in Auto-it, which they were using to cover some deficiencies in another build tool we were using called FinalBuilder. They started talking about either writing their own XML parser, or using yet another tool/language to do what they wanted.

A few of my coworks obviously didn’t like either idea. I mean, sure it was a solution, but it wasn’t an ideal solution. None of us liked the thought of debugging build/test/release scripts cobbled together from 3 different programs/languages. Some of us thought that if we were going to take the time to do something like write our own XML parser, we might as well spend the time to do something even smarter, like rewrite all our scripts in a single language. This would have several advantages, including things being uniform (1 language vs 3 helps there) and making it easy to track changes in svn (FinalBuilder has binary files, which caused problems when multiple people made enhancements).

So a number of suggestions were made, including batch files (ugh) and php. I obviously suggested Ruby, pointing out its portability (as opposed to Windows only solutions), readability, and the existence of desired functionality (eg. XML Parsing). The individual who was going to write the scripts had never used Ruby before, and so wanted to know more before making a decision. Coincidentally, I had a copy of Enterprise Integration With Ruby sitting on my desk,and was able to toss it over so he could take a look at the syntax (bonus points for its section on XML parsing). I also pointed out the ruby-doc site and pointed out rake.

Now, we have all of our build scripts written in rake format, and I reworked my translation scripts slightly to be rake tasks as well. At the moment we are working out some kinks in another series of scripts a coworker has written for creating packages for our clients, and we won’t have to waste time making small tweaks to packages manually.

Railsday 2006

Sean — Fri, 16 Jun 2006 15:43:00 +0200

So yesterday was RailsDay2006. The objective: Write an entire web app of your choosing (with some restrictions) in a span of 24 hours.

Oliver and I decided to participate together. I came up with a bunch of ideas, but we ended up doing something Oliver had in mind. The goal: a deli.cio.us clone that we called Tasti.er. We wanted a simple interface, where everything happens on one screen. We put it together in under 18 hours (with the final commit happening just as the competition closed).

Check out our performance log or Oliver’s RailsDay Post.

Let's Get Ready To Roombaaaaaaaa!!!!!

Sean — Tue, 28 Feb 2006 01:06:56 +0100

So, lately I have been spending some late nights on campus. I mean LATE nights, 1….. 2….. almost 3 in the morning. Have I been spending late nights working on my schoolwork? Ok, you can stop laughing now. No, instead I have been doing some hardware/software hacking with a Roomba. My friend Oliver and I have been busy putting the Roomba together and doing cool stuff with it. Ok, ok, Oliver did most of the hardware work, I just provided ideas and suggestions along the way. End result: A Roomba being controlled using a USB Gamepad over the wireless network in the Computer Science building. Over the break, several individuals from tech support came to take a look at it cause it sounded cool, and we even showed it off to the high school students that showed up at the Open House last Saturday (they also thought it was cool. Right now, we have the movement controlled via one of the analog sticks, though we have a lot of cool ideas (which I am sure I will write about as they are accomplished).

More information (as well as pictures) can be found at Oliver’s site here

Additionally, Make Magazine has already featured it in their Make Blog. How cool is that?

Writing Database Code In Rails: Migrations and Neutrility

Sean — Wed, 23 Nov 2005 18:12:00 +0100

As I recently said, I switched TigerEvents over from using a MySQL input file to migrations. There were many decisions behind this choice.

I wanted the code to be database neutral. Using migrations would allow me to automatically support MySQL, PostgreSQL, and SQLite by making changes to one file instead of 3.
I know that the database for TigerEvents is going to change at some point in the near future. Rather than write multiple upgrade scripts manually, I could just use the built in migration functions to do it better.
If for some reason I make a mistake and problems occur on the production site, it is easier to roll back to a previous version using migrations than dump the database, roll back the code, reload the database, etc. (Note, we still make sure to back up the database, cause not doing that is just tempting fate)
Migrations will, in theory, make development easier. Someone made a change to the schema? Just run rake migrate, and your database is automatically updated. I think this is easier than reinitializing a database and then loading it with data repeatedly (though the second part of this can be handled with Fixtures).

While an awesome introduction to getting started with Migrations has already been written, I feel that the ‘database neutral’ stuff is missing. Using my own experience, several items must be taken into account, mostly due to MySQL usage and certain programming that were being used.

Already Existant Database

So we already had a database. A somewhat large database with a number of tables. I didn’t want to spend a lot of time manually creating the migration code from scratch. Was there a quicker way? You betcha. There was a rake task called db_schema_dump which will dump all the table data from your database to a file called schema.rb. So, once we do that, all we have to do is copy this information to the self.up section of a migration and we are done, right? Unfortunatly, it is NOT that easy. The problem is (in my case) that MySQL data types do not necessarily behave the same. Mostly, this deals with constraints, but also has to do with the boolean data type itself.

Constraints

In MySQL, you can do int(8). In rails, this would be translated into something like :integer, :limit => 8. However, PostgreSQL only has smallint, integer, and bigint, not constraint values. Therefore, the previous rails code returns an error, as PostgreSQL chokes on the SQL command that rails sends it. Therefore, while it is true that you don’t need to know specific SQL syntax, you DO need to know what kind of data you can feed various databases. For TigerEvents, I just generalized items and made the following changes: :integer, :limit => 8 became :integer :integer, :limit => 1 which translated to tinyint(1) in MySQL became :boolean :timestamp became :datetime (which gave me extra functionality). Now, I by no means know if these are the optimal solutions, but they did work.

Boolean Data

We have a few boolean flags in our database. However, MySQL does not have a boolean data type. Instead, tinyint(1) is generally used. Well, generally that is ok, as ActiveRecord will automatically use tinyint(1) when connecting to MySQL and boolean when connecting to PostgreSQL and SQLite. However, since we started out with MySQL, there were numerous statements such as

@newgroups = Group.find(:all, :conditions => ["approved = 0"])

where 0 is supposed to indicate false. However, since this does not translate to false with PostgreSQL and SQLite, we have a problem. Solution: use placeholders. You are acually allowed to do this:

@newgroups = Group.find(:all, :conditions => ["approved = ?", false])

ActiveRecord takes the value and automatically translates the value into the proper data type, depending on the database type.

So once again, while you don’t need to know specific SQL query usage, it is important to keep data types general, and passed values abstracted if you want to create database code which is database neutral (at least for MySQL, PostgreSQL, and SQLite).

World Usability Day!

Sean — Thu, 03 Nov 2005 19:44:00 +0100

Today is World Usability Day. A day to work towards better user experiences in products and experiences. I also decided to use this day as a deadline for the next release of TigerEvents, one of the software packages I work on. 39 closed issues later…............... a brand new release. All that remains is to migrate my.dsu.ca to a new server, upgrade to the new version, and then all users can revel in…..... well….... errr…....... actually, I must admit there isn’t anything major in a regular user’s perspective.

Removing that pesky sidebar proved troublesome (due to Javascripting and CSS issues), and is unfortunatly pushed back (I’m working on it!). You will see that events actually have their formatting preserved, so no more giant block paragraph that is a pain in the ass to read. There are also some more subtle rearrangements and additions to some options, which I think will make posting events easier for people. Admins get a little more, mostly avoiding huge lists of groups and users when trying to navigate (pagination helper is your friend).

And the backend stuff is where most of the changes occured. I personally refactored the code so that the authentication stuff is easier to drop into other code (important since we want to use it in multiple projects. Additionally, I refactored the code to make the entire system database neutral, and to have as much as possible done through ruby. This includes important things such as setup and schema migration. This was the longest and largest changeset I have done in a while, and I am glad it is over. Of course, I need to pass this on to several budding developers so they don’t make the same mistakes, so…....... check back at some point in the future.

What however, is the future of this project? The individuals working on it (and by that I mean myself and Oliver) have decided we want to refocus on putting the ‘my’ into the ‘my.dsu’. Upcoming, expect to see new skins, a better actual interface devoid of those confusing multiple columns, and other things that will help the USER kick ass. So think of this World Usability Day not as a day for which we bring out a ton of usability fixes, but a day where we begin to devote more attention to where it is needed.

You know, after we take a much needed break.

Woo! TigerEvents 0.5.0 Public Release

Sean — Fri, 07 Oct 2005 12:42:00 +0200

Finally, after long hours, little sleep, and lots of work, the 0.5.0 release of TigerEvents, code named “It’s Finally Our So I Can Take A Break” was released the other day on both Sourceforge and Rubyforge.

The focus of this release was getting all the proper administration interface stuff working properly (sorry front end only users) and trying to document it enough so a person can take the code, set it up, and run it on another machine.

Now that the initial file release is out, all I have to do is upgrade my.dsu.ca (merging is going to be a pain in the ass), work on 0.6.0 (which involves merging my development branch back into the trunk, ugh), and redo that ugly, ugly interface.

Regarding the interface, I plan to do something even more minimalistic than some people’s ideas (the one’s I am getting are awesome though, don’t stop). It will, at the very least, grant more open space, as opposed to cramming everything important into a small area. A primary advantage of starting out small is that it will be simple (except for all the XMLHTTPRequest stuff I need to do), and if people want more, I just add more, instead of scalling back and forth.

Oh, and I will do my best to get rid of that blinking text box.

A License To Bitch

Sean — Tue, 04 Oct 2005 21:16:00 +0200

As already mentioned I have been working on a project called TigerEvents, which powers the my.dsu.ca website.

This project, written entirely in Ruby On Rails, took 4 part time students 2 months to code a working, publicably usable beta. Pretty sweet, since some of us had other, paying, supposedly full time jobs on the go as well, and all of us had other responsibilities.

The my.dsu.ca website has gotten 102430 requests since Aug 25. Not bad I suppose, but I think we can do better than that.

The main problems? I know it, you know, it’s the visual layout. Sure it sucks. A layout like this is when a graphical artist that is supposed to do work totally flakes out and techies are left in charge. Also high up on that list is usability. Some things work well, some things…...... not so well (hey, it’s beta). So how do we fix this? Well…..... I am hoping that you, the public, the intended audience, the actual, non-involved USERS could give me a hand here. Let me know what you like, let me know what you don’t like, let me know what YOU would like to see.

Go ahead, chew me out, rip it to shreds, praise it, stomp it, love it, hate it. Just give me something I can use.