Confused about which Ruby Event Sourcing library to use? This might help.

Interest in Event Sourcing is picking up in Ruby-land, and there's a lot to wrap your head around. In the interest of helping Ruby programmers pick a path forward, I've published a guide on Ruby Event Sourcing libraries that I hope you'll find useful.

Event Sourcing with Rails: A Case Study

In December I gave a talk at NYC.rb on Event Sourcing with Rails. Hakka Labs was there to take video, which is now up:

Event Sourced Record, the gem I mentioned in that talk, is now up. Check it out and let me know what you think.

The long-rumored Apple console, free-to-play games, and the future of the living room

I've never worked in the games business, and I have no major reason to have opinions about it. But I've been thinking about this one for a really long time and I don't see it being fully explained anywhere. So here's my thesis about what's going to happen with console gaming.

One day, Apple will expand Apple TV into an iOS device that can support third-party apps, perhaps renaming it in the process. The biggest reason they have to take this step is the rise of free-to-play (F2P) games. F2P games have made major inroads in mobile and PC gaming, but nobody has taken them into the living room. Apple will be the company to do this, beating Sony, Microsoft, Nintendo, and Valve to the punch. It will give the company a major footprint in the living room, strengthen its position as a distributor of streaming entertainment, and grow Apple TV into a massive new product line.

Free-to-play gaming is a tidal wave

Continue reading “The long-rumored Apple console, free-to-play games, and the future of the living room” »


More than once, I've been asked to make sense of a document store underneath an out-of-control codebase. For my last project, I wrote JsonInference to help me see the entire data store all at once, looking for common patterns.

Given a bunch of JSON documents that are assumed to be similar, JsonInference reports on statistical patterns about commonality. For example, feed a report object a bunch of JSON hashes:

report = JsonInference.new_report
huge_json['docs'].each do |doc|
  report << doc
puts report.to_s

And you receive output that looks like this.

JsonInference report: 21 documents
:root > ._id: 21/21 (100.00%)
  String: 100.00%, 0.00% empty

:root > ._rev: 21/21 (100.00%)
  String: 100.00%, 0.00% empty

:root > .author_id: 14/21 (66.67%)
  Fixnum: 100.00%

:root > .sections: 21/21 (100.00%)
  Array: 100.00%, 0.00% empty
  :root > .sections:nth-child(): 50 children
    Hash: 100.00%
    :root > .sections:nth-child() > .title: 50/50 (100.00%)
      String: 100.00%, 0.00% empty
    :root > .sections:nth-child() > .subhead: 50/50 (100.00%)
      String: 100.00%, 2.00% empty
    :root > .sections:nth-child() > .body: 50/50 (100.00%)
      String: 100.00%, 0.00% empty
    :root > .sections:nth-child() > .permalink: 46/50 (92.00%)
      String: 100.00%, 15.22% empty

I keep meaning to write more about document stores and challenges they represent to teams in modeling data. I don't necessarily think they're worse than relational stores, but they do seem to offer lots of unfamiliar pitfalls.


For a recent consulting project, I found myself comparing a lot of large JSON documents in tests, which can be frustrating since differences don't show up well when comparing the hashes normally. Hence JsonDeepCompare, a Ruby gem for comparing large JSON documents and showing the most specific points of difference if they are unequal.

Let's say you've got a test case:

class MyTest
  include JsonDeepCompare::Assertions

  def test_comparison
    left_value = {
      'total_rows' => 2,
      'rows' => [
          'id' => 'foo',
          'doc' => {
            '_id' => 'foo', 'title' => 'Foo', 'sub_document' => { 'one' => 'two' }
    right_value = {
      'total_rows' => 2,
      'rows' => [
          'id' => 'foo',
          'doc' => {
            '_id' => 'foo', 'title' => 'Foo', 'sub_document' => { 'one' => '1' }
    assert_json_equal(left_value, right_value)

Running it will output this error:

RuntimeError: ":root > .rows :nth-child(1) > .doc > .sub_document > .one" expected to be "two" but was "1"

The selector syntax uses a limited subset of JSONSelect to describe where to find the differences.

What database should I choose if I'm a total Rails n00b?


Stick with SQL databases for now, and use whatever's easiest in whatever environment you're using. That's probably SQLite on your laptop, PostgreSQL if you're deploying to Heroku, and PostgreSQL or MySQL if you're deploying somewhere besides Heroku. And as soon as you deploy anything that has data that you care about, and will have multiple people using it, make sure to not be on SQLite.

More explanation below:

How much research should I be doing on my own?

Very little. If you're a complete newcomer to programming, you're going to have your hands full as it is. Your choice of database is not the first problem you have to solve.


You may have heard of these new-fangled databases loosely called "NoSQL". They're cool, but they're a lot newer than SQL databases, which will cause you troubles when you're getting started. This isn't so much an issue of the technical merits of one style vs. another, but if you choose a NoSQL store that you're going to have an uphill climb with setup, installation, library support, documentation, etc.

SQL, on the other hand, is super-popular and might actually be older than you. That means that for every single SQL question you have, you're only a Google search away from an answer. Stick with SQL for now.

Which SQL database should I use?

There are three meaningful open-source SQL databases: SQLite, MySQL, and PostgreSQL. An over-simplified comparison might go like this:

  • SQLite, as the name implies, is meant to be a very light implementation of SQL functionality. You can use it, say, if you're making a Mac application and need a good way to store structured data, but you don't want to go to the trouble of setting up a SQL server. This also makes it great for developing on your own machine, but since it's multi-connection functionality is limited, you're not going to be able to run an app on production with it.
  • MySQL is a full-scale SQL server, and many large websites use it in production.
  • PostgreSQL is also a full-scale SQL server, used by other large websites in production. This is actually my personal favorite, but that distinction doesn't matter when you're just getting started.

Any of these will get you what you need: A place to store your Rails data and a way to start learning SQL bit-by-bit. You should optimize for ease of installation or deployment. So that means:

  • SQLite when you're working on your laptop
  • PostgreSQL if you're deploying to Heroku, since Heroku favors PostgreSQL over MySQL
  • PostgreSQL or MySQL if you're deploying somewhere else. Check their docs and use whatever they tell you to use.

And it's going to be fine, at first, to have the same app using different SQL engines in different environments. At some point you may end up using some really specific, optimized SQL that SQLite can't run, but that's not a newbie problem.


So I switched to Vim, and now I love it.

For years, I was actually using jEdit, of all things, even in the face of continued mockery by other programmers. My reasoning was well-practiced: TextMate didn't support split-pane, all the multi-key control sequences in Emacs had helped give me RSI, and Vim was just too hard to learn. jEdit isn't very good at anything, but it's okay at lots of things, and for years it was fine.

But eventually, I took on a consulting gig where I was forced to learn Vim. And, as so many have promised, once I got over the immensely difficult beginning of the learning curve, I was hooked.

Continue reading “Vim” »

The law of constant testing hassle

Over time, technological progress makes it easier to write automated tests for familiar forms of technology.

Meanwhile, economic progress forces you to spend more time working with unfamiliar forms of technology.

Thus, the amount of hassle that automated testing causes you is constant.


Looks like your Twitter bots need to be better at quote-escaping:


The Front-End Future

My Goruco 2012 talk, "The Front-End Future", is now up. In it, I talk about thick-client development from a fairly macro point-of-view: Significant long-term benefits and drawbacks, the gains in fully embracing REST, etc.

I also talk a fair amount about the cultural issues facing Ruby and Rails programmers who may be spending more and more of their time in Javascript-land going forward. Programmers are people too: They have their own anxieties, desires, and values. Any look at this shift in web engineering has to treat programmers as people, not just as resources.

Francis Hwang - The Front-End Future from Gotham Ruby Conference on Vimeo.

As always, comments are welcome.