What the name "lightbend" means to me

I thought that it'd be useful to share my personal perspective on the meaning of our company name change. Here are the contents of an email that I sent out to everyone within Lightbend, and which was warmly received.

---

Hi fellow lightbenders,

I’m very excited about the Lightbend name, and want to provide my view on what it means to me.

About two years ago, I presented at YOW. YOW is a great conference with the characteristic that speakers get to talk to a cross section of our industry on three occasions: Melbourne, Brisbane and Sydney. One is therefore not preaching to the converted, but rather talking to what can be quite a hostile crowd!

My first talk was to a few hundred people in Melbourne - apparently the most hostile of the three cities. About ten minutes into the talk I had that sinking feeling that I’d lost everyone. My talk was about Akka streams and the importance of back pressure. Lots of blank looks all around. An interesting aspect of YOW is that you are scored by the audience. You guessed it, my scores were low.

Travelling up to Brisbane I felt that it was important to bring the talk back a bit. Instead of delving right into Akka streams, I felt that I should at least have a preamble around reactive streams and why we did that. The Brisbane talk went much better.

However given the nature of the questions asked after my talk I felt that I could do even better. So, for Sydney, my preamble included a discussion on “why reactive”. This set the scene for the remainder of the talk and my Sydney scores reflected that.

Coming away from YOW I realised how fringe Typesafe were - again this is two years ago. I certainly appreciated that we were not anything near mainstream, but really, we were on another planet compared to where the IT industry was at.

Roll forward to today and you can see that we’ve come a long way. We have done so without deviating on our mission from an technical perspective. I would tell people that if you want to understand anything about our technical direction then simply read the Reactive Manifesto. You'll then see our DNA blueprint; the very fabric of what we are. Taking that further and quoting Jonas Boner, “without resiliency, nothing else matters”. We have upheld the manifesto and, in particular resiliency, like nothing else matters.

And now we are seeing the industry finally come our way. To highlight a few points, the industry received our new name well, it is excited about Lagom as a microservices framework for Java and the enterprise leading Spring framework is effectively adopting the reactive manifesto.

This is where the lightbend name kicks in for me.

I see lightbend as the gravitational force that is bending the light beam representing the direction of the industry at large. Gravity bends light.

To use my earlier analogy of Typesafe being on another planet, two years ago, we were light years away from where the industry was thinking. We are no longer. We have pulled the industry to the way we think software systems should be put together and managed.

We are now at an interesting juncture. As the company expands as it needs to, it would be easy to compromise our technical mission in order to gain further traction. However it is now more important than ever to stay on mission.

We need to be brave and continue to be bold. The industry doesn’t need more of the same; it needs more companies like us.

Thanks for reading!

Kind regards,
Christopher

Where FP meets OO

A strong feature of Scala is the embracing of both Functional Programming (FP) and Object Orientation (OO). This was a very deliberate and early design decision of Scala in recognition of the strengths of both approaches over the decades. I hope to show you that utilising both approaches to developing software can work together.

Over the past two years of using Scala on a daily basis I’ve found myself adopting a predominantly FP approach to development, while embracing true OO in the form of Akka’s actors. What this boils down to is side-effect-free programming with functions focused on one purpose. Where state is required to be maintained, typically for IO style scenarios, then actors come to the rescue. Within those actors if there are more than 2 state transitions then I find myself using Akka’s FSM where upon it maintains the state through transitions. As a consequence, there are very few “var" declarations in my code, but I don’t get hung up on their usage where the code becomes clearer or there is a performance advantage in some critical section of code.

I can’t even remember the last time I used a lock of some type...

Thus my actor code looks something like this:

object SomeActor {
  def props(): Props =
    ...

  // My actor’s other pure functions, 
  // perhaps forming the bulk of code. 
  // The functions are typically private
  // to the package and therefore 
  // available for tests within the
  // same package. 
}
 

class SomeActor extends Actor {
  override def receive: Receive =
    ...

  // Functions that break down the 
  // receive handling calling upon the
  // pure functions of the companion and 
  // possibly other traits
} 

What I find is that as I expand the companion object with pure functions, patterns of behaviour emerge and its functions are factored out into other traits which of course become re-usable and remain highly testable. Sometimes I form these behavioural abstractions ahead of creating the companion object, but more often than not it is the other way round. I’m big on continuous re-factoring and spend a lot of time attempting to get the functional abstractions right. This can mean that the functions are often re-written once the behavioural patterns emerge.

So why then is the above representative of OO? Actors permit only message passing and are completely opaque to the outside of their instance. This is one of Alan Kay’s very early requirements of OO. Actors combined with Scala also mostly fit his following requirements (taken from http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented):

1. Everything is an object.
2. Objects communicate by sending and receiving messages (in terms of objects).
3. Objects have their own memory (in terms of objects).
4. Every object is an instance of a class (which must be an object).
5. The class holds the shared behavior for its instances (in the form of objects in a program list).
6. To eval a program list, control is passed to the first object and the remainder is treated as its message.

Point 3 is a weak point of the JVM and one should be careful about message payloads remaining immutable, but at least with Scala, immutability is the default way of coding. It’d be great if actors themselves had their own address space. However this has never raised itself as a problem in my world.

Scala is one of the few languages that marries the world of FP and OO and thus does not need to “throw the baby out with the bathwater”. Many other languages force you to make a choice. That said, just like most marriages, there’s always the dominant party making the most sense, and that’d be FP!

Reflections on Java, JavaScript and Maven for 2013

About a year ago I made some predictions on Java, JavaScript and Maven for 2013. There has been some movement, so time to report back:

Java

Java 8 didn't quite make it as a GM release, but mid-March 2014 now appears to be the date. Java 8 has been available for playing with for some time during 2013 though.

I must confess to having been excited at the prospect of Java 8's lambda support a year ago, and I still think that what's coming is a great boost to the language. However I'm now squarely in the functional camp and, well, Java simply won't cut it. If you have an interest in functional programming, my personal recommendation is to move to a language designed for the job. Languages such as Scala which offer the best of the imperative and functional worlds are the ones to look at.

JavaScript

This one is mostly pinned to the release of Java 8 and Nashorn - DynJs hasn't really taken hold as I thought it might. So, may be March 2014 for this also.

Projects such as Trireme are particularly interesting as they bring the Node API to Rhino. I suspect that projects like this can be adapted to Nashorn, and I also see that Nashorn may provide its own Node API implementation, although the details on this are light. No matter what happens regarding Nashorn and its Node offerings, I suspect the Trireme and Rhino combination will remain relevant for some time given their Java 6 focus.

Maven

Maven continues to be strong however my hope for an alternate DSL for the pom hasn't materialised… sort of… Tesla polyglot is ready for a release and offers Groovy, Ruby and Scala DSLs for Maven. I actually wrote the Scala dsl :-)

I suspect that Tesla polyglot will be released sometime during the first quarter of 2014.

Conclusion

I feel that my predictions were largely on track, although they certainly haven't materialised within the timeframe that I expected. There's been considerable progress across all three fronts though and I'd be very surprised if they haven't materialised by the first half of 2014.

Play-ing with WebJars

One of my responsibilities on the Play team is to enhance the JavaScript development experience. We will shortly be releasing a strategy document on what is coming for Play 2.3 in this regard. As a preview though, one of the things the strategy will be advocating for is the use of WebJars. WebJars are JavaScript web libraries deployed to well known repositories including Maven Central. There are many popular JavaScript libraries already available as WebJars and the number is increasing.

Preamble

Why is there a need for WebJars? Managing the versions and dependencies of JavaScript libraries is just as important as for any other language. WebJars utilises familiar and established repositories instead of relying on newly introduced ones. I don't think that this can be understated; many organisations are already using and hosting Maven and Ivy based repositories so it makes sense to leverage them. To further support this, over 8 billion downloads occurred on Maven Central in 2012.

Why is dependency management important for JavaScript libraries? Some libraries are standalone of course but others are not. Many popular libraries have dependencies and it is the responsibility of the developer to source them and ensure they are available before the target library is sourced e.g. the popular bootstrap library depends on jQuery. Having a system that automatically manages the complexities of dependency management makes the JavaScript programmer more productive. WebJars enable such systems to be used.

The Play Framework makes it easy to build web applications with Java & Scala. Play is based on a lightweight, stateless, web-friendly architecture. What we on the Play team have done as a first step is extend the work of my colleague, James Ward, so that WebJars offers first class support of requirejs when used with Play. Requirejs is a popular implementation of the AMD specification - a means by which JavaScript applications can be modularised. The easiest way of thinking about AMD is that it is JavaScript's equivalent of package and import statements (or namespace and include statements depending on your preferences!).

JavaScript and Play

The first thing to state is that we want to make developing web applications in conjunction with Play as familiar as possible when it comes to authoring JavaScript. To use a WebJar the programmer declares its dependency in Play's Build.scala file. This file describes a Play project in a similar way that a Maven pom or NPM's package.json would. Here's what a typical build file looks like using a variation of the angular-seed project extended for Play and WebJars:

object ApplicationBuild extends Build {

val appName = "angular-seed-play"
val appVersion = "1.0-SNAPSHOT"

val appDependencies = Seq(
 "org.webjars" % "angularjs" % "1.0.5",
 "org.webjars" % "requirejs" % "2.1.1",
 "org.webjars" % "webjars-play" % "2.1.0-1")

val main = play.Project(
  appName, appVersion, appDependencies)
}

What is important to note is that the variable declared appDependencies specifies a list of WebJars that are required directly by the project. angularjs, requirejs and the webjars-play plugin are declared along with their versions. webjars-play actually depends on requirejs and so the above dependency declaration is not strictly required. However it is there to show that whatever requirejs version is declared by webjars-play, a different version can override it e.g. webjars-play depends on requirejs version 2.1.1 and so when requirejs version 2.2 is released then 2.2 can be specified above.

Knowledge of Scala is not required in order to declare dependencies. The above constitutes the total amount of Scala that the JavaScript programmer will be exposed to (unless they wish to delve into Scala which we would actively encourage of course!).

The WebJars website allows the easy selection of a WebJar and its version and then outputs the declaration required to download it for Play, SBT, Maven, Gradle and others.

The next requirement is to tell Play how WebJar assets are going to be resolved. Play's conf/routes file is used to do this. Here is the part of the routes file for the angular-seed-play project concerned specifically with WebJars:

# Obtain require.js with built-in knowledge of 
# how webjars resources can be resolved

GET /lib/require.js controllers.WebJarAssets.requirejs

# Enable webjar based resources to be returned
GET /webjars/*file  controllers.WebJarAssets.at(file)

The above tells Play to return a wrapper of requirejs whenever /lib/require.js is requested. This wrapper configures requirejs so that it knows how to resolve files hosted within WebJars. The /webjars declaration takes a file path and locates the corresponding resource from a WebJar.

The JavaScript programmer need do very little else to have Play deliver a JavaScript application.

Requirejs usage

Declaring the use of requirejs should look quite familiar. Here is a sample HTML snippet:

<script data-main="js/app" src="lib/require.js"></script>

Given the routes declaration from the previous section the above will bring in js/app.js after requirejs has been loaded. Note that Play must also understand the routing in terms of how to load resources from the js path:

GET /js/*file   controllers.Assets.at(path="/public/js", file)

Here is what the angular-seed-play js/app.js file looks like with the less relevant bits removed:

require([
  './controllers', 
  './directives', 
  './filters', 
  './services', 
  'webjars!angular.js'], function(controllers) {

  // Declare app level module which depends on filters, 
  // and services
  ... 

});

The first few lines of the require statement declare dependencies on JavaScript files relative to the current one via the ./ convention. These files are required for the angular-seed project itself. The line of interest for this topic though is "webjars!angular.js". What this does is call upon the WebJars requirejs plugin to load a file that is contained in a WebJar declared as a dependency.

…and that's about all there is to it.

But wait, there's more...

Let's say that bootstrap is required. Bootstrap has a dependency on jQuery. Ordinarily the JavaScript programmer is required to ensure that jQuery is loaded before bootstrap given its dependency. When using bootstrap's WebJar, jQuery is declared as a dependency such that:

require(["webjars!bootstrap.js"], function () {
  ... 

});

...will automatically load jQuery. This is achieved given that bootstrap's WebJar declares how jQuery is to be located within a repository. Here's a snippet from the bootstrap WebJar pom.xml file:

<dependencies>
  <dependency>
    <groupId>org.webjars</groupId>
    <artifactId>jquery</artifactId>
    <version>1.9.0</version>
  </dependency>
</dependencies>

The other thing that bootstrap's WebJar provides is a file named "webjars-requirejs.js" in a well-known location within the jar. Here are the contents of that file:

requirejs.config({
  shim: {
    bootstrap: [ 'webjars!jquery.js' ]
  }
});

The above declares to requirejs that whenever "webjars!bootstrap.js" is depended on, "webjars!jquery.js" will be loaded first. requirejs.config along with the shim property is standard requirejs configuration. In addition to requirejs behaviour, whenever a "webjars!" module is specified we strip off the "webjars!" prefix and the ".js" suffix and end up with a module name i.e. "bootstrap" in the case of "webjars!bootstrap.js". This module name is then looked up within the shim property of requirejs.config and, if found, the dependencies that are declared are loaded prior to bootstrap.

One more thing...

If there is a requirement to avoid using "webjars!" in JavaScript AMD dependencies then something like the following can be done:

define("jquery", [ "webjars!jquery.js" ], function() {
  return $;
}); 

Thus any time that "jquery" is specified as a dependency its webjar will also be loaded e.g.:

define([ "jquery" ], function($) {
  …
}); 

The above is just as if jQuery was declared to use AMD itself (which it can do).

We intend to enhance the JavaScript development experience further with the goal of making Play the #1 choice for web development.

Happy Play-ing with WebJars!

Hello Typesafe!

I'm thrilled to be able to announce that I am starting as a Senior Engineer with Typesafe this coming Monday. I'll be working on the Play framework.

I'm excited to become involved in the Typesafe mission. In many ways Typesafe feels like an early SpringSource given its culture, focused people and established open-source projects.

I'll be based just south of Sydney (where I live) and work alongside my new colleague James Roper.

You'll be hearing more from me about why Play should be top of mind when considering the RESTful JSON based web service use case. Watch out Node, here we come!

Java, JavaScript and Maven in 2013

A couple of predictions for this year:

• Java will become cool again
• JavaScript running on the JVM will be interesting
• Maven will become cool

Java

Java 8 will bring lambda functions into the fold and enhance its collections to support them. Functions as first-class objects are one of my favourite features of other languages such as JavaScript. What I like about them is the mainly the flow of writing code. With Java today there's a bit too much of a context switch when providing some type to handle lambda style behaviour. This can curb productivity.

It is a shame that automatic property access isn't being incorporated as I think that this would be the final nail that pushes aside a few other JVM languages.

JavaScript on the JVM

Both Nashorn and DynJs will change the landscape in terms of running JavaScript on the JVM. I'm personally quite impressed with Mozilla's Rhino and have always found it to be quite functional. Having something that builds off of our API learnings and simultaneously runs much faster will make the JVM a first class platform for running JavaScript. Watch out Node.js… I'm suspecting that they'll be a nice JVM based equivalent coming along.

Maven

It seems to me that people's main issue with Maven is the XML pom file format. Its about time that we had a better DSL for POMs. Imagine what a JavaScript POM DSL would look like… My belief is that moving away from XML will make Maven appeal to many current naysayers.

 

Click here for my reflections a year on.

Fast broadband == backup

Gosh, what a long time since I last blogged. Truth is I've moved over to R&D within VMware and I've been working on really interesting cloud stuff that has taken up all of my cycles. I'll be writing more about that soon.

There's a big debate here in Australia on the benefits of the National Broadband Network (NBN). The opposition in government are asking for justification in terms of business case etc. etc. They're also arguing that the government's plan is rubbish stating that wireless is a better option. The arguments go on and I think are mostly inspired by the fact that the NBN isn't the opposition's idea.

I think that the biggest unstated benefit that will come out of the NBN is offsite backup. Yep, you heard it here, the boring business of backing up data.

My 1TB backup drive gave up the ghost a couple of weeks ago. Since then I've been thinking about buying another, but the thing is, I really want more offsite backup. I've got some offsite backup going in the form of other devices (iPhones, iPods etc.), and I'm even using our VMware Mozy backup solution for work stuff.

The things that are holding me back in terms of full offsite backup though is: (i) the ISP cost of uploading/downloading GBs of data; and (ii) the speed at which this can be done (both the initial upload and incremental uploads).

My view is that not only will the NBN deliver more speed (I'm only getting 3mbps at the mo), I think it'd be reasonable to expect larger download/upload quotas over time. Right now download quotas are pretty similar to existing ADSL plans but as more people suck the data down, the market will demand higher quotas. And that means that offsite backup should become a reality.

So the next time you're thinking about the cost of NBN here in Australia (presuming that you do!), think about how much your data is worth and then multiply that across the population!