Posted
Tue, 06 Mar 2007 14:02:32 GMT
to Posted in Programming
Tags freebsd, gems, ruby
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.
no comments | no trackbacks
Posted
Thu, 25 Jan 2007 01:40:24 GMT
to Posted in Projects
Tags rails, ruby, tigerevents
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.
no comments | no trackbacks
Posted
Sun, 19 Nov 2006 17:29:03 GMT
to Posted in Life, Geek
Tags presentation, rails, ruby
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.
no comments | no trackbacks
Posted
Tue, 24 Oct 2006 02:14:58 GMT
to Posted in Ideas
Tags BDD, rSpec, ruby
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.
Read more...
no comments | no trackbacks
Posted
Sat, 16 Sep 2006 13:49:41 GMT
to Posted in Programming
Tags rake, ruby
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.
Read more...
1 comment | no trackbacks
Posted
Sat, 16 Sep 2006 13:45:27 GMT
to Posted in Programming
Tags railsday, ruby
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.
no comments | no trackbacks
Posted
Wed, 23 Nov 2005 17:12:24 GMT
to Posted in Programming
Tags migrations, rails, ruby
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).
Read more...
11 comments | no trackbacks
Posted
Tue, 08 Nov 2005 00:27:40 GMT
to Posted in Projects
Tags rails, ruby, tigerevents
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.
5 comments | no trackbacks
Posted
Thu, 03 Nov 2005 18:44:40 GMT
to Posted in Programming, Projects
Tags rails, refactoring, ruby, usability
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.
1 comment | no trackbacks
Posted
Fri, 07 Oct 2005 10:42:09 GMT
to Posted in Programming, Projects
Tags rails, ruby, tigerevents
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.
1 comment | no trackbacks
