James Roper, Typesafe’s technical lead for the Play Framework demonstrates building a webapp in 45 minutes, at the Melbourne Scala user group. April 2013.
June 16, 2013 at 10:45 pm (Software Development)
James Roper, Typesafe’s technical lead for the Play Framework demonstrates building a webapp in 45 minutes, at the Melbourne Scala user group. April 2013.
February 10, 2013 at 1:55 pm (Software Development)
Tags: scala, scalaz, static-types
Design issues when using Static Typing in Scala
This was given at the Melbourne Scala User Group, in August 2012.
To get the most out of it, I recommend viewing the code that accompanies the talk:
https://github.com/benhutchison/ScalaTypeSystemTutorial/blob/master/src/main/scala/typestalk/TotalFunctions.scalaub.com/benhutchison/Scala…
September 18, 2012 at 12:09 am (life & culture)
Following on from my last post, here’s some more oddities in The Lord of the Rings:
Where are the all people?
From my understanding of history, most areas of our earth that were agriculturally viable we’re populated to some degree, once humans arrived. But most of Middle Earth is inexplicably empty. Even in the Shire, one of the most densely populated places, they didn’t meet a single traveller on the road the whole way to the Brandywine, save for Merry. Most of Eriador is a vast Wilderness. Another example is Rohan: Aragorn/Legolas/Gimli cross this supposedly populated nation without ever bumping into anyone.
This de-population of the world actually works well the first couple of times you read the book. It ensures that each and every person you meet is relevant to the story (with the unfortunate exception of Bombadil). But from about the third reading, you start to notice the emptiness of the place.
…and what do they eat?
Apart from the Shire, the Pelennor Fields, and a tiny bit of land around Isengard, no one in Middle Earth seems to grow any food or plough any fields. Where is the food grown that feeds the household of Rivendell? Or Bree, for that matter.
For some absurd reason, I became fascinated by these two flaws in the book while I was recently reading it to my son.
I now have this fantasy (in an alternate lifetime) where I do a machinima [http://en.wikipedia.org/wiki/Machinima] interpretation of the Lord of the Rings – my version. In many ways, it will follow the book’s plotline much more faithfully than Peter Jackson did. But in subtle ways, it will be different: there will be inhabitants, huts, farms, fields. There will be side roads, lanes and paths. Shepherds and livestocks.
And everyone will need to grow, gather or hunt what they eat, somehow. Not just the humans, but subterreaneans like Orcs and Dwarves too. Edible fungi anyone? ~Termite Style~
Even the too-good-for-mortals Elves won’t e able to conjure lembas from starlight. They’ll have to grow Oats, or Barley or Corn, to bake it from. That means they’ll have to keep livestock to plough the earth. And even Arwen’s pretty little hands might occasionally be rostered on for mucking out the oxen’s barn.
August 15, 2012 at 11:32 pm (life & culture)
This is one for Tolkien fans, amongst which I number.
I’ve been reading the Lord of the Rings, aloud, to my 8 year old son the past 6 months or so. A little bit at a time, perhaps 5 nights a week. It’s been alot of fun, an out-of-world experience that we’ve shared together.
But it’s undeniable that Lord of the Rings has some boring bits and some weak points:
Fellowship of the Ring, the finest of the three books, has the best signal-to-noise ratio with only 2 slow downs:
The first half of The Two Towers is very well paced, with only one boring bit.
..but in the second half things go less well:
But, as any Tolkien fan knows, it’s Return of the King where the real nuggets of boredom are to be found. It’s as if, as the thing was conceived, the sheer enormity of what he had created began to get out of control. Whereas in Fellowship, we travel with the characters, at their shoulder, and share their meals, by the Return of the King, they are more distant. The language becomes more formal, spontaneous dialogue lessens.
In the second half…
June 5, 2012 at 11:06 pm (Games)
I play alot of Starcraft, perhaps 8 hours a week or so. It’s a popular evening recreation after my kids have gone to bed; a TV substitute. I much prefer to play 2v2 and 3v3 teams allied with friends, with voice chat over skype, but I play 1v1 when there’s no one I know online.
The social aspect is a big part of it’s appeal to me. Its brought me closer to the friends I regularly play with, both because we catch up on news while we’re playing, and because we have to work together to win games.
The level of play on the open leagues is very high. I’ve been regularly playing for nearly 2 years, on the Australia / SE Asia server, as a Terran under the name ‘bunge’, and I’m about Silver league standard. It must be daunting for new players to begin.
The game is very mentally stimulating and gets my adrenaline flowing. For 10-30 minutes you are required to constantly make decisions, act, react, outwit another human’s mind. In team games, there can be up to 8 humans minds contributing to the game, with concurrent battles going on all over the map. I like to think I’ve become a better thinker under time-pressure as a result of playing.
For the first 12 months of playing, I would have trouble sleeping for hours afterwards; not good, when you play in the evenings. It no longer has such an effect on me, but I do find myself reviewing what went wrong in a game, as I’m lying in bed going to sleep.
A Winning Streak, a Winning Strategy
Currently, I’m on my longest winning streak ever in Starcraft 2 league play, 11 of the past 12 games. The matching algorithm pairs you with opponents of similar skill level, so it’s hard to sustain wins for long periods.
In this case, the streak is associated with a particular strategy: fast cloaked Banshees, which I used in every one of those winning games. In higher leagues, players know how to defend them, but in my adopted home of Bronze & Silver leagues, they cause havoc.
My build:
Using Banshees Well
June 5, 2012 at 10:25 pm (Software Development)
Google’s Guava open source library provides a class Optional<T> that holds zero or one value, as a superior alternative to null references. Its a certainly good idea, but also a very mature, well understood idea. Haskell has Maybe, Scala has Option.
For some inexplicable reason, Guava’s designer turn there back on prior art and wisdom with a lame dismissal: Optional is not intended as a direct analogue of any existing “option” or “maybe” construct from other programming environments, though it may bear some similarities.
“Some similarities”? Sure does! Its the same damn abstraction. How many abstractions can you get that consist of exactly 0..1 values of some type T? One, that’s how many.
And one of the most useful capabilities of this abstraction is that can be a monad; essentially, support a flatMap (of flattenTransform in Guava terms) operation. The flattening part is useful when you have an Optional<T> value, and a function from T to another Optional<S> value. If you simply transform the input, you get a Optional<Optional<T>> container as a result. Typically, you want to flatten any number of Optional wrappers down into a single Optional<S> layer. That is, either I have a result value of type S, or I don’t.
Sadly, Guava hobbled their Optional class by leaving out a flatten operation.
I find myself speculating on why they left it out, and suspect that it resulted from the kind of ignorance of the outside world that seems to common in Java programming culture. An attitude that its OK to reinvent a existing abstraction that has been widely used and well understood, and yet ignore or dismiss any wisdom that comes from outside the Java ecosystem.
April 2, 2012 at 8:48 am (software)
A tutorial on Scala’s Type System, presented by Ben Hutchison at the Melbourne Scala User Group in Feb 2012.
Part 1 covers structural vs nominal typing, type inference, parametric polymorphism, and type bounds.
Part 2 covers type members, compound and singleton types, type projection, type lambdas, going beyond inheritance hierarchies..
The code used in the talk is at:https://github.com/benhutchison/ScalaTypeSystemTutorial/blob/master/src/main/…
May 3, 2011 at 11:06 pm (Software Development)
Attached are the slides from my April 2011 Melbourne Scala user group presentation, on “Heroscape 2.0: A case study in using Scala for complex HTML document generation”
May 3, 2011 at 10:56 pm (Software Development)
Here are the slides from a “State of Scala” talk I gave at OSDC in November 2010, summarizing where Scala is currently at.
February 11, 2011 at 1:16 am (Software Development)
My previous post was perhaps a bit symbolic (or plain smart-arse) and in need some some explanation.
In simple terms, it is a lament about the shortcomings off Test- (aka Behavior) Driven Development (TDD or BDD), a testing practice that is widely considered current best practice for software engineering, or least my experience of doing it.
In this method, software is constructed by first building executable tests, or specifications, that function somewhat like moulds in the casting of metals or plastics; they determine form of the software by specifying very precisely how it must behave. This takes more of the time and effort; once the specifications are constructed, it is usually less effort to construct the software to satisfy them.
Its been discovered, by myself empirically, but also by many others, that using many fine-grained, non-overlapping, unit tests yields software and tests that are easier/cheaper to build and maintain. However, an uncanny thing happens to unit tests as they become fine-grained: they start to look eerily similar to, or perhaps mirror images of, the code they specify.
So, the mirrors halves of photo in the previous post represents the two sides of a system (in this case, the text on the sign): the code (on the left), and the tests (on the right). What I was seeking to highlight is how the information content of the system has not been increased by adding the tests. We have said the same thing twice: once, as code, and again, as tests over that code.
What we have added is redundancy, which serves to detect errors, just as redundancy does in error correcting memory or RAID disks.
So, to me, the essence of the TDD practices is actually to ensure redundancy in a system’s specification. When the 2 copies of the specification, Code and Tests, do not agree, we have a test failure that is easily detected.
My problems with present day TDD are that
Ive been thinking alot lately about what could replace TDD, to give us reliable software at more lightweight redundancy levels, in the 10-50% of code size range, rather than the 100%+ redundancy of textbook TDD. Some early ideas: