Upgrading Yesod 1.2 -> 1.4

I’ve recently had to quickly upgrade Yesod 1.2 web application from version 1.2 to 1.4. I was looking for resources on how to do this and couldn’t find anything beyond Announcing Yesod 1.4 and Persistent 2.1 Released. This post should be useful if you’re in a similar situation and your app is backed by PostgreSQL, even though it should work just about the same for any other SQL backend.The transition was actually pretty simple, you have to take care of the following steps:

Update the libraries

Installing Yesod 1.4 through hackage is even more of a pain that before. It’s doable, and I have done that before, but I strongly recommend using Stackage Server. Go with an exclusive snapshot to avoid headaches and having to set constraints. It completely takes care of cabal hell as long as your dependencies aren’t highly exotic. Even then there are ways to work around it, but that’s for another post.

Once yoru cabal is wired against Stackage, remove version constraints from all of the packages in your .cabal file, as those will be decided for you by the Stackage snapshot.

Update Foundation.hs

-- replace this
import Database.Persist.Sql (SqlPersistT)
-- with this
import Database.Persist.Sql (SqlBackend)


-- replace this
giveUrlRenderer $(hamletFile "templates/default-layout-wrapper.hamlet")
-- with this
withUrlRenderer $(hamletFile "templates/default-layout-wrapper.hamlet")

Add the following after all of the implementations of instance YesodAuth:

instance YesodAuthPersist App


-- replace this
share [mkPersist sqlOnlySettings, mkMigrate "migrateAll"]
-- with this
share [mkPersist sqlSettings, mkMigrate "migrateAll"]

Update SQL entities

Love timestamptz in Postgres? ZonedTime SQL type is gone in Persistent 2.1: it’s now officially replaced with UTCTime which was already available before. If you actually need to know the TZ of a certain timestamp, you’re going to need a custom solution, Persistent isn’t going to do this out of the box, but if you don’t, just swap one for the other.

Update Entity Key creation logic

If like me you were manually generating Entity keys in your tests, then you will no longer be able to do so with Persistent 2.1. Replace your old code doing:

Entity (Key $ PersistInt64 1) { foo = "bar" }

with the new:

import Database.Persist.Sql
Entity (toSqlKey 1) { foo = "bar" }

The steps above should take of the most common conflicts that you will encounter when upgrading PostgreSQL-backed Yesod 1.2 to 1.4. Let me know if it’s missing anything.

As always don’t forget to drop by #yesod and #haskell-beginners on Freenode if you have any questions.

Upgrading Yesod 1.2 -> 1.4

Reference Haskell libs for developing great style

Been somewhat busy digging into Haskell recently for our analytics-heavy upcoming web app and couldn’t get a good idea of what quality Haskell code should look like. Sure, there’s LYAH and RWH, and Beginning Haskell, but I like to see live code form authors who are universally considered reputable and well understandable by beginners such as myself. The following libs were recommended for perusal by the fine and generous folks at #haskell-beginners:

There are also a couple of good Stack Overflow posts on the subject if you need more examples:



This should be plenty of reading, back to work.

Reference Haskell libs for developing great style

Early/mid 2014 update – we’re hiring

Whoa, a few months have gone by really fast here. Hi world. Guess I should post an update.

Been hard at work as usual at Front Row, it’s been very interesting to watch our numbers go up at a staggering pace while the # of people supporting the project stays the same. Really makes you appreciate the people making it happen, the tools you’re using and the best practices that keep the whole system from falling apart.

In any case, a few folks and we decided that it was time to give Front Row a bit of a budget to start scaling things out. We’re now looking for a couple of engineers to join us and work closely with yours truly. We’re seekingĀ  web generalists with strong interest in functional programming: we’re a very small team and being able to pick any part of the stack up in a few days is very important. Here’s more info.

Whatever you like, we got it:

  • Want to build super-interactive SPAs and get good at data-visualization? Check.
  • Want to get your hands dirty with ops, configuration management, build automation and continuous delivery? Love Ansible? Check.
  • Want to crunch a ton of data and serve it to the outside world with Clojure and Haskell? Check.
  • Want to build tools and pipelines that enable Front Row content creators to publish their work to hundreds of thousands of students? Check again.
  • Love DBs? We do too! Ours is growing exponentially šŸ˜¦ If you’d like to contain the beast, we can keep you busy.

That’s it for now!

Early/mid 2014 update – we’re hiring

The hard balance

One of a founder’s toughest logistic challenges is balancing drinking the coolaid of one’s own vision against the iron skepticism that is required for making healthy data-driven decisions.

With the vision, we’re in the land of dreams: Ok, I convinced myself, the team, the people investing in us, the people paying for our services and the people using them that the world is one day going to work according to our bold vision. I claimed that this is how it’s going to be, it’s inevitable, it’s coming and we might as well be the ones executing on it. I claimed that you are all going to behave the way we predict for the foreseeable future.

In the real world on the other hand, a realm of estimates, percentages, decision-making through empirical means, nothing ever goes according to plan. You make a prediction, you test it, most of the time you discover missing a subtle but fatal nuance: one of your assumptions was wrong and you now need to try again with a different set of variables. Rinse and repeat. Maybe you overcome a local maximum, then you run into the next one which turns out to invalidate everything you had done up until that point. Oops, months wasted, time to go all the way back and try again. You just discovered one more way something couldn’t work.

The trick is that you need to convince everybody else of being right, yet at the same time you have to relentlessly try to prove yourself wrong: you most likely missed something and the plan won’t work until all the kinks are ironed out. It’s a very hard line to walk, it’s working every day through cognitive dissonance, getting used to it and not letting it stop you from making progress.

The hard balance

2013 – a retrospective

The kind of fast-paced, “just get it done now” work we do tends to be very day-to-day. You toil the days away, immediately switching to the next task, and never feel like you’ve learned anything. In a healthy Agile tradition, I would like to reflect on the past year and acknowledge the learnings, keeping things in perspective for those moments where I feel I’ve accomplished nothing. Here are some of them for posterity:

  • First MVC JS app in Backbone.js. Since then iterated for close to a year on our existing teacher dashboard. Now using Backbone + LayoutManager to implement the student MVC app for Chromebooks, directly replicating the iOS experience. Really fortunate to be able to chat with folks of the caliber of Tim Branyen and Samuel Reed when it comes to getting some Backbone coaching.
  • Got a lot more intimate with JS, CoffeeScript and functional programming in the process. Interesting foray into the require.js / AMD territory with hand-rolled build scripts etc. Dropped that in our latest app, but will eventually slowly build back up a very simple minimalistic pipeline with grunt.js.
  • Lots of time spent on CSS and layout work. Good chunk of time working with boostrap 2.3.2 and bootstrap 3.0.x on both responsive sites.
  • Wrote first unit test suite in JS thanks to buster.js. Actually extremely pleasurable, somewhat close to the testing experience in Clojure.
  • Started working with Clojure half-way through the year. Still very much of an ongoing project, S. Halloway claims it takes at least 18 months for alien superpowers, so I still have plenty of room. Migrated Parse.com-based backend to our Ring app, rewrote all of our clients to use the new REST api instead of Parse’s libraries. Lots of tests on all levels of granularity. App is continuously being refactored as I discover new simpler and more elegant techniques. Infinitely grateful to the folks in #clojure, especially bitemyapp (Chris Allen) for the torrent of tips.
  • Finally got some time re-visit the Dragon Book and put some of that to use for our tentative math interpreter with Clojure + instaparse.
  • Lots of ops work. Never touched a “datacenter” previous to this year, was always hiding behind something like Heroku. Started with AWS EC2, not using any of their convenience services, feeling pretty comfortable with it now. Initially started CM with Puppet, didn’t like it. Switched on Ansible, no headaches whatsoever now. Switched traditional EC2 to a VPC. The system was all Internet-facing for a while, I had to figure out how to setup a VPN for the first time, which was fun. Now all office machines are on VPN and have direct safe access to the datacenter.
  • Lots of Postgres work. Anything from deployment, to administration, to fine-tuning for performance for the given machine. That one was a BIG book, which I still reference every time.
  • Good progress in my understanding of computer networks, still a work in progress. Recently had to setup a DNS server at the office for our Chromebook to be able to reach the sites hosted on my dev machine. Networks is such a good skillset to have when doing ops work, debugging connectivity in various locations such as our school networks.
  • Plenty of Linux administration work. Again, still very much a work in progress. Lots of time spent on bash and Linux/UNIX tools and utilities. Running Ubuntu full time on all of my machines now, including home. Got very comfortable using tmux, and recently switched from Unity to xmonad so that the mouse is halfway useless. Tiling window managers are awesome, but do require some configuration effort.
  • Lots of practice of XP and other Agile practices with a small team. Good experience with cherrypicking which practices to follow and when. Right now the engineering efforts at Front Row are still very manageable, but we’ll need to step things up a bit once more people hop on board and chaos ramps up.

Looking back this has been a pretty fruitful year. Here’s what I hope to work on in 2014:

  • Would be interesting to pursue the interpreter-building route a bit more, see where that goes. Still very interested in getting more practice with building languages.
  • More Clojure work, of course. The language and the ecosystem are like chess: the pieces are very simple, but I can see this taking many years to master.
  • Would love to experiment with Haskell for some internal low-pressure tools, build some experience before considering it for production.
  • More work with scaling out the system. Right now our load is very humble, partially thanks to how the API was designed. If we do our job well at Front Row, then it will be time to start engineering for a more interesting load.
  • More depth with anything infrastructure-related such as Linux, network administration etc.
  • More opportunities to release some of our tools as open-source. I recently put out an early alpha of a Mixpanel client library for Clojure, so I’m hoping to release more of these tiny helpers as I get more experience with designing quality libraries that others actually want to use.
2013 – a retrospective

Clojure’s instaparse TI-style math interpreter

There aren’t too many examples of Clojure’s instaparse use out there, so if you’re working on parsing a little language of your own, I hope this might come in handy.

I’ve been working on a little interpreter for some internal stuff part of the Front Row stack, mainly for validating student answers in the more complex middle school math domains. The interpreting the answer becomes pretty much mandatory for validating things like equivalence of two polynomials. This is what came out from the early efforts.

The EBNF grammar itself can be found here, the implementation of the parser is here (still blows my mind it’s under 50 lines), and the tests are all here. Wouldn’t have touched this with a ten foot pole without testing every single incremental addition.

A couple of resources I found useful, in addition to instaparse’s official docs:

The author of instaparse himself was also generous with a few tips on the library’s Google Groups.

Clojure’s instaparse TI-style math interpreter