Richard Searle's Blog

Thoughts about software

Archive for the ‘Scala’ Category

annotate Datomic transaction to record side effect

Posted by eggsearle on October 13, 2013

Extends previous post to indicate how the transaction can be annotated to indicate the email was generated.

In the general form, this can capture any metadata required to describe process(es) that have been executed, decisions made, etc.




Posted in datomic, datomisca, Scala | Leave a Comment »

Datomic txReport and tracking changes via Datomisca queries

Posted by eggsearle on October 13, 2013

A common web site use case is notifying a user of a change of address, with notifications to both old and new addresses.
This is a simple mechanism that helps to address fraud.

Generally this code would form part of the http post action, perhaps including some indirection via a queue.
Arguably that logic is orthogonal to the primary function of the web site.

Datomic records all changes to entities and provides a notification mechanism

The following gist illustrates how this might be implemented.

Line 39 creates a user with the name “john” and email “”.
Line 44 updates that user, changing the email to “”

Line 46 defines a query that will retrieve the name and previous email, given a delta to the user entity

Line 59 will print empty result since qe is the change that created the user (and there is thus no previous value)
Line 62 creates the result:(“john”, “”,””)
Which provides the name, before and after emails needed to send the warning email.

Posted in datomic, datomisca, Scala | Leave a Comment »

Type providing from SQL provides excellent justification for Scala macros

Posted by eggsearle on August 17, 2013

sqltyped processes SQL statements to extract the DDL details and then uses macros to generate type safe code.

This provides a DRY implementation where the database schema is the master and errors in the referencing code are detected at compile time.


Posted in Scala | Leave a Comment »

Play as an ESB

Posted by eggsearle on July 31, 2013

Back in 2007 Mark Nottingham suggested squid could serve as an ESB , which was probably considered a rather radical idea.  Certainly I never came across any further references to the concept.  This recent Play blog post  triggered my recollection of that half decade old idea.

It has many functions that one might expect from an ESB:

  1. Caching
  2. Rate limiting (via timeouts and return codes)
  3. Proxying (via REST call to external service)
  4. Data conversion (http response to json)

The sample is compact, easily understand and easily extended via composition. (characteristics that are rarely encountered using the big name ESBs)





Posted in play, Scala | Leave a Comment »

scalaz contrib and Futures

Posted by eggsearle on July 24, 2013

The canonical combined Future example is

def c(i:Int):Future[Int] = ...
val f1 = c(5)
val f2 = c(2)
i1 <- f1
i2 <- f2
yield i1+i2

Creating the Futures within the for-comprehension would be much tidier, but then they would execute sequentially ruining the entire purpose.

The scalaz contrib project provides support for Scala 2.10 futures, allowing more expressive coding for some tasks.

This applicative functor expression is equivalent to the above code.

val r:Future[Int] = (c(5) |@| c(1))(_ + _)


Posted in Scala, scalaz | Leave a Comment »

Defaulting type with Scala implicits

Posted by eggsearle on July 13, 2013

This stackoverflow answer shows how a default type can be specified, using some interesting side effects of the Scala implicit rules.

Scala 2.10.1 allows the code to be further simplified

object DefaultsTo {
 implicit def default[B] = new DefaultsTo[B, B]
 implicit def overrideDefault[A,B] = new DefaultsTo[A,B]

The  T DefaultsTo Node looks rather strange but is actually the infix form of DefaultsTo[T,Node]


Posted in Scala | Leave a Comment »

Server Sent Events and Akka IO performance

Posted by eggsearle on November 11, 2012

The experiment was extended with an Akka IO implementation, using as the basis.

Latency is 16ms and CPU load 12%
The former is a little worse than the alternatives and the loading falls between them.
The IO implementation is merely a sample, so there is likely some performance improvement to be had.


Posted in Akka, Scala | Leave a Comment »

Play 2 Server Sent Events and Ajax performance

Posted by eggsearle on October 20, 2012

Consider a “dumb client” Single Page App where the domain logic resides on the server.
The UI events are delivered via Ajax, with the server responses flowing over SSE to update the UI.
This minimizes the size of Javascript code while (hopefully) retaining the responsive interaction.

The key question is thus latency and server load.

A simple experiment wires an Ajax call to the SSE event handler, where the call delivers a new data element over the SSE connection, forming an infinite loop.
That provides a simple measurement of the total request/response chain.

Both Play 2 and Jetty Continuations based implementations were tested, using Fedora Core 17, Google Chrome running on AMD Phenom II X6 1100T.

Implementation latency (ms) CPU Load (%) JRE Load (%)
Play 16 52 7
Jetty 12 5 1

CPU Load is reported by top and JRE Load by JConsole.

Play uses Iteratees and NIO, which are both designed for concurrency rather than raw throughput.
A 10x difference is a surprising high cost to pay for the concurrency and expressiveness of the Play API.

The proposed user case would have less than a score of clients, which would be feasible even with a vanilla block Servlet implementation.

Posted in play, Scala | 4 Comments »

Performance surprising with Scala regexp parser combinators

Posted by eggsearle on August 21, 2012

The various examples generally have the form

def identifier  = """[_\p{L}][_\p{L}\p{Nd}]*""".r

This works fine, but the underlying Java Pattern is recompiled on every reference.

The behavior came to light during an upgrade from Java 6 and Scala 2.7.7 to Java 7 and Scala 2.9.2, when a ~ 10% performance degradation was noted.
Performance analysis indicated an unexpected large number of calls to Pattern.compile.
The Java 7 implementation is evidently somewhat slower.

Changing the def to val resolves the problem, without impact to the semantics.
In this case, the improvement was greater than 30% which  more than compensates for the degradation.

Posted in Scala | Leave a Comment »

The future and promise of Scala is it’s killer app

Posted by eggsearle on April 4, 2012

Essentially every framework and library for Scala is based on or provides extensive support for asynchronous processing.
The title is thus something of a pun, referencing the future and promise functionality that form the the basis of such processing.

NIO was introduced back in Java 1.4, but has remained a niche technology. Even the introduction of netty and grizzly did not bring it into the mainstream.

This progression essentially started with Tuxedo and CICS, very complex and expensive products. JEE containers, ESBs and other variants on the theme reduced the cost and complexity to some extent. It is perhaps hard to remember that Spring first came to life as a way of dealing with the complexity of J2EE. Scala has now reduced this complexity to a library, largely seamlessly integrated into the language.

What was previously a complex and specialized middleware project is now something that “mere” application developers incorporate as a matter of course.
The provision of flags in spec2 and sbt to turn off concurrent processing is an indication of the ubiquity of concurrency in the Scala ecosystem.

These facilities are arriving just in the nick of time to allow effective utilization of multicore processors.

Posted in Scala | Leave a Comment »