Late night capistrano

Excerpt from my current Capistrano cheat sheet:

cap deploy_with_migrations
- will deploy normally and then run 'rake db:migrate' (SCARY!)
- 'cap disable_web' (FIRST!)
- WILL NOT RUN ANY :after_deploy methods (FUCK!)

Now don’t get me wrong, I really love Capistrano (now at 1.4) as it makes my development life a lot easier. It’s just those little bits that bite you in the ass in the most unexpected moment.

Oh, and I’m sure there’s a reasonable explanation for this behaviour.

UPDATE: It has its own ticket now.

Express Kaszubski – my second public Rails app

Express Kaszubski, a local Kaszubian (that’s in Poland) newspaper has just recently decided to stop releasing its printed edition and move entirely to the web. It was my honour to accompany during this move. The online edition took about a month to create. It’s just a basic website at the moment. No comments, no RSS feeds, although the CMS behind the scenes is quite powerful. All in Rails, of course.

Here is the snippet:

Express Kaszubski

And if you haven’t noticed by now, it’s all in Polish.

Kania Lodge – my first public Rails project

To be honest, I’ve been a Rails programmer/enthusiast for quite a while now (something along 1.5 years; I think I’ve first downloaded it in July, 2005) but it’s only now that I can show you my first public project using this awesome framework. So without further ado, here it is, the Kania Lodge:

Kania Lodge

The Rails part on this website is the custom CMS that is backing it all up (based on RedCloth). Most of the hard work was with the design, though (Photoshop, etc.). I know it is a hardly original design as I’m not a full-time designer, yet I’ve done my best for it to look good. I’ve aimed for simplicity, cleanliness and good overall feel/aesthetics. Did I miss or am I right on the spot? :)

Yet another anti-PHP rant

I’m quite surprised to see this great stir in the blogosphere caused by Tim Bray and his essay On PHP. I mean, what’s the deal anyway? We all know that PHP is a lousy programming language. So instead on focusing on the big picture and trying to list as many of its faults as I can remember, I’ll stay on one specific problem, which is really a pain for me.

I’ve been programming in PHP for the past five years (I’ve started using it in the beginning of 2001, during my Computer Science studies). PHP is (was?) both my love and hate. My biggest complain about it, and probably about all other programming languages used for web development, is that there is no decent way of producing HTML code from your application. No matter how hard you try, you’ll always end up having spaghetti either in your HTML or in PHP code (or even worse, in both places). Sure, separating business from presentation logic is a common practice which helps the cause (apart from the fact that most PHP folks mix HTML with PHP whenever and wherever they can). Problem is, that it’s not good enough.

It would be all much simpler if you didn’t need to put any logic into your presentation code. The moment you introduce loops or conditionals – bam – you either get unreadable code or spaghetti HTML with way too much whitespace (or without any whitespace at all) and improper indentation. Not to mention that I am probably not the only one sick of typing all those nasty angle brackets all the time. But what about all that specialized templating engines? Frankly, they are not any better. Besides the fact that some of them require a certain overhead (like defining the variables you wish to use in your templates – Smarty, anyone?), they all still carry the same burden – they either produce spaghetti HTML or have spaghetti templates.

Actually, Rails, being my current weapon of choice, is no better in this area. My .rhtml templates are a complete mess. I strive to have my HTML as pretty as it can be, because (maybe strangely) I find it easier to debug if I have a nice HTML output to deal with, instead of a nice .rhtml template. Too bad that I feel utter disgust when I look at those templates. And just as Smarty is no better for PHP, Liquid and similar projects are no better for Rails. However, there is still hope, with projects like Markaby (which, unfortunately, has its own issues, check the comments).

Just a small digression, to sum all this up. Rails has solved one other, big inconvenience, namely writing your own SQL for each and every interaction with the database. Thanks to ORM provided by ActiveRecord, you don’t have to write SQL any more (at least in most of the cases; the 80/20 rule). This is one of the basic reasons that Rails is so much better than PHP. Markaby tries to do the same to HTML, what ActiveRecord did to SQL. No more those nasty < /> characters! We’ll see how (and where) it goes.

Custom HTTPS POST queries in Ruby

Complementing both the manual for the Net::HTTP class and Rail’s guide to rendering proxied pages (from the Rails wiki) here is a short script, which makes use of a custom made HTTPS POST query (btw. HTTP POST is basically the same, you just have to remove the ssl declaration and change the destination port).

First, the script makes a GET query to the target host (in the example, it is the login page for Wirtualna Polska webmail). In the next step it reads which cookies the website wants to set. After that, we can make our POST query. We send both filled in POST parameters (and hidden inputs too) and all of the cookies, which would normally be set in the browser. After that the script just prints out response headers and data (if there’s any).

The solution is simple, short and clean, although it took me few hours to find out that POST parameters must be a &-separated string and that the headers is a hash array. After that, it was a piece of cake.

Anyway, here’s the script:

#!/usr/bin/ruby

require 'net/http'
require 'net/https'

http = Net::HTTP.new('profil.wp.pl', 443)
http.use_ssl = true
path = '/login.html'

# GET request -> so the host can set his cookies
resp, data = http.get(path, nil)
cookie = resp.response['set-cookie']


# POST request -> logging in
data = 'serwis=wp.pl&url=profil.html&tryLogin=1&countTest=1&logowaniessl=1&login_username=blah&login_password=blah'
headers = {
  'Cookie' => cookie,
  'Referer' => 'http://profil.wp.pl/login.html',
  'Content-Type' => 'application/x-www-form-urlencoded'
}

resp, data = http.post(path, data, headers)


# Output on the screen -> we should get either a 302 redirect (after a successful login) or an error page
puts 'Code = ' + resp.code
puts 'Message = ' + resp.message
resp.each {|key, val| puts key + ' = ' + val}
puts data

Installing Ruby on Rails on Ubuntu

This guide is valid for the following distributions:

Ruby on Rails

While there is a nice tutorial in the Ruby on Rails wiki, it’s by no means complete. According to it, you should only type: apt-get install rails to have the newest Rails installed on Ubuntu. It installs both Ruby and Rails, but what about rubygems? Sorry, not this time. There is also another caveat. Although commands like rails test and ruby script/server are working properly, ruby/console is not. If you had the misfortune of experiencing the aforementioned behavior, then this tutorial is just for you.

Pre requirements:

nano /etc/apt/sources.list

Add the following at the end of the file (replace edgy with breezy if you are running Breezy, dapper for Dapper, etc.):

# All Ubuntu repositories
deb http://archive.ubuntu.com/ubuntu edgy main restricted universe multiverse

Update your apt sources:

apt-get update

Installation:

Install Ruby with developer’s libraries:

apt-get install ruby ri rdoc irb ri1.8 ruby1.8-dev libzlib-ruby zlib1g

Download and install Ruby Gems (no .deb package, unfortunately):

wget http://rubyforge.org/frs/download.php/17190/rubygems-0.9.2.tgz
tar xfvz rubygems-0.9.2.tgz
cd rubygems-0.9.2
ruby setup.rb

Update your RubyGems (also updates the gems cache):

gem update --system

If you get Could not find rubygems-update (> 0) in the repository or a similar error, you need to delete your RubyGems cache:

$ gem env gemdir
PATH_TO_DEFAULT_GEM_REPOSITORY
$ rm PATH_TO_DEFAULT_GEM_REPOSITORY/souce_cache

and

rm $HOME/.gem/source_cache

In the next step install the OpenSSL bindings for Ruby (needed to install signed gems). They are required if you get the following error: SSL is not installed on this system, while installing signed gems like rake:

apt-get install libopenssl-ruby

And the last one:

gem install rails -y

And this is basically it. There are, however, depending on your needs, some…

Additional steps:

One of them is setting up the Rails to connect to the MySQL database in a proper way. We will be using the MySQL C bindings, which, for one, support the MySQL old style passwords (which is set as default for Ubuntu 5.04), but are also significantly faster (in the 2-3x range) than the native Ruby MySQL bindings. First, we will need to install the gcc compiler (and libc6-dev if you don’t have it already installed). Although strange it may seem, as a default it is not installed on a clean Ubuntu installation.

apt-get install gcc libc6-dev

MySQL development libraries are also required (mysql_config plus mysql/include):

apt-get install libmysqlclient14-dev

(for MySQL 5.0 you might be better of with libmysqlclient15-dev).

And now we can install C MySQL bindings:

gem install mysql

If you get "sh: make: not found" do:

apt-get install make

or if you have it already installed, add it to your path:

export PATH=/usr/bin:"${PATH}"

And, of course, in the end install Mongrel:

gem install mongrel -y

And that’s it. Rails installation is complete. Complicated? Not really :) Happy coding!

Rails 0.13 released

Quoting David Heinemeier Hansson: with so much new stuff in there it’s not even funny. I suppose I just need to bang my head against the wall a few more times, first, to receive a little bit of motivation to finally finish the fourth day of Four Days on Rails and second, to receive a little bit of inspiration to develop a useful (at least for me, for a start) Rails application that has a little bit more of code apart from scaffold

Here’s the official announcement.

Rolling with Ruby on Rails on Dreamhost

As of yet it is unofficial, but Dreamhost has indeed added support for Ruby on Rails (v0.12.1) together with FastCGI!

I have just tested it briefly and it works as it is supposed to.

If you want to turn FastCGI on, you must log in into your Dreamhost panel and go to Domains -> Web. Single checkbox and FastCGI is enabled. Couldn’t be simpler.

Dreamhost, regarded by many as the hosting company is indeed staying on the cutting edge, being the first major player to support Rails.

UPDATE: It’s now official.

(via)