Crazy Or Genius?: Tag ruby

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.

TigerEvents 0.7.1 - It's About Time

Sean — Thu, 25 Jan 2007 02:35:00 +0100

So….. I have actually had a release version of Tigerevents for a long time now. 0.7.0 is actually powering my.dsu.ca now, but was never officially released. As I added several features since then, as mentioned a while ago, I decided to just increment the release number, and push it out there.

This decision was prompted by an organization other than the DSU contacting me, saying they wanted to use it, and if I could just add this one little feature enhancement…...

Needless to say, the idea of other people using this pleases me, and hopefully in the near future I can point out to other in production instances.

The code, as always, is available at the Sourceforge, and Rubyforge locations for download.

Finally Giving In

Sean — Sun, 19 Nov 2006 18:03:00 +0100

Over the last few years I have been asked to present something at various local conferences (mostly just CEOS). This has always ended up with me saying, “sorry, I don’t have the time”. Recently, I have come to the realization that I am likely going to always be “busy” with various other things. So I made a decision.

More recently, I have been asked to give a talk at DevEast. Rather than my traditional “sorry I don’t have time”, I decided to give in and accept. I am now going to be giving a talk about Ruby on Rails that will encompass a lot of the basics, as well as sharing some of my own experiences with it over the last year.

Win, lose, or draw, at least in a few days I will be able to say I’ve tried.

Behaviour Driven Development And rSpec

Sean — Tue, 24 Oct 2006 03:52:00 +0200

Last week, Dave Astels came into Halifax and gave a talk on Behaviour Driven Development (BDD) and rSpec (a BDD framework for Ruby). I thought it was quite the interesting talk, and that a lot of things seemed to make sense.

I took some rough notes, and thought I would write a bit about what I managed to take away from the talk.

The premise behind BDD (as I understand it) is that many users are only getting part way up the Test Driven Development ladder and then getting stuck and not being able to leverage the full set of tools and techniques they have at their disposal. Some of this has to do with terminology (ala the Sapir-Whorf hypothesis) and not being able to grasp the concepts as they are presented. For example, TDD has unit tests, but what exactly is a unit? What exactly are tests supposed to test?

TDD emphasizes checking state at various points in execution. BDD, as the name would imply, defines tests in terms of behaviour.

The part of the talk that I enjoyed most was the fact that BDD focuses on human readability. So instead of something like:

def test_truth
  assert_kind_of Group,  @group
end

you get:

specify "is really a group" do
  @group.should_be_an_instance_of Group
end

Note: the above examples are identical in functionality (in fact, Dave pointed out that they made a point to provide all the same functionality as the Ruby TDD framework, so people that preferred BDD would have a clear migration path) but differ in how they are presented.

If you are interested in a more in depth description, you can check out an earlier version of the talk on Google Video video.google.com/videoplay?docid=8135690990081075324 or check out Dave’s site

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.

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).

TigerEvents Breaks 50! (Downloads That Is)

Sean — Tue, 08 Nov 2005 01:27:00 +0100

One month after the first official release of TigerEvents and we have achieved the following:

31 downloads on Sourceforge
20 downloads on RubyForge
17 downloads directly from TigerOnRails
Currently Ranked 3,682/105,551 projects on Sourceforge (Top 5%!)
Currently Ranked 83/999 Projects on RubyForge (Top 10%!)
One individual (from the Netherlands) actually testing out trunk and submitting tickets

Wow, this totally, totally exceeds expectations.

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.