Sean Eshbaugh

Web Developer + Programmer

Converting Text into a Sorted List

Ever had a list that's sorta broken up into different lines but is also mostly just uses spaces to delimit items? Ever wanted each item in that list on its own line? Ever want that one-line-per-item list sorted? It's shocking how often I need to do this. Actually it's probably more unfortunate than shocking.

If you find yourself needing to do all that too then you're in luck! It turns out there's plenty of easy ways to turn a bunch of words into a sorted list!

First, a few notes...

Since I'm on OSX I'm accessing my clipboard with pbcopy and pbpaste. If you're on Linux with X11 you can use xclip or xsel instead. Obviously you can replace the clipboard paste with some other output command and you can omit the clipboard copy or replace it with some other command.

All of these examples use grep and sort. grep is used here to remove blank lines, I'll just leave it at that since a book could be (and has been apparently) written about grep. sort does exactly what you'd expect, it sorts a file or input. The -f option makes the sorting case insensitive. If you do really want words that start with capital letters to go first then omit that option.

sed

% pbpaste | sed 's/[[:space:]]/\'$'\n'/g | grep -v '^[[:space:]]*$' | sort -f | pbcopy

sed is ancient. Despite its age it remains incredibly powerful and versatile. If you're on OSX or some other BSD variant then your sed will function somewhat differently from GNU sed. I won't waste a bunch of space explaining the details here, but this Unix & Linux Stack Exchange question explains it nicely. Basically BSD sed doesn't do escape sequences in output. The best solution I've seen to the problem is in this Stack Overflow comment. If you're on Linux and using GNU sed then this is what you'd do:

% xclip -o -selection clipboard | sed 's/[[:space:]]/\n/g' | grep -v '^[[:space:]]*$' | sort -f | xclip -i -selection clipboard

The s command takes a regular expression, a replacement string, and optionally one or more flags in the form "s/regular expression/replacement string/flags". The g flag, like it does most places, makes the substitution global.

tr

% pbpaste | tr -s '[:space:]' '\n' | grep -v '^[[:space:]]*$' | sort -f | pbcopy

tr is similar to sed but much simpler. So simple there isn't much to say. The first argument is a set of characters to replace and the second argument is a corresponding set of characters to replace the first with one-to-one. The -s option squeezes consecutive occurrences of the replacement characters to into a single character.

awk

% pbpaste | awk '{gsub(/[[:space:]]+/, "\n"); print}' | grep -v '^[[:space:]]*$' | sort -f | pbcopy

awk reads each line and executes the action inside the curly braces for each line. In our case we're using gsub to do a global substitution and then unconditionally printing the line. awk does far more than simple substitution and printing so there's probably a million different ways to accomplish this task. I've met several people who swear by awk, and I can understand why. Personally, I find it to be too awkward (pun sorta intended) for serious use given that alternatives with far fewer rough edges and more extensibility exist.

Ruby

% pbpaste | ruby -ne 'puts $_.gsub(/[[:space:]]+/, "\n")' | grep -v '^[[:space:]]*$' | sort -f | pbcopy

This right here is actually the biggest reason why I'm writing this post. Whenever I'm faced with a task involving transforming text my natural inclination is to write a small throwaway script in Ruby to get the job done. Usually those scripts end up being fairly elaborate and and proper, in the sense that they could easily be part of an actual program. I like to make it a habit to not write overly terse code. Even when I know I'm going to throw it all away I like my code to be readable with nice descriptive variable names and no magical short cuts. That being said, this article inspired me to venture forth and try my hand at something arcane and nigh unreadable. I try and avoid writing Ruby that looks like 1990's Perl, but the -n option coupled with -e is just too cool to ignore. I will, however, choose to ignore that the Ruby example looks almost exactly like the awk example. Personally I don't think that's a very flattering comparison.

If all of this seems familiar, it's probably because you've seen Avdi Grimm's excellent post on solving almost the same problem in several different languages.

Multiple Key Hashes in Ruby

Here's an idea I've had rolling around inside my head for a while: hashes with multiple keys for the same value. Or, rather, some data structure, that is like a hash, except that only the values are unique, not the key/value pair. A data structure like that would allow for multiple keys to access the same underlying data. What use could this possibly be? Well, I occasionally find myself doing something along these lines:

def flash_message_alert_class(name)
  case name
    when :success, :notice
      'alert-success'
    when :info
      'alert-info'
    when :warning
      'alert-warning'
    when :danger, :alert, :error
      'alert-danger'
    else
      'alert-info'
  end
end

Where name is a key to the Rails flash hash. That particular example isn't too egregious; it's easy enough to understand, only a handful of lines long, and most importantly has only a few possible outcomes. But what if that wasn't the case? What if we had 10, 100, or even 1000 when clauses? What if each of those clauses had as many possible values that would trigger it? That seems far fetched, and it is, but consider a more likely scenario, what if the above mapping between sets of symbols and a single string was somehow constructed at run-time based on various forms of input. It'd be very impractical or downright impossible to write a case statement to handle that. It occurred to me the other day that the above scenario could be modeled has a data structure much like the one I described.

I'm positive I'm not the first person to think of this, but I have no idea what it would be called so I can't verify whether or not it has a name. If you're reading this and know the proper technical name of the data structure I've described please send me a message, I would love to know. For now I'm calling it a "multiple key hash". Other possible names I've considered are "unique value hash", "dedupicated hash", and "double layered hash". That last one will make sense in a minute.

I did however find an interesting Stack Overflow answer which offered up what the poster called an AliasedHash. That data structure is pretty cool and is so close to what I've been thinking about but it's not quite there. I want "aliasing" to be implicit and consequently I want it to be impossible to have duplicate values. Attempting to create one will instead merely create an "alias".

Yesterday evening I finally got enough inspiration to implement a multiple key hash in Ruby. What I have so far is still very rough, untested (since I'm only one step beyond playing around in an irb REPL), and likely very bad as far as performance goes. Here's the most important parts:

class MultikeyHash
  def initialize(initial_values = nil)
    @outer_hash = {}

    @inner_hash = {}

    @next_inner_key = 1

    if initial_values
      initial_values.each do |keys, value|
        if keys.is_a?(Array) && !keys.empty?
          keys.each do |key|
            self[key] = value
          end
        else
          self[keys] = value
        end
      end
    end
  end

  def [](outer_key)
    inner_key = @outer_hash[outer_key]

    if inner_key.nil?
      nil
    else
      @inner_hash[inner_key]
    end
  end

  def []=(outer_key, new_value)
    inner_key = @inner_hash.select { |_, existing_value| existing_value == new_value }.map { |key, _| key }.first

    if inner_key
      @outer_hash[outer_key] = inner_key
    else
      @outer_hash[outer_key] = @next_inner_key

      @inner_hash[@next_inner_key] = new_value

      @next_inner_key += 1
    end
  end
end

A quick note before I explain this code in detail. The MultikeyHash#new method behaves a bit differently from Hash#new method; rather than take the default value (a feature I have not yet implemented) it takes a hash that represents the initial values of the MultikeyHash. Here is an example of how it would be used:

m = MultikeyHash.new(['a', 'b', 'c'] => 'letters', [1, 2, 3] => 'numbers') #=> #<MultikeyHash:0x007f9ad31bb370 @outer_hash={"a"=>1, "b"=>1, "c"=>1, 1=>2, 2=>2, 3=>2}, @inner_hash={1=>"letters", 2=>"numbers"}, @next_inner_key=3>

m[1]                                                                       #=> "numbers"

m[2]                                                                       #=> "numbers"

m['a']                                                                     #=> "letters"

m['b']                                                                     #=> "letters"
  

If a key in the initial hash is a non-empty array then each element in that array is made a key of the new MultikeyHash. This means that if you want an actual array to be a key you will have to nest it inside of another array. Unfortunately I haven't been able to come up with a better solution. I'm afraid this might become a nuisance since it's not at all obvious without reading the source for initialize. I'm also considering changing it to accept anything that response to each to make it a bit more flexible.

The MultikeyHash class consists primarily of two hashes. The outer hash is what is exposed to the user. The keys behave like normal hash keys but the values are always just a key to the inner hash. I've chosen to use an integer for simplicity's sake. When accessing a MultikeyHash value we first find the inner hash key in the outer hash. If it exists we use that key to get the value from the inner hash, otherwise we return nil.

Setting a value is a bit more complicated. First we check the inner hash to see if the value exists in the inner hash and if it does we get the inner key for it and set the outer hash value for the outer key to the inner key. If the value was not found we set the outer hash value for the outer key to a new inner key and then set the inner hash value for that new inner key to the new value and increment the inner key counter. The result of all this shuffling is that new values are effectively inserted as normal and existing values are given one more key by which they can be accessed. From the user's perspective hash access occurs like normal, but in reality there are two layers of access, the first mediating access to the second (hence why "double layered hash" is a name I've considered).

The above code works just fine, but it lacks something very important. One of the key features of Ruby's hashes is their ability to be enumerated. The Enumerable module provides a powerful set of methods to any class that implements its own each method. Let's take a look at just how easy this is:

class MultikeyHash
  include Enumerable

  # Omitting the rest of the class for the sake of brevity.

  def each(&block)
    @outer_hash.group_by { |_, inner_key| inner_key }.inject({}) { |acc, e| acc[e.last.map { |i| i.first }] = @inner_hash[e.first]; acc }.each do |key, value|
      block.call(key, value)
    end
  end
end

By grouping the outer hash by the inner key and then collecting those groups into a new hash where the key is all of the outer keys and the value is value the inner key points to we end up with a hash that looks like {[:a, :b, :c]=>"letters", [1, 2, 3]=>"numbers"}. This lets us easily implement an inspect method:

class MultikeyHash
  # Omitting the rest of the class for the sake of brevity.

  def inspect
    "{#{self.map { |keys, value| "#{keys.inspect}=>#{value.inspect}" }.join(', ')}}"
  end

  def to_s
    inspect
  end
end

Because MultikeyHash has an each method it now has all the other goodies like map, select, reject, and inject.

I'm still pretty hesitant to say this data structure is a good idea. I haven't actually used it for anything so I have no idea how it works in the real world. Odds are I never will. Either way, building new types of data structures is always lots of fun! You can find the whole class here.

Chef Resource Condtionals

Lately it seems like all of my posts are about things that are super, painfully, embarrassingly obvious in hindsight. The trend continues!

Over the last week I've been learning to use Chef to set up some servers at work (with the help of the iron_chef gem, which was written by a co-worker of mine). At this point I feel like a real dummy for never having bothered to use Chef before, especially since it's been around for some time now. If you're not using Chef for server management you really ought to look into it. It makes automating your setup easy and having everything that your servers need documented in your scripts is awesome.

Despite quickly becoming a "why wasn't I using this before?" sort of tool there's been a few conceptual hurdles, as there always is with any framework or DSL. The one that really got me is the not_if/only_if conditional guards on resource blocks. The Chef documentation lays it out in what seems like a straightforward manner:

The not_if and only_if conditional executions can be used to put additional guards around certain resources so that they are only run when the condition is met.

Seems simple right? Well, if you look around enough you'll see examples of not_if and only_if used with either a block passed as the argument or with a String passed as the argument.

Here's two quick real and I swear not-contrived examples. One with a block:

bash 'unarchive-lame-source' do
  cwd ::File.dirname(src_filepath)

  code <<-EOH
    tar zxf #{::File.basename(src_filepath)} -C #{::File.dirname(src_filepath)}
  EOH

  not_if { ::File.directory?(::File.join(Chef::Config[:file_cache_path] || 'tmp', "lame-#{node['lame']['version']}")) }
end

And one with a string:

bash 'compile-lame-source' do
  cwd ::File.dirname(src_filepath)

  code <<-EOH
    cd lame-#{node['lame']['version']} &&
    ./configure #{lame_options.join(' ')} &&
    make &&
    make install
  EOH

  not_if 'sudo ldconfig && ldconfig -p | grep libmp3lame'
end

Here comes the embarrassing part. To me, at least, it wasn't clear what each form of the method call did, or really that there is a difference between the two. When passing a block as the argument, the result of the block, truthy or falsy, determines whether or not the resource is run. When passing a String, it is executed as a shell command and the return result of the command is used to determine whether or not the resource is run. Remember, for shell commands a return result of 0 indicates success (or true) and anything else, typically 1, but it can be any non-zero value, indicates failure (or false).

At first I was naively trying to use not_if like this not_if { 'sudo ldconfig && ldconfig -p | grep libmp3lame' } expecting the block to run the command. Instead, the block just returns the string. Since Strings are truthy the block always returns true and always skips the resource for not_if or runs the resource for only_if.

If we take a look at the source for Chef::Resource::Conditional#initialize it becomes pretty clear what's going on.

def initialize(positivity, command=nil, command_opts={}, &block)
  @positivity = positivity
  case command
  when String
    @command, @command_opts = command, command_opts
    @block = nil
  when nil
    raise ArgumentError, "only_if/not_if requires either a command or a block" unless block_given?
    @command, @command_opts = nil, nil
    @block = block
  else
    raise ArgumentError, "Invalid only_if/not_if command: #{command.inspect} (#{command.class})"
  end
end

Here we can clearly see that if the optional command is passed as a String the Chef::Resource::Conditional object is initialized with the command and command options and the block instance variable set to nil (and importantly, ignored if it was passed at all). If no command was passed but a block was given then the command and command options instance variables are set to nil and the block instance variable is set to the block that was passed. And finally an exception is raised if no command or block is given or if something weird is passed as the command.

And if you look a little bit further down in the source you'll find where the conditional is actually evaluated:

def evaluate
  @command ? evaluate_command : evaluate_block
end

def evaluate_command
  shell_out(@command, @command_opts).status.success?
rescue Chef::Exceptions::CommandTimeout
  Chef::Log.warn "Command '#{@command}' timed out"
  false
end

def evaluate_block
  @block.call
end

Pretty much exactly as I described above. If the command instance variable is present, it'll evaluate the command, otherwise it'll call the block. If you're interested in seeing how the cross-platform shell_out method works you can check out the source, it's definitely worth a read.

In fact, I think the takeaway from all of this is, when in doubt, go straight to the source code. It'll save you lots of time and you'd be hard pressed to not learn something new, especially if you're diving into a well-known and properly designed library.

Nth Element of a List in Scheme

Common Lisp and Clojure both provide a built-in nth function for retrieving the nth element in a list. Surprisingly enough Scheme (MIT Scheme at least) doesn't that I'm aware of.

Fortunately nth is super simple to implement in a recursive fashion:

(define (nth n l)
  (if (or (> n (length l)) (< n 0))
    (error "Index out of bounds.")
    (if (eq? n 0)
      (car l)
      (nth (- n 1) (cdr l)))))

After checking to make sure that the index n isn't greater than the length of the list l or less than 0 the function checks to see if n is 0. If it is then it simply returns the first item in l with car. Otherwise nth is called again with n - 1 and the tail of l, retrieved with cdr.

seshbaugh ~% scheme --load nth.scm
...
;Loading "nth.scm"... done

1 ]=> (nth 3 '(1 2 3 4 5))

;Value: 4

I'm reasonably certain that this function is tail recursive; so it should work just fine, albeit slowly, for very long lists.

Recursive Closures in Elixir

File this under "things that are obvious in retrospect". I got to wondering if it's possible to recursively call a closure in Elixir. The answer is of course, yes, but with a small caveat. You simply have to pass the function (so it can't be truly anonymous) as an argument so it can be used as a callback.

Consider the following pathetic first attempt:

lol = fn
  0 -> 0
  x -> x + lol.(x - 1)
end

IO.puts lol.(100)

Looks good, right? Not quite...

seshbaugh ~% elixir lol.exs
** (CompileError) /Users/seshbaugh/lol.exs:3: function lol/0 undefined
    src/elixir_translator.erl:463: :elixir_translator.translate_each/2
    src/elixir_translator.erl:613: :elixir_translator.translate_arg/2
    lists.erl:1339: :lists.mapfoldl/3
    lists.erl:1340: :lists.mapfoldl/3
    src/elixir_translator.erl:620: :elixir_translator.translate_args/2
    src/elixir_translator.erl:80: :elixir_translator.translate_each/2
    lists.erl:1339: :lists.mapfoldl/3

The closure has no idea what we're talking about. Which shouldn't really come as a surprise, we're still in the middle of defining the value of lol (that's my understanding as of right now, if I discover that I'm right for the wrong reason I will be sure to update this post). If we want to call lol from within itself we have to pass a reference to it to itself, like so:

lol = fn
  _, 0 -> 0
  lol, x -> x + lol.(lol, x - 1)
end

IO.puts lol.(lol, 100)

This time around we pass lol has an argument to itself. In the first function clause the callback is ignored (since its purpose is to halt the recursion) and in the second one we use call it, with itself as the first argument again. Now when we run this we get the expected output:

seshbaugh ~% elixir lol.exs
5050

I'm not sure if this is really all that useful, since you could (and probably should) use defp in your modules to define private functions that aren't available outside the module. But it never hurts to know what's possible!

More Elixir Adventures

Last night I went to a surprisingly crowded meetup featuring Dave Thomas (of "pickaxe" fame) giving a talk about Elixir. I had a great time hearing him share his experience and the chance to pick his brain about Elixir was rather exciting. His most interesting take away point: Elixir may or may not be the next "big thing" in programming languages, but whatever it ends up being, it's going to look and feel very similar to Elixir. I think I'm starting to be inclined to agree.

The best part about the meetup was that I left with a better understanding of Elixir's (and Erlang's) concept of pattern matching and why it's so important. About a week ago I was attempting to do Project Euler problem 1 in Elixir. Whenever I encounter a new language I like to re-solve some of the easier Euler problems with it just to get a feel for the language, how to set it up an environment, and how to handle the basic syntax and patterns. Since I've already done most of them in Ruby or JavaScript I have a basic understanding of what I'm trying to do. My first attempt at Euler #1 is, in retrospect, embarrassing. When Dave Thomas said that early on with Elixir he was stuck in a Ruby mindset I totally understood what he meant.

defmodule Euler do
  def naive_euler_1(x) do
    if x <= 1 do
      0
    else
      if rem(x, 3) == 0 || rem(x, 5) == 0 do
        x + naive_euler_1(x - 1)
      else
        naive_euler_1(x - 1)
      end
    end
  end
end

IO.puts Euler.naive_euler_1(999)

I suppose it's not terrible considering I had only read and understood a few parts of the "Getting Started" documentation. At least it's recursive!

After getting home last night I immediately set out to re-write the above but using the awe-inspiring power of pattern matching.

defmodule Euler do
  def better_euler_1(x) when x <= 1, do: 0
  def better_euler_1(x) when rem(x, 3) == 0 or rem(x, 5) == 0, do: x + better_euler_1(x - 1)
  def better_euler_1(x), do: better_euler_1(x - 1)
end

Holy crap. No conditionals. Okay, well, technically there are conditionals, but they're in the form of guard statements on the pattern matching part of the function clause (I really hope I'm getting my terms right here!). Still, this is much cleaner and, from what I understand, much more idiomatic. Dave was rather emphatic in pointing out that by removing the standard if-then-else type of conditional logic you remove the possibility of many of the bugs typically found in software. I can't say I know from experience that that's true, but it's a very intriguing argument and one I hope to explore.

After Dave was done speaking a couple of people from the audience went up front and shared some things they've been doing with Elixir lately. The first person, while giving a quick rundown of his version of Conway's Game of Life pointed out something interesting that had only been briefly touched upon earlier while Dave was speaking (although I'd seen it before while reading up on Elixir); the |> macro. |> takes whatever is returned from the left and passes it as the first argument to a function on the right. It's a simple but powerful expression. Realizing this I set out to shorten my solution to Euler #1 even further.

IO.puts 1..999 |> Enum.filter(fn x -> rem(x, 3) == 0 || rem(x, 5) == 0 end) |> Enum.reduce(0, fn (x, sum) -> x + sum end)

Again, holy crap. This is almost identical to my standard Ruby solution.

puts (1..999).select { |i| i % 3 == 0 || i % 5 == 0 }.inject(:+)

In fact, were I reading it out loud and explaining it to someone I would probably end up using almost the same English words in both cases. To me, that's a good sign.

As soon as I'm done writing this I'm going to pre-order Dave's new book on Elixir. He said he's as excited about Elixir as he was about Ruby many years ago. Color me excited too.

I heard you like Ruby and Erlang so I put Ruby inside Erlang for you

Now I know I'm only just scratching the surface of this whole Elixir thing, but I have a sneaking suspicion I'm going to be feeling lots of deja vu...

~% irb
2.0.0p247 :001 > name = "world"
 => "world" 
2.0.0p247 :002 > "Hello, #{name}!"
 => "Hello, world!" 
2.0.0p247 :003 > 

~% iex
Erlang R16B01 (erts-5.10.2) [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] [dtrace]

Interactive Elixir (0.10.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> name = "world"
"world"
iex(2)> "Hello, #{name}!"
"Hello, world!"
iex(3)> 

Logging in Go

The other day I found myself needing to keep a log file for a small Go web application. I'm pretty new to the language so it actually took me longer than I initially thought it would. Mostly for one reason: I couldn't find a clear example of actually using the log package to do what I wanted. I suspect that because this is such a trivial task no one (that I could find) has bothered to document just how to accomplish this. In retrospect this seems so obvious now I can't help but question whether or not this post is even worth writing. I'm going to stick with my original gut instinct.

To demonstrate, here's a small sample program. All it does is open up a file, log a message, and then quit. Let's take a look at the entire program first and then dive a little deeper.

package main

import (
	"fmt"
	"os"
	"log"
)

func main() {
	logFile, err := os.OpenFile("sample.log", os.O_WRONLY | os.O_APPEND | os.O_CREATE, 0666)

	if err != nil {
		fmt.Println(err)

		return
	}

	logger := log.New(logFile, "Sample Log: ", log.Ldate | log.Ltime | log.Lmicroseconds)

	logger.Println("Logger created!")
}

For the sake of clarity: this isn't mean to be a final working example of logging in Go, just a demonstration of the setup.

The first thing we do is open up a file for writing set to append. If the file doesn't exist the os.O_CREATE flag will ensure it is created if possible. After making sure that went well we create a new Logger. Finally we call Println to append our message to the log.

The final output is something like this:

Sample Log: 2013/03/21 20:39:29.348481 Logger created!

For more information on log.New see the documentation. Since the documentation doesn't really tell you what the available options for the flag parameter are you can find them here.

Ripping Vinyl

I originally wrote this some time ago for a message board. It finally occurred to me the other day to post it here where it can actually be found. When I wrote this I was working on Windows 7. The general steps should be applicable to older versions of Windows as well as Windows 8.

The rest of this is very long...

Why I Program

"It may seem like a strange motivation to you, but sometimes people say things because they want people to hear them, make things because they want people to look at them and use them, and write things because they want people to read them." - Hacker News user pessimizer

I really don't think I could have better distilled the essence of why I program as both a living and as a hobby.

I was once explaining to someone entirely unfamiliar with software development, much less free and open source software, that I put much of my code out on the internet for anyone to freely use as they see fit. This idea seemed appalling and downright dangerous to them. "What if someone uses it without paying you!?" they asked with a stunned look of horror and concern. "That's the point. I would be ecstatic if someone found something I had written to be useful. It's why I do what I do."

Getting paid to program is awesome, but I'd still do it either way.

Configuring Nginx and Unicorn for force_ssl

It turns out that setting up SSL on Nginx + Unicorn + Rails is actually pretty easy. But there's a few pitfalls you have to watch out for. The following guide is based partially on these instructions and assumes you already have an SSL certificate and already have it placed on your server.

Let's take a look at our initial Nginx configuration file. You can find yours in /etc/nginx/sites-available, but if you're reading this you probably already knew that.

upstream unicorn_mysite {
	server unix:/tmp/unicorn.mysite.sock fail_timeout=0;
}

server {
	listen 80;
	server_name mysite.com;
	root /srv/mysite/current/public;
	access_log /srv/mysite/shared/log/nginx.access.log main;
	error_log /srv/mysite/shared/log/nginx.error.log info;

	location ^~ /assets/ {
		gzip_static on;
		expires max;
		add_header Cache-Control public;
	}

	try_files $uri/index.html $uri @unicorn;
	location @unicorn {
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header Host $http_host;
		proxy_redirect off;
		proxy_pass http://unicorn_mysite;
	}

	error_page 500 502 503 504 /500.html;
	client_max_body_size 4G;
	keepalive_timeout 10;
}

As you can see, this configuration makes some assumptions about our setup that are unlikely to be true for yours. However, for this exercise the details of the configuration are largely inconsequential.

In your editor of choice take the above config file and copy the server section and paste it below. Now, make the second server section look something like this:

server {
	listen 443;
	ssl on;
	ssl_certificate /etc/httpd/conf/ssl/mysite.com.crt;
	ssl_certificate_key /etc/httpd/conf/ssl/mysite.com.key;

	server_name mysite.com;
	root /srv/mysite/current/public;
	access_log /srv/mysite/shared/log/nginx.ssl.access.log main;
	error_log /srv/mysite/shared/log/nginx.ssl.error.log info;

	location ^~ /assets/ {
		gzip_static on;
		expires max;
		add_header Cache-Control public;
	}

	try_files $uri/index.html $uri @unicorn;
	location @unicorn {
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header X-Forwarded-Proto https;
		proxy_set_header Host $http_host;
		proxy_redirect off;
		proxy_pass http://unicorn_mysite;
	}

	error_page 500 502 503 504 /500.html;
	client_max_body_size 4G;
	keepalive_timeout 10;
}

The first difference you should notice is the listen port. HTTPS uses port 443 instead of port 80. The following three lines tell Nginx that we want SSL on and where our certificate and where our certificate keys are being stored. /etc/httpd/conf/ssl is a pretty standard location, but you can keep them anywhere.

The next change we make is to the log file locations. The normal HTTP config will write to nginx.access.log and nginx.error.log. Here we're telling the HTTPS config to write to nginx.ssl.access.log and nginx.ssl.error.log instead. If you ever encounter any problems with your SSL setup it'll be pretty handy to have your logs separated out by protocol.

The last difference between the two configurations is the extra proxy_set_header setting. Since we plan on using force_ssl in our Rails application to selectively ensure SSL on different controllers this step is really important. force_ssl relies on the HTTP_X_FORWARDED_PROTO HTTP header to determine whether or not the request was an HTTPS request. If this setting isn't set to https then you will end up with an infinite redirect loop as force_ssl will always think the forwarded request isn't HTTPS.

At this point you should restart Nginx: sudo /etc/init.d/nginx restart. In your Rails app's controller add the call to force_ssl at the top like this:

class ContactsController < ApplicationController
  force_ssl
  before_filter :whatever
  ...

Now, when you go to any action on that controller you should immediately be redirected to the SSL version.

If you get an error similar to "Error 102 (net:: ERR CONNECTION REFUSED)" then this likely means your server is blocking port 443. Odds are you won't have this issue, but I did, so it makes sense to me to include a possible fix. This makes the assumption you're using iptables to manage your ports. Open up /etc/sysconfig/iptables and look for a line similar to this:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

Immediately below it add the following:

-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

As usual, if your settings look similar but not quite the same then base your changes off your settings. The important part here is the --dport, we want to open up port 443. After you do this you'll need to restart iptables with sudo /etc/init.d/iptables restart.

At this point your controllers with force_ssl in them should be redirecting to the SSL version of your site. Like most ActionController callbacks you can also specify which actions force_ssl will be run on using the only and except options.

Overriding But Preserving Ruby Methods

Recently I found myself needing to overwrite ActiveRecord's default save method but still retain the ability to call the original method. I know, I know, that's crazy talk, right? What could you possibly need to do that for? Well, in my case it was to provide a way to create "drafts" of my models under certain conditions when save is called. Rather than have all sorts of messy logic repeated over an over my controllers or tucked away in an awkward helper method it made much more sense to me to attach the functionality on my models as I need it. The ever so sublime paper_trail gem does something quite similar with ActiveRecord callbacks. But that isn't quite what I needed. What I really wanted was the ability to prevent a model from being saved in the first place. After all, what good is saving a draft if we've overwritten the original in the process? I particularly had in mind a use case where some users could only save drafts, which could be approved at a later time by more privileged users.

So now that we know the why of doing something that at first seems crazy (and more than a bit dangerous), what about the how? The core of how to override but preserve a method is pretty simple, but I think it might be helpful to provide some context, so bear with me.

Just like paper_trail, and many other gems, we start off with the following to get our module to load whenever ActiveRecord is loaded. This ensures that we don't have to manually include our module.

# /lib/kentouzu.rb
ActiveSupport.on_load(:active_record) do
  include Kentouzu::Model
end

Next we define self.included in or Model module so that when it's included we extend the base class with the ClassMethods module. This provides a slew of class methods to our model, the most important of which for the purpose of this post is the has_drafts method.

# /lib/kentouzu/has_drafts.rb
module Kentouzu
  module Model
    def self.included(base)
      base.send :extend, ClassMethods
    end

The has_drafts method provides us with a nice way of making it so we only include our InstanceMethods when we actually need it. It'd be really bad if we always override a vital method like save! If we just included the code to orverride the method without going through this it would lead to all sorts of disasterous behavior as our earlier hook into ActiveSupport#on_load would include it in every model in our application even when it doesn't make sense.

By providing this method we give a nice clean way to add functionality to our models (or really, any class) in the same way paper_trail's has_paper_trail does. Lots of gems take advantage of this pattern.

    module ClassMethods
      def has_drafts options = {}
        send :include, InstanceMethods
      end
    end

Here's where things start to get interesting (and relevant). In our InstanceMethods module we use the same self.included method as before. But this time we call instance_method(:save) on the base class to get an UnboundMethod for save. This allows us to reuse it later.

    module InstanceMethods
      def self.included(base)
        default_save = base.instance_method(:save)

After getting a reference to the old save method we then override it with define_method, sent to the base class. define_method is important because it allows access to the surrounding scope where default_save is defined. This lets us use it even after its out of scope. Inside the block the key is the if statement. It checks for the conditions for using our new save method. In my particular case I check to make sure that everything is enabled on the model (in pretty much the same way paper_trail does) and that the conditions for saving are met and then create draft from the model and save the draft without saving the model. The details of what happens here are up to you.

        base.send :define_method, :save do
          if switched_on? && save_draft?
            draft = Draft.new(:item_type => self.class.base_class.to_s, :item_id => self.id, :event => self.persisted? ? "update" : "create", :source_type => Kentouzu.source.present? ? Kentouzu.source.class.to_s : nil, :source_id => Kentouzu.source.present? ? Kentouzu.source.id : nil, :object => self.to_yaml)

            draft.save

And now for the magic. If the conditions for using our new version of the save method aren't met we take our unbound reference to the old save and bind it to self which, since this is an instance method on our model now, is our model. Finally we call it with the () method. You could also use call.

          else
            default_save.bind(self).()
          end
        end
      end
    end
  end
end

Now whenever we call the save method on our model so long as switched_on? and save_draft? return true we'll get a copy of the model as a draft. Of course we could strip this down to something much simpler without all the fancy including, but in my opinion all that is what makes this so useful, we only get it when and where we want it. That's pretty important because overriding methods like this can be very dangerous. I strongly suggest that before you do this you make sure you actually need to.

The source for the gem this is from is on GitHub.

Finally Learning to Make Games

One of my earliest aspirations I can remember seriously having was to be a video game developer. Sometime in elementary school it dawned on me that people actually made the video games I played every afternoon. There were grownups who got paid to dream up and create games. I wanted in on that because obviously, I naively thought, it must be as cool as playing video games.

When I was in sixth grade a friend and I decided we would attempt to learn to program and make our own games. He got his parents to buy him a book on C++ (It's been over 15 years so I have no idea which book it was) and we both started to read it. The first chapter was a bit of a dumbed down history of computers and programming which I had no problem comprehending. But with the second chapter the actual programming began. It took less than two pages for me to be completely lost and give up. My friend fared a little better and was able to get a compiler installed on his computer and even got a "Hello World" program working.

Turns out, learning to program is hard. Reading about programming is so easy an eleven year old can do it without much effort. I consider myself lucky to have grown up with parents who encouraged my love of computers if not my love of video games over homework. That encouragement is greatly responsible for my desire to make video games never really going away. It did, however, sort of lay dormant for a few years.

When I was 13 I started playing Ultima Online. Eventually I learned one could emulate Origin's servers and write their own custom scripts for the server. This was around the time I was taking Computer Science in high school and learning C++ (for real this time). I eventually rescripted large portions of the game and in the process learned a ton about interpreted languages.

In college I started to read books specifically about video game programming. I would always get stuck though. Rather than going into how to build a game and really design the whole system of parts that makes a game engine; the books I tried would really just get bogged down in the low level details of how to setup OpenGL or DirectX and drawing things on the screen. Don't get me wrong here. That is tremendously important knowledge if you want to make a game. If you don't know how a simple triangle is rendered and all the steps necessary to do even that it's unlikely the bigger picture will make any sense. But after a few chapters I always felt like I was spinning my wheels so I would stop reading and abandon my dreams for a few months. This has been an ongoing cycle for about 7 or 8 years now, each time with a different book that promised to teach me to make games like a pro(!).

The furthest I ever got was a "shooter" that was really just a camera that let you move in an empty space surrounded by a skybox and shoot projectiles. Sure, it impressed my mom, but I wanted to do more. And the code I'd hobbled together from books and internet tutorials just couldn't be turned into anything resembling an actual game.

All this has been a lead into what I really inteded to write about: a book that finally taught me something I felt was useful. XNA 4.0 Game Development by Example: Beginner's Guide by Kurt Jaegers. This book is exceptionally good for a host of reasons. The least of which is that it delivers on the title's promise to teach by example. Each chapter has well written, easy to understand, and clearly explained code for working games.

The "working" part is really the key here. Instead of examples that touch on one isolated subject, leaving it up to the reader to tie it all together into something that can be played, the author presents complete games. The reason this is such a big deal, for me at least, is that it lets you see all the parts and more importantly where they all fit together. That's what I had always felt I was missing. The bigger picture. The overall flow of the entire system. Yes, knowing how to normalize the camera's view matrix is important, but without knowing how you're going to keep track of the state of the things in your scene it's close to useless. XNA 4.0 Game Development actually addresses those things. And because it uses the XNA framework it skips over the boilerplate stuff.

I really can't emphasize enough how important that boilerplate stuff is. I don't want to be misunderstood as saying it should never be learned. However, abstractions exist for a reason. Every game ever made has a main loop and some sort of timing mechanism and a way to draw stuff to a screen. Really, the implementation details of those things aren't important to the actual logic of the game and they really shouldn't be too important to the actual game play. After spending a few weeks with XNA I feel like it's let me do what I've always wanted, focus on the game, not the graphics library. This is the same reason I love Ruby on Rails. It abstracts away the boilerplate code that nearly every web application needs and lets me focus on my application, not reimplementing the wheel.

I hate reimplementing the wheel. Mostly because I know that no matter how good of a programmer I become, unless I become a dedicated wheel maker, I will never be as good at making wheels as the people who think about making the wheels all day every day because that's their job. And by wheels I mean the lower level stuff that any useful program sits on top of, whatever it may be. Most of the time the stuff that sits below my level of concern is only incedental to the problem I'm trying to solve. Without it I can't get anywhere, but that doesn't mean I have to be the one to build it.

Failure to recognize this is the reason all the other game programming books I've tried haven't clicked. Drawing a series of polygons to the screen that makes a cube or moving a 3D character model from A to B isn't what I'm trying to do. But they're all written as if it is the problem I've set out to solve. Very little of the code in XNA 4.0 Game Development is even XNA code. Rather it's video game code that happens to use XNA as its means of getting things done. I'm here for the high level architecture and logic, and the fine people at Microsoft responsible for XNA and Mr. Jaegers seem to understand that very clearly.

I'm admittedly pretty late to the XNA game, but I suppose I wouldn't have appreciated it as much earlier in my programming career. I've been a fan of C# for years now though, it's probably the best thing to come out of Microsoft. It's not my favorite language, but if I'm on Windows it's my first choice by a mile. XNA supporting C# is a big part of why I've been enjoying learning how to use it.

When I finish the book I plan on making a game of my own. For the first time in my life I think I just might be able to do it.