Log Reader:

Voila. Multiple apps can connect to the same log reader. Log messages will be “fair queued” between the sources. In a test run on my 2010 MacBook Pro, I can send about 13000 log messages a second. I needed to run three of the log writers above in parallel before I maxed out the 4 cores and it slowed down. Each process used about 12 MB RAM. Lightweight and fast.

Log Broadcasting:

If we then need to broadcast these log messages for multiple readers, we could easily do this:

Then we have many log sources connected to many log readers. And the log readers can also subscribe to a filtered stream of messages, so one reader could do something special with error messages, for example.

Non-portable code in ruby’s configure scipt. Easy workaround, prepend the configure command with a shell that can handle the current state of the configure script, ie: `bash`. (A fix has already been submitted, ans should be in the next ruby patch.)

And voila. The result is an array of dictionaries, each with “status” and “count” keys and corresponding values. Even though the group by guarantees the grouped values be unique, there could be more than one grouped column, so it does make sense.
If you think that’s a lot of code, it is. Let’s compare that with the Rails solution:

Record.count(:group => :status)

And that returns a dictionary (Hash), keyed by status, with the counts in the values

I’ve recently set up RVM running with Jenkins, and finally have it all working just the way I want.

I’m running on OpenIndiana and have Jenkins running as its own user. I ssh in as that user and install rvm for that user and verified that I can run ruby tests with rvm from the terminal.

There’s a “RVM plugin” (version 0.1) for Jenkins which has great promise – I like the idea of running all build steps with RVM setup. However, I couldn’t get it to find my rvm installation no matter how much stuffing around with environment variables I did. So I’m not using it for now.

The trick was to use a “Execute shell” build step and use a script like so:

This was for a ruby gem project which installs that gem in the named rvm gemset. Other projects can use this gem simply by using that same gemset.

Note also the line: “export TERM=xterm” – rvm is designed to run in a terminal where the TERM environment variable is set. Apparently there was a change to gracefully ignore its absence or be able to use TERM=dumb for no colour, (github issue 698), but that doesn’t appear to be working for me in rvm 1.10.2.

OpenIndiana is a fork of Sun’s OpenSolaris before it was killed by Oracle. There’s quite a few commands in there that are different from linux, and there’s been a bit of discussion on the openindiana mailing list about whether commands should be more linux like or not.

In any case, there’s the built in commands in /usr/bin and the linux-like versions in /usr/gnu/bin. This is what you need in your path to use the linux versions, which I have, but I have it at the end of my path.

Unfortunately that’s no good for rvm. Well at least for the rvm upgrading part.

You can put /usr/gnu/bin at the beginning of your PATH. Or if you don’t want to do that, you can:

With my continuing my interest in redmine / ChiliProject, I’m really wanting a way of backing up my data that is database independent. I did a bunch of searching around, and the best solution I found was here. However, it appears a little out dated, and didn’t work in Rails 2.3 for a few reasons:

The excluded tables list was outdated (probably from an earlier Rails)[1]

There were also some comments about the export being quite slow. This could have been because every record of every table was loaded up in an ActiveRecord model instance before being dumped to the YML files.

I addressed these issues and made a new version. Can’t attach a file to this blog, so it’s on pastie for now: http://pastie.org/1877530

I’ve tested this getting data out of mysql and into sqlite3 and that works just fine. This is really handy for getting the data into a test environment quickly without having to set up more mysql databases, users, etc.

[1]: I’m testing this for Rails 2.3.11 as Redmine and ChiliProject are Rails 2.3.x apps.

If this saves you some time, or could be improved, please let me know.

I originally got onto Redmine because of its great out of the box support for git as well as remote subversion repositories. I’m keeping an eye on the “chiliproject” fork of “redmine” at the moment.

I have a redmine installation which includes a few custom modifications. So I have my “local” branch, which forked from redmine’s 1.1-stable some time ago, but when there’s a new version to do, I merge the new redmine version into my local, giving me, for example, redmine 1.1.3 + my changes.

So in order to evaluate chiliproject, and to see if my custom changes would go across, I figured I’d just add the chiliproject git remote and merge it across. Easy right? Well, kind of.

This resulted in a *whole bunch* of merge conflicts; many of which actually looked to me like they should have been resolved automatically.

It appears those two repositories have a lot in common, but the main branches I’m interested in (redmine/1.1-stable and chiliproject/stable) have quite a distant common ancestor, which is what git will use to do the merge.

And Voila! All of my changes since redmine/1.1-stable can be applied to chiliproject/stable without any conflict. So, when two git repositories are related by difficult to merge, let `git merge -s ours` come to the rescue!