Table or Booth?

Introducing the WACD Methodology

Pronounced 'whacked', WACD is short for:

• W - Wild
• A - Ass
• C - Cowboy
• D - Development

Key WACD Tenets

• Use IDD (Instinct Driven Development). After all, you’re the one who has to build it.
• Always code alone. Other opinions rarely help, so, in the end, they just slow you down.
• Always don’t test. You know what you're doing. Like opinions, this is just more drag.
• Document when asked but never again. You’re not a writer. Who’s going to read it anyway?
• Keep information to yourself. Anything else just risks you losing your job.
• CM with zip. You're stuff is archived. You know where it is – that’s all that really matters.

Benefits of a WACD Team

• Overdue projects
• Low levels of usability
• Lots of application bugs
• Costly O&M
• High staff turnover

Google Mail Up

It's back.  At least, for now.

Google Mail Down

Lately, no matter where you look, the unthinkable is being thought of.

Google Mail has been down for last 40 minutes.  Sitting here at downtown Reston's Panera, I have connectivity to any other site to which whim takes me.  Just not Google Mail.  

Sites like this don't have scheduled outages.  At least this used to be the case.

Generally, I recommend Google.  This most recent email outage is starting to put dents in my trust.  After their Feb 09 outage, you'd think they would've pulled out all the stops to make sure mail service wouldn't die only a few days later.

RIAs - The New Web UI

SproutCore is slick; has a RoR + Apple pedigree & leverages Javascript very nicely.  MobileMe integrates it.  Apple contributes heavily to the project.  Silverlight, AIR, and Google Gears compete.  Silverlight and GG require browser plug-ins.  Only GGs is open-source.  Here's a good overview: http://rapidappsgroup.com/content/desktop-web-applications-using-sproutcore/

Groovy 1.5: No Private for You!

Considering Groovy for your next big project?  We did.  All things considered, it figured to be a safe choice given its Java pedigree. From the limited exposure I'd had to Groovy up until that point, it looked and felt remarkably familiar to Ruby (a good thing).  I had even heard you could cut & paste any amount of Java into a .groovy file and it would just work.  Depending on what 'work' actually means, this is mostly true. 

One of the small untruths about Groovy behaving 'just like Java' is worth serious consideration - especially if you want your .groovy code to become API-ready.

RailsConf 2008 Saturday Night Key Note: Kent Beck

I got lazy and didn't blog about DHH's key note last night.  So, before I get on with Kent's salient story-style wisdom, I'll quickly catch up with DHH's.

Continue reading "RailsConf 2008 Saturday Night Key Note: Kent Beck" »

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

Summary: Dialogue Concerning the Two Chief Modeling Systems

Jim Weirich, Joe O'Brien, and Chris Nelson acted out a dialog where they built an application to reserve conference rooms.  Very entertaining and novel approach for a tech conference!  I loved it.  But, to the point now - the summary...

So, you want to build something?  

Their are at least two philosophies to fleshing out the model: Traditional object-based modeling and behavior-based modeling.  How are these different?

Continue reading "Summary: Dialogue Concerning the Two Chief Modeling Systems" »

May 30, 2008 at 06:08 PM in Current Affairs, RailsConf2008, Ruby, Software, Web/Tech | Permalink | Comments (0) | TrackBack (0)

Digg This | Save to del.icio.us

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

Yellow Pages.com Rewrite

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

RailsConf 2008

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Book Review: Sketching User Experiences by Bill Buxton

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.