-
Get a monthly update on best practices for delivering successful software.

Installing plugins in Griffon is pretty easy. You just type something like
% griffon install-plugin [plugin-name]
in your application's base directory and it does all the rest. The actual plugin stuff gets put in ~/.griffon/<version>/projects/<appname>/plugins. But what if you want to develop a plugin and don't want to have to reinstall with every little code and test change?
Well, Josh Reed has a nice blog post on exactly how to do that. I won't recap it here, just say that essentially you nuke the installed stuff under the .griffon directory and make a symbolic link to your plugin development directory.
There are just two things that are a little confusing about it.
griffon list-plugins?Well, the answer to the first question is simple. Simply package your plugin by going going to it's base directory and typing
% griffon package-plugin
to generate a zip file. You can then navigate to your application's base directory and type
% griffon install-plugin [path to plugin]/plugin-name-0.1.zip
all assuming that your plugin is version 0.1. After that you are good to go with Josh's original instructions.
As for the second question, I'm still spelunking through the gant scripts to figure that one out.
Topics: Griffon, Griffon Plugin Development, Groovy
![]()

I finally have some small amount of spare time to start working on my Griffon PureMVC plugin. One of the first things to think about is where to we make the marriage between the two frameworks?
Griffon has Models, Views and Controllers, as does PureMVC (actually, it has Commands, Mediators and Proxies, which essentially perform the tasks under MVC). My initial thought is that Griffon's MVC triads really perform the tasks of a complex view, and PureMVC wires these complex views together via it's message bus. So, my thinking is to wrap each MVC triad into a Mediator, with the Mediator mostly talking to the Griffon controller and perhaps the Griffon model.
I'll make some more posts here as my thinking and experimenting evolves.
We have a few simple principles when it comes to software guarantees: either we have developed the software according to our rigorous testing standards or the third party code we being asked to support meets some basic criterea:
That may seem pretty extreme, but if we're promising to fix bugs on our dime, we can't have it any other way. Doing without these basic criteria is like guaranteeing you can drive from New York to Los Angeles in 30 hours, keeping under the speed limit without a speedometer and without being told what the speed limit is. Spelling it out a little more, if you can't tell me what your application should do, how do I know if it is "broken?" If I can't run and inspect unit tests to tell if individual classes and methods are doing the right thing, how can I quickly tell if my changes have broken the system? Continue reading »
Topics: agile, Agile Development, software develoment, waterfall
On a recent project after months and months and hundreds of files worth of work, we were asked to provide documentation for the code. This request could have gone one of two ways depending upon how well we adhered to some basic documentation rules.
The C# compiler itself is setup to extract documentation which can then be piped through one of a number of documentation generation apps. My preference is a new(ish) project called SandCastle from Microsoft, which aims to provide much of the featureset that NDoc once did. Unfortunately this application provides no GUI. A fine gentleman named Eric Woodruff stepped in to wrap this application in an easy to use GUI for us aptly named Sandcastle Help File Builder. Through the use of good comments written WHILE we wrote the code, we were able to pop out some documentation for every bit of code we wrote in a matter of minutes. Add to this the nice information we get when using our code via intellisense, and it simply doesn't make sense not to strictly enforce documentation standards on your project.
I often see code written with little or no attention paid to comments. Sometimes the comments are fairly haphazard and appear to follow no standards whatsoever. By following documentation standards, you too can auto generate documentation instead of wasting hours or days going back through and trying to remember what your code does. Continue reading »
Topics: c# documentation ndoc sandcastle

I have a short list of things that I don't like about GWT. They are:
So, what does 2.0 promise? To resolve these four things, and a few more. Check out the GWT 2.0 Milestone 1 release announcement:
In-Browser Development Mode: Prior to 2.0, GWT hosted mode provided a special-purpose "hosted browser" to debug your GWT code. In 2.0, the web page being debugged is viewed within a regular-old browser. Development mode is supported through the use of a native-code plugin for each browser. In other words, you can use development mode directly from Safari, Firefox, IE, and Chrome.
Code Splitting: Developer-guided code splitting allows you to chunk your GWT code into multiple fragments for faster startup. Imagine having to download a whole movie before being able to watch it. Well, that's what you have to do with most Ajax apps these days -- download the whole thing before using it. With code splitting, you can arrange
to load just the minimum script needed to get the application running and the user interacting, while the rest of the app is downloaded as needed.Declarative User Interface: GWT's UiBinder now allows you to create user interfaces mostly declaratively. Previously, widgets had to be created and assembled programmatically, requiring lots of code. Now, you can use XML to declare your UI, making the code more readable, easier to maintain, and faster to develop. The Mail sample has been updated to use the new declarative UI.
Bundling of resources (ClientBundle): GWT has shipped with ImageBundles since GWT v1.4, giving developers automatic spriting of images. ClientBundle generalizes this technique, bringing the power of combining and optimizing resources into one download to things like text files, CSS, and XML. This means fewer network round trips, which in turn can decrease application latency -- especially on mobile applications.
Using HtmlUnit for running GWT tests: GWT 2.0 no longer uses SWT or the old mozilla code (on linux) to run GWT tests. Instead, it uses HtmlUnit as the built-in browser. HtmlUnit is 100% Java. This means there is a single GWT distribution for linux, mac, and windows, and debugging GWT Tests in development mode can be done entirely in a Java debugger.
Looks like Xmas has come early. I've been working with the browser plugin for a little bit and it is just a joy to use. One down side, of course, is that Intellij 9.0 will be out of date re: GWT the day it is released.
Topics: GWT 2.0

Time to answer some questions about Griffon:
There is even an installer plugin that allows you to package your app as an izPack (platform independent), RPM (Linux) or DMG (Mac) distribution. It will also create app (Mac) or exe (via JSmooth) launchers for Mac and Windows. Pretty sweet.

Design patterns. I think they are the one of the most intriguing areas of object oriented application design and development. There are so many out there that can puzzle you each and every time you try to take a crack at them (I can name a few of them that I still can't figure how they are to be used or implemented). But a thing that most programmers would agree is if used wisely and appropriately, these design patterns can provide really powerful benefits that can enhance one's programming experience and also the software that is being built. There are several patterns I have used/implemented in my projects that I think are awesome. I ll touch upon how I used some of them and why every Object oriented programmer needs to master them.
Topics: .NET, Gang of Four, OOP
We've been building a lot of mapping/GIS data visualization applications over the last few months, mostly using flex with various back end services (ArcGIS, google and yahoo maps, open source mapping frameworks.) One of the more fun little projects was putting together this flex widget for displaying maps and graphical data together on a timeline. It's meant to be distributable so that anyone with a blog can display it. We put it together using presidential election data and national debt, not because we thought the correlation was particularly significant, but because the data was available going back a long time. The widget is pretty flexible; it can go against a local data source or a web service, and we can easily modify it to show different kinds of data. We'll be coming out with a few more of these over the next few months, hopefully with some more 3D maps, drill down on geographic level, as well as more charting and other visualizations. If you'd like to use this one, or have ideas for other data sets and visualizations you'd like to see, let us know.
Topics: blog widgets, data visualization, elections, Flex, flex widgets, graphing, mapping, Widgets
As part of our ongoing development in the air traffic logistics and weather forecasting space, we developed a three-dimensional prototype for tracking flight path data and meteorological readings using Flex, Papervision 3D and PureMVC.
The framework is configured for using multiple APIs for mapping services from Yahoo and Google, as well as receiving live data streams from different sources. A number of custom controls were developed and integrated into the application, including altitude and rotation controls. The application can be re-used for any three dimensional map-based visualization such as weather patterns, demographic, political or economic data.
Topics: 3d mapping, Adobe AIR, AIR, data visualization, mapping, papervision3d

In the past, one of the nice things about web application development versus desktop development has been the proliferation of application development frameworks. Where desktop development pretty much gave you a set of GUI components and a few concepts like event driven programming and MVC, web frameworks, in particular the more recent ones such as Rails and Grails, gave you an application architecture into which you could implement your domain specific logic.
Lots of benefits accrued from this predefined structure, not the least of which was the ability to quickly understand the application based on a shared understanding of how applications using this framework were put together. In my experience of looking at desktop and web applications over the years, the web applications were better and more consistently designed than their desktop counterparts. Similar tries at desktop frameworks just never seemed to gain any traction (recall Scope, an app framework based on the HMVC pattern that died of neglect).
Now along comes Griffon, a desktop application framework modeled on (and sharing an architecture) with Grails. Griffon has a very similar controller, view and model breakdown as Grails, and support for plugins. I'd like to see similar frameworks for .NET and Cocoa (yes, yes, Cocoa has some of it's own framework goodness, but could use some higher level application abstractions to make application development more consistent).