How we read


View Larger MapRecently, I tweeted about reading Steven Johnson’s book, The Ghost Map.  It’s a book that ties in with my PNSQC paper in a very odd way which I’ll write about later.  What I noticed as I was reading, is that the way I read has changed.  The Ghost Map is about a cholera outbreak in London during late August/early September of 1854.

Even though I’m only 1/5 through the book, I’ve already looked up all of the places on Google street view.  This is a new and an old thing for me.  Whenever I’ve read books about a certain location, the next step, for me has always been to find a map of the location and take a good look.  This time, not only can I see the layout of the streets, but I can see what they look like “on the ground.”  Johnson writes about how crowded the streets are and about the dense population of the area.  If you look at streetview, this is immediately noticeable.

Although my copy of this is book is a dead-tree copy, I have to wonder how my experience would change if I had an e-Reader.  With the current paradigm shift taking place from dead-tree books to e-readers, I expect that books themselves will change and will allow the reader different ways to explore their content.  This, in turn, will create different expectations from those who are reading.  I won’t be going from my dead-tree book to my computer to look at the Soho area of London.

Some of you may have used Zemanta for blogging.  Zemanta sits next to the window where I write text in my blog and makes suggestions for pictures and links while I type.   Although, at this point in time, I use Zemanta for writing, I can see a Zemanta like integration for reading as well.  One of the first chapters in The Ghost Map describes clergyman Henry Whitehead making his rounds through the neighborhood.  I’d love to see a map next to the text that I am reading which shows the route he is taking or pictures of some of the places he is visiting.

Language is its own art form.  You can’t just replace a book with a bunch of pictures and links, but there is more than one way to explore writing.  The best writers, I believe, will find ways to integrate the language of their writing with the exploratory journeys their readers take.

Have you noticed differences in the way you read?  How do you think reading will change as we move from paper to e-readers?  If so, I’m very interested in hearing about it.

The Observer Pattern

Gustave Doré's illustration to the European fa...
Image via Wikipedia

This pattern is also known as publish/subscribe. It’s mainly used for keeping objects updated. The object sending out updates is called the “Subject” and the objects receiving updates are called “Observers.”

As a one-to-many example, think of Little Red Riding Hood (LRRH…she recently converted to Scientology. It was on TMZ). She’s setting up Grandma’s RSS feed for the very first time.
Grandma only has 1 feed, from her favorite televangelist, Mozelle Patterson. Grandma only has one feed because after LRRH set it up for her, she’s probably not going to go looking for more.

Mozelle Patterson is a televangelist here in the ATL who has a show on a local channel every Saturday that can, at times, be more amusing than SNL. Let’s say Mozelle Patterson has an RSS feed. Her feed is the subject. All the grandmas who have had someone set up their RSS feed, get the Mozelle Patterson feed. All of the grandmas, including LRRH’s, are the observers.

**subject**

Mozelle

|

|

v

** observer**
-Little Red Riding Hood’s Grandma

**observer**

-Sleeping Beauty’s Grandma

**observer**
-Anansi’s Grandma

Notice that, previously, I said that this is the 1 to many example. Why? Because the next time LRRH visits, she notices that Grandma hasn’t added anymore feeds, but she knows that Mozelle has a special feed specifically for the Gospel music featured on the show, and she adds that to Grandma’s reader. Now, Grandma has 2 different types of feeds from the same place. That’s many to many.

Here’s a class diagram of the 1-to-many example. Note: this is my example, and it’s not guaranteed to be perfect, so don’t take it as “gospel.”

The Observer Pattern
The Observer Pattern

Push/Pull
There are two types of Subject/Observer relationshiop. In the “Push” relationship, the Subject will send the observer everything it needs on notify. For example, If Mozelle’s rss feed contained all of the highlight from the show with pictures, etc., this would be a push. If the feed only contained the title of the show, and Grandma had to click through to view the show highlights, then it would be a pull relationship.

Loose Coupling
This pattern is a great example of loose coupling, because the subject doesn’t know that much about its observers. The observers operate freely and independatly of their updates from the Subject.

Reblog this post [with Zemanta]

Design Pattern Series

I’m taking Design Patterns this Summer.  At this point, I’ve coded enough Java to be able to say I can code Java.  However, I also know that my code typically is not, ahem, polished.  Take for example, this past week.  We’ve been going over publish/subscribe.  Some may call it the “Observer” pattern.  I call it the distributed message queue system I made for distributed systems class a year ago.  Hindsight is always 20/20, right?

Design Patterns is all about avoiding DRY.  This is something that I’m going through even with the Automated Test Framework that I’m writing at work.  It’s all Unix shell scripts.  Since shell scripting was created when programming pretty much meant that you were programming the OS, the syntax itself wasn’t particularly intented to be OO (insert e-vil grin here)…but that doesn’t mean that it can’t be.  At this point, I’ve got scripts everywhere, and they are settling into a pattern.  I chose test patterns and test harness patterns as my research topic for the class. I’m waiting to see if, in the course of my research I find myself looking in the test patterns mirror at my own automated test framework.

In the meantime, I will be making a few posts this Summer about Design Patterns.  I’ll post my research assignment too.  I’m so happy that my teacher is using Head First Design Patterns.  I know that THE Design Patterns book is Design Patterns: Elements of Reusable Object-Oriented Software, typically known as the “The Gang Of Four” book, but the information in Head First Books is always so much easier to remember.  They remind me of The Best Calculus Teacher Ever, Dr. Kathleen Hall who was considered somewhat unorthodox in using colors, YES! colors for describing calculus concepts on the black board.  Every time I read a Head First book or find myself taking the derivative of something, I think fondly on Dr. Hall and her classes.

Testing in a Throwaway Culture

Picture of a Caterpillar 826C landfill compact...
Image via Wikipedia

When was the last time that a prized possession of yours broke before its time? Did it make you angry and disappointed?  Were you surprised or were you half-expecting it to break?

Craftsmanship is a word we no longer associate with many of the things that come into our possession.  This was brought to my attention recently when I had to buy a new motor for my very pricey KitchenAid, Architect II dishwasher.  As software quality professionals, we are all on the other side of this.  How many tests were you able to run?  How well did you really vet that app?  Did you understand the app?  How much of your testing went according to plan, however much planning you had?  Did the plan really matter anyway?

Last week, a good friend of mine wrote about his frustration at not having enough time to execute tests because of other test activities such as shaking out requirements, managing others, etc.  I kind of know how he feels because, as the test army of 1, I am responsible for many of the same activities.  I’ve done all sorts of reports and activities that will pad my resume as a QA resource, but, in the end, this is not why I do the job that I do.

Here is a post from Chris McMahon’s blog that is, in contrast, ALL ABOUT why I am very content as a technical QA.  The utter hack-itude of the exploits described in this post are exactly the domain of the tester I try to be every day.  But then, I have the bug reports to fill out, the test planning to create and the inevitable smoothing over of dev ego.  These things slowly but surely chip away at my day.   My friends blog is a description of how, for more senior test professionals, it becomes their whole job, and my friend isn’t the only tester I’ve noticed lately opining the strategy tasks that take up their time ( you know who you are).

We live in a throwaway culture where breadth is valued way over and above depth, and it seems, to me, that this can heavily influence our careers, sometimes for better and sometimes for worse.  This includes software development AND QA.  I’ve worked in this type of environment, not as a tester, as a CM.  I noticed that for every role, CM, tester or dev as soon as people became technical experts at what they were doing, they were expected to start managing whether they wanted to or not, whether they made a good manager or not.  Am I right or am I right?  What’s missing here is an association depth with value both on the technical side and the management side.

What does this mean, specifically, for testing?  What does it mean to be an expert craftsman in testing?  Does it mean that I can switchblade an app with heuristics, any time, any place? Or does it mean that I will find a way to make some assessment of quality if given the most mountainous of systems to test in extremely adverse conditions?  My personal goal is to work hard at both.  I use test management activities mainly as a way to manage DRY (do not repeat yourself) and to get on with the tests.  It’s almost as if there is a sliding scale with test execution at one end and management of test activity at the other end.  This seems a rather one dimensional approach, and careers are not one-dimensional.

When you are asked to stop testing so much and to start managing more, what will you say?  Are you ready to give up depth as a tester and increase your breadth as a manager?  Is this really a one-dimensional issue?  For some, and maybe even for me at some point, this can be a great decision.  In some places, maybe there is less of a tradeoff than what I’ve seen.  For some, participating more in the management process might mean better quality for an entire team.  If the entire team improves, maybe the software will break less.  If the team is testing KitchenAid dishwashers, maybe the dishwashers will break less, and I won’t have buyer’s remorse for my fancy kitchen appliances.

Love it? Hate it?  Comments are always welcome.

Reblog this post [with Zemanta]