A Fart In Space

Joel Söderström, currently CTO and partner at a digital agency based in Stockholm, Sweden. These are my humble thoughts.

[afartinspace-blog]

Play 2.0 in the wild

**Last week we released our first web app built with Play Framework 2.0! Being somewhat excited about this I thought I'd jot down some notes about it. Here it goes...** ### A new framework for a new era for a new project Play Framework 2.0 is in fact a **new** framework. Some people don't appreciate the newness of 2.0. I have read about the [community split in two](http://playframework.wordpress.com/2012/04/01/community-split-in-two/) a while ago which is partly the reason why we didn't take it out for a spin earlier. When this project landed on our doorstep I felt like it was time to step out of the comfort zone and get going with 2.0. After all, being afraid of the *new* is not a quality I value. Especially not for a developer. The project itself was a relatively simple web application which could be summarized like this: * Public site with... * …a secured user area * …a secured admin area * Read-only, public JSON REST API * File upload to Amazon S3 * Email sending * Hosted at heroku * PostgreSQL * All java, except from parts where scala is required * Should scale horizontally and be able to handle large amount of requests during a short period of time There were no tricky integrations with other systems or any other platform requirements. Just a webapp coded from scratch where the clients biggest concern were time-to-market and scalability.  ### A productivity booster? When we first started out using **Play 1.2** about a year ago we were blown away. The productivity boost was enormous. At that time my main project was a Spring MVC/JSP/Hibernate stack which we had been hacking on over the last couple of months. Now all of a sudden I had this new exciting framework at my fingertips. Declaring all those static methods in my controllers and then hitting reload in my browser made me feel rebellious, excited and a bit nervous. Nervous about the fact that [Joshua Bloch](http://en.wikipedia.org/wiki/Joshua_Bloch) would tap me on my shoulder - ask me politely to read that book of his (Effective Ja…) and give me a real good hard punch in the face so that I forgot about all this static nonsense. Needless to say, my expectations were high to see if Play 2.0 could even more boost our productivity. The short answer is: **NO**.  **Compilation and hot reload is much slower.** Making changes in a view and then hitting reload takes about 10 sec for me (2011 Macbook Pro, 8 gig RAM). Reload time depends on size of the project - adding more views, classes and assets would probably make it even slower. It seems like the root of the problem is scala compilation time, which is considerably slower then java compilation. On the upside it's getting better and better and one could think that the people behind Play and Scala (Typesafe) puts a lot of effort in tweaking this. **The assets pipeline** enables you to let play compile and minify LESS and CoffeScript out-of-the-box. We already use LESS as much as possible and it's a real productivity booster. However, we decided not to use CoffeeScript. We simply didn't want to invest time in learning it at this point. **IDE support** works as expected. I use IntelliJ IDEA and always have an open terminal running where I start/stop server and run tests. I have always liked this way of working, so I didn't really explore all possibilities on how play/sbt integrates with my IDE. Someone with a different workflow that is more IDE centric would probably have something to add here. Debugging worked without any problem (runt test with: "play debug test" or start console with "play debug", then connect your debugger). **Views and routes are all compiled**. I think this is great. I often end up with strange issues due to refactoring in the view layer. Having this compiled and being able to catch errors directly in the browser makes it a lot easier, more than I initially thought it would do.  **Scala views are a bit more verbose**. Type safety comes with some extra code, that's okay, but I still feel like something is missing. I want stuff like the magic **elvis operator** in Groovy and how do I [declare a simple variable](http://stackoverflow.com/questions/12031146/declare-variable-in-a-play2-scala-template) anyways ;) For our next play project I will definitely invest more time in learning and understanding Scala and the template engine better. **Documentation** for Play 1.2 was extremely well written. The documentation for 2.0 is not up there yet. The framework is a bit more complex now, and the documentation will get better. I paid many visits to the user group and SO to fill in when needed. When it comes to the best documentation of all - the source code - it's a bit of a pain since the core is written in Scala (I speak java fluently, Scala like a 3-year-old but I am getting there). ### Right tool for the job? How many times have you heard the phrase *"it's a mater of finding the right tool for the job"*? Clever people say that… ...and then the same guy goes on and chooses Spring + JPA/hibernate + a relational database. I identify with that guy. Our game is not in the enterprise (as in large scale transaction heavy systems). However from time to time we end up being part of a web project with *enterprise-ish* requirements. We haven't had the guts to choose Play for such a project... yet. Play 2.0 has great potential in changing this. Knowing more about **sbt**, **akka**, **Scala** and **modularization** will unlock even more powers that 2.0 possesses. Also, the fact that Typesafe acquired Play is an important point here. Having a large and credible organization backing up the project will be a decider in some cases. ### Conclusion During this first exploration I didn't come across anything in Play 2.0 that I couldn't achieve in Play 1.2. It is also apparent that things are solved differently compared to 1.2 and those changes are sometimes not an improvement. At least not from a developers productivity perspective. **This is not the point though.** Taking a step back, looking at the big picture, I would say that Play 2.0 still lets the developer enjoy rapid development and fast turnaround compared to most other frameworks out there. It simply feels more future proof. I am definitely going to continue to use Play 2.0 for future projects and would *love* to see it as a new multi-tool in our Java shop. Over and out, *Joel*

[afartinspace-blog]

Multiple environments in Play Framework 2.0

Short story: You need a way to handle configuration for multiple environments. Typical scenario is that you have different configuration for dev, staging, CI and production. This was pretty easy last time I did it in Play 1.2.x by using the **%prod** prefix and framework id's. Now that I am (finally) getting my feet wet in Play 2.0 I see that things have changed. We still have [three static modes](https://github.com/playframework/Play20/blob/master/framework/src/play/src/main/java/play/Play.java#L18) - dev, prod and test - but these doesn't affect how properties in conf/application.conf are parsed. Instead the [proper](https://groups.google.com/d/topic/play-framework/8DAMyY6OkqE/discussion) [way](https://groups.google.com/d/topic/play-framework/1c53g6P8Dsw/discussion) of doing this seems to be to provide different config files for different modes and specify which one to use as a JVM argument: play -Dconfig.file=conf/prod.conf start There are different JVM properties depending on if you want to use config file located in the classpath (use *config.resource*), external file (use *config.file*) or URL (use *config.url*). These are documented in detail [here](http://www.playframework.org/documentation/2.0.2/ProductionConfiguration). > NOTE: At the time of writing (Play 2.0.2) I can't get *config.resource* to work when starting app in dev mode (using **play run**). Instead one can use *config.file* which, if using a relative path, points to project root: **play -Dconfig.file=conf/prod.conf run** A nice feature is that configuration files can include and override other files. This means that we may have a base config file and then use niched config per environment/mode that extends the base. It ended up like this: * conf/**application.conf** - "base", dev configuration that has an in-memory database * conf/**staging.conf** - includes application.conf and overrides database properties * conf/**prod.conf** - includes application.conf and overrides database properties prod.conf looks like this: include "application.conf" # Override db properties from application.conf db.default.driver=org.postgresql.Driver db.default.url="jdbc:postgresql://localhost/my_prod_db" db.default.user=db_user db.default.password=secret_prod_password # Tweak logging for prod logger.application=WARN If you host your app on [heroku](http://www.heroku.com/) it's pretty simple to set which config file to use in the Procfile: web: target/start -Dhttp.port=${PORT} -Dconfig.file=conf/prod.conf ${JAVA_OPTS} --- ####References: * http://www.playframework.org/documentation/2.0.2/ProductionConfiguration * https://groups.google.com/d/topic/play-framework/L-Do4qTmArw/discussion

[afartinspace-blog]

Manage FTP deployments with git

In some projects I work on the deployment is done by uploading files to a FTP server. This the typical approach in a "standard" shared hosting environment.

I don't like it.

It has happened more than once that a collaborator that isn't aware of (or doesn't care) simply overwrites your changes. Also, I am a CLI kind of guy and would like to be able to upload code straight from the console.

For these reasons I have researched ways to integrate git to handle deployments in a better, more efficient way. What I've found? git-ftp - it's pretty sweet!

Here is how to do it:

# 1. Install $ git clone http://github.com/resmo/git-ftp.git $ cd git-ftp $ git checkout master $ sudo make install # 2. Init and configure git-ftp for existing git project $ cd my_project $ git config git-ftp.user joel $ git config git-ftp.url ftp://ftp.afartinspace.com/public_html $ git config git-ftp.password qwerty $ git ftp init # 3. Use $ git commit -am 'a commit' $ git ftp push

All in all I think this is pretty darn good! But git-ftp is missing out on an important feature: pull/fetch. What happens if that designer guy uploads a bunch of new images using a regular FTP client? As now these files cannot be merged into your git project in a simple way. Ideally it would be nice to be able to do something like: git ftp pull to download changes.

Conclusion

Git-ftp makes it easier for those familiar with CLI git to handle ftp deployments. BUT be prepared for weird stuff to happen if you know that other collaborators will work with code using a traditional ftp client.