Scala Summit @ OSCON 2010

I attended the Scala Summit at OSCON this year. I have worked with Scala off and on in the past year, but have never really used it on any substantial project.
There were several presentations throughout the day, here is a quick rundown on what I saw:

Akka framework, providing support for concurrency, fault-tolerance, and STM. To me this was the most interesting presentation, in part because I think Scala provides great promise for building concurrent applications more safely. This framework borrows concurrency and fault-tolerance ideas from Erlang, using message-passing between lightweight event-based actors, allowing for thousands of such concurrent actors. It claims to be much more performant than the default Scala concurrency libraries.
more here: akka

sbt - the Simple Build Tool, is clearly the tool of choice to manage the Scala/Java build process. It incorporates dependency management using Ivy, allows for build programs to be written in Scala. It looks useful as a general replacement for other build tools as well. simple-build-tool/

Specs - a domain-specific language for creating specifications and validating code against it.
see more here: specs

Lift framework: another presentation on Lift that, I think, suffered from the presenter doing live code instead of working from slides. There was some interesting discussion of the benefits of static-typing in such a web framework (a bit less testing required for example.) The other thing I came away from this with was how powerful the Comet library is, looking forward to diving into this further.

Android/Scala integration - some discussion on toolchain, problems with larger libraries, and the role of type-safety.

Scala in Practice: developers from Twitter and ??? ran a Q&A session. A couple of things that echoed my experience was the difficulty of integrating new Scala development into existing Eclipse & Maven toolchains. Also, remember you're not writing Ruby on Rails, or Java - don't just bring the same idioms. These folks also gave up on the standard concurrency libraries due to performance, rolling their own (Akka wasn't yet available, but they said they would use it now.)
The other thing that really rang with me was that, rather than trying to introduce Scala in a low-risk "test" project, it would be better to write something important. (At least it worked for them!)
There was also some discussion about lack of support for nested annotations and how this affects persistence frameworks - something I need to look into more.

Advanced Scala Language Features - last session of the day, some of which was over my head as a Scala newbie.
The two concepts I took away was the notion of "higher kinds" and continuations.
Kinds are a level above types (Kind systems classify Types, Type systems classify Values.) They allow you to construct and manipulate Types.
Continuations are a feature common in a few other languages, Scala 2.8 has a form that the speaker argued was not really that useful. Remains to be seen

I also had some offline discussions with people about integrating Java and Scala. All thought it was great, but also warned me that the Eclipse 3.5/Scala 2.7 integration was a bit brittle. So at least it wasn't just me having the problems!
All swore by the 'sbt' tool. I hope to get a chance to new Eclipse and Scala 2.8 soon and see if its better to integrate. i'm also looking forward to digging into the Akka framework.

Flex client/server performance

I had a chance recently to do some Flex-based client/server development work with a small team. During the course of this project questions arose about data transfer using various protocols. Originally the team decided to use a SOAP interface, and this started out fine, but during development someone accidentally requested a deeply-nested graph of objects - and we hit a wall where data retrieval started taking many seconds.

Time for some performance testing, comparing three different protocols:
- SOAP marshaled into ActionScript class-based objects
- RESTful/JSON marshaled into dynamic objects (using as3corlib for JSON decoding)
- RESTful/XML marshaled into the ObjectProxy objects that Flex 3 creates by default

Basic results - the above list shows the performance ranking, SOAP being 3X to 7X slower than the RESTful/XML case.
JSON decoding added approx 20% overhead - presumably because it all happens in AS3 code rather than in native code.

The other thing that stood out - increasing the object graph depth caused an exponential increase in processing time, even though there was only a linear increase in the number of objects in the graph.

Another advantage of the RESTful/XML case is that the ObjectProxy objects created are directly bindable by the Flex UI controls, so if you can live with 'duck-typing' no further marshaling is required.

Later, on a different test setup, the speed of AMF3 was tested, and it was a little faster, with the added advantage (to some) that it was marshaling into class-based objects. (It also handles object graphs better because it uses server-side instance folding). But its a binary format with a limited user base.

Conclusions for now - another strike against SOAP in this environment, RESTful/XML ends up being a pretty compromise in performance and usefulness in the UI.

rgg_20091027_084712

rgg_20091027_084712, originally uploaded by rgordon.

I hadn't emptied out the 'point & shoot' for a couple of weeks, found some pleasant "surprises" in the images. here's a photo of an autumn morning fog bank

20090926-191601-compare-4up

20090926-191601-compare-4up, originally uploaded by rgordon.

i was experimenting with HDR imaging recently, and came up with 4 different renderings of the same image. its clear I need to learn how to control Photomatix Pro! But in the end I was able to get a more interesting and realistic rendering using PSCS4 and the Local Adaptation conversion.

maples on Fort Ward Hill trail

rgg_20090913_151541, originally uploaded by rgordon.

Hiking up Fort Ward Hill trail today, maples lit nicely.

Epson 2200 in Snow Leopard

After upgrading my Leopard system to Snow Leopard, I not only lost the AppleTalk-based connection to my old LaserJet, but also had problems printing to the Epson Stylus Photo 2200. Low-resolution images when printing PDF's from Preview. InDesign refused to recognize any of the custom Epson profiles on my system. When I figured the profiles problem out, it then claimed the printer had the wrong inkset.

Reviewing Apple's support docs, they claim only GutenPrint is supported.

Reviewing Epson's support docs, they claim the older drivers should work fine, but you need to have Rosetta installed in order to instll them.

I never could get GutenPrint's many options lined up to print an accurately color-balanced photo, although I did get closer after a few iterations.

Here's how I got the Epson to work again:

• install the 'latest' Epson drivers and the 'common updater' found for the printer. ( see http://www.epson.com/cgi-bin/Store/support/SupportSnowLeopard.jsp)
• using System Preferences: Print & Fax panel, delete the existing Epson printer defined there.
• in the Print & Fax panel, add a new printer - select the Epson printer (already connected and powered up) and select the Epson driver for it.
• the old color profiles are in /Library/ColorSync/Profiles, yet for some reason InDesign only wants to read them from /Library/Application Support/Adobe/Color/Profiles. One way to fix this is simply to copy the profiles you want into the Adobe folder. (Another way that may work is to put an alias or a symlink to the ColorSync directory. )

I can't wait until I have to try and get the roll paper option working again, that's always a feat with the OSX Epson driver!

rgg_20081130_124908-hdr

rgg_20081130_124908-hdr, originally uploaded by rgordon.

I've been experimenting with HDR photography lately, and one foggy morning I used it to attempt an image I had seen for awhile but had never quite captured - the autumn yellow of the big leaf maple in a conifer forest. This particular morning the fog was just starting to burn through the top of the forest, and gave me enough glow to work with.

Location:
Ted Olson Nature Preserve, Bainbridge Island, WA