JRuby MemCache Client Gem

I wrote a post about using the jruby_memcache_client Rails plugin to manage sessions. Since then, Abhi Yerra made a fork of Ikai Lan's repository and turned it into a gem. I promptly merged his changes into my repository and I am now publishing my own version of the gem (with a few minor changes).

The new JRuby MemCache Client Gem is API compatible with the Ruby MemCache Client. You should now be able to install the gem into your application and use it directly.

Installing The Gem

You need to add github as a source for gems before you can install the new gem. Thsi is a simple one time command to run:

gem sources -a http://gems.github.com The next step is to install the gem as usual:

jruby -S gem install fredjean-jruby-memcache-client --remote Using the JRuby MemCache Client Gem One way to use the JRuby MemCache Client is to add the following to your environment.rb:

memcache_options = {
:namespace => 'fortaleza:production_live:'
}
memcached_servers = [ ENV['MEMCACHED_LOCATION'] || '127.0.0.1:11211']

# Constant used by libs
CACHE = MemCache.new memcached_servers, memcache_options

You will then be able to configure Rails to use the :mem_cache_store for both session and cache store.

Colorado Springs Introduction to JRuby Talk

I opened up the Colorado Springs Open Source User Group with a very quick introduction to JRuby. The talk was well received and there was a good back and forth with the audience. Many interesting questions were asked and there were a few follow up discussions. Ben Simo (@QualityFrog) had the following feedback on the presentation:

This is pretty much what any presenter could hope for :)

Here are the slides:

Quick Intro To JRuby

View more presentations from fredjean.

Working on One Thing At A Time With Git-Svn

We've all seen people who have 2 or 3 work in progress items within a single workspace. Even the workspace owner doesn't always know what file belongs where, nor can they really prove that their change will integrate cleanly with the rest of the code. I see this more often with people that have used centralized source code repositories to manage their code. Branching is expensive and checking out a fresh repository sometimes takes more time than actually fixing the bug. It is tempting to cut a corner here and there to be able to do this quick fix and move back to the task at hand. It is a dangerous thing to do though.

I find that I do my best work when I am working on one item at a time, whether we are talking about a feature or a bug. This is one of the reasons why I like git. It's local branching capabilities makes it easy to do just that while still being able to quickly go back to a clean slate when reality intrudes and I have to switch to a different task.

My Workflow

Project Kenai still hosts its repository in a Subversion repository. I quickly started using git-svn to managed my workspace and I base my daily workflow on Lennon's daily git-svn workflow. Here is how I approach a task:

1. I make sure that I am at a clean slate and up-to-date. I checkout my master branch (git checkout master) and bring it up to date with the upstream subversion repository (git svn rebase).
2. I create a branch against the master branch and switch to it (git checkout -b branch-name). I normally name the branch based on the Jira issue that I'm working against. This makes it easy for me to link the work that I'm doing to the related Jira issue. I do not using any of the git svn commands in this branch. I add files to the index and commit frequently as I work as a safety net. It is easier to revert to a previous state that way.
3. I then switch to my svn merge branch once work has completed. I make sure that it is up to date (git svn rebase) and run our automated tests. This lets me know that I am working against a clean branch. I then merge my changes from the work branch (git merge --squash branch-name). This condenses all of the commits I did in the branch into one commit that will be merged into the svn merge branch, resolve any merge issues and run the tests again.
4. I commit the merge into the svn merge branch (git commit) and then push my changes to the Subversion repository (git svn dcommit).
5. I finally go back to the master branch, update it (git svn rebase) and run the tests to make sure that all is working as expected.

It may seem a little involved, but it gives me many points where I have a chance to run tests and verify that the work will integrate cleanly with the rest of the team's work.

When Reality Intrudes

I don't always have the luxury of a linear workflow. there are times where I have to jump to a different work item (critical bug) and work on a fix. The workflow that I use allows me to do this very easily since I can go back to a clean slate at any point in time by:

1. Committing the work in progress
2. Going back to the master branch
3. Updating the master branch
4. Creating a new branch for the new work
5. Complete the new work and commit it to the Subversion repository.
6. Go back to the work in progress branch and resume work

As a result, my workspace always contains the changes associated with one work item. There isn't confusion on what file needs to be committed nor do I run the risk of having multiple patches applied to a single file and having to sort through them manually when it is time to commit.

The good news is that this very same workflow will work just as well if we switch the Project Kenai's repository to git or Mercurial.

MemCache Session Store with JRuby on Rails

The JRuby MemCache Client Plugin has been replaced by the JRuby MemCache Client Gem. Details can be found at JRuby MemCache Client Gem

We realized a few weeks ago that we spent a fair amount of time writing Project Kenai's sessions to our database. We already had decided to start using fragment caching and we were exploring different options on the client side.

Project Kenai's front end is a Ruby on Rails web application that is deployed to Glassfish and running under JRuby. We do have multiple JRuby runtimes per domain. There are issues with running the Ruby MemCache client with a JRuby on Rails application, so we paid some attention to Ikai Lan's jruby-memcache-client library. It is a wrapper around a Java based MemCache client that support connection pooling back to the memcached servers.

I quickly discovered that Ikai had focused on the Rails cache store but hadn't put work on the session store. I forked his project and started adding support for a session store.

Using the jruby_memcache_client plugin

Here are the steps to install the client:

1. Run "script/plugin install git://github.com/fredjean/jruby_memcache_client.git" in the root of your Rails application. This will install my forked copy of the plugin.
2. Configure the MemCache client by following the instructions located at http://wiki.rubyonrails.org/rails/pages/HowtoChangeSessionStore .
3. Finally, change the config.action_controller.session_store to use :j_mem_cache_store instead of :mem_cache_store

Make sure that you have a memcached server running and start your rails application.

Making sure that it is running

You can verify that the sessions are sent to the MemCache store by restaring memcache with a more verbose setting. You should then be able to see sessions being put into and retrieved from the session store.

Cloud Computing in Plain English

From WHAT THE HECK IS CLOUD COMPUTING?

I think it does a great job of introducing the concept of Cloud Computing without going into the technical details that makes it tick.

Advice for Uncertain Times

Here are two things that you can do to help yourself and your career in these uncertain times:

1. Upgrade your skills. Continuing to educate yourself is going to be key in standing out from the herd and adding value to your current or future employer. Now is a great time to learn a new language or get exposure to a new technology. The best part is that it doesn't have to be expensive. There are plenty of resources that are low cost or even free on the Internet or in books that will give you a head start on upgrading your skills.
2. Network. Seek out other people in your industry that share similar interests. Find places where great programmers or designers meet in order to exchange information and tips. Don't wait to need a job to network either. It's never too early to establish relationships with individuals outside of your organization or company.

Users Groups in general give you the ability to do both. You do have a chance to meet other individuals that are willing to take some time to learn about technology and to network with other individuals of like mind. They are usually free and will often bribe you to attend with food (Pizza being a favorite around here) or door prizes. Many groups do go out for drinks afterward, extending the networking opportunity.

The Boulder JUG and the Denver JUG are going to host Scott Davis of ThirstyHead.com who will present on Lizard Brain Web Design and how to implement DSLs using Groovy. Make your way down to either meetings, learn a new thing or two and network with some of the brightest and motivated developers in the Denver area.

Groovy Unit Testing Presentation

I gave a talk on Groovy Unit Testing to the Boulder JUG and the Denver JUG this week. The talk was well received, and I got some helpful comments that I will certainly incorporate into future version of the talk. The talk covered:

• How to use Groovy to author JUnit 4 test cases
• How to use closure and map coercion to mock dependencies
• How to use JMockit to mock classes with final or static methods

I tried something different this time. I used the Codex presentation tool put together by Dave Thomas and Chad Fowler to author the slides. It was a great fit since they are very code heavy. This also allowed me to version the talk and keep a copy of the source up on a github repository. The tool chain generates S5 presentations which can be run in a browser.

The slides themselves are posted on my web site. It certainly doesn't have the same impact as attending the presentation but there's a lot of material available and there are 2 sample NetBeans projects that illustrate the techniques that I presented on.