No Fluff Just Stuff

Architecting from the Features

Johanna Rothman — Sun, 06 Jul 2008 16:00:00 CDT

I’m writing the portfolio management book, and I just finished a whole big re-architecture. I’m so excited.

I realize most people aren’t that excited about a rearchitecture :-), especially not of a book in progress. But I am, because I took my own advice.

When I started writing the book, I had several partly done chapter-things. They were not particularly well-written, nor were they coherent and several pieces were tightly coupled. But they were enough for the Prags to see what I was thinking. Luckily, that was enough for a contract.

I’ve been writing off and on since I got the contract, and have been getting stuck. I realized last week it was time to print the book and start cutting pieces of it to reorganize.

I finally started making the book (yes, I write in markup language, check my writing into Subversion, and use make to make the book), and seeing it on paper helped me see where my features were.

I have some user stories:

“As a first level manager or technical lead, I want to see how to make a portfolio.”
“As a middle manager, I want to see how to make a portfolio and make decisions about it.”
“As a senior manager, I want to review the portfolio, and make decisions about it based on data.”

But being your own product owner is not such a good idea. Because I thought the roles were driving the book, I had separated a bunch of the writing by role first, and then what the roles did. But it turns out, that for this book, right now, the portfolio activities are what needs to drive the book. Maybe that’s obvious to you. But it wasn’t for me.

I realize the current book’s architecture may not last. But I can see how to write more of it. And, I’ve been refactoring to clean up my writing. I think of the refactoring as where I put things to make the book clearer, and editing as how I change the words to make the ideas clearer.

I wrote several features–actually parts of several features because I got stuck. Now I’ve rearchitected and the writing is flowing. I’m probably not done rearchitecting, but that’s ok. I have a place to head towards now. Onward!

Uxebu Hangs Their Shingle

Alex Russell — Sun, 06 Jul 2008 13:00:00 CDT

Several Dojo’s most prolific European contributors have banded together to form Uxebu, a new consultancy centered around Dojo and JavaScript (blog here). SitePen recently expanded to the UK and while we’re doing lots of business in the EU, it’s an exciting time to be working with Dojo as the demand is very high. I’m tremendously excited to see that Nikolai, Wolfram, and Tobias are stepping in to help fill the need! Given the quality and quantity of their contributions to Dojo, I expect great things of their new firm.

Congrats guys!

Ode to Process

Nathaniel Schutta — Sun, 06 Jul 2008 11:00:00 CDT

Clearly I’ve kicked off a trend - one day, I post about process, a few days later Reg Braithwaite coins a new term and the Daily WTF posts an ode to process . OK, I’ve only got three readers so I know it’s all just a big fat coincidence but still! Process theatre really does capture the notion perfectly; pointy haired bosses believe more templates, meetings and blind adherence to methodology are the answer to failing projects. Of course when you remove all decision making from the hands of sentient beings, you get a lost workday instead of someone just hitting the spacebar.

I’m not anti-process; you’ve got to have some framework to hang your work on. I plain can’t stand dogma though and I thoroughly believe you need to test your processes just as much as you test your code. Is this document/meeting/hurdle saving us money? Resulting in better projects? Happier customers? Whatever the raison d’��tre, we should make sure it’s actually delivering. Do more of what works, less of what doesn’t. Rinse and repeat.

LHB: Same Story, Different Tune

Alex Russell — Sun, 06 Jul 2008 08:00:00 CDT

I’m not sure how I missed it for so long, but I’m now reading every word of the Linux Hater’s Blog. It’s beautiful catharsis, and I say that as someone who used to serve as President of a university LUG and who writes open source software for a living.

Like the author of LHB, I’ve written my share of low-level Linux stuff and shudder in horror and how backward the linux desktop still is. X11 is an abomination and configuring sound or wifi or some new-ish device…well, I still have those scars. It wasn’t that long ago that I was hacking together bits of kernel patches to get an early firewire iPod (a gift from Jennifer) working on my SuSE desktop. And I was using SuSE because it usually required the least futzing of the then-available distros. Even when Linux was my desktop OS of choice – I had since climbed down from my brief flirtation with OpenBSD – it was blindingly clear to me that building my own packages was a fool’s game. My time is simply worth more than that. Perhaps the most cogent point I took away from reading the LHB archives is that building professional code for the “Linux Platform” is nearly impossible, not because it can’t be done, but because it costs too damned much to justify the costs. The Linux crowd seems to mis-value the immediate vs. long term costs of choice. By failing to provide a binary-friendly environment, the Linux world creates conditions only friendly to Open Source software, crippling their platform and robbing it of the capital investment that would allow it to truly compete. Many people who suffer through some Linux distro as their desktop environment no doubt see this as a good thing. I, however, need to get some work done. The LHB cogently lays out why everyone else on the planet whose time is worth more than what Amazon charges for a CPU-hour on EC2 similarly dismisses Linux for anything but servers.

The almost religious belief that choice is good ignores the inability of most people (myself included) to fully judge the long-run costs of any given technology decision. Oddly, the web browser world seems stuck in a similar position. Choice in browsers is promoted like some sort of panacea, when in fact our big problem isn’t choice, it’s that browsers simply can’t natively attempt the feats we need them to accomplish. Smart people don’t replace their browsers, they use what works until it doesn’t any more. No wonder it’s taken Firefox so long to gain market share. Like linux distros, browsers evolve in hodge-podge was, never quite tracing a straight line toward real progress. The refrain of “standards will save us” seems to ignore the reality that, like the LSB, the existing W3C standards are absolutely insufficient to address the problems at-hand. Both CSS3 and HTML5 are nice first-stabs, but they don’t get us “there”. For Linux, the LHB points out that there’s zero reason to not ship “the same bits”, and for the web, the issue is that content can’t tell the browser “no, really, use that renderer”. Interestingly, Microsoft tried to convince the world that we should version our content and the standards zealots just shot them down without really considering the consequences. Instead of making the world safe for a better web, the HTML standards geeks instead did the most powerful thing they could do to prevent it from materializing. In essence, they preserved “choice” at the expense of utility. What a waste. Seriously, if these are the deep thinkers on “our team”, why not go just use Flash to build everything?

Many people have gotten worked up about Microsoft’s role in killing Netscape (although they tend to minimize Netscape’s role in its own demise), but ISTM that the real long-term harm done here has been to remove the renderer as a profit center. Once Microsoft set the price of the browser at “free” they effectively killed browser evolution as part of anything but an OS-based platform play (in part, to preserve their existing OS-based platform play). Interestingly, then, web-based services have routed around the difficulties of the platform to date to deliver apps that seemed well out of reach of HTML 4.01 as implemented by IE 6, but well, we’re a plucky lot, aren’t we? The most progress being made right now seems to be coming from a large software vendor in Cupertino with an OS-based platform play that absolutely needs the web to sparkle in order to drive adoption of their OS and hardware.

Like Linux, the web will probably lurch forward this way for the forseeable future. The standards zealots smacked down the IE team so hard on content versioning that I don’t think anyone else will have the testicular fortitude to try again for a good while. It’s down to the whole “vision thing”, and the web standards crowd doesn’t seem to have any. It’s about time someone took the punch bowl away from them once and for all. The open web needs real progress too badly to stall any longer.

WPF Composite Application Guidance is Live

Brad Abrams — Sat, 05 Jul 2008 16:00:00 CDT

A very common pattern for business focused applications is the "Composite Application Pattern". Over the last few months our P&P team has been working with industry leaders and the product teams in Microsoft to develop an sample application and a framework for building composite applications in WPF.

If you are looking at building a WPF business focused application, you should really check this out.. all the documentation, source code and even unit tests are included!

Check it out! Composite Application Guidance for WPF

Coolidge Park by night [Flickr]

Aaron Gustafson — Sat, 05 Jul 2008 13:00:00 CDT

Aaron Gustafson posted a photo:

Testing Cocoa Controllers with OCMock

Erik Doernenburg — Sat, 05 Jul 2008 11:00:00 CDT

For a few releases the Apple development tools have included OCUnit and many developers have now started to write unit tests. There are lots of tutorials that explain how this is done for the straight-forward cases but there’s one area of testing that has proven difficult on most platforms, and that is testing of the user interface. That said, there are a few things that make this an easier problem to solve with Cocoa and in this post I’ll explain why.

Let’s look at an example. CCMenu is a small application that displays the status of CruiseControl continuous integration servers. As part of adding a new project to be monitored the user has to enter the URL for the CruiseControl server and a combox provides a history of previously used servers.

The same dialog has a matrix of buttons to set the type of the server. Actually, by default CCMenu detects the server type automatically but that’s beside the point. What we’re interested in is the piece of functionality that is responsible for selecting the correct server type for the URL chosen by the user. In our case, this would be Cruise Control Dashboard.

One difference between Cocoa and most other UI frameworks is the fact that the user interface is stored by serialising the objects, rather than generating code. For this reason I’m happy to not insist on test-first for the actual interface. What I do want to test is the code in the controller classes.

Obviously, I could load the serialised objects, locate the elements involved and then use methods such as performClick: to trigger the actions. Sounds convoluted? Yes, I agree. Luckily there’s a better way.

This is a case where testing is tricky because the object under test interacts with objects that are difficult to deal with. In such cases dynamic mock objects have proven extremely useful. A good introduction can be found here and mockobject.com lists papers and implementations. For Objective-C I created OCMock. Let’s look at how this helps us testing our controllers.

Here are the relevant parts of the interface declaration of the controller. Given that I’m doing test-driven development there’s currently no implementation of the methods. I simply created the interface of the controller based on my needs while designing the dialog.

@interface CCMPreferencesController : CCMWindowController
{
    IBOutlet NSComboBox *serverUrlComboBox;
    IBOutlet NSMatrix *serverTypeMatrix;
}

- (IBAction)historyURLSelected:(id)sender;

In my test I want to use mock objects instead of loading the actual user interface. So, in the test setup, after creating my controller, I create appropriate mock objects and set up the controller to use these.

@implementation CCMPreferencesControllerTest

- (void)setUp
{
    controller = [[[CCMPreferencesController alloc] init] autorelease];
    serverUrlComboBoxMock = [OCMockObject mockForClass:[NSComboBox class]];
    [controller setValue:serverUrlComboBoxMock forKey:@"serverUrlComboBox"];
    serverTypeMatrixMock = [OCMockObject mockForClass:[NSMatrix class]];
    [controller setValue:serverTypeMatrixMock forKey:@"serverTypeMatrix"];
}

You notice that I’m using key-value coding to set the variables (outlets). I’m doing this because the variables are not public and at the same time I don’t want to write accessor methods for them.

Now, we can start writing the actual test for the functionality. Have a look at the full test first.

- (void)testSelectsServerTypeWhenHistoryURLIsSelected
{
    NSString *selectedUrl = @"http://localhost/cctray.xml";
    [[[serverUrlComboBoxMock stub] andReturn:selectedUrl] stringValue];
    [[serverTypeMatrixMock expect] selectCellWithTag:CCMCruiseControlDashboard];
    [controller historyURLSelected:nil];
}

What’s going on here? Firstly, I tell the mock object that stands in for the actual combox box that it should stub the stringValue method. This means that when somebody invokes stringValue on this object it will return the string @”http://localhost/cctray.xml”. This is all we’d have done with the real combo box anyway.

Secondly, I tell the mock that stands in for the server type matrix that it should expect that the method selectCellWithTag: is called with CCMCruiseControlDashboard as an argument.

Lastly, I invoke the method I want to test. What happens, once the implementation is complete, is that the code will go the the combo box and ask it for its string value. The first mock will return the stubbed value. Now, the code should do whatever it needs to do to figure out which server type this corresponds to and then set that in the server type matrix by selecting the cell with the appropriate tag, and this is what we’ve told the second mock to expect.

Wait, you might say, we don’t have an implementation yet. So, how does this test fail? It doesn’t yet. We’ll have to tell the mock objects to verify that everything we told them to expect actually occurred, and a logical place for this is the test tearDown.

- (void)tearDown
{
    [serverUrlComboBoxMock verify];
    [serverTypeMatrixMock verify];
}

Strictly speaking, we don’t have to verify the combo box mock because it doesn’t have any expectations but it’s good practice to verify all mocks in the tear down, especially if the same mocks are used for multiple tests. By the way, by default the mocks also have fail-fast behaviour; when they receive a method that wasn’t stubbed or expected, they raise an exception right away. Detecting something that wasn’t expected can be done right way, detecting that something that was expected didn’t occur must be trigger by the user.

Now, if we run this test with an empty implementation of historyURLSelected: it will fail when we tell the server type matrix mock to verify because the expected method hasn’t been called. The error message will look something like this:

Unknown.m:0: error: -[CCMPreferencesControllerTest testSelectsServerTypeWhenHistoryURLIsSelected] : OCMockObject[NSMatrix]: expected method was not invoked: selectCellWithTag:0

Adding an implementation like the following one adds the right functionality and makes our test pass.

@implementation CCMPreferencesController

- (void)historyURLSelected:(id)sender
{
    NSString *serverUrl = [serverUrlComboBox stringValue];
    [serverTypeMatrix selectCellWithTag:[serverUrl cruiseControlServerType]];
}

In summary, testing controllers becomes relatively easy when we follow this pattern:

1. Replace all UI elements with mocks; using key-value coding to access the outlets.

2. Set up stubs with return values for UI elements that the controller will query.

3. Set up expectations for UI elements that the controller should manipulate.

4. Invoke the method in the controller.

5. Verify the expectations.

I find tests following this pattern easier to write and understand than tests that load a NIB file and interact with the actual user interface elements.

Catching up on performance with the SitePen crew

Ryan Breen — Sat, 05 Jul 2008 08:00:00 CDT

There’s been so much going on in the performance space lately that I’ve been snowed under. It’s difficult to know where to begin chronicling all of the progress. I’ll start with a few updates from Sitepen.

Back in April, Kris Zyp had a great article for IBM developerWorks called Ajax performance analysis. The developerWorks crew puts out some great material, and this is no exception. Simply put, it’s one of the best articles I’ve seen on the topic, and it should be required reading for every Ajax developer. He discusses Firebug, YSlow, and some client-side instrumentation techniques.
Old friend of the Perf, Tom Trenka, had a nice post about string operations across browsers in May. One of the more interesting takeaways is with regards to IE7 versus IE6. The net — there’s no longer any justification, if there ever was, for special casing string concat operations for IE.
One of my favorite tools, Firebug Lite, has seen some “>dramatic improvements in the Dojo Toolkit version, as discussed by Mike Wilcox in early June. The features discussed: a popup mode that remembers size and position, ReCSS (so you can reload stylesheets without reloading the app), a DOM Inspector, an Object inspector, and a command line. They’ve definitely taken Firebug Lite a long way past the initial goal of offering a bare subset of Firebug functionality to IE developers.
A few days ago, Mike posted another article — this time with a nice addition to the recent swell of client-side profiling articles. Mike whipped up a nice generic mechanism for tracker client side performance in a cookie to remove some of the tedium from generating a statistically relevant data set in your own browser.
Finally, Alex Russell expands on the concept of lazy loading by creating a stub loader for Dojo. Weighing in at a slim 6kB (gzipped over the wire), this build of dojo.js is just the bootstrap code necessary for loading the main functionality, all of which is deferred until it’s actually called within an application. John Resig posted a follow-up regarding some of the clear downsides of this approach, such as the potential violation of user expectations.

ASP.NET Ajax Roadmap Published

Brad Abrams — Fri, 04 Jul 2008 16:00:00 CDT

Bertrand recently published our roadmap for ASP.NET Ajax.

Our goal is to describe some of the proposed features that we are considering investing in future releases of ASP.NET AJAX, Visual Web Developer, and the ASP.NET AJAX Control Toolkit.
We really appreciate your feedback, so this document is intended as much for you to provide an input to our direction as well as to give some indication of what the teams are investing in.

We'd love to hear your thoughts!

My Clutter is Different

Johanna Rothman — Fri, 04 Jul 2008 13:00:00 CDT

On the long weekends, Mark and I make a concerted effort to clean up the house. That means I have to address all my little piles: go through them, recycle what I can, throw out what can’t be recycled, file others, figure out what to do with the rest. While Mark was helping me bring some of my paper and books downstairs, he nudged me about finishing the living room. “I know you don’t like clutter,” he said. “Yes, but I know where everything is. Besides, you have clutter, too.” “But I don’t like your clutter,” he responded. I started to say, “Yeah, but my clutter is different” at which point we both cracked up.

My clutter is comfortable for me, otherwise I would have dealt with it already.�� You could call my clutter technical debt, and you’d be right. I don’t mind paying it off on long weekends. Otherwise, I would do something about it more often. But the reason my clutter is different is because it fits with my mental model of the world.�� I’m sure when Mark reads this, he’ll try to change my mental models. He’s unlikely to be successful.

These same kinds of discussions occur at work, but we tend to laugh at them less. (Maybe we should.) The next time you find yourself perturbed by someone else’s perspective, consider this question: What would have to be true for the other person to be happy (or content or satisfied) with the situation?�� Partly, my clutter helps me see all the things I do, which is helpful. More clutter does not make it more helpful — there’s a point at which even I think there’s too much clutter. But seeing clutter doesn’t help Mark, and since we share a house, I need to flex a bit. I’ll continue cleaning up now.

On the radio

Richard Monson-Haefel — Fri, 04 Jul 2008 11:00:00 CDT

Just in case you were fortunate enough to miss it, I was on the RIA Weekly radio show yesterday. Actually, The RIA Weekly Show hosted by Michael Cote of RedMonk (a favorite analyst company) and Ryan Stuart of Adobe (a stand up guy) is a great show. Every week they talk about current events in the RIA industry and mix in a good amount of chuckles.

I was the guest on Episode 17. I spoke mostly about Curl and how its different from other RIA solutions. We also spoke a little bit about JSF, SOA, programing languages, and other topics. Over all I think it went pretty well, but its never fun to see yourself on video or listen to yourself on a voice recording. Apparently I do an in-take-of-air after every sentence as if I'm living on a respirator and need to get the mask back on or suffocate.

Where the hell is Matt?

Richard Monson-Haefel — Fri, 04 Jul 2008 08:00:00 CDT

"Matt is a 31-year-old deadbeat from Connecticut who used to think that all he ever wanted to do in life was make and play videogames. Matt achieved this goal pretty early and enjoyed it for a while, but eventually realized there might be other stuff he was missing out on. In February of 2003, he quit his job in Brisbane, Australia and used the money he'd saved to wander around Asia until it ran out. He made this site so he could keep his family and friends updated about where he is.A few months into his trip, a travel buddy gave Matt an idea. They were standing around taking pictures in Hanoi, and his friend said "Hey, why don't you stand over there and do that dance. I'll record it." He was referring to a particular dance Matt does. It's actually the only dance Matt does. He does it badly. Anyway, this turned out to be a very good idea."
- Patrick Drury

See Matt dancing video.

Json-lib: 2 years and counting

Andres Almiray — Thu, 03 Jul 2008 16:00:00 CDT

Yikes! been so busy at work that missed Json-lib's second anniversary by two days. Don't have exact download stats as sourceforge.net decided to give broken links for projects statistics for over a week now, last time I checked we were over the 78K mark

20 releases, 71 bug reports, 72 feature requests, 6 patches, 123 forum messages and countless direct emails we are still up and going strong. Thanks to everybody that has contributed to the project, and to the users too, we wouldn't be here if it wasn't because of you.

“Physical” Request-Scoped Attributes for JSF in Portlets

Scott O'Bryan — Thu, 03 Jul 2008 13:00:00 CDT

One of the more frustrating parts of portal development is the fact that the Portal Specification does not follow good “design by contract” principals.�� One of the more annoying aspects of this deficiency is how the behavior of request-scoped attributes is defined in the portlet specification.

In the servlet world, there is one Request object for each physical request from the the browser.�� This is called a single-phased request.�� Because of their complexity and the need to enable applications to perform better, the Portlet 1.0 specification introduced a multi-phased request in which certain types of requests are run in response to certain types of requests.�� This means that rendering logic can be light and fast in its implmentation while data-fetching logic and processing could be done only when a portlet is the target of its own request.

Although this approach has merit, the Portal Specification does not clearly outline the lifespan of a request-scoped attribute.�� Many portal vendors (quite incorrectly in my opinion) say that items added to the request during the processAction will NOT be available durring the render.�� While other vendors, including the R.I. do preserve these attributes between an action and it’s following render request.�� This means that different containers behave differently depending on their implementation, which is something that directly violates “Design by Contract” principals.

JSR-301 Portlet Bridge’s Take

The JSR-301 Specification tries to address this inconsistency for JSF applications by stating that Request Attributes which are added during a JSF Action phase of the lifecycle, should be available during the following render and all subsequent renders.�� This allows a situation where a JSF portlet which needs to be rendered as a result of another portlet’s action, can simply continue by running the render portions of the lifecycle.�� This behavior happens regardless of behavior and although there may be some challanges in dealing with this nuance, it will remain consistent across portal boundries.

For those attributes that should NOT be around for subsequent renders, like per-request state information, JSR-301 added a special configuration as well as an “@ExcludeFromManagedRequestScope” attribute which allows an attribute to remove itself from this feature.�� For example, let’s say a renderkit stores an attribute on the request which holds a flag telling the renderkit to render in XML (for an Ajax request) rather then html.�� If this bean persisted to multiple requests, you might find that your renderkit would render ajax content directly into your portlet’s window on the portal page.�� This is NOT the desired result.

Where JSR-301 falls short, however, is that it does not enforce any sort of consistency when a bean is excluded from the managed request scope, instead it defers to the logic defined by the portal container.�� As such, attributes which are excluded from the managed request scope suffer from the same implementation-specific problems that the Portlet 1.0 containers suffer from.

The good stuff

There are several ways to handle this situation.�� The first is to make sure that beans are able to be re-created on an as-needed basis, even from a portlet render request.�� This is a challange in a portlet environment because parameters which are passed into the action are not available durring the subsequent render request unless they are explicitly added.�� Furthermore, if the parameters are added, they will be added to every Render request until either a render request is called specifically or until antoher action is called on the portlet.�� In either case, this suffers the same pitfalls as the bridge’s managed request scope, so if your initializaion state is dependent on incomming parameters for your initialization, it will be very difficult for you to manage this manually.

Another approach, and the one which I will concentrate on here, is to develop your own mechanism for preserving request attributes from action to render.�� Before I get started, I also want to make some comments about the code.�� This code it an example which I’m using to illustrate an idea.�� As such, I’m not worrying about thread safety and robustness so much as I’m trying to illustrate an idea.�� If you want a pre-canned solution, I will likely be adding one to the configurator mechanism that I currently have under development, so keep watching this blog for further details.

The code below outlines the usage of a custom FacesContext Decorator.


  public class FacesContextImpl implements FacesContext
  {
    private FacesContext _orig;
    public static final String STATE_NAME = "scottobryan.STATE";
    public FacesContextImpl(FacesContext context)
    {
      _orig = context;
      ExternalContext ec = getExternalContext();
      Map<String, Object> saved = null;
      if(ec.getRequest() instanceof RenderRequest)
      {
        /*
         *First we look to see if we have a stored state
         *For this example I'm using the session but you can
         *use other scopes
         */
        saved = (Map<String, Object>)ec.getSessionMap()
                                         .remove(STATE_NAME);
      }

      if(saved == null)
      {
        saved = new HashMap<String, Object>();
      }

      ec.getRequestMap().put(STATE_NAME, saved);

      //TODO your other logic here
    }

    //TODO all other methods should delegate except release
    @Override
    public void release()
    {
      ExternalContext ec = getExternalContext();
      if (ActionRequest) instanceof ec.getRequest())
      {
        Map<String, Object> state =
         (Map<String, Object>)ec.getRequestMap()
                                  .remove(STATE_NAME);
        ec.getSessionMap().put(STATE_NAME, state);
      }

      _orig.release();
    }
  }

Lines 17 and 18 are responsible for trying to get the state off the session if it exists.�� If it does not then a new state map is created regardless of environment.

Lines 33 to 46 will save the map to the session when the FacesContext is release by the bridge.�� It will only do this on an action request since that’s the only usecase we care about.�� For cleanliness I go ahead and remove it from the request, but an uglier (albeit faster) technique might be to try to leave it on the request so that durring the next render you can figure out whether you are in a container which preserves request attributes and are therefore able to disable this caching alltogether.

The code will make sure that there will be a map stored on the request attributes by the name of STATE_NAME and that any attributes which are appended to it will be available throughout the lifetime of the physical request.�� If you have a container that is not tolerant of non-serializable data on the session (by spec it should be, just not for failover), you can either make all your stuff serializable or you can play around with appending it to the Application scope.

Also, it might be good to be able to encode some sort of id that can be used to tell whether the state belongs to a certain render request or not in case something happens and the render does not follow the action for which is was intended.�� This could happen as a result of a network hickup on a remote (WSRP) portal, but I’m hoping that in such curcumstances portals are able to recover better.

Enjoy!

Across the bridge [Flickr]

Aaron Gustafson — Thu, 03 Jul 2008 11:00:00 CDT

Aaron Gustafson posted a photo:

Links for 2008-07-02 [ma.gnolia]

Aaron Gustafson — Thu, 03 Jul 2008 08:00:00 CDT

Composition

Somewhere in this film is one of my photos of the Sydney Opera House. Very cool short film.

Saved By: Aaron Gustafson | View Details | Give Thanks

Tags: "Sydney Opera House", film, creative commons

Hidden folders in OS X file dialogs

Brian Pontarelli — Wed, 02 Jul 2008 16:00:00 CDT

Found a good shortcut for getting access to hidden folders in OS X file dialogs and the Finder. It requires some typing and it doesn’t auto-complete like Linux does, but it is better than nothing. Just hit Shift-Command-G to open the “Go To Folder” dialog and then type the path to the hidden file or folder. The path can be relative.

Now, just need to figure out how to access hidden files from the Finder and file dialogs.

Compass 2.1.0 M1 Released

Shay Banon — Wed, 02 Jul 2008 13:00:01 CDT

Compass version 2.1.0 M1 released. The release includes several features including a much improved XSEM support (namespace xpath, better stax integration, jdom integration), Dynamic mappings removal and additions, JSEM - JSON to Search Engine Mapping support, and Collocated integration and distributed search with GigaSpaces. It also includes several bug fixes (with the important ones backported to 2.0 branch). Enjoy!.

Where the hell is Matt?

Richard Monson-Haefel — Wed, 02 Jul 2008 11:00:00 CDT

I really needed this today.

"Matt is a 31-year-old deadbeat from Connecticut who used to think that all he ever wanted to do in life was make and play videogames. Matt achieved this goal pretty early and enjoyed it for a while, but eventually realized there might be other stuff he was missing out on. In February of 2003, he quit his job in Brisbane, Australia and used the money he'd saved to wander around Asia until it ran out. He made this site so he could keep his family and friends updated about where he is.A few months into his trip, a travel buddy gave Matt an idea. They were standing around taking pictures in Hanoi, and his friend said "Hey, why don't you stand over there and do that dance. I'll record it." He was referring to a particular dance Matt does. It's actually the only dance Matt does. He does it badly. Anyway, this turned out to be a very good idea."
- Patrick Drury

It’s ok to wet yourself every once in awhile

Andrew Glover — Wed, 02 Jul 2008 08:00:00 CDT

Dan North, the veritable progenitor of behavior driven development (or BDD), recently blogged about unnecessary DRYness (meaning don’t repeat yourself) with respect to clarity of intent when it comes to testing (in generic terms of the word). Essentially, in the case of a JUnit test, for example, by utilizing a setUp method and possibly other helper methods, the test itself becomes somewhat cluttered– one must jump around the code to truly understand the intention of the test in the first place.

In fact, Dan says it quite nicely– tests (or stories, baby) are:

“examples [that] tell a story about what the code does… [and] clarity of intent is found in the quality of the narrative, not necessarily in minimising duplication.”

Thus, over utilizing the DRY principle can be ineffective when it comes to testing; indeed, he makes a great point! If tests or stories are intended to serve as “executable documention” doesn’t it make sense to make them as easy to read and understand as possible?

As such, because it’s my bag, I took the liberty of pondering the depth of favored term DRY and decided that when it comes to clearly expressing intent with respect to stories (as in the case of easyb) or tests, it often pays to be WET– that is, wholly express your tactics, baby.

You see, applying WET to, say, an easyb story then yields perhaps more text, but it leaves no room for misinterpretation, man. For example, imagine a story regarding discounts (this is my touchstone example that is in danger of itself becoming dry– no pun intended either, man). The high level story is such that VIP customers receive varying discounts depending on the amount of money a particular order has– you could even require a minimum number of items too (if you were attempting to move inventory). Thus, one scenario could be:

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
}

Of course, from here, stakeholders, through a collaborative effort, realize more scenarios are possible– for instance, the VIP customer has 3 items totaling over $100– thus, a higher discount is applied. A first stab of staying WET (that is, wholly expressing your tactics, man) yields this scenario:

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
}

Reading these scenarios (which are executable, by the way!) leaves no room for missing the boat– the tactics involved are wholly expressed!!– reading them is somewhat effortless from the standpoint that you don’t necessarily need to jump around the file to gain a clear understanding of context.

If you prefer staying DRY, the story can become more concise–

before_each "a VIP customer with 3 items is assumed", {
  given "a VIP customer"
  and "given they have at least 3 items"
}

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "the 3 items total at least $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
} 

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "the 3 items total at least $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
}

Both stories convey intent– it is just that the WET one is more clearly expressed– in the DRY example, as more and more scenarios are added (and they surely will), one needs to jump to the top to gain an understanding of the underlying assumption (that is, a VIP customer with 3 items in their shopping cart).

DRY is fundamentally a sound principle– I’m not here to deny that; however, like all good things, it can be overused without regard for a particular situation. In fact, Johann Wolfgang von Goethe (of Faust fame, baby) is quoted thus:

“The phrases that men hear or repeat continually, end by becoming convictions and ossify the organs of intelligence.”

Because it is everyone’s bag, baby, think through DRYness from time to time and realize that in some cases, it is perfectly acceptable to WET yourself (I mean, to practice WET). Can you dig it, man?

I also blog at testearly.com | My company is hiring gurus