jkraemer.net - Blog

Get a new bike, powered by Rails

2008-06-25T08:24:00Z

Working with webit! I recently built the dynamic parts of the new website of Fahrrad-XXL, a quite large group of bike dealers here in Germany. Besides the product catalog, which is maintained via a separate Rails app, there’s also lots of static content which is managed with the help of Bricolage, a Perl CMS generating static html pages.

I originally intended to name this post Find a new bike, powered by Ferret, because the full text search is one of the coolest features of the site. But maybe I’m a bit biased here ;-). In fact, I’ll delay the Ferret stuff to a later post and instead tell you about another interesting aspect of this project.

Integration of CMS driven static html with Rails

As long as the static pages are completely static that’s no big deal and we already did that in other projects: just have the CMS generate your Rails layouts to ensure visual consistency across the site, and let it publish it’s files into public/. But what do you do if your static pages aren’t really that static?

At www.fahrrad-xxl.de you have a watch list where you can remember bikes you want to revisit later on. The number of bikes currently on this list is shown on every page, regardless of whether it stems from the CMS or comes out of the Rails application.

So how can you do this? The first solution that comes to mind is of course to embed some ERb rendering the watch list status, and pipe each and every page through Rails. This might have worked but why take on the whole overhead of Rails compared to serving the file directly through the web server just for that tiny little number?

I wanted to do better, and remembered a blog post talking about nginx server side includes I stumbled across a while ago. The SSI feature of nginx is really cool because it allows you to include dynamically generated content retrieved via HTTP somewhere in your page.

So what we did was building an action that just rendered that tiny snippet showing the status of your watch list, and put an SSI include directive pointing to this action on every page:

Before serving such a page to the user, nginx will parse the page for any SSI directives, retrieve the content from the location specified there, and replace each directive with the content:

The good

So what have we gained? It’s still one request to the rails application per page, but it’s one that’s substantially faster because it only needs to output a few bytes of text instead of the whole page.

In fact we started using nginx’ SSI in several other places, too, which yielded another benefit of this approach: with pages containing multiple SSI directives you will experience multiple concurrent requests hitting the Rails app, which is a good thing because by splitting the task of rendering a page into several smaller tasks these may be distributed across multiple CPU cores and/or physical servers.

Having pages composed of multiple small snippets also eases caching: the decision whether a particular piece of content is eligible for caching and when it has to be expired is far easier to make for a small and focused snippet, than for a whole page potentially containing data with different life cycles. For example in our case we could easily page cache the watch list status snippet and expire it once the user modifies his watch list. Or, even better, use memcached to store the rendered snippet and have nginx retrieve it directly from there as shown in the blog post I mentioned above.

The ugly

There are some things you should be aware of when trying this approach out:

No setting of cookies

Your actions rendering stuff included via SSI cannot set cookies because the response you send is received by nginx, and not by the client. And since it wouldn’t make any sense for nginx to try and merge headers from multiple SSI responses into the single response that gets sent back to the client, it silently drops all those headers. So, no cookies, and especially no modification of session data if you use the cookie based session store. Which leads us to the next point:

Don’t use Rails’ stock session stores

At least if you intend to have multiple SSI-directives on a single page and the corresponding actions are session-aware (i.e. you don’t call session :off for them). After processing a request Rails by default writes back the session data to the configured session store, even if you didn’t touch the session at all. That doesn’t hurt much as long as you don’t have concurrent requests for the same session, or none of those requests modifies the session state.

With nginx and SSI you will have concurrent requests for the same session, so now if at least one of these requests changes session data, there’s a good chance it won’t end up stored correctly just because another request finished a bit later, overwriting the updated session data with stale data read from the session store before the change has been saved by the first request. Fun stuff, cost me a day to debug ;-)

To get around this issue we’re using the SmartSessionStore plugin. You can find out more about the issue and the plugin in this fine blog post at texperts.com.

Acts_as_ferret moved to Git

2008-05-17T13:46:00Z

I’ve been using git-svn for a while now with nearly all my svn-based projects, so this was a logical step when Rubyforge started offering git hosting a while ago.

So now you can use

git clone git://rubyforge.org/actsasferret.git

to get your local copy of acts_as_ferret.

I plan to keep the svn repository’s trunk in sync with the master branch, so svn users aren’t left out in the cold.

Saxon government's press releases now powered by JRuby on Rails

2008-04-07T07:39:00Z

Last week, the Medienservice, the platform via which the saxon government publishes its press releases to journalists and to the public, has been relaunched. It now runs on a cluster of JBoss servers that are part of the official saxon e-government platform. While the public web frontend might look like just another Blog-like application to you, I assure you that the stuff that happens in the background is anything but simple - there’s a lot of stuff going on like deferred publishing, publishing press releases only to subscribed journalists, and sending out press releases in four different formats including PDF and XML, to only name a few.

As far as I know this is the first public german JRuby on Rails application - one more reason for me to be proud of being part of the team at webit! that built this baby.

RDig 0.3.5

2008-02-26T21:01:00Z

RDig is a tiny web and file system crawler built on top of the Ferret search engine. It’s one of my less active side projects and from what I can tell doesn’t have a very large user base. However there are some people out there who actually use it, and some of those people even tell me so and suggest new features from time to time :-)

Limit crawling depth

You can now configure a maximum crawling depth to restrict RDig to only index pages up to this level. For example, setting config.crawler.max_depth = 1 will make RDig only index the configured start pages, and pages the start pages directly link to. You get the picture I guess.

This option is especially useful if restricting RDig to a pre-defined number of hosts is not an option for your use case, but you still don’t intend to have it crawl the whole web.

HTTP proxy auth support

If you are behind a proxy and have to use HTTP Basic Authentication with it to get through, you can specify proxy url, user name and password:

cfg.crawler.http_proxy = "http://yourproxy:8080"
cfg.crawler.http_proxy_user = "username"
cfg.crawler.http_proxy_pass = "secret"

Under the hood

I put some work into refactoring parts of RDig in order to make integration with acts_as_ferret easier. I’ll write more about that in another post.

Get it!

RDig is available as a gem via Rubyforge.

Regexps on steroids with Ruby 1.8.x

2008-01-27T10:00:00Z

Ruby 1.9 comes with a new powerful regular expression engine called Oniguruma. It sports better handling of UTF8 encoded content, plus goodies like positive and negative look-behind or named matches. Here’s a good overview about these and some more of the new features of Oniguruma.

There are two ways to get Oniguruma into a pre-1.9 Ruby: You can patch the Ruby source tree with Oniguruma and build your own Ruby, or use the Oniguruma gem, which makes it fairly easy to use the new style regular expressions in any Ruby 1.8.x project. Here’s how:

$ wget http://www.geocities.jp/kosako3/oniguruma/archive/onig-4.7.1.tar.gz
$ tar xzf onig-4.7.1.tar.gz
$ cd onig-4.7.1
$ ./configure --prefix=/usr
$ make
$ sudo make install
$ sudo gem install oniguruma

Note the prefix argument in the call to configure - it should point to the location of your current ruby installation. So if your ruby executable is located in /usr/bin, you’ll have to use /usr here as shown above.

If everything went well so far, try it out in irb:

require 'rubygems'
require 'oniguruma'
reg = Oniguruma::ORegexp.new '(?<before>.*)(a)(?<after>.*)'
match = reg.match( 'terraforming' )
puts match[0]         <= 'terraforming'
puts match[:before]   <= 'terr'
puts match[:after]    <= 'forming'

The downside of not having Oniguruma patched into a self-compiled version of Ruby is that something like

'terraforming' =~ /(?<before>.)(a)(?<after>.)/

won’t work because it will be handled by your Ruby version’s built in regexp rengine.

Encrypted root and swap plus suspend to disk with Gutsy

2008-01-24T22:34:00Z

In order to give my trusted T42 a slight speed up I decided to replace the built-in 5400rpm hdd with something faster. I decided to go with Seagate’s ST910021A which seems to be a great choice from what I can tell so far - it’s noticeably faster and despite it’s 7200 rpm it’s nearly as quiet as the original 80GB disk from Hitachi.

But I digress. Initially I just wanted to copy over all the stuff and be done with it, but then I took the chance to do a fresh install of Ubuntu so I could try out the hard disk encryption setup that has been introduced in the alternate installer of 7.10. Until then I only had an encrypted /home, which was pretty useless since most of the time my notebook isn’t shut down but hibernated, and I never needed to type in my passphrase upon resume…

Installation of Gutsy, including the setup of encrypted partitions for root, swap and home went without problems, however on first boot I only got a blank screen, and no prompt for a passphrase as I expected. Removing the quiet splash options from the kernel boot arguments in Grub solved that one, so I could finally see when to enter the pass phrase.

Not nice, however, that I had to enter it three times now, once for each partition. Maybe I should have guessed this would be the case when the installer also asked me three times, once for each partition…

Seems you can get around this by choosing one of the LVM-based encryption options in the installer, which will set up your partitions inside a single encrypted LVM volume. But I didn’t feel the need for another layer of abstraction between my data and the disk, plus those options all sounded like they would use the whole disk, blowing any existing partitions away. So I decided to fix this on my own.

A bit of googling quickly led me to the EncryptedFilesystemHowto5, which suggests creating a separate encrypted partition where all the keys for the other encrypted partitions will be stored. That way, you only need to type your passphrase once when the keys partition is mounted in order to retrieve the (unencrypted) keys for the other partitions from there. The following steps and the initrd script are roughly based on this howto, however the process is much easier since we’re already starting with a fully encrypted system and only add the additional comfort of that separate keys partition to it.

So here’s, in short, what I did, starting from the encryption setup already created by the alternate installer:

Make backups

I did all this on a fresh install having all my data on the other hard disk lying on the table so there wasn’t much to backup but I thought I’d mention it anyway ;-)

Set up the keys partition

First create a small partition to hold your keys if you didn’t already do so during installation. Let’s say this is /dev/sda6. Then set this up as an encrypted volume and mount it somewhere (you need to be root for all of the following commands):

/sbin/badblocks -c 10240 -s -w -t random -v /dev/sda6
dd if=/dev/urandom of=/dev/sda6
cryptsetup --verify-passphrase --verbose --hash=sha256 --cipher=aes-cbc-essiv:sha256 \
   --key-size=256 luksFormat /dev/sda6
cryptsetup luksOpen /dev/sda6 cryptokeys
mke2fs -j -O dir_index,filetype,sparse_super /dev/mapper/cryptokeys
tune2fs -c 0 -i 0 /dev/mapper/cryptokeys
mkdir /mnt/cryptokeys
mount -t ext3 /dev/mapper/cryptokeys /mnt/cryptokeys

This will check the partition for bad blocks, overwrite it with pseudo-random data, setup a luks volume on it, create a filesystem there and finally mount this at /mnt/cryptokeys.

Now, create the keys for your root, swap and any other partitions you might have. The fine thing about luks is that you can have any number of keys for a given encrypted volume, so this is pretty straight forward (do the first two lines for root, swap and any other encrypted partitions):

dd if=/dev/random of=/mnt/cryptokeys/sda7-key bs=1 count=256
cryptsetup luksAddKey /dev/sda7 /mnt/cryptokeys/sda7-key
chmod 600 /mnt/cryptokeys/*-key

If you should ever happen to lose the keys stored on that partition, you will still be able to access your data with the passphrase you told the alternate installer during installation.

Create a new initial ramdisk

Of course the original initrd image doesn’t know anything about our new keys partition. To change this we create a custom script named /etc/initramfs-tools/scripts/local-top/cryptokeys which will mount the keys partition asking for the passphrase, then unlock all other encrypted partitions and finally close the keys partition again. As a bonus, it also tries to resume from the swap partition after unlocking it.

The script assumes your swap is at /dev/sda8, and root and home are sda7 and sda9. Be sure to edit this to suit your needs.

Before creating the new initrd it’s a good idea to backup the original one in /boot/, just in case we messed something up. You might even want to create a separate boot menu entry using this original initrd in /boot/grub/menu.lst below the END DEBIAN AUTOMAGIC KERNELS LIST line:

title           Ubuntu 7.10, kernel 2.6.22-14-generic (old initrd)
root            (hd0,4)
kernel          /vmlinuz-2.6.22-14-generic root=/dev/mapper/sda7_crypt ro 
initrd          /initrd.img-2.6.22-14-generic.safe

To finally create a new initrd, call:

update-initramfs -u ALL

Try it out

Well, reboot and see if it works :-)

You should get asked once for your passphrase, and then see the other partitions being unlocked automatically. Thanks to the call to /bin/resume in the cryptokeys script resuming from suspend to disk should work, too (which it didn’t with the setup created by the alternate installer).

Please let me know if you spot any bugs or have any other comments/thoughts on this.

Grails project begging for attention

2008-01-14T22:02:00Z

Sorry, but I can’t think of any other reason why Graeme Rocher might write such crap.

Among the points he makes when trying to convince his readers why they should choose Grails over Rails, there are at most two or three which are somewhat reasonable, namely those dealing with integrating your application with external J2EE based services. I completely agree that these are valid points when comparing Grails running inside a fully-fledged J2EE container to Rails running in, say, Mongrel. But since Rails runs fine in a J2EE environment as well, that’s an unfair and misleading comparison.

Using container-managed database connections via JNDI in a JRuby on Rails web app is no problem at all, neither is using Quartz to schedule Rails background jobs, just to name a few examples. I don’t see anything stopping people from using the whole range of J2EE container features in their JRuby/Rails applications once they need to do so.

The whole ‘Grails is more enterprisey than Rails’ argumentation falls apart once you stop comparing apples to oranges, and slap JRuby + Rails onto that damn app server.

Grails 1.0 coming out within the month

Uh cool, yeah. Until now I thought statements like this were more a specialty of closed source vendors trying to convince their potential clients not to check out the competition. Looks like they can’t wait to finally attach that decision maker friendly 1.0 label to Grails ;-)

Anyway, I feel we’re all going to have an interesting time in the future watching how the competition between JRuby/Rails and Groovy/Grails goes on. After all, competition tends to lead to better products in the end.

Job scheduling with JRuby and Rails

2008-01-12T09:21:00Z

As promised earlier, here’s the first of several articles I’m planning to write about running Rails on JRuby. Originially I wanted to start this little series with some kind of ‘getting started with JRuby on Rails’ guide. Since I didn’t find the time (or, say, motivation) to write one for weeks now, I decided to skip right through to some more advanced topics. So for this post, I’m assuming you already got your hello world JRuby on Rails project up and running and deployed to the application server of your choice. If this is not the case, have a look in the Wiki for documentation about getting started. It’s also worth following the various relevant blogs, as well as the jruby and jruby-extras mailing lists.

Ok, this post is titled Job scheduling with JRuby and Rails for a reason, so let’s get started with this now.

While Rails itself nowadays runs quite flawless inside application servers like JBoss or Glassfish, the usual way to handle background job (push it to some external daemon) doesn’t fit a J2EE application server environment particularly well. Besides the fact that I couldn’t think of an easy way to get BackgrounDrb running from my application’s WAR file, it simply doesn’t feel right to have any extra daemons like BackgrounDRb running besides that fat application server.

As it turns out, there are several ways to do better.

The GoldSpike solution

The kind folks from the jruby-extras team provide two servlets, RailsTaskServlet, and RailsPeriodicalTaskServlet as part of the GoldSpike plugin. These servlets can be used to run arbitrary Ruby code inside the context of your Rails application either once or periodically every n seconds. To schedule a job running YourJobClass.do_stuff every minute, you would place the following declaration into your web.xml:

<servlet>
  <servlet-name>periodicalTask</servlet-name>
  <servlet-class>org.jruby.webapp.RailsPeriodicalTaskServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
  <init-param>
    <param-name>interval</param-name>
    <param-value>60</param-value>
    <param-name>script</param-name>
    <param-value>YourJobClass.do_stuff</param-value>
  </init-param>
</servlet>

Oh the joy of XML configuration files ;-)

While this works great, I had to run a job not every some seconds, but once a week on a defined day and time. Besides that, declaring a separate servlet for each single background job seems like overkill. Back from my Java days I knew that the Quartz library provided exactly what I needed - support for cron patterns. So the challenge was to get Quartz run my Ruby script inside the context of my application.

The rails_quartz plugin

Our target platform was JBoss, which already includes the Quartz library. I’m not sure about other app servers, if yours doesn’t have this already, just download quartz and put the jar including any dependencies somewhere in your application so it ends up inside the WEB-INF/lib folder of your WAR file. With Warbler, which is my preferred way to package JRuby on Rails applications, RAILS_ROOT/lib is good place, since it will pick up any jars from there automatically.

How does it work?

The plugin provides a ContextListener, which, when declared in web.xml, looks for any job declarations and tells the Quartz Scheduler about them. Here’s an example web.xml snippet scheduling a job to run every friday at 10 am:

<context-param>
  <param-name>yourJobCommand</param-name>
  <param-value>YourJobClass.do_stuff</param-value>
</context-param>
<context-param>
  <param-name>yourJobCronPattern</param-name>
  <param-value>0 0 10 ? * 6</param-value>
</context-param>

<listener>
  <listener-class>org.jruby.webapp.quartz.QuartzContextListener</listener-class>
</listener>

As you see, I use context parameters to configure the command to run, and the cron pattern to use. You can declare any number of jobs you want, just stick to the naming scheme for the parameters: <jobName>Command and <jobName>CronPattern so the listener can find out which pattern belongs to which job.

You can get the plugin here: https://projects.jkraemer.net/svn/plugins/jruby/quartz_rails/ . As always, any feedback is welcome.

Strange Mongrel 1.1 error (solved)

2008-01-07T13:50:00Z

Right after updating Mongrel, gem_plugin and some other (probably unrelated) gems today, Mongrel didn’t like me any more, refusing to start up any Rail s application. Instead, I got this nice message complaining about a missing init.rb in the activerdf gem:

** Rails loaded.
** Loading any Rails specific GemPlugins
Exiting
/usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:27:in 'gem_original_require': no such file to load -- /usr/lib/ruby/gems/1.8/gems/activerdf-1.6.1/lib/activerdf/init.rb (MissingSourceFile)

It took me a while to find the fix on rubyforge via google, so maybe this helps somebody else having the same problem.

acts_as_ferret 0.4.3

2007-11-18T16:14:00Z

Long time since the last release (not counting the short-lived 0.4.2 …), and I guess most people already use trunk anyway, but for the faint of heart, here’s the new stable version of your favourite Rails fulltext search plugin.

As always, get it via svn from svn://projects.jkraemer.net/acts_as_ferret/tags/stable/acts_as_ferret. More installation information can be found on the acts_as_ferret Trac site.

No big news feature-wise, I already wrote about the more important features when I added them to trunk:

Going through the timeline looking for some cool feature I didn’t already write about I found several smaller things worth mentioning:

Dynamic document specific boosts

This comes in handy if you want to have search results automatically ranked by a criteria which is different for each record, e.g. the popularity of an article in your shop:


class Article
  acts_as_ferret :boost => :popularity
  def popularity
    # return dynamic boost value for this document
  end
end

You may also apply the dynamic boost to a specific field (or even different boosts to different fields), so it only is applied when a hit occurs in the boosted field. This way you can choose at query time if you want to have the boosting applied or not. Just query either the boosted fields, or the normal ones:


class Article
  acts_as_ferret :fields => { 
                             :title               => {}, 
                             :boosted_title => { :boost => :rating } 
                         }
  def rating
    # return rating of this article
  end

  # value for the boosted title field
  def boosted_title
    title
  end
end

New and better start/stop scripts

The DRb server now has a unified start/stop script and it ships with scripts for using the it as a Windows system service. Thanks to Peter Jones and Herryanto Siatono for contributing these.

Also the acts_as_ferret gem now has got an installer that will install the server script and sample config into your Rails project:


$ gem install acts_as_ferret
$ rails test
$ cd test/
$ aaf_install
$ script/ferret_server -e production start

And your DRb server is up and running. Easy, isn’t it?

No more `:remote => true`

Last but not least, aaf now is a bit more clever and goes into remote mode automatically if the DRb server is configured for the current environment. If for whatever reason you don’t want that, use :remote => false.

How I learned to stop worrying and love JRuby on Rails

2007-10-31T10:31:00Z

As I wrote earlier, I got pretty excited about JRuby and especially about the idea of running Rails on top of it at RailsConf Europe. By pure coincidence we had just had started a project at webit! at this time which had to be deployed to the customer’s J2EE infrastructure. I didn’t really follow the JRuby development before, and therefore greatly underestimated its level of maturity. So, looking for a Rails-like way to build this application, I decided to go with the Groovy-based Grails framework.

At first Grails looks and feels much like Rails, however if you look closer and actually try to build a real application with it, the differences start showing up. Don’t get me wrong, when compared to the more traditional J2EE ways to build web applications (my experiences in this field range from plain Servlets to Struts and Spring), Grails is a huge step into into the right direction. Unfortunately for me, coming from Rails, it just didn’t feel right or complete in many places. Partly this is for sure because Grails, despite its name, is not just a Rails clone, but does things in its own way in many places. Without going into much more detail here, things often weren’t working the way I expected, and documentation was often outdated or missing.

Another issue with Grails for me was Hibernate, its persistence layer of choice. I simply can’t get used to the way Hibernate works. In my opinion it abstracts way too much from the database with its own query language and all its object oriented query building glory. Also it seemed to queue up sql statements and execute them at will at some later time, which I found irritating to say the least. I really don’t understand why Hibernate is the persistence framework of choice in so many J2EE projects. On the other hand it fits the ugly picture of the bloated J2EE web application quite well ;-)

To summarize this rant, don’t underestimate the learning curve of Grails, which will be even steeper when you aren’t already used to Hibernate. I think Rails people having to do J2EE development are just not the target audience of Grails. But it might be a good fit for J2EE developers who either already have their Hibernate models in place or at least have the will to invest some serious time in learning Hibernate.

After all, as you might already have guessed, I decided to start from scratch with JRuby and Rails after RailsConf Europe. And it really felt like coming home from a long and exhausting trip. Despite the lost time in the beginning we met our deadline and had a really great time solving problems the Rails way and deploying to JBoss every now and then. Right now I’m in the middle of my second JRuby on Rails project, same customer, same target platform. I plan to write some more articles about our experiences with JRuby, so stay tuned.

Keep an eye on your DRb server with Monit

2007-10-21T15:13:00Z

Many people nowadays seem to use monit to ensure their Rails application is always up and running, and maybe even to get notified in case of any problems like unusual high load or memory usage.

Since acts_as_ferret doesn’t really like it when the DRb server has gone away, it’s a good idea to not only monitor your Mongrels, but also the DRb server itself. So here’s for you a small snippet of monit configuration derived from one I’m using elsewhere:

# monit configuration snippet to watch the Ferret DRb server shipped with
# acts_as_ferret
check process ferret with pidfile /path/to/ferret.pid

    # username is the user the drb server should be running as (It's good practice
    # to run such services as a non-privileged user)
    start program = "/bin/su -c 'cd /path/to/your/app/current/ && RAILS_ENV=production script/ferret_start' username"
    stop program = "/bin/su -c 'cd /path/to/your/app/current/ && RAILS_ENV=production script/ferret_stop' username"

    # cpu usage boundaries
    if cpu > 60% for 2 cycles then alert
    if cpu > 90% for 5 cycles then restart

    # memory usage varies with index size and usage scenarios, so check how
    # much memory your DRb server uses up usually and add some spare to that
    # before enabling this rule:
    # if totalmem > 50.0 MB for 5 cycles then restart

    # adjust port numbers according to your setup:
    if failed port 9010 then alert
    if failed port 9010 for 2 cycles then restart
    group ferret

As you can see it’s pretty straightforward, well, maybe except the start/stop commands which took me a few iterations to get right. I also added this to the acts_as_ferret distribution: monit-example.

The Nag - make the world a better place step by step

2007-10-15T21:00:00Z

Because today is blog action day, I’ll tell you a bit about an interesting project I’ve been helping to create during the last few months.

I think most people actually want to do something about certain issues like climate change or poverty in the world, but they tend to forget about it being busy with other stuff, or they simply don’t know where to start. I for sure am one of this kind…

To help these people, Antiapathy.org created The Nag It’s a platform where you can register to get nagged once a month with a small, accomplishable task to help solve a certain issue. The web site supplies background information and links to sources of further information on many different issues, and users are guided step by step through each task on the web site.

Tasks range from asking the makers of your clothes whether they’re paying their workers fair wages to switching your home’s energy supply to green energy.

The fun part is that the application collects all that data and aggregates it on a map so everybody can see the impact all members have made, and which regions in the UK are the most active. So if you live in the UK and want to do something good, but you need a little reminder every now and then, why not give it a try?

Not living in the UK of course is no excuse for doing nothing - since I live in Germany, my recent switch to Greenpeace Energy unfortunately doesn’t affect The Nag’s total impact, but it’s a good feeling anyway :-)

And they have this neat thingy showing where your energy right now is coming from…

Railsconf Europe Roundup

2007-09-20T19:09:00Z

With more than 3 days full of Rails and fun and meeting cool people from all around the world behind me, here’s what I took home from Railsconf Europe:

Sun and ThoughtWorks are really pushing JRuby

JRuby has been covered in 4 talks by speakers from both Sun and ThoughtWorks, who also were among the diamond sponsors of the conference.

It really looks like JRuby is ready for real life usage in J2EE environments, effectively bringing Rails into the so-called enterprise through the backdoor. Or, as Ola Bini put it,

JRuby is just another Java library.

Pretty impressed I immediately tried this stuff out - and it really works :-) Time to ditch Grails and have some fun with my favourite language instead.

Selenium

Till Vollmer’s presentation of the browser-based testing tool Selenium was quite impressive. I definitely have to try this out.

Webistrano

At Rejectconf which was organized by the Berlin Rails User Group, Jonathan Weiss gave a short introduction to Webistrano, which is a web-based frontend to Capistrano. Great way to get designers and editors without a local Ruby/Capistrano installation involved in the development process.

Report #12

Besides telling us that it’s time to put the party hats and James Dean jackets aside for a while, and instead get some real work done (and of course have fun) with Rails, DHH introduced report #12, which basically is a list of well-tested patches that have been approved by at least 3 other people. This formalization of the peer-review process is a really good thing as it takes some of the work load away from the core team and makes it easier for people to contribute.

Rails developers are happier

We all knew this, but it’s good even Sun’s Craig R. McClanahan noted in his inspiring talk that he never saw that many friendly and happy people at JavaOne, as he saw at Railsconf Europe. He also admitted that going back to Java after having worked with Rails is not that pleasant. Just to remind you - he’s working at the company whose ticker symbol is JAVA…

All in all it was a great event, and even with Dr Nic speaking at the same time my own talk was pretty well attended,

Raise your hand please if you're using Ferret

2007-09-09T14:48:00Z

Working on acts_as_ferret for more than one and a half year now, I’m really interested in why and how people are using it in their applications. Also, a list of Ferret-powered projects will be a good starting point for people who are still looking for a search solution for their Rails app.

So if you’re using Ferret, please drop me a line, comment here, or even add your application to the Powered by Ferret page over at the Ferret project’s Trac. Ideally you would also post some facts like index size, your production environment or even performance numbers. Personally I’d also like to know if you’re using acts_as_ferret, or, if that’s not the case, why you decided to go with pure Ferret.

I’ll also mention some sites that make use of Ferret in my talk at Railsconf Europe next week. So if you’re looking for some publicity, what are you waiting for?