Sharing is Caring – Sharing filters between applications

We’ve been creating a set of Rack applications that we are tying together using Padrino.

Each application represents an API endpoint for a set of related services on a distinct resource, e.g. /customers or /invoices etc.

This is nice. But we still need to share some common API-level functions, such as request timing etc. between the all applications. This means for every API call in every application we want to log the time the request started at, store the time in the request and then log the elapsed time when the request ended. So:

  • Before filter: Log time, store in request as @start_time
  • After filter: Read @start_time from request and log the elapsed time between it and now

Now that we had this, how could we apply this to all applications? In other words, how do you avoid plastering these before and after filters into every application?

Well we were already creating all applications as a sub-class of BaseApp – mostly in order to share settings. This was working great, we could set lots of configuration up in the BaseApp class and the CustomerApp class would just inherit it, and override it if required. But you can’t use it to share the filters, because filters are not inherited.

I posted this to the Padrino Google Groups mailing list, and one of the Padrino maintainers, Davide D’Agostino, kindly helped me out via this StackOverflow post.

It worked great. The Ruby community to the rescue again!

Advertisements
Posted in Uncategorized | Tagged , | Leave a comment

Choosing Padrino

We’re writing a RESTful API for our platform – like just about everyone else.

We needed a thin framework layer between the web and our service classes. We craved some organisation. We wanted to learn from the Ruby community how to do this best.

We went to Rails first, but we felt there was too much there we just wouldn’t use – yet.

So we went to Sinatra and we found that was much better, but we had to do almost everything from scratch, from mounting sub-apps to deciding where things (apps/models/views) should live. We needed at least some convention, and not so much configuration.

So we’ve settled on Padrino.

It occupies that happy middle ground in the Ruby framework ecosystem. The space between the 300 pound gorilla and the Zen Buddhist monk; enough to get your started, but not get in your way, and it exposes some lovely Rack middleware elegance.

A good start so far, but you’ll hear about any bumps on the road, don’t worry.

Posted in Uncategorized | Tagged , , | Leave a comment

Running Padrino Tests on JRuby

This one tripped me up, and I thought others might run into it.

If you are trying to run a set of specs under Padrino, you usually run:

padrino rake spec -e test

But this was blowing up for me with the following error:

ArgumentError: Java package `java.sql' does not have a method `send'

You have to remember to run the tests in test mode, so try running padrino rake spec -e test

It also helps to have the rack-test gem in your Gemfile under the development block:

group :test do
  gem "rack-test", :require => 'rack/test'
end

Hope that helps you get your tests running.

Posted in Uncategorized | Tagged , , | 1 Comment

Running Torquebox as a Windows Service

If you are planning on running Torquebox – the JRuby application server – as a Windows service then let me save you a bit of searching.

The thing to remember is that Torquebox 2.x is – under the bonnet – a JBoss AS7 instance and as such you can use the instructions here for running JBoss AS7 as a service. This worked right off the bat for me.

Running Torquebox as a Windows service will ensure that you can stop and start it automatically with the machine in the event of a reboot, and the server execution is not tied to a particular user session.

Another useful bit of information for getting your JRuby stack running on Windows.

Posted in Uncategorized | Tagged , , , , | Leave a comment

A Different Direction – Why we’re choosing Ruby

Past, Present and Future

Over the past few months, I’ve been thinking hard about what the future of development in fusioneer.com will look like. Since I was promoted to head up the development team over five years ago, we have never stopped and thought about how we do things, and what we use to do these things.

Over that period we have learned a lot.

Aches & Pains

We needed to address a number of issues, namely:

  • How we could expand our product offering, onto mobile and beyond while only maintaining a single core set of server-side functionality? The website had been all-consuming since the business was started and everything was designed with only that in mind. Very little throught was given – in the early days – to separation of concerns and the idea that we should have a core API we can depend on from different products (website, mobile etc.)
  • In the absence of a dedicated QA team, we were finding that a lot of bugs were coming back to us from older work – often work that had never been written with testing in mind. These bugs were costing money and there was a realisation that we needed to do more about code quality.
  • The development team felt that the language choice of ColdFusion (currently our primary server-side development language) was holding the team back. There is no doubt that most tasks can be done adequately using CF, but we wanted to strive for more than that. We also want in future to attract the best talent we can, and CF – for better or worse – is seen by many new developers as a career dead end.
  • The current deployment process, while improved from a number of years ago, was still not up to scratch. We were not deploying from a particular revision and we had issues with cleaning out old stuff on the site. We needed to pull up our socks in this regard.

So a lot of work was needed and happily management felt that it was time for some fundamental changes in order to take us into the next 5/10 years in good stead.

Ruby? Seriously, like?

So after a lot of research, discussion and investigation we settled on ‘mixing in’ Ruby – specifically JRuby – over the short to medium term.

And this week I was asked my our IT / Sys Admin team to explain the choice of Ruby. And it’s incredible how much a decision can make such sense to you, but be incredibly hard to explain to others. Some feedback:

  • What’s wrong with ColdFusion anyway?
  • Is Ruby not just a fad and likely to disappear?
  • Why not PHP? That’s waaay more popular than Ruby.
  • Will it work (well/quickly) on Windows?
  • Is it a bad choice because it is open source?

So the context for these decisions is our current web technology stack, which is:

  • IIS
  • Adobe ColdFusion 9
  • JavaScript
  • (a little) Java
  • Flex / ActionScript
  • SQL Server 2000
  • Windows 2003/2008

If you check out the Tiobe index of programming languages – and just presume it’s somehow correct – you’ll see that Ruby is at number 11 (at the time of writing). I’ll exclude a bunch of non-web languages ahead of it, that knocks out:

  • C
  • C++
  • Objective-C

That leaves:

  • Java
  • PHP
  • C#
  • Visual Basic
  • Python
  • Perl
  • JavaScript

At this point, any of these top languages will do the job, so the following explanations are really speific to us and our team and language stack. It’s easy to get into programming language holy wars, so please take the following with a pinch of salt and don’t be offended if I didn’t reason the same way you would 🙂

We excluded the following:

Java, C# & VB .NET: we didn’t feel either of these languages (being compiled and statically typed) would help with productivity and simplicity. We especially felt compile step would be difficult to manage for a team that is used to a dynamically typed, interpreted language. We also felt that if you were going to choose a .NET language C# is first among equals, which ruled out the (older) VB .NET.

Perl: excluded as it’s not an object-oriented language and is being replaced by more modern scripting languages such as Python and Ruby.

JavaScript: we’re not cool enough to run Node.js 🙂 Maybe someday, but for us in the medium term this will remain as a client-side language.

Python: I would have loved to seriously consider Python, but it’s lack of compatability with Windows systems was a worry for us. We are dabbling in *nix systems but not for core production machines yet.

PHP: a strong contender. Windows compatible (via MAMP), very popular. But we felt that the language was not really a step forward compared to ColdFusion.

Ruby: there was a very complelling reason to choose Ruby and that was JRuby. We could run JRuby on the JVM on Windows, just like CF now, and it was a familiar thing to us. And one of the most compelling things about JRuby is TorqueBox, the JRuby server built on the JBoss Application Server. The idea of an application server, to handle tasks like scheduled jobs, services and configuraton was also familar to us as CF users.

If you want an overview of TorqueBox then check out this PDF.

Well worth the read.

Finally, Community

When Ruby on Rails emerged in 2005 it quickly established it’s reputation as a high-productivity best-in-class MVC web framework and has been copied across many other languages. What the Ruby community started in Rails is still going on – pushing the edge of web development, establishing best practice and building a thriving community.

The Ruby community is is love with testing and especially with Test Driven Development (TDD), and we want to set that tone within our development team as we adopt Ruby. When you share code in a open-source community it’s only fair you provide some proof your code works as expected, and we feel that should apply to our little development team community too.

We are planning on introducing TDD alongside Ruby and testing tools like RSpec and Cucumber are well established in the Ruby community. We’re going to jump on that bandwagon. We hope that over time we’ll develop a set of tests that will allow us have more confidence in our code and catch regressions early.

The Ruby community also thinks hard about application design, about deployment, about APIs and about standards. This is the other reason we chose Ruby: the community. We want its opinions, experiments and lessons.

We’re looking forward to this journey, we’re excited and rearing to go. More posts to follow.

Posted in Uncategorized | Tagged , , , | 11 Comments

Running Rails 3 on JRuby in Windows

I read an excellent post today, that resonated with me.

My day job involves me using ColdFusion (CF), a interpreted language on the JVM. Say what you will about CF as a language, but the decision they made at version 6 back in 2002 to rewrite CF to run on the JVM was inspired. It brought some real stability and power to the CF platform, and we’ve benefited from this deep integration with Java since then. We get all the speed of CF development and all the power of the JVM, and we get the seamlessly integrate with a myriad of different Java libraries. We can use any JVM debugging tools out there to find issues with our applications, and we can run CF on almost any major platform, should we wish to.

However, as a scripting language, CF can be inconsistent. It lacks any form of null value for instance which can be pretty frustrating in mapping database tables to CF objects. It’s case insensitive which in an unsupervised environment can make things very messy if developer are not consistent. While the syntax is much more compact than Java, it is not very expressive by modern standards, is full of global functions len(), listFindNoCase() and the implementation of the tag and script versions of the language can be confusing and inconsistent. Nevertheless we use it, it’s always been up to the job and overall it’s an enjoyable and productive language to work with.

In my spare time I’ve dabbled in PHP, Python and Groovy (Grails). And lately I’ve been playing around a lot with Ruby on Rails. I really like the Ruby language and the Rails framework is really excellent. But then again Rails is a very popular framework and Ruby a very popular language compared to CF. If we take the number of questions asked on Stackoverflow.com as an indication of the number of programmers using a particular language then we can really see the difference:

Ruby on Rails – 45854
ColdFusion – 2534

But before I go on: an admission. I tried to dabble in Rails a few years back (maybe 2006) before I really understood Ruby, and I did it in a Windows environment as I did not have a Mac at the time. Boy was that painful on both counts. However, in the past 6 months I have taken the plunge and invested in a Macbook Pro and all of a sudden, after reading a few Ruby tutorials before going near Rails, the penny dropped. Programming using Ruby on Rails on a Mac is a dream. Everything works. It’s really great.

Addiitonally the deployment setup for Rails is great, and I’ve had a really easy time deploying to Heroku.

Which brings me back to the article I mentioned at the start. The gist is that Ruby developers need to start making life easier for those on Windows, and if they do that they will be rewarded by an explosion in users, because until recently Ruby and Rails is for the Mac and Linux crowds only.

That was until JRuby arrived on the scene.

Now Windows developers can run Ruby on the JVM, very much like the way CF works now. This not only opens up Ruby and Rails to Windows developers but also to the ‘enterprise’ crowd, the developers who are using Java now but crave a performat scripting language with lot of programmers using it. With JRuby they can have the JVM, they can have native threading and real concurrency, and they can all their usual JVM tools but they also have a massively popular, modern language and framework which should make them more productive.

As an experiment his evening I decided to see if I could get my spare-time Rails application – currently running on my Macbook Pro and in the Heroku Cloud – up and running on my Windows 7 laptop using JRuby.

I was actually very surprised at the results. It was very simple. The steps are simply to:

  • Install JRuby + JVM (single Windows installer)
  • Follow these instructions but just to get rails and the ActiveRecord / SQLite adaptor gem installed
  • I then had to tweak a few of my own gem file settings before I started to ensure that I was not using an native C extensions such as the mysql2 gem – JRuby cannot support those.

All the rest of the issues revolved around the fact that my application was running on a later version of Rails under JRuby, so at this point you can forget you are running on JRuby and the JVM – you are just dealing with a Rails application and there are a lot of resources out there on the net to help you.

Overall I’m very happy with the results. I am thinking of trying this out on a production environment next, and running the GlassFish or Tomcat server instead of Passenger. I also want to experiment with Rails talking to SQL Server – another Windows stalwart.

Posted in Uncategorized | Tagged , , , | 2 Comments

ColdFusion Dynamic Finders using onMissingMethod()

I doubt if our team is unique in this respect, but we actually wrote our own DAO / Gateway library from scratch.

The main reason we did so was to ensure that the SQL being executed was exactly as we expected, but we could still use the ideas of a DAO / bean CFC for quick one-row reads and updates to tables.

So we generally will generate three CFCs from a SQL table definition. For example, for the Customers table we would create

  • Customers.cfc – DAO / bean class
  • CustomersGateway.cfc – editable ‘gateway’ class for multi-row queries and multi-table joins
  • CustomerGatewayBase.cfc – the base / super class for the CustomersGateway.cfc – this contains helper functions generated specifically for this table.

I’ve been doing some Ruby programming lately, using Rails and I got exposure to Active Record – pretty much impossible to avoid when using Rails.

One of the ideas used in AR is that of Dynamic Finders: simple functions used to help lookup a database row. Example might be Customer.findByFirstName(firstname) or Customer.findByUsernameAndPassword(username, pwd).

The nice thing about these functions is that you don’t have to write them, they are inferred or dynamically created (sort of!) by some Ruby magic – explained pretty well here.

Even better, you can do almost exactly the same thing in ColdFusion!

The general idea:

  • You have a table bean or DAO
  • You catch any missing methods called on the class using onMissingMethod()
  • You use the passed arguments to work out what the user was trying to do and give an appropriate response

Example:

  • Imagine I call Customer.findByUsernameAndPassword(username, pwd)
  • There is no actual function called findByUsernameAndPassword(username, pwd) on my DAO so ColdFusion will execute onMissingMethod() passing in the name of the function I tired to call and whatever arguments were passed to it
  • onMissingMethod() will examine the function name I was trying to call, and if it starts with ‘findBy’ it will assume I am trying to lookup some data, i.e. execute a dynamic finder
  • Next a bit of parsing will work out the fields I am trying to find the data by, so by delimiting by the word ‘and’ and removing the ‘findBy’ we can work out the the search fields are ‘username’ and ‘password’
  • Super, now it’s just a matter of constructing our SQL query based on these strings and the passed values. Really simple and powerful.

And that as they say is that! The only other things I did was check the passed finder search fields against a list of table fields I store in the DAO which just means I can throw a more sensible error than waiting for it to blow up executing the SQL.

You can get the code as a GitHub gist here.

Enjoy!

Posted in Uncategorized | Tagged , , , , | Leave a comment