←

→

Living In A Post Rails World

February 14th, 2009 | Agile, Programming, Ruby, Tech

The hardest thing to see is what is in front of your eyes. -Goethe

It’s been about 6 or 7 months since I’ve done any Rails work.

I’m in a post-Rails world.

After working in Rails for 3 years, I was burnt out. I took some time off to try to learn the finer points of marketing and running a business, and then attempted to start a new business just before the market cratered. Not a great idea.

Now I’m back writing code all day and it’s great. My days now consist of coming up with test cases to solve problems and then solving them.

Something is different though.

I used to write a ton of test cases in the context of my Rails apps.

Now I write high level test cases and then write code and pick and choose technologies to solve them.

I feel like this is a natural progression for those of us that practice TDD.

Take one more step back, use something at an even higher level to write tests (I’m using some Cucumber and some rSpec), and then implement a bunch of little apps to make what you want to happen, happen.

It keeps things simple, and keeps the problem from growing too large.

In my current project I’ve got a cluster of Nanite agents up and running with a couple of Merb apps talking to them on the front end. It’s something that I never could have done if I was trapped inside of the Rails box.

Hell, it’s probably something that I never even would have thought of.

I think that the Ruby world is eventually going to end up in a model like this, writing small simple apps that all talk to each other, and can be replaced or upgraded at any time.

By writing a lot of tiny apps, I’ve been able to solve problems now in days that used to take weeks or months.

Plus I’m not getting locked in to anything. If I want to replace my Merb app with a Sinatra app next month, it’s not a huge project. If I want to swap in some code running on the Maglev Alpha that I’m playing with or deploy some components written in Clojure, I can do that too, without being intimately tied to anything.

All of my hard/long running logic is well tested, encapsulated, and most likely running in little agents on the wire.

I guess what I’m saying is that if you’ve been writing Rails code for a long time, perhaps now is a good time to step outside of the rules that Rails imposes upon you and look at things from a different angle.

You might find it refreshing and helpful.

I certainly did.

  • I think the key is, as you say, that this is the natural progression of BDD. If you describe the behaviour you want in a high-level way, the app becomes an implementation detail. Cucumber makes this easier than it ever has before. I do things strictly over HTTP (no running features inside a Merb process) so that I'm not tied to the framework I use. Controlling multiple components can be a challenge in itself - something I've had to work on a lot lately, and want to turn into a gem.

    95% of specs should relate either to high-level behaviour (Cucumber features), or isolatable domain logic (ie model/lib code). The web (or otherwise) framework just provides the glue to tie these together - there's no need to think about writing a "Rails app" or a "Merb app", you write an app "with help from Rails" or "with help from Merb".
  • I've been working on a project that's a loose conglomeration of a few gems, and it's really liberating after being used to huge monolithic Rails codebases. Being able to focus on one small app at a time really helps since it's much easier to fit in your head all at once. Doesn't hurt that the test suite runs a lot faster too.
  • So in a post rails world we have myriads of Nanite agents talking to a countless number of little applications? Sounds interesting. A concrete example would be nice. Or a small presentation describing the basic elements of the system.
  • I'll try to come up with a simple example of something and put it up on Github. All of the code I've written lately has been for clients.

    The problem is that these sort of things tend to need a lot of plumbing (RabbitMQ, dependencies, etc) so I'll have to figure out a more scaled way to demonstrate things.
  • lolcatz
    +1 for examples, please
  • Ade
    I'm with Sean here...can I see some actual examples of these tiny-app systems?
  • ferrisoxide
    That should have been "I think even core Rails folks realise it's NOT the answer to every problem." Wups.. one little word.. :)
  • rick
    we never said rails was the answer to everything. it fills a need.

    I wouldn't say multiple smaller apps are necessarily easier to maintain, though. Each piece adds complexity in getting an application up and running. I'm just dabbling in this area, and I already need to startup a database, a Parkplace server (using Amazon S3 in production), Sphinx, a payment gateway (sinatra w/ json api), and an Astrotrain instance (merb server for processing emails) just to get Tender Support (all rails) running. it's not exactly trivial for me, and it's downright a pain for our designers. Luckily, these external services are optional and only needed if you're looking at that specific feature that they enable.

    Being able to step outside your comfort zone is a very good thing, though.
  • Let me clarify one thing, I don't think that Rails is dead.

    I think that it's very much alive and well (and Rails 3 is looking great), but at the same time the Ruby tools world has reached a level of maturity where if you're not looking at all of the other possible solutions to a problem then you're really doing yourself a disservice.
  • ferrisoxide@gmail.com
    Weirdly enough, this is the very direction Rails seems to be headed anyway. With support for Rack - via Rails Metal - the opportunities to write tiny apps that stick together is huge.

    Have a look here for a couple of examples of where this is headed: http://weblog.rubyonrails.org/2008/12/17/introd...

    Rails aint dead - but I think even core Rails folks realise it's the answer to every problem. Small things, loosely coupled - that's the Ruby world I want to live in.
  • Sean
    I'm not sure if I can wrap my head around this... can you provide an actual example of one these tiny-app systems?

    @elliottcable: Just because you don't use Rails doesn't mean it's dead. Get real.
  • zerohalo
    I agree with/like the concept of small apps talking to each other rather than one big one. Easier to maintain/upgrade/reuse the individual components. But I see no reason to ditch Rails in order to achieve that. (No need to be stuck in Rails either, of course.)
  • Great article, I also thought of seperating parts of my applications, like the authentication system and others. At some point I could build applications which relate very well if they use the same tiny applications/databases.

    @elliottcable: Rails is far from dead, come on! It's being developer for, upon and with!
  • I came to Ruby a few years ago, intending to get "a firm base" in the parent language before hitting Rails, my real goal. I fell so much in love with Ruby - real, pure Ruby - that I never ended up doing anything with Rails. I'm glad of it.

    Rails is dead, or will be soon enough. Long live Ruby!
blog comments powered by Disqus