Tech-Angels

We’re looking for (passionate) SysAdmin to join our existing team. You will be in charge of managing servers remotely with ssh and puppet.

Read More

We’re looking for (passionate) Ruby / Ruby on Rails developers to join our existing team. We work mostly with recent Rails versions, haml, sass/scss, jQuery, Redis and PostgreSQL.

Read More

We’ve just released TcpSyslog 1.0.0 gem. TcpSyslog is rails logger using syslog with TCP instead of UPD. This gem should be used in large apps, where a central syslog server is available using TCP, and no syslog server is present on the local node.

(image credits : lamenta3)

Weird enough, the default syslog librairy (ie: Syslog) doesn’t allow to sent logs to a distant server. Instead, localhost must be used, and the local syslog server will forward the message to a central server.

Anyhow, in some cases, there’s no local syslog server, or you might have to send your messages directly to that central position. In the cloud, that’s a lot of syslog servers you won’t have to monitor.

Here it comes, you can find the TcpSyslog for rails here. It was inspired from SyslogLogger and ActiveSupport::BufferedLogger. In fact, TcpSyslog will act exactly as a BufferedLogger, except messages are sent over TCP/IP (only for now) to syslog.

We’ll release a gem soon, stay tuned.

Irb, the interactive Ruby shell should be the Ruby developer’s best friend.

Anyway, with a few customization, we can still improve this tool. First, you will notice the backward search won’t work out of the box on Mac OS X. This is an issue with readline.

To fix this, add this to your ~/.editrc file :

bind "^R" em-inc-search-prev

Now you may use CTRL-R to Reverse-search your history.

Also, you may want to give a try to Wirble, which is used to colorize your IRB output.

At tech-angels, we also use Hirb to format the ActiveRecord outputs.

Finally, this is a common .irbrc file :

require 'rubygems'
require 'wirble'
require 'hirb'
Wirble.init
Wirble.colorize
# hirb (active record output format in table)
Hirb::View.enable

# IRB Options
IRB.conf[:AUTO_INDENT] = true
IRB.conf[:SAVE_HISTORY] = 1000
IRB.conf[:EVAL_HISTORY] = 200

# Log to STDOUT if in Rails
if ENV.include?('RAILS_ENV') && !Object.const_defined?('RAILS_DEFAULT_LOGGER')
  require 'logger'
  RAILS_DEFAULT_LOGGER = Logger.new(STDOUT)
  #IRB.conf[:USE_READLINE] = true

  # Display the RAILS ENV in the prompt
  # ie : [Development]>> 
  IRB.conf[:PROMPT][:CUSTOM] = {
   :PROMPT_N => "[#{ENV["RAILS_ENV"].capitalize}]>> ",
   :PROMPT_I => "[#{ENV["RAILS_ENV"].capitalize}]>> ",
   :PROMPT_S => nil,
   :PROMPT_C => "?> ",
   :RETURN => "=> %s\n"
   }
  # Set default prompt
  IRB.conf[:PROMPT_MODE] = :CUSTOM
end

# We can also define convenient methods (credits go to thoughtbot)
def me
  User.find_by_email("me@gmail.com")
end

Rails migrations are great. They allow to migrate and rollback, and maintain the DB in a consistent state. Thanks to Rails DSL (+ some plugins like rails_on_pg), they are even easy to read and write. Fine.

Enters our beloved friend language SQL. Whilst views (or functions, or whatever) creation is made easy, updating existing code can become a real nightmare, especially with long and complex queries.

Let’s illustrate our problem :

In a rails app, I’d like to create a view for confirmed users. Let’s leave rails_on_pg plugin for now, but the problem would be exactly the same. (Note: examples bellow are based on rails 2.3, they would be a little different in rails 3, but the problem is still there).

script/generate migration create_confirmed_user_view

In the migration file, you would add your code as :

Right, now your run your migration process :

rake db:migrate

and everything goes fine.

Later, you realize that the view was incorrect, you should have filtered also on the disabled boolean column. Now the migration will be something more :

Here comes the problem. You have to copy / paste your previous definition in the migration, each time you want to update a view or a function.

In this example, our view is 2 lines only. With a big fancy function of 20 lines, you won’t be able to notice differences easily (or at all).

Enters Git

To solve our problem, we can create a sql folder in our project tree, and put all functions and complex queries in there.

Now we can write our first implementation of the confirmed_users view :

Add the file to git :

git add sql/confirmed_users_view.sql

And commit it :

git ci

The file has been “saved” in git, at least in its original version. We can easily use git to manage the history of the file. Do your changes, and commit the file again (you know, git add, git ci).

Let’s spice up our migration now. First, grab the last commit ids from git :

git log --oneline -n 2

2d308a6 Update view confirmed users
1596b6d Create view confirmed users

We can use these 2 ids in our migration :

Migration files will be certainly harder to read, but you get a valuable tool with git diff :

git diff -p 2d308a6

[...]
CREATE OR REPLACE VIEW confirmed_user AS
-  SELECT * FROM users WHERE confirmed_at IS NOT NULL;
+  SELECT * FROM users WHERE confirmed_at IS NOT NULL
+  AND disabled IS FALSE;

Of course, this implies you have Git installed on your production servers, but why won’t you ? Especially if you’re using capistrano.

If you’re using Ack grep command in a Rails project, you’ll notice all haml views aren’t taken into account. This is because the haml file pattern is not recognized by Ack.

To fix this, simply create a ~/.ackrc file and add :

--type-add=ruby=.haml,.rake,.rsel

This subject is really not very often highlighted in rails security docs, even in the official guide.

We’re often happy with the basic cookie store options :

Anyway, secure websites (like e-commerce sites) must include some more secure options. Cookies have two attributes people usually don’t use :

• Secure : “A server can specify thesecure flag while setting a cookie; the browser will then send it only over a secure channel, such as an SSL connection.”
• Expires : “Cookies expire, and are therefore not sent by the browser to the server, under any of these conditions: […] An expiration date has been specified, and has passed.”

(Definition taken from Wikipedia)

The last means the session AND the cookie will expire after the given date. It’s generally a good idea to set this option, unless you’re running facebook.com, people won’t spend more than 1 hour on you site per day.

To enable these 2 options, you can use the configuration in config/environment.rb :

You should set the secure option per environment, otherwise your dev environment will fail. To do so, you can add a line in each secure environment :