Whatever

• Two interesting stories about human evolution and what has driven the process
• Technology can help solve our "energy problems," as usual
• Exposing the flaws of the social-welfare state
• Wow! I think my wife might want this software.
• This is why I started playing the guitar. Even though the sound isn't what it used to be it's still a neat story.
• So what?

Whatever

• "I've got to get me one of these!"
• Doesn't this seem like it would make the criminal's job that much easier?
• Does this mean I'm not a programmer?
• The Evolution of Java. Oh, how true! Sad, but true.
• This is why public wifi is a bad idea. If the government can force private institutions to turn over "images including 'obscene' cartoons and drawings" that were sent over its network then that same government will have no problem regulating what goes on over public wifi. More here.
  
• A New Pope...
• The Spirit of 1776! Thanks for nothing W.
• Charles Wheelan gives a good explanation of why self-inflicted embargoes tariffs are bad (HT: CafeHayek)
  
• Pimp'n the 'naut
• Well, is Arnold a cyborg or not?
  

Fight the ignorance

One blog that I read daily is the Neurologica Blog which is run by Dr. Steven Novella. His articles are always very interesting and informative even when the topic is a complex scientific/medical issue. (I highly recommend his podcast the Skeptics Guide to the Universe. He and his fellow "rouges" can always be counted on to provide a humorous and informative look at science and skeptical news of the day.)

I want to comment on this article in which Dr. Novella examines the legal and social issues of "free citizens giving medical advice." He wonders how we protect the public from those who spout bogus medical advice while at the same time upholding the basic right of free speech. Novella doesn't claim to have the answer, but I wanted to comment on something he says at the end of the article. Here's what he says

"...although I think we do need to thoughtfully tighten up our regulation of the giving of medical advice, any legal remedy is extremely problematic. The far better solution is to educate the public so that they can recognize nonsense when they see it. This, however, is also a very imperfect solution as it is far easier to spread misinformation than it is to correct it."

He is skeptical of legal remedies, as I am, and offers education as a possible solution. I think this solution can actually be more powerful than he understands.

I think we as individuals can start by changing expectations about what is acceptable in society. Educate the credulous; call bullshit on those who perpetuate bogus claims; don't let snake oil salesmen go unchallenged - call them out in a public forum. Setting such expectations creates true organic law that is a better reflection of values shared by individuals in society. Political legislation creates constituencies of power that pit groups against each other and creates a market for pull. (DRM is an example of legislation that doesn't reflect the reality "on the ground" but has powerful constituencies that have the ears of politicians.)

Is this idea of "organic law" via expectations a perfect solution? No. But it is at least more nimble than political legislation which punishes the many to stop the few.

I also believe we have to be careful when informing others about pseudo-science and other false claims. I was recently in a discussion with a friend about natural medicines and homeopathy and I was a bit harsh in my criticisms. If I had to do it over again I would most likely take a different approach because in the end I think my harsh tone was counterproductive. There are times, however, when just calling bullshit is necessary.

You'll read more about this idea of "organic law" if I ever get back to live-blogging Law, Legislation, and Liberty. Until then, fight the ignorance!

Whatever

• The world is going crazy (HT: The Agitator)
• The future of the user interface (I really like the reactable)
• Ha! I heard the same talk seven years ago
• Commie chic
• The Fed is just going to make the ultimate day of reckoning that much worse
• Damn! I may have to agree with the politicians on this one
• Back to the days of sailing
• You can't use oil; you can't use nuclear; now you can't use wind
• Ah! Scientists against science. Money quote: "Here's what the Bible says. Now let's go to the rocks and see if we find the evidence for it." And if the evidence isn't there then ... um .... isn't God wonderful!
  
• It seems that the ignorant masses haven't received the memo that Wal-Mart is evil
• Ok, I don't understand most of this, but the implications makes me think that the science is B.S.

Reign over me (cont.)

I sent the following to the Raleigh News & Observer

In your editorial "No dynasty needed," you quote Warren Buffett as saying that "the resources of society I don't think should pass along in an aristocratic dynasty of wealth." This you use to help make your case for keeping the estate tax.

If we are truly concerned about "aristocratic dynasties," however, why not go after the more harmful dynasty of power? Let's amend the Constitution so that family members of former elected officials are prevented from taking their relatives' former seat - a growing phenomenon with regards to Congressional seats. It is possible, after all, that by the year 2017 the presidency will have been in control of two families for nearly 30 years. Why is that less troubling than someone handing down rightfully acquired wealth to his heirs?

We easily violate property rights to prevent so-called "dynasties." Why should we let eligibility requirements for political candidates stand in our way?

Thanksgiving Whatever

• The Gettysburg Presentation
• The government doesn't like competition
• Simple, small changes can lead to big effects. Especially when dealing with complex systems.
• Gee, who'd of thought. Drunk men at football games acting like...um...drunk men at football games.
• The Twenty-first Century version of the Speak and Spell, and the idiots who buy it
• The snake that is the Mississippi River
• My alma mater struggles to cope 2 years after Katrina
• So this is why I can walk around in my underwear in public and not feel weird

Happy Thanksgiving!

Reign over me

"The resources of society I don't think should pass along in terms of an aristocratic dynasty of wealth. I believe in keeping equality of opportunity as much as you can in this country."

Those were the words of renowned investment guru Warren Buffet when he spoke to the Senate Finance Committee recently. He was there to lobby the U.S. Congress to keep the Inheritance Tax which was set to expire in 2010 (it would actually only expire for that year and would return in 2011). It's somewhat sad that such leftist shibboleths are spoken by a man who seems to have the Midas Touch when it comes to investing.

Let's start from the beginning. "The resources of society..." No Mr. Buffet they are not society's resources they are yours. You created them with your hard work - they would not have existed otherwise. Why does "society" have a claim on them? Okay, maybe you can make the claim that if it wasn't for "society" you wouldn't have had the ability to acquire such wealth. But the reverse case could also be made: other members of society wouldn't be as rich or even have jobs if it weren't for men like you.

"... I don't think should pass along in terms of an aristocratic dynasty of wealth." I applaud the healthy suspicion of aristocracy, but let's not forget the other American tradition: respect for property rights. I would also argue that a "dynasty of wealth" is somewhat innocuous unless that wealth is allowed to wield the power of government. We can blame the owners of such wealth for influencing government power, but the onus must fall upon elected officials who allow themselves to be bought.

A note on terminology: Aristocratic dynasties are primarily governing institutions. If we really wanted to stop true "aristocratic dynasties" shouldn't we amend the constitution to prevent family members of former elected officials from running for office? (It is possible that by 2017 the U.S. Presidency would have been in the control of two families for almost 30 years. There is also a growing trend where children are replacing their parents in Congress.)

"I believe in keeping equality of opportunity as much as you can is this country." How is it that opportunity is taken away from anyone if you, Mr. Buffet, are able to leave your wealth to your heirs? I would argue that your wealth has created opportunity for countless numbers of people - whether it be with jobs that were created or investments that increased in value. Do you trust the political process with such wealth more than your heirs? You may want to think that your taxed wealth will go to better someone's life, but it could just as easily be said that that money will go to support more corruption and war. I would hope that you would look to clean up government before giving it more wealth to destroy.

Here's an idea: Why not continue your philanthropic ways by willing your estate to a cause (or causes) that would provide opportunity directly to individuals? Why should that wealth have to be pass through the unproductive sieve of a political bureaucracy?

Unfortunately, Mr. Buffet is part of a sad tradition of wealthy people who want to fund and lobby for the destruction of the very engine that made them wealthy. Maybe this book by Garet Garrett would be a valuable read.

Whatever

Some random whatever

• "E8 encapsulates the symmetries of a geometric object that is 57-dimensional and is itself is 248-dimensional." Umm...now me feel dumb.
• Wow! This is neat - security in your pocket.
  
• While I agree with their overall message, I hate that these women politicized such an occasion
• I've been suspicious of AT&T for a long time. Now I know why.
• A great explanation of trade by Russ Roberts
• It's about time the car gets an overhaul
• Before too long these monkeys will be voting
• Ignore Al Gore!
• When the government gets to define privacy, you no longer have it
  

Milton Friedman on "greed"

I love this YouTube video of Milton Friedman giving Phil Donahue a good smack-down. In contrast to Donahue's banal, simplistic arguments, Friedman teaches with reason and trenchant arguments while maintaining a sense of class.

Ants and order

Here's an article from Carl Zimmer talking about how insects create order by following very simple rules. What's interesting is that in the article Zimmer mentions that experiments were run with humans to mimic this order making phenomenon. I couldn't help but wonder why they had to run experiments with humans, because you could easily study human society to find similar spontaneous orders. Medieval law, language, the market process and other aspects of human culture can be traced to individuals following simple rules.

I will have more to say about this in future blog posts when I continue my live blogging of "Law, Legislation, and Liberty."

Two minute answers

I've joined Toastmasters recently, and in this past week's session the table-topics master asked "how would you fix the problem of rising gas prices?" I regret not volunteering to answer because it would have been a good forum in which to educate people on the market process. So here is the answer I would have given.

My answer is that I don't know, and neither do you. No one in Washington knows and no environmentalist or oil company executive knows.

The answer, or more likely answers, will emerge from what Ludwig von Mises called the "daily repeated plebiscite" of the market process. Each of us contributes to this process by acting on our own bit of information. Consumers make decisions about what and how much to purchase, and producers and entrepreneurs decide on what and how much to produce. What governs this process is not some central authority with god-like powers; nor is it some committee of wise men with only the public good in mind. The governing mechanism of this "daily plebiscite" is the price system. Rising prices encourage consumers to cut back on purchases while at the same time encouraging producers to find new sources of supply. Innovative new products and technologies become more viable with higher prices.

Now I know this answer is somewhat simplistic because it ignores the international political issues going on in the world. It also assumes that the normative statement of rising gas prices being a problem is correct. But there was a two minute time limit!

Whatever

Some random whatevers

• Private efforts to preserve the coast
• Someone didn’t get the memo that obesity is always bad
• Doesn't this happen naturally at vacation spots all over the world?
• Yawn...another planet found
• I'll be bookmaking this for sure
• Does this mean the vroom, vroom, vroom gets replaced with hum, hum, hum
• So, the OLPC is going to be built in China. Does that mean the factory workers will get to keep the computers they make?
• Maybe this can answer this (last paragraph)
  

Economics of health care

I've written many blog posts about health care and the problems with government-run systems, so I was excited to see that the latest episode of EconTalk with Russ Roberts was about the economics of health care. Take a listen.

BTW, if EconTalk is not one of your regular podcast subscriptions, you should make it so. Russ Roberts is a great host, and his topics are very thought provoking and interesting. If you have listened to EconTalk before then think about voting for it as the Best Podcast of the Year.

While I'm on the subject of the economics of health care, here are some interesting articles to peruse

• Abolishing the Middlemen Won’t Make Health Care a Free Lunch - a great article by Tyler Cowen showing how the costs of health care are not just monetary
• Beyond those health care numbers - Gregory Mankiw debunks some common myths about health care in the U.S.
• Brooklyn doctor opens IM practice - a great story about an entrepreneur bringing health care to the uninsured
• Here are several horror stories about government-run systems
  

The Curse (cont.)

Cruel fate, why must you mock me so?!

Joe Torre leaves the Yankees
Dark Days Ahead

Kosmos and Taxis

Go to the ant, you sluggard;
  consider its ways and be wise!
It has no commander,
  no overseer or ruler,
yet it stores its provisions in summer
  and gathers its food at harvest.
-- Proverbs 6:6

I continue my live-blogging of Law, Legislation, and Liberty here with an investigation into order and its sources.

Order

Hayek defines social order in the following way:

“a state of affairs in which a multiplicity of events of various kinds are so related to each other that we may learn from our acquaintance with some spatial or temporal part of the whole to form correct expectations concerning the rest, or at least expectations which have a good chance of proving correct.”

The key word in that definition for me is expectation – order is expectation. Order is knowing that a cause will have an effect. Hayek expounds on his definition by saying that order manifests itself in the matching of intentions and expectations of different individuals who are members of a society and who are dependent upon cooperation with others.

Sources of Order

Now, having defined order we need to determine how it comes about. According to Hayek there are two sources of order – made order (taxis) and spontaneous order (kosmos).

Made orders require a “maker” from outside the system (exogenous) with a deliberate arrangement in mind. The “maker” is authoritarian and requires knowledge that is not possible to attain when dealing with complex systems. Simple organizations are made orders that have defined rules for the different roles. The operational details of those roles, however, are still left to the individual members.

Spontaneous orders, on the other hand, emerge based on rules not known by the individual elements. Nature teems with this kind of order (e.g., evolution, insect colonies, etc.), but we can also see it in human institutions. Language is a classic example, but what is more interesting is the order that emerges in basic human civilization. For a social order to exist individual members must follow certain rules, but how are those rules defined if a social order does not yet exist? The rules must evolve over time. Just like evolved traits that allow biological forms to survive and reproduce, social rules that allow individual members of a group to survive will be passed on and allow the group to survive. (We must be careful here and not equate social groups (i.e., society) with organisms. Organisms are concrete entities while social groups are mere abstractions that are constructed by the mind.)

Hayek says this about the rules that govern human society:

"Although man never existed without laws that he obeyed, he did, of course, exist for hundreds of thousands of years without laws he 'knew' in the sense that he was able to articulate them."

Could this be why murder seems so intuitively wrong to us? What about theft and property rights in general? Could we have evolved past a primitive state without these “laws”?

Conclusion

What is the purpose of defining order and its causes? Hayek is basically leading us to a differentiation between law and legislation - laws are naturally forming while legislation is man-made. Laws are what bring about a natural order. What does legislation bring? To be continued...

The End of Scarcity

This article is another reminder that John Edwards is an economic illiterate. If he were to be elected president he would do to this country what George Bush is doing to Iraq. Ok, that's a little strong, and there aren't many other candidates in this race that would be better, but come on! We are talking about a basic understanding of scarcity and incentives.

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.

"The Two Metaverses"

[Inspired by this article]

"Today, under George W. Bush’s avatar, there are two metaverses, not one: One metaverse that does the work, another that reaps the reward. One metaverse that pays the Linden-dollar taxes, another metaverse that gets the tax breaks. One metaverse – the Residents - whose needs Linden has long forgotten, another metaverse – the Feted Inner Core - whose every wish is Linden’s command. One metaverse that is struggling to get by, another metaverse that can buy anything it wants, even Linden Labs."

"Two Americas" indeed

To the Raleigh News & Observer

According to [Chapel Hill Town Council member] Laurin Easthom, John Edwards is just another in a long line of liberal politicians who should not be criticized for their wealth. The "Two Americas," it seems, is divided not by wealth or class, but by differing ideologies. Those who believe in the heavy hand of government are allowed to partake in "conspicuous consumption." All others belong to "narrow-interest America."