Handling Dependency Injection in Scala Test Cases With TestNG

This is a short post about using Guice dependency injection in Scala test cases that are configured with TestNG annotations. The two interesting points are

  • How in Guice do you override production dependencies with test ones when you want to execute a test case?
  • How do you use TestNG with Scala?
Read on →

Using Spring Transaction Support With Scala

What’s the best way to use Spring’s transaction management features from a Scala program? This is my second attempt to come up with an answer to that question.

My preference for Spring transactions with Java is to use the @Transactional annotation. I’d like to be able to achieve the same effect in Scala.

The intention for the Java annotations, and what we want in Scala, is to

  • Have some piece of code execute inside a transaction.
  • Be able to specify the behavior of the transaction.
  • Don’t overwhelm the rest of the funactionality with the transactional code.
Read on →

Finagling

I’ve been playing with Finagle, or “Finagle, from Twitter” as the site refers to it, to see whether it will work for me as a framework to support a simple http rpc/rest server. The Finagle documentation is good but I wanted to explore in a complete simple example how I could implement

  • Catching execptions from underlying services and returning 500 response codes to clients.
  • Returning a timeout response if the underlying service takes too long to respone.
  • Separating common process, such as extracting values from headers, from more specific service handling.
  • Mapping from urls to services.
  • Executing service code on a separate thread from the request processing thread.
Read on →

Rotating to Show Different iOS Views

In the tradition of explaining fairly simple things at great length this approach is based on the documentation from Apple describing Creating an Alternate Landscape Interface and various answers on stackoverflow. It differs from the information I could find on the internet because the flow includes a navigation controller and uses a storyboard. The flow between the screens in the interface is shown in the diagram below.

Flow

There is a first screen, A, that has two alternate views, one portrait and one landscape. These can’t be created using the springs and struts layout tools. Rotating the phone while screen A is showing should switch between the two views. Tapping some element on screen A, in either view, transitions to screen B. Screen B handles rotation itself by redrawing its interface in drawRect:. Going back from B should show the correct version of A. There’s a navigation controller wrapping the whole interface that provides the navigation bar and button in view B to go back to view A.

Read on →
iOS