Tom's Blog

Let me start this review of Dan Brown's latest novel by saying I read Angels & Demons and The Da Vinci Code and thoroughly enjoyed the stories and the storytelling. Second, although The Lost Symbol was at times painful to read, I do not join other critics who point out the preachy, moralistic ending. Sometimes we need a reminder to return to the basics of our morality. Finally, I plan to reveal minor details of the book here but I won't disclose any plot twists or surprises.

The Lost Symbol reads as if Dan Brown had been kidnapped and tortured by the Masons, just like one of the characters in the book is kidnapped and tortured by an evildoer, and forced to write this book under duress. Each chapter, while revealing frat-boy antics committed by the Masons during its rituals, also includes what seem to be apologies to the reader for those antics. Brown constantly reminds the reader that Masons have included the geniuses of history, the rich, the politically powerful -- including, he says, most of the high-ranking members of all three branches of the U.S. government. Whenever a character in the book criticizes a Masonic activity, the hero of the book reminds us how warm and cuddly the Masons really are to the point that the subtitle of the book could have been, "Hug a Mason Today."

The constant apologies for the Masons is not why I thought this book was a Brown dud. I actually learned what I hope are facts about Masonic history from this book, which I thought were enlightening and interesting. No, the worst part of this book is the amateurish writing and the forced, silly narrative. Brown wanted to ladle so much history and symbology onto the pages that the hero of the story, Robert Langdon, has to constantly stop and lecture one or more of the other characters in this book on the history of Freemasonry and all the wonderful contributions the world has received unto it by a Mason. We're 30 seconds from the clutches of the bad guys, from whom we are running so we can save someone's life, but wait, let's stop a moment so I can explain in historic detail a particular symbol, or show you this nifty, magical number sequence and spell out in detail why it pertains to our rescue mission. Those stop-and-explain moments clue the reader in early that the tension the author is trying so hard to build must not be really all that tense if the main characters have so much time to marvel over history while being hotly pursued.

To add to the amateurish narrative, the characters, all portrayed as very smart and world-wise, are shocked, shocked! at every predictable turn of events. The characters actually exclaim, quite regularly, "Oh my God!" when something occurs that the readers will have predicted 5 pages ago, pandering to our egos so we can constantly pat ourselves on the back on how smart we are. Langdon, who is surprised the most, has evolved from a savvy, likeable university professor in The Da Vinci Code to a naive, gullible idiot savant. What? You mean this secret package as heavy as a bowling ball, the one my good friend and mentor (and, gasp, a 33rd degree Mason) told me years ago to keep safe and guard with my life because evil people across the entire globe would kill for it, and for which I got a mysterious phone call this morning telling me to bring this vital package to Washington, D.C., this heavy package I have been carrying over my shoulder, which I completely forgot I was carrying even though my shoulder is aching from the weight, might have something to do with why my friend and mentor has been kidnapped? Oh my God! How could this be? I'm shocked! Shocked! And sadly, I'm not exaggerating.

Another example of the irritating writing packed inside The Lost Symbol is that nearly every chapter begins with a retelling of what has occurred up to this point -- just in case the previous section had lulled you into a deep case of neurasthenia and you lost all memory of the previous dozen pages. Why Dan Brown felt he had to constantly summarize previous events is a mystery. If you ignore my suggestion to pass on this book, you will remark to yourself each chapter how you haven't seen such great recapping of events since watching the first three minutes of Batman reruns from the 1960s where they summarize the previous week's cliffhanger.

As the final reader irritation (especially to us in Washington, D.C.), Brown gets some of his D.C. geography, details and landmarks wrong. Here are some of the more obvious factual indiscretions:

• His limo driver takes him from Dulles Airport to the Capitol via an unlikely route: the Dulles toll road to the beltway to the George Washington Parkway, then finally over the Memorial Bridge. Unless I-66 was closed, the limo driver would not have taken the beltway.
• The book says the trip from the airport took a half hour. Not by taking the GW Parkway to the Memorial Bridge it doesn't.
• When Langdon's limo crosses the Potomac, Langdon looks to left of the Lincoln Memorial to see the Jefferson Memorial. Didn't Brown check a map? Or did his researcher mistake the Kennedy Center for the Jefferson? The Jefferson is way over to the right.
• Langdon enters the Capitol Visitor Center on a Sunday and sees tour groups inside the Rotunda. The visitor center is closed on Sundays. There are no public tours.
• Langdon crosses the street from Freedom Plaza and enters the Metro system to get away from the bad guys. The closest Metro station to Freedom Plaza is a couple of blocks away, not across the street.
• When the bad guys try to arrest Langdon as the Metro train pulls into the station, the train conductor is driving from the third car. Metrorail conductors always drive from the first car.
• The metro conductor exits the car without opening the doors. I guess he could have squeezed out the side window, but I think Brown would have included that contortionist trick in the narrative.

Those are a few of the errors a D.C. resident, regular visitor or observant tourist would notice. Since I mentioned a few of the book's D.C.-centric errors, to his credit, Brown does have Langdon notice the hum of the limo's wheels change as he approaches the Memorial Bridge, a sign that Brown knows the road is cobblestone between the Parkway exit and the roundabout approaching the bridge.

Since Brown's previous two books were so much better, I have to ask, What happened? That's why I had to conclude from reading The Lost Symbol that Brown must have been kidnapped by some group intent on rehabilitating the public's view of the Masons after Brown's previous books made these types of secret societies look evil. The real lost symbol of the book is hidden in plain sight. The words on the page, those everyday alphabetic symbols, are Dan Brown's way of crying out to the reader: "Can't you tell from this stilted writing and my obvious mistakes of D.C. geography that any tourist would pick up on that I've been kidnapped and forced to write this? Help me!"

If indeed Dan Brown has been seen in public since the book's publication in September, and he isn't a prisoner of the Masons, the only other reasons I can see for this book being so bad after two previous entertaining novels are:

• The Lost Symbol was a contractual obligation book. Maybe the book was motivated by Doubleday reminding Brown of the $5 million advance and the promise of another $10 million upon delivery of the manuscript.
• This book reflects Dan Brown's actual writing ability, and he got in a major tiff with his editor. The Lost Symbol is the editor's revenge.

Overall, if you still feel compelled to read this book, do like I did and buy the ebook version. At least no tree would have been required to share your suffering. My plea to the Masons: Free Dan Brown before he writes another book.
Saturday December 05, 2009 Permalink Comments [0] For the past few months, tech publisher Manning Publications has impressed me with its marketing push by offering quick-strike discounts on print and ebooks. Until Manning's recent marketing and discounts, I was buying a Manning book maybe once a year, and I almost never bought it directly from the publisher. Instead, I'd usually check sites like BestBookBuys to find who had the title I was looking for at the best price. But with its steep short-term discount offers, and my newfound fondness for ebooks, I have purchased Manning books in recent months on Groovy, Grails, Spring and Ext JS, almost always buying the ebook version for $10 to $15 -- a great price for a tech book.

As part of its marketing push, Manning offers daily and weekly discount codes on its website and Twitter feed. Discounts are often 50% or more from its regular price. Tuesday, for example, the Ext JS In Action ebook for which I paid about $15 a few weeks ago (on discount from $27.50) was on sale for $10. (The book, not yet in print by Jesus Garcia, is a great introduction and explanation on how to use the Ext JS 3.0 component library and the only book I found available at the time covering version 3.0.)

In addition to the book discounts, following Manning's marketing message won me an additional $300. In one of Manning's emails in August, I learned that Manning was holding a monthlong technology quiz in September. Manning posted a question daily on a technology topic related to one of its books, with a $300 grand prize to the contestant who could answer the most questions correctly. The tech quiz was great marketing because it brought me and hundreds of others to the Manning website daily. As a quiz incentive, Manning gave away two ebooks every day to two contestants and offered a daily discount on one or more of its books. After answering 30 technical questions, on topics as diverse as features of ActiveMQ, Clojure and Silverlight, I'm proud to say I walked away as the grand prize winner. The competition was stiff. Manning said it had 1,500 contestants. Toward the end of September, there were still about a dozen people with perfect scores with just days left in the contest. After the final question, only two contestants remained with perfects scores, me and Belgian developer Renaud Florquin. I was lucky to be randomly selected as the grand prize winner. (Thanks again, Manning.)

In addition to improving its marketing and pricing, Manning also has impressed me recently by expanding its ebook file formats. Previously, Manning offered its ebooks only in PDF format. Earlier this month, Manning announced it will begin offering its books in the mobi and EPUB file formats. That's great for me because I like reading books in the mobi format on my BlackBerry using the free Mobipocket reader. Ebooks have won me over from the paper version of tech books because of their searchability, the ability to cut and paste code, and their ultra portability by being on my phone and laptop when I visit customer offices. The mobi format is also supported by the Kindle, while the EPUB format is popular with devices like Sony Reader, the nook and the iPhone.

Keep it up, Manning. If you keep offering good technology books at great prices in flexible formats, I will continue to be a regular customer.
Wednesday November 25, 2009 Permalink Comments [0] Technical pride prompted me to write my first Griffon application Tuesday. Griffon is a Groovy-based framework to write Java desktop applications. Groovy takes some of the sting out of writing Java Swing applications and Griffon relieves more of the burden. My pride came into the picture when Manning Publications released its daily Pop Quiz yesterday asking what technique one would use to process the shutdown of a Griffon application running on OS X. Manning posts a new question each day of September, and as of today, I'm running a perfect score. I couldn't let a little question about Griffon stop me. However, since Griffon is so new (its stable release is 0.1.2) and developers are only now starting to play with it, googling around for a simple answer didn't turn up much.

After failing to find sample Griffon code that described the application shutdown process (especially with the question's wrinkle of using OS X), I figured I'd write a simple Griffon desktop application and give the technology a spin. In the category of famous last words, "How hard could it be?" Turns out, thankfully, not that hard.

After downloading the Griffon 0.2-BETA zip file, setting my GRIFFON_HOME environment variable to point to the folder where I unzipped the files, and adding the $GRIFFON_HOME/bin directory to my PATH for convenience, I was ready to create my first Griffon application. I followed the instructions on the Griffon Quick Start page and ran the command:

griffon create-app

and typed in my project name (quiz) to create all the files needed for a basic application. The create-app command generates the application scaffolding along the lines of other modern frameworks like Rails, Grails, App Fuse and even Maven.

Once the create-app command created the skeletal the application files, I followed the sample code on the Griffon Quick Start page to augment the files with code to create a simple desktop application. The application provides a window that lets you type in and execute code in the Groovy shell. Griffon structures its files around the Model-View-Controller pattern, creating subdirectories for "models", "views" and "controllers". Here are the directories in the project's "griffon-app" folder:

$ ls griffon-app
conf/  controllers/  i18n/  lifecycle/  models/  resources/  views/

Figure 1 shows the resulting application in action, which you can build and run using the command griffon run-app. I typed the two Groovy statements into the window and clicked the Execute button. One of my first tweaks to the sample application code was to put in place what I learned during my googling around for an answer. I followed the advice of Josh Reed, one of Griffon's six committers. Josh, who uses Griffon in his day job, wrote a blog post this month about how to intercept window closing events that proved quite helpful. I edited the file griffon-app/views/QuizView.groovy to define application properties for defaultCloseOperation and windowClosing so the top of my QuizView.groovy now looked like this:

QuizView.groovy:

import javax.swing.WindowConstants

application(
   title:'quiz',
   pack:true,
   locationByPlatform:true,
   iconImage: imageIcon('/griffon-icon-48x48.png').image,
   iconImages: [imageIcon('/griffon-icon-48x48.png').image,
                imageIcon('/griffon-icon-32x32.png').image,
                imageIcon('/griffon-icon-16x16.png').image],
   defaultCloseOperation: WindowConstants.DO_NOTHING_ON_CLOSE, // ADDED PROPERTY HERE
   windowClosing: { evt ->                                     // AND HERE
       println "QuizView.groovy: windowClosing event called!"
       System.out.flush()
       app.shutdown()
   }

In addition to the println statement to tell me my shutdown hook was invoked, I needed to add the call to app.shutdown() since I was now telling Java not to end the application when its main window was closed by setting the defaultCloseOperation property to the DO_NOTHING_ON_CLOSE. I followed Josh's tip on editing the griffon-app/conf/Application.groovy file to set the autoShutdown property to false. This flag is needed so my window-closing event code would be run instead of the default auto-shutdown behavior. (Thanks for the tip, Josh.)

Application.groovy:

application {
    title='Quiz'
    startupGroups = ['quiz']

    // Should Griffon exit when no Griffon created frames are showing?
    autoShutdown = true

    // If you want some non-standard application class, apply it here
    //frameClass = 'javax.swing.JFrame'
}
mvcGroups {
    // MVC Group for ""
    'quiz' {
        model = 'QuizModel'
        controller = 'QuizController'
        view = 'QuizView'
    }

}

Now when I run the application and close the window, the console shows:

$ griffon run-app
Welcome to Griffon 0.2-BETA - http://griffon.codehaus.org/
Licensed under Apache Standard License 2.0
Griffon home is set to: /home/tom/Projects/Griffon/griffon-0.2-BETA

Base Directory: /home/tom/Projects/ManningQuiz/quiz
Running script /home/tom/Projects/Griffon/griffon-0.2-BETA/scripts/RunApp.groovy
Environment set to development
Warning, target causing name overwriting of name default
  [groovyc] Compiling 3 source files to /home/tom/.griffon/0.2-BETA/projects/quiz/classes
QuizView.groovy: My windowClosing event called!

That's one way to add a shutdown hook to a Griffon application, by adding a listener to fire when the application's window closes. However, this discovery didn't answer the Manning quiz. None of the available answers showed this technique.

More searching around the web pointed me to the compellingly sounding griffon-app/lifecycle files created by the create-app scaffolding command. One of these auto-generated files is called Shutdown.groovy. It couldn't get more obvious or more easy than that, I suppose. The contents of this file show helpful comments describing how to add shutdown hooks to your application.

griffon-app/lifecycle/Shutdown.groovy

/*
 * This script is executed inside the EDT, so be sure to
 * call long running code in another thread.
 *
 * You have the following options
 * - SwingBuilder.doOutside { // your code  }
 * - Thread.start { // your code }
 * - SwingXBuilder.withWorker( start: true ) {
 *      onInit { // initialization (optional, runs in current thread) }
 *      work { // your code }
 *      onDone { // finish (runs inside EDT) }
 *   }
 *
 * You have the following options to run code again inside EDT
 * - SwingBuilder.doLater { // your code }
 * - SwingBuilder.edt { // your code }
 * - SwingUtilities.invokeLater { // your code }
 */

I thought I'd edit this file and add some custom shutdown code. I added this to the end of the above file:

import groovy.swing.SwingBuilder

def swing = new SwingBuilder()
swing.doOutside {
    println "doOutside called in the Shutdown.groovy lifecycle"
}

With these few extra lines of code, running the application (griffon run-app) and closing the window resulted in these lines on the console. (I eliminated the Griffon startup information.):

QuizView.groovy: My windowClosing event called!
doOutside called in the Shutdown.groovy lifecycle

Interesting to see that the application's window-closing event occurred before the application shutdown event. That makes perfect sense.

But Wait, There's More

Unfortunately, this solution didn't seem to satisfy any of the available options in the Manning quiz. (Except for the tantalizingly tempting "None of the above" fourth option.) I didn't want to give up yet in finding a solution. The available quiz answers that seemed worthy of looking into talked about defining event handlers for the "ShutdownStart" event or the "ShutdownEnd" event. According to the Release Notes for version 0.1, runtime events may be added to the controller class. The notes list all events that may fired by the application during its life cycle:

• BootstrapEnd
• StartupStart
• StartupEnd
• ReadyStart
• ReadyEnd
• ShutdownStart

Since no event for ShutdownEnd is in the list, I figured the Manning quiz answer was probably defining an event handler for ShutdownStart. Since I wanted to be sure, I added a tiny event handler, with code borrowed from the sample in the Release Notes, to my controller class in griffon-app/controllers/QuizController.groovy:

    def onShutdownStart = { app ->
        println "Controller onShutdownDown says ${app.config.application.title} is shutting down."
    }

I re-ran the application and shut it down, and the console now showed:

QuizView.groovy: My windowClosing event called!
Controller onShutdownDown says Quiz is shutting down.
doOutside called in the Shutdown.groovy lifecycle

The lines show all of my shutdown code successfully got called. So here's what I learned in my foray into Griffon:

• There are at least THREE ways to handle events that fire when an application is shut down
• Writing event listeners in Groovy/Griffon is a lot easier than Swing
• There is no requirement to register the runtime event with the source of the event
• Griffon (and Groovy) do their share to ease programming by defining conventions over requiring configuration

The nice bonus in playing with Griffon was the scaffolding-building create-app command got me started and running quickly. I was able to create a Griffon desktop Java application, add three ways to capture runtime events, compile and test the application several times -- all in less time it took me to write this blog documenting these facts. I don't know whether Griffon can win the hearts of developers who want to write desktop applications, but I sure think it can win the hearts of Java developers who would otherwise be stuck writing a straight Swing application. If you're a Swing developer, definitely check out what Groovy and now Griffon have to offer in ease of development and simpler code writing. I look forward to seeing what Griffon becomes once it reaches the 1.0 milestone.


Wednesday September 23, 2009 Permalink Comments [0] The bloom of the Japanese cherry trees in Washington, D.C. is at its peak, so Renee and I went over to the Tidal Basin at dawn this morning to watch the sun come up behind the Jefferson Memorial. We got some nice photos.

I was surprised at how popular the Tidal Basin was at 6 a.m. During the Cherry Blossom Festival, D.C. has turned Ohio Drive SW into a one-way street going north, with parking available on the west side along the Potomac. By sunrise at 6:47 a.m., there almost wasn't a parking spot left. There was a plethora of photographers lined up along the Tidal Basin walking path, all prepared with their tripods and telephotos. Renee set up her tripod near one tree, while I roamed around shooting hand-held, which made for a lot of blurry photos in the pre-dawn twilight. I shot at ISO 800 initially, then switched to ISO 200 in the hopes that it would let me blow-up the photos extra-large without as much graininess. Still, I was shooting at 1/30 of a second and slower for a lot of the early photos. That's what I like about shooting digital: I deleted about 60% of my photos with no thought to all the "film" I wasted.

Visiting the Tidal Basin before dawn to enjoy the cherry blossoms was a good idea. The area around the basin was packed a couple of hours later, with the usual gridlock traffic on Independence Avenue SW and the Memorial Bridge entering the district from Virginia. If you're in D.C. and plan to visit the cherry blossoms on Sunday, definitely arrive early. I saw a lot of cars idling along the Memorial Bridge, slowly crawling toward D.C. -- and probably not finding a close space to park.

I uploaded several of my photos from today and from last weekend to Picasa Web Albums.

Some cherry tree facts: There are 1,678 cherry trees around the Tidal Basin, with more surrounding neighboring roads and parks. Trees originally were planted around the Tidal Basin in 1912 as a gift of friendship from the people of Japan. About 400 of the present trees were propagated from the original 1912 trees. The health of the trees often suffers as a result of their beauty. The crowds who visit the area often tromp around the base of the trees, compacting the soil. The drainage in the area could use some improvement, too, as you'll notice when you have to walk around some of the flooded areas along the Tidal Basin path -- forcing you to compact the soil even more around those trees. New trees need to be planted regularly to replace the suffering ones, which is probably one reason none of the trees you see there are ancient.

If you are interested in planting a Yoshino cherry tree at your home like the ones along the Tidal Basin, the non-profit American Forests sells them online. My "green" plug for the planet.


Saturday April 04, 2009 Permalink Comments [0] Alfresco Software said Tuesday it will not release certain new enterprise features of the Alfresco content management products, such as high-availability clustering, as open source as a way to persuade freeloading companies to pay up. John Newton, CTO and co-founder of Alfresco Software Inc., posted notice of this new business strategy in a blog entry that effectively says Fortune 50 users of the free version of Alfresco are cheapskates. He reassures everyone in his blog that core components of Alfresco will remain open source and free. Alfresco thus joins other commercial open source projects, such as MySQL, in bifurcating their source code into a core version licensed as open source, and a version with features important to large businesses (the ones with money) available for a fee.

In a blog last August, Andrew Lampitt called this division an "open-core licensing" model. This division is now officially reflected in Alfresco Software's release Tuesday of Alfresco Enterprise 3.1.

Newton implied in his blog that Alfresco Software was pushed to close-source enterprise features of Alfresco for financial reasons. Many "world-class companies" with "household brands" are using Alfresco's free and open source Labs version, he wrote, and not paying the annual Enterprise subscription. Enterprise subscriptions are a source of revenue for Alfresco Software. Subscribing customers receive a more stable "Enterprise Edition" of the Alfresco content management suite, dedicated support, and optional training and consulting. By releasing enterprise features of Alfresco only to paying customers, Newton said, he hopes Alfresco's largest users will see the benefit of paying Alfresco an annual subscription rather than paying their own developers to figure out how to deploy Alfresco in a high-availability environment or writing their own management tools.

If indeed Alfresco Software won't be able to survive (or at least thrive) without finding a more sustainable revenue source, this move sounds like a good strategy. It will allow Alfresco to continue to improve its already excellent enterprise content management system while allowing smaller companies to use Alfresco's core products for free. If, however, this bifurcated source code strategy is merely a way to return higher profits to Alfresco's founders and funders, the change might negatively impact how Alfresco Software is perceived by developers writing useful extensions and integrations and releasing them as free, open source. Open source developers release their code for the community's benefit as a whole, but might hesitate to do so when a corporation profits indirectly from their work.

There is nothing wrong with a corporation out to make money, and adopting the "open core" model might be the best move for Alfresco's future -- as a product and as a company. I don't know whether much or any of the Alfresco "core" code base was written by non-Alfresco employees. If not, the risk of Alfresco losing contributions from external open source developers is small. Other "community" contributions, like free technical support offered by fellow users on the Alfresco forums, likely will continue unaffected by the licensing change because much of that free exchange of information is among users of the free Labs version.

From what the privately held Alfresco Software says publicly, it isn't hurting for money. Alfresco employees I spoke with last year say the company is profitable. Matt Asay, Alfresco's vice president of business development, said in a CMS Wire story Tuesday by Barb Mosher that sales have been increasing recently by more than 27% from the quarter before. On Monday, Alfresco Software released limited financial information for its fiscal year ended Feb. 28. The news release says Alfresco Software Inc. closed the 2008 fiscal year with a 103% year-over-year revenue growth and a 92% increase in revenue from the fourth quarter of 2008 compared to the same quarter in 2007. It also added 270 paying customers during the 2008 fiscal year.

Newton wrote in his blog that Alfresco Software looked at options other than close-sourcing enterprise features. Alfresco considered "crippling" the open source version, he said, or letting the open source branch become so cutting-edge that it fell "into a destabilized state." But going that route "would make it difficult for certain governments to use our product," he said, and could cause the open source community to create competing forks to fix the crippleware.

Newton said Alfresco's new software model will adhere to these six principals:

1. Alfresco extensions to create high-availability, clustered systems and provide better monitoring and and administration will be developed as closed source.
2. The core system and interfaces will remain 100% open source.
3. Bugs fixed for Enterprise customers will be folded into the next open source Labs release.
4. Code that Alfresco Software writes for paying customers to integrate Alfresco with proprietary systems will remain closed source.
5. Integrations to "ubiquitous" proprietary systems, like SharePoint, will remain open source.
6. Alfresco will continue to support paying customers to the levels of their SLAs.

Wednesday April 01, 2009 Permalink Comments [3]