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
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
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.
I’ve been using the Matasano crypto challenges to augment my Scala language skills. So far I’d say it’s been worth the effort. As part of the challenges, there is a requirement to find an implementation of SHA-1 in the language you’re using for the rest of the challenges, but calling the framework digest libraries was not acceptable. After spending about 3 seconds not finding an implementation in Scala, I decided to roll my own. Based on the wikipedia pseudocode I was able to do it fairly quickly.
If you’re writing a play application and using an actor, chances are you’re going to want to test that they work. This is pretty straight forward, but what happens when the actor itself needs to frobitz a whatsits every bleventy seconds?
My Scala development has gone from occasionally reading on the bus to actually using it as my primary development language 9-5. Which is awesome. After having done Martin Odersky’s course and having read the stairway book, I’d also recommend Scala for the Impatient to anyone as a second Scala book. The reason I’d recommend it second is that it’s very good at filling gaps that inevitably come up after the fact. (I still strongly recommend the stairway book as well).
I recently found a need for a Cocoa based implementation of a word cloud and ended up throwing one together. I know word clouds provide very little informational value and they’re kinda 2004 but I made it anyways. I’ve released the source under the Apache 2.0 license (as per the usual). More info is available at the Srs Biznas site (or in the case there’s a distant future where Srs Biznas no longer exists, here’s the GitHub link)
As both readers of this blog know, I’ve been working on an OS X client for Planets Nu (A web-based version of the old play-by-email game VGA Planets). The idea was to make something like EchoView for my own use, brush up on technologies I had been putting off and potentially have an app in the Mac App Store that pays for the Mac Developer Program registration fee.
CoreData. It’s one of those looming technologies of Cocoa that people put off. I did, most coders I know did. Mainly because it’s thought of as a big looming technology. If you’re not sure if you need to learn CoreData, take the following quiz: