Larrikinism

GSOC 2011: ssc Week 10

Mon, 01 Aug 2011 18:56:47 +0530

Tasks completed this week:

Implemented checkout of an existing appliance from Studio. ssc checkout --appliance-id=APPLIANCE_ID now works.
Integration tests for the appliance, package and repository handlers. (Currently at about 50% test coverage).
Completed the refactoring and migration to the New DirectoryManager module.
Added the build and build_status commands

Schedule for next week:

Improving test coverage and removing all the deprecated and unused methods.
Writing unit tests for the helper modules.
Writing usage examples for the app to help new users.

GSOC 2011: ssc Week 9

Sat, 23 Jul 2011 17:13:00 +0530

Tasks completed this week:

Replacing of ArgumentParser with Thor. I’d given a mid-week update about this [1] on the mailing list. Please check there for complete details.
Implementing the general commands (checkout, commit and status). As a direct consequence of using thor for the command line parsing, we get to use the invoke method to call other actions. This made writing these commands quite easy.
Started on refactoring the DirectoryManager module. The NewDirectoryManager is currently in use in the general commands and will gradually replace the older version which is a mess of helper functions right now. There will be separate classes for handling each of the local storage files (for software, repositories and files) deriving from a parent LocalStorageFile class which implements the generic #read and #save methods.
The gem is now hosted on rubygems.org . So, you can install it with gem install ssc. Use the fantastic thor generated usage instructions to help you use the app.

The tasks for next week are:

Write integration tests
Implement a command to get information about installed packages from the currently run system.
Commands for Appliance building and build status reporting.

If you have any suggestions for features. Please do write in on the studio-users mailing list.

[1] http://lists.opensuse.org/opensuse-project/2011-07/msg00098.html

GSOC 2011: ssc Week 6

Mon, 04 Jul 2011 11:05:09 +0530

Most of the work this week has gone into the File Handler. Adding and removing files in appliances has been implemented although there is a lot of work left to be done to make this robust. Right now its pretty basic. However I’m going to ease up on adding functionality right now to make the app more robust and usable. The mid-term evaluations are coming up and the plan is to have a usable app that is community tested by then. Not to say that new features won’t be added over the next two weeks, but it will be a second priority. In making the app more stable, the following things will be addressed:

Ruby 1.8.7 (backward) compatibility
Extended test-suite including integration tests which require a network connection
Better error handling.
A method to roll back changes in case of failure.
Documentation.

That will be the focus over the next two weeks building up to the mid-term evaluation. Thank you for reading. As always you can check out the core here

GSOC 2011: ssc - Week 4

Sun, 19 Jun 2011 20:00:00 +0530

The DirectoryManager module has been polished and it now handles duplicate entries in the software and repositories files. The app now handles errors better and crashes more gracefully with meaningful error messages. As for functionality, I’ve added package banning and unbanning. Also package importing has been included in the current release.

I’ve started work on the file handling of the app. Currently it works similar to the packages or repositories with the difference that the file in question is copied over to <appliance_directory>/files. Adding and removing these files will be simple enough within the current framework. And with some work time-stamp information can be incorporated to do more efficient syncs. I hope to have that done by next week and follow up with a basic implementation of the commit command in the week after that so that we can have a first usable version of the client.

If you want to check out the application now, you can take it for a spin using the gem. Use with caution, and all that. It shouldn’t do anything catastrophic, but, I wouldn’t use it with anything other than a test appliance at this point. Download it from here. Install it with rubygems (gem install ssc-0.1.0.gem) and run ssc help to see the usage instructions.

GSOC 2011: ssc - Week 3

Mon, 13 Jun 2011 11:59:08 +0530

This week I was working on the local storage feature of the client. As proposed we were going to add and remove packages, repositories and files with a git-like workflow. i.e. ssc package add gnuchess would make a local record of the intention to add that package and on ssc commit the changes would actually be pushed.

In order to facilitate this I’m abstracting all the directory management to a DirectoryManager module. Which abstracts methods to save, read and diff from local sources. Right now the syntax I’ve chosen is YAML. For instance the software file in the appliance directory - which catalogues the changes made to the appliance’s software - stores names of installed packages. Unless the ssc command is invoked with the -r | --remote option, it will display the packages in that file. In addition when ssc package add gnuchess is run with out the -r option, it will make and addition add gnuchess to the software file. Similarly for remove. I am having some problems figuring out how to integrate patterns into this architecture so any help on that front would be appreciated.

That’s it for this week. I’m going to be working on pretty much the same thing next week. Extending and refactoring this functionality. So hopefully we will have a more usable version then.

Thank you for reading.

GSOC 2011: ssc - Week 2

Sat, 04 Jun 2011 19:39:28 +0530

In terms of user functionality, searching for software, templates, appliances and packages has been implemented this week. The actual api calls are performed by handler classes like SSC::Handler::Appliance which exposes public methods like list, show, repositories and installed_software. I’m trying to follow a template that allows any command of the type ssc <class> <action> <arguments> to map directly to Class#action(arguments) with minimum modification along the way. The command line arguments (—option value) are parsed into an options hash that keeps getting passed down the stack and used as necessary. Right now I’m not happy about exposing data that is unnecessary for certain functions via this hash but it makes sense to have the checking of data in the handler action rather than at the top level which makes that inevitable.

There’s been some abstraction and refactoring to make way for having the .sscrc file what will hold the appliance configuration in the appliance directory. Right now there isn’t a lot of validation of options and the parser merely merges options from .sscrc and the command line to pass into the various handlers.

One tiny useful takeaway from this week has been learning about the Method class. Its very useful in meta-programming. For instance when calling methods with the Class#send method it would be useful to make sure that you’re passing the correct number of arguments. The Method#arity method can be used to check the number of arguments that a method takes before passing arguments to it.

Next week I’m going to be focusing on the structure of the appliance directory and handling those commands that work locally.

GSOC 2011: ssc - Week 1

Wed, 25 May 2011 11:38:27 +0530

Introduction:

My proposal for a command-line client for Suse Studio has been accepted for this year’s Google Summer of Code. You can see the full proposal here. In short, the project is pretty self-evident from the title. In case you don’t know what Suse Studio is, its a web service that allows you to design custom ISOs of linux distributions. As you can imagine, designing a custom variant of a linux distro will involve a lot of configuration. This tool aims to ease the hassles involved with using the web interface to make these customisations. The most common use case for this tool as I see it will be modifying default configuration files. The tool will allow you to make all the modifications you want locally in an appliance directory and push the changes when you’re ready. If you want a more thorough view of how it will work please do read the complete proposal.

Project Details:
Now that the introduction is out of the way, some updates about my implementation of this proposal. The coding period started a couple of days back. The code is going to be hosted on gitorious, here. I’ll be pushing there almost daily and when we have a relatively stable version we’ll push to the upstream repo. The rough timeline that I hope to follow is as outlined in the proposal:

May 24th - Jun 5th: Create the framework for the command line client. Get the option parsing working and implement some of the basic search functionality.
Jun 6th - Jun 19th: Implement the appliance directory management features.
Jun 20th - 26th: Release a first alpha version for testing and reviews
Jun 27th - Jul 11th: Tidy up, refactor code. Raise test coverage. Fix Bugs.
Jul 12th - Jul 17th: Mid-Term Review
Jul 17th - Jul 31st: Implement the commit, update and status commands.
Aug 1st - Aug 15th: More testing, bug fixing and community review.

High level documentation will be maintained on the openSuse wiki. Once there is substantial code, the class/method level documentation will be hosted at rdoc.info.

Work Update:

ssc uses the studio_api gem to make API calls to Studio. While trying out the gem in preparation for this project, I made a small but important(at least I think so :)) bug fix contribution to the project. It probably required someone with a crappy internet connection like mine to discover this.

So far the code written is mostly framework stuff. There’s an ArgumentParser that does the command line parsing. I’m using mocha and shoulda for testing. I decided to bump the oh-so-cool rspec/cucumber frameworks for simple test unit. I’ve used rspec in most of my projects and other than syntactical niceness I don’t see what test unit lacks. I’d like to try out that theory here.

That’s it for now I think. Not a lot, I know but hopefully, I will have more for you next time. Thanks for reading.

Bye Bye NerdTree. Hello CommandT

Tue, 14 Dec 2010 09:52:01 +0530

CommandT is an awesome vim plugin made by Wincent Colaiuta of http://wincent.com . Its been around for a while but I wasn’t able to use it earlier since it requires vim complied with ruby support which the standard Ubuntu vim package lacks. I tried compiling it from source but after a couple of hours of struggling to meet dependencies, I gave it up. Recently, I heard that v1.0 of the plugin had been released and figured the time was ripe for another attempt. Turns out what I had to do was crazy simple. On Ubuntu 10.04 just

sudo apt-get install vim-gtk

For some reason vim-ruby which is the only package you need is a virtual package included in vim-gtk, vim-nox or vim-gnome. So just install one of them, grab the vba, open it up in vim and so :so %.

This is way better than NerdTree and FuzzyFinder for file navigation for obvious reasons: It doesn’t take up screen real estate, files are fewer key taps away and its blazingly fast. Enjoy using it.

node.js+ mogodb+ websockets

Mon, 01 Nov 2010 06:16:00 +0530

Now there’s an amazingly buzz-word laden title, if I ever saw one. Anyway, if you, like me, have been hearing more and more about of these terms floating around the interwebs in additions to things like ‘coffee script’, ‘nosql’, ‘event driven programming’, ‘document-oriented databases’ etc. etc. read on for a gentle introduction to new paradigms of programming, new server architectures and new persistence layers.

I’ve always found that the best way to get started with a new technology is to start writing code using it. Of course this has to be followed by very in depth reading about the topic, but it helps if you’ve actually done something to follow along with what people are writing. So in my quest to understand node.js, mongodb and HTML5 websockets, I chose to implement a very basic EtherPad( used in typewith.me ) clone.

The components:

node.js

From what I’d heard about it, its a blazingly fast web server written in JavaScript running on Google’s V8 engine. I still haven’t gotten to a stage where I can benchmark the code myself. But the benchmarks provided here looked really exciting. Installing node was a cinch on my ubuntu system. The usual:

          $ wget http://nodejs.org/dist/node-v0.1.99.tar.gz
          $ tar xfz node-v0.1.99.tar.gz
          $ ./configure
          $ make
          $ sudo make install

Brownie points to the node team for making the make tool give pretty output.

The exciting, game-changing thing about node.js is of course Evented I/O. The presentation below is the best explanation of the concept, that I’ve come across so far.

Evented I/O based web servers, explained using bunnies View more presentations from Simon Willison.

Coffee Script

Since I was going to be writing JavaScript, I thought I’d kill two birds with one stone and look into Coffee Script which helps you avoid JS’s ugly ugly syntax. I would definitely recommend investing the extra time learning this useful tool if you’re going to be developing for node.js or any JS library for that matter. Also as a bonus you can run node.js apps directly using coffee app.js.

express

In three words this is: Sinatra for JS. Being a big fan of the simplicity and transparency that sinatra offers, I pounced on this particular framework for my app. The framework for node.js scene had erupted recently with lots of exciting developments, including: A standard base for frameworks to be built on (similar to ruby’s rack): connect. Being developed by the fabulous guys behind ExtJS (now Sencha). Connect is still however in its infancy and does not have much support.

          get('/' ->
            'Node says, Hello world!'  
          )

kiwi

Pakage management for node.js libraries based on rubygems.

          $ kiwi install express
          $ kiwi list
          $ kiwi remove express
          etc. etc.

I must add here that node.js is still at version 0.1.99 which is infancy compared to most software projects. And is by far not the only server to incorporate Event-driven I/O and to be written in JS(see the end of this article). It has however made sure that those idioms extremely popular and has fostered development along those lines in the ruby community and beyond as well. Think: EventMachine and all the em-* libraries.

mongodb

So I needed a persistence layer for the app and wanting to use a NoSQL DB. I went for mongo coz’ … well … how do you not look into something named mongo. Anyway mongo is a great place to start your jouney to the Dark Side of The Moon, the moon being the database implementations landscape.

To get started playing with mongo, sudo apt-get install mongodb. This gives you a rather limiting mongo REPL where you can try stuff out. When migrating from an RDBMS to mongo there are some changes in vocabulary that you will have to embrace. Tables are collections and rows/records are documents(hence document oriented db). I won’t go into a tutorial about mongodb as there are quite a few of those out there. But, I’ll try and cover some of the benefits.

Dynamic Queries like:

db.users.find({address: /[D|d]elhi/, age: $lt 25}).sort({name: 1})

That’s right, I just queried a db with a regex. And chained queries! Stuff, I could only do with an ORM that would ineffeciently translate that into SQL.

Neat JSON-like language for queries called BSON
Embed has-many associations.

          db.users.insert({
            name: 'Ratan',
            notes: [
              {content: 'The Daily Show is awesome ...'},
              {content: 'Jon Stewart is awesome ...'}
            ]
          })

No unnecessary tables for holding strictly hierarchical data.

I’m sure there are many more but there are the ones that I encountered within 2 days of using it. Another thing that I should add here is the scalability promise of NoSQL DBs. Many users(me included) are drawn to NoSQL by its horizontal scalability. This article seems to debunk that, so i would advise further research before relying on that promise.

I’m not in the best position to debate the pros and cons of document-oriented DBs vs. the traditional RDBMS. But I do think I can propose a rule of thumb to decide between the two if your data fits well into either of the models:

 use NoSQL if (no. of objects central to your app)/(no. of small, supporting and dependent objects) >> 1

websockets

One of the most awaited aspects of HTML5 this revolutionary protocol will make all the hackery featuring flashsockets and jssockets to create real-time web apps obsolete. Support is limited to only chrome and safari currently but that is because the spec for the protocol is not finalised yet. Firefox, waiting for the spec to be finalised, will support it in Firefox 4 and IE … well… First impressions of websockts are that its is extremely easy to use and will be one of the prime uses for node.js apps. Writing your server and client in JS gives the feeling of just on complete library connected by passing JSON messages to each other.

I used the extremely simple ws.js on the server side and jquery.ws.js on the client side. If you want a bit more power and flexibility, check out Socket.IO which comes with its own client library.

Hope this cleared the air about a couple of these web dev buzz words and encourages you to look further into it. While writing this article a tweet from DHH brought this to my attention. Clearly there is a lot out there beyond the technologies out lined here and there are just current-popular implementations of philosophies and ideas that have been around for a while.

rxvl: The making of

Thu, 21 Oct 2010 06:13:00 +0530

I’ve been meaning for some time to write my own blogging engine and now that I finally got the time I went for it. It was meant to be a learning excercise so I tried to use tools and libraries that I’d never used before. I ended up chosing Sinatra for the framework to write it in with an SQLite DB and using DataMapper as the ORM. Also, I intended to host it on Heroku. In this article I’ve described everything from setting up my development environment for sinatra to finally deploying it on Heroku. Enjoy!

Setting up

Our first goal is to get a basic, “Hello World!” Sinatra app running with passenger and apache. You most probably have apache and passenger setup, so feel free to skip the next bit. For those who don’t, you should. Setting up passenger is the easiest thing. I’ve written about it here . Set up a VirtualHost to point to a directory named public in the directory where we’re going to have our sinatra app (/path/to/app/public). Create this empty directory. No special configuration is required in the apcache config file just treat it like a normal rails app. Now in /path/to/app lets create the sinatra app in the file app.rb. For a basic Hello World! application it’ll include something like this:

          get '/' do
            "Hello World!"
          end

Next we need the rackup file, Sinatra being a rack framework. This is my config.ru:

          require 'sinatra'
          require 'app.rb'
          root_dir= File.dirname(__FILE__)
          ENV['RACK_ENV'] ||= 'development'
          set :environment, ENV['RACK_ENV'].to_sym
          set :root, root_dir
          disable :run
          run Sinatra::Application

And that’s it. Point your browser to the ServerName that you’d specified in that VirtualHost config and you should see Hello World!

DataMapper

Now lets start writing the actual app. We start as with a normal rails app with the models. As you can imagine, we’d need a post model. You would also usually use a comments model but I want to use Disqus for my commenting system so I’ll demonstrate inter-model relationships with a category model. Post and Category have a has and belongs to many relationship. I’ll show you how to do that with DataMapper. So first the migrations. Create db directory and create the following migrations.rb file:

          DataMapper.setup(:default, ENV['DATABASE_URL'] || "sqlite3:///home/sapna/src/testing/db/datastore.sqlite3")
          class Post
           include DataMapper::Resource
           property :id, Serial
           property :title, String, :required => true
           property :slug, String
           property :file_name, String, :required => true
           property :created_at, DateTime
           has n, :categorizations
           has n, :categories, :through => :categorizations
          end
          class Category
           include DataMapper::Resource
           property :id, Serial
           property :name, String
           has n, :categorizations
           has n, :posts, :through => :categorizations
          end
          class Categorization
           include DataMapper::Resource
           property :id, Serial
          
           belongs_to :category
           belongs_to :post
          end

The explanation:

The first line defines the link to the database. I’ve used an sqlite database here. Setting up a connection to a mysql or postgres DB should be no different. the ENV[‘DATABASE_URL’] bit is for heroku. My local database is the datastore.sqlite3 file. Once this is delpoyed it’ll get the information of the DB URL from heroku. DataMapper::Resource is a module that you will have to include in all your model classes. Since the migration is the first time I’m defining the model class Post I’m including it there.

Next the property lines. These as you might have guessed are used to define the feilds of the post. Since I’m defining a blogging engine to read the post from a file rather than a database there are some differences between the design here and a conventional Post.

Note here that unlike ActiveRecord the id field isn’t automatically created for you you’ll have to define it with the type Serial. DataMapper takes care of the automatic updation of the field if its of type Serial. Now coming to the HABTM relationship. Category as you can see has only one field: name. Categorization is the mapping table. it has only one property which is the id. Now relationships are defined with the has and belongs_to methods. If you’d wanted to define a one to many relationship from post to category the post class would have

has n :categories

and the Category class would have

belongs_to :post

Extending the principle, you can see how what is shown above would work. This gives you Category.new.posts and Post.new.categories.

Stuff I learnt writing Rubycious

Mon, 04 Oct 2010 06:13:00 +0530

Day before yesterday, I released my del.icio.us API wrapper gem rubycious. There are a couple of things I learnt while writing it that I’d like to share here. To give you a heads up on what’s inside:

Meta-Programming
class_eval
self.included
method_missing
Documentation with YARD
Publishing a gem

If that’s piqued your curiousity click on through.

Meta-Programming

Before I go any further, I must warn you that some of the choices I’d made, design-wise weren’t exactly the smartest and I know that. But given those choices, I was faced with certain problems that had to be solved and I’m glad that it led me to learn about some cool Ruby meta-programming.

class_eval

This is a class method which any object of type Class has(by that I mean, of course, any ruby Class (Ain’t ruby grand!)). It takes a block and dynamically puts the contents of that block inside your class. Now this is only useful if you have to dynamically add stuff to your class. One oft-used use case of this facility is in conjunction with self.included. Trivially though the following should illustrate what class_eval can do

          class A
            def do_something
              something
            end
          end
          
          A.class_eval do
            def something
              puts "Hello World!"
            end
          end

Now there are a couple of other methods in the eval family, namely, instance_eval(1)(2), module_eval(just an alias for class_eval) and just eval(1). They’re equally cool and useful and to pretty much the same thing so I’ll leave it to you to discover more about them.

self.included

This is basically a call_back defined for any module. When it gets included in a class this method is run. The reason I’m calling it self.included is usually its usage goes something like this:

          module B
            def self.included(base)
              puts base.class
            end
          end

However the really interesting use case, like I mentioned earlier comes up when I put it together with class_eval like I did in Rubycious here. The module ClientHelper was meant to be included in any class that was a client and I didn’t want to redefine some of the httparty declarations in each of these classes.

method_missing

This one is pretty basic and chances are you probably know about this one. If not you really should. Basically method_missing is the method called when a method called on an object is not found. It takes a symbol which contains the name of the missing method and and array of the arcuments passed to that method. The great thing about method missing is that it can be used to generate an arbitrary number of methods. See more here

Documentation with YARD

YARD has emerged as the standard for documenting ruby projects of late, taking over from rdoc, and after using it to document rubycious, I can see why. YARD uses a tagging based approach to documentation. It uses directives like @param, @return, @see, @author etc. to structure your documentation and give nicely readable docs in a variety of formats. Read more about why you should use YARD here. Here is an example of code documented with YARD from rubycious:

                # Use for searching all URLs
                # NOTE: Use Sparingly. Call the update function to see if you need to fetch this at all.
                # @todo Look into caching these results
                # check the last update time before performing
                # @param [Hash] options for searching for the URL (all optional)
                # @option options [String] :tag |optional| "ruby"
                # @option options [String] :start |optional| Integer: Start returning posts this
                # many results into the set
                # @option options [String] :results |optional| Integer: Return these many results
                # @option options [String] :fromdt |optional| Format: Time#iso8601: On this date or later
                # @option options [String] :todt |optional| Format: Time#iso8601: On this date or earlier
                # @option options [String] :meta |optional| yes/no: Include change detection signatures
                # on each item in a 'meta' attribute. Clients wishing to maintain a
                # synchronized local store of bookmarks should retain the
                # value of this attribute - its value will change when any
                # significant field of the bookmark changes.
                # @return [Array<:post>]
                # @see Time#iso8601
                def find(options)
                  response= handle_errors { self.class.get('/all', :query => options)}
                  response["posts"]["post"].collect{|i| Rubycious::Post.new(i)}
                end

See more here

Publishing a Gem

I used echoe for packaging and releasing the gem. Basically echoe creates a bunch of rake tasks for you that take you through the process of creating a gem. So, first you need to define a couple of defaults in your Rakefile:

          require 'rubygems'
          require 'rake'
          require 'echoe'
          
          Echoe.new('rubycious', '0.1.1') do |p|
            p.description = "Ruby wrapper to the del.icio.us API"
            p.url = "http://github.com/rjsvlajean/rubycious"
            p.author = "Ratan Sebastian"
            p.email = "rjsvaljean@gmail.com"
            p.ignore_pattern = ["tmp/*", "script/*"]
            p.development_dependencies = ["httparty"]
          end
          
          Dir["/tmp/tasks/*.rake"].sort.each { |ext| load ext } e

Next assuming that all your code is in your lib directory and you have a file having the same name as your gem in there, run:

          $ rake manifest
          $ rake build_gemspec
          $ gem build rubycious-0.1.1.gemspec
          $ gem push rubycious-0.1.1.gem

And that’s about it for now. I plan on doing a rewrite with a bit of a better design soon but for now Rubycious is pretty stable for those using basic auth. I’ll add oauth support soon in a couple of days and I’ll document the procedure here.

vim tips

Wed, 22 Sep 2010 06:11:00 +0530

vim tips

So, I’ve been using vim for my ruby/rails dev of late and I thought I’d share a few things I picked up along the way. Another tool that I’ve begun relying on heavily is GNU screen. It didn’t make sense to put that in a separate post so I’m going to include some of my screen setup here as well. This is primarily aimed at people who’ve already begun with vim and are looking for examples of development setups.

The Tools:

vim

One of the core features of vim that you’ll find amazingly useful is the split screen. Incredibly useful when dealing with multiple files that you constantly have to refer to(while writing tests for instance). For more about some handy core features have a look at my .vimrc. Of course the real power of vim is in its amazing repository of plugins(advantage of being a nearly 20 year old project). Some of the ones that I find indispensible are:

rails.vim: The most basic plugin that you will need for rails development.
NERD_tree: File browser.
command-t: File finder
fugitive: git integration done right
specky: makes specs your friend again.
irb_slime.vim: For integrating irb and vim through screen

For my complete .vim folder clone git://github.com/rjsvaljean/vim_config.git

screen

GNU screen is one of those tools, that, once you’re exposed to will become essential to any sort of terminal intensive work that you do. I like to think of it as a window manager for your terminal. It basically hosts a bunch of terminals in different windows(tabs) and makes sure that you never have to Alt-Tab again. But of course its much more than that the killer feature is that ability to detach screen sessions. I do most of my development on a laptop which I almost never shutdown. So I’m working in my screen for project A, when I need to switch, I don’t need to worry about shutting down the various programs safely. I just need to detach the session and re-attach when I need it. This way I get back to work with no interuptions. It nicely allows you to keep all the terminal based programs that you run with a particular project in one place.

Bringing it all together

As I’d put in the list of plugins this ties vim, irb and screen together nicely. Next master fugitive(which is alarmingly simple to use) and you’ve got SCM integration in your editor. Its starting to look more like an IDE, isn’t it? Now sugar coat the whole deal by opening vim up in your project directory within a screen session. But of course development seldom involves just your editor so go ahead and open a bung of windows for your REPL, your test running window, IRC client etc. etc. But you don’t want ot keep repeating this every time you start a screen session of a different project. What I do is create a project specific .screenrc which in my project root directory with a bunch of screen -t declarations to open the windows that I need for that project and add an alias to my ~/.bashrc. Something like:

alias work="screen -c .screenrc"

This I find works pretty well. Additionally the irb_slime plugin I’d mentioned eariler requires you to specify the screen session name and the name of the window where your REPL is running. You only have to do this the first time but its still pretty annoying. To automate things further do the following in your .screerc

          screen -t vim 0 vim -c 'let g:screen_sessionname=session'\
          -c 'let g:screen_windowname=repl'

That makes sure that once you execute work in your project directory you’re all ready to start hacking.

Hope this helps!

passenger + apache + NameVirtualHosts

Thu, 09 Sep 2010 06:10:00 +0530

Everyone knows how to setup passenger and apache on a linux box. But if you have multiple apps, its a pain keeping track of all the localhost port numbers that point to each of them. In this article I discuss you can have addresses like myapp.mybox.lan to point ot specific apps. I’ve written this for a linux system but it should work just as well for a Mac. Also, I haven’t tried this out with ngnix. I’ve also gone through the setting up of Passenger for those of you who still use script/server.

Setting up Passenger

Installing the passenger apache modules is as easy as:

          $ gem install passenger
          $ passenger-install-apache2-module

That will download and compile passenger’s apache modules. Once compiled the installer will give you instructions to load these modules using apache configuration directives. You’ll probably have to edit your apache configuration file for that. If you’re on linux, these will probably be in /etc/apache2/[apache2.conf|httpd.conf]. Just append the three lines that the installer gives you to this file. They’ll look something like this:

          LoadModule passenger_module /home/rjsvaljean/dev/ruby/lib/ruby/gems/1.8/gems/passenger-2.2.11/ext/apache2/mod_passenger.so
          PassengerRoot /home/rjsvaljean/dev/ruby/lib/ruby/gems/1.8/gems/passenger-2.2.11
          PassengerRuby /home/rjsvaljean/dev/ruby/bin/ruby

Creating the domains

Once that’s done lets create our rails app in /path/to/app/blog. In order to demonstrate how to create different addresses for different apps create another app at /path/to/app/todolist. Say that we want those two apps accessible at blog.lan and todolist.lan. Notice that I’ve use the TLD .lan but that’s completely aribitrary. You can use anything that you want. Now comes the bit where we tell your computer to got to localhost when you point your browser to blog.lan. For this we need to edit our /etc/hosts file. You’ll need to be root to edit it. Add the following two lines:

          127.0.0.1    blog.lan
          127.0.0.1    todolist.lan

Creating ‘NameVirtualHost’s

Now we need to instruct apache where to look when it gets a request for blog.lan. Open up the config file once more. First you need to declare that Named VirtualHosts are running on post 80 - your default port for http requests. To do that:

NameVirtualHost *:80

Now define your VirtualHost sections:

          <VirtualHost *:80>
            ServerName blog.lan
            DocumentRoot /path/to/app/blog/public
          </VirtualHost>
          <VirtualHost *:80>
            ServerName todolist.lan
            DocumentRoot /path/to/app/todolist/public
          </VirtualHost>

Now reload apache with ‘/etc/init.d/apache2 reload’ and you’re done. Pointing your browser to blog.lan or todolist.lan whould show you the default rails page for a new app.

Some notes on cron, whenever and rake

Fri, 06 Aug 2010 06:09:00 +0530

I recently had to set up some cron jobs from an app that I was writing. I learned a couple of things so I thought I’d put them here. I’ve covered setting up precisely fortnightly cron jobs, setting up the whenever gem and how I tackled some of the errors that I came up against while trying to set it up.

Fortnightly Jobs

Setting up precisely fortnightly jobs that need to run on every other monday is quite easy. You don’t have to settle for just running the jobs on the 1st and the 15th. Set your job to run onw whichever day of the week that you want it to and set it to run every week. Include this in the actual command to be run:

expr `date +\%W` \% 2 > /dev/null || fortnightly_script.sh

Whenever

Whenever( github link ) is a nifty gem that you can use to modify your crontab easily from your application using some sort of capistrano recipie of rake task. First off install the gem with

          $ gem install whenever
          $ wheneverize  # Excute this inside your app to setup the necessary files

Now edit the schedule.rb file where you can easily define your jobs in plain ruby. Now you can run the binary whenever —update-crontab to update your crontab cleanly from your capistrano recipies. When I tried to run the command however I ran into some difficulties. Read on …

Error: Rakefile: undefined method `importâ€™ for main:Object (NoMethodError)

I ran into this error while trying to use the whenever gem in my app. Whenever I tried to run the whenever command I got this error:

          ./Rakefile:3: undefined method `import' for main:Object (NoMethodError)
          from /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/whenever-0.4.1/lib/whenever.rb:5:in `load'
          from /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/whenever-0.4.1/lib/whenever.rb:5
          from /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'
          from /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require'
          from /opt/ruby-enterprise-1.8.7-2009.10/lib/ruby/gems/1.8/gems/whenever-0.4.1/bin/whenever:7
          from /opt/ruby-enterprise-1.8.7-2009.10/bin/whenever:19:in `load'
          from /opt/ruby-enterprise-1.8.7-2009.10/bin/whenever:19'''''

I fixed this by adding

require 'rake'

at the beginning of my Rakefile. I’m still not sure what exactly the problem was and how that line solved it. Maybe some of you more knowledgeable netizens could clear it up.