The Dev Blog

How I learned to Love vim and Ditched Eclipse

Posted by Guy Naor Thu, 08 Mar 2007 13:03:00 GMT

For the longest time, since starting to work with Ruby and Rails, I used Eclipse with RadRails and RDT for coding. It's a pretty good IDE as far as IDEs go, and has nice Ruby/Rails tools to make development a lot easier. It also has a VERY nice subversion interface. One of the best I've seen as far as working the way I like to work.

On the down-side, it's a performance hog and the editor itself is so-so in features.

As I also do system admin chores on remote computers, I always use vi as well. And for many quick and dirty tasks, I use it even localy. Developing on a Linux machine, I always have some terminal windows open. Slowly I was pulled to do more things with vim, until I realized I prefer being in it than in Eclipse. Now I spend 90% of my time in vi, and most of my projects never even see Eclipse.

Why did I switch? First and foremost vi as an editor is really good. And lets keep the vi/emacs wars for another time. I'm sure emacs is a really good editor as well. I just have to choose my tools. Can't use all of them. Second thing is speed. I NEVER have to wait for vi. It's always super fast and super responsive.

But to make vi really useful with ruby and rails, some additions are needed. After all, I want synax highlighting, macros, easy way to open files, etc... So here is a list of vim scripts/plugins I use and recommed:

rails.vim, eruby.vim, ruby-macros.vim, rubycomplete.vim

There are many more additions and plugins on the vim site. Please note that some require the newer vim 7 to work.

Another option is getting the rails-vim gem: sudo gem install vim-ruby. Please note you have to then run the vim-ruby-install.rb script to complete installation.

So now that we have vim loaded with the additions, where do we start? Granted, the learning curve is steep! And don't get me started on using the esc key so much, that I keep doing it in Eclipse ;-). But as the editor is our main tool of work, learning it pays for itself later with productivity. vim has a lot of help written for it, and you can access it from within vim, but I prefer browsing it on the internet. So start with this short tutorial, and then bookmark the main help file. And for the rails related parts, take a look here. Some of the things it does are just awesome. I open files faster with :Rfind than on a tree in the IDE browser! And check out the partial extraction. That one is unbelievable.

vim also has the GUI version in gvim. And there you can open multiple tabs and have an IDE like file browser. Use that if you are more comfortable with the mouse and a real GUI. It's also easier to stasrt with as it has menus for the more common commands.

One thing I did that really got me into more advanced editing, is deciding that whenever I want to do something, and I don't know how to best do it, I stop resorting to hacking a solution with the things I know, and look for the real solution. In a few short weeks I learned more than in the last 5 years...

So give vi a try. Give yourself some learning time, and you'll never look back!

BTW, I also use svn from the command line. I'ts so much faster than from Eclipse that I don't mind the few keystrokes it takes to get things done. It's so much faster!

Posted in Rails, Ruby, Programming, Linux | 41 comments

libical + ruby + linux = nirvana

Posted by Guy Naor Thu, 22 Feb 2007 13:25:00 GMT

We have a need for strong ical support in Famundo, and unfortunately all the ruby libraries for handling ical are nowhere near complete. A really great alternative is to use the well used and tested libical. This requires a wrapper that will let ruby use it, and the simplest way to do that, is to use SWIG to generate the wrapper, then compile it into an extension ruby can use.

Lucky for me, Rob Kaufman in this post contributed most of what's needed to get it going with SWIG. But it won't work on Linux. It seems it was compiled on a Mac, and trying to compile it on Linux just won't work.

Lucky for you, I have here the steps to make it compile on Linux (and probably any other system that supports the standard make tools). So lets jump right into the instructions.

1. Get the latest libical files and the zip file attached to Rob's post. You will also need to get the latest SWIG if it's not yet installed on your system.

2. Compile and install libical:

    tar tar xif libical-0.26-6.aurore.tar.bz2
    cd libical-0.26
    ./configure # you can run ./configure --help to see more options  
    make
    sudo make install 

3. Extract the files of the ruby SWIG based wrapper:

    unzip libical-ruby.zip
    cd libical-ruby/swig/
    make clean

4. Create an extconf.rb file to generate the makefile. The file should have the following in it:

    require 'mkmf'

    have_library("pthread")
    have_library("ical", "icaltime_null_time")
    have_library("icalss", "icalset_new_dir")

    create_makefile('LibicalWrap')

5. Generate the needed wrapper file using swig: swig -ruby -o LibicalWrap.c ical.i

6. Run: ruby extconf.rb This should generate the needed Makefile. If it fails, you might not have the libraries from libical installed correctly. If that is the case, redo step 2 above, but use the ./configure command with different parameters, to point it to the correct lib directory. For example, on 64bit FC4, you might want to try with this:

./configure --libdir=/usr/lib64 --includedir=/usr/include

7. Compile and install the wrapper:

    make clean
    make 
    sudo make install

8. We're done. You can now launch irb and type include 'LibicalWrap', and you are ready to go. With the libical-ruby.zip file, there are also some tests you can run on it to see if it works. And some ruby helpers to facilitate working with the library, as the library is C based, and so doesn't have nice class representations for ical objects.

Now that we have a good ical library, time to start using it. But that's outside the scope of this post.

Let me know if you have problems getting it to work. I'll be glad to help.

Posted in Rails, Ruby, Linux | 2 comments

AjaxScasffold, Security and Deployment Problems in Rails

Posted by Guy Naor Wed, 17 Jan 2007 23:05:28 GMT

AjaxScaffold was already mentioned in my previous post, so no need to sing it's praise again...

While deploying the Famundo help to my staging server, it stopped working, not even leaving a single clue in the logs. For me this is always a sign that something isn't initializing correctly. So it was time for a small investigation.

After playing a bit with the code, I realized the problem is caused by init.rb in AjaxScaffold trying to copy it's files into the application main directories. The reason this is a problem is my desire to make the system as secure as possible. Part of that is not letting the user the application runs as, write access into the application directory. This prevents a bug or breakin from writing into the application directories, reducing the damage that can be caused. The user running the application has only read access to the application directories.

Time to fix AjaxScaffold. First of all, I don't think that in production mode those files need to be copied over. It's done in development mode, and then are there for production mode. I do think it's a nice thing for development mode as it allows easy upgrade to a new AjaxScaffold version. Second, an error like that shouldn't kill the application with no explanation.

So my fix just adds an if around the copy and skip it in production mode, and also surounds it with begin/rescue/end, logging the error if one happens.

I also opened a ticket in the AjaxScaffold bug database, and I'll try to find who to email this to. For now, just take this file and replace your init.rb with it, or just copy the changes.

NOTE: The edge code of AjaxScaffold plugin moved the file copy to install.rb, so you'll have to change that file instead.

# Include hook code here
require 'ajax_scaffold_plugin'

ActionController::Base.send(:include, AjaxScaffold)
ActionView::Base.send(:include, AjaxScaffold::Helper)

# copy all the files over to the main rails app, want to avoid .svn
# Do not copy in production mode!!! And catch errors and log them
if ENV['RAILS_ENV'] != 'production'
  begin
    source = File.join(directory,'/app/views/ajax_scaffold')
    dest = File.join(RAILS_ROOT, '/app/views/ajax_scaffold')
    FileUtils.mkdir(dest) unless File.exist?(dest)
    FileUtils.cp_r(Dir.glob(source+'/*.*'), dest)

    source = File.join(directory,'/public')
    dest = RAILS_ROOT + '/public'
    FileUtils.cp_r(Dir.glob(source+'/*.*'), dest)

    source = File.join(directory,'/public/stylesheets')
    dest = RAILS_ROOT + '/public/stylesheets'
    FileUtils.cp_r(Dir.glob(source+'/*.*'), dest)

    source = File.join(directory,'/public/javascripts')
    dest = RAILS_ROOT + '/public/javascripts'
    FileUtils.cp_r(Dir.glob(source+'/*.*'), dest)

    source = File.join(directory,'/public/images')
    dest = RAILS_ROOT + '/public/images'
    FileUtils.cp_r(Dir.glob(source+'/*.*'), dest)
  rescue Exception => ex
    RAILS_DEFAULT_LOGGER.error "AjaxScaffold error while copying the AjaxScaffold files to the application directory. (#{ex.t_s})"
  end
end

Posted in Rails, Ruby, Linux | no comments

Rotating the Rails logs with FastCGI

Posted by Guy Naor Fri, 23 Jun 2006 15:47:00 GMT

Deploying a rails app will eventually lead to the need to manage the rails log files. They get pretty big fast, and if the log level also include the SQL queries, they grow EXTREMLY fast.

Though there is some information about it in the Rails Wiki, it's missing restarting the FastCGI processes. If you are using dynamicaly launched FastCGI processes from lighty or apache, the web server log rotation will restart the FastCGI processes and you will be covered. But if you are using FastCGI processes you launch (using spinner/spawner or a similar solution) the log file will be rotated, but the newly created log file won't be used by the ruby app until it is restarted.

Here is my logrotate configuration:

# Assume the the rails app is installed to /app/my_blog/current
# And that the user we running the app with is called rails
/app/my_blog/current/log/*.log {
  daily
  missingok
  rotate 7
  compress
  delaycompress
  notifempty
  create 0660 rails rails
  postrotate
     /app/my_blog/current/script/process/reaper -a graceful -d /app/my_blog/current/public/dispatch.fcgi 1>/dev/null 2>&1 || true
  endscript
}

The main change from the rails wiki version is the postrotate call that causes the fastCGI processes to restart and reopen the log file.

Posted in lighttpd, Rails, Linux | no comments | no trackbacks

Capistrano (aka SwitchTower) and security

Posted by Guy Naor Mon, 06 Mar 2006 12:40:00 GMT

You already know I ABSOLUTELY love Capistrano (well, I do prefer SwitchTower as a name...). I also count security as a critical component in any production system (and no, having a firewall doesn't count as security). So to make sure I can comfortably use it in production, I had to make some security adjustment on the machines I deploy to.

Some important requirments:

1. The web server should only have read access to the absolute minimum it really needs. In my case, as I'm using FastCGI processes launched from outside the server, only the public directory needs to be readable by it.
2. The deployment user (set :user "deployer" in deploy.rb) should be a distinct user and should be the only one with write privileges to the rails application directory.
3. The rails application runner will be itself a distinct user with only read access to the rails application.
4. All other users can't even read the deployment directories.
5. The deployment user can run as root using sudo only the minimum number of things like restarting the web server, or changing configuration.

To satisfy those requirement I created 2 users - one to deploy and one to run the rails application. I then set the privileges on the files (using chmod) so that the runner can read everything in the rails app directories and write just to the log directory. And the web server can read only the public directory. Then I edited the sudoers file (use visudo and direct editing to catch syntax errors) and allowed the deployment user rights to launch/stop/reload the web server, and to copy some configuration files. Note that it can't write to the files. It can just copy them from one specific location to another. It's risky letting someone to sudo run shell scripts, as then they can do anything like root. Here's a piece of my sudoers file:

Cmnd_Alias      CP_LIGHTY_CONF = \
    /bin/cp  /etc/lighthttpd/maintenance.conf /etc/lighttpd/lighttpd.conf, \
    /bin/cp /etc/lighttpd/application.conf /etc/lighttpd/lighttpd.conf, \
    /etc/init.d/lighttpd

deployer    localhost = CP_LIGHTY_CONF

This gives the deployer user the rights to copy the config files around, but not to ever write to them. So that the admin on the box set them as needed, but the deployer can change them as needed.

Please note that this is only one layer of the security. Just like the firewall is just a single layer. When planning a deployment, think of security as a layered mechanism, adding more and more layers (firewalls, host firewalls, privileges, monitoring, IDS, SELinux, etc...).

Posted in Rails, Linux | no comments | no trackbacks

And So It Starts

Posted by Guy Naor Sat, 28 Jan 2006 20:44:00 GMT

It wasn't too long ago that my main development language was C++ on Windows. But when I decided I want to do web development, this just plain didn't make sense. Enter Ruby and Rails!

I was on a search for a good web development environment, and looked at many of the options available, but none seemed to meet my requirements. Java was too heavy (I did do Java development in the past, but that was long ago), I didn't like the then available Python stacks and I really dislike all the .NET stuff. Call it too many years on Windows, or a dislike to proprietary systems, but I just won't touch it.

While searching, I stumbled upon RubyOnRails. I was weary of all the promises I read about it, but playing with it a bit proved me wrong. What a refreshing surprise!!!

Then came the need to do a 180 degree turn in my head. From the strict mindset of C++ to the "crazy" way Ruby and the other dynamic languages do things. I had no prior Ruby experience, so it required lots of learning. Luckily I had lots of experience with Linux and all related technologies, so this part was taken care of.

A few weeks after starting learning, I switched my dev environment from Visual Studio on Windows to Eclipse on Fedora Core 4 (past experience with RedHat made it my choice), and I can't be happier :-).

Some dev choices I have made so far:

• OS - Linux FC4
• IDE - Eclipse with RadRails
• Source control - Subversion
• Database - PostgreSQL

Come visit this blog for some development ideas and solutions related to my new development journey. And for details as I take an amazing new application online.

Posted in Rails, Ruby, Postgres, Linux | no comments | no trackbacks