Juixe Techknow

I think the price range of laptops have made them disposable. Recently, I had the choice of sending an HP laptop repaired at $400 or just buy a new one for about the same price. There are many laptop models, from many vendors, at the sub-$500 dollar range. So, what would you do? Deal with customer support, send in your laptop, wait a week to have the display fixed or just go in to Best Buy and get a new one? The choice is clear, buy a new one.

This wasn’t so clear a few months ago, when I had a similar decision to make when four year old Apple laptop had problems recharging the battery. As it was out of warranty, I paid $300 dollars to send it in to have the power unit repaired and had he laptop refurbished to original manufacturing specifications. Two months later, the monitor was crapping out!

97 Things Every Software Architect Should Know is a collection of essays written by a community of software architects. Each essay is about a page or two and drops some soft skill knowledge an architect needs to master. I already made reference of this book in 101 Things Every Software Architect Should Know. In this post I wanted to highlight some of the favorite quotes from the book, some real pearls of software architecture. The reason why these quotes mean something to me is because I have found them to be true through my experience. I hope they right true with you too.

“Fast” is not a requirement. Neither is “responsive.” Nor “extensible.” The primary reason why not is that you have no object way to tell if they’re met.
– Keith Braithwaite

Simplicity through experience rather than generality through guesswork.
– Kevlin Henney

Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.
– Dave Quick

A little training goes a long way toward ensuring that everyone is on the same page when it comes to reuse.
– Jeremy Meyer

Software architects love the challenge of big, complicated projects. The potential rewards can even tempt people to artificially expand a project’s scope to increase its apparent importance. Expanding scope is the enemy of success because the probability of failure grows faster than expected. Doubling a project’s scope often increases its probability of failure by an order of magnitude.
– Dave Quick

Large projects’ requirements change many times before they’re completed. Important requirements usually remain important as the business changes, while others change or even evaporate. Prioritization lets you deliver the most important requirements first.
– Dave Quick

Reducing the project scope often results in a simpler architecture, and is one of the most effective strategies an architect can apply to improve the odds of success.
– Dave Quick

There is no appeals court for required field or mandatory workflow. … Required fields seem innocuous, but they are always an imposition of your will on users. They force users to gather more information before starting their jobs.
– Michael Nygard

From an architects’ point of view, the hard part is to find the natural places to locate boundaries and define the appropriate interfaces needed to build a working system.
– Einar Landre

Things are usually easier said than done, and software architects are notoriously good at coming up with things to say.
– Timothy High

When you try to guess at future requirements, 50% of the time you’re wrong and 49% of the time you’re very, very wrong.
– Chad LaVigne

Screening for specific technical knowledge is definitely part of the process but turning an interview into a certification test will not guarantee success. You are searching for developers with problem-solving skills and passion. The tools you use are sure to change; yoiu need people who are good at attacking problems regardless of the technologies involved.
– Chad LaVigne

If you accept this fact – that the choices you make today will most certainly be wrong in the future – then it relieves you of the burden of trying to future-proof your architectures.
– Richard Monson-Haefel

Choosing a good technology for right now is hard enough; choosing one that will be relevant in the future is futile. Look at what your business needs now. Look at what the technology market offers now. Choose the best solution that meets your needs now, because anything else will not only be wrong choice tomorrow, but the wrong choice today.
– Richard Monson-Haefel

Griffon is the rapid desktop development equivalent to Grails or Ruby on Rails. Griffon is a desktop application framework written in Groovy, a scripting language that runs on the Java Virtual Machine. Just like Grails or Rails, Griffon is very DRY and opinionated, comes with generators, and separates your models from your controllers from your views.

Griffon is a new project with the most recent release clocking in at version 0.1.1. Even though Griffon is new, it is based mainstay libraries such as Groovy, Swing Builders, and SwingX. Even with a version number of 0.1.1, Griffon provides enough features to develop functional and complex UIs. To help getting started with Griffon, here is a collection of Griffon tutorials and resources that I have found insightful and helpful.

• Griffon
• Griffon Quick Start
• Griffon Docs
• Griffon in Action Source Code
• Grinding Griffon: The Setup
• Grinding Griffon: The Hit
• Styling a Griffon application
• Riding The Griffon
• Griffon In Front Grails In Back
• Griffon Pre-Alpha NetBeans Plugin Demoed at the NetBeans Booth
• GriffonCast Simple Video Player
• SwingX busy label demo in Griffon and Groovy
• Griffon Applications
• My First Griffon App
• Getting Started with Swing MVC Development on Griffon
• Flying with Griffon

I’ve had my Kindle for about six months and I’ve already purchased 18 books! And before you ask, NO! I haven’t even read half of them yet! At any one time I am in the middle of two or three books. I recently finished 97 Things Every Software Architect Should Know and thought that I should list my favorite books on my Kindle. These books are classics by any standard and belong on the any developer’s bookshelf.

• 97 Things Every Software Architect Should Know
• Hackers and Painters Kindle
• Founders at Work: Stories of Startups’ Early Days
• Practical API Design: Confessions of a Java Framework Architect
• Processing: Creative Coding and Computational Art

If Griffon delivers on the promise of rapid desktop development, the desktop will see a renewed focus. Griffon is relatively speaking a new project and currently Griffon needs a lot of documentation, tutorials, and use cases which means this is a perfect opportunity for Groovyist and enthusiasts to participate in the community.

Griffon views are created using UI builders. Groovy has a nice set of meta-programming features and the Groovy builder pattern to commonly used to create Domain Specific Languages. The UI builder used by Griffon is generic UberBuilder. Griffon 0.1.1 also uses SwingXBuilder and can theoretically work with other builders such as JideBuilder and FlamingoBuilder.

Lets enhance the default view created in the previous post with something a bit more interesting and interactive. Lets create a view with two buttons, and when the buttons are pressed a corresponding action should be executed. To get started, lets enhance the view to something like the following.

application(title:'gouda',
  pack:true,
  locationByPlatform:true,
) {
    panel(border:emptyBorder(6)) {
        borderLayout()
        hbox(constraints:SOUTH) {
            button("Ok", actionPerformed:controller.&okAction)
            button("Cancel", actionPerformed:controller.&cancelAction)
        }
    }
}

Griffon views are declarative. Notice how you add components to containers. You don’t explicitly add the button to horizontal box layout, but you just declare the the button method to create and add a button.

To declare a button we pass a string used for the label of the button and an action event handler to process the button pressed action. The action event handler is defined in the controller for your MVC group. Open the correct controller under the griffon-app\controllers directory. Adding the doAction and cancelAction methods to support the button press events, the controller looks like the following.

import java.awt.event.ActionEvent</pre>
class GoudaController {
    // these will be injected by Griffon
    def model
    def view

    void mvcGroupInit(Map args) {
        // this method is called after model and view are injected
    }

    def okAction(ActionEvent evt = null) {
        println "Okay Button Pushed!!"
    }

    def cancelAction(ActionEvent evt = null) {
        println "Cancel Button Pushed!!"
    }
}

Griffon seems very promising, it is lacking a strong set of documentation and tutorials but it has a strong legion of evangelists and hackers working on that. That said, I am sure this is enough to get you started and get you going with Griffon.

Griffon is the rapid desktop development equivalent to Grails or Ruby on Rails. Griffon is a desktop application framework written in Groovy, a scripting language that runs on the Java Virtual Machine. Just like Grails or Rails, Griffon is very DRY and opinionated, comes with generators, and separates your models from your controllers from your views.

To install Griffon just follow their instructions. Installing Griffon is very simple, basically just unzip the download, create a GRIFFON_HOME environment variable, and add the Griffon bin to your path. Once you have Giffon in your path, you can just type griffon from the command prompt and you should get some output much like this.

Welcome to Griffon 0.1.1 - http://griffon.codehaus.org/
Licensed under Apache Standard License 2.0
Griffon home is set to: /OSDEV/griffon-0.1.1

No script name specified. Use 'griffon help' for more info or 'griffon interactive' to enter interactive mode

To create a new Griffon project, execute the following command from the command line.

giffon crate-app

You will be asked to enter a application name. You will be asked to enter a MVC Group name too. The name given for the MVC Group will be used to create a Griffon model, view, controller, and test.

Creating a new Griffon application creates a directory structure not to dissimilar from those created for a Grails or Rails project. In the case of Griffon, your application’s root directory will have a griffon-app directory, under which you have a controllers, models, and views directory.

New Griffon Project

Even though we have not added any of our own code, the Griffon application just created is fully functional and can be started. To run the application execute the following from the command line.

griffon run-app

If you named your application different that your default MVC group, you will get an error running the app. To start up correctly, Griffon needs a MVC group to run and by default the MVC group name is that of the application, but this can be different if you enter a different name for the MVC Group. Whatever the case might be, you can edit Application.groovy under griffon-app\conf directory to startup the correct MVC group.

If everything is setup correctly, you should get a small window that reads ‘Content Goes Here!’ when you run the Griffon application. To modify the desktop application, edit the view file for your default MVC group which is located under the griffon-app\views directory.

NetBeans has decent support for Groovy, and just about every other programming langauge. There is a Griffon plugin for Netbeans 6.7. Unfortunately as of this writing, I was not able use the Grifon plugin to crate a new Griffon project… But once you have Griffon project, you can open the project and edit the Groovy views, controllers, and models in NetBeans.