No Fluff Just Stuff

Compass 2.0.2 Released

Shay Banon — Tue, 19 Aug 2008 16:00:01 CDT

Compass version 2.0.2 released. This is a bug fix released for Compass 2.0 and is recommended for all Compass users. Full change log can be found here.

How Buildings Learn

Michael Nygard — Tue, 19 Aug 2008 13:00:01 CDT

Stewart Brand's famous book How Buildings Learn has been on my reading queue for a while, possibly a few years. Now that I've begun reading it, I wish I had gotten it sooner. Listen to this:

The finished-looking model and visually obsessive renderings dominate the let's-do-it meeting, so that shallow guesses are frozen as deep decisions. All the design intelligence gets forced to the earliest part of the building process, when everyone knows the least about what is really needed.

Wow. It's hard to tell what industry he's talking about there. It could easily apply to software development. No wonder Brand is so well-regarded in the Agile community!

Another wonderful parallel is between what Brand calls "Low Road" and "High Road" buildings. A Low Road building is one that is flexible, cheap, and easy to modify. It's hackable. Lofts, garages, old factory floors, warehouses, and so on. Each new owner can gut and modify it without qualms. A building where you can drill holes through the walls, run your own cabling, and rip out every interior wall is a Low Road building.

High Road buildings evolve gradually over time, through persistent care and love. There doesn't necessarily have to be a consistent--or even coherent--vision, but each own does need to feel a strong sense of preservation. High Road buildings become monuments, but they aren't made that way. They just evolve in that direction as each generation adds their own character.

Then there are the buildings that aren't High or Low Road. Too static to be Low Road, but not valued enough to be High Road. Resistant to change, bureaucratic in management. Diffuse responsibility produces static (i.e., dead) buildings. Deliberately setting out to design a work of art, paradoxically, prevents you from creating a living, livable building.

Again, I see some clear parallels to software architecture here. On the one hand, we've got Low Road architecture. Easy to glue together, easy to rip apart. Nobody gets bent out of shape if you blow up a hodge-podge of shoestring batch jobs and quick-and-dirty web apps. CGI scripts written in perl are classic Low Road architecture. It doesn't mean they're bad, but they're probably not going to go a long time without being changed in some massive ways.

High Road architecture would express a conservativism that we don't often see. High Road is not "big" architecture. Rather, High Road means cohesive systems lovingly tended. Emacs strikes me as a good example of High Road architecture. Yes, it's accumulated a lot of bits and oddments over the years, but it's quite conservative in its architecture.

Enterprise SOA projects, to me, seem like dead buildings. They're overspecified and too focused on the moment of rollout. They're the grand facades with leaky roofs. They're the corporate office buildings that get gerrymandered into paralysis. They preach change, but produce stasis.

Does Your Team Have STDs?

Jared Richardson — Tue, 19 Aug 2008 11:00:01 CDT

Last week I was talking with a friend about a common ailment on development teams today. And it seems to be getting worse.

Perhaps you've seen it already in your shop. Once one person catches an STD, it seems to spread quickly.

STD, of course, stands for Shiny Things Development.

Oh cool! Check that out... it's new and cool. Let's include it in the product! Why? Umm... it solves some problem. And didn't I just say it's shiny and new?

How many shops have you met that have insane development infrastructures "just in case" things get crazy? Anytime the shop has a list of tools and libraries where every single one requires a specific version for anything to work, someone there has STD.

What's the problem with STD? It generally indicates a lack of discretion and promiscuous use of technology. Rather than saving yourself for something that actually works, you're chasing down every new product and technology. Sure, it might be fun to try out new stuff

Need Help with BackUpWordPress

Johanna Rothman — Tue, 19 Aug 2008 08:00:01 CDT

I’ve been using BackUpWordPress to backup my blogs. I successfully upgraded Hiring Technical People to a newer version of WP and of BackUpWordPress. I upgraded this blog, Managing Product Development, to the newer version of WP, but now my newer version of BackUpWordPress is not working. I’m pretty sure it’s all about file permissions.

If you have experience with this and insight, please email me, jr at jrothman dot com. I can’t figure out what I’m doing wrong and want to keep backing up! Thanks.

Name Soup

Alex Russell — Mon, 18 Aug 2008 16:00:01 CDT

There still seems to be an amazing amount of FUD going around regarding the Harmony announcement. There is clearly a very different perspective from those who have been sitting inside the WG for the past year (as Kris Zyp and I have been lucky to). Inside the WG, the change seems a welcome way to break a logjam of reasonably held opinions of people who are all acting in good faith. From the outside, it all looks like confusion and game-playing.

One of the things, though, that keeps getting me frustrated as I read the “coverage” is that the names people use are confused. Probably because the names are confusing. Here’s a quick glossary:

ECMAScript 3

Aka: JavaScript, ES3, ECMAScript 262-3, and JScript.

The current JavaScript that every browser implements (more or less). This is the current ratified standard and represents the 3rd edition of the ECMAScript spec. It is very old. Nothing else in this list is (yet) a ratified standard of any sort.

ECMAScript 4

Aka: ES4, “JavaScript 2″.

A new language which was to be mostly backwards compatible but add optional (gradual) typing and class-based inheritance. Based loosely on Adobe’s ActionScript 3. This is the language effort which died as a result of Harmony.

ECMAScript 3.1

Aka: ES3.1. A set of small additions to ES3.

Planning for this edition was started at Microsoft and Yahoo’s behest late last year, causing the split in the working group which has been healed by the Harmony announcement.

ActionScript 3

Aka: AS3

Adobe’s current JavaScript-like language, only with many features lifted from languages like Java which also enforce types and class-based semantics. This was the starting point for much of the work which became known as ES4.

Tamarin

A JIT-ing byte-code virtual machine (VM) which is at the core of the Flash Player and was donated by Adobe to the Mozilla Foundation. This is the VM that runs ActionScript 3 code today but will likely run “real” JavaScript for Mozilla in the future. It is not a full implementation of ES3 or ES4, but instead implements its own byte-code and needs to be wedded to a “front end” (like the ActionScript 3
compiler from Adobe) in order to be usable by programmers.

Tamarin-tracing

A VM which implements the same byte-code language as Tamarin (known as “ABC”) but which is designed for use in mobile devices and other scenarios where code size and VM footprint are important. It implements trace-tree JIT-ing as a way to speed up hot-spots. Also donated to Mozilla by Adobe.

TC39

The name of the ECMA technical committee which is chartered to evolve the JavaScript language.

Harmony

A new code-name for a language which is to come after ES3.1. It will feature many of the things ES4 was trying to accomplish, but may attempt them from different directions and will
focus much more on incremental, step-wise evolution of the language.

JavaScript 2

A now-defunct name. This name was originally given to Waldemar Horwat’s first proposal at a large-scale evolution of the JavaScript language in 1999. That effort did not succeed (although Microsoft implemented some of it in JScript.NET) and subsequent work via the current TC39 charter to build ES4 has sometimes been given the name “JavaScript 2″, but it never really stuck. Not a name that describes any ratified standard or current proposal.

ECMAScript

The formalized name of the JavaScript language. Since Sun Microsystems owns the name JavaScript and has no idea what to do with the trademark (but has been benevolent thus far), the ECMA committee which standardized the language was forced to adopt a different name.

Cloud-Oriented Architecture (COA)

Scott Leberknight — Mon, 18 Aug 2008 13:00:01 CDT

With all the hype this year about cloud computing and things like Amazon EC2/S3 as well as Google App Engine and Bigtable, you can feel it coming. Soon vendors will be peddling COA (Cloud-Oriented Architecture) solutions, probably combining them with their SOA solution and somehow probably getting their ESB solution into the mix as well. This past weekend at the Enterprise Architecture BOF at the Southern Ohio Software Symposium, we had a discussion about cloud computing among other things. Ted Neward even coined the term "Enterprise Service Cloud" and I came up with "Cloud Service Bus," surely the next Big Thing. Any vulture (I mean, venture) capitalists out there want to invest in my new Cloud Service Bus company? I have a pretty brochure ready to go!

The big difference I see with regard to cloud computing is the fact that, unlike your typical ESB/SOA peddling vendors, companies like Amazon and Google already have cloud or cloud-like solutions in place a la Amazon EC2/S3 and , and Google App Engine and Bigtable. Now all of those things just mentioned are not "the cloud" (whatever "the cloud" actually is defined to be), but it doesn't matter because the point is these companies have designed, implemented, and most importantly, run their critical business operations on these platforms. That in and of itself is more important than all the vaporware and marketing hype any other vendor comes up with. Rather than having to get customers to believe that a solution works via marketing and then force it down their IT staff's throats, Google and Amazon are basically saying "Hey why not use stuff that we use and have proven can scale up to handle huge loads and huge amounts of data?"

To me as a developer this is a much more appealing approach for several reasons. First, it means there won't be (or shouldn't need to be) any "golf-course deals" where the vendor sales guys and customer CIOs/CTOs/CEOs meet up and decide on the technology stack independent of any real technical analysis, investigation, or input of the people who will be charged with implementing the vendor stack (and they better do it well else it's their job on the line to boot).

Second, I can base my decision to use a Google or Amazon service based on their actual track record in delivering these services and eating their own dog food, since they are trying to monetize their existing investment in proven highly distributed and scalable infrastructures. Yes, there have been Amazon outages this year and whenever it happens it is big news because it is right there out in the public, as opposed to a company whose IT operations are totally in-house and which isn't going to publicize their downtime statistics. I'd wager on Amazon and Google's availability over probably most other companies. Of course I have no way to prove that last statement, but the mere fact that I can get objective statistics on their services helps in my decision making process and planning.

Last, I can decide how much or how little to outsource to the Amazon or Google infrastructure; for example some organizations might choose to keep their most sensitive data (e.g. customer information, credit card numbers, etc.) in-house but outsource everything else to, say, an Amazon EC2/S3 infrastructure. There is still some level of vendor lock-in here, but there is with anything else short of you implementing your own solution from scratch. And if, by leveraging proven solutions by companies like Amazon and Google, you are able to deliver real value to your customers faster and are able to scale up, out, and beyond without needing to build that infrastructure yourself, then I'd say that could potentially equate to a big win.

So when that vendor comes calling with their shiny new COA solution, be very afraid, and make sure you know your options and present them objectively. We as an industry have more buzzwords and hype (at least from my perspective) than almost any other, and this causes more money than I can possibly imagine to be wasted every year on solutions that don't (and never will) work as advertised. Developers often have a feeling that the VDD (vendor-driven development) solutions just won't work, but cannot convince their managers or their managers' managers of this fact, which is why communications skills are critical in today's world. I don't know about you, but I don't want to be the person who becomes responsible for implementing a solution I don't believe in.

"The Cloud" and cloud computing are definitely here to stay forever, and as Amazon and Google have proven, can add huge amounts of value to businesses. I am sure there will be other companies perhaps trying to implement similar strategies and monetizing their investment in their own infrastructure, and that will be mostly a good thing to have different options and competition to further push the Cloud Service Providers (CSPs) to continually improve their offerings. Get ready, because our toolboxes have just become a lot bigger.

jSilhouette update

Andres Almiray — Mon, 18 Aug 2008 11:00:01 CDT

A couple of days ago there was an announcement on this blog about jSilhouette's 0.1 release, followed by a comparison between the geom, scene and jfx demos (regular Java, Project SceneGraph and JavaFx Script each).

Things have changed a bit. Jacek Furmankiewicz brought to my attention that Project SceneGraph is licensed under GPLv2 (no classpath extension) which means both jsilhouette-scene and jsilhouette-jfx must use the same licensing scheme. But jsilhouette-geom does not, in fact it has been re-licensed to ASL 2.0, this means that starting with the next release commercial use of jsilhouette-geom is no longer a problem. The commercial usefulness of the remaining modules lies in Sun's will to re-license Project SceneGraph to GPLv2 with classpath extension.

Some other updates

Donut shape has been added to all modules. Donuts may be circular or polygonal.
Default values have been added to some attributes in the jfx module, alleviating the pain of setting each attribute.
Groovy demo (GraphicsBuilder based) available!

Here is an screenshot on the latest demo app

Nice Nimbus look &feel, you may be thinking that this is the new version of the jfx demo, but it is not! this is the Groovy version (ShapesDemoGroovy.groovy) , the green color is darker in jfx, remember? let's revisit the stats, shall we?

	geom	scene	jfx	groovy
LoC	369	505	619	369
Tokens	1486	1855	2644	2194
Source file size (bytes)	16412	21000	20626	15311
Compiled code size (bytes)	104K	60K	76K	92K

The Groovy version beats the JavaFx Script version in almost all categories (the source file is even shorter than the Java2D version) but these numbers do not reflect how small the code can be in each version. For example I discovered that the jfx version has some commas (,) between attribute declaration (which bump the char and file size), I was surprisewd to find out JavaFx Script was happy with them as not even a slight warning is given by the compiler, nice!; the Groovy version harnesses the power of native syntax for Lists and Maps to reduce variable declaration; defaults values are not really used that much in all versions.

I also mentioned previously that making the second and third demo was quicker once the first one was done, in this case it was no different. The jfx version was copied almost verbatim, added some Groovy sugar here and there (even had to add a MetaClass hack due to how SwingBuilder handles look&feel in the 1.5.6 version (the new one is slicker thank @shemnon for that)). Quick comparison between how the jfx and groovy versions initialize the frame, first the jfx one

SwingFrame {
   title: "jSilhouette Shapes (JavaFX)"
   visible: true
   closeAction: function() { System.exit(0); }
   width: 500
   height: 400
   content: BorderPanel {
      center: canvas /*an instance of Canvas*/
      left: GridPanel {
         columns: 1
         rows: 10
         content: [
            SwingButton { text: "Arrow"    action: drawArrows },
            SwingButton { text: "Balloon"  action: drawBalloons },
            SwingButton { text: "Cross"    action: drawCrosses },
            SwingButton { text: "Donut"    action: drawDonuts },
            SwingButton { text: "MultiRoundRectangle" action: drawMultiRoundRectangles },
            SwingButton { text: "Rays"     action: drawRays },
            SwingButton { text: "RegularPolygon" action: drawRegularPolygons },
            SwingButton { text: "RoundPin" action: drawRoundPins },
            SwingButton { text: "Star2"    action: drawStars },
            SwingButton { text: "Triangle" action: drawTriangles }
         ]
      }
   }
}

Where each draw* function is of the form

Here I'd like to take the opportunity to mention that the function signature must have Void as its return type otherwise a compilation error will be thrown. If the return type is not specified then it will be the same type of the last evaluated expression, in this case Node[], SwingButton expects its action function to return Void. I'm sure a tool (like NetBeans' jfx plugin) would have drawn a red underline/popped an error/whatever under the offending code before attempting a full compile on the code by myself, but I went with the "manual" way: Vim + command line compiler, so there, had to be more careful

Here is the Groovy version

Where shapes is a Map initialized like

The Groovy version requires some 'blumbing'

Fix SwingBuilder.lookAndFeel to accept a List of L&F identifiers (available in Groovy 1.6.x).
Set the preferred L&F.
Tell the frame where it should be located by default (locationRelativeTo: null)

The native syntax for Lists and Maps comes in our aid here. Iterating each entry (String,GraphicsOperation) it is a matter of hooking up the proper values on the button's text and action. Notice that each time a button is clicked a new GraphicsOperation is created (a group) that has a 'global' property applied to all its children (borderColor: 'black') and antialias is turned on. GraphicsPanel is smart enough to know when it should repaint itself (similar to JSGPanel and Canvas). Of course some would say you may iterate over a sequence in the jfx version in order to build the buttons in a loop, sure you can. You could also create a java.util.Map that holds each label and related function, but the code is not as concise as the Groovy one. Assuming hypothetical classes javafx.util.LinkedHashMap and javafx.util.MapEntry
Yup, hypothetical is more like it (my code that is, still have to learn more about JavaFx Script) but you get the idea. Back to jSilhouette, I'd like to have proper javadocs/javafxdocs in place before releasing the next version, so it will take a couple of days more.

Feedback is always appreciated.

Testing Anti-Patterns: Invisible Code

Jason Rudolph — Mon, 18 Aug 2008 08:00:01 CDT

As we’ve seen over the last several weeks, it’s remarkably easy for code to earn the badge of 100% test coverage without necessarily having a strong test suite. In each of those examples, the coverage analysis tool performed its task flawlessly: it reported exactly which portions of our code were executed as a result of running the tests. The all-green coverage report showed us that the tests indeed touched all of our code, but it was up to us to acknowledge that simply touching a line of code doesn’t mean that you’ve exercised and verified that line of code in a meaningful way. Some folks interpret this acknowledgement to mean that coverage analysis is meaningless, but that unfortunate conclusion overlooks the real benefit of a coverage report: it’s not about getting to 100% test coverage and assuming victory, it’s about highlighting any areas of our codebase that we’ve forgotten to test entirely.

As with any tool, to make effective use of coverage analysis, we need to understand its purpose, its capabilities, and its limitations. In all of the previous examples, we looked at code that was already in the coverage report. In other words, the coverage tool knew about this code and was able to watch the code and assess its coverage upon completion of the test suite. But if we’re using the coverage report to help us find untested code, how do we deal with code that the coverage tool might not be aware of in the first place?

Let’s start with a sample Rails app that represents the beginnings of an online store. The project currently contains the following files (as well as some others that I’ve omitted for the sake of brevity).

[store]$ tree
...
|-- app
|   |-- controllers
|   |   |-- application.rb
|   |   `-- products_controller.rb
|   |-- helpers
|   |   |-- application_helper.rb
|   |   `-- products_helper.rb
|   |-- models
|   |   `-- product.rb
|   `-- views
|       |-- layouts
|       |   `-- products.html.erb
|       `-- products
|           |-- edit.html.erb
|           |-- index.html.erb
|           |-- new.html.erb
|           `-- show.html.erb
|-- config
|   |-- boot.rb
|   |-- database.yml
|   |-- environment.rb
|   |-- environments
|   |   ...
|   |-- initializers
|   |   |-- inflections.rb
|   |   |-- mime_types.rb
|   |   `-- new_rails_defaults.rb
|   `-- routes.rb
|-- db
|   |-- migrate
|   |   `-- 20080810220638_create_products.rb
|   `-- schema.rb
...
|-- lib
|   |-- product_ftp_importer.rb
|   `-- tasks
|   |   |-- data_load.rake
...
|-- test
|   |-- fixtures
|   |   `-- products.yml
|   |-- functional
|   |   `-- products_controller_test.rb
|   |-- integration
|   |-- test_helper.rb
|   `-- unit
|       `-- product_test.rb
...

37 directories, 63 files

After installing the rails_rcov plugin, we can easily produce a coverage report to see where we currently stand.

According to the coverage report, we’re not aware of any code that isn’t touched by at least one test. But is that really the whole story? The number of test-related files sure accounts for a small proportion of the overall app. We can see that we have test/unit/product_test.rb and test/functional/products_controller_test.rb, but do those two files really encompass all the developer testing needed for this application?

Out of Sight, Out of Mind?

What about that mysterious file hanging out in the lib directory?

[store]$ tree
...
|-- lib
|   |-- product_ftp_importer.rb
...

Just judging by the name of the file, that sure sounds like functionality that deserves testing, but for some reason it’s not listed in the coverage report. And if we take another look at the test files listed above, there are no test files that obviously correlate to product_ftp_importer.rb. So, how is it that we have 100% coverage?

In order for code to show up in a coverage report, we need to instruct the coverage tool to assess that file. The approach for doing so tends to vary from tool to tool. With rcov, we first have to tell it which files constitute our test suite (i.e., the files we want rcov to run). But that alone is not sufficient; we also have to ensure that application files (i.e., the files whose test coverage we want to measure) get loaded as part of the test suite. Adding this require statement anywhere in our test suite is enough to shed some light on the elusive code in product_ftp_importer.rb.

require File.expand_path(File.dirname(__FILE__) + "/../lib/product_ftp_importer")

It’s hard to feel good about 45 lines of untested FTP-processing voodoo, so how can we unearth this invisible code as soon as it tries to sneak its way into our app?

Ensure that your coverage task knows where to find your tests, always place new tests where the coverage task can find them, and use a consistent naming scheme so that a simple file-matching pattern can distinguish test files from non-test files.
If you’re using rcov, add a quick script that will crawl your project tree and require all application files. Adding individual require statements one-by-one is not a reasonable solution. If someone’s not going to write the test in the first place, they’re sure as heck not gonna take the time to tell the coverage report about that misdeed. So, walk the tree and require any Ruby file that you encounter in places where application code is likely to turn up. At the very least, in a Rails app you should include all subdirectories under app (being aggressive enough to catch any new directories that might get added there) and the lib directory.

(Not So) Scenic View Ahead

View templates have long been a favorite dumping ground for misplaced application logic. This problem can often go undetected, because view templates fly under the radar of the coverage report. Most developers know they should minimize the application logic included in the view, but when a deadline’s looming, the lure of throwing some code in the view “just this once” is often hard to resist. For example, what’s so wrong with having the view decide whether to display a particular product in the list?

<% for product in @products %>
<% if product.quantity_in_stock > 0 && product.quantity_in_stock > product.pending_backorder_count %>
<!– display purchasable product here –>
<!– … –>
<% end %>
<% end %>

Well, how exactly will we verify that the view is indeed displaying the right products and suppressing the others? We could manually test each scenario by visually inspecting the resulting UI, and that might be good enough for us to have confidence that the app is doing the right thing as of this moment. But code has a life of its own, and it will grow and change over time, and we want automated tests to make sure that this page continues to display the correct data even after those inevitable changes.

So we decide to write tests to verify that we’re displaying only the right products. And since this logic is inside our view template, we need to write tests that will render our view template and then dissect the resulting HTML to verify that it contains the products that should be present and that it does not contain the products that should not be present. But in order to render the HTML, we need to invoke some controller action. And because that lone if statement needs at least four different test cases to check the various conditions, we get the joy of doing all that setup and dissection at least four times. That’s a big enough pain that it quickly becomes very tempting to let this bit of logic remain untested, remain out of sight of the coverage report, and remain “good enough.”

We can do better than that. When something’s too hard to test, we should refactor it until it’s easy to test. [1]

We’re going to need this logic outside of the view anyway, so the sooner we get it into the model the better. Sure, the view will only display those products that are available for purchase, but we need that logic for server-side validation as well. Before we process an order, we need to make sure that we still have the product in stock. If we leave the logic in the view as is, then we’ll be forced to duplicate that logic elsewhere inside our order-processing code. There’s clearly no justification at all for leaving this logic in the view.

<% for product in @products %>
<% if product.available_for_purchase? %>
<!– display purchasable product here –>
<!– … –>
<% end %>
<% end %>

When we encapsulate this logic in the Product class itself, we can test that logic in isolation, without any dependencies on controllers, and without the need for fragile HTML-parsing to verify the result. Once we perform this refactoring, unit testing the #available_for_purchase? method becomes trivial, and we can refer to that method wherever necessary without unnecessary duplication.

Better still, if we know that we only want to display the products that are available for purchase, we can ensure that our controller provides only those products to the view in the first place. With this approach, our view then enjoys the pleasant simplicity of just displaying the list of products.

<% for product in @products %>
<!– display purchasable product here –>
<!– … –>
<% end %>

The coverage report isn’t going to alert us to business logic lurking in our view templates. It’s up to us to keep our views from becoming too smart for their own good, and it’s up to peer code reviews to keep us honest.

Raking for Buried Treasure

While it’s tempting to let our views acquire too much business logic, there’s usually an obvious place to move that logic once we realize the error of our ways. (In Rails, you’ll typically relocate that logic to a model class or to a helper, either of which are easily tested in isolation.) But what about the other parts of our application where untested code tends to hide out and germinate?

Perhaps we have some code that only needs to run at application start-up. In Rails, we’re talking about code in environment.rb or config/initializers. In Grails, BootStrap.groovy is home to this logic. In either case (or in most any other framework), we’re not likely to see those start-up “scripts” included in the coverage report, nor is there a natural and obvious place for testing any complex code that we may need to include in the start-up process. We’re used to testing models and controllers and helpers and mailers, but where does this start-up logic fit into the mix?

Data migration suffers from a similar problem. Rails migrations are great for creating and dropping tables, adding and removing columns, etc., but sometimes we need to do more than just alter the schema; sometimes we want to push data around as well. Schema transformations are essentially declarative code, and really don’t warrant anything beyond visual verification of the results. But when it comes time to migrate 10 million records from some legacy database into our hip new application, chances are we’re not just talking about simple declarations anymore. What’s the worst that could happen though? This code only has to run once. And who wants to write a bunch of tests for code that we’re only gonna run once and then throw away? And once again, there’s no obvious place for us to add tests for this kind of data conversion functionality in the first place. Surely a simple Rake task will suffice.

namespace :db do
namespace :load do
desc ‘Load products from csv’
task :products do
require ‘csv’
require ‘environment’
CSV.open("#{RAILS_ROOT}/db/input/csv/product-catalog/products.csv", ‘r’).each_with_index do |row, idx|
next if row[0] == "Product"
p = Product.find_or_create_by_name(row[0])
p.description = e.purpose = row[5]
p.sku = row[3]
p.price = row[4]
p.save
shipping_options = row[1].split("|")
shipping_options.each do |o|
p.shipping_options << ShippingOption.find_by_name(o)
end
vendors = row[2].split("|")
vendors.each do |v|
p.vendors << Vendor.find_by_number(v) unless v.downcase == ‘none’
end
end
end
end
end

Indeed, a simple Rake task will suffice, but that’s certainly not what we’re looking at above. While we could write tests for this logic in its current state, doing so is unnecessarily difficult. We’d be restricted to solely black box tests. To test each individual decision point, we’re forced to also construct a new file holding the appropriate dataset, run the Rake task, and then inspect the state of the data in the database. For every decision point.

Scripts Can Be Classy Too

We shouldn’t have to also test the ability to read a file (i.e., line 7) just so that we can test the ability to populate a vendor based on a given vendor number (i.e., line 21). For sure, we want one good end-to-end test to verify that all the cogs are working together correctly. But if that’s our sole testing strategy, then we’ve made testing just painful enough that it probably won’t happen at all.

Whether we’re talking about hard-to-test code in start-up scripts, hard-to-test code in migration scripts, or hard-to-test code hiding out in the handful of other custom scripts that an application tends to accumulate over time, the answer’s the same in each case. Just because the coverage report doesn’t see this hidden code doesn’t mean that it’s not worth testing. And just because our framework-of-choice might not provide a convention for testing this logic, that doesn’t mean that we should just punt.

When something’s too hard to test, we should refactor it until it’s easy to test.

namespace :db do
namespace :load do
desc ‘Load products from csv’
task :products do
require ‘environment’
importer = ProductCsvImporter.new("#{RAILS_ROOT}/db/input/csv/product-catalog/products.csv")
importer.run
end
end
end

In the case of this Rake task, and in each of the cases discussed above, by simply moving the logic out of the script and into a proper class (or module), the testing strategy goes from clumsy at best to downright obvious. We no longer need to invoke the whole script in order to verify the particular unit of functionality that we want to test. Instead, we test that functionality in isolation, and allow the script to resume its trivial role of merely calling our well-tested class.

Use It Wisely

In order to make effective use of coverage analysis, it’s important for us to understand what a coverage report is telling us and what it’s incapable of telling us. Tools are imperfect, but we can adopt strategies to make sure we’re reaping the maximum benefit from the tools we choose to employ. With good naming conventions and an agreed-upon application structure, we can easily configure an intelligent solution that allows the coverage tool to automatically pick up any new source files that we want included in the report. With a commitment to testing all application logic - regardless of whether it’s needed in a model, a view, a script, etc. - we’ll extract the code that would otherwise be buried in a dark corner of our app. We’ll benefit from the ability to test it in isolation, and we’ll allow the coverage tool to assess that code, giving us a more realistic and complete view of our codebase.

Invisible code is hidden technical debt, but the sooner you expose it, the sooner you can start to pay it down.

Notes

[1] In past posts in this series, I’ve advocated test-driven development (TDD) as means for combatting the various testing anti-patterns. Invisible code is no exception. While this post is geared more toward uncovering invisible code so that we can give it the testing it deserves, developing test-first is the best bet for preventing invisible code in the first place.

This series is taken from the How To Fail With 100% Test Coverage talk. Check the schedule for a talk near you.

–

Thanks to Muness Alrubaie, Justin Gehtland, and Greg Vaughn for reading drafts of this post.

Agile 2008 - Sanjiv Augustine - The effect of Agile Projects on Middle Management

Bob Payne — Sun, 17 Aug 2008 16:00:01 CDT

I talk with Sanjiv Augustine about his work with Agile Project/Portfolio Management and the Middle Managers that execute projects within organizations. Sanjiv and I have worked together for years on client engagements, training and publishing. More recently we have been working to kick off Agile Philanthropy. LitheSpeed was the sponsor for the LiveAid Stage this year and you will be seeing more of Sanjiv and LitheSpeed in the years to come here on the Agile Toolkit Podcast.

Enjoy.

-bob payne

eRubyCon 2008 Day 2

Josh Holmes — Sun, 17 Aug 2008 13:00:01 CDT

Yesterday I wrote a write up of eRubyCon 2008 Day 1.

- Charles Nutter started up with JRuby. I'm always impressed by people that are able to make their weekend project their full time job. I was further impressed that Charles was up with the rest of the speakers until closer to 4am than any of us should really admit, drinking really good scotch and solving the world's problems.

Charles talked about the JVM and Java as both a problem and a great asset. There are a lot of people that look at the J in JRuby and automatically associate it with all of the things that they don't like about Java. Charles answer is to separate the JVM from the Java language. He did a really good job of talking about the things that the JVM brings over the standard Ruby runtimes such as world class garbage collection, memory compaction, thread handling and the like. He did a number of really compelling demos around threading in particular. One of the things that he said here is that JRuby and IronRuby are really the only Ruby implementations that are able to do native threads because they are the only ones that are built on production quality VMs that handle that native threading for them.

One of the great quotes was "We write a lot of Java. So you don't have to..." - Charles Nutter

After setting the stage, he pulled up a long list of features and said - "There's way too much for me to cover in the time left - what do you want to see?". that was fun. The first suggestion that he showed was 2D graphics that flashed a bunch of little balls around the screen. It was even responsive to voice commands. The second suggestion was to show Rails running on JRuby. He showed that they are running Rails on Ruby 1.8.6 (java). Next he brought up image_voodoo to do more 2D libraries. Lastly, he showed "java_inline" which allows you to inline Java code similar to the Ruby_inline which allows you to inline C right in your Ruby code.

- Evan Light came up next. Unfortunately I was putting out a few small fires. Fortunately Michael Lettere wrote up a small write up so that I could include it here.

Evan Light hates EJBs.
EJB encourages difficult to test idioms, private fields, private static final fields.
Nice demo code "public class DeepThought" <--- How do you test that?
You COULD shoot the guy who wrote it, but don't do that.
Very good use of humor, engaged the audience.

- The lunch keynote was Neal Ford. Neil Ford is an amazing speaker. What’s cool about him is that every time I see him speaker, I wonder how he could get any better. And then he does. Today’s talk was about complexity. One of the core concepts that he talked about is the idea of Language Lockdown. It’s when language writers put in features to protect people from themselves and cut down on the stupid things that you can do. The idea is that if you do that the lower end (read cheaper) developers will still be productive. “What they are trying to do is strap a rocket to the ass of a turtle. What they are actually doing is putting chains on the rabbits than can go fast.”
The problem with that take though is two fold. First, it is not a linear line between the top developers and the lower end developers. What that means is that on the curve, a highly productive programmer will get done in one day what it will take an average developer more than a week to do and the weak developer a month or more. To point out the second issue, Neal quoted one of my other favorite speaker - “Bad developers will move heaven and earth to do the wrong thing” - Glenn Vanderburgh
One of the huge questions that he put out there is “How much of your enterprise software simple services accidental complexity?”. It’s a great question.
As he was wrapping up, he left us with the thought that “Courage is contagious. Cowardice is infectious”.

- Following Neal was Stuart Halloway again. He was talking this time about how one can fail with 100% test coverage. It’s an interesting topic because for so many people, 100% test coverage is the holy grail that they shoot for. The first thing that he pointed out is that you might cover all the lines, but not all the branches so it depends on how you measure things to get to 100% coverage. The second thing that he points out is that you can cover all the code, but not all the corner cases. The example that he used is testing if a value is above or below $25.00 but forgetting $25.00 even. Oops. Then you can start writing way too much code and too much complexity into your tests. Now you need to test your tests and you’ve taken too much time writing them. Then he talked about the “ugly mirror” where the test is really a mirror of the code where you’re covering the line but using the code that you are trying to test while testing – oh dear I have a headache. This is where he says that you are allowed to write literals in your tests.
Neal Ford piped in - “It’s ok for your test to be moist, not drenched”.
The next topic was slow tests and how dangerous they are. The short version of the issue is that if the unit tests don’t run in under 1 second, developers are not going to run them. Functional tests should run in under 2 minutes. If they don’t, then factor them so that they run on different schedules, parallelize them on different machines to get the normal check-in process back under the 2 minute mark if possible.
The last type of fail that he talked about is shallow tests. The quote that he referenced is “No automated test suite can ever replace exploratory testing.” - Jay Fields. The goal is that once the unit and functional testing passes, that people will put themselves in the clients seat and go spelunking and try out a bunch of stuff.

- The next talk was a very unique idea called “Dialogue Concerning the Two Chief Modeling Systems”. They wrote a play! The guys from EdgeCase, Joe O’Brien, Jim Weirich and Chris Nelson, acted out a normal project for them. They started out on twitter talking about the new project that they just landed. Then they actually started with the early on meetings that they have. Joe played the cowboy dev lead who insists that it’s a “simple rails app” and decides to do a data first model. Chris played clueless nub and Jim played the seasoned architect that was concerned about requirements analysis, separation of layers and behavior driven models. Joe, ready to start slamming code out, starts pairing with Chris. The first thing that they tackle is a simple calendar event. Then they have to schedule reoccuring events. Joe, the cowboy, just decides to replicate the events in order to do the reoccurence. The next requirement is rescheduling the reoccuring meetings.... Oops. They have neatly coded themselves into a corner and start hacking out a solution. At that point, Chris decided to take a walk and went to see what Jim thought of it all. Jim started writing out CRC cards and started thinking about higher level ideas, bringing in light-weight design patterns around temporal expressions from Martin Fowler and so on. Jim, the architect, is blithely ignoring “implementation details” such as where to store the data and performance. When performance sucked – they went back to the drawing board. Jim and Joe had to eventually come together. Of course the answer was to write a DSL... :)
Great talk. The good news is that Neal Ford is following them so there won’t be a let down as we end the day...

- The last talk of the day was Neal Ford talking about Design Patterns in Ruby. One of the things that he pointed out fairly early on is that the Design Patterns book, even according to one of the authors ( Vlissides), should have been called “Making C++ Suck Less”. Even the Smalltalk that’s in the book was really C++ written in Smalltalk syntax. He covered a number of different patterns including the Iterator and the Interpretor pattern. There were a number of circumstances where he pointed out that the issues addressed by the pattern were addressed by the Ruby language. For example, the interpretor pattern’s intent is really addressed by DLSs which are dead easy to implement in Ruby. The only problem with this session is that it’s at the end of the day and my brain is a little mush at this point.

Dan Pritchett on Availability

Michael Nygard — Sun, 17 Aug 2008 11:00:01 CDT

Dan Pritchett is a man after my own heart. His latest post talks about the path to availability enlightenment. The obvious path--reliable components and vendor-supported commercial software--leads only to tears.

You can begin on the path to enlightenment when you set aside dreams of perfect software running on perfect hardware, talking over perfect networks. Instead, embrace the reality of fallible components. Don't design around them, design for them.

How do you design for failure-prone components? That's what most of Release It! is all about.

Storytelling

Alex Miller — Sun, 17 Aug 2008 08:00:01 CDT

I’ve been taking a lot of walks lately and listening to podcasts, and I’ve become kind of addicted to podcasts oriented around story-telling. Perhaps the best is This American Life with Ira Glass. This NPR series every week takes a theme and tells a series of stories around it. They do an amazing job of putting together a riveting show every week. You can subscribe on iTunes but to reduce bandwidth they only provide the most recent episode.

Last week’s episode “Fear of Sleep” featured a number of good stories, but the one that stood out for me was Mike Birbiglia’s stories about him acting out his dreams. For one, it’s really funny, as only extended personal stories can be. For another, the presentation is just pitch-perfect - the pauses, the word choice, the pacing, etc. Of course, the comedian background should make this no surprise.

Of course, Mike’s performance was actually taken from a show at The Moth, which I’ve never heard of before. Apparently, they do storytelling shows in both New York and LA. Even better, they have a podcast. :) So, now I’ve been working my way through their podcast and enjoying it immensely.

Anyone else have any favorite story podcasts to share?

Ajax4jsf/RichFaces presentations at JSFOne

Max Katz — Sat, 16 Aug 2008 16:00:01 CDT

Besides my presentation, there are a two other talks covering Ajax4jsf/RichFaces at JSFOne:

Dan Allen, Building JSF components with the Ajax4jsf CDK
David Geary, Using Ajax4jsf

Read more about Ajax4jsf and RichFaces names

Framework Design Guidelines 2nd Edition Available today on Rough Cuts

Brad Abrams — Sat, 16 Aug 2008 13:00:01 CDT

Krys and I just finished writing the update to the framework design guidelines and you are can already get the "Rough Cuts"! That is right, in today's instant information world why wait for copy editing, printing and shipping time!

Framework Design Guidelines: Conventions, Idioms, and Patterns for Reuseable .NET Libraries on Rough Cuts

Expect it in on Amazon and in book stores late this year.

Getting a list of Grails plugins programmatically

Kenneth Kousen — Sat, 16 Aug 2008 11:00:01 CDT

In September, I’m very happy to be giving a couple of presentations at the No Fluff, Just Stuff conference in the Boston area. One of my presentations is a review of the various available Grails plugins. To prepare for that, I thought I’d create a Grails application that acted as a survey, so people could rate the plugins they like.

One task is to get a list of available Grails plugins. I wanted to do that programmatically, too, because I’d like to update the list automatically using the Quartz plugin (of course).

How do you get a list of available plugins? My first thought was to do the HTML equivalent of screen scraping at the main plugin site, http://grails.org/Plugins . At that site everything is nicely divided into categories, along with links to descriptions and more.

Screen scraping HTML is not fun, though. I’ve done it before, when necessary, but it’s not very robust and tends to run into problems. Many of those problems have to do with the fact that HTML is a mess. Most web sites are filled with HTML that isn’t even well-formed, making processing it programmatically a real pain.

GinA, however, mentioned HTTPUnit as an easy way to access a web page. Since it’s a regular old Java library, that meant I could use it with Groovy. Therefore, my first attempt was:


import com.meterware.httpunit.WebConversation

def baseUrl = 'http://grails.org/Plugins'

def wc = new WebConversation()
def resp = wc.getResponse(baseUrl)

Unfortunately, I’m already in trouble even at that point. If I run that, I get a massive exception stack trace with shows that the included Neko DOM parser choked on the embedded prototype JavaScript library.

While I was debating what to do about that (I really didn’t want to just open the URL, get the text, and start having Fun With Regular Expressions), I noticed a blog posting here, from someone named Isak Rickyanto, from Jakarta, Indonesia.

(A Java developer from Java. How cool is that? Or should I say, “how Groovy?” :))

Isak points out that there is a list of Grails plugins at http://svn.codehaus.org/grails-plugins/ . As a Subversion repository listing, it’s not full of JavaScript. Even better, every plugin is listed as a simple link in an unordered list.

I therefore modified my script to look like this:


def baseUrl = 'http://svn.codehaus.org/grails-plugins/'

def wc = new WebConversation()
def resp = wc.getResponse(baseUrl)
def pluginNames = []
resp.links.each { link ->
    if (link.text =~ /^grails/) {
        def name = link.text - 'grails-' - '/'
        pluginNames << name
    }
}
println pluginNames

Here I’m taking advantage of the fact that the WebResponse class (returned from getResponse(url)) has a method called getLinks(). Since there was one link that had the name “.plugin-meta“, I decided to use a trivial regular expression to filter down to the links definitely associated with plugins. The WebLink.getText() method then returned the text of the link, with gave values of the form

grails-XXX/

for each plugin. One of the things I love about Groovy is that I can then just subtract out the characters I don’t want, which is how I added the actual plugin names to an array.

Unfortunately, while that’s part of what I want, that isn’t everything I want. I’d like the version numbers and the descriptions, too, if possible. I could go digging into the various directories and look for patterns, but a different idea occurred to me.

I finally remembered that the way I normally find out what plugins are available is to run the

grails list-plugins

command and look at the output. You’ve probably seen it. It gives an output like

Welcome to Grails 1.0.3 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: c:\grails-1.0.3

Base Directory: c:\
Note: No plugin scripts found
Running script c:\grails-1.0.3\scripts\ListPlugins.groovy
Environment set to development

Plug-ins available in the Grails repository are listed below:
-------------------------------------------------------------

acegi               <0.3>            --  Grails Spring Security 2.0 Plugin
aop                 <no releases>    --  No description available
audit-logging       <0.4>            --  adds hibernate audit logging and onChange event handlers ...
authentication      <1.0>            --  Simple, extensible authentication services with signup ....
autorest            <no releases>    --  No description available

etc. So if I could get this output, I could break each line into the pieces I want with simple String processing.

How can I do that? In the spirit of reducing it to a problem already solved, I realized I just wanted to execute that command programmatically and capture the output. One way to do that is to take advantage of Groovy’s ability to run command line scripts (GinA covers this, of course, but so does Scott Davis’s most excellent Groovy Recipes book). Here’s the result:


def names = []
def out = "cmd /c grails list-plugins".execute().text
out.split("\n").each { line ->
    if (line =~ /<.*>/) {
        def spaceSplit = line.split()
        def tokenSplit = line.split('--')
        def name = spaceSplit[0]
        def version = spaceSplit[1] - '<' - '>'
        def description = tokenSplit[-1].trim()
        names << name
    }
}

Basically I’m executing the list-plugins command at a command prompt under Windows (sorry, but that’s still my life), splitting the output at the carriage returns (for some odd reason, using eachLine directly kept giving me errors), and processing each line individually. The lines listing plugins are the ones with version numbers in angle brackets (like <0.3>), and the descriptions came after two dashes. It seemed easiest to just split the lines both ways in order to get the data I wanted.

I ran this script and the other script together to see if I got the same output. Here’s the result:


println "From 'grails list-plugins': " + names
println "From svn repo: " + pluginNames
println "Difference: " + (pluginNames - names)

From 'grails list-plugins': ["acegi", "aop", "audit-logging", ..., "yui"]
From svn repo: ["acegi", "aop", "audit-logging", ..., "yui"]
Difference: ["extended-data-binding"]

Why the difference? From the list-plugins output, here’s the line for “extended-data-binding“:


ext-ui              <no releases>    --  No description available
extended-data-binding<0.2>            --  This plugin extends Grails' data binding ...

Yup, the name ran into the version number format. Sigh. Of course, the other problem with this is that at the moment it’s dependent on my own system configuration (Windows, with the grails command in the path), which can’t be a good thing.

Finally, after all this work, I suddenly realized that I already have the script used to list the plugins. As with all the other Grails commands, it’s a Gant script in the <GRAILS_HOME>\scripts directory called, obviously enough, ListPlugins.groovy. According to the documentation at the top, it was written by Sergey Nebolsin for version 0.5.5.

What Sergey does is to go to a slightly different URL and then parse the results as XML. His script accesses

DEFAULT_PLUGIN_DIST = "http://plugins.grails.org"

instead of the SVN repo location listed above, but if you go there, they look remarkably alike. I wouldn’t be surprised if http://plugins.grails.org is simply an alias for the SVN repository.

Note that the script also creates a cached version of the plugin list, called plugins-list.xml, which is kept in the

"${userHome}/.grails/${grailsVersion}/plugins/"

directory. That’s completely understandable, but a lousy location on a Windows box. I never go to my so-called “user home” directory, so I would never occur to me to look there for information.

His script checks to see if that file is missing or out of date. If it’s necessary to update it, he opens a URL and starts processing:


def remoteRevision = 0
new URL(DEFAULT_PLUGIN_DIST).withReader { Reader reader ->
    def line = reader.readLine()

...

    // for each plugin directory under Grails Plugins SVN in form of 'grails-*'
    while(line=reader.readLine()) {
        line.eachMatch(/<li><a href="grails-(.+?)">/) {
            // extract plugin name
           def pluginName = it[1][0..-2]

           // collect information about plugin
           buildPluginInfo(pluginsList, pluginName)
        }

etc.

So, in effect, he’s screen scraping the SVN page; he’s just doing a better job of it than I was.

Incidentally, the line in his script that lead to my parsing problems is on line 86:

plugins << "${pluginLine.padRight(20, " ")}${versionLine.padRight(16, " ")} -- ${title}"

I could bump up the padding by one, or learn to parse the output better. I expect the “right” answer, though, is to do what Sergey did, pretty much. Still, if all I have to do is add a little padding, it’s awfully tempting to just “reuse” Sergey’s existing script.

In an upcoming post, I’ll talk about how I used the RichUI plugin to apply a “star rating” to each entry so that people could vote. I don’t have the site ready yet, though. I’ll be sure to mention it when I do.

eRubyCon 2008 Day 1

Josh Holmes — Sat, 16 Aug 2008 08:00:01 CDT

I'm sitting here at the second Enterprise Ruby Conference (eRubyCon). There's a couple of fun and interesting things that have happened this year.

One of them that's exciting for me is that the whole event is being hosted at the Microsoft facilities in Columbus, OH. Joe O'Brien was looking for a facility so I offered up the office since we can get that for free. There are some minor facility issues, such as the internet access is fairly limited due to the Microsoft security policies. We got that mostly sorted by renting a number of cell card based routers from iBox2Go. It's not a perfect solution because we're at about double the recommended number of users per router. That's caused network to be a touch spotty but it's better than non-existent.

Another thing that's a ton of fun is that we've doubled the number of attendees. The conference room here at the Microsoft office is FULL. Tomorrow I'll show some pictures from the conference room. It's really cool to see.

The whole event is going very well. Joe has been plagued with speakers having travel issues and the like. For example, Stu Halloway was supposed to do a lunch time keynote but was thrown off as his plane had mechanical issues. The great news is that this is an Agile conference and everyone is used to requirements changing mid-project and Joe was able to shuffle the speakers.

- First up was Randall Thomas from the Engine Yard. He was talking about ETL (Extract, Transform, Load). He did a masterful job of making that important topic interesting and fun. It's a fundamental topic but even Randall equated it to Bob Ross painting trees and it was tough to keep people awake talking about the best possible way to make one string into two and two into one...

- Next was Tom Mornini. I wish I had been able to stick around for this talk. He talked heavily about Vertebra, Scalability and Accountability.

- Anthony Eden followed Tom with a session on Identity Management. It was interesting to hear his take on OpenID, InformationCard, SAML and how Ruby works with those. The good news for Ruby is that it does really well with and is leading the way with OpenID. The bad news is that the things that are done inside of an enterprise are a little less prevalent in the Ruby at the moment. It was a great tutorial on the state of

- Giles Bowkett talked about Meta-Programming vs. Code Generation. He had a fun and deep tirade on something called Monkeypatching.

"A monkey patch (also spelled monkey-patch, MonkeyPatch) is a way to extend or modify the runtime code of dynamic languages (e.g. Smalltalk, Javascript, Objective-C, Ruby, Perl, and Python) without altering the original source code." - http://en.wikipedia.org/wiki/Monkey_patch

This is meta-programming at it's finest. He then went on to talk about meta-monkey-patching or meta meta programming... Somewhere in there I got a headache. That's about the time that he brought it back to Code Generation. My favorite quote, other than "Here's a completely gratuitous picture of Jessica Albert" (which did come with a gratuitous picture of Jessica Albert...) " "Should I hire a programmer or should I just write one?". He gave an example of a past job at NY Times where he left after he wrote a "mini-giles". That's a code generator that did much of what he had been doing until he wrote the generator. The "mini-giles" meme has really taken off since then and has been worked into a ton of the talks and conversations...

- Stuart Halloway followed Giles with a keynote called "Ending Legacy Code in Our Lifetime". He had one of the better starts that I've ever heard - "Legacy Code is like Porn. I know it when I see it. It's ubiquitous on the internet. And like all porn, it's ultimately unsatisfying". (At least he has it on good authority that porn is ultimately unsatisfying). One of the things that Stuart points out is that code can be broken down to Ceremony and Essence. The Essence is what you actually want to get done. The Ceremony is the stuff that you have to do in order to have the Essence work. For example, if you have gone from "New" on an object to writing factories - the reality is the factory is Ceremony. End of the day, all you really wanted is an object.

Another great quote from Stuart was "Ceremony leads to fear. Fear leads to anger. Anger leads to pain. Pain leads to Ceremony." The goal, according to Stuart, is to have as little ceremony as possible and have every line of code contribute to the Essence. And right now, Ruby is the closest answer as it's got a fairly high Essence to Ceremony ratio.

His talk was chock full of great quotes - "What authority authorizes this in the Ruby world? - ME - and I'm Right". It was full enough of great quotes that there's a Stu Halloway Quote Tracker.

- Brian Sam-Bodden, always a great speaker, closed out the day with Refactoring with JRuby. He talked about the core of refactoring is having a great suite of tests. One of my favorite quotes from him was "Since I'm a Java consultant, I have a lot of work to do...".

Overall, it was a great day. I really enjoyed catching up with a lot of the guys that I don't get to see at the .NET community events. I'm hoping that most of these guys will be at CodeMash cause that will give me 2 times a year to hang out.

Ajax4jsf and RichFaces - historical perspective

Max Katz — Fri, 15 Aug 2008 16:00:01 CDT

The following is a snippet from my upcoming book which talks about Ajax4jsf and RichFaces names and historical perspective.

It’s a good idea to give you some background on how RichFaces was born and also tell you what Ajax4jsf is. Ajax4jsf has its roots in RichFaces. The Ajax4jsf framework was created and designed by Alexander Smirnov. In early 2005, he was looking to add a “hot” new technology along with the associated experience to his resume. Roughly at the same time, the concept of Ajax was being established by Jesse James Garrett. Meanwhile, JSF was starting to pick up steam. Alexander figured why not just merge the two, so it would be easy to have Ajax functionality within a JSF application. He figured this would be an excellent addition to his resume. He started the project on sourcforge.net and called it Telamon (taken from the Shakespeare play, Anthony and Cleopatra) and Ajax4jsf was born.

In the fall of that same year, Alexander joined Exadel and continued to develop the framework. Alexander’s goal was to create a tool that was easy to use and that could be used with any existing JSF component libraries. The first version of what would become Ajax4jsf was released in March 2006. It wasn’t quite a standalone thing, yet. Rather, it was part of a product called Exadel RichFaces. Later in the same year, RichFaces was split off and the Ajax4jsf framework was born. While RichFaces provided out-of-the-box components or what’s called a component-centric Ajax approach (components that do everything you need), Ajax4jsf provided what’s called page-wide Ajax support. You as a developer specify what parts of the page should be processed on the server after some client side user actions and what parts should be rendered back (rendering is happening on the server and then partial DOM updating on the client) after processing.

Ajax4jsf became an open source project hosted on Java.net while RichFaces became a commercial JSF component library. Fast-forward to March 2007. JBoss and Exadel forged a partnership where Ajax4jsf and RichFaces would now be under the JBoss umbrella and be called JBoss Ajax4jsf and JBoss RichFaces. RichFaces would now also be open source and free. In September 2007, JBoss and Exadel decided to recombine Ajax4jsf and RichFaces under the RichFaces name. It made sense as both libraries were now free and open source. Having just one product solved many version and compatibility issues that existed before, such as which version of Ajax4jsf works with what version of RichFaces? While today you will still see an a4j namespace used, the product is now called JBoss RichFaces.

Is Your Product Development Half-Actions?

Johanna Rothman — Fri, 15 Aug 2008 13:00:01 CDT

Via Jack Vinson, I found this gem: Stop doing half-actions.

All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A half-action means you have technical debt and will have to get back to that area of the product.

Silos encourage half-actions (or third-actions or sixth-actions). Defining the architecture and implementing across it encourages half-actions. Create a cross-functional product development team. Have them finish one feature at a time. That’s a full action.