technology from back to front

Archive for the ‘Reviews’ Category

CodeMesh 2013 Redux

Last month I attended the CodeMesh conference here in sunny London, along with a couple of my colleagues. Here are my recollections and thoughts.

The venue (Hotel Russel on Russel Square) is a pleasantly rambling, grand old hotel, which hosted a few hundred hardcore geeks fairly well. A couple of the rooms were a bit small and not entirely suited to the task, though the main lecture hall and the exhibition/mingling/eating space alongside worked very well. Food was good and the craft beers on the first night were exactly what is missing from most such parties. Most event organisers don’t do any better than Becks, so the variety of beer here and live, Clojure-generated beats make it stick in the memory.

The content of the conference (I didn’t just go for the beer and food) was tending strongly towards functional programming, new languages and general deep geekery. And for that I applaud it, though I found the quality of the talks variable. Putting it less politely, a few were atrocious, mainly due to scatty content and poor exposition, but there were just enough gems to make it worthwhile. I think I may have chosen badly between the available tracks as my colleagues seemed to fare better. I’ve been to enough conferences to know that this is par for the course, and like a round of golf, it just takes a couple of standouts to make it all worthwhile.

For me, Jafar Husain’s talk “End to End Reactive Programming at Netflix” was a sparkling example, and I have already presented a mini version of it back at base, introducing my colleagues to the Reactive Extensions (Rx) from a JS point of view, and including some nice examples that I found from Bacon.js, an alternative implementation based on the same principles. I strongly recommend looking at Rx for JavaScript if you’re working in the browser, and at the many other ports for use on the server or various UI frameworks. I’ve actually been exposed to the Scala version myself recently as part of the Principles of Reactive Programming course on Coursera, which was nicely timed to bolster my understanding.

More generally, the key themes that stuck out to me, with a heavy helping of personal opinion, were as follows.

  • Scala has a lot of mindshare and people are doing real things with it. It also brings with it a great deal of scepticism from those that think it’s too complicated or too impure as a functional language. I share those feelings, but I’m learning and using it all the same as it may be the best thing available right now and allows me to mix and match paradigms within a single program, bringing pragmatism to problem solving. I spoke to Bruce Tate after his talk on the evolution of programming languages and he reckoned Scala is a good bridge language to a better place that probably doesn’t exist yet (I’m paraphrasing).
  • Haskell maintains the moral high ground and the talk about what they’re doing with it at Facebook was a necessary example of its use in the real world. Having one of the long time Haskell compiler engineers working on the project has clearly helped, and indeed they have made compiler changes to enable their project to succeed. Somehow Haskell leaves me cold however, at least for now. Perhaps because it’s that much more of a stretch away from the JVM and its purity feels more like trouble than freedom. Maybe I’ll get there in the end.
  • People are really trying hard to bring new languages to the table that learn from what has gone before. Rust looks like a nice approach to systems programming and I’d definitely consider it if faced with a problem that looked like it required C or similar.
  • There was a background level of Erlang, but perhaps more interesting was Elixir, a new functional language that runs on the Erlang VM. Dave Thomas was up on the stage with José Valim, Elixir’s creator, waxing hysterical about how he was as excited as he was about Ruby back in the day. Personally I’m not feeling it, perhaps because I’m tending towards statically typed languages recently, having done plenty of Ruby and Groovy in years past.

To summarise, it was a little hit and miss, but allowed me to put my finger on the pulse of this section of the tech community, and to learn some worthwhile lessons. Many of those lessons were of the intangible, hand-wavy sort, but I value them highly as we try to navigate the currents of the fast-moving tech world. Then again, one of the things we learn is that at a higher level it doesn’t move that quickly and a lot of the stuff that’s hot right now has its origins in the 70s and 80s.

Sam Carr

Möbius Transformations in a Tangle

We saw in a previous post a kind of transformation of complex values, a Möbius transformation. It turns out that we can decompose any Möbius transformation into a series of four separate transformations – a translation, an inversion, a dilation/rotation, and a final transformation. From a UX perspective, we saw that using input fields and a button to modify the transformation was not slick. Today we’re going to make things more slick.

Read more…

Frank Shearar

simple build tool

I started using Maven at a company where we had 60+ Java projects all
with their own individual Ant build file. Each build file was different and
each project was structured completely differently. Porting the most active projects to
Maven made this situation a lot saner, test code was always in the same location, the same
commands achieved the same things on different projects and we could
start to manage our library dependencies sensibly. However, some things just always seemed
crazy about Maven - having to explain that Maven really did need to ‘download the whole
internet’ just to clean compiled code out of its target directory soon gets painful!

Since I started working on some Scala projects at LShift I experienced
further annoyances with Maven so I thought I would examine an alternative to Maven written in
Scala – the simple build tool (sbt)

The first thing it did nicely was new project creation, this is much
simpler than Maven, no multiple command line options or selections from very long lists,
just a simple interactive script with questions that are easy to answer.

[bert] things%sbt
Project does not exist, create new project? (y/N/s) : y
Name: parsnip
Organization []: lshift
Version [1.0]:
Scala version [2.7.5]:
sbt version [0.5.5]:
:: retrieving :: sbt#boot
confs: [default]
2 artifacts copied, 0 already retrieved (9831kB/619ms) :: retrieving :: sbt#boot
confs: [default]
3 artifacts copied, 0 already retrieved (3395kB/39ms)
[success] Successfully initialized directory structure.
[info] Building project parsnip 1.0 using sbt.DefaultProject
[info]    with sbt 0.5.5 and Scala 2.7.5
[info] No actions specified, interactive session started. Execute 'help' for more information.

This creates a project structure for you that is closely modelled on the standard directory layout used by Maven. There are two additional directories lib and project. The lib
directory provides a standard place to keep any dependencies that aren’t available in a Maven repository. The project directory is where the project configuration is kept.

Secondly, there is no XML required to configure the project, the configuration is carried out by a properties
file and a Scala file. Dependencies are managed by adding the values to the Scala file that defines the project configuration; for example:

import sbt._

class ParsnipProject(info: ProjectInfo) extends DefaultProject(info) {
  val derby     = "org.apache.derby" % "derby" % ""
  val scalatest = "org.scala-tools.testing" % "scalatest" % "0.9.5" % "test"

This uses a simple DSL to replace your Maven or Ivy configuration file.

Thirdly, testing is easy! Maven can be a bit hit or miss running the
three major Scala testing frameworks and it doesn’t report the actual
error when a test fails – you need to dig through the test output. If
a test fails with sbt the standard output you would get from the test runner is
displayed in the console. Additionally, you can make sbt monitor your project
continuously and re-test as code changes so you are informed of broken tests as soon
as they break.

Fourthly, it won’t ‘download the internet’ unless you explicitly tell
it. The command, sbt update, downloads dependencies but you can do sbt
clean without having to download the internet.

[bert] things%sbt clean
[info] Building project parsnip 1.0 using sbt.DefaultProject
[info]    with sbt 0.5.5 and Scala 2.7.5
[info] == clean ==
[info] Deleting directory /Users/timc/tmp/things/target
[info] == clean ==
[success] Successful.
[info] Total time: 0 s
[success] Build completed successfully.
[info] Total build time: 1 s

So for Scala development sbt seems to be as good if not better than Maven. Extending sbt is also
simpler, custom tasks and plugins are simple Scala functions or classes with no additional XML required.




You are currently browsing the archives for the Reviews category.



2000-14 LShift Ltd, 1st Floor, Hoxton Point, 6 Rufus Street, London, N1 6PE, UK+44 (0)20 7729 7060   Contact us