Adding nginx to logwatch was more complicated than I’d imagined. I found a couple entries on the internets about how to do it, but I wasn’t really impressed with any of them.

And so, my list of steps to accomplish this follows. Enjoy!

Blocks are fantastic. Being able to store code in the current context and execute it elsewhere is wonderful.

On a project I’m working on, we’ve got a bunch of ruby test code executed using Cucumber, and right now I’m working on integration with third party systems. This results in a large number of polling loops.

I start to notice a pattern appearing. They almost all follow the same syntax, keep track of time and timeout after a certain amount of time has passed. The only differences are: * Amount of time to wait * The criteria for success * The code to execute to get that criteria (maybe a rest call, maybe selenium UI tests)

That seems like it’d be a lot to try to narrow down. In Java I can’t even imagine how I’d go about doing it. In groovy it could be done with closures, but it wouldn’t be as clean as I’d like it to be. In Ruby, however, it comes out beautifully:

1
2
3
4
5
6
7
8
9

def do_timeout(wait_time, logic, &block)
  start_time = Time.now
  while logic.call
    yield
    if Time.now - start_time > wait_time
      raise "Timed out!"
    end
  end
end

I can pass in all three items and handle all the time logic trivially. Makes the end user’s code much cleaner:

1
2
3
4
5
6

x = 0
do_timeout(10, lambda { x < 3 }) do
  puts "omg, I'm doing something and it results in x being #{x}"
  x = x + 0.25
  sleep 1
end

This will hit the timeout and raise a nice Timedout exception for me. Making my tests fail as they should. If one changes the increment to 0.5 it’ll pass and everything comes out perfectly fine and moves on just fine. This is basically an enhanced while loop. I can easily encapsulate the logic as well as the block of execution. It’s almost like I added a new keyword to the language.

Ruby is fantastic. So is functional programming :)

First the warning about dangerousness:

Rewriting your history is generally anti social. Any downstream clones of your repository will no longer be valid. Their history and your history will have diverged. That’s not impossible to recover from, but it is best if you can get everyone to push everything they’d want to push, and then clobber your history. People will just clone the repo again and have the new history and everything will be peachy.

Yet another blog conversion. This time, I’m much happier with the capabilities than in the past. Wordpress was a “make it easier” step from serendipity a long time ago. I don’t have any of that old blog data anymore at all. This time, however, I took advantage of exitwp and successfully exported everything. To get the comments in (which I’m still not sure is working correctly, at least for historical comments) I used the disqus plugin for wordpress and imported the comments from wordpress. Then I migrated the URL, which was only a small change: /wordpress/ to /blog/ and now all the comments should be available on the new urls. I’ve got 301 permanent redirects for all the old /wordpress/ urls, so hopefully the search engines will update their indexes and such.

On the my project at work, there are configuration files that are used to configure the artifact for the various environments it gets deployed to. We’ve got about 6 different environments some with remarkably similar configurations, and that means lots of duplicate property values. With the current setup using maven resource filtering, if one environment is different from the other 5, the property has to be specified in all of the filtering config files. Worst case scenario, that means 5 files have duplicate data, and the 6th has something different.

Well, that was driving me crazy and so I implemented a groovy based solution using a YAML file instead.

Over the weekend the Jenkins build started failing. The error leads me to believe that someone didn’t verify their build before committing code, and that the configuration file now has a problem:

1
2
3

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl (create-schema) on project incident-service:
   Execution create-schema of goal org.codehaus.mojo:hibernate3-maven-plugin:2.2:hbm2ddl failed: 
    Could not parse configuration: file:/var/lib/jenkins/jobs/IncidentService/workspace/target/classes/hibernate.cfg.xml

Particularly deployment automation, in my case something like capistrano. It goes further than just the application, however. It goes into being able to ensure that the deployment environment, including the database and the application container all behave nicely. I have failed in this aspect, as my rails app is no longer behaving, and I’ve been reduced to updating things in the hopes that one of the things will fix it :(

I updated my postgresql database, as it was version 8 and version 9 has been out for quite a while. That actually went painlessly. Backup the SQL, terminate the db server, build/install the new one, and restore the SQL. Then tewak configuration files to get everything back the way it was before. No problem.

Then realized I needed to rebuild a pg gem on the deployed host so that it’d talk to postgresql 9 now. Did that. Suddenly the app server no longer responds. it just sits there forever waiting on … something. No amount of debugging output from Passenger will help. It must be something else. So now I’m updating ruby and rebuilding a new Passsenger against it in the hopes that it’s a bug in ruby that I’ve encountered that evidences itself with postgresql 9 or something. Otherwise, I might be spending the day getting the newer revision of my application ready to go a bit earlier than I had planned.

Had I had an automated deployment script built in, I could’ve just clobbered the environment and redeployed within the new fresh environment. Instead I’m having to monkey around getting everything to behave well, and generally failing at it.

I know it’s not something you have to do. But when it arrives an entire day early, would it be that difficult to put it on the truck and deliver it?

Instead, it’s simply “not due for delivery,” and so you keep it. I wish I’d checked before I left work, then I could’ve gone and picked it up, because you’re too lazy to get it to my house today.

If you weren’t better than UPS at smashing boxes for me, I’d have shipped it UPS, and they’d have delivered it a day early.

cuke4duke support has been dropped in favor of work on cucumber-jvm. Which is all well and good, except that cucumber-jvm isn’t fully baked yet. It’s not quite there regarding features, but it’s getting there fast.

Unfortunately, that means for those that are still using cuke4duke, you’ve got problems to deal with. The voodoo magic that is cuke4duke does not install gems very well. I don’t know precisely why this is, but it ends up with many problems. Things that will install just fine using a jruby command line, or in native ruby barf a horrible death. Often regarding some YAML::Syck thing.

ERROR:  While executing gem ... (ArgumentError)
      undefined class/module YAML::Syck::DefaultKey

Blarg. Gcc.

I kept having a horrible error building collectd 4.10.x on my Source Mage servers:

1

libiptc.c:85: error: redefinition of 'struct xt_error_target'

The internets couldn’t really help me with the error, I think I was searching for the wrong words. There was also issues regarding warnings that gcc now treats as errors.

I ended up spending probably about an hour cloning their git repo, cherry-picking a few commits into the 4.10.3 tag, and then submitting the patches to the bug I created.

End result is that collectd-4.10.3 now builds on gcc 4.4.3 and 4.6.1. The fix is in the Grimoire on Source Mage, and should trickle out to stable eventually. I think I’m the only one who uses collectd, so it’s not all that important, heh.