Longevity: A Persistence Framework for Scala and NoSQL

Longevity is a Domain Driven Design persistence framework for Scala and NoSQL. We currently support MongoDB, with a Cassandra back end coming soon. After having been working on this project for over a year, I am so excited to finally share it with you! I've been working hard to put in a core set of features that would make the tool feasible for you to use in a real application. The result is our MMP release, which we just put out yesterday.


Discontinuing the Introducing Emblem Series

It's been a while since my last post in the Introducing Emblem series, and having had some time to mull it over, I've decided to discontinue the series. It seems silly to be writing what is essentially user documentation as a series of blog posts, when I could be writing user documentation in a more suitable place, such as the wiki for the project's GitHub page.

I've migrated the useful content from the previous blog posts into the wiki. I've also added two new wiki pages there, which would otherwise have made up this blog post. In the new pages, I cover TypeBoundMaps, and how to use emblem's maps with types that do not have exactly one type parameter.

I'll put out a note on Twitter or wherever when I add significant new content to the wiki in the future.


Codename: Life Happens

I don't have to actually look over at GitHub to know what it says. It says the estimate for MMP is mid September, 2015. And I don't need to go to my board to know how much work I have left for an MMP release. And I don't really want to look up at the date in the top right corner of my screen.

And I don't expect that mid-September language to stay there long! When I get around to it I'm taking out all language about estimated dates. I've already pushed back dates in the README once. By this point, it's more of an "It'll be ready when it's ready" kind of thing.

So what happened? Why did I miss my date? As often happens, I underestimated the work. But that wasn't the half of it. I mean, it's really a lot of work. Writing a good library API is tricky, and this library is trying to do some big things. But I can do the work. It's just a matter of time and focus.

I've spent a great deal of energy this year moving my family from Boston to Minneapolis. And I'm quite sure I underestimated the amount of work involved there too! It'll take some time to settle in, but I can truly say that the move is done, and that's a relief. I love the Twin Cities. It's beautiful out here, and people are so much more friendly and relaxed than they are in Boston.

And that's really the main reason why I missed my date. That move was a bear, and I'm still recovering.

So you might think, he's done with his move, he can start working full time on longevity, really focus, and get that MMP release out. Right? Unfortunately, life doesn't seem to want to be that simple for me. Because I ended up taking a job, and I started last week.

I know what you're thinking: "That's pretty self-defeating, to take a job at this point, isn't it?" At least, I know I hear myself thinking that. I've put a lot of effort into this project already, and it would be a big waste to leave it incomplete. And it's a waste to not get it out in a timely manner. It's a pretty cool project, and a lot of people might be able to make use of it. I could complete it in a few weeks if I weren't working. With a job, it's going to take longer.

So why did I take it? Do I need the money? Not really. I'll tell you one thing, I wouldn't have taken it if I had to work full time. I'm on a four day work week, which gives me one day a week to focus on longevity. I really do appreciate that they would take me for a four day week. And the company - Dow Jones - and their office in Minneapolis really seem to value work-life balance in general.

So that's great, part time, work life balance, but it still doesn't explain why I took the job. I took it because it was an opportunity I could not afford to pass up. Let me just bullet-point some of the awesome things about this job:

  • Commitment to agile methodologies
  • NoSQL database
  • All Scala

I list these three because that's basically what it says in the objectives section of my resume. Here are three things about the job that I probably wouldn't dare to list as objectives on my resume:

  • DDD
  • CQRS
  • Event Sourcing

Quite frankly, it's rare to see jobs in the JVM world where people really care about things like this. I'm a long-time fan of DDD, and it always comes into play on the job. But being influenced by the ideas of a great methodology is a very different thing from being on a team that is following that methodology. I've also been very interested in CQRS and Event Sourcing since I first heard about them, and I never thought I would actually get to try them out for myself, short of using them in my own pet project.

And to top that off, there are the technologies I get to learn and use. Some, I haven't used professionally yet, such as:

  • Akka
  • Cassandra
  • Docker
  • Node
  • Ember
Every one of these technologies will be a valuable addition to my skill set.

And then there are the technologies that I am quite familiar with already, and happy to be using on any project:
  • SBT
  • GitHub
  • ScalaTest
It sounds like a lot of fun. And it sounds great, nearly perfect, for my career right now. So when I feel bad about only getting one day a week to work on longevity, I basically have to remember all that. It's getting easier with practice.

Don't worry, I promise I won't abandon it! One day a week is more than I've had most of the weeks over the summer. It'll keep going. I'll get that MMP out soon. As you know, you can watch progress on the board.


Pitching Scala

I find myself in a position of pitching Scala to a couple of players tomorrow, and I thought I would organize my thoughts on what I might pitch to them in bullet points. These are IT generalists having a good familiarity with Java and the JVM, but not terribly familiar with Scala. I decided to arrange my bullets in the following manner, going from most important to least important:

  1. Headline pitch. A one-liner that both frames what Scala is, and is provocative enough to capture the listener's attention.
  2. What is Scala? A short list of bullet points that both gives a brief summary of what Scala is, at the same time promoting some of the core benefits of adopting and using Scala.
  3. What else makes Scala so awesome? More in depth points demonstrating the power and promise of Scala. Valuable topics of discussion, but things that I won't mind too much if the conversation wanders and I don't get around to mention.
Here's my pitch list. What do you think? Please let me know in the comments!

Headline Pitch:
  • Scala is a natural successor to the Java programming language, and is certain to be a key player in the Java ecosystem for years to come.
What is Scala?
  • Scala is a function/object-oriented hybrid. It is easy to program in Scala with a very Java like style, and to adopt the best features of functional programming at your own pace.
  • Scala/Java interop is seamless, allowing you to painlessly integrate with the thousands of Java libraries available on the JVM, as well as with your own legacy Java code.
  • Like other next generation languages that run on the JVM, you can code in Scala with massively less boilerplate than in Java.
  • Unlike other next gen JVM languages, Scala is strongly typed, improving code quality and coding productivity on large projects and in a team environment. Scala’s type system is actually quite a bit more expressive than Java’s, providing even more compile-time safety to the development team.
What else makes Scala so awesome?
  • A wide variety of Scala libraries and frameworks that are constantly becoming more robust and fully featured.
  • Many of these, such as Akka, Play, and Finagle, provide both Java and Scala APIs, making business-wide transitions from Java to Scala even easier.
  • The Scala community enthusiastically embraces reactive principles, paving the way for more robust, resilient, and scalable systems. This is especially notable in three areas:
    • Scala has powerful asynchronous tools such as Futures and Promises built right in to the language library.
    • ReactiveX styled asynchronous streams in RxScala.
    • Akka is unquestionably the premier actor framework running on the JVM.
  • Spark, written in Scala with APIs in Scala, Java, Python, and R, is rapidly becoming the go-to big data processing and analysis tool.
  • The Scala community is full of friendly and enthusiastic people!

Here are some of the sources I drew on to put this list together:
  • http://www.scala-lang.org/what-is-scala.html
  • https://twitter.github.io/finagle/
  • http://www.reactivemanifesto.org/
  • http://www.reactive-streams.org/announce-1.0.0
  • https://spark.apache.org/docs/latest/
  • http://www.typesafe.com/resources/video/reactive-streams-1-0-0-and-why-you-should-care


Introducing Emblem - TypeKeyMaps

This is the third post in the Introducing Emblem series, where I discuss a reflection-based utility library I have developed called emblem. If you want to try emblem out on your project, follow these instructions. Or read this if you just want to explore try it out in the Scala REPL.

In the previous post, we looked at the core building block of the emblem library: the TypeKey. In this post, we begin to explore the utility of the TypeKey using TypeKeyMaps.


Advancing Enterprise DDD - Acknowledgements

Many of the ideas I discuss in this series originated in discussions many years back with two good friends excellent software engineers, Andrew Tolopko and Armen Yampolsky. I am grateful to Armen and Andrew for sparking many different avenues of critical thought regarding JPA, Hibernate, and Domain Driven Design. I would also like to thank Andrew for introducing me to Domain Driven Design in the first place, back in 2005 or so.

Thanks goes to Eric Evans for initially developing the concepts of Domain Driven Design, and presenting them in a book by that same name. This is really a wonderful book that has profoundly changed my way of thinking about software engineering like few other resources have. It was a bit of a challenging book for me on first read, mainly because the ideas he presents were so counter to the ways I typically thought about software engineering. Like many of the best programming books I've read, I didn't really grasp everything the first time through, and I read it a second time in short order. I've read this book three times now, and often re-read sections of it when working on particular problems or challenges. While this book is a little difficult to get through, I highly recommend you give it a read, and keep a copy on your shelf. It's worth the investment.

I would also like to thank Vaughn Vernon for his excellent book, Implementing Domain Driven Design, and for advancing the field of DDD into areas such as CQRS and event-driven architecture. His book provides specific programming and architectural patterns for applying DDD using a variety of technologies, including JPA, and has influenced my thinking here a good deal.

Thanks to the developers of Java, Spring, and Hibernate, for providing a great back-end developer stack that gave me so many employment opportunities over the years. In hindsight, it is easy to focus on all the limitations of this stack, and to overlook it's power and all the ways that it was so innovative for its time. Thanks to Scala and MongoDB for helping the software world take that next step forward.

Thanks to StarUML for helping me produce all the pretty UML diagrams found in this series. Also, thanks to Blogger for providing me with a platform to write and share my work.

Finally, I'd like to thank my family, Josie, Jamey, and especially Shu, for being so supportive of me while I worked through this series. They've been very gracious and patient as I've stolen moments from here or there, and disappeared for brief spells on Sunday nights to post.


Advancing Enterprise DDD - Moving Forward

In the last essay of the Advancing Enterprise DDD series, we wrapped up our discussion on immutability, as well as the technical discussion overall. In this essay, we wrap up the series by reflecting on what we've learned, and discussing how to apply these lessons as we move forward.