Pathfinder Blog
Archive: September 2007

One BA’s Shifted Paradiagm: How I Became a BA

Scot Witt, Friday, September 28, 2007 @ 11:42 am

I've been a professional writer for more than 25 years- heck, I was stringing for the local newspaper when I was in high school. I spent the first 25 or so years post high school in the wunnerful world of Radio News. Then I figured it was a. time to get out of a dying industry and b. make enough scratch to help the kids through college.

So I spent 18 months on a help desk. Ugh. I have all the respect in the world for those special people than have the patience. I realized I don't. Anyone that 'names' their 'hard drive' Freddie seems a bit off to me.

So I took my minimalist technical skills (I am an amateur radio operator and had been playing with 'puters since the first TRS-80 came out- was the first on my block to have a Radio Shack Color Computer, connected to a black and white portable I traded for a 30-30 rifle I knew I'd never use) and my writing skills and declared myself to be a Technical Writer.

Wasn't hard. Except for Word. The organizational abilities and putting one word after another is pretty much the same.

Instead of story telling, I was writing incredibly difficult to understand Step Action Tables with Slot B and Post 34 merging into Compressor Cylinder 2 output going into the PDF to create an audit trail for  the Content Manager component of the  WinNT4.0 Server Security Accounts Manager.

There's a reason technical writers are a dime a dozen. In my experience, many can't write their way out of a paper bag. Many of the really good ones reinvent themselves. I always stayed with the really good ones. And I watched, read and asked for help when I didn't need it but wanted another point of view.

So I was consulting as a 'Content Manager' (read: Metadata Classifier), which was about 10 bucks more an hour than a tech writer gig. Momma didn't raise no dummy.

At a couple of application design sessions I noticed a couple of people who called themselves Business Analysts. They were very well dressed. Had nice shoes. I asked around. They made $20-$50 more per hour than I did. And they weren't bored.

I'm in.

  • I read about UML. Process. Modeling. Seems pretty straight forward- that's what writers and tech writers do.
  • I wrote a few cost-benefit analysis papers. Templates. They work!
  • Use Cases- hmmm. Need another book.
  • Action Diagrams- VISIO is a wonderful application.
  • Iteration. Yeah, makes sense. If at first you don't succeed...

Kewl. Now I Are a BA.

Some observations as a BA on a few projects:

  • SMEs (Subject Matter Experts) don't seem to think their company spending 34 gazillion dollars (that's a real place holder- a 1 followed by a jillion zeros) for an application is really that important to them. Which means I don't get all the requirements- no matter how many questions I ask, how I ask them or search the company's archives.
  • Nobody seems to think my Use Cases and fancy schmancy VISIO diagrams are important. So they ignore them. I don't get sign off.
  • Um, why, oh why, does the manager in  charge of part of the project keep coming up with new stuff she wants? Who is she talking to and how do I find a ninja when I need one?
  • Hey! Mebbe you forgot to tell me you needed an interface to the U.S. Department of Heavy Handed Security, but the week before deployment is not the right time to tell me!
  • Am I the only one who thinks four months planning the first phase of the project is, I dunno, excessive? Do we really need to dot all these i's? As long as we identify traceability to the requirements, isn't that enough?
  • If the customer has the domain knowledge. And the Development Team has the technical knowledge. And if both sides want the application to work and work well, why is everybody pointing fingers at the requirements documents and the Statement of Work? They all signed off on them, didn't they? See second bullet.

Well, Bunky, some smart guys realized that and didn't tell me about it until I got my current job.  No, it's not a panacea. But it works a lot better for medium and smaller applications.

And no one points fingers.

Because we're all on the same team.

It's called Agile.

Next up, coaching a UML-guy into Agile.

Technorati Tags: , , , ,

Powered by ScribeFire.

tech development Tech Development

Wiki? I Don’t Need No Stinkin’ Wiki!

Scot Witt, Friday, September 28, 2007 @ 11:41 am

So my first project here at PathFinder Development is to move an existing application from .NET 1.0 to 2.0. Seemed simple.

I started the usual As-Is Decomposition modeling while looking at the existing application.

It turned out to be a prototype that didn't type.

Hmmm.

OK, abandon As-Is and concentrate on To Be.

The Functional Requirements template worked just fine in Word. Everybody loved it. Everybody thought it was real snazzy. Of course it was. I'm the English Major Alice referred to in her fine blog on Design.

Everybody, that is, except our Technical Architect.

"I want you to put this on our wiki," he said calmly.

????

"And we'll all be able to edit it."

!!!!

I'm the document master on this project, Mister. I determine what the developers see and how they see it. I create the catalogs, baby. I talk to the customer, dude- keep the developers behind that curtain- they might pull out a slide rule when the suits are around. I'm the technical to business and business to technical translator, fella. I run the JAD sessions and the interviews, pal.

Well. I've only been here a coupla weeks. And they're payin' me real good. And they seem pretty smart...

So as I was groaning and moaning learning the new tool, and doing it over to the technical guy's satisfaction (who ever allowed a developer or Technical Architect to have an opinion on formatting and word use? You ever try to read one of their documents?).

And then did it again to satisfy the slave driver.

The he rubbed salt into the wound by telling me to add <previous> and <next> links at the bottom of each page.

I tricked him.

I looked at the mark-up language for our instance and found some cool tags that generated them automatically. Hah!

If I post this, I thought, and anybody on the team can edit it, what the heck do they need me for? Mebbe it's time to get the old resume revised, even though I've only been here a few weeks.

"You'll write the Functional Specifications and we'll all edit them as we develop the feature," My team-mate turned Agile Coach told me.

Oh. I'll add the use cases, data maps and controls to these 'Specifications.' Yeah, I can see how that'd work.

"No, we don't long use cases that no one will read- plop in some activity diagrams, we'll list the use cases as 'scenarios' and you read up on User Stories."

!!!

"Agile is 'just enough' documentation," he said patiently, "Read up on that, too."

$%^#@!

My hesitant, but analytical hold on the world started caving in.

None of my closely held writing, analysis or PM skills were being used, much less valued, in this Agile stuff. 

It was akin to moving from the world of daily journalism into a help desk- all the moves and instincts I used in news were, at one fell swoop, totally and absolutely wrong.

  • I know UML I cried out.
  • I can split a 45 page Use Case into 13 different documents and set them all at different levels!
  • I can create To-Be and As-Is Decompositions PowerPoints that make people cry!
  • My Vision and Charter documents are so clean there no one sues anyone else, I declaimed.
  • My VISIO charts are animated art works fer gosh sakes with drop shading and colored boxes so the executives has something in color to look at.

Then I started to read. I like getting paid regular.

I started with the Manifest for Agile Software Development.

  • People oriented. Hmmm.
  • Working Code? Never been on a project that actually worked the first time to the customer's satisfaction.
  • Actually listen to the people who use it? I've been demanding that since I started this BA stuff.

Not bad.

Went to the links.

  • Iterative- excellent- works best that way.
  • Feature driven with add ons as able- just the way I've designed in the past.
  • Self-organizing? Only high level folks? WOW!

Cool.

Got me some books.

  • Good for small to medium sized projects- coordination and traceability issues otherwise, makes sense
  • Scrum? Who invented that word? Oh. Rugby. Nasty game. Ah, everyday status/obstacles/plan- good idea.
  • Prototyping with actual code? Great Idea.
  • User Stories? Hmmm. makes a lot of sense- after all, we're not gonna use this...

Excellent.

But no mention of the need, want or value added to the Agile Team by a Business Analyst or User Experience except for some upfront JAD or interview work in Iteration Zero.

"That's because they had customer buy-in at the start with dedicated, empowered customer buy-in," The suddenly wise and no longer job threatening Agile Coach explained, "You're gonna do much of that with interaction with Subject Matter Experts and our User Experience team member as we implement this feature."

Um, How do we handle Scope Creep?

"We only deal with the feature we did last week (bug fixing), what we're working on now (design, specification and code) and what we're going to do next week," My Agile Coach explained, "And we let the visionary blog, add to the wiki in a Blue Sky section to his/her heart's content, but we only deal with that stuff as we begin designing that feature."

Mark Twain was right, your father seems like the biggest dope in the world when you're 18 and you become amazed athow smart he became in 7 years when you're 15. This turn around only took a month or so.

Ah. Thank you Sensei.

Next Up: My First Agile Project's Process Flow

Powered by ScribeFire.

Topics:

tech development Tech Development

Developer’s Notebook: Mastering (your fear of) regular expressions

Brian Dillard, Friday, September 28, 2007 @ 8:17 am

Regular expressions are one of the most difficult programming concepts for novices and journeymen to wrap their heads around. Take a look at most any blog posting about RegExes and the comments will invariably be littered with words like "hate," "pain" and "AAAAARGH!"

Once you get comfortable with them, though, regular expressions become one of the most powerful tools in your programming arsenal. For Ajax/JavaScript developers, they can lend power and elegance to everything from form validators to keystroke interpreters to JSON, CSS and DOM parsers - in short, many of the thing you'll want to do on the client side of any powerful webapp. Take a look under the hood of any respected Ajax/DHTML library and you'll see RegEx literals being used liberally.

It's no secret that I'm big on programming books, especially O'Reilly ones, but I can think of few books that have been more useful than Jeffrey E. F. Friedl's "Mastering Regular Expressions". One difficult aspect of JavaScript regular expressions is their syntax, which is completely different from the better-known Perl variety. Friedl steps back from the implementation details of individual RegEx engines to explain the central concepts common to them all. After having this book for a year, I still refer to it so often that I can't say when I'll be ready to graduate to Tony Stubblebine's "Regular Expression Pocket Reference." In the meantime, when I'm away from my copy of the Friedl book, there are plenty of online resources to guide me.

Cheat sheets & quick references

These links don't offer really in-depth tutorials, but they do show you the JavaScript RegEx syntax at a glance.

Interactive terminals

Apparently, everybody and their mother decided to build a little DHTML/Ajax app to let you create regular expressions, run arbitrary text against them, and check out the results. This is a fantastic way to play with the technology and get more confident in your abilities. Here are 9 different implementations of the same basic idea. I haven't used all of them, so let me know in the comments which are most useful.

And for the over-achievers

For those of you so advanced in your RegEx powers that you've hit the limitations of the built-in JavaScript implementation, check out XRegExp, an open-source regular-expression library that supports named capture and other advanced features.

Technorati tags

Topics: , , , ,

agile ajax Agile Ajax

Scriptaculous and Why ‘extends’ is Evil

Dietrich Kappe, Thursday, September 27, 2007 @ 12:03 pm

The extends keyword is evil—maybe not at the Charles-Manson/Vlad-the-Impaler level, but bad enough that reputable designers don't want to be seen in public with it. The Gang-of-Four Design Patterns book is, in fact, largely about replacing implementation inheritance (extends) with interface inheritance (implements).

-- Allen Holub, Holub on Patterns: Learning Design Patterns by Looking at Code

Holub can be a bit controversial in OO circles. He throws bombs like "getters and setters considered harmful." Not everyone likes or respects him, but beneath some of that hyperbolic language, he makes some good points. Some of the arguments he makes about OO in general, and Java in particular, can easily be applied to the world of JavaScript and Ajax libraries.

Take Scriptaculous and Prototype, for example. Because JavaScript is missing some of the syntactic sugar for traditional declarative OO programming, many utility libraries take as their first task the creation of functions that make creating class hierarchies much easier. With this tool in hand, like a novice Java or C++ programmer on a bender, everything is inheritance. Everything.

Now I like using Scriptaculous, but Object.extends makes far too many appearances in it for my taste. Pretty much every effect is implemented by extending Effect.Base. The only exception is Effect.Parallel, which allows you to compose two simple effects. The resulting code is somewhat messy and difficult to modify, since the design mixes two different concerns in a single object: the scheduling of the effect and the actual DOM modification that achieves the effect.

Having started the porting of Scriptaculous to GWT (GWTaculous), I was very tempted to replace inheritance with something like the Command pattern, essentially composing the scheduling part of the effect with the DOM modification part, as mentioned above.

Right now, changing Effect.Base is extremely difficult, as doing so would break all of the effects subclasses (the Fragile-Base-Class problem, as Holub calls it). A clearly defined command interface would simplify that immensely.

There is good news on the horizon, however. Some JavaScript/Ajax libraries are starting to show a little more OO sophistication. Take Ext JS. In Ext JS, the behavior of widgets and components can be modified through the composition of different objects. To have a data grid widget, for example, retrieve it's data from a file, a static JSON structure or an Ajax call, all that is necessary is to pass an appropriate object to the widget that implements a well-defined interface. No extends necessary. Nice.

So, when writing frameworks or even a large application or library in JavaScript, view extends with mistrust. Most times, there is a better (in OO terms) way.

Technorati Tags: , , ,

Topics: , , ,

agile ajax Agile Ajax

Busy. Busy. Busy.

Alice Toth, Wednesday, September 26, 2007 @ 6:24 pm

I've been a tad bit busy lately starting up one project and entering the UAT phase of another. More importantly, though, I'm still alive in my Pick a Loser football pool (for those of you keeping track, Arizona kept me in the game). In the meantime, here are some links you may or may not find interesting -- click away at will:

  • Too often, implementing search engines within a project are an afterthought rather than a well planned feature. Read up on Strategies for Improving Enterprise Search to prevent having a "neglected orphan" in your project.
  • Not sure how to break it to the Marketing Director that the approved brand colors just don't translate well on the web? Don't Let Branding Kill Your Brand gives you some useful discussion points for extending the brand experience.
  • It's all about the Experience, my friend. Peter Merholz explains it best in Experience IS the Product.
  • Designers Rule! 'nuff said.

user experience design User Experience Design

JavaScript style and the art of anal retention

Brian Dillard, Wednesday, September 26, 2007 @ 8:01 am

Years ago, in a former life, I was not just a journalist, but the worst kind of journalist: a copy-editor. I was paid to rewrite other people's copy, often while they were sitting next to me, so that it conformed to a set of stylistic conventions. Copy had to follow, in descending order of importance, the stylebook of whatever publication I actually worked for, the Associated Press stylebook, and standard grammatical rules.

The theory behind copy-editing is that convention is good even when it's arbitrary: "gray" rather than "grey" even though both spellings are listed in the dictionary. The more consistently a given publication handles specific ambiguous cases, the easier that publication is to read - or so the theory goes. ***

Software development, especially in a large, shared codebase, can work a lot like a newsroom: Project leads function like desk editors, technical leads like copy editors, code reviews like editing sessions, and releases like print runs. The big difference with code is that it will get rewritten repeatedly even after it's "gone to press."

When I sit down to extend other people's code, I find it difficult to dive in until I've cleaned things up a bit. I don't fix bugs. I simply reformat the code so it looks more like my own. With JavaScript, I move braces around, tweak the commenting style, rewrite certain if-then-else statements using the ternary operator, and so on. Ideally, none of this affects the functioning of the code. It simply makes the code easier for me to read, understand and extend. It puts it into my vernacular.

None of that would matter if I didn't have to check the edited code back in after I was done. Once somebody notices that you've altered non-functional attributes of their code, they can get a little peeved. Back in my Orbitz days, we tried to cut off any discussion about such issues by intoning, "Tabs vs. spaces! Let's move on!" Indention style is the most basic code-style decision, but it's practically a religious issue. There's no way of proving that your side is right. It's a matter of faith, so why waste time arguing? The same goes for most other arbitrary stylistic tics. IDEs, with their auto-format options, help ease this kind of conflict. But if you're an adherent of, say, Hungarian notation, you're still going to get caught up in some pretty endless debates.

When it comes to JavaScript, some stylistic tics aren't so arbitrary. Subtle changes in our coding style can improve not just readability, but also shelf life, cross-browser compatibility, and ease of minification. Several brand-name JavaScript authors and projects have weighed in with style guides. Some follow the AP stylebook model: seemingly arbitrary commandments. Douglas Crockford provides more context than most with his Strunk & White-inspired "Elements of JavaScript Style" (in two parts: 1 and 2). But the Mozilla and Dojo folks certainly have a lot of good advice.

Are all of you JavaScript authors aware of these resources? If so, which do you find most useful? Which are worth following slavishly? Which need to be ignored? Personally, I find all of these examples useful because they force me to think about my own coding conventions - many of which I picked up unconsciously - and decide which ones actually add value rather than simply manifesting my anal-retentiveness. Understanding these guidelines is like studying the source code of third-party libraries. It helps you see how other people are solving the same problems you're facing.

Here are the links:

*** Incidentally, that's why most newspaper journalism does so many
weird things consistently, such as putting all modifiers before all
helper verbs. The phrase "already had been working" may be harder to
read than "had already been working," but it's easier to codify in
absolutes. What was that about "the hobgoblin of little minds"?

Topics: ,

agile ajax Agile Ajax

Word Begone: A Brand New Way to Document Requirements

Scot Witt, Tuesday, September 25, 2007 @ 8:54 am

So I grab my project notebook and amble into my first Agile Modeling session. I think me and my templates are ready. I read a coupla web pages on Agile and this should be a snap

What was that word? Hubris, yeah.

I had spent months getting those Word, Excel and PowerPoint templates ready- from the ones I stole (er, um, ah 'folk processed' as we folk music aficionados call it) to the ones I had to create myself.

Even today, I have my security blanket templates on my laptop and safely archived at home:

  • Four versions of Vision/Charter documents
  • Two Cost Benefit Analysis Finding templates
  • Six Use Case Templates of varying color and table divider thicknesses
  • Four Business Rule documenter boilerplates
  • Three Excel Project Trackers
  • Five model Project files
  • Three Business Rule/Use Case Catalog blanks
  • A wide variety of VISIO stencil items
  • Two Decomp templates (on for PowerPoint and another in Word)
  • Functional Requirements boiler (To Be and As Is States- a secret- you can use the same template for both!)
  • A couple of horrendous templates that include one each of the above in monstrous detail.

As I sat in my first Agile session and discussion with our new Agile Coach, every instinct, every pat answer and smart alecky comment I usually make were absolutely, positively wrong:

On an Agile Team:

  1. The weeks long process of generating a mound of paper or lots of files on a network share are over, Amigo. Both the Business and the Dev side only want 'just enough' documentation. Napkin diagrams, digital pictures of the white boards are fine. ('Horrors, developers actually writing stuff?' I thought to myself.)
  2. The BA doesn't 'own' anything- it's sort of like Developer Socialism- everybody has a piece of the action and my not-yet-written documents. ('So, like, what the heck do I do?' I whined to myself)
  3. There ain't no catalog of use cases- you can do the same thing with three line User Stories. 'User Stories? Yuh mean the customer actually does something other than yell at us?')
  4. The developer actually talks to the end user! No translator (me, BA, out of job, must find waterfall/UML gig, soonest)

And none of those kewl templates and fancy-schmancy colorized customer-eye-popping stuff will ever be used.

Because we're putting all of this stuff on a wiki, the Coach told me.

I said, God Bless You.

I didn't sneeze, sez he.

That's what worries me, I responded.

Next Up: I use Word for the last time professionally.

Powered by ScribeFire.

tech development Tech Development

The painful art of prognostication

Brian Dillard, Tuesday, September 25, 2007 @ 7:35 am

They say science fiction is rarely actually about the future; it's really an exploration of present-day fears and anxieties, interrogated through a metaphor of the future. William Gibson himself - the father of cyberpunk - has given up the future in favor of exploring our technological present in compelling novels such as Pattern Recognition and the brand-new Spook Country.

I couldn't help but think about science fiction when I read this "strategy letter" by Joel Spolsky of "Joel on Software" fame. Spolsky looks at a number of current trends in the Ajax world, draws parallels between them and the original emergence of desktop computing, and concludes that the future looks a lot like Windows. In Spolsky's vision, one or two powerful Ajax toolkits will become the de facto new platform/operating system for the next era of application development.

I cry bullshit not because Spolsky's discussion is illogical or ill-informed, but because it's presented with such certitude. If my time in the blog echo chamber has taught me anything, it's that the guy who seems most sure of himself is probably the one blowing the most hot air. Folks have an insatiable appetite for strong opinions, repeated loudly. Everybody wants to know what the future will bring. But the best most commentators can hope for is to surf the currents of the present and catch of peek at what's beyond the next wave. Extrapolating a bunch of disparate trends 5 or 10 years into the future is just an exercise in rhetorical prowess. Joel's a great storyteller, but like most storytellers he's primarily interested in spinning a great yarn. By all means give his theories a whirl, but don't expect capital-T Truth. Nobody can tell the future. To believe otherwise is science fiction.

1984 is a powerful book precisely because Orwell didn't have to make a lot of shit up. He had Nazi Germany and the Soviet Union under Stalin as models for what he was doing. He only had to dress it up a little bit, sort of pile it up in a certain way to say, "this is the future." But the reason it's powerful is that it resonates of history. It doesn't resonate back from the future, it resonates out of modern history. And the power with which it resonates is directly contingent on the sort of point-for-point mimesis, like sort of point-for-point realism, in terms of what we know happened.

--William Gibson, via Boing Boing

Topics: , ,

agile ajax Agile Ajax

Rails, Ajax, RJS, and Testing

Noel Rappin, Friday, September 21, 2007 @ 3:03 pm

As promised, today’s entry is Agile and Ajax. Also, it’s a dessert topping.

Ajax in Rails

The initial support for Ajax calls in Rails was centered on two framework methods called link_to_remote and remote_form_tag. The basic functionality of these methods is to allow a remote call to be triggered by a link or form submit and have the result of that call be used to update a DOM element somewhere on the page.

Moving outside that simple behavior, however, quickly got messy. Both methods specify a series of callbacks where arbitrary JavaScript can get implemented at various points in the call life-cycle. However, writing dynamic JavaScript in an ERB template is awkward, and the resulting method calls could get ugly.

Enter Ruby JavaScript (RJS), sometimes described as “training wheels for JavaScript”. RJS allows a very simple subset of JavaScript to be written in Ruby and translated to JavaScript as the result of a Rails Ajax Request.

Here’s what a sample RJS template looks like:

page.visual_effect(:fade, 'recipes_to_show',  :duration => 0.5)
page.visual_effect(:fade, 'category_being_shown', :duration => 0.5)
page.delay 0.5 do
page.replace_html("category_being_shown",
"Recipies For: #{@category.capitalize}")
page.replace_html("recipes_to_show", :partial => "recipes")
page.visual_effect(:appear, 'recipes_to_show', :duration => 0.5)
page.visual_effect(:appear, 'category_being_shown', :duration => 0.5)
end

The page variable is automatically provided by Rails and represents the page that is going to receive the JavaScript. There are about a dozen or so instance methods that page can receive, mostly having to do with the basic Ajax-y features of replacing HTML in a DOM element and calling Scriptaculous visual effects. This particular snippet fades out two elements, changes their text, and fades them back in for a crossfade effect.

(There’s a certain similarity of concept with Google Web Toolkit, but RJS is going after a much smaller and more focused piece of functionality, optimized towards what you would do in a single Ajax call in an otherwise standard interface. GWT, on the other hand, is trying to be the entire application on both the client and server side.)

How useful this is depends on your relative level of comfort with Ruby and JavaScript. I’m personally much more comfortable in Ruby, so I think this is just great. It’s especially nice since I can use Ruby blocks to abstract this crossfade function into something I can use generically.

def crossfade(page, *dom_ids)
dom_ids.each do |dom_id|
page.visual_effect(:fade, dom_id, :duration => 0.5)
end
page.delay 0.5 do
yield
dom_ids.each do |dom_id|
page.visual_effect(:appear, dom_id, :duration => 0.5)
end
end
end

The generic function takes a list of DOM ids and a block — the assumption is that all the content changing will be managed in the block. So the original snippet would now be changed to:

crossfade(page, 'recipes_to_show', 'category_being_shown') do
page.replace_html("category_being_shown",
"Recipies For: #{@category.capitalize}")
page.replace_html("recipes_to_show", :partial => "recipes")
end

If you’re feeling more adventurous, you can patch the crossfade method directly into the JavaScriptHelper class and change the call to page.crossfade, making it more consistent with the other calls performed in an RJS template.

Testing RJS

Now for the Agile portion — how do you test this thing? RJS templates can be tested pretty thoroughly based on the content of the JavaScript code being generated. It’s much harder at the moment to test based on the actual results of the JavaScript — for example, it’s hard to test that the DOM elements being referenced actually exist in the client page.

There are two mechanisms for testing RJS that I’ve found useful. The first is mock object testing. Using the flexmock package to set up the page as a mock object, a sample test for the crossfade method looks like this:

def test_crossfade
page = flexmock("page")
page.should_receive(:visual_effect).with(:fade, "dom_1", :duration => 0.5).once.ordered(:first)
page.should_receive(:visual_effect).with(:fade, "dom_2", :duration => 0.5).once.ordered(:first)
page.should_receive(:delay).and_yield.once.ordered
page.should_receive(:replace_html).once.ordered
page.should_receive(:visual_effect).with(:appear, "dom_1", :duration => 0.5).once.ordered(:last)
page.should_receive(:visual_effect).with(:appear, "dom_2", :duration => 0.5).once.ordered(:last)
crossfade(page, "dom_1", "dom_2") do
page.replace_html()
end
end

Without going into the details of flexmock because, hey, future blog post, the idea is that the mocked page object keeps track of the method calls it receives and checks them against an expected set of method calls. In this case, I’m telling the mock object that it should get two calls to the visual_effect method with various arguments, and that those calls should come before the other calls.

The interesting thing about this method is that on the face of it, it contains no assertions. Implicitly, though, each should_receive call sets up an assertion about the messages coming to the object that is validated at the end of the test.

The other mechanism uses a plugin called ARTS (Another RJS Testing System), which defines a method called assert_rjs, which checks the outgoing JavaScript for a method call matching a set of parameters.

Using ARTS, the following method tests whether an individual DOM element is in the crossfade:

def assert_crossfade(dom_id, replacement)
assert_rjs :visual_effect, :fade, dom_id, :duration => 0.5
assert_rjs :visual_effect, :appear, dom_id, :duration => 0.5
assert_rjs :replace_html, dom_id, replacement
end

And a full test of the example would look like this:

def test_one_crossfade
assert_crossfade 'recipes_to_show', /Recipe/
assert_crossfade 'category_being_shown', /Category/
end

The replacement argument can be either a string, in which case the output needs to match exactly, or a regular expression, in which case a Regex match is performed. In general, assert_rjs works by recreating what the JavaScript looks like from the assert call, and checking the actual output for the existence of that call. Again, this is most helpful when you can bundle calls together in a single assertion.

ARTS is a nice little plugin, and it does let you do some syntactic testing of your RJS templates, but semantic testing along the lines of, is the recipes_to_show element visible at the end of the RJS and what text is actually in the element is still elusive. I think that’s doable, but it would require a much more complex mock object representing the page, one that keeps track of a pseduo-DOM tree and can manage at least some of the effects of RJS calls. Another project for another day…

Topics: , , , ,

agile ajax Agile Ajax

Developer’s Notebook: Forward-thinking CSS float-clearing

Brian Dillard, Friday, September 21, 2007 @ 8:11 am

The art of float-clearing - getting containers to honor the height of floated elements inside of them - has slowly evolved over the past several years as Safari has taken over many Mac desktops, IE5/Mac has atrophied, IE7 has slowly caught on, and our use of CSS filters has improved. I'd like to share a slight variation on the state of the art that I believe makes for much cleaner markup. But first, a little background.

How we got here

Several years ago, Tony Aslett of csscreator.com convinced us to stop using clearing our floats using this sort of junk markup:

<div id="container">
   <div id="rail" style="float: left;"></div>
   <div id="content" style="float: left;"></div>
   <br style="clear: both; height: 0; visibility: hidden;">
</div>

His solution, popularized on Position is Everything, convinced us to use pure CSS to solve the problem:

.clearfix:after {
    content: ".";
    display: block;
    height: 0;
    clear: both;
    visibility: hidden;
}

.clearfix {display: inline-block;}

/* Hides from IE-mac \*/
* html .clearfix {height: 1%;}
.clearfix {display: block;}
/* End hide from IE-mac */

<div id="container" class="clearfix">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The advantage, of course, was that you didn't have to litter your markup with extra <br /> tags that would eventually become totally useless once the state of the art changed.

Where we are now

For sites that have dropped support of IE5/Mac and adopted support of IE7, the recent concensus on float-clearing has been something like this (using the same markup as above):

/* float clearing for IE6 */
* html .clearfix{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html .clearfix{
  min-height: 1%;
}

/* float clearing for everyone else */
.clearfix:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

And now, a slight refinement

Which leads me to a technique used at Orbitz, my previous employer, to apply the same methodology with even less impact on the markup itself. Instead of declaring a single clearfix class and then applying it to countless containers inside their XHTML, the Orbitz UI team uses a grocery list of CSS selectors, like this:

/* float clearing for IE6 */
* html #container,
* html .classThatNeedsToBeCleared,
* html div.anotherClassThatNeedsToBeCleared,
* html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  height: 1%;
  overflow: visible;
}

/* float clearing for IE7 */
*+html #container,
*+html .classThatNeedsToBeCleared,
*+html div.anotherClassThatNeedsToBeCleared,
*+html #someDiv .someClass .yetAnotherClassThatNeedsToBeCleared{
  min-height: 1%;
}

/* float clearing for everyone else */
#container:after,
.classThatNeedsToBeCleared:after,
div.anotherClassThatNeedsToBeCleared:after,
#someDiv .someClass .yetAnotherClassThatNeedsToBeCleared:after{
  clear: both;
  content: ".";
  display: block;
  height: 0;
  visibility: hidden;
}

<div id="container">
    <div id="rail" style="float: left;"></div>
    <div id="content" style="float: left;"></div>
</div>

The idea here, of course, is that each time you have another container that needs to be cleared, you add browser-specific selectors for it to each of the three blocks above. Suddenly, there's no need to apply a utility class to a zillion different nodes in your HTML. Instead, you apply the same CSS rules to a bunch of atomic CSS selectors. Voila: float-clearing with absolutely no impact on markup. Presto: a solution completely centralized in a single block of CSS code, so that it can be changed in one place as the browser landscape evolves.

(Props to Gena Wilson, Orbitz's CSS headmistress extraordinaire, for constantly synthesizing elegant solutions like this one.)

Final side note: As long as folks are going to keep griping about missing items from their CSS wish list, could we please just eliminate the need to clear floats altogether? I know that the need to clear floats isn't actually a bug, according to the WC3, but it should be. I can't think of a single time I've ever _not_ needed to clear my floats. Can you? Tell me in the comments.

Topics: , ,

agile ajax Agile Ajax

iPhone and Air Travel

Alice Toth, Friday, September 21, 2007 @ 12:10 am

I just might need an iPhone. Let me back up a bit. When the iPhone debuted, our CEO purchased one for the office so we could take turns using it, playing with all the features, admiring the GUI and generally looking cool at the local neighborhood hangout. I loved it but not enough to buy for various reasons (couldn’t use one hand to hold and type, didn’t fit in jeans pocket, too nice to just throw in the bottom of my purse, no iChat). So, I looked cool for a weekend and then turned back into regular me come Monday.

Well, the other week I was 'lucky' enough to once again experience early 21st century air travel which, as you know if you’ve traveled lately, means delays, delays, delays. The plane is late, the crew didn’t show up, the gate changed, the gate changed again, it’s sunny outside, it’s the third Tuesday after the fourth week following the geese flying south, etc, etc.

Luckily I was traveling with my CEO who had the foresight to bring the iPhone. Which led to my iPhone epiphany: when you’re stuck on the tarmac hoping that #49th in line isn’t really as bad as it sounds, surfing the web is a much better distraction than counting the planes as they’re taking off. And surfing the web on a cool device just adds to the sweetness.

Thanks to the iPhone and EDGE network (as slow pokey as it is), even when sans wifi I can still waste a considerable amount of time checking email (personal not work), checking faa.gov (for further delays), catching up on some reading (love Safari Books), using the widget to check random cities forecasts (because I can) and generally doing most anything to avoid pulling out my laptop and doing meaningful work. Beautiful! If I continue to travel (which really means sitting on tarmacs bored to tears), I just might have to pull out the old credit card and contribute to Apple’s bottom line.

For an actual review of the iPhone, check out what my colleague had to say.

Technorati Tags:

user experience design User Experience Design

6 More GWT Tutorials

Dietrich Kappe, Thursday, September 20, 2007 @ 10:59 am

Since posting 36 GWT Tutorials, a few more have made their way onto the web. Many of these are more sophisticated than the last batch, developing non-trivial example applications, a sign that GWT development is maturing:

  1. GWT and OpenLayers integration - OpenLayers is an open source GeoServer, sort of an OpenSource google maps. The tutorial demonstrates integrating GWT with OpenLayers using Eclipse. Lots of code and screen shots with a simple working application at the end.
  2. Screencast Tutorial for GWT-RPC in Eclipse - if you learn better by watching someone drive and IDE, you can follow along as someone uses GWT 1.4.10 to create and extend a simple GWT-RPC app in Eclipse (3.2).
  3. Integrating XForms with GWT - another in a series of quality tutorials published at IBM's Developer Works. What are XForms? XForms 1.0 defines a device-neutral, platform-independent set of form controls suitable for general-purpose use. They are implemented in Mozilla Browsers (Firefox, etc.) through XUL. So, marrying XForms and GWT.
  4. Simplifying Ajax development using Cypal Studio for GWT - pointed out to me by my colleague Noel Rappin. Cypal studio is a plugin for Eclipse that simplifies common GWT tasks.
  5. Building an Offline Salesforce Application with GWT and Gears - integrating Google Gears, Apache Axis, GWT and Salesforce.com. If you want to see how to build a non-trivial application that stretches the bounds of Ajax and the browser, this is an excellent tutorial.
  6. Creating a GWT War File in Eclipse - really more of a recipe than a tutorial, but still useful.

If you know of any other new GWT tutorials, feel free to add them in the comments.

Technorati Tags: , ,

Topics: ,

agile ajax Agile Ajax

Get in the Flow (Task Flow that is)

Alice Toth, Wednesday, September 19, 2007 @ 12:40 pm

Call them what you like (task flows, work flows, process flows), flow diagrams are an important part of any software project. As a developer, you may be more familiar with sequence diagrams, a nifty way to visualize an exchange of messages between different processes and the order in which they occur.

Well another useful diagram is the end-to-end task flow. This handy dandy diagram shows all the steps necessary for a user to accomplish a task. Buy a pair of shoes? Select shoes, select size, add to cart, go through checkout process. Simple and easy.

And yet, what is it really telling you? Well, a flow diagram gives you an overview of the end-to-end process, the start to finish if you will. It lets you know what the user needs to do in order to start a task (select those really cool shoes) and what defines that the task is completed (display order confirmation). In between those two points are all the necessary steps to go from start to finish.

Shoeflowbasic_3

Initially, the in betweens are very high level (as evidenced by the above diagram). As more information becomes available, the flow is modified, added to, subtracted from and generally redrawn to show not only the user tasks, but also the system tasks (return error message, validate and continue), alternative routes (continue shopping, display upsell message) and decision points.

Shoeflowenhanced_3

I've found flow diagrams to be very helpful because they let team members know how their stuff fits into the big picture. Let’s face it, on most projects the end-to-end flow is never developed lineally by one developer. Instead, it’s broken down into pieces and parts and assigned to various people. Seeing the end-to-end diagram up front gives you the overall picture of how an entire feature will play out and, more importantly, shows you how and where your piece fits into the whole. It'll get you thinking about potential points where code can be reused (sweet!) or better ways the data can be used at the presentation layer.

End-to-end diagrams let you see that what you're working on is no longer a lonely story in isolation, but rather something that’s part of a defined sequence that contains a beginning and middle and end. It ties what you're doing into the whole and brings a coherency to the process. This is especially valuable for large features that are spread out across teams and even iterations.

Technorati Tags: , ,

Topics: , ,

user experience design User Experience Design

Really Simple History now live at Google Code

Brian Dillard, Wednesday, September 19, 2007 @ 5:20 am

Point your browsers to Google Code for the new home of Really Simple History, the Ajax bookmarking and back-button library I recently agreed to take over from creator Brad Neuberg.

I just got back from vacation and spent today diving into the code, which hasn't been versioned in a couple of years. I've already gotten some great feedback and suggestions from users who have hacked the library since its last update. I expect to get a new version out in the next few weeks, so keep the requests and comments coming.

Topics: ,

agile ajax Agile Ajax

YUI Bubbling Library: a seriously cool design pattern

Brian Dillard, Wednesday, September 19, 2007 @ 5:15 am

Caridy Patino recently posted to the YUI Blog about his event-bubbling library, which uses the subscriber/publisher design pattern to abstract an entire webapp's event binding into its own unobtrusive behavioral layer. Instead of attaching events to individual DOM nodes using addListener, you intercept and process all events near the document root, then use CSS classes or other criteria to match up individual events with the correct handlers. In effect, you end up with a big, global switch statement for handling mouse clicks, mouseovers, keydowns and other events.

Patino, a respected contributor to the YUI mailing list, makes a strong case for the usefulness of his library on larger, more event-driven webapps. For one thing, it can reduce the overhead of handling IE memory leaks. For another, it can simplify the process of attaching custom JavaScript behaviors to dynamically loaded content. Best of all, it can be used to improve performance of really complex apps.

Of course, such an abstract approach isn't for every developer or every application. Patino is pretty frank about both the pros and cons of his approach for specific situations. Even if the actual technique isn't for you, though, the post is a fantastic primer on the intricacies of DOM events and the publisher/subscriber pattern.

Topics: , , ,

agile ajax Agile Ajax

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics