• Lessons learned from serverless application development

    I’d like to share some experience from serverless pet project - photo gallery. The idea was to be able to browse family photos backed up to Amazon S3 storage service. They should not be publically available - only authenticated users must be able to browse. When browsing the photos they must be resized to screen size in order to avoid excessive traffic, resized photos must be cached for subsequent requests.
  • Are RESTful APIs over-valued?

    Nowdays RESTful APIs are usually considered to be the only reasonable way for communication between back-end and front-and, and default approach for communicating between separate back-end services. Lot of people consider RPC (remote procedure call) as a curse word. “It’s not RESTful”, “This is RPC” is often used as an ultimate reason why certain API should be discarded, and another designed instead. I used that grounding quite a bit as well, but such reasoning has a cargo cult smell.
  • Mockito and default parameters in Scala

    Suppose we need to mock such service and verify that doSomething is called exactly once, and then no interaction happens with the service: class SomeService { def doSomething(from: Int = 0, to: Int = 10): Unit = { //... implementation ... } //... other methods ... } A common approach to do it: val serviceMock = Mockito.mock(classOf[SomeService]) //run tested code which invokes this: serviceMock.doSomething() Mockito.verify(serviceMock).search(0, 10) Mockito.verifyNoMoreInteractions(serviceMock) But here’s surprise: it fails with such error message:
  • Play, ScalaTest and afterAll: There is no started application

    Recently I was trying to do some cleanup of shared DB after the tests (with ScalaTest) of Play application using afterAll method of BeforeAndAfterAll trait. DB credentials were contained in Play’s config files so cleanup code relied on running play application. But when trying to run the test I’ve got an exception: java.lang.RuntimeException: There is no started application Looks like application was shut down before afterAll gets started. Turns out that traits inclusion order matters here.
  • Why I dislike Scala enums

    I came to conclusion that even in fully-Scala projects it’s better to define enums using Java. Even third-party libraries that have support for Scala enums suffer from the fact that in runtime all Scala enums have the same type. So if you get some enum value - you have no way to tell to which enum type does it belong. Let me show you how bad it can be with json4s.
  • Generics with Play JSON

    As Play JSON library uses implicits in order to know how to serialize/deserialize some object the type of that object has to be known at compile time. This makes serializing/deserializing generic classes not that straightforward - even if you know at compile time type which is substituted in generic class type parameter, you need to provide somehow reads/writes for each such type, not just for single generic class. The trick is to use def instead of val.
  • Cross-version testing with SBT

    I’d like to share my experience on testing versions compatibility with sbt. The system which had to be tested consists of server (Play application) and a client - library that exposes server functionality to other apps. Not all apps that use client library may be updated fast enough with new version of server, so before deploying new server version we must check that client versions which are in use currently keep working.
  • Scala Parser Combinators Quickstart

    Parsing may be a challenging task. And it’s amazing how Scala Parser Combinators make it doable for regular human beings. You can easily describe how to parse simple things like identifier, string constant or argument list, and then combine these simple parsers into more comples ones. I’d like to describe here step-by-step how to get that brilliant library working for you. No deep theory or specific features, just bare minimum to get started with typical tasks.
  • Java Enums in Play Json

    I prefer using Java Enums even in Scala code, because unlike Scala enums they’re distinguished by actual type, not just type parameter. Thus they still can be distinguished after compilation, unlike Scala enums which end up as the same type after type erasure (at least if not taking into account experimental tricks like type tags). Unfortunately, Play doesn’t have built-in support for Java enum serialization/deserialization to/from JSON at the moment (v.
  • Play Json date format customization

    By default Play Json just truncates time zone when working with ZonedDateTime from Java 8. So the following code: case class MyClass(createdAt: ZonedDateTime) implicit val myWrites = Json.writes[MyClass] ... val d = MyClass(ZonedDateTime.parse("2015-10-01T12:13:14.00+02:00")) val json = Json.toJson(d) would produce following Json: {"createdAt": "2015-10-01T12:13:14"}. That’s because play.api.libs.json.DefaultWrites.DefaultZonedDateTimeWrites uses same formatter as DefaultLocalDateTimeWrites and simply disregards time zone. To display the time zone together with date time you’ll need to add following code before myWrites: