Category Archives: JavaPosse

JPR 2011 Day 0

Despite the winter storm and avalanche warnings in the Crested Butte area, the flight into Gunnison went off without a hitch. The last few miles of descent were as bumpy as an old dirt road, but the sky was mostly clear, as were the roads leaving the airport.

GunnisonSkyJpr11.jpg

A few miles uphill, the story was a bit different, but our Alpine Express driver got us to our door smoothly and safely.

RoadJpr11.jpg

Day Zero is traditionally reserved for explorations of new technologies, alternate languages on the JVM, and collaborative skills-building. I joined a group that focused on Scala. We talked about Guy Steele’s parallel string-splitting algorithm as presented at StrangeLoop 2010, got a demo of parallel collections in Scala 2.9, and worked on Scala koans.

ScalaKoansJpr11.jpg

After I pointed the folks at my table to Steele’s published slides and summarized the the algorithm, Michael Barker immediately re-coded it in Scala and we started looking at performance. More on that later.

Inspired by the excellent Ruby koans work led by Jim Weirich, Dick Wall had begun working on Scala koans at a previous year’s CodeMash. Dianne Marsh took up the reins; the informal team continues to refine and add to the material, and welcomes additional participants. The Scala koan collection is currently a work in progress; despite a rough edge or two, I really like this approach to ease into the thought processes of a language and very much appreciate the work of the team.

The end-of-day semi-lightning-talk presentations demonstrated a breadth of interests and subjects that will likely help shape this year’s Roundup:

  • Michael and I discussed our observations on the performance of the parallel string splitter;
  • Dianne and Dick described the Scala koans and their current statusy
  • Joe Sundow summarized the jQuery and JavaScript MVS explorations that he had led through the day;
  • James (“I’m just a Flex guy!”) Ward showed how he’s using Spring and Hibernate on a current demo project;
  • Fred Simon gave a quick demo of Fantom, including its ability to compile to JavaScript.

Handerson Gomes and Jim Hurne get my “Wow!” vote for a joint presentation which really made us all sit up and take notice. In the course of one day, they downloaded the Android development kit, got themselves up to speed, and built and tested a small app which include audio and use of the touch-screen gestures.

It was a great start to what promises to be an excellent week. In other words, it was typical for a Roundup!

Advertisements

JPR 2009: Thursday Lightning Talks

The final lightning talk session, like the entire week, went by too quickly! While a technical glitch was being resolved, Bill Pugh and Matt Grommes stepped in with 20-second impromptu lightning talks (spark talks?).

Dick Wall
JFlubber, FlexFlubber, and FXFlubber – Long-time Posse listeners know about Dick’s JFlubber app. In this talk, he presented the results of re-implementing it in JavaFX (steampunk style) and in Flex (with dynamic skinning, courtesy of James Ward).
Jack Leow
GWT in a Traditional Web Development Environment – After touching on the benefits of GWT, Jack described some bumps in the road and how he overcame them, followed by a demonstration.
Bill Pugh
(20-second talk)Donate bone marrow and save someone’s life!
Matt Grommes
(20-second talk)Evernote is a cross-platform system for capturing and managing information, even on your phone!
Oliver Gierke
Coding and Music, Passion and Profession – Oliver, a Java developer and the drummer with Four Sided Cube, talked about the parallels between development and musical composition/performance.
Ron Hafernik
Hacking Hardware for Fun and Profit – Ron talked about low-cost, low-power microcontrollers (such as the ATtiny24, the PIC18F87J11, the Arduino, and the BasicStamp), their uses, and a variety of sites with more information (Evil Mad Scientist Laboratories, Hack a Day, and Instructables).
Joe Nuxoll
Helmet-cam videos – With his photographer’s hat on again, Joe showed us his helmet-mountable camera and solid state recorder, then played some videos from skiing and snowmobiling at this year’s Roundup.
Andrew Harmel-Law
Zombies Ahead – Andrew had us rolling in the floor with his dire warnings about the rising danger from zombies!
Joe Sondow
Working on the front end – Joe demonstrated the use of JavaScript Shell, a web-based”command-line interface for JavaScript and DOM.”
Eirik Bjørsnøs
How to catch a laptop thief using Flex – We all applauded Eirik’s ingenious use of his skills to help catch the burglar who stole a friend’s laptop.
Dick Wall
Doctor Who – Dick summarized the backstory and major characters from this popular BBC series.
James Ward
Sexy apps with Flex – After a quick glance at Tour de Flex, James blew us away with some über-cool user interface demos.
Carl Quinn
Free Electricity From the Sun – Carl showed the design and installation of his home’s solar panel system.
Alf Kristian Støyle
JavaRebel and Scala – Alf demonstrated using Scala on top of JavaRebel, a JVM plugin that reloads modified class files on-the-fly.
Dianne Marsh
What Microsoft Does for Its Developer Community – Dianne reviewed some of the ways that Microsoft supports its developers, including the MVP program.
Todd Costello
Groovy/Swing/GoogleMaps/YQL Mashup – Todd mashed up JXMapKit with Groovy and YQL to plot the home airports of some of the Roundup attendees.

JPR 2009: Wednesday Lightning Talks

As mentioned before, recorded lightning talks will be posted to the Java Posse YouTube channel. Here’s a quick summary of the second LT session.

Joel Neely
The Other Staircase – As a kid, I always wondered why the octave is divided into 12 parts (in Western music). Here’s a reason.
Jason Nerothin
DB Migrations in Java – Jason showed a lightweight approach to bi-directional, development-friendly database change management.
Joe Sondow
Semantic HTML and Skinnable CSS – Joe gave us a quick demonstration of the power of CSS, and pointed us to a couple of useful and interesting web sites.
Joe Nuxoll
CenterLineSoccer.com – Joe serves as a photographer, technical advisor, and blogger to this soccer site. He discussed soccer photography and showed us some great shots.
Ido Green
YQL 101 – Ido demonstrated Yahoo’s YQL tool for querying, filtering and combining web-based data.
Peter Pilgrim
How to start your very own Java User Group – Peter, a Sun Java Champion from England, passed on tips for starting and leading a JUG.
Oliver Gierke
Persistence layers – Inspired by a DeveloperWorks article on generic DAO, Oliver implemented a low-ceremony, annotation-based framework.
Joe Nuxoll
Formula One 2009 – Technology Advances – Joe (who’s also a racing instructor) gave us the basics on the Kinetic Energy Recovery System for F1 race cars.
Alf Støyle and Fredrick Fraalsen
Scala and Wicket – This tag-team presentation looked at using Scala and Wicket to implement on-line registration for JavaZone.
Joel Neely
Why is there a lower-case “A”? – This encore presentation from last year looked at the effect of tools and needs on a very old technology.
D J Hagberg
811: Know what’s below before you dig – Buried utilities can be damaged by thoughtless digging, sometimes with catastrophic results. The 811 system is a response to this risk.
Robert Cooper
Old school computing – Robert’s explanation of basic slide-rule technique showed “an elegant computer for a more civilized time”. (It also had nice screen shots.)
Fred Simon
JFrog and Artifactory 2.1 – Fred introduced us to his clean, functional open-source enterprise repository.
Barry Hawkins
tips for introducing change – Barry’s fantastic talk on… Nah, I can’t do it justice. Just go see for yourself. This one’s already posted on the Posse channel. It was a perfect cap on the evening.

JPR 2009: Tuesday Lightning Talks

At the first Java Posse Roundup (2007), lightning talks were added after the conference began. It was a great idea, but novel enough for some of us that the slots filled up slowly. This year, the three lightning talk sessions were booked solid shortly after the sign-up sheets were posted. By the end of the first LT session, it was clear that the continuous improvement trend was continuing in fine style.

I’m going to list only a very brief summary for each of the lightning talks; all of them will be posted to the Posse’s YouTube Channel.

Joel Neely
Fair Allocation – I showed a small algorithm for weighted division, which illustrates a useful heuristic for discovering correct design.
Joe Sondow
The Selenium IDE – Joe demonstrated the Selenium web testing tool that works well with Firebug.
Bill Pugh
Becoming 3/4 of the man I was – Bill talked about how he lost 60 pounds.
Joe Nuxoll
The Art of the Photo – Joe illustrated fundamental photographic concepts with lots of great photos.
Ido Green
High Gear – Ido introduced his new company, High Gear Media, which supports the “long tail” car-buying market with support for content management and rich site publishing.
Fred Simon
Physics of the 20th Century: the Incomplete Revolution – Fred hit key points regarding general relativity, quantum mechanics, string theory, and loop quantum gravity.
Peter Pilgrim
Animation in JavaFX – Peter talked about SceneGraph, binding, and timelines in JavaFX.
Joe Nuxoll
Racing 101 – This was an encore performance of Joe’s intro to key racing concepts.
Dick Wall
GMail Keyboard Shortcuts – Dick showed us several tips to speed up our GMail sessions.
Bill Venners
ScalaCheck – Bill demonstrated the use of ScalaCheck, a powerful tool for automatic unit-testing of Scala and Java, which offers automatic test case generation and minimization of failing test cases.
Dave Briccetti
Scala Twitter Client – Dave demonstrated features of his Simple Twitter Client in Scala, which he’s worked on this week with other Roundup attendees.
Bill Pugh
Your eyes suck at blue – By separately manipulating the color channels of an image, Bill demonstrated how much less sensitive our eyes are to blue than to red and green.

JPR 2009: Monday

After beginning the day with Camp 4 Coffee, we assembled at the Posse House to dive into a day of coding dojos on alternate JVM languages. Various groups split off to different rooms and houses to discuss Scala, JavaFX, Groovy and Grails, and Jython. The plan for the day also included a discussion of Fan; that session was deferred to the afternoon when Fred Simon (of AlphaCSP and JFrog) experienced an unexpected travel delay.

You’d think that the gate agent would think to wake a sleeping passenger, instead of just issuing last call and launching the aircraft!

I started at the Posse House in the Scala session. Dick Wall was interested in trying to implement linq-like functionality in Scala. Dianne reviewed the first part of Bill Wagner’s article and I recapped the generic sort we worked out last year. Dick showed some sample code that demonstrated several Scala techniques for nice, clean, concise code.

It wasn’t as formal as that may sound; it was more conversation than presentation.

After a lunch break, I went to Chestnut House where Bill Venners met with some Possee attendees to work on his ScalaTest project.

After supper many early-arrivers re-convened at the Posse House for a series of informal wrap-up talks which summarized the activities of the various meetings for everyone. It was a great way to overcome the frustration of not being everywhere at once.

JPR 2009: Sunday

As usual, getting from Memphis to Crested Butte had a bit of drama, although less this year than before.

A winter storm blew through the Mid-South Saturday afternoon and night, leaving about two inches of snow in the Memphis area. The temperature had been well above freezing, and the snow began with big wet flakes, so the first few hours’ worth melted on streets and other hard surfaces. Overnight the temperature dropped well below freezing, so sunrise revealed abundant ice below packed snow on the streets.

This sort of thing is infrequent enough that Memphis simply doesn’t have the gear to respond rapidly. That’s understandable. However, after arriving at the airport and getting to the gate, it became apparent that at least one airline at Memphis International Airport is equally ill-prepared.

Three hours of entertainment (watching staff trying to reroute passengers, watching an idle glycol trailer, watching solar energy deice our plane, eavesdropping on staff talking why deicing wasn’t happening, etc.) finally ended and we walked out to the plane over ice-crusted concrete. After another post-boarding delay, the pilot announced that there was a computer problem and proceeded to reboot the aircraft. Powering off everything, waiting a couple of minutes, and starting back up seemed to satisfy the crew, so we got underway.

Fortunately for me, my missed connection from Denver to Gunnison was not the last of the day. I ended up with the flight carrying the entire Java Posse, along with Dianne Marsh, Bill Pugh (of FindBugs fame), and several others heading for the Roundup.

We arrived in plenty of time to make a supermarket run, including picking up a pound of Sledgehammer for morning wake-up assistance.

This year I’m staying at Chestnut House with a great group of folks: Dianne Marsh, Jason Nerothin and Kurt Heilman of NimbleGen, and James Ward of Adobe.

JPR 2008: Wednesday morning, part 1

This post resumes coverage from my notes on the Java Posse Roundup, 2008 conference.

Agile methodologies on large projects

The conventional wisdom is that agile development is a game for small teams. This session examined that issue, informed by the experience of attendees who have worked on large development projects.

Getting started on large projects

The discussion began with some opinions and suggestions which apply to getting started with agile methodologies:

  • Agile works best (only?) if it is driven from the bottom up.
  • Refactoring requires permission and inclination:
    • Individual developers must be allowed to make pervasive changes to the codebase.
    • Individual developers must be willing to follow the consequences of a change through to the end.
  • Lead by example.
    • Start with a pilot project with a small number of developers.
    • Use the success of that project as a “poster child” to the rest of the organization.
  • Modularity is a key for success.

A couple of the participants had been involved in a large, distributed project. The team comprised 500 developers (in a company which had a total of 1200 developers) located in India, Israel, the Bay area, Houston, and Europe. They were able implement continuous integration across that size and geographic distribution.

Agile is stereotypically described in terms of small teams. What is “large”?

  • Small: one team
  • Medium: 2–3 teams
  • Large: more than 3 teams

One effort discussed had a limit of 6 people per team.

How does a project achieve modularity and team structure? One choice is to spend an iteration on defining the modular structure. Some agile methodologies emphasize delivering working, business-value code in each iteration. But kick-starting a multi-team effort may require using an iteration to get structure (of the modules and the teams!) in place.

However, there can be built-in tension with a layered effort that separates “framework” from “application”. The framework team(s) are naturally going to have a bias in favor of flexibility, to make the framework as general as possible. The application team(s) are naturally going to have a bias in favor of stability, to minimize the rework of application code due to framework evolution.

I think we can generalize this to any agile multi-team scenario where there’s a common interface or (especially) a producer-consumer relationship. It’s crucial to maximize communication and minimize “us-versus-them” thinking. Otherwise it will be natural to see “my team’s changes” as natural or necessary agile evolution, versus “your team’s changes” as “churn”.

There was some discussion of the roles of “gatekeeper” and “contributor”, and the separation of those roles as a way to help achieve stability. However, needs to be balanced by strong advocacy for the view that “anybody can fix the code” if the overall effort is to remain agile.

Engaging the business owner

The discussion turned to the non-developer aspects of an agile project. Getting a product owner may be much harder than getting buy-in from the technical side. There may be a greater need for education, as developers may be more likely to be familiar with the concepts of agile projects. However, the pain is still less than that of being stuck in waterfall mode. The consensus was to get the business side involved as early and thoroughly as possible.

There’s another contrast here. Because business value is achieved by integrating the total effort, the business owner for a large project is likely to fit most naturally at a cross-group level. However, agility demands level-of-effort to be understood at a fairly fine-grained level. Mike Cohn’s books on agile were highly recommended. I’ve put links to a couple of his books at the end.

Estimating and scoping

Estimates are critical to the communication from developers to the product owner and to planning (at all levels). How does the team come up with estimates level of effort?

Most of the participants leaned toward estimating in “points” rather than hours or other calendar units. One common scheme is to assess points along a Fibonacci scale: 1, 2, 3, 5, 8, 13, 21, etc. What’s the difference between a 5 and an 8? It’s simply the developers’ best-effort assessment of relative effort based on complexity. Product backlog is measured in points, and the sprint backlog is extracted from that. The planning conversation addresses the questions:

  • How long is a sprint?
  • What is our velocity (points per sprint)?
  • How many sprints will it take for this feature?

The focus on continuous learning, communication, and adjustment makes this a very different conversation from the stereotypical “Gannt chart mentality” that just wants to put milestones on a calendar, set in concrete. Priorities can adjust, based on experience earned during the project.

Barry Hawkins pointed out that an important concept to keep in front of the product owner is: “You can have anything you want, but you can’t have everything you want!” It’s also critical to communicate the concept of “technical debt” to the product owner. (There are some good on-line discussions of technical debt which provide a comprehensive discussion, a quick, business-oriented metaphor, some nice visual aids, and reminders of the development process aspects.) Participants also referenced Mary Poppendiek’s work on lean software.

Barry also offered the view that agile methodologies don’t address some issues that become important on larger projects, including the cross-feature dependencies and how to partition functionality. He suggested domain-driven design as a good fit with agile development practices as a way to address these issues.

As the session was wrapping up, Barry offered a summary that seems applicable to any introduction of agile practice. He has observed that politics only diminished after the entire team (product owner, development, etc.) had a backlog of experience that showed the productivity benefits of the agile approach.


Recommended reading

Sorting by Schwartzian transform in Scala

The term “Schwartzian transform” was named in honor of Randall Schwartz by Tom Christiansen. (If you recognize either name, you might be thinking, “What would Perl have to do with Scala?” I’ll simply observe that the idea of a multi-paradigm language is an old one.)

At JPR 2008, Dianne Marsh mentioned an article that included a description of the orderby keyword in LINQ. The resulting conversation explored the strategy described below.

The example

Let’s use a minimal Employee class for our discussion:

  class Employee(
      val id:    Int,
      val dept:  String,
      val first: String,
      val last:  String
  ) {
    override def toString() =
      "(" + id + ") " + first + " " + last + " in " + dept
  }

Here’s a list of sample data, used as the basis for a list of employees:

  val data = List(
      (314, "Payroll", "Ursula", "Ficus"),
      (159, "Sales", "Ville", "Eave"),
      (265, "Development", "Wilbur", "Dim"),
      (358, "Sales", "Xeris", "Confabulation"),
      (979, "Development", "Yolanda", "Borg"),
      (323, "Development", "Ziggy", "Ableton")
  )
  val employees =
    for ((id, dp, fn, ln) <- data) yield new Employee(id, dp, fn, ln)

Note that we could mix in the Ordered trait, implementing compare and equals methods, to create a standard ordering for Employee. We won’t use that approach here because we intend to sort employee lists in a variety of ways: alphabetically by name, by employee ID, or even by length of name.

The goal

Our immediate objective is to create a function to sort a list of objects by identifying the sort criteria. The result of the discussion is the sortBy function, which allows us to sort our employees by first name and employee ID by writing as little as:

  sortBy ((e: Employee) => (e.first, e.id)) (employees)

The remainder of this post describes how we compose such a function. There’s certainly room for further enhancement, but getting this far was enough for one conversation (and more than enough for one article).

The standard sort method

Scala’s List class has a pre-defined sort method which uses a caller-provided function to determine whether a pair of elements is in order. To obtain a list sorted by a single Employee attribute, such as id, we can write the expression:

  employees.sort((a, b) => a.id < b.id)

Because it takes only a single argument, the sort method can be written as…

  employees sort ((a, b) => a.id < b.id)

…which is the style I’ll use for the remainder of this article.

Scala also doesn’t require us to specify the type for arguments a and b; the compiler can infer that they have type Employee because they are coming from employees, which has type List[Employee]. (In this case, we could go further and use placeholder syntax to abbreviate the above to…

  employees sort (_.id < _.id)

…but we can’t use that abbreviation for functions that refer to the same parameter more than once.)

As our sorting criteria are more complex (i.e. sorting by length of name, with last name and then first name as tie-breakers), the in-line syntax becomes cumbersome. We can define and use a method which returns Boolean, as in:

  def lessByNameLength(a: Employee, b: Employee): Boolean = {
    val bylength = (a.first + a.last).length - (b.first + b.last).length
    if (bylength == 0) {
      val bylastname = a.last compare b.last
      if (bylastname == 0) {
        a.first < b.first
      } else {
        bylastname < 0
      }
    } else {
      bylength < 0
    }
  }
  // ...
  val employeesByNameLength = employees sort lessByNameLength

That approach provides the per-call flexibility we want, but it has two drawbacks:

  1. it is “boilerplate-heavy”, and
  2. it re-derives the ordering data for each operand, regardless of how many times the operand has been examined previously.

With respect to point #1, the multiple-key comparison requires much more typing, hides our intention in a mound of implementation detail, and is therefore much more error-prone. (For example, if a.first < b.first had been mistyped as a.first > b.first, how long would it take to find the typo-bug?)

We’ll address the boilerplate issue after we discuss the other drawback.

Schwartzian transform

A typical, well-chosen sorting algorithm requires O(n log n) comparisons. The key idea (pun intended) of the Schwartzian transform is to:

  • compute the sort key for each value in the collection and attach it to that value,
  • sort the key/value combinations based on the pre-computed keys, and
  • extract the sorted values from the key/value combinations.

This is a nice application of the time-honored mathematical strategy of transforming a problem to a representation which makes work easier, doing the work, and then transforming the result back (f = g · h · g-1). Each stage can be written and examined individually, a core idea in functional programming. Re #2 above, this approach performs the key computation exactly once per original element, during the setup stage, rather than repeating it every time a pair of elements is compared.

So what do we do with the keys, and how do we use them in the sorting process?

Tuples as keys

A nice feature of Scala tuples is the implicit conversion to Ordered for a tuple whose fields have Ordered types. For example…

  val data = List(
    ("my", 9),
    ("ukulele", 8),
    ("has", 7),
    ("my", 6),
    ("dog", 5),
    ("has", 4),
    ("fleas", 3)
  )
  println(data sort (_ < _))

…produces output of…

  List((dog,5), (fleas,3), (has,4), (has,7), (my,6), (my,9), (ukulele,8))

…in which the values are ordered by the first element of each tuple, with the second element serving to break ties. Because String and Int are both Ordered, Scala can treat Tuple2[String,Int] as Ordered as well.

It’s easy to write a function that produces a key tuple from an instance of Employee, especially if the key is simply made up of fields! Examples of this include:

  def byName       (e: Employee) = (e.last, e.first)
  def byDeptId     (e: Employee) = (e.dept, e.id)
  def byNameLength (e: Employee) = ((e.first + e.last).length, e.last, e.first)

That idea, along with map, zip, and the sort method described earlier, provide all the raw materials we need.

Bolting it together

After reviewing the map and zip methods, we’re ready to start assembling a solution.

If Visitor is the standard illustration for OO design patterns, then map probably fills that role for functional programming. It’s the first syllable in “mapReduce“, and also makes an occasional guest appearance when closures are being discussed.

The expression

  employees map byDeptId 

applies byDeptId to each element of employees and returns the results as a List (which I’ve wrapped to fit on the page):

  List((Payroll,314), (Sales,159), (Development,265),
       (Sales,358), (Development,979), (Development,323))

Associating each key with the corresponding employee is the job of zip, which combines two sequences (as if matching the two sides of a zipper). Given two lists, aList and bList, the expression aList zip bList returns a list of pairs (instances of Tuple2), each of which contains an element of aList and the corresponding element of bList. In our case, that means that…

  employees map byDeptId zip employee

…gives us the list of key/value pairs we need to sort our employees by department and then by ID. Because we want to sort only by the key part of each pair, we need to use sort with a function that compares just the keys. The _1 method retrieves the first element of a Tuple2 instance, so we’ll write:

  employees map byDeptId zip employees sort (_._1 < _._1)

With key/value pairs in the desired order, we are ready to extract the values to form the result, which we can do by adding another map to the pipeline:

  employees map byDeptId zip employees sort (_._1 < _._1) map (_._2)

Evaluating that expression gives us a sorted list. Printed one element per line (via the toString method) it contains:

  (265) Wilbur Dim in Development
  (323) Ziggy Ableton in Development
  (979) Yolanda Borg in Development
  (314) Ursula Ficus in Payroll
  (159) Ville Eave in Sales
  (358) Xeris Confabulation in Sales

Getting functional

Now that we can write an expression that does what we want in a specific instance, we want a general function that captures the core pattern. Looking at the last expression above, it’s clear that the key-extraction function and the list of values are the two parts that need to vary as we re-use the idea. The general template is…

  employees map ? zip ? sort (_._1 < _._1) map (_._2)

…so we just need to fill in the blanks in the following function definition:

  def sortBy ? (f: ?) (vs: ?): ? = {
    (vs map f zip vs) sort (_._1 < _._1) map (_._2)
  }

If the values (the vs parameter) are provided in a list of some type, then the result should be a list of the same type. Because that type can very, we will use type parameters. Choosing V for our value type, we get:

  def sortBy[V, ?] (f: V => ?) (vs: List[V]): List[V] = {
    (vs map f zip vs) sort (_._1 < _._1) map (_._2)
  }

Specifying the remaining type parameter is a bit tricky; we need for f to map from type V to type K (for key)…

  def sortBy[V, K ?] (f: V => K) (vs: List[V]): List[V] = {
    (vs map f zip vs) sort (_._1 < _._1) map (_._2)
  }

…however, K must be a type we can sort. As mentioned in the “Tuples as keys” section, Scala has an implicit conversion to Ordered for tuples (for Tuple2 through Tuple9, actually). That means that we must specify that K can be converted implicitly to Ordered[K], which give us the last bit of type incantation:

  def sortBy[V, K <% Ordered[K]] (f: V => K) (vs: List[V]): List[V] = {
    (vs map f zip vs) sort (_._1 < _._1) map (_._2)
  }

While that last detail is not the sort of thing you’d likely want to write throughout your application code, you don’t have to! That last definition is the sort of thing (pun intended 😉 that you’d put in a library (utility jar, etc.) and just use throughout your application. With that function in hand, we’re now free to write…

  val sortedEmps = sortBy ((e: Employee) => (e.first, e.id)) (employees)

…or…

  def byNameLength (e: Employee) = ((e.first + e.last).length, e.last, e.first)
  // ...
  val sortedEmps = sortBy (byNameLength)(employees)

…or even…

  def byNameLength (e: Employee) = ((e.first + e.last).length, e.last, e.first)
  def sortEmployeesByNameLength = sortBy (byNameLength) _
  // ...
  val sortedEmps = sortEmployeesByNameLength(employees)

…if you’ve read the post on currying, that is.

Scala tutorial on IBM developerWorks

IBM developerWorks has the first two parts of an introduction to Scala by Ted Neward. The series looks good so far, and I’m eager to see more.

I was particularly interested to see in the second article that Neward described Scala as “a better Java“, a theme that Dianne Marsh and I explored in the Scala workshops we did at Java Posse Roundup 2008. I’m tidying up the material we used in the first presentation to make it more blog-friendly, and will post it soon.

For me, one key point of that description is the way Scala provides a graceful transition from Java to functional programming, just as Java offered a graceful transition from C to object-oriented programming.

ScalaBridge.jpg

Java’s similarity to C allowed a developer to quickly begin writing procedural Java “with a C accent”, and then transition to an object-oriented style. In the same sense, a developer can quickly begin writing Scala “with a Java accent”, and then begin to shift to a more functional style.

Scala makes this an attractive proposition by offering some immediate benefits. The canonical example is type inference, which allows the programmer to skip writing redundant type specifications. But more about that as I get the workshop material posted.

JPR 2008: Tuesday afternoon

During the afternoon break, Dianne Marsh took Dick Wall, Mike Levin, and me to the Crested Butte Nordic Center for a bit of cross-country skiing. (Dick and Mike had tried xc before, so I was the rank newbie.) Dianne was a very patient and helpful babysitter. I didn’t fall down once. (*)

I took the picture below…

NordicCenter

…looking back down a small hill toward Dianne and Dick standing by the Nordic Center building. The snow on the right side of the picture (between the building and the ice rink) really is as deep as the second-floor balcony. The next picture…

IMG_2733

…was taken only a few dozen yards further on (after Mike had joined us and everyone had passed me, which wasn’t hard 😉 ). This shot illustrates that the beauty of nature is only a few steps away, almost no matter where you are in Crested Butte.


(*) The statement above is true, strictly speaking. I actually fell down about a half-dozen times. 😉