Wow, more than a year has passed since the last blog post. Time for an update.
When we started creating fleetdna.com, we iterated quickly using the ORM built into Lift: Mapper. It is a fairly simple (in a good way!) ORM based on the Active Record pattern. It comes with builtin support for things like CRUD screens etc. This allowed us to create functionality fast, essential in a new company trying to get a product to market.
Fast forward a few years. As product complexity grows, the simplicity of Mapper and the tight coupling of data to UI was becoming a burden. It was not possible to create the more advanced queries without running into the N+1 problem. We also needed to present and edit information in the UI which is not directly related to single records. Basically we are moving towards a more task based UI.
This is a quick intro to developing Lift (the framework, not applications using Lift). Mostly useful for people wishing to work with the code base (like committers).
Just to reiterate: This is not for developing Lift applications. If you need to navigate the Lift source code (highly recommended btw!), have your build tool of choice download the source jars and attach them to the Lift jars in your project.
So, it has been quite a while since the last update on this blog. Time to do something about it and build a real-time social application using lots of new and shiny technology!
In this article I’ll describe the setup I use to do develop Lift applications. While more heavy-weight than if an interpreted language is used, I find this setup provides fairly decent turnaround times.
For the last year or so, I’ve been using the Lift web framework to develop our B2B SaaS application (my experiences can be found here). I’ve enjoyed this very much, especially the community, so when David Pollak asked me to be become a committer I couldn’t say no :-)
One area where Lift is lacking is in documentation, so I’ll try to write a few posts here that can help people getting started using Lift. I’ll be writing about the workflow we use, since
- It works for us
- It is not using Maven, a source of some ….. frustration for many
There are many choices to be made when starting a new project. In this post I’ll try to explain our technology choices and the experience we’ve had so far.
One of the nice things about starting a new project in a startup is the freedom of choice when it comes to selecting platform and tools. You can spend an awful lot of time mulling between the different choices, but in the end, it is usually not the choice of programming language that kills a startup.
First, a little background. I’ve been programming for more than 15 years in C++,VB,C#, Java,Perl & PHP. The last 5-6 years it has been mostly enterprise Java. When I started at my last job (another startup) we had a product implemented in Java that we turned into a SaaS platform. The core remained in Java and much of the web frontend was implemented in PHP. I really liked the productivity we got out of PHP as compared to the Java code. Very fast turnaround times. But somehow the language/platform doesn’t really turn me on.
I wanted to convert some youtube footage to mp3 by using the Firefox addon DownloadHelper together with ffmpeg.
Ok, installed ffmpeg on OS X using MacPorts:
sudo port install ffmpeg +gpl +lame +x264 +xvid
Tried to convert a file. Got this error:
[libmp3lame @ 0x1804600]lame: output buffer too small (buffer index: 8360, free bytes: 1432)