Two Major Design Flaws

Throughout the time I spent developing longevity, I've made any number of major design flaws. The vision I started out with has changed drastically over time. It's evolved as I experimented with developing the longevity API. While my core guiding principles have stayed in place, the early versions of the library are nearly unrecognizable when compared to the latest version.

Since the beginning, I've had a comprehensive test suite, that has allowed me to correct mistakes and simplify my API with ease and assurance of correctness. And working with the API as it has grown has allowed me to spot problems as I moved forward. But there were two major design flaws that remain in place. Both of them have been nagging me for many months now, until they have become clear in my head. Now I'm ready to admit and address these two errors: the failure to use shapeless, and the lack of column-oriented storage of persistent entities with column-oriented back ends such as Cassandra and SQLite.

longevity IDEA plugin

I'm so excited to announce the longevity IDEA plugin, written by Mardo Del Cid, that helps IntelliJ understand the longevity macro annotations! If you are using IDEA with your longevity project, installing this plugin will remove your red squiggles! It's in the JetBrains plugins repository, so you can install it just like you would any other plugin for IntelliJ. Just search for “longevity” under Plugins in the Settings / Preferences Dialog.

I haven't been using IDEA much at all these last couple years, so I hadn't really realized that IDEA was showing false errors for projects using longevity. I'm grateful to have a user that discovered and reported the problem. I wonder how many people saw this and never even mentioned it! But the best part is that Mardo didn't just tell me about it, he went ahead and fixed the problem as well! I really, really appreciate it. Thank you.

An Interesting Use for Type Classes in Scala

This is a technical writeup of the major new feature in the longevity 0.23 release.

There are more than enough writeups on using type classes in Scala already. I normally wouldn't bother to write about it, but I will now, for three reasons. First, the usage of type classes in longevity seems unique to me; I haven't seen type classes used quite this way before. Second, I want to write this up as documentation for any future contributors to the longevity project. Third, I'd really like to get your feedback into what I've done here, and hear your advice about how I might further improve on things.

More Longevity Awesomeness with Macro Annotations!

I just got longevity release 0.18 out and wow, is it awesome! If you've looked at longevity before, you will be amazed at how easy it has become to start persisting your domain objects. And the best part is that everything persistence related is tucked away in the annotations. Your domain classes are completely free of persistence concerns, expressing your domain model perfectly, and ready for use in all portions of your application. Of course, we also provide a complete persistence layer for you, saving you countless hours of development effort!

See for yourself, here is a simple example demonstrating how easy it is to get started:

More API Simplifications in Longevity 0.17

Longevity is the persistence framework to use with Scala and NoSQL. Release 0.17 simplifies the user API in some very pleasant ways. Empty marker traits Persistent and Embeddable are removed. Also, KeyVal now takes a single type parameter instead of two. In brief, this will make defining the classes you want to persist so much easier and more natural, as you no longer have to extend your persistent classes with empty marker traits.

Introducing Emblem - A Reflection-based Utility Library for Scala

I've been working on this Scala project for a while now, and I found myself needing to develop some reflection-based tools to do some of the things I wanted to do. These things definitely weren't part of my core code, and I thought other people might find them useful as well, so I split them off into a separate library called emblem. It's open-source and on GitHub. The code is clean and has good API docs, but I haven't gotten around to writing any user documentation yet. I plan to do that here, and I'd like to start by describing my basic goals with emblem, and the design principles I decided to follow.

Scala Days Recap and Video

Recap

I really had a blast at Scala Days this year. I met so many wonderful people, saw many wonderful talks, and had a ton of fun. I met so many great people, I can't possibly mention them all. My best memory is drinking a glass of wine at a bar with all the Scala Days attendees, when from out of the blue come Matthias Nehlsen to greet me. We have known each other on Google+ for some time, but had never met before in person. It felt like one of those Dora episodes where they all jump into the Fairy Book and go to Fairy Land.

I also got to speak to Dick Wall a bit, which was sort of a Wayne's World moment for me ("We're not worthy!"), as I used to be an avid Java Posse listener before I started writing mostly Scala. Great podcast that really helped me keep in touch with what was going on in the Java community. For Scala, I listen to the Scalawags, and I eagerly look forward to the resumption of the Scala Types podcast.

I really loved Rod Johnson's keynote. Scala poetry is a beautiful idea. I'll try to write some one day. The only point in his keynote that I question is that startups are not going to be using Scala. I don't object out of reason, but from the observation that there are many startups in the Cambridge/Boston area that are taking up Scala. There were too many great talks to start telling stories, but I won't forget asking a stupid question at Heather Miller's Pickles and Spores talk for a while. There are still many talks that I need to catch up with online. In many slots it was hard to pick between sessions!

Proof of Concept: Cake Pattern Type Macros

I've been using spare cycles over the last six weeks to try to put together a proof of concept implementation of the type macros I described in my Taming the Cake Pattern blog post from three months ago. I'm happy to say I have a working implementation of the first six macros! It really needs at least one more to be at all useful, and there is plenty of stuff that needs to be fleshed out. But I was very happy to learn that it was actually possible to make this happen. I'm currently compiling three examples and 27 test cases.

Taming the Cake Pattern with Type Macros

In a previous post we discussed various techniques that could be employed with the component based dependency injection (CBDI; typically referred to as the cake pattern). In particular, we discussed two CBDI features that are not available in DI frameworks such as the Spring framework or Google guice: expressing design constraints between hierarchical components, and encapsulating the details of a composite component. Alongside these advantages, however, the cake pattern has some disadvantages that limit its appeal. The three major problems that I see are:

1. Verbose: Lots of boilerplate.
2. Opaque: It's hard to figure out and understand what is going on by looking at the code because the language structures used do not signify the user's intent. These language structures are somewhat advanced, and may seem a bit foreign to programmers that are relatively new to Scala.
3. Aloof: Compiler error messages are potentially confusing and misleading, because they address the language structures used, and not the user's intent.

(I've heard Daniel Spiewak report that the compiler can also be very slow at handling the cake pattern. I haven't had any personal experience with this problem, so I am not in a position to address it.)

Lately I've been pretty excited about type macros, an experimental Scala language feature, and I've been considering ways in which type macros might relieve some of these problems. In this blog post, I want to describe some hypothetical type macros that might alleviate the first two problems: verbosity and opacity. I haven't had a chance to use Scala macros yet, and while the macros presented here should be possible, I can't say for sure until I've tried it. So think of what is presented here as a spec. I'm going to try to implement it, and I'll let you know how that goes.