This goes out to all the professional software developers out there working with time constraints just trying to get their job done. Dependency injection (DI) is one of those kinds of concepts that fall through the cracks and becomes assumed knowledge at some point. At a high level it means anything your classes depend on are passed in (usually via a constructor) and it helps make more testable code. Does that make sense? No. not even a little bit. That explanation is terrible.

Comments are a source of contention with many developers. I don’t think that is a shocking or contrarian viewpoint. Generally people have opinions that fall into one of three camps.

In the last post, we added a user interface with React and CoffeeScript to have something other than raw API endpoints to interact with. In this post we will take a look Cross-Site Request Forgery and how it can be mitigated before it becomes a problem.

In the last post, we added another API method to query ticket blocks by respective events while extracting the availability of the tickets in the block. In this post we will take a step back from the back end and give our user interface an overhaul using CoffeeScript-driven React components, replacing our current reliance on server side templates.

In the previous post, we added actors to handle concurrency in a more sensible manner inside of our Play application. In this post we add another API endpoint, relying further on our existing actor model and creating a new method for operating on Futures.

In Part 3, we built out the API and learned how to access a database from inside of our Play application. In this post we will take a deeper look at concurrent requests, utilizing the asynchronous tools at our disposal to fix some concurrency bugs that were introduced in the last section.

In Part 1 we covered routes, controllers and client side scripting which led to a very basic and not very useful result. In this post we will walk through what is required to read, write and maintain a database for Ticket Overlords. The technologies we will be using are Slick 3.0 and Evolutions.

In Part 1 we covered routes, controllers and client side scripting. In the time since that post, the Play framework released version 2.4 (Damiya) on May 27, 2015. With a major point release there are usually enough changes to warrant taking some time to rebuild a few things. Since the ticket-overlords project is still fairly small, the effort will be minimal. This gives us a good opportunity to take a look at what is entailed in performing a framework upgrade.

This is the first in a series of posts about writing a web application with the Play Framework in Scala. For the purpose of these posts, we will be writing an online concert ticket store named TicketOverlords. Some things will seem goofy or strange at first because not everything will be developed correctly the first time.

About thirty minutes after I finished the last post on the SHA-1 implementation I got to the part that required an MD4 implementation and started to get right to work.