When you try to learn a new language, a new framework, a new library, etc., you usually go through some tutorials, books or articles. As long as you just follow them (mostly) everything works fine. The day you start doing some serious stuff you learn the flaws of your tools the hard way. Sometimes you can find your way around (either by learning the proper usage or by finding workaround) and sometimes you just find out that the tool is broken.

I used PHP a lot in the beginning og my “journey”. It let me earn first money and get the first real job. And it was perfectly fine then and I still have some good feeling for it. A few days ago a friend of mine showed me this article: http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/. It’s a very good read about the cons of PHP. So if you used PHP, use it at the moment or plan to use it in the feature you should read that :)

When you run tasks in Google App Engine backends you may see the following message appear in your logs from time to time: Process terminated because the backend took too long to shutdown.

At first it migth seem pretty odd. You try to run some code and you are informed that process was terminated because the backend took too long too shutdown. But who actually tried to shutdown the backend server? Certainly it was not me ;-)

If you go to the documentation you can find a few reasons for the backend to shut down:

  • You manually stop the backend using the Administration Console or appcfg backends <dir> stop.
  • You update the backend using appcfg backends <dir> update.
  • Your backend exceeds the maximum memory for its configured class.
  • Your application runs out of Backends Usage quota.
  • The machine running the backend is restarted, forcing your backend to move to a different machine.
  • App Engine needs to move your backend to a different machine to improve load distribution.

The first four are pretty straightforward. If you don’t perform any action and you are good with quota nothing strange happens.

The other two are the trickier ones. It means that Google can shutdown your backend at any time due to some under the hood reasons. It’s cloud so they might need to do some maintenance, load balancing and other stuff at any time.

And what are the consequences? You should design your tasks to take a few things into account:

  • divide big chunks of work into smaller tasks
  • make these chunks independent
  • make these chunks “resumable”

Every task should be ready to be stopped at any moment (actually you can use shutdown handlers and get 30 seconds to clean your work). If possible every task should be able to resume it’s work from where it was left so in case of restart you don’t need to do the same work again. And if you split your work into many tasks it can be distributed among many backends instances. I believe you heard the term map-reduce ;-)

For more information go to https://developers.google.com/appengine/docs/java/backends

If you prefer a hands-on experience to reading books you can try koans for a quick start with Scala: http://www.scalakoans.org/

“Koans are small lessons on the path to enlightenment. The aim of the Scala Koans project is to provide an easy learning environment in Scala. Your insight will be derived by encountering failing tests and fixing them so that they pass. A testing framework is used to simplify this process and to get you off to a good start with using Scala.”

I find it a very nice way to get the idea about basics of scala as a great complimentary to Martin Odersky’s course. Give it a try or search for koans in other languages.

If you want to move to GIT from other (non-distributed) VCS you have to consider the following aspects:

  • how to move my current repository without loosing the history. You will have to (hopefully) do it just once. A lot of people done that, just search the web :)
  • it’s just another VCS but still it’s new for you and the tools will be new. They will be similar (commands, way to show the diffs, etc.) but you will have to get used to them.
  • it is fast. I didn’t use to create so many branches on SVN.
  • the mental shift. And that is the biggest change. It is a distributed VCS. You and your whole team may have a local repository. There are a few strategies to use remote repositories.  You will need to set up a policy how to distribute the changes. And if you are used to “classical” model (one repo, many working copies) this will bring you a lot of new options and possibilities. Try to experiment with them and choose the one that fits you the best.

If you want to have a quick look at Spring MVC appliaction together with the source code, just do the following steps:

  1. Download STS at http://www.springsource.org/sts
  2. Run STS from the downloaded package (STS stands for Spring Tool Suite which is based on Eclipse)
  3. Go to the dashboard
  4. Find the Example Projects section
  5. Click spring-mvc-showcase to download the showcase project

Once the download is complete you can choose Run As -> Run on server from the project context menu. Explore the app and the source code. Opening just a few classes and tests should give you the understanding how it all works.