Bootstrapped Thoughts
  • Bootstrapped Blog

RVM, gemsets and bundler

10/7/2016

6 Comments

 
I use RVM with gemsets and Bundler to manage my Ruby environment and dependencies.  Some people question that.  "Isn't RVM over-complicated?" they say. Or, "why are you using gemsets when you have bundler?" There are even some ethical objections: "I don't like how RVM overrides shell commands!"

Allow me to address these questions, starting with the easy one: RVM overrides shell commands, mainly the cd command so that it can detect environment files when we change directories. So what!? It just works and unless you're some kind of Shell Puritan that's all you should care about.  Besides, many other apps and utilities use all kinds of shims and proxies and no-one bats an eyelid. Get over it!

But what about complexity? Installing RVM involves a single command, two if you include downloading the gpg key. The vast majority of the RVM commands that I use daily are just a combination of the words use, gemset and create with a couple of list and install thrown in for good measure. Pretty simple really.

Finally, why use gemsets? Surely, with Bundler there is no need to use gemsets any more, is there? Well, from a deployment point of view, this is correct. We can just deploy our Gemfile and Gemfile.lock and Bundler will ensure that the right versions of our gems are installed. Furthermore, Bundler can also tell us whether our gems are outdated or if we can upgrade the version of a specific gem without breaking others and other such wonderful stuff.  However, from a development POV using gemsets is the cleanest and safest way to manage our environment. Consider a non-gemset set-up:
Picture
To make sure we use the correct version of our gems for our project we need to go through Bundler, which will look up the relevant Gemfile and use the appropriate gem. So Bundler knows ,for instance, that when we call rails we mean rails v5 within our current project and not v4. There are two problems with this approach:
  • We have to prefix commands with bundle exec. This is a right pain in the neck, even if we do get to alias bundle exec in our shell.
  • There is no easy way to remove gems used in a project once we've finished with that project. So we tend to end up with a heap of unused and unnecessary gems of different versions in our system.
Picture
By creating separate RVM gemsets for each of our projects, we get a physical separation of our dependencies. RVM stores ruby versions and gemsets in separate directories, so there are no potential conflicts. We still use Bundler to install our gems, but each bundle install now works within the context of the current gemset. This means that we don't have to call our rake or rails commands within the bundler context, as there is no need: we now know that the right dependencies will be in the right gemset. And when we finish with that protoype app we've been working on, we can just delete the app's gemset and get rid of these gems that we used as an experimental one-off.

RVM simply stores each permutation of <RubyVersion> and <Gemset> in separate directories.
Picture

Whenever we decide to use a new Ruby Version or Gemset, RVM will just set our GEM_HOME and GEM_PATH environment variables to the appropriate directories.
Picture

My Workflow

I install commonly-used gems like bundler and nokogiri in the Global gemset. The Global gemset acts as a template from which all other gemsets are created. This means that whenever I create a new gemset, it will already include bundler and nokogiri.
rvm gemset use global
gem install bundler nokogiri

When I start a new project, I create a new gemset for it
rvm gemset use myapp --create
////myapp gemset includes bundler and nokogiri

In the case of Rails projects, I'll install the Rails version I want straight into my gemset. No, I don't put it in my Gemfile first and then call bundle; there's no need: the rails new generator will do that when I create my Rails project
gem install rails -v 5.0.0
rails new myapp

Installing rails directly in my gemset also means that I know I'm using the right rails version, so i don't have to type bin/rails.

I then create RVM config files .ruby-version and .ruby-gemset in my project directory.  These files will be looked up by RVM whenever I cd into this directory so that RVM will load the right Ruby version and gemset for me.
cd myapp
rvm use --ruby-version 2.3.1@myapp
////creates .ruby-version .ruby-gemset

And that's it. Simple and effective. Clean separation of dependencies, no faffing about with bundle exec and full control over my gems. Sweet!

I'd love to hear how you manage your gems and dependencies. If you use other version managers, what makes them better / easier than RVM? Let me know.
6 Comments

Why you should use Rails for your new company

9/25/2015

3 Comments

 
Picture

Jared Friedman, founder of Scribd, recently wrote a blog post titled "Why I wouldn’t use Rails for a new company".  In it, he makes three points as to why Rails is 'past it' and why new start-ups should look to some other framework or language for their products:


  1. Rails isn't the hottest thing any more.
  2. Other frameworks have caught up with Rails. Rails is static.
  3. Ruby is slow

He then draws on these points to make a startling conclusion:
"If you want to future-proof your web application, you have to make a bet on what engineers will want to use in three years. That’s more important than what framework lets you be most productive right now."


The myth of 'hotness'
Points 1 and 2 are unarguably correct. Rails isn't hot any more and is not evolving at the pace it used to be.  But this isn't a bad thing. It's a sign that Rails has matured, it's now an adult framework and not the spotty teenager who grows taller by an inch every month.  Its growing pains are behind it, the rough spots have been ironed out and all Rails needs to do now is position itself in a changing technological environment. With Rails 5 it seems this process has already begun. That's partly what maturity is about: the ability to assess a changing scenery and see your place within it. Not playing catch up with the Joneses. Let's leave that to all the other frameworks which have been 'inspired' by Rails over the years. This is by itself a testament to the success and influence of the framework.  As the saying goes: 
"Imitation is the sincerest form of flattery."

The myth of 'speed'
Ruby is slow. I know it, you know it, the world knows it. The question is : 'Does it matter?'

Let me tell you a secret. I was around in 1996, in my first job as a C++ engineer (yes, I'm that old).  It was when Java first came out. I was one of the many C++ developers who had a good laugh about it.  'It will never catch on', we said, 'it's just sooo slow!'.

And it was. This was Java release 1, way before the JIT optimisations and the HotSpot. It was an order of magnitude slower than anything we built in C++. Even today, after all the Java performance improvements, C++ natively-optimized code is still faster than its Java counterpart. Did that stop Java from becoming, arguably, the most popular language on the planet? Nope.  Did that stop Java from replacing C++ as the language of choice for enterprise back-end and desktop applications? Nope.  

So why didn't Java's lack of speed  stop it from spreading like a virus? The answer is simply: 'context'. In the context where Java apps were beng used, Java's slow performance didn't make a difference. Think about it, the average HTTP request takes about 0.5 secs.  Many database transaction times are measured in seconds (PS: you should optimise these, BTW).  Why would I put in the time and effort to re-write my 250ms Java applet to a more performant 50ms C++ DLL, when it will make no difference at all to the end result?  Oh, and also did I mention that my Java code would crash half as often as my C++ equivalent? (no explicit memory management mistakes, see)



So what about when you needed that extra performance boost or this explicit memory management in your app?  Well, then you just didn't use Java, you used C++. As simple as that. Ease-of-use, productivity and safety are usually valued over app performance. As someone famous (I forget who) once said: "Developer cycles cost more than processor cycles".


Now replace 'Java' with 'Ruby' in the above paragraphs and 'C++' with <your-choice-of-fast-language> and you'll see that the principle still stands. Ruby is a wonderfully expressive, flexible and highly-productive language (much more so than Java ever was). That's why you should be using it in your start-up. Ruby gets out of your way and lets you be creative. Rails is a tried-and-tested framework that's proved itself in the field. Yes it has its bad points- too much magic and some un-OO practices- but as a start-up you want to put your product out there as quickly and efficiently as  possible and there are few better tools than Rails to help you achieve that. 


Epilogue
If your main worry is about what engineers are likely to be using in three years time, instead of the best way to make your product available to your customers, then chances are you'll be joining the 90% of start-ups that fail within their first year.  If you don't want to go down that route then use Rails to maximise your chances.








 







3 Comments
    Picture
    MetaRuby Forum
    Let's talk Ruby!


    Fred Heath

    Polyglot developer, consultant and all-round good guy. I love: solving tricky problems, Ruby, meta-programming, Nim, Behaviour-Driven Development, the semantic web. 

    PGP fingerprint: 6FD4 7DE2 539E 16F8 AE7F FB30 425A 794F 860A 7DDF

    "My fierce intellect and dashing good looks are only surpassed by my under-stated sense of modesty"

    Categories

    All
    Agile
    C++
    Dependencies
    Estimation
    Hash
    Interview
    Java
    Job_ad
    Learning
    Logic
    Nim
    Performance
    Python
    Rails
    Recruitment
    Ruby
    RVM
    Scrum
    Startups
    Story Points
    Velocity

    Archives

    July 2017
    October 2016
    April 2016
    November 2015
    September 2015
    April 2015
    March 2015
    February 2015
    January 2015
    October 2014

    RSS Feed

Proudly powered by Weebly
  • Bootstrapped Blog
✕