Matt Brown content for you

Personalization at Spotify using Cassandra

I cowrote a blog article about things my team at Spotify has been working on the past few months, primarily focused on how we use Cassandra.

How to type the ⌘ (Command) key in OS X Mountain Lion

This was harder than I expected it to be:

  1. Press ⌘ ⌥ T to bring up the Character Viewer.
  2. Click the gear menu (⚙) to bring up options and choose “Customize List…”
  3. Under Symbols, check the box next to Technical Symbols
  4. The command symbol (⌘) should be the first in the list.

From here you can drag and drop the ⌘ to whatever text editor you want - although a keystroke to type it would be far easier rather than opening Character Viewer each time.

Screenshot

Is there an easier way to do this?

Update: Yes, there is.

Crazy git error message of the day

$ git submodule add https://github.com/derekwyatt/vim-scala.git .vim/bundle/vim-scala
fatal: You are on a branch yet to be born

Stackoverflow has a solution for this problem.

Graphing CPU temperature in OS X with Munin

Last week I made a plugin for Munin to collect the temperature of my Macbook’s CPU, hard drive, and GPU, for no real reason other than I thought it would be need to see how they change over time, and because graphs are irresistible.

Screenshot

The plugin is on github. It requires a free app called Temperature Monitor to be installed so the temperature values can be collected in a script (I could not find any way built into OS X to collect the data from the command-line, like you would read /proc on Linux).

How to get iCal to recognize recurring events in iCalendar (ics) files

Here is the solution to a problem I recently debugged which I had a very hard time finding any information on via Google. Hopefully this helps someone else in the future.

When programatically generating iCalendar (.ics) files, iCal on OS X (at least on my Snow Leopard version, 4.0.4) seems to refuse to recognize that the event is recurring if the VEVENT contains a RECURRENCE-ID element.

For an event that should repeat on the first Thursday of the month, iCal would only add the first event if the ICS file looked like this:

BEGIN:VEVENT
DTSTAMP:20120425T210028Z
DTSTART;TZID=America/New_York:20120503T180000
DTEND;TZID=America/New_York:20120503T190000
SUMMARY:This event should repeat on first Thursday of the month
RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=4;BYDAY=1TH
RECURRENCE-ID;TZID=America/New_York:20120503T180000

However, remove the RECURRENCE-ID element and iCal recognizes that this is a recurring event just fine - it adds events on the first Thursday of the month for four months:

BEGIN:VEVENT
DTSTAMP:20120425T210028Z
DTSTART;TZID=America/New_York:20120503T180000
DTEND;TZID=America/New_York:20120503T190000
SUMMARY:This event should repeat on first Thursday of the month
RRULE:FREQ=MONTHLY;INTERVAL=1;COUNT=4;BYDAY=1TH

Outlook 2011 and Google Calendar recognize the first example as hoped for (shows an event that repeats on first Thursday of the month four times). It’s not clear to me from the RFC which behavior is correct - the meaning of RECURRENCE-ID seems confusing.

Cool Mac trick of the day

Highlight a word in almost any app, press Cmd + Ctrl +D, instant dictionary lookup.

Screenshot

Email Privacy Tool

Cool tool that I found today, which tests how much of your privacy your email client leaks when it displays an email (by displaying remote images or other content). Some quick results of different email clients:

  • iPhone 4 iOS 5.1 native mail app, remote images enabled (by default): leaks 17 out of 32 categories
  • iPhone 4 iOS 5.1 native mail app with remote images disabled: leaks 0 out of 32 categories (the winner)
  • Outlook for Mac 2011, remote images disabled: leaks 2 out of 32 categories (audio and video)
  • Mac’s built-in Mail.app v4.5, remote images disabled: leaks 14 out of 32 categories

Required Code Reviews

Ben Kamens posted today about changing his opinion on required code reviews from the negative to the positive after a change in policy at Khan Academy.

Having moved within a company from a team that had nothing close to approaching a code review policy, to a team that almost-religiously does code reviews on changes regardless of size (with one caveat, it’s not required for someone to “OK” each review/change), I can safely say that having a code review process is a huge bellwether of the overall quality of a software team.

I would never want to work with a team in the future that didn’t already do code reviews. It makes such a huge difference in the quality of the code produced, the level of understanding of each person on the team as to how things actually work, and education among people on the team in all sorts of ways (on best practices, tips and tricks, cultural things the team prefers, etc). It doesn’t slow you down, or increase the amount of process - it just makes sense.

As a developer, looking at code all day is what you should be doing in the first place anyway.

Khan Academy’s official policy on code reviews is a good read too.

How to verify a PGP signature with GnuPG

In case you are an idiot like me, here is a simple set of steps for verifying a PGP signature (for example, if you are downloading the TrueCrypt installer and you want to verify that the binary is intact).

If you already have GnuPG or another PGP client installed, skip steps 1 and 2.

  1. Install GnuPG - on my Mac with MacPorts, I ran

    $ sudo port install gnupg
    
  2. Create your private key with

    $ gpg --gen-key
    

    Accept all of the default options.

  3. Download the public key of the person/institution you want to verify. For TrueCrypt, their public key is available here.

  4. Import the person’s public key into your key ring with:

    $ gpg --import TrueCrypt-Foundation-Public-Key.asc
    

    (change the filename to whatever is appropriate).

  5. You need to sign the person’s public key with your private key, to tell PGP that you “accept” the key. This contains a few steps on it’s own:

    1. List the keys in your keyring with

      $ gpg --list-keys
      

      The output will look like:

      ... 
      pub   1024D/F0D6B1E0 2004-06-06 uid
                        TrueCrypt Foundation  
      sub   4077g/6B136ECF 2004-06-06 
      
    2. The “name” of their key is the part after “1024D/” in the line

      pub   1024D/F0D6B1E0 2004-06-06
      
    3. Sign their public key with:

      $ gpg --sign-key F0D6B1E0
      
  6. Now you can verify the signature of the file you downloaded. With TrueCrypt and it’s installer, this command was:

    $ gpg --verify TrueCrypt\ 7.1\ Mac\ OS\ X.dmg.sig
    

    which outputted:

    gpg: Signature made Thu Sep  1 11:50:54 2011 EDT using DSA key ID F0D6B1E0
    gpg: Good signature from "TrueCrypt Foundation " 
    

The dangers of java.security.SecureRandom

Java offers a few ways to generate random numbers, the default being java.util.Random. java.security.SecureRandom offers a more-secure extension of java.util.Random which “provides a cryptographically strong random number generator”.

“Cryptographically strong” sounds like something everyone would want, right? Why generate weak random numbers if you can generate secure random numbers instead?

Well, there is a pretty large downside to using SecureRandom in some scenarios:

If you want a cryptographically strong random number in Java, you use SecureRandom. Unfortunately, SecureRandom can be very slow. If it uses /dev/random on Linux, it can block waiting for sufficient entropy to build up.

Well, here is how the /dev/random device file in Linux works:

In this implementation, the generator keeps an estimate of the number of bits of noise in the entropy pool. From this entropy pool random numbers are created. When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

If you don’t read the descriptions carefully enough, you might miss the fact that /dev/random will block when there is not enough entropy data available. This means that in practice, it’s possible for your calls to new SecureRandom() to block for an unknown amount of time.

This is great if you truly need a very strong random number - return random data generated by the environment rather than a pseudo-random number generator, and if there is none available wait until there is some more - but is a really poor choice if you don’t need a super-secure random number and just a random-enough number will do.

It’s a bad habit to use SecureRandom everywhere by default, unless you truly want to make sure your unit tests or other code-that-doesn’t-need-to-be-that-secure randomly block for long periods of time in certain environments (hint: you probably don’t want this).

Unpredictable blocking is a very bad thing for most applications.