Al Hoang

February 21, 2007

Finally a gem release of ruby-opengl

Filed under: Open Source, geek, linux, osx, programming, ruby — hoanga @ 8:05 pm

Just wanted to let folks know that I’ve finally figured out how to get the build system in place for ruby-opengl to:

  • Gemify itself
  • Build native extensions during Gem installation using mkrf

Which means (I hope) that there should be an easier way to get OpenGL working with Ruby. Currently it should support installing in Linux and OS X. Installation should be as difficult as:

gem install -y ruby-opengl

Deinstallation should be similar.

For win32 users, I’d suggest using the old bindings provided with the all-in-one installer although I’d like to get a gem built for win32 so hopefully it can get included in the all-in-one installer.

References

Messages like Warning: require_gem is obsolete. Use gem instead. driving you nuts?

Filed under: gripe, programming, ruby — hoanga @ 7:55 pm

If you’re seeing tons of those messages like I’ve been and wondering what in the world that is all about. After Googling around I finally found a definitive answer on Jason Young’s Blog what it was all about.

What is it

Since rubygems 0.9.0 the command require_gem has been deprecated in favor of just plain gem. Part of the reasoning for it going the way of the dodo is tied to some
problems with autorequire. I don’t know any of the deep voodoo that powers rubygems but uh.. okay.. sure.

How to fix it

If you’re still getting these warnings you’re recommended to try re-installing all gems you might have installed if you have a 0.9.0 or lower installation. Happy Ruby Hacking.

References

February 20, 2007

Optimized for more memory than yesterday’s big iron servers

Filed under: gripe, stupid, tech — hoanga @ 8:25 pm

Here’s something I never want my Operating System to be asking of me

users should consider 4GB of RAM if they really want optimum Vista performance

February 7, 2007

Migrating instiki from one database type to another

Filed under: fixes, gripe, ruby, tech — hoanga @ 8:24 pm

The Rant

Instiki is one of the premier wikis for Ruby on Rails which is another way of saying the other rails-based solutions don’t look that great so far from what I’ve seen. Here is an except from the instiki website:

1. Download
2. Run “instiki” with Ruby 1.8.4 or greater. (on windows, that’s instiki.cmd)
3. Chuckle… There Is No Step Three™! :) (See note)

Yeah, nice and simple… to install. Here’s some facts that instiki DOESN’T tell you without digging around:

  • It uses sqlite as its database backend to store all wiki information (except images and file uploads).
  • It’s NOT Rails 1.2.x ready
  • It was written BEFORE ActiveRecord and was migrated to ActiveRecord later
  • You can export your data but have no way to import your data easily (more later)
  • The documentation from a USER perspective is pretty sparse
  • Active development seems to be moving at a snail’s crawl

So what does this all mean? Well, if you want to migrate your instiki instance to a different instance you’d like to think you have a couple of options.

  1. Just copy the whole application to the new server, kickstart done (This works)
  2. Dump out the wiki in some export friendly format and re-import it back in

Option #1 works quite well however if you want to switch database backends you’re stuck with option #2. However save yourself hours of time (I didn’t) and DON’T try the following things (unless you’re a rails god. In which case why are you reading this?)

  • Try exporting the wiki in textile format and importing it…. oops import is busted. A stub is there (http://localhost:2500/wiki/import) but it is definitely broken
  • Dump the sqlite database with sqlite utilities then re-import them into target database. This doesn’t work with MySQL as far as I know. I bet it’s broken with Postgresql too
  • Look at the source code
    to find where the issue might be. Don’t worry, even the changelogs say import is busted and there is no other sign of some way to input data easily
  • Write some tool to import textile in. That would require reading the APIs, right? bleh
  • Write some sort of ActiveRecord translator? Well sort of… but it’d be nice if there was a tool available. And if you’re not a rails guru you’re sort of screwed in this case.

Now I’m sure DHH (the creator of instiki) will grumble about something about this not being ‘appropriate’ for its original intentions and blah-blah. Gee that’s nice. Maybe you better put that down in the caveats, before I commit a whole bunch of data into it.

The Fix

Okay, enough ranting about half-baked Open Source Rails apps. Here’s the fix.

1. Add plugin script to instiki app

Most normal rails app will include a file called plugin inside $RAILS_ROOT/script/plugin. Unfortunately, instiki doesn’t include it. Luckily the script is really small since it just calls out to the rails framework to handle most of the hardwork. So try this:

$ echo "
#!/usr/bin/env ruby
require File.dirname(__FILE__) + '/../config/boot'
require 'commands/plugin'
" >> $INSTIKI_HOME/script/plugins
$ chmod +x $INSTIKI_HOME/script/plugin  # Make it executable
2. Install the manage_fixtures plugin

I’m afraid I don’t have time to explain what a Rails Fixture is in this post but just think of it as a portable way of representing data going into a database for rails. It works well but don’t try hundreds of megabytes of data.

I also won’t go much into rails plugins except to say it’s a way of extending a rails application with more functionality (probably for a Rails developer rather than an end user of the application). We’re going to use a really sweet tool called manage_fixtures which allows us to move around data between different databases with ease (assuming the rails app isn’t doing weird SQL crap).

$ cd $INSTIKI_HOME
$ script/plugin discover    # Hit enter a gazillion times
$ script/plugin install manage_fixtures
3. Export the data into fixtures

The following will export all your db entries as fixtures into $INSTIKI_HOME/test/fixtures. You need to set the RAILS_ENV to production because by default it will try to use the development database.

$ cd $INSTIKI_HOME         # You SHOULD be here anyways
$ RAILS_ENV='production' rake  db:fixtures:export_all
4. Change the database connection to desired

Now change the file in $INSTIKI_HOME/config/databases.yml from:

production:
  adapter: sqlite3
  database: db/production.db.sqlite3

to the following (adjust mysql parameters to suit your setup)

production:
  adapter: mysql
  host: localhost
  database: instiki
  username: root
  password:
4. Create database and the appropriate tables

The following commands will create a database named instiki (or whatever you put in databases.yml) and make sure the database schema in the database matches instiki’s schema.

$ echo "create database instiki" | mysql -u root
$ RAILS_ENV='production' rake migrate
5. Finally re-import the data from fixtures

Whew! Finally we can re-import the data into MySQL (or whatever) and continue on using instiki for something.

$  RAILS_ENV='production' rake db:fixtures:import_all

Powered by WordPress

Protected by AkismetBlog with WordPress