harryh

Lift 2.0!

Big congrats to David Pollak and the rest of the Lift team on getting the 2.0 release out the door.

I first started diving into Lift back in April of 2009 when I was doing some deep thinking about what platform to rewrite foursquare on.  I was already moderately familiar with, and very enthusiastic about Scala.  The prospect of a Java like language running on the JVM but with a much less verbose syntax and support for functional programming paradigms was very very appealing.  However, I didn’t want to have to write a web framework from scratch, so I was seriously considering using something like Wicket or Rails (even though I’m not the biggest fan of languages that aren’t strongly typed).

Eventually though, not even sure how, I stumbled across Lift and was immediately very impressed.  The BIG IDEA that ajax operations should be simple closures is very compelling to me (even with the tradeoff of stateful servers.  An issue which a scares some but we haven’t found to be too much of a problem).  It allows us to extremely rapidly, and securely develop complex ajax web pages with very little code.

Soon after, I ported foursquare to the platform (which took about 90 days, which isn’t too bad) and it’s been terrific ever since.  We’ve scaled up to close to 2M users, and 1M checkins/day. Traffic currently peaks at close to 1000 requests/second (distributed to about a dozen app servers).  We’ve gotten tremendous help from the lift community, from a very responsive google group, to David taking tons of time out of his busy schedule for personal attention.  Whatever few bugs we’ve run into have been fixed extremely rapidly (often in < 24 hours).

In addition the use of scala has turned out to be a great recruiting tool.  It’s a new and exciting language, and strong developers are interested in learning more about it and using it in a professional context.  We’ve hired up a an awesome team, several of whom are here due to our use of scala.  If you’re thinking about using scala (and lift!) don’t let recruiting worries get in the way.

Over the next year or two we hope to scale up foursquare in every possible way: team, users, requests, checkins, features, and I’m sure that being on the Lift platform will help us reach these goals.

For those interested in additional information, I’ve given a couple of presentations on Lift and Foursquare’s use thereof that can be found here and here. If you are considering using Lift in a professional fashion somewhere I’d be happy to talk to you about my experience with it. I’m easily found on twitter as @harryh.  There are also numerous scala meetups around the country all with very knowledgable participants.

trival backgrounding with scala actors

A simple backgrounding object:

object BackgroundOperation {
   def apply(f: => Unit) = {
     BackgroundActor ! BackgroundJob(() => f)
   }

   case class BackgroundJob(f: () => Unit)
   
   object BackgroundActor extends LiftActor {
     protected def messageHandler = {
       case BackgroundJob(f) => f()
     }
  }
}

Then you can do this whenever you want:

BackgroundOperation {
  // some complicated thing
}

Scala Puzzler of the day

Many different database objects in foursquare have a foreign key to User.  So I wrote something like so:

object User {
  trait FK[T <: FK[T]] extends LongKeyedMapper[T] {
    self: T=>
    object userid extends MappedLongForeignKey(this, User)
    def hasUser_? = userid.defined_?
  }

  class FKList[A <: FK[A]](list: List[A]) {    
    def primeUsers: List[A] = {
      if (!list.isEmpty) {
        val uids = list.filter(_.hasUser_?).map(_.userid.is)
        val users = findAll(ByList(User.id, uids))
        list.foreach(item => {
          item.userid.primeObj(users.find(_.id.is == item.userid.is))
        })
      }
      list
    }
  }
}

So that things can extend User.FK[Foo] and get automatic extra functionality for dealing with their User parents.  But you’ll notice that the field name is hard coded in the above.  Some things have two user parents.  For example Venues have creators and mayors.  Is there some way to enhance the code above so that a single model can extend User.FK twice with different field names?  Pondering what might be a good way to do this.

NFL Suicide League

I’m 12 weeks into my NFL Suicide Leage.  So far I have used up: Baltimore, Washington, Dallas, Chicago, Pittsburgh, Green Bay, New England, San Diego, Seattle, Minnesota, Jacksonville, and Cincinnati.  Looking ahead to the remaining 5 weeks I see these two as the best options:

OPTION 1:

Indianapolis over Tennessee
NY Jets over Tampa Bay
Arizona over Detroit
New Orleans over Tampa Bay
Denver over Kansas City

OPTION 2:

New Orleans over Washington
NY Jets over Tampa Bay
Denver over Oakland
Arizona over St Louis
Indianapolis over Buffalo

Any thoughts?