Divorce

This past weekend I closed the Window on a fifteen year relationship. The decision was inevitable. The relationship had become too routine even though we continually tried to Start anew. The age difference had finally begun to show. Separation was the only course of action, as Macabre as it may seem.

With one relationship ending, however, another has begun. For the past year or so I have been flirting with this other. Several years ago, an office fling was started but amounted to nothing - immaturity kept it from ripening into anything serious. Now at a Mini-mum, everything seems right. The combination of beauty, elegance, and prowess gives me hope for a long, fruitful relationship.

I only hope I haven't given in to succulent lust when another Vista may have opened in front of me.

NFJS: The Java Memory Model

[More of my first "No Fluff, Just Stuff" experience]

The Java Memory Model session with Brian Goetz was intense, and I wasn't the only attendee to come away from the talk feeling that way. I'm still trying to absorb some of the concepts mentioned in the session, but I will do my best to summarize it here.

"A Memory Model is an abstraction for how one thread sees the effects of another thread's actions on memory." The following optimizations may interfere with this visibility

• Values might be sitting in a processor-local cache and not yet flushed, or the local processor may have stale values in its cache
• Values could be cached in registers and not written to memory
• The processor may have executed instructions out of order
• The compiler may have reordered certain instructions

The problem with these optimizations comes when you are trying to access shared data.

What blew the minds of some of the attendees was the idea that "sequentiality is an illusion" with modern processors. "This is not your father's Von Neumann machine," as Brian put it. But Java does provide the developer with mechanisms to ease the pain.

Synchronize

The synchronize mechanism is one of the tools Java provides to help developers deal with the complexities of concurrent programming. Here is Brian's Rule of Synchronization

If you are writing a field which may next be read by another thread, or reading a field which may have been last written by another thread, you must synchronize.

• Synchronization is required by both the reading thread and the writing thread
• Both reading and writing threads must synchronize on the same lock

In essence you must synchronize when accessing shared, mutable data. Something else that Brian mentioned that probably should be a global rule of programming is "make it right before you make it fast." (Hey, that rule could apply to guitar playing as well!)

Brian then talked about the happens-before relation which states that "if one action happens-before another, then the first is visible to and ordered before the second. This relation is defined in the Java Language Specification (Chapter 17).

So what problems could arise if the Java Memory Model (JMM) did not have the happens-before rule? The optimizations listed above will give you a clue. The order of operation execution in thread A, for example, may appear different from thread B's perspective (just like Special Relativity – order of execution is relative to the observer). Essentially, operations could occur in almost any order.

Volatile

The other tool that Java developers have for dealing with concurrent programming complexities is volatile variables. The visibility rules are similar to synchronized blocks, but there are no atomicity or mutual exclusion guarantees. Volatile variables are good for flags and "for safely publishing objects where atomicity is not required."

There is a lot more in this session including a little history of the JMM, problems with the old JMM, the double-checked-locking problem and how the new JMM fixes it with volatile. He ends with the following advice

• Don't try to reason about ordering in under-synchronized programs
• Make it right, then make it fast
• Avoid tricks which rely on unsynchronized nonvolatile reads, like double-checked locking
• Don't try to outsmart the JVM (synchronization is trickier than you might think)

Like I said, this session was intense. There were people who seemed visibly amazed at some of the things Brian was telling them (myself included). I think another idea from Einstein applies: spooky action at a distance. Spooky indeed.

A note on the speaker: Brian is a good speaker and very knowledgeable. He was obviously the smartest person in the room. He did a very good job explaining something that is very complex which tells me he really understands this subject.

Next up: The Holy Grail(s)

NFJS: The Holy Grail(s)

[More of my first "No Fluff, Just Stuff" experience]

My last session at "No Fluff, Just Stuff" was Advanced Domain Models with Grails with Jason Rudolph. (N.B.: Jason is a friend and former co-worker of mine.) I saw Jason's Getting Started with Grails session at a recent Triangle Java User Group meeting, and was impressed with the simplicity and power of Grails. I was eager to learn more.

Jason started the session by talking about the benefits of GORM (Grails Object Relational Mapping) and how DAOs are evil (maybe those are my words). This is one aspect of Grails that I really like because, as Jason said, no one wants to write another DAO. We should be spending our time as programmers writing business logic, not plumbing.

Here are the key benefits of GORM

• Zero-configuration persistence management
• Rich relationship model
• Declarative validation
• Powerful query support
• Easy scaffolding

All this makes for a happy, productive developer.

GORM, by the way, is built on Hibernate which is something that impresses me about Grails. It is built on proven technology with intuitive behavior. Jason did a great job emphasizing this aspect of Grails by building an application from scratch throughout the session.

Jason showed how easy it is in Grails to map relationships between entities. Using Groovy, here’s how you create a 1-to-n relationship

 class Knight
 {
    static hasMany = [swords : Sword]
 }
 class Sword
 {
     static belongsTo = Knight
 }

Grails takes care of the rest. It can’t get much easier.

Using EJB3 POJOs was about as easy as updating a Hibernate configuration file with the fully qualified class name. Converting those classes to Groovy was easy and, I believe, the preferable approach. In fact, the power of GORM allows you to swap out domain classes written in different languages with little effort.

What was great about this presentation was that Jason spent more time doing and less time pointing at slides. One thing I found a little disappointing, however, was the domain he was using for his examples. I get the joke about Knights and Swords, but I would have liked to see something more related to a business-oriented domain. (I overheard someone in a different session groan about having to see the bookstore example again.) I know it’s not possible to create a real-life application in ninety minutes, but incorporating some of the challenges found in enterprise applications might be useful. For example, ummm….I’m drawing a blank at the moment. This session did run a little short, so I think there is some room for a more complex example.

A note about the speaker: Jason is a good, knowledgeable speaker who knows his domain. He’s not a natural presenter like some of the others, but after seeing him present a few other times I do notice him improving. His passion for technology shows and that makes for an enjoyable session.

--

That's it! That was my first NFJS experience. It was a fun and exhausting weekend, and I look forward to next year. I hope these session summaries were somewhat valuable.

SOA what!

[More of my first "No Fluff, Just Stuff" experience]

My last day at the Raleigh "No Fluff, Just Stuff" symposium began with a session called Implementing SOA. This was another session with Neal Ford who seemed to be in competition with Venkat Subramaniam to see who could speak at the most diverse set of sessions.

The session started off with Neal's opinion that a Service Oriented Architecture is not possible without agile best practices. He supports this by saying that such an architecture must be able to adapt to change gracefully. This seems intuitively correct to me because of the fine-grained nature of services and the complexity of the overall architecture. Without the small stuff being correct and stable, the big stuff won't matter.

What is SOA?

Here is how Neal defines SOA

• Enterprise-wide architecture that breaks monolithic applications into a set of finer grain services
• Services are available enterprise-wide through standard protocols
• New applications are assembled from existing services rather than built from scratch
• Services are registered in a central registry
• Services can be discovered and interfaces can be 'negotiated'
• Common services such as security can be shared by all applications or application services

That seems straightforward enough, but something tells me that even these clear guidelines can be stretched to include architectures that don't embody the spirit of SOA. Because what exactly is a "service" anyway? Hmm. Let's see if we can't flush that out as we evolve to an SOA.

Stages of an SOA

Stage 0, as Neal called it, of an SOA is a set of siloed applications that have no integration. This is the typical scenario of many IT organizations - disparate applications that could share common libraries (e.g., security, logging, etc.), but don't talk to one another and could possibly duplicate information.

In Stage 1 we start to see applications exposing functions as Web Services, but there is no integration or management of these services. This is relatively easy to accomplish, and as a best practice should be done via Web Service facades.

Stage 2 starts the process of centrally managing the exposed services from Stage 1. This is where a centralized service, like a Security Service, can start to be used and is, in fact, a good "case study" for the larger SOA.

Stage 3 is the "paradigm shift" - applications are dissolved into coarse-grained business services and business processes are managed across those services. The business functionality in those siloed applications (Stage 0) start to get cleaved away into standalone services that can be orchestrated or choreographed into business processes. This is where I see the agile/iterative process being a key to success.

Service Versioning

Once you have your services up and running what do you do when you need to version a service? The answer depends on whether your services are strongly typed or loosely typed. Strongly type services look something like this

public int AddOrder( Order toAdd, LineItems[] lineItems )

This is the typical way in which we define a method in Java, but you can see the problems if the interface needs to change.

A better way is to loosely type your services. This is done by having your services pass around a canonically defined document. Endpoints end up looking like this

public void service( Document doc )

What changes in this version is not the service, but the document. The service can then use a factory to retrieve the proper logic for handling the given document version (Strategy Pattern).

With loosely coupled services, we can now create a bus architecture that is document-centric and more resilient to change. Defining a robust meta-model for your document structure, however, is paramount to making this architecture a success.

What's also important (maybe most important) to remember here is that your services must have the correct granularity. Too granular and you get latency issues. Too coarse means there is not enough separation of business behavior. "Business function should drive service granularity."

Other things of interest that Neal mentioned included using XSL/XSLT to transform documents before putting them onto or getting them off of the bus. What I found most amusing are Neal's feelings on BPEL. He calls it “doodle-ware” and thinks it's a bad idea - "keep behavior in code," he says.

Conclusion

This session was jam packed with information, most of which was really useful. With my company starting to implement an SOA I will frequently be returning to my notes on this session.

Next up: The Java Memory Model

NFJS: How to build a team...maybe

[More of my first No Fluff, Just Stuff experience]

Build Teams, Not Products with Jared Richardson was one "No Fluff, Just Stuff" session that actually surprised me. I went in with low expectations, thinking I would be taking a break from the long day of lectures, and ended up really enjoying the talk even though the content wasn't groundbreaking - something I've complained about with other NFJS sessions.

Jared started off by talking about employee motivation using Maslow's hierarchy of needs. He broke down IT worker motivation to the follow needs

• Self improvement
• Respect
• Belonging
• Job Security

This is not an exhaustive list, of course, but something that some employers neglect all too often.

Jared then laid out six "principles" of team building each with a corresponding "anti-pattern." They are

Principle	Anti-pattern
Interaction	Isolation
Mentoring	Immaturity
Learning	Apathy
Vision	Thrashing
Leadership	Feuding
Fun	Boredom

During the rest of the session, Jared kept referring back to these principles when he introduced a new best practice. This was a great way to tie everyday work practices back to a set of core principles - an exercise that organizations should probably do on a regular basis.

We then moved on to the best practices. Like I said above, these were not groundbreaking ideas that are new to the industry. They are things that most companies have probably done in one form or another. I've done several of them at different times in my career. What made this session interesting was how we connected each best practice back to a core principle, and also, how Jared illustrated each with an anecdote.

Here are the best practices

• Daily meetings
  • Three questions
  • One minute per person
  • Everyone talks
  • Scrum
• Code reviews
  • Fast and frequent
  • One-on-one
  • Rotate reviewers
  • Teach by asking
• Team-wide architecture
  • Design as a team
  • Requires a leader
  • Everyone hears, contributes, learns
• Test automation
  • Automate boring work
  • Remove personal touch
• Task lists
  • The source of work

Nothing new here. As an exercise for the reader, relate each of those practices back to the principles above.

The punchline of the session was just as we were leaving someone asked which of these we should be using. Jared replied, "Use what works." I find it amusing because here we are in this session being told the benefits of these best practices just to find out they may not work! "Introduce frequently, remove frequently," is good advice.

One last thing that was mentioned in the session that I found worth repeating was this quote: Working with smart people helps raise the effectiveness of all team members. Something to keep in mind when you are interviewing prospective employees.

Note about the speaker. I guess what made this session enjoyable was in large part due to the enthusiasm of Jared Richardson. He is a very good speaker, second only to Scott Davis in the NFJS sessions I attended.

Next up: SOA what!

NFJS: A couple of disappointments

I want to discuss two sessions during the weekend of "No Fluff, Just Stuff" that I found disappointing: Domain Driven Design (DDD): Simplifying Enterprise Architecture with Ramnivas Laddad and The Zen of REST with Scott Davis. DDD was so disappointing, in fact, that I had to leave 45 minutes into the session.

Part of the problem with the DDD session was that the subject matter dealt with nothing new. The session description reads as follows

"[DDD] recommends dealing with complex software system[s] using a domain model and preserving the model through implementation."

I guess I should have gotten a clue after reading this description, but sitting in the session made me feel like I was reading James Rumbaugh's Object Oriented Modeling and Design book all over again (remember, the one that competed with Grady Booch's book). Maybe the second half of the session had some more punch to it, but I doubt it.

The other problem with this session was that Ramnivas was not an inspiring speaker. As soon as it started I could tell it was going to be a dreadful session. He seemed like a knowledgeable enough fellow, but his speaking style was way too monotone.

"The Zen of REST" was a little better (I actually stayed the entire time), but I was disappointed because it also told me nothing new. Scott spent a lot of time showing us what Yahoo! is doing with REST, which is OK I guess, but I didn't feel any zen from this type of presentation. I am not sure exactly what I was looking for in this session, but my understanding going into it was not enhanced when I left.

Would I recommend either of these sessions? "The Zen of REST" maybe. It at least had some good live examples. DDD, however, would only be useful for someone just starting out in software design.

Next up: How to build a team...maybe.

NFJS: Domain Specific Languages

Building DSLs in Static and Dynamic Languages was another "No Fluff, Just Stuff" session that I was really looking forward to. There has been somewhat of a buzz lately about Domain Specific Languages (DSLs), especially with the rise of languages like Groovy. With the little experience I have with Groovy I can see why it would be a great choice for creating a DSL. This session also explored creating DSLs with static languages, with particular emphasis on Java.

Neal Ford started the session by talking about how DSLs make programmers change their abstraction style. We should no longer think in trees or hierarchies, but in layers of abstraction using language – what Neal called "working at a higher level of abstraction." He also distinguished between declarative vs. imperative programming, which had echoes of what I heard in the Drools session.

To emphasize the importance of moving to a higher level of abstraction, Neal made the observation that "every non-trivial human behavior has a domain specific language." Here are some examples

• "Iced Decaf Triple Grande Vanilla Skim with whip latte"
• "Route 66, swinging, easy on the chorus, extra solo at the coda, and bump at the end"
• "OMFG D00d Bob is t3h UBER 1337 R0XX0RZ LOL

The point of all this is, of course, to show that there is a disconnect between how we as programmers write code in our problem domain and how we speak in our problem domain. Can't we bring the two together? Wasn't object-oriented programming supposed to do that?

In typical programming, we code using an API that has an explicit context. For example

Coffee latte = new Coffee( Size.VENTI );
latte.setFatContent( FatContent.NON_FAT );
latte.setWhip( Whip.NONE );
latte.setFoam( Foam.NONE );
latte.setTemperature( Temp.EXTRA_HOT );
latte.setStrength( 5 );

The context, latte, is explicit and repeated. DSLs, however, have an implicit context which seems more natural to us. You would speak the code segment above thusly

Venti half-caf, non-fat, extra hot, no foam, no whip latte

See, you know the context so why repeat it. Why can't we code in this manner? Maybe we can.

Types of DSLs

There are two types of DSLs: internal and external. Internal DSLs sit on top of the base language and make the job of programming a little more fluent. An external DSL is a separate language that needs a "lexer and parser." One disappointment that I think many people had with this session was that we did not go into external DSLs enough.

What is meant by fluent with regards to internal DSLs is that lines of code are treated as sentences – complete units of thought. This makes code easier to read, but much harder to write. The simplest way to create an internal DSL with Java is to have methods return this so that actions can be chained, and context does not have to be repeated. Also, method names have to be a little more grammatical. Here's an example

Car car = new CarImpl().withMarketingDescriptionOf( new MarketingDescription( “Box” ) ).
andAttributeOf( “length”, “50.5” ).
andIncludesA( “ladder” ).
andAttributeOf( “lining type”, “cork” ) );

While I can see how this can be more fluent, I think the nature of Java still makes this look and feel clunky (a method named andAttributeOf, yuck!). Neal's comment about how this is harder to write is well taken. As an aside, Smalltalk's nature is better suited for this type of programming.

Neal then spent some time on best practices for method chaining and how to avoid some pitfalls like the stopping problem. I leave that for the reader to explore.

Internal DSLs in Groovy

Next, Neal talked about creating internal DSLs with Groovy. Looser syntax, closures, dynamic typing all make Groovy a better base language for writing DSLs.

One of the most powerful features in Groovy that makes a DSL easy to create is the category feature. This allows the developer to add additional behavior to classes not under their direct control. For instance, you could add a method to Integer called days. Why? So you could do something like this

2.days.fromToday.at( 4.pm )

This can be valid syntax in Groovy if implemented correctly. In Groovy 1.1 this will be even easier with the ExpandoMetaClass class (something borrowed from Grails). The analogy I give for this concept is that you are teaching an old dog new tricks.

Conclusion

This was a good session. It didn't live up to my expectations, but overall I enjoyed it. I do have some doubts, however, on the benefit of creating internal DSLs with Java. This idea seems like a better fit for Groovy or dynamic languages in general.

A note about the speaker. Neal Ford is a very competent speaker. His strength is his breadth of knowledge. I attended two of his sessions, which, by the way, covered two completely different topics, and in both cases you could easily tell he had a command of the subject matter. People who I talked to who attended his other sessions came to the same conclusion. He is not a pure speaker like Scott Davis, but he is very good.

Next up: A couple of disappointments