Page 1 of 36

Tusen tack, Kent

Mike at the Kent show in Oslo

Sometime in 2006, I was listening to random stuff on Pandora when a song came on that was distinctly not in English. I had no idea what the lyrics said but I was immediately hooked by the music. I learned the band was called Kent and the words were in Swedish. Then I found they had two albums in English, I bought those right away. Finding the Swedish CDs was more work; I ended up ordering those from websites in Europe that I could hardly read.

Every year or two there would be a welcome surprise in the form of a new album. I snapped them up and have thoroughly enjoyed them. Occasionally I would read the translations of the lyrics, but in general I was just happy to have great music to groove to. Often I thought about seeing the band in concert, but they only toured Scandinavia. In 2009 they played an album launch party in New York City, but I wasn’t able to go. Someday, I always thought.

In March, out of the blue, the band announced that they were quitting at the end of 2016, with a creepy video that included visual references to their past albums. It ends with “Sista albumet” (the last album) and “Sista turnét” (the last tour), and an end date of December 17.

2016 in general has been a lousy year, with a few ups and some serious downs. I overcame the worst part in the summer, and reminded myself that life is short. Why not go see this band? There will never be another chance. With luck, cheap airfare, and help from my family, my wife and I traveled to Oslo to see a show in October. It seems crazy to vacation in Norway in the fall but it was worth it!

How cool it was to see Kent play live after all these years. They put together a musical and visual masterpiece. So many of my favorite songs. At the same time it was bittersweet, knowing there won’t be any more.

Today is their last concert ever. I am glad to have known them for ten years, and I’ll enjoy this music the rest of my life. If you’ve never heard them, their music is easy to find these days on the streaming services. There are hundreds of great songs to listen to.

Färvall Kent och tusen tack!, Now with Less NSA?

As part of my site overhaul, I have been wanting to make the whole site run on SSL. Now that Let’s Encrypt is here, it’s easy and free to add SSL to a website. I wanted a lightweight tool for installing and maintaining the certificates, and was really easy to setup and use. I even managed to score an A grade on the SSL Labs Report.

Now, if only the other sites I used would SSL everything. Cough, Amazon, cough.

Once I clean up my Ansible scripts, I’ll publish them.

I'm Back!

After neglecting my website for years, it was time to smash it and reassemble the pieces.

My goals:

  • (Mostly) static site - I work on enough web infrastructure for my day job that I don’t really want to maintain more in my free time. So I’m dropping nearly everything that was dynamic. I can get a lot of the features from the old dynamic site, like blog pagination and such, from a static site preprocessor like Middleman. It plays nicely with my Ruby on Rails background.

  • Modern - I want to be able to use my site on my iPhone and iPad.

  • Automation - I do enjoy the convenience of deploying sites with one command and then everything Just Works™. I’ve become a fan of Ansible recently. I have a small amount of Ansible code that I use to configure, update, and deploy the site.

  • Deprecation - There are parts to my site that are simply ancient. I’m going to start phasing them out. I hate to send 404s to people, but I only have so much time and it’s not worth maintaining anymore. I’m adding deprecation notices to those pages, not linking them from my home page, and will remove them eventually.

I haven’t figured everything out yet. I still want a solid way to handle lots of pictures efficiently, with consideration for screen sizes, densities, and bandwidth. In the meantime I’ll keep my old homegrown code around for a while.

Hopefully this setup will be a good foundation for the next several years.

Until next time!

Ruby's shallow copies of hashes

When you try to copy a Ruby hash using .dup or .clone, you get what is called a “shallow” copy. The data in the hash below the first level just seems to be referenced, so if you have a hash within the hash, and try to change a value in the deeper hash, the value is changed even for the original hash you ran the .dup on. To get a full (“deep”) copy of a hash, you have to run an inelegant hack using Marshal to copy it: copy_hash = (Marshal.load(Marshal.dump(source_hash))). This apparently applies to arrays too. See the code below for an example, and I hope this saves you hours of debugging.

# Ruby unexpected behavior when using .clone or .dup on a hash (or array)

# create a hash and freeze it so it shouldn't be modified
MY_HASH = { :one => { :first => 'eins', :second => 'zwei' } }.freeze

puts MY_HASH.inspect # {:one=>{:first=>"eins", :second=>"zwei"}}

new_hash = MY_HASH.dup # copy the hash, unfrozen

new_hash[:one][:second] = 'dos'

puts new_hash.inspect # {:one=>{:first=>"eins", :second=>"dos"}}

# original hash should not be modified, but it is!
puts MY_HASH.inspect # {:one=>{:first=>"eins", :second=>"dos"}}

# this happens apparently because hash copies are "shallow" and only
# contain pointers to values
# a "deep" copy requires ugliness using Marshal

MY_HASH2 = { :one => { :first => 'eins', :second => 'zwei' } }.freeze

puts MY_HASH2.inspect # {:one=>{:first=>"eins", :second=>"zwei"}}

new_hash2 = Marshal.load(Marshal.dump(MY_HASH2))

new_hash2[:one][:second] = 'dos'

puts new_hash2.inspect # {:one=>{:first=>"eins", :second=>"dos"}}

# now the original hash is intact:
puts MY_HASH2.inspect # {:one=>{:first=>"eins", :second=>"zwei"}}

Rails validations with accepts_nested_attributes_for and _destroy

I was recently working on a Rails app that has a form with a parent item and child items on the same form. Ryan Bates’ complex form examples is a good place to start with this. That code will give you a simple form setup with some Javascript for adding and removing rows of children.

It works pretty well, except that in my case, I needed to ensure that each parent had a minimum of one child. I had a validation which checked for this, but it only worked for creating new records. If I removed all the child rows during an edit, the form would still save successfully. It turns out that the key is in the Rails documentation: “Note that the model will not be destroyed until the parent is saved.” So my validation was still happily finding a child row, even though it was set to be deleted. It took me some time before I found the right way to check for this, but the marked_for_destruction? method seems to do the trick. Here’s my code:

class Project < ActiveRecord::Base
  has_many :tasks
  accepts_nested_attributes_for :tasks, :reject_if => :all_blank,
    :allow_destroy => true

  def validate
    # require a minimum of one task
    undestroyed_task_count = 0

    tasks.each { |t| undestroyed_task_count += 1 unless t.marked_for_destruction? }

    if undestroyed_task_count < 1
      errors.add_to_base 'There must be at least one task'

Hope this helps someone!

Next page