{"id":391,"date":"2013-07-26T09:54:29","date_gmt":"2013-07-26T09:54:29","guid":{"rendered":"http:\/\/nicholshayes.co.uk\/blog\/?p=391"},"modified":"2014-02-06T14:32:32","modified_gmt":"2014-02-06T14:32:32","slug":"adding-a-console-shell-to-your-ruby-apps","status":"publish","type":"post","link":"http:\/\/nicholshayes.co.uk\/blog\/?p=391","title":{"rendered":"Adding a console shell to your ruby apps"},"content":{"rendered":"

Using Rails Engines<\/a> is a really nice way to introduce yourself to creating gems. It provides an environment to create and test code that is very similar to that used when creating a full rails app. There are couple of things to be aware of, such as that you run tests from the root (rake test<\/strong>), but run the test server and console (via rails s<\/strong> and rails c<\/strong> respectively) at test\/dummy, but otherwise any rails developer should be able to get up to speed with engines reasonably quickly.<\/p>\n

However, the more gems I write, the more I’m learning that keeping dependencies to a minimum is a really good idea. For example, do you really need a specialist HTTP gem like curb<\/a> or typhoeus<\/a> or can you manage with net\/http<\/a>. In a rails app, the simplicity and features that excellent gems like curb and typhoeus provide, often make them compelling. In a gem, the extra dependencies they add can be an issue. For example, what if a host rails app is already using a version of typhoeus, and that version clashes with the one your code uses.<\/p>\n

A key rule with a gem is that you cannot predict the environment in which it is run, and therefore you should put some effort into reducing the gem’s dependencies.<\/p>\n

Using engines to create gems, by definition, adds a dependency on rails, and all the baggage that comes with rails. If the gem is only ever going to be a rails plugin, and it adds its own controllers and views to the host app, dealing with this ‘baggage’ is well worth the effort. However, that is often not the case. With a little effort you can minimise the dependencies. For example, my most popular gem (array_logic<\/a>) has no dependencies beyond the ruby standard library.<\/p>\n

So as I have been creating more gems, I’ve started to identify strategies that allow me to minimise dependencies. For example, indulgence<\/a> needed ActiveRecord, but by using standalone-migrations<\/a>, I was able to create a nice test environment using ActiveRecord, without any other dependencies.<\/p>\n

In fact, it is fairly easy to create a working test environment. I’m a great fan of test\/unit and minitest, and as both are now part of ruby standard library, using them again reduces my gems’ dependencies.<\/p>\n

What I’ve been missing is an easy way of getting to an equivalent of the rails development console. Today, I’ve had yet another ‘why didn’t I think of that before<\/em>‘ moment. There is an easy way to create a console. I’ve added a console.sh<\/em> file to my latest gem project (webdav_file_store<\/a>) with this content:<\/p>\n

#!\/bin\/bash<\/span>
\n
\necho<\/span> Opening Ruby shell with WebdavFileStore loaded
\nirb -r<\/span> .\/<\/span>lib\/<\/span>webdav_file_store<\/div><\/div>\n

The -r option of irb is doing all the work. It is loading the file that opens my WebdabFileStore namespace Module, along with the requirements it loads. This only works in a bash shell, and you have to make the file executable, but once that is done, all I do is run .\/console.sh<\/strong> and I am in a console session with all my WebdavFileStore objects loaded.<\/p>\n

So another technique I can add to my strategies to minimise my gem dependencies.<\/p>\n

Update:<\/h2>\n

See this article on Ernie Miller’s blog<\/a>\u00a0for an alternative approach. That is, to create a rake task that opens the console with the gem loaded. The comments are well worth a look through. I think Ernie’s is probably a better technique to the one I describe above.<\/p>\n","protected":false},"excerpt":{"rendered":"

Using Rails Engines is a really nice way to introduce yourself to creating gems. It provides an environment to create and test code that is very similar to that used when creating a full rails app. There are couple of … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3],"tags":[],"_links":{"self":[{"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/391"}],"collection":[{"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=391"}],"version-history":[{"count":15,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/391\/revisions"}],"predecessor-version":[{"id":488,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/391\/revisions\/488"}],"wp:attachment":[{"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=391"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=391"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/nicholshayes.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=391"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}