We have been doing a painful migration from Rails 2 to Rails 3 for several months at work, and refactoring some code the other day I had to do something in a non straightforward way, so I thought I’d share that.

Basically we had an action that would group several files into a zip file and return those zipped files to the user as a response. In the old code, a randomly named file was created on the /tmp folder of the hosting machine, being used as the zip file for the rubyzip gem, and then returned in the controller response as an attachment.

During the migration, we’ve replaced all those bespoken temp file generation for proper Tempfile objects. This was just another one of those replacements to do. But it turned out not to be that simple.

My initial thought was that something like this would do the trick:

filename = 'attachment.zip'
temp_file = Tempfile.new(filename)

Zip::File.open(temp_file.path, Zip::File::CREATE) do |zip_file|
    #put files in here
end
zip_data = File.read(temp_file.path)
send_data(zip_data, :type => 'application/zip', :filename => filename)

But it did not. The reason for that is that the open method, when used with the Zip::File::CREATE flag, expects the file either not to exist or to be already a zip file (that is, have the correct zip structure data on it). None of those 2 cases is ours, so the method didn’t work.

So as a solution, you have to open the temporary file using the Zip::OutputStream class and initialize it so it’s converted to an empty zip file, and after that you can open it the usual way. Here’s a full simple example on how to achieve this:

#Attachment name
filename = 'basket_images-'+params[:delivery_date].gsub(/[^0-9]/,'')+'.zip'
temp_file = Tempfile.new(filename)

begin
  #This is the tricky part
  #Initialize the temp file as a zip file
  Zip::OutputStream.open(temp_file) { |zos| }

  #Add files to the zip file as usual
  Zip::File.open(temp_file.path, Zip::File::CREATE) do |zip|
    #Put files in here
  end

  #Read the binary data from the file
  zip_data = File.read(temp_file.path)

  #Send the data to the browser as an attachment
  #We do not send the file directly because it will
  #get deleted before rails actually starts sending it
  send_data(zip_data, :type => 'application/zip', :filename => filename)
ensure
  #Close and delete the temp file
  temp_file.close
  temp_file.unlink
end

We saw in chapters 6 and 12 several control structures but we left out a usual one: the switch also known as select/case. In this chapter we will see how we can implement it in ARM assembler.

It may be suprising, but the ARMv6 architecture does not provide an integer division instruction while it does have a floating point instruction in VFPv2. In this chapter we will see usual ways to workaround this limitation with different techniques that can be used in specific scenarios involving divisions.

If you ever need to use the acts_as_list gem in Rails on a model that uses single table inheritance, here’s the snippet you need to use for the list methods to work if you want the setup done on the base model:

acts_as_list :scope => [:type]

You’ll need to use the array syntax as neither the string nor the symbol versions will work. The symbol one assumes the column ending in _id, while the string one will simply not allow you to evaluate the current object’s type.

It’d be nice to have a lambda syntax in future versions of the gem so you can inject code into the conditions.

We have been using nagios (more specifically Check_MK) recently at work to get some monitoring information on our CentOS instances. Recently we decided to reprovision all of our EC2 instances to apply several security upgrades. Among the packages upgraded, there was the kernel (which I guess was the cause of our subsequent problems).

After updating all our instances, nagios began to complain about the mount options no being the right ones for the root file system, and started sending critical alarms. The file system was ok, it was mounted without problems and everything was woking fine, but for some reason the mount options had changed after the reprovisioning.

Turns out that Check_MK checks the options in place when it does the initial inventory, and if the options change over time, it issues an alarm. If you face this problem, just do a reinventory of your machines and reload the configuration and restart the service, and it should be fine:

cmk -II && cmk -R