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

NFJS: Drooling

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

The second day of the "No Fluff, Just Stuff" symposium started off with a session called Drooling with Groovy and Rules presented by the indefatigable Venkat Subramaniam. I was really looking forward to this session, and I wasn't disappointed.

Venkat started the session talking about rules-based programming. Now, I've programmed rules engines before, but it had been a while and this refresher was very informative. He contrasted declarative programming (you say what you want, not how to do it) with procedural programming (a series of sequential instructions). Rules-based programming is declarative because you are describing the behavior you want not creating an algorithm with instructions to follow. You can program a rules engine in a procedural manner, but the if-else logic becomes unmanageable.

We then moved on to the anatomy of the Rules Engine. There are four basic parts to a rules engine: the rule base, the working memory or fact base, the inference engine, and the action list. I won't go into detail about each of these, but what basically happens is, given a set of facts that are in working memory, the inference engine determines which rules (in the rule base) will be fired. The result is a set of actions. What I just described was the forward chaining method. The other method of reasoning is called backward chaining which starts with a set of goals and works backwards to find supporting data.

After talking a little bit about computational complexity and the RETE (ree-tee) algorithm, we moved on to Drools. Drools is an open source rules engine that is JSR 94 compliant. You can express the rules in XML with Java or Groovy, Python, a Domain Specific Language, or the new JBoss Rules. Venkat demonstrated Drools with XML and Groovy which was great because I finally got to see Groovy in an enterprise type environment. Here's a look

<rule name="Big Time Buyer accepts Big Time seller" salience="1">
<parameter identifier="buyer">
 <class>com.agiledeveloper.Collector</class>
</parameter>
<parameter identifier="seller">
 <class>com.agiledeveloper.Collector</class>
</parameter>
<parameter identifier="theExchange">
 <class>com.agiledeveloper.Exchange</class>
</parameter>
<groovy:condition>theExchange.seller == seller</groovy:condition>
<groovy:condition>theExchange.buyer == buyer</groovy:condition>
<groovy:condition>buyer.bigTimeOperator</groovy:condition>
<groovy:condition>seller.bigTimeOperator</groovy:condition>
<groovy:consequence>
 println('Big Time Buyer accepts Big Time seller')
 theExchange.okToTrade = true
</groovy:consequence>
</rule>

He also showed a little of the JBoss Rules syntax which follows more of the typical rules-based language format. Apparently, JBoss has no immediate plans to support Groovy in the JBoss Rules format (I'm a sad Panda).

Anyway, this was a great session because, like I said above, I got to see Groovy in a real enterprise environment. Okay, that maybe a little strong, but finally seeing the potential was great. Also, programming a rules engine forces you to think in a different manner and can introduce some interesting challenges. There are several opportunities at my current job for this type of programming, so this session was extremely beneficial.

Next up: Domain Specific Languages

More minimum wage silliness

Actually, the same minimum wage silliness we've heard before. So, I sent this letter to the New & Observer.

In a recent editorial, Holly Sklar praises the recent hike in the minimum wage using faulty economic logic. She makes the claim that higher wages have the effect of increasing consumer spending which we are to assume is good for the economy. However, an artificial raise in wages not backed by underlying economic reality will have the effect of increasing demand for the current supply of goods and services, thereby putting an upward pressure on prices. In the end those people who she wanted to help will have higher nominal wages, but their real wages will be the same or lower. We should be looking to increase real wages by increasing the supply of goods and services, which will put downward pressure on prices. Raising costs for producers will do nothing to achieve this goal.

She then states that higher wages raise "worker morale and productivity" and improve product quality and company reputation. If it were that easy wouldn't the greedy, profit-seeking companies she admonishes so much figure this out as well? Maybe she should start a business and show us how to defy economic law.

NFJS: What is OSGi?

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

My last session on the first day of the "No Fluff, Just Stuff" symposium was another talk by Venkat Subramaniam called OSGi: A Well Kept Secret. It's interesting that Venkat titled this talk "A Well Kept Secret" because even after hearing it I must confess that the secret is still safe. I am not sure what to make of OSGi. Here is the OSGi website. Go there, and when you come back please tell me what it means.

The key catchphrase that I got from the session was that "OSGi helps you cope with classpath hell." Okay. Maybe I haven't worked on big enough applications, but I don't ever recall having serious enough problems with classpaths to call it hell. Apparently OSGi helps you manage multiple versions of a class. Hmmm. Why do I want to deploy multiple versions of a single class? I know there are times when you need multiple versions of software running, but this solution seems odd to me because you have to manage another run-time environment, and that just seems like more complexity than is warranted.

I think part of the problem was that the session was mostly spent configuring the OSGi environment and deploying various versions of "bundles," and no time was spent on running a real application against those different bundles. And how would it work with a WebSphere environment? The simple application that Venkat ran actually failed to show the gist of bundle management. The session ended before he got to fix whatever bug it was that caused the problem.

I guess I could see some value in OSGi, but it just seemed to me that it was a solution looking for a problem. Or even a solution whose problem no longer exists.

Next up: Drooling

NFJS: Groovy and Java

[The continuing story of my first No Fluff Just Stuff experience]

Next up at my first "No Fluff Just Stuff" experience was a talk by Scott Davis entitled Groovy and Java: The Integration Story. I was really looking forward to this session because I've been using Groovy lately for simple scripting tasks, and I wanted to see how the language could be used with Java in a true enterprise application. Unfortunately, I was disappointed.

The good things about the session were Scott's comments on the Groovy and Java compilers, and how circular references can come into play when Groovy and Java code are mixed. He gave the following set of Best Practice recommendations when using the languages together:

• Group classes by language and tier
• Write interfaces in Java
• Write implementations in either Groovy or Java

I also liked the recommendation of using Groovy for unit tests as a way to bring the language into a shop that is heavily invested in the Java enterprise solution. Jason Rudolph had actually recommended this practice when we worked together, but it was good to hear it again. I only wish that Scott had provided some good examples of this practice.

This brings me to the things that made this session a disappointment.

First of all, I felt he spent a little too much time upfront talking about basic things like downloading Groovy and how to use a Unix softlink to maintain multiple versions on your machine. This is a trick that has been around for quite some time, but he seemed to think he was imparting some hidden Groovy secret.

Other basic Groovyisms that seemed out of place for this session were things like explaining the println() shortcut for Java's System.out.println(), and how the last line in a method is an implicit return statement. These are things that should be covered in a Groovy introduction session.

Scott then went into an array of different topics that seemed to be disjoint. He talked a little about code coverage with Cobertura, Spring, and Ant, all of which were good topics, but not for what I was expecting.

Overall I thought that the session was a mashup of different topics that only had a cursory relationship to Java and Groovy working together. Maybe my expectations about the integration of these two languages is different from what others believe. In the session later in the weekend on Drools, I saw Java and Groovy working together in a rules-based system. That's the type of thing I wanted to see in Scott's session.

A word about the speaker. Scott Davis was arguably the best pure speaker at the symposium. He has a very appealing style for this type of event - he is knowledgeable and his presentations are fun. He has so much enthusiasm that he bounces across the stage at times keeping the attendees on their toes and entertained. The rhythm of his speaking style matches this buoyant choreography.

Next up: What is OSGi?

NFJS: The Hammer

[The continuing story of my first No Fluff Just Stuff experience]

My first session at "NFJS" was Annotation Hammer presented by Venkat Subramaniam. Venkat used an interesting analogy to start the session.

In pre-Java 5 (pJ5) code, how did we specify that a class could be serialized? We used one of the tools in our toolbox at the time – the inheritance hammer. Specifically, we implemented the serializable interface. Or did we? How do you implement an interface when there are no methods to implement? We had a hammer (inheritance) and the problem (serialization) became a nail.

The problem was that we had no way to "convey consent" before Java 5. Now, with annotations, we can address this problem more intuitively.

The analogy of a hammer really drove home the point (no pun intended) about forcing a solution using existing structures. Another example of this point was given when we talked about how deprecation was handled in the pJ5 code. Remember the special Javadoc comment? This is obviously bad because hadn't we always been taught that compilers should ignore comments. Again, the annotation solution is much more intuitive.

I wont go into the details of the material because it was basically an introduction to annotations. It was, however, enjoyable for someone like myself who has had limited actual experience using annotations. I also liked seeing how this feature is being used to make the programmer's life easier in many realms of Java development. From EJBs to web services to unit tests, annotations are becoming a valuable tool (pun intended).

One note about the instructor. Venkat is very knowledgeable on this and many subjects. I had three sessions with him on three completely different topics, and all were enjoyable (but not all valuable). He was very energetic even later on in the weekend when I was tired just sitting and listening. He seems to have boundless energy and an iron larynx.

Next up: Groovy and Java

'No Fluff' weekend

This past weekend I attended the "No Fluff Just Stuff" Symposium's Raleigh tour stop - a two-and-a-half day geek fest that was both fun and mentally exhausting. The symposium consisted of eleven sessions that were roughly arranged into tracks that focused on Groovy, Java performance tips, Agile development methodologies, and client-side programming. Attendees did not have to keep to any one track throughout the weekend, and in fact, it was probably more enjoyable if you didn't.

I don't consider myself a "true" geek because I don't live and breathe technology (as you can probably tell from my other blog posts); but I am a software engineer (and have for nearly 15 years), and this event was a great way for me to keep up with technology trends. It was also a good place to network with other people in the area unless, of course, you are anti-social like me (maybe I am a "true" geek).

In subsequent posts I will give my thoughts on each session individually. As much as I liked the event overall, there were sessions that I felt were of dubious value. Stay tuned!

Limits of Reason

[I am currently reading Friedrich Hayek's Law, Legislation and Liberty, Volume 1: Rules and Order. I will attempt to summarize the book chapter-by-chapter in this and subsequent posts.]

Reason and Evolution

What are the limits of human reason? According to philosophers such as Rene DeCartes reason, independent of the senses, can determine knowledge. But is this universally true? Hayek says no.

Knowledge, particularly in the social realm, is dispersed amongst the members of society, and so any attempt to construct complex societal institutions are doomed to failure. In fact, human institutions evolve over time through a process... well, let's let Hayek explain

...a process in which practices which had first been adopted for other reasons, or even purely accidentally, were preserved because they enabled the group in which they had arisen to prevail over others.

Now, I find this extremely interesting because it reminded me of something I learned while reading At the Water's Edge, by Carl Zimmer. In that book, Zimmer talks about the biological-evolutionary concept of exaptation - the idea that traits that had evolved for one purpose can be beneficial for a different purpose, even if the original purpose is lost over time.

I often make the analogy that the market process is an evolutionary process, and that both are examples of non-linear, chaotic systems. Although Hayek doesn't explicitly say as much, one of the lessons I get from this chapter is that the evolutionary process is even more pervasive in human societal development.

Getting back to the theme of human reason, Hayek continually reminds us that information is dispersed and because of this our knowledge is limited. Those who believe that human institutions can be designed by pure reason alone are thwarted in their attempts because of this limitation. Man's confidence in science, says Hayek, has fostered in him the belief that complete knowledge about society is possible.

All is not lost, however. We can overcome our limitation of knowledge by utilizing the dispersed knowledge in a civilized society. We can see this in the institutions of language, morals, currency, etc. More on this later.

Hayek blames the 'rationalist' philosophy that was born out of the Age of Reason for the belief that human reason alone can construct society. Starting with DeCartes, rationalist philosophers believed that the same scientific method that was used to construct physical systems could also be used to create human institutions. We see it in politics today - many believe that just getting the right people in charge will solve all of our problems.

One last interesting link with evolution is the way Hayek criticizes those who think that human institutions must be rationally designed. His tone is similar to the tone that scientists use to criticize creationists who think that biological life is too complex to have emerged without some designer.

TANSTAAFL: Health care episode 82

Another day, another load of nonsense regarding single-payer health care systems. Nicholas Kristof can be counted on to regurgitate leftist canards like a drunken frat boy at a keg party.

I sent this to the Raleigh News & Observer:

Nicholas Kristof, in arguing for a single-payer health care system, explains that the current U.S. system is inefficient because 31 percent of spending goes to administrative costs. He, like many socialized health care advocates, is fixated on monetary costs.

As economist Tyler Cowen explained in a recent New York Times piece, when patients don't directly pay for health care they will demand extra services. Private insurers will spend money to monitor these services to make sure they are not allocated indiscriminately. A single-payer system would have to deal with the same pressures, and, as evidence from other countries shows, the government will require patients to wait for care or not provide it at all. So the costs still exist; they are just non-monetary and are borne by individual patients.

The "Rube Goldberg" plan

To the Raleigh News & Observer

The John Edwards plan for America's health care system consists of a single-payer initiative run by the government, and an apparent market initiative with plans provided by private companies. According to Mr. Edwards, "the idea is to determine whether Americans actually want a private insurer or whether they would rather have a government-run...single-payer plan." The details of this plan, however, make me think that this "contest" is rigged.

His plan would force everyone in America to be covered, force employers to fund employee plans in one fashion or another, and force health insurance companies to cover certain services and provide a "fair" price for those services. Calling this a market-based approach stretches the language beyond any Orwellian measure. Both supply and demand would be coerced into a "play" market within which market signals would be prevented from properly allocating scarce resources.

This plan would be better termed the "Rube Goldberg" health care plan - a complex system with the simple purpose of getting Mr. Edwards elected.

Mature and Confident

Frank Furedi at Spiked makes a great point regarding the reactions to the Virginia Tech shootings:

A mature society can accept the fact that, occasionally, human beings do very destructive things;a confident society does not have to search for special meaning in every act of human degradation. We will never really know why he did it. However, what we can do is talk to each other a little more, look out for each other, and not turn away when someone is hurting (emphasis mine).

A "confident society" does not view its members as potential psychopaths ready to go on a shooting rampage. Sadly, however, there are many who call for government action to treat law-abiding citizens as immature imps needing paternal observation. A government that treats its citizens as such is a government that citizens need protection against.

What happened at Virginia Tech was a tragedy, and we will probably never have a clear explanation as to why it occurred. But let's be confident enough not to have another PATRIOT ACT style overreaction.

Batty legislation

This is one of many reasons why health care socialism is so dangerous. If the government, in the name of public health, can legislate the type of bat baseball teams can use then absolutely nothing is off limits.

Low-fat diets and paternalism

I like John Tierney. He is a good writer with a strong libertarian bent. When he was on the NY Times op-ed page his articles were a refreshing break from the collectivist drivel that inhabits that paper. Now his science blog is daily stop on my blog surfing. I say all this because the questions he asks at the end of this blog post have me confused.

He asks "Why did the federal government ever think it could determine the best diet for everyone in America? And why should it keep on dispensing advice?" So my question to Tierney is why would he think that the federal government would do otherwise considering its paternalistic track record?

At least the dietary recommendations are just that, recommendations. The more onerous problem is that government thinks it can best determine our retirement, and taxes us for the "service."

More oil from old wells

Price signals actually work. Imagine that.