Online Equation Builder

Hey, this is just a quick one to point out this cool on-line tool to build equations:

Roger's Online Equation Editor

You simply enter you LaTeX into the form, submit and save the image it generates. If like me, any clue you had on LaTeX markup is long-gone, there is a nice concise guide to the Mathsy stuff.

Nice one Roger.

Cheers

Darren on Ruby: Migrating Rails to Tomcat / JEE, Part 3: Using Warbler (Rack) to Deploy to Tomcat, Jetty or GlassFish

The Series So Far

Part 1: Switching to JRuby & Apache Derby showed you how to migrate from the Ruby+SQLite3 technology stack to JRuby+Derby.
Part 2: Migrating Your Data From SQLite3 to Derby showed you how to export your data out of your SQLite3 database and import that data into your new Apache Derby database.

Now I will take you through using Warbler to package your Rails app into a Web ARchive, ready for running on Tomcat, Jetty, Glassfish or whatever Servlet container you like.

Packaging Rails as a WAR

1. Install Warbler:
   • jgem install warbler -y
2. Configure Production Database:
   • Replace the production spec in RAILS_ROOT\config\database.yml with

     production:
       adapter: jdbc
       url: jdbc:derby:db\blog_ production;create=true
       driver: org.apache.derby.jdbc.EmbeddedDriver
       username: app
       password: app
     

3. Satisfy Ruby Dependencies:
   • We need to make sure that all the Rails app's Ruby runtime dependencies are taken care of. We only need to worry about the dependencies that are required explicitly i.e. not provided transitively by Rails or Warbler. In our case it boils down to the JDBC/Derby stuff.
   • To specify the inclusion of these deps, we need to generate and modify the Warbler configuration; first run warble config, then edit the RAILS_ROOT\config\warble.rb file, replacing (or inserting after) this line

       # config.gems += ["activerecord-jdbcmysql-adapter", "jruby-openssl"]
     

     ...with this line

       config.gems += ["activerecord-jdbc-adapter", "activerecord-jdbcderby-adapter", "jdbc-derby", "jruby-openssl"]
     

4. Satisfy Java Dependencies:
   • We need to make sure that all the Rails app's Java runtime dependencies are taken care of, that is, we must ensure the Derby jars will wind-up on the deployed applications CLASSPATH. Here are 3 ways to achieve this, in increasing scope:
     1. Copy derby.jar, derbyclient.jar and derbynet.jar in DERBY_HOME\lib to RAILS_ROOT\lib
     2. For Tomcat, copy these jars into TOMCAT_HOME\lib
     3. Copy them to JAVA_HOME\jre\lib\ext
     Taking the first option, Warbler will by default put these jars into WEB-INF\lib of the built WAR file.
5. Rails 2.3.2 Session Management Issue:
   • We need to make few extra configuration changes due to an incompatibility with Warbler.
   • Uncomment the following line in RAILS_ROOT\config\initializers\session_store.rb

     # ActionController::Base.session_store = :active_record_store
     

   • Run the following commands to bring the database upto spec:

     jrake db:sessions:create RAILS_ENV=production
     jrake db:migrate RAILS_ENV=production
     

   • Now add the following line of code to the RAILS_ROOT\config\warble.rb file:

       config.webxml.jruby.session_store = 'db'
     

   • In RAILS_ROOT\config\environment.rb, just before

     Rails::Initializer.run do |config|
     

     ... add the following

     if defined?(JRUBY_VERSION)
       # hack to fix jruby-rack's incompatibility with rails edge
       module ActionController
         module Session
           class JavaServletStore
             def initialize(app, options={}); end
             def call(env); end
           end
         end
       end
     end
     

Now we should be good to go. Run warble which should produce blog.war. Now take this and drop it into TOMCAT_HOME\webapps. Restart Tomcat if it does not auto-deploy the application then navigate to your blog. This concludes this 3 part series on migrating from Ruby on Rails+SQLite3+WEBrick to JRuby on Rails+Derby+Tomcat. I hope through this blog I can spare you the pain I have gone through in figuring out how to get all this to work.

Epilogue

Next step for me is to get this procedure (of constructing the WAR file) mavenized. Maven handles WAR artifacts seemlessly; furthermore it knows how to 'overlay' WAR archives, reducing multiple WARs to one. This obviously simplifies the deployment and maintenance effort, a benefit I hope to reap in my current project that (now) produces three WAR achives. Good luck in your next steps. Cheers

Darren on Ruby: Migrating Rails to Tomcat / JEE, Part 2: Migrating Your Data From SQLite3 to Derby

The Series So Far

Part 1: Switching to JRuby & Apache Derby showed you how to migrate from the Ruby+SQLite3 technology stack to JRuby+Derby.

Now we will take a look at migrating the important stuff: your data. I found two ways to do a data migration: the easy way and the hard way. And unfortunately for me, I found the hard way first.

Update, 01/05/2009: You Don't Really Need to Migrate to Derby

You can continue to use SQLite3 if it so pleases you. You just need to install the necessary gems i.e. jdbc-adapter:

jgem install activerecord-jdbcsqlite3-adapter -y

The other thing is that it seems that SQLite3 allows you to use names for entities that are keywords in Derby e.g. min or max. Check here for a list of keywords used by Derby.

Do It The Easy Way, Do It The Ruby Way

To facilitate the easy way, we need to install the AR_Fixtures Rails plugin (not quite sure why this isn't a Gem, thus making it available to all Rails apps).

ruby script\plugin install http://topfunky.net/svn/plugins/ar_fixtures

This plugin gives us the db:fixtures:dump Rake task. As you'll see next it understands the MODEL and RAILS_ENV commandline/environment variables. It can't dump the entire database, strangely enough.

For this first step you need to go back to RAILS_ROOT\config\database.yml, disable (prepend an underscore) the jdbc development spec and re-enable the sqlite3 development spec. Then run the following commands:

rake db:fixtures:dump MODEL=Post
rake db:fixtures:dump MODEL=Comment
rake db:fixtures:dump MODEL=Tag

Take a look in RAILS_ROOT\test\fixtures; you should see posts.yml, comments.yml and tags.yml.

Now change you RAILS_ROOT\config\database.yml file to point to the jdbc development spec again, then run:

jrake db:migrate
jrake db:fixtures:load

You should now be good to go - start up your app using JRuby and test the blog data was migrated by going here.

Do It The Hard Way, Do It The Way I Did It When I Didn't Know The Easy Way

...Also The Way To Do It If Your Data Isn't Entirely Managed By ActiveRecord

1. Export SQLite3 Data:
   • Run sqlite3 development.sqlite3 .dump >> development_dump.sql in RAILS_ROOT\db
2. Tidy-up SQL Dump:
   • Open development_dump.sql in a text editor and make the following changes:
   • Remove any DDL or DML commands to do with the sqlite_sequence table
   • Remove any DDL or DML commands to do with the schema_migrations table, including the index
   • Unquote all table names e.g. change CREATE TABLE "posts" ... to CREATE TABLE posts ...
   • Replace AUTOINCREMENT NOT NULL with NOT NULL GENERATED BY DEFAULT AS IDENTITY
   • Replace datetime with timestamp
   • Replace integer\([0-9]*\) with integer
   • Replace text with long varchar
   • Replace DEFAULT ([0-9]*|NULL) NULL with DEFAULT NULL
   • Also be sure that any varchar(255) table columns only have that many characters, or else the import will complain and truncate your data (in this case, your precious blogs).
     If varchar(255) is not big enough, just switch it to long varchar
3. Import into Derby:
   • Run ij (the Derby command-line client) in RAILS_ROOT\db
   • Run the following commands in ij:

     connect 'jdbc:derby:blog_development;create=true' as dev;
     run 'development_dump.sql';
     exit;
     

That should be it; you should have seen each model-table being created followed by the corresponding blog data going into Derby. You might see some 'Table already exists' errors when the DDL statements execute; these will occur if you previously ran jrake db:migrate, which creates the tables for you - just ignore them. Run the server again using JRuby and you should be able to access your blogs again.

What's Next?

Next I will step through the procedure to package your Rails application to a Web ARchive file, ready to deploy to Tomcat, Jetty or any JEE/Servlet container of your choice. You can catch that blog here

Cheers

Syntax Highlighting 2.0 on Blogger

I previously blogged about adding code and displaying it nicely in your blog posts.

Back on February 3, 2009 Syntax Highlighting 2.0 was released. It is much nicer than the previous versions and the clipboard feature now works properly - It's also backward compatible or rather it upgrades the old 1.5 style to the 2.0 style without needing to touch all those old blog posts. Cool, ay?

Inspired by FaziBear, I am providing here a widget that can be used to add SH2.0 to your Blogger so you don't need to worry about the details or go through the trouble I did.

Note: If you have the old version installed via a widget or directly in your template, remove it; it's simply nolonger needed.

There is one caveat: Because everything is inlined, you won't get any updates to the remote JS and CSS code. On the otherhand, your blogs will be stable and won't be susceptible to any errors in those updates. Enjoy!

Darren on Ruby: Migrating Rails to Tomcat / JEE, Part 1: Switching to JRuby & Apache Derby

Prologue

Complete this tutorial as a prelude to this blog. This is less about you learning RoR, but more about giving you a convenient starting point to proceed. If you already have a project in mind that you want to migrate, make a copy and work with that. Note for Windows users: When you get to the point of installing the SQLite3 gem, use version 1.2.3 as at the time of this writing, it is the most recent version compatible with Windows; gem install sqlite3-ruby -v 1.2.3 -y. For your convenience, here are some links you might find useful while completing that tutorial: http://localhost:3000
http://localhost:3000/home/index

Run it on Ruby

So you should now be at a point where you can successfully run your application on Mongrel or WEBrick using MRI. If you haven't done that already, give that a whirl and test it by going here. You should see the 'Hello, Rails!' home page. Now get you hands on the default generated index.html file and put it back in the public folder and hit refresh/F5. You should now see the 'Welcome aboard... You’re riding Ruby on Rails!' welcome page. Click on the 'About your application’s environment' link and you should see a flash message (I think that's what they call it) describing you environment; you should observe two things:

Ruby Version

1.8.6 (i386-mswin32)

Database adapter

sqlite3

Now shut down the web server.

Prepare for JRuby

1. Setup JRuby
   • Download and install JRuby 1.2.0 from here
   • Set your JRUBY_HOME environment variable and add JRUBY_HOME\bin to your PATH environment variable.
   • Checkout this blog for jgem and jrake
2. Install Rails (currently 2.3.2)
   • jgem install rails -y
3. Setup Apache Derby
   • Download and install Derby 10.4.2 from here.
   • Set your DERBY_HOME environment variable and add DERBY_HOME\bin to your PATH environment variable.
   • Copy derby.jar, derbyclient.jar and derbynet.jar in DERBY_HOME\lib to JRUBY_HOME\lib.
   • jgem install activerecord-jdbcderby-adapter-0.9.0 -y (I had an issue with version 0.9.1; something about an uninitialized constant...)
4. Prepare Development DB
   • Update the RAILS_ROOT\config\database.yml file; comment out the default development database definition (or just prepend an underscore or something) and paste in the following below it:

     development:
       adapter: jdbc
       url: jdbc:derby:db\blog_development;create=true
       driver: org.apache.derby.jdbc.EmbeddedDriver
       username: app
       password: app
     

   • Run the following commands:

     jrake db:sessions:create
     jrake db:migrate
     

Run it on JRuby

Now you should be at a point where you can run your application on Mongrel or WEBrick using JRuby. Start it up, this time running jruby script\server and test it again by going here. Click on the 'About your application’s environment' link; this time you'll observe two significant differences:

Ruby Version

1.8.6 (java)

Database adapter

jdbc

Well that's all folks - You have now migrated to JRuby!. But where are all your blogs?!

What's Next?

Next I will run through a couple of ways of migrating your SQLite3 data to Derby; when it's ready you can catch that blog here. Cheers.

Darren on Ruby: JGem, JRake... For Your Convenience

I have recently been investigating migrating RoR apps to JRoR, furthermore to Tomcat/JEE. This naturally means that I have both Ruby and JRuby installed at the same time, both on my PATH variable, meaning one takes precedence over the other; in my case Ruby comes first. Consequentially, I found myself typing in jruby -S gem ... or jruby -S rake ... a lot of the time and it started to annoy me. I took a look into the JRUBY_HOME\bin folder and discovered there is the jirb.bat script, obviously the JRuby equivalent to IRB. The inards are:

@ECHO OFF
IF NOT "%~f0" == "~f0" GOTO :WinNT
@"jruby.bat" -S "jirb" %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO :EOF
:WinNT
@"jruby.bat" "%~dpn0" %*

Pretty simple, ay? So what happens when you change the jirb to gem or rake? Exactly what you expect, lol. Go ahead and do it, save the files as jgem.bat and jrake.bat, respectively. You are now good to go. This should work for any executable-type script residing in your JRUBY_HOME\bin e.g. jwarble.bat. I'm not sure why the JRuby team did/do not distribute these scripts as standard, especially for gem and rake, as they are as common as irb. Anyway, enjoy.