So much Hello, World!

Today I listened in on a few tech screens with some Java developers. The experience made me want to crack open Exercism. Exercism is an amazing platform to write some code and get some feedback.

So here’s a collection of various people’s ways to say Hello World from the first Java exercise.

Here’s another one:

Ok, that one was clearly wrong. Here’s another one:

And another one, which I rather like for its thoughtfulness:

Another one:

And this:

And this one with some dependencies:

Yet another:

Those are just some examples from the past few days. Some I like, some I don’t; some are more efficient, some are not. My only point in this post is to just highlight that, even in a simple hello, world example, there are many different approaches.

Kotlin: Let’s Kill the Dreaded Java Null Pointer Exception

I’ve been spending some time with Kotlin this weekend. While I’m still getting to know Kotlin myself, it seems like a language that’s worth your time as an enterprise developer, particularly if you’ve got a legacy enterprise Java code base that you can’t realistically migrate en masse. Helpfully, Kotlin can run side by side with that legacy code and buy you modern language features incrementally (more on this later).

nullpointerexceptionKotlin has many benefits — from cleaner, more succinct enterprise code to modern, functional capabilities (especially with funKTionale). In this post, I want to drill in on a mundane issue, an issue near and dear to many enterprise Java developers: solving the dreaded null pointer exception problem, a problem also known as the “billion dollar mistake.”

First of all, Kotlin takes an oblique approach to the null pointer problem: it simply doesn’t allow accidental null pointers. For example, you can’t do the following because you’ll get a compile error (try it yourself):

If you must have a variable that might be null, you need to demarcate it as optional with the following (clean, IMO) syntax:

Notice the question mark? As you might have guessed, it denotes a variable that could be null, which is similar to (but so much more succinct than) Optional in Java 8+ (or similar Guava features).

Given that syntax, the Kotlin compiler is able to provide you substantial null safety. In the following example, it is always going to be safe to ask for the length of the string in name because the variable name can never be null — ever.

However in the next example, if you try to compile code that checks the length of the name string in example 2 without checking for null first, you’ll get an error.

Let’s look at a somewhat more elaborate example:

In this example, we have two classes where the Address of a Person could be null. We also have some instances of people, one of which can never be null and one that can. Again you can see the compiler won’t let you directly access a nullable variable null without handling the possibility of the null (with the “?” syntax above).

The Kotlin compiler is smart about null safety in other ways too:

As you can see, in the first example, the compiler detects when you access the address field within a null check, which is a pattern familiar to Java developers (maybe painfully familiar?), and lets you proceed.

The second example is a little more interesting and succinct. It shows how you can use the Kotlin elvis operator to safely access a variable that could be null. The first part will print the postal code if it’s non-null and the second, optional, operator (?:) will respond with a different string when address is null — no if statements required!

Also interesting to note in the examples are the string templates, which we will discuss in another post.

Hello, world with Kotlin and Maven

Kotlin seems like an interesting language for Java enterprise developers who want to introduce a new simpler language with modern functional features but who can’t realistically leave their legacy Java code behind. Also, Kotlin is super easy to read, learn, and code — IMO, anyway.

I noticed a lot examples are based on Gradle. I think Gradle is great. But since most of the Java developers I work with are used to Maven and the project object model (“POM”), I thought this post might be somewhat useful for you. First, we need is a simple Maven POM:

Next, create a file named hello.kt in src/main/kotlin. Create a new source file named hello.kt (the name is important) and add this code:

You can see right away that Kotlin is different: the function is named differently, the arguments are defined differently, and there are no class references anywhere — even the function lives outside a class!

How to Run It

So that’s easy enough to get your Maven project set up for development. But what do you do with it? And how do you actually run it in the real world?

Inside the IDE

If you’re running in JetBrains’s IntelliJ, running it is as simple as clicking the Kotlin icon (among other methods):

Easy but obivously only useful if you’re code will never leave the IDE.

Assemble an Executable Kotlin Jar with Maven

To build a JAR that you can execute in a runtime environment, we’ll need to do some more work on your pom.xml file. In the build section, you need to add two additional plugins. First is the jar plugin:

This is a standard Maven plugin for adding a MANIFEST.mf file, which will tell the Java runtime which class to execute.

You might notice the mainClass element contains the cryptic looking word “HelloKt.” When you go a little further with Kotlin, you’ll learn that it’s completely interoperable with Java. When you want to call Kotlin code from Java, the Kotlin compiler names your classes with Kt suffix appended to the Kotlin source file name.

In our case we named our source file hello.kt, so Kotlin will expose our code to the Java world as HelloKt. You can override the naming with annotations, but I’ll save that for another post.

Now you can assemble an executable jar file. To run the file, however, you’ll need to put additional runtime Kotlin libraries on the classpath. So let’s build a fat jar with the runtime dependencies baked in by adding one more standard Maven plugin in our Maven build process:

Now drop into your command line, run mvn package on your project and you should be able to execute this command:

And Hello, world!

For More Information

JetBrains has a nice, succinct Maven guide for Kotlin with current version numbers. Also, this code is available on my Github account here: https://github.com/mrice/kotlin-maven-hello-world

kotlin_icon

Thanks to a comment from Eric for causing me to update the example with some guidance on how to actually run it!

How-to: An Embedded jBPM hello, world example

Ok, I admit it. BPM is not the hottest of hot trends right at the moment. But it still has a place. For example, BPM is rock solid at collaboratively modeling business processes with diagrams and orchestrating enterprise services — especially microservices. In fact, BPM might let you keep your microservices finely grained, as they should be, and avoid too many composite microservices.

But what if you don’t want to implement an entire BPM server and suite? Instead, you want to flip it around (as I argued for in mode 3 of my draft whitepaper on the same subject). You want to expose a service that embeds the workflow execution engine. If this is what you’re thinking about doing, then I think this is the hello, world example you’ve been Googling for.

Model your hello, world “business process”

I did this TDD, but let’s start our discussion with a super simple business process model. The workflow it describes accepts some initial parameters and then calculates a new string saying “Hello ____.” That is, the example sets a process variable as input — in BPM-speak — and then reads a different process variable to use as output.

bpm-diagram

Above you see my BPMN 2.0 diagram really is simple: it’s comprised of a start event, an end event, and a script task reading the input process variable string (“name”) and setting a new process variable (“welcomeText”) to be consumed later.

First, I defined an input process variable as a data element in the properties window of the overall BPM2 process.

bpm-diagram-properties

One thing I should mention is that the tooling didn’t let me actually specify the string datatype for the incoming type. I had to manually edit the XML file (which is on my Github repo below), but I think it’s just that I’m a little new to the tooling — not that it’s impossible.

Next, I defined the following script task, which reads the process variable named “name.”

script-task

 

I saved the file as say_hello.bpmn in my Maven project’s resources directory.

Now embed the jBPM execution engine

Remember, I don’t want to deploy the BPMN file into a standalone server. I want to flip it around and embed the server. We can do that with just a few lines of Java code. Before we get too far into this, the JBoss documentation says that my approach is “not recommended for real application development but more for try outs.” Instead, they recommend using the RuntimeEngine to give you finer-grained control over your execution. For now, I’ll leave it to you to explore the distinction.

Under this scenario, we just need to create an object that has access to the BPM execution engine and then create a session from that engine. Specifically, the first step is to set up our KieBase, which has the execution engine inside it, and feed it the BPM workflow (documented above). Then we get a reference to a KieSession. KieBase is a relatively heavyweight operation but creating new sessions is pretty lightweight.

Next we’re going to set our process variables on the session and start the workflow (while holding a reference to the ProcessInstance).

Notice the typecast in there? It’s from the kie-based ProcessInstance to the jBPM process instance from the org.jbpm package, which is useful in later steps.

Finally, we extract the “output” of the BPM process by getting access to the workflow’s process variables after the workflow completes as follows:

I don’t like all the typecasts, but this is my first cut. It works, and it’s pretty fast. Comments? All the code is on Github here.

warningAn important caution about this approach: One initial comment you may have is that running a process in this way will cause a lot of problems if you’re trying to run a long-running process or take advantage of the full suite of options in BPMN. I know, I know. But I’m imagining a microservices-like use case that’s pretty limited. By this I mean you’re going to run mostly quick, short orchestrations (likely of other microservices) and you don’t need to incorporate human interaction in the process nor do you need to even store the state of the process as it runs. In short, you’re getting a very limited suite of BPM services, but that’s ok for this use case.

“How far do you want to fall?” Git rebase

Think about the last time you were mountain climbing. You clip your carabiner as you go depending on how far you’re willing to let yourself fall if you slip. So how far apart do you set them if no one is watching? What if you friends are watching? A little farther?

That’s the analogy I got from Rob Richardson the other day at a Meetup on advanced git topics, and it perfectly captured the value of git’s rebase to me.

If you’re not familiar with git rebase, it’s basically a way of revising your source code commit history before you publish it to a place like Github. With it, you can make lots and lots of small local commits — even if your code sucks in any given commit — and then remove or compress certain unsightly commits when you publish.

For an example, you’re working locally on your repo. You’ve committed some changes that worked, some didn’t. Your revision history looks like this:

git-log-1.png

But when publishing to Github (or behind your firewall to your snarky coworkers), you want to make your revision history cleaner so that the world doesn’t have to see the commits that didn’t work out. Enter git rebase (interactive):

git-rebase-1

And suddenly (magically, even), those two unfortunate commits disappear when you publish. Snarky coworkers silenced.

git-log-2

Honestly, having this feature might actually change the way I think about coding a bit. All of us have a little anxiety about checking in crappy code, so being able to commit a rosier picture than you had locally takes a little pressure off.

And speaking of anxiety, git is from Linux Torvalds and I presume the kernel community uses it heavily. If I were contributing to the kernel, personally I’d have a ton of anxiety about my revision history. I wonder if that was the inspiration for the feature…?

(For a much better description of how to use git rebase, use this Atlassian tutorial.)

 

A proposal for immutable Docker containers to run the Drools engine

People don’t talk enough about rules engines, but they hold a lot of promise. Even if you’re not a financial institution or an insurance company, engineers and architects should consider them whenever they find the team writing too many algorithms with too many nested if/then conditionals.

Red Hat has an open source rules engine you’ve probably heard of — Drools. Drools is solid technology but there are many ways the core execution runtime gets bundled in various other products, so that flexibility and adaptability make it appear complex at first glance. I want to propose yet another open source permutation for you to consider, but I think it’s a lightweight one.

Let’s say your rules use cases are simple and you’ve got a small, engineering-driven environment

Let’s say you’ve got just a few rules you ever need to execute. The rules, which are written in DRL, are authored and maintained by the engineers, not business people. Given this, you believe all you really need is the open source Drools execution engine. But, you’ve got a bursty environment where you can suddenly have a lot of data show up that you want the rules engine to operate on. So you don’t want to run it embedded in your other code.

For this, may I propose immutable Docker containers running the Drools execution engine and either a REST-based or JMS-based messaging microservices entry point? Something like what Mauricio Salatino proposed.

Immutability, Docker, Drools, and (maybe even) Kubernetes might simplify things for you

Sure, my proposal means you’d lose a ton of the services that the Drools and jBPM team have worked hard to produce, but you’d buy some simplicity and possibly a different kind of scalability.

The developer’s architecture would be simple. The workflow for the developer would be as easy as modifying the DRL files, unit testing, and then committing. Ideally, you’d have Jenkins or Bamboo building the code, running integration and automated acceptance testing (may I suggest Cucumber for Drools??), and then build and push the Docker image.

The runtime architecture would be simple too. The server would pull the latest Docker-based runtime. The runtime would operate on the facts it receives from the microservice entry point. The DRL would be baked right into the container. Immutability.

And if you want to get scalable, you could use Kubernetes to orchestrate it all. (Incidentally, if this all sounds like OpenShift to you, you’d be right.)

To those on the leading edge, this proposal won’t shock you. But I thought it was worth writing up since I didn’t see anything else like it.

Java 8: Don’t mistake concision for readability

O’Reilly has a quick little eBook called Introducing Java 8 that, in exchange for your name and email, you can download now on Java 8 right now. If you haven’t spent much time looking at Java 8’s new features, it’s surely worth a download because it’s a quick and easy read.

If you do however, I hope you’ll come back and consider my comments.

My immediate and most prominent reaction to the book is that it appears to pile on to the idea that more code always makes code less readable. Here’s the compare/contrast he offers. This is old school:

According to the author, the following Java 8 syntax is both more concise and more readable:

I obviously can’t disagree that it’s more concise because there were five lines in the first example; one the second. Therefore, concision.

Squishier is the author’s conclusion that it’s therefore more readable. My first reaction was quite contrary. In the first example, I knew exactly what was going on (maybe because I’m old school and understand the APIs well). In the second, I didn’t think it was readable for lots of reasons:

  1. What is the comparingDouble function? It’s oddly named and I don’t know what kind of comparison it does. And where did it come from? Static import? If so, that adds an off balance sheet line of code.
  2. Why is there only one “Invoice” amount getting passed into the function? What invoices?? Comparing what to what?? What comes first and what comes last???
  3. What does “reverse” do?

I totally understand what the author was trying to do with the example because I’ve tried to put these kinds of juxtapositions together too. But I think he’s just going too far to drop a single line of code and conclude that it’s both more concise and more readable without explaining why.

And if you’ll allow me to go further, it’s an issue I have with the fashion industry mentality that too many developers have. Think critically. Just because it’s concise doesn’t make it readable. If you think it is, explain why. Am I just irrational? Look no further than some of the grep statements that “those grep people” put together to know that concision does not automatically result in readability.

In defense of the enterprise developer

I was reading a PriceWaterhouseCoopers article during my long West to East Coast trip to Raleigh last night. PWC warned big enterprise CIOs that their organizations are lame because they represent “slow tech,” and that all the talent wants to go work for “fast tech.” So, old line CIO, prepare to retool to go to the mat with Etsy. And good luck with that.

Instead, I want to offer a clear defense of what it means to be an enterprise software developer even as they are today and without changing a thing (even if change is always warranted).

Before I start, let’s get this out of the way: I know, quite painfully, how lame it can be to be an anonymous corporate software developer lost in a sea of cubicles buried deep in some forgotten corner of Corporate America when you disengage. I hated it with an exquisite passion, so much so much that I dropped out of the whole thing and went to law school. I met a guy today at the Red Hat Tower who shared my experience but did something much more fun: he bumped chairs in Breckenridge for a while. But you can avoid the problem and not derail your career like we did.

I believe that enterprise software developers get bigger opportunities more often than developers in almost any other context — especially with the big emphasis on “digital” these days. The bigger the enterprise, the bigger the range of opportunities. Here’s the non-exclusive list I made on the airplane:

It can be a huge mental challenge to navigate and improve the thick mesh of enterprise applications, services, domain knowledge, and the endless sea of acronyms. An even bigger challenge is how to break down all the barriers and speed bumps created by those systems.

For many software developers, shipping code is not the bottom line. If you look around for stuff on developer culture or developer happiness, you’ll run into a lot of (quite good) navel gazing pieces about how important it is for developers to be able to ship code. I get it. But the art of craftsmanship, which often gets included in the discussion, exists even in code that doesn’t ship this afternoon and it exists in places other than just code. Anyone can be a craftsman anywhere and whenever they chose to start.

In big enterprise environments, your code touches millions without much effort. Big enterprises already have the scale most startups dream of. So it’s amusing for me to read how young software developers dream of working for companies like Facebook or Google because their code could touch millions of people. Well guess what, most big enterprises deal with multiples of those numbers daily. What if you were working on code for Visa? How many lives would you be involved in? Target? The New York Stock Exchange? How many lives can you touch by just being in those environments and doing great work?

Finally, big enterprises offer something “out of the box” that’s hard to get with anything but the fastest growing startups. If you’re smart, you’re articulate, and you want to develop strong leadership skills, there’s really no better launch pad. If you’re in a company of 50, 100, or 300 thousand people there’s a lot of runway in front of you right now. If you join a startup of five, ten, one hundred people, your runway is completely dependent on the growth of the company.

Why didn’t I see Chad Dickerson’s talk twelve years ago (or, why I hated writing code)?

Lately I’ve been really interested in developer happiness. Initially it was because now I have to worry about more than just my own happiness as a developer, but I remain fascinated for a much different reason now. 

I’ve always been an unhappy developer, and diving through a lot of writing on the subject over the past half decade (especially out of the Rails world) is starting to explain why. Don’t get me wrong, I really enjoy writing code. But writing code in the Corporate World sucked — and not just because of some stupid policies, standards, reference architectures, or that guy in the cube across from me. I think those are just scapegoats.

It wasn’t until I watched Chad Dickerson (the CEO of Etsy) that I have a deeper insight into why I hated it (but doesn’t explain why I stuck with it for almost two decades). This is from a 2011 RailsConf, and you need to watch it. Do it again if you’ve already seen it.

Dickerson says a lot, but there are two themes I want to explore. First, he believes happy developers are part of a community. Before you cringe (like I did when I wrote that), he makes an import point about “community”: he seems to mean that you’re in a community when you’re in an environment where people watch each others’ backs. As in you know people in a New York City would help you up if you tripped and fell on the sidewalk. In Phoenix, where I’m from, nobody would have even seen you.

That’s a very minimal definition of community, I know, but it’s a lot more than I’ve had at almost all my corporate coding gigs. For example, I’ve been coding too long to make (too many) really stupid design mistakes, so mostly I was paranoid about some stylistic code choice. I would either have some alpha geek call me out on a code review tool, I’d get a bunch of apathetic shrugs, or most often absolute silence (which of course, I would always interpret as just them silently judging me). Call me obsessive, overly sensitive, or whatever you want but mostly it’s because I wanted to be accepted and valuable as part of the developer community where I was and I rarely ever felt that way. And that’s just the developers. When you add in the QA folks, the architects, the scrum masters who challenge you for trying to move your card too early (or, more likely, for why it’s still in the in progress lane), the product owners who hate your error message coloring… a lot of environments hardly met that minimal standard.

And even though it’s pretty minimal, my feeling is that — now that I’m more accountable for community than I was — I should probably be spending a huge amount of my time getting only that much right. Everything else that might happen to make a richer community will rest entirely on that kind of foundation. Indeed, by focusing on higher order community stuff (like, let’s all go play paint ball together) is just going to feel contrived. I can’t attest to how community is formed, but I know a great deal about the little things that cause developer communities to fail.

Dickerson’s other big theme is craftsmanship (not a surprise from the chief of Etsy, I guess). He talks about some of the obvious things like tooling (text editors, etc.) how easy it is to deploy code, but his point about craftsmanship is letting developers connect to their work. Easy for a startup to say, and easy for a big corporate environment to mess up — true. That’s easy, easy to criticize, and I think pretty straightforward to fix.

What he doesn’t mention about craftsmanship is how community (or a lack of it) can really disrupt your connection to your work — especially if you’re touching each others’ code.

Anyway, just some initial thoughts… lots more thinking and reading to do on this subject.

Does Docker = The End of Java Containers?

I’ve said this to almost every software person I know, including a guy who lives here in Pasadena and works for Docker as an evangelist: I’ve never seen anything hit so broad, fast, and high-profile as Docker has in the enterprise. Lots of people who are lots smarter than me said also said it months before me, locked it in as a critical opportunity, and aligned to it. My company, Red Hat, is a great example. In a lot of ways, we’re leading the charge — not just with Docker but with ancillary technologies like Kubernetes, and I’ve heard we’re in the top three upstream contributors to those projects.

While I get to see the from the inside the great stuff Red Hat does (and it’s indeed cool, I’m just writing personally and as a consultant who only really cares about results for my clients. And in that context — out in the field — I’ve noticed the impact Docker’s having on the developer ecosystem, especially the Java enterprise ecosystem. While we recently celebrated the twentieth anniversary of Java, as an industry we spent the majority of those twenty years trying to figure out how to build big, monolithic, mutlti-threaded, container-based enterprise systems. That is, we thought we needed Java EE containers or OSGi containers or whatever because we couldn’t possible run mainline Java code.

Or that’s what our industry and our bosses said, right?

Frankly, even though I admit I followed my marching orders without really challenging them, hasn’t it been a colossal hassle? As a developer, all I really want is some kind of framework that works, like Hibernate. I like it even better if it’s a standards-based framework like JPA because I could theoretically move to some better framework someday… maybe.  It’s great for speeding up development and saving me keystrokes.

But at runtime, I don’t want to have to code around specs and requirements and impositions just because of some mythical (or, worse, historical) scalability issues. When I was younger and when I challenged less, I just assumed that the big runtime containers, like the JavaEE containers, were solving a problem I didn’t really understand, so I slavishly followed the specs and debugged the seemingly endless issues and just believed that my life was the better for it.

But… now… in a Docker-like, microservices world, all that has turned on its head. An executive-level client at one of my recent clients, who’s tracking these same issues closely, asked me not so long ago, “Do I really need a container anymore?” I didn’t have an articulate, crisp answer for him. Since then, I’ve had people I’ve heard other people with vested interested in container-based architectures answer with a resounding, “YES!”

The developers in the room looked skeptical. I am too. I don’t think containers are dead. But I think their primacy is.