Sho Fukamachi Online

So I’ve got this web app. It’s pretty “heavy” and it does a lot of image manipulation. It’s a bit of a pig, to be honest.

Under Ruby 1.8.7 and 1.9.1, you can reliably expect the memory usage of this app to grow .. and grow .. and grow. I have seen it reach 900M before I shut it down (manually on development machine – in production monit would have killed and restarted it long ago).

Memory usage under 1.9.2pre1? 72.7M and it’s been running for hours. It got as high as ~130M or so at one point, but then – astonishingly – GC actually worked and released unused memory. Will wonders ever cease?

Performance is up around 20% on 1.9.1, too.

Memory usage, and the constant leaking/growth thereof, is my number one daily problem with Ruby. The preview release of 1.9.2 seems to have solved it. To say I’m happy about this development would be an understatement. I am looking forward to deploying on 1.9.2 ASAFP and will do so, probably, upon the release of preview 2 (I have noticed no stability problems whatsoever).

update: 12 hours later it’s gone down to 65.5M. Praise the Ruby Gods!

Is the process 1234 running?

Process.kill(0, 1234) == 1 rescue false

I do not understand why bloggers adopt services such as Disqus.

It is not hard to put comments on a blog. Really, it is not hard at all.

It is not especially hard to block spam. This blog may not be popular but it’s over 4 years old and gets a LOT of spam; sometimes thousands a day if some bot gets into heat. All is dealt with. It’s not effortless but it’s pretty minimal.

So why do people wilfully pervert the core strength of the internet’s redundant peer-to-peer structure and adopt a centralised commenting system for their independent blog? I just don’t get it. Especially the so-called experts at Ruby Best Practise who apparently can’t even run a fricking comment system. I qualify for “Ruby Worst Practise” most of the time and I have written and run several.

Here’s “Ruby Best Practise” as I experienced it today:

Thanks for losing my comment, matchless professionals at Ruby Best Practise.

Mongrel, still probably the most-used workhorse for serving Rails applications, has been abandoned for a long time – first by its creator, then its so-called maintainers. It’s been a farce, actually, that this important piece of infrastructure has been tossed around in this casual manner. I still rely on Mongrel in several ways, and I know others do too.

Anyway, I wanted a gem with the Ruby 1.9 patches in it, so I made one . Nothing but 1.1.5, plus the Ruby1.9 patches (thanks ), there will be no ongoing changes – all I care about is that I can do

sudo gem1.9 install sho-mongrel

update: fucking github has turned off gems so this doesn’t work anymore.

and it works.

If you’re looking for more progress than that, phurley is actively improving mongrel in (which I didn’t know about before I made mine). He is also making it available as a gem, and looks to be actively improving and modernising the ancient battleaxe.

(1..100).each {|num| Growl.new(:message => "I am number #{num}!").run}

Change the number to 1000, as I did, and don’t plan on seeing your desktop for a while. Add :sticky => true for extra “fun”.

I hate writing and maintaining code which does extremely common things, so I’ve gone through a few rubygem management libraries over the years. Most recently I’m been using a library called Bones – it was OK, I guess. Better than doing it myself.

Recently, however, I’ve come across – a clean, simple solution which really fits my needs. It’s git-aware – any files git knows about, it knows about, and includes effortlessly. It automatically handles binaries, it does version updates, it doesn’t require you to include numerous files of its own – just a short addition to an existing projects’ Rakefile will do the trick. In short, it’s exactly what I want and nothing more, and I’ve adopted it for my gem needs.

Another fantastic RubyGem I’ve stumbled across lately is , which is exactly what the name suggests – a kit for easily generating daemons in Ruby. It’s a little more complex than Jeweler, obviously, but it generates a logical and familiar directory structure – if you’re proficient in Rails you’ll instantly grok what everything is for. Putting together a daemon in Ruby has always been relatively easy, but somewhat time-consuming as you build your own structure with all the little bits you need – I find DaemonKit’s defaults to be pretty much exactly what I want as a base, and you can be up and running in minutes. Plus, since half the daemons I write these days seem to have something to do with AMQP, its explicit catering to this use case is particular welcome.

Combine the two and you’re in gem daemon heaven. Check them out.

Anyone else think this is a pretty weird inclusion in the ruby core distribution?

One of the things I miss most about Rails when working in gems is the reload! function, which rebuilds the environment to update anything that’s changed since the last save. Well, I wanted to recreate that functionality, but hopefully in a really simple way.

The good news is, it’s actually pretty easy. I have two ways of doing it, pick the one you like best.

module AutoReload
 
  @mes = {}
 
  def reload!
    diffs = AutoReload.differences # we can only call it once per reload, obviously
    if diffs.size > 0
      diffs.each {|f| Kernel.load(f)}
      puts "reloaded #{diffs.size} file(s): #{diffs.join(', ')}"
    else
      puts "nothing to reload"
    end
  end
 
  def self.update_modtimes
    $".each do |f|
      @mes[f] = File.mtime(f) if File.exists?(f)
    end
  end
 
  def self.differences
    oldlist = @mes.clone
    AutoReload.update_modtimes
    newlist = @mes.clone
    oldlist.delete_if {|key, value| newlist[key] == value }
    oldlist.keys.uniq
  end
 
end
 
include AutoReload

You will then need to initialise it somewhere after all your requires. AutoReload.update_modtimes will do the trick. If you can’t manage that, it will only work properly after the first time you use reload!.

This is the way to do it if you have a lot of files, I think, since it maintains a list of what was changed when, and then only reloads changed files.

Note that it’s not perfect. It will only be able to find files which are in local path, ie won’t be able to reload gems. However, that’s all I need for now.

The next way is even simpler, since it doesn’t bother to maintain a list – it just blindly reloads everything it can:

def reload!
  diffs = []
  $".each {|f| diffs << f if File.exists?(f)}
  if diffs.size > 0
    diffs.each {|f| Kernel.load(f)}
    puts "reloaded #{diffs.size} file(s): #{diffs.join(', ')}"
  else
    puts "nothing to reload"
  end
end

As you can see, this just blindly reloads everything it can find. Probably not the best if you have a lot of constants etc, but for a simple project could be just the ticket. The good news is you don’t need to initialise it. if you have a lot of files you probably should return "OK" or something, else you’ll have pages of reloads scrolling past.

Let’s bear in mind that this kind of trick is always a bit of a hack. Kernel.load() has no ability to unload anything, even if it doesn’t appear in the file anymore. All it can do is overwrite. If you break your code by deleting something important, then reloading using this kind of trick won’t show it up – the object is still there until you reload ruby itself. It’s a convenience thing only, so don’t rely on it too much, do a full reload once in a while.

However, for my use case – making a lot of small changes and working in a very interactive manner with irb – this is a real time-saver, hope you find it useful too.

If you’d prefer it to happen automatically, rspec-style, there is a gem available which will do this for you here which basically does the same thing, just every 1 second instead of manually.

Any Ruby programmers who are reading this, I’m experiencing a strange issue regarding Digest::MD5. Let me show you:

>> require 'digest/md5'
=> true
>> Digest::MD5.digest "Les Rhythmes Digitales"
=> "\213U\3601\260%\267-\343(\213I\030\347"

What the fuck is that huge escaped thing? A unicode issue?

Check out the same from bash:

$ md5 -s "Les Rhythmes Digitales"
MD5 ("Les Rhythmes Digitales") = 8b55f031b0253c6ab72de3288b4918e7

Now that looks more like what I expect from an MD5 hash. Is Digest::MD5 mangling the text into some kind of weird invalid unicode?

Let’s try with $KCODE set:

>> $KCODE = "UTF8"
=> "UTF8"
>> require 'digest/md5'
=> true
>> Digest::MD5.digest "Les Rhythmes Digitales"
=> "\213U?1?%\267-?(?I\030\347"

Great. Any different in 1.9?

irb(main):003:0> Digest::MD5.digest "Les Rhythmes Digitales"
=> "\x8BU\xF01\xB0%\xB7-\xE3(\x8BI\x18\xE7"

Different again. At least I can see the characters in there, though. This is causing some pain.

Am I doing something hopelessly wrong? Somewhere in all these, some character encoding crap is going down. I can’t believe I’m the only one having these problems, and they render it difficult to use hashed passwords. I am working around the issue by shelling out to bash for now, but would like to get it fixed.

UPDATE: About 2 minutes after writing that, I realised I need to use Digest::MD5.hexdigest, not plain digest. I have no idea what the difference is supposed to be, but oh well, lesson learned. Apparently writing complaints on this blog helps me solve problems, so expect it to continue.

>> Digest::MD5.hexdigest "Les Rhythmes Digitales"
=> "8b55f031b0253c6ab72de3288b4918e7"