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.