Mapping Java Enums in Slick

We had some Scala code that depended on a bunch of Java enums, and I was adding some support for mapping them to Slick columns. (Side note: so far I think Slick is a great technology.) One of the many handy features of Slick is that you can use a type class to define a mapping between some arbitrary type and a database-friendly type. For example, if you have a Java enum “SomeEnum”, defining a mapping is as simple as creating this implicit value:

implicit val SomeEnumMapper = MappedColumnType.base[SomeEnum, String](, SomeEnum.valueOf _)

Now you can use it:

def myColumn = column[SomeEnum]("myColumn") // maps to a String column

But suppose you have lots of enums, where “lots of” is an integer greater than one. You can write a generic enum mapper “generator” that pops out an enum mapper on demand, i.e. whenever the compiler needs one. This is a great case for implicit def: as you would expect, val is for when you have just one instance, and def will generate a new instance for each invocation. The tricky bit is the reverse mapping (SomeEnum.valueOf _ above) since you can’t write A.valueOf _ for a type parameter A. Instead we can use a bit of Reflection black magic to summon a Class[A], then stuff that into the generic java.lang.Enum.valueOf(Class, String) method:

implicit def JavaEnumMapper[A <: java.lang.Enum[A]](implicit classTag: ClassTag[A]) = MappedColumnType.base[A, String](, { x => java.lang.Enum.valueOf(classTag.runtimeClass.asInstanceOf[Class[A]], x) })

Or the sugary version using a context bound (about 5 characters shorter… yay?):

implicit def JavaEnumMapper[A <: java.lang.Enum[A] : ClassTag] = MappedColumnType.base[A, String](, { x => java.lang.Enum.valueOf( implicitly[ClassTag[A]].runtimeClass.asInstanceOf[Class[A]], x) })

Now we can write column[AnyEnum] for any Java enum type.

Strange Loop 2015

I recently returned from the Strange Loop 2015 conference. Many people gave great talks there, and I was glad to hear speakers on a number of interesting topics. One I particularly enjoyed was “Evidence-Oriented Programming” by Andreas Stefik. The speaker has created Quorum, a programming language where features are included only if proven to be useful in Randomized Controlled Trials (RCTs). Fascinating! We also learned some tidbits from his research; for example, using RCTs it appears that “for” is an unfortunate keyword choice (compared to, say, “repeat”). He also found that static typing has a slight negative impact on productivity for beginning programmers, but a large positive impact for developers with some experience. So now there is scientific evidence that a static type system does help prevent bugs. There were many other great talks, so I do recommend this conference for software engineers who want to keep up on current trends and research.

Chamber Recital

We’re hosting a chamber music recital on Friday, September 4, 2015, 7:30 p.m. at Tates Creek Presbyterian Church. I’ll be performing with a number of other friends, with music including Dvořák’s “American” Quartet and York Bowen’s Fantasie Quartet for four violas. We’ll also be premiering a piece I just finished, Fairy Tales for four violas. The title is reminiscent of Schumann’s Märchenbilder.

North American Bridge Championships

My wife and I attended the NABC bridge tournament in Chicago last week. We had a great time. On on our fourth and final day, we entered an event called “Gold Rush Pairs”, which included a moderately strong field (no pros) with 81 pairs. We finished first overall (top of page 12)! It’s one of our strongest tournament games yet. We’re improving!


I recently entered the Rapido! Composition Contest. They have an interesting condition: the piece submitted must be written during a two-week period that the contest is open. The first day, they email contestants the constraints for the piece. This year, the requirement is a 4-6 minute theme and variations for violin, clarinet, and piano. I composed furiously for two weeks and finished a piece that I am very happy with. Now I’m back to working on a quartet for four violas, which I hope to premiere in September.

Creating video game sounds

I recently discovered some awesome tools for creating synthesized sounds. The sounds they generate are just like the sort of things you hear in an 8-bit Nintendo game.
First there is BFXR. You can easily get started by clicking the presets on the left. They aren’t “fixed” presets, but rather random distributions, so if you click “Explosion” repeatedly it generates several sounds that resemble explosions. Then you can manipulate the various synthesis parameters. The “Mutation” button jiggles the parameters a little bit. Way cool!
Then I found LabChirp, another fun tool with a similar purpose. LapChirp focuses on layering several synthesized shapes. It’s not quite as freakishly easy to use as BFXR, but it’s powerful and it also has a randomizer function to help you get going.
Two great programs for creating new sounds for your next homemade video game!

Java package structure

As I’ve built out several applications in Java and Scala, I’ve spent time musing on and researching different approaches to package structure.

The two main approaches are “package by layer” and “package by feature”. These are exclusive in the sense that you have do one of them first, at the top level of your structure, though you can do the other at a lower level.

Package by layer

  • com.example.model.feature1
  • com.example.model.feature2
  • com.example.ui.feature1
  • com.example.ui.feature2

Package by feature

  • com.example.feature1.model
  • com.example.feature1.ui
  • com.example.feature2.model
  • com.example.feature2.ui

Like many architecture discussions, things can tend to get a little religious. We’re talking about a strategy for breaking down a very large and complex problem; it’s actually viable to do either one. But I do think that in general, package by layer is a preferable approach. Here are some of the better references I found:

Package by layer:

Package by feature: and

The main reason I prefer package by layer is this: layers are fundamental to most architectures, and package by layer puts the core architectural division at the first level. I agree with “Directory structure is fundamental to your code” section in the “” site that the “first strokes” are important. But I disagree that the fundamental division is features rather than layers. That article says, “The fundamental flaw with package-by-layer style, on the other hand, is that it puts implementation details ahead of high level abstractions…” I think this is misleading. Someone looking at the codebase is already interested in the “implementation details” of how it is constructed. I use apologetic quotes because we are talking about the highest-level architectural decisions, so calling them “details” seems like a hand-waving way of dismissing the structure of the software. Abstractions let us divide a problem into manageable parts. Dividing a problem into mostly-independent, loosely-coupled layers is a common first step in architecture, and I think it is much more fundamental than dividing an application into features.

Features tend to come and go much more quickly than layers. Over time, the most stable part of the software architecture is likely to be the division of layers, so that should be the top-level structural division. The division is so deep that some features may not map 1-1 with features in other layers: you may have several UI components per model component, or vice versa. It is very likely that there are fewer layers than features. And finally, specific layers are common to many software applications: you are very likely to see something like “model” and “UI” layers in most applications; by contrast, features are completely dependent on the domain. If I know very little about the project structure, and I’m looking at the project for the first time, I think it is more likely that I can find what I need if the top-level division is similar to other applications. Once I’m more familiar with the application, I probably know something about each of the layers, but I may not have touched some of the features.

So while it may not be appropriate for every application, my tendency is to prefer package by layer, unless I have a compelling reason to do something else.