Checkvist Pro plan

After a long silence, we've finally released Checkvist Pro plan. The detailed post about this is available.

With this release, I've also upgraded Rails to the version 2.3.3 and migrated Mysql database from MyISAM to InnoDB engine (because we've had problems with data consistency when transactions were interrupted).

So far so good, performance haven't become worse. And I'm pretty satisfied with upgrade of the app engine from mongrel cluster to Nginx Passenger.

Now will focus on the daily work and on adding more features to Checkvist.

Migration of Checkvist to Rails 2.3

I decided to migrate Checkvist to new and fresh Rails 2.3 (or 2.3.2, to be more specific).

I cannot say I really need features from 2.3, but I think it worth using the latest release (especially given that I already had to patch my Rails 2.2.2 installation to remove some bugs from it).

As usual, the migration turns to be an adventure:

• Change all tests which extend Test::Unit::TestCase and use fixtures with ActiveSupport::TestCase
  
• Many test failures were fixed by adding self.use_transactional_fixtures = false to test_helper.rb
  
• Fixed tests with cookies (see a good post with the explanation)
  
• Faced a bug with cookie escaping in tests. This bug is not fixed in 2.3.2, so some tests are failing unless edge 2.3.x is used.
  
• DEPRECATION: formatted_ paths had to be replaced. Replaced.
  
• DEPRECATION: session.delete => session.clear
  
• DEPRECATION: session.session_id => request.session_options[:id] (faced another already fixed bug)
  

Some of these issues are described in Rails 2.3 change log. And some (like bugs ;) are not.

So now, tests are successful again (for the latest 2.3 branch). But I'm not going to update production yet, will do some more testing. And, probably, wait for 2.3.3.

Monit start/stop problem from the command line

Monit is a great tool to monitor various UNIX-like services and to take appropriate actions when they fail. And I've been using it with a great success to monitor Checkvist server. But, as with any tool, there are some issues.

I've spent some noticeable time trying to figure out why monit's command line actions do not work. All of the start, stop, restart actions did nothing. Monit's log didn't contain any trace of my attempts to change state of services.

After some browsing and googling and reading docs I've found the reason of the problem: I've enabled HTTP access to monit only in read-only mode, like this:

set httpd port 3111
    allow   user:user read-only

And that was the problem. For command line commands to work, the first 'allow' line must not contain 'read-only' option!
This is written in the Monit docs, but not in FAQ:

NB! a Monit client will use the first username:password pair in an allow list and you should not define the first user as a read-only user. If you do, Monit console commands will not work.
...
If the Monit command line interface is being used, at least one cleartext password is necessary. Otherwise, the Monit command line interface will not be able to connect to the Monit daemon server.

So the solution was to change HTTP settings to:

set httpd port 3111
    allow   user123:user321     # actually, here goes really cryptic credentials, I don't use them anyway
    allow   user:pwd read-only

I hope this will save some time for those having the same problem.

TeamCity 4.0 runs Checkvist's tests

I'm working on two projects: TeamCity - a rather popular continuous integration and build management server, and Checkvist - a simple and fast online outliner with task sharing and keyboard navigation.

I use Checkvist to plan my work on TeamCity, and recently I got a chance to use TeamCity to assist Checkvist development.

TeamCity recently reached its next milestone - 4.0 release. One of the interesting things it has is Rake build runner (so it can test Ruby and Rails projects).

You know, software must be tested before the release. So I tested this runner by creating a Checkvist build configuration in TeamCity. It happened to work so nice, that I couldn't resist to prepare a short and dirty demo. 

Definetely, I had to break some Checklist tests to demonstrate some cool TeamCity features :)

View demo on TeamCity developer blog