Don't Start With Automation

I’ve lost track of the number of times new testers have asked me some variant of “I’m new to testing. What automation tool should I start learning?”

I really appreciate their excitement about automation—especially since I’ve made automation my wheelhouse—but it’s not the thing new testers should focus on!

Testing’s a craft with a whole lot of tools, most of which are between one’s ears. You need to focus on developing your skills as a craftsperson, not just jumping on the automation bandwagon. (Please, do join me on board, though. It’s a great wagon to use for parts of your testing ride!)

As a newcomer, there are a tremendous number of things you can use to build up your testing skills. In no particular order, here’s a few things I’ve pointed people to over the various years.

People:

• Elisabeth Hendrickson, aka @TestObsessed on Twitter. Funny, wise, calm, extremely thoughtful tester. Her Test Heuristics Cheat Sheet is caramelized unicorn bacon drenched with awesomesauce.
• Michael Bolton (@MichaelBolton) is a great thinker and writer in the testing space. He’s strong coffee and very opinionated, but I’ve gotten a lot out of reading his material. Much of Michael’s writing is at DevelopSense.
• James Bach (@JamesMarcusBach) I’m really not a fan of James’s personality, but he’s done a lot of great thinking about what testing’s really about. Read with an open and skeptical, questioning mind. His deck on test cases is a great read.
• Lisa Crispin (@LisaCrispin) and Janet Gregory (@JanetGregoryCA) are both smart folks who you should follow.

Other people who I’m not taking enough time to describe their awesomeness, but simply list. All are easily discoverable on Twitter, Google, etc.

General testing folks

• Matt Heusser
• Michael Larsen
• Alan Page
• Trish Khoo
• Paul Carvalho
• James Lyndsay

Automation geeks (who are also great testers, btw)

• Adam Goucher
• Richard Bradshaw
• Dave Haeffner

Please keep in mind: these folks are a starting point! Many are folks I know personally and respect, and they’re pals. Expand beyond this list!

Books:
There are plenty of great books to read; these are a few titles that really stick out:

• Beautiful Testing
• ExploreIt!
• Agile Testing and More Agile Testing
• The Art of Agile Development
• The Art of Unit Testing in .NET
• Specification By Example
• A Practitioner’s Guide to Software Test Design
• ATDD by Example
• Lessons Learned in Software Testing
• Experiences Of Test Automation

Community:
Find testing groups near you, or start one! Look to some of the various online testing communities. Weekend Testers is a great start!

Conferences:
Some conferences are great, so are a waste of time and money. But I’m slightly opinionated…

• CAST
• EuroStar
• STP Conference

Branch out to good developer conferences where there’s a welcoming, encouraging atmosphere. I’m biased, having been on the Board of Directors, but CodeMash is one of the best conferences you could hit for cross-polinating.

Other:

• Elisabeth Hendrickson’s blog Test Obsessed. She’s stopped posting since moving out of the consulting space; however, her writing is gold. Just. Plain. Gold.

Don’t Stop Here

Testing is about curiosity. It’s about sharing information with your team, organization, and customers. It’s not about “assuring” quality—you as a tester simply can’t do that. You can be part of a team that delivers great quality.

Go out. Explore. Learn.

THEN go get started in automation.

Fixing Slow/Hanging VMWare Guests

Problem: Your VMWare guests may be incredibly slow or all together hang.

Solution: (One potential one) Check if your VMs disks have become corrupted. Repair them if so.

Steps:

Do the following with your VM powered off!

1. Find the logs for your VM. They’re usually in the VM’s root directory, eg

   E:\VMs\2012R2\Win2K8R2.vmwarevm

2. Open the latest logfile in that directory, eg vmware.log

3. Search for “repair”

4. If you find hits similar to the example below, you’ll need to run the disk repair utility.

   2015-02-13T14:00:06.102-05:00| vmx| I120: DISKLIB-DSCPTR: Opened [2]: “Virtual Disk-s003.vmdk” (0xa)
   2015-02-13T14:00:06.107-05:00| Worker#0| I120: DISKLIB-SPARSE: “E:\VMs\2012R2\Win2K8R2.vmwarevm\Win2K8R2-s001.vmdk” : failed to open (14): Disk needs repair.

5. Open a command prompt and navigate to your VMWare install directory. On my system it’s:

   C:\Program Files (x86)\VMware\VMware Workstation

6. Run the following command, where “” is the folder containing your VM’s disk—likely the same folder you found the logfile in above.

   vmware-vdiskmanager.exe -R

7. Start your VM back up. Once it’s back up and stable, check the latest logfile and search for the same “repair” error. If “repair” isn’t found, search for the same file opening entry just before you ran the utility:

   2015-02-13T14:00:06.102-05:00| vmx| I120: DISKLIB-DSCPTR: Opened [2]: “Virtual Disk-s003.vmdk” (0xa)

8. Verify there aren’t any errors.

Hopefully this will get you up and running!

Fixing Outlook Search Issues

Problem: Outlook’s “instant search” isn’t returning any results, or search isn’t returning results unless you change the scope from its default Current Mailbox to something else.

Solution: (Well, more accurately One Potential Solution) Run scanpst.exe, found in the same folder as Outlook.exe. On my system that’s C:\Program Files (x86)\Microsoft Office\Office15.

Point the utility at your PST or OST files. It will scan them. If it finds errors, you’re offered the option to back them up (Duh!) before repairing.

Fixed up my search problems that had been nagging me for a bit too long…

Speaking on Leadership at KalamazooX Conference

I’m really pleased to be returning to the KalamazooX Conference as a speaker. KalX is my second favorite conference in the world, right behind CodeMash. KalX is something very, very special because it focuses on the human side of things: inspiration, motivation, self-improvement, self-fulfillment.

Mike Eaton invited me back to talk about leadership, so I’m polishing up a new talk “Growing Into Leadership” based on previous talks, workshops, and of course my Leadership Journey book.

If you’ve been to KalX you know how special it is. If you’ve never been, I encourage you to consider attending—even if you need to travel. It’s that special. It’s that worth it.

Go register now on Eventbrite. You won’t be sorry. I promise.

I'm Listed in Top 21 Automation Blogs

I was surprised to find my blog as #3 on Testbuffet’s list of the Top 21 Test Automation Blogs for 2014. That’s quite flattering, and I’d like to give a big “Thanks!” to the folks at Testbuffet and the evaluators for that list.

That list is a great resource for you if you’re trying to broaden your reading horizons. There’s a lot of smart testers writing on topics other than just automation there!

I’d also encourage you to check out other lists from Testbuffet:

• Top Software Testing Blogs
• Top Technical Testing Blogs
• Top Performance Testing Blogs

Book Update

Update: Wow, StackEdit did a horrible job of posting this! I had to fix several format issues including the book's price, which is is $12, not $122.

In case you missed it, I’m writing The Leadership Journey on LeanPub. The book’s meant to help individuals become great team leaders.

Pricing for the book is pretty attractive: Minimum price is FREE and recommended price is $9.49. When I release the price will change to minimum of $$9.49. I'll leave it that way until I "release" it, at which point I'll likely make minimum around$5 and recommended around $12.

The book’s currently at 67 pages and around 13,600 words. I hesitate to put a figure on it, but I’d estimate I’m around 50% - 70% done. Mind maps lay out the sections and their rough status, so you’ll have an idea where the book is going.

The latest major update is getting started on dealing with Impostor Syndrome. Self-confidence is a critical part of leadership, and I want readers to have some concrete actions to deal with self-doubt which can turn out to be quite destructive.

If you’ve signed up and are getting the updates, I’d love to hear from you.

If you’re not currently reading it, but are interested, go grab it! Please do let me know what you think of it, either on the LeanPub discussion group for the book, or via e-mail: Jim@GuidepostSystems.com.

I’d love to hear what you think of it!

Find me at CodePaLOUsa 2015

I’m very pleased to announce I’ve been selected to give two pre-conference workshops at CodePaLOUsa 2015!

If you’re not familiar with it, CodePaLOUsa is a terrific four day conference in Louisville, Kentucky. It’s organized by a number of terrific community folks including Chad Green, and it’s a wonderful conference full of great speakers and attendees. This is another conference where the hallway conversations are every bit as great, if not better, than the sessions themselves.

For my part of the schedule I’ll be doing my Leadership 101 workshop plus my Testing Web Applications with WebDriver session.

I hope to see you there if you’re in the neighborhood!

Hone Your Craft, Raise Your Hand

Last week I was talking with some folks at Pillar in Columbus, Ohio, and we were discussing career progression. The discussion evolved into how individuals could move up a career path, or be recognized as wanting more responsibilities.

John Huston, one of Pillar’s leaders, made the comment “Hone your craft, raise your hand.” That comment really struck home with me, so much so that I grabbed a 3x5 card on the table and scribbled the phrase down right in the middle of the ongoing discussion.

I love John’s phrasing because it concisely sums up one of the best ways you can advance along your career path: work hard, ask for more responsibility. I’ve always been a believer that hard work gets recognized in good organizations. [1] It’s not immediate recognition; sometimes it takes an extended effort to get to that point.

Honing your craft is critical both to you and the organization you work for. Honing your craft means you need to invest the time and energy in a focused, planned effort to improve your skills. That helps you get better at your job. Your improvement rolls up into your organization’s ability to better deliver value to whoever the customer or end users are.

Raising your hand isn’t always easy. First off, many of us (I’m looking hard in the mirror here) have problems letting our leaders know we’re ready for more responsibility. We may suffer from impostor syndrome, we may feel it’s arrogant, or we may just have a hard time speaking up. (I suffer from all three…)

Regardless, it’s something that everyone should strive to feel more confident about. Asking for more responsibility makes sure your leaders know you want to help the organization in one fashion or another&emdash;and that’s something they may have been too busy to notice.

My most favorite jobs have been opportunities that popped up after having worked hard at other roles: Director of QA at Telligent, Director of Engineering at Telerik, and a few other things further in my past. I didn’t plan for those advancements, I just worked hard at the role I was in and made it clear I was happy to take on other tasks as needed. That mindset worked out well for me and resulted in neat opportunities I’d never thought of.

Obviously my journey’s different than yours. Your mileage may vary. Insert other disclaimers here as necessary.

Point being, too often we forget that sometimes the best way to advance in one’s career is simply to focus on improving how we do our own work: Hone your craft. We also forget it’s good to let your leadership know you want more responsibility: Raise your hand.

Hone your craft, raise your hand. Solid words for moving your career along.

[1]Yes, yes, there are places and situations where it doesn’t. Remove yourself from those. You own your own path.

CodeMash Session Follow Up

For those readers who attended any of my three sessions at CodeMash: Thank you! I appreciate the great audiences I had, especially those who braved the 55 or 60F temps Thursday morning in Cypress for my Ten Tips for UI Automation talk!

Here are resources for my three sessions:

Leadership 101 Workshop
- Slide deck
- The Leadership Journey, my book on growing into being a great leader.

UI Automation Workshop
- Slide deck
- Basic examples on GitHub
- Demo site showing table access, updates to UI for dynamic IDs and flag elements

Ten Tips for Web UI Automation
- Slide deck

Common references for web testing
- Dave Haeffner @TourDeDave on Twitter.
- Dave’s Elemental Selenium site and newsletter
- Richard Bradshaw @FriendlyTester on Twitter

My CodeMash Sessions

UPDATE: I had the days wrong. Leadership workshop is Tuesday starting at 8am in Salon H. My Web UI Automation workshop is Wednesday from 8-5 in Guava/Tamarind.
I’m flattered to have been picked up for two workshops and one regular session at CodeMash! It’s going to be great being able to focus on just giving great sessions and not worrying about herding various cats around.
Tuesday I’m giving an all-day workshop on web UI test automation. We’ll dive deep into working with Selenium WebDriver, but the concepts will cover plenty of other toolsets. I’ll likely spend a bit of time showing how a commercial tool like Telerik Test Studio fits in to things.
Wednesday I’ve been asked to do a half-day workshop on leadership. That’s incredibly flattering! I’m basing the content for that off my Leadership 101 series, plus the book I’ve just started The Leadership Journey. This brand-new workshop will be very interactive with a good number of exercises meant to help you really dig deep and figure out how to evolve your own leadership style. I’m pulling this workshop’s content together very quickly, and I’m both excited and terrified.
Thursday I’m in an opening slot at 8am talking again about web UI automation: Ten tricks to help you get the most out of your UI testing. The talk centers on web automation, but it really will help you regardless of what UI tech you’re working with.
Interested? Check the CodeMash schedule for details, or go grab the EventBoard app and get your schedule built up.
Got questions on testing, process, leadership, or something else? Look me up at the conference! I’d love to chat!

You Broke My Code? It's My Fault

I was having a conversation with a few smart folks a couple weeks ago and one of them mentioned a great mindset their organization has: “You broke my code? It’s my fault–I didn’t have the right tests in place.”

Step back and think about for a minute.

This quip really set me back on my heels. If you’ve read anything of mine over the years, you know how I feel about taking responsibility for one’s code and one’s tests. This organization’s mindset of owning the responsibility for bullet-proofing your own code with great tests is terrific.

It’s one thing (a great thing!) to step up to the plate and be serious about getting testing ingrained in your delivery process. It’s a serious elevation to get a mindset where every developer takes it personally when someone else breaks their code.

“You broke my code? I needed more tests.” What a great mindset.

Book In The Works: The Leadership Journey

I swore I’d never write another book after finishing 1300 pages of Windows Developer Power Tools with my co-author James Avery.

Famous last words.

When the kind folks at CodeMash asked if I could put together a four hour workshop on Leadership, I figured I’d better get some solid content laid out to make sure the class wasn’t just boring anecdotes of mine. I needed something more focused, and something with some practical put-this-to-use-tomorrow kind of ideas.

Apropos, let me introduce to you The Leadership Journey. This book contains the original Leadership 101 blogposts and will end up with a lot of new content. There will also be practical exercises to help you focus in on a few key things.

What’s the books goal? To help you answer a few key questions:

• Do I want to be a leader?
• What are my strengths and how can I make the best of them?
• What are my weaknesses, and how can I best mitigate them?
• How can I make my team be awesome?

I’m publishing the book on LeanPub with a recommended price of $9.49. I hope you’ll have a look at it.

What would you find helpful in your own leadership journey? Leave me feedback here in the comments, or over on the book’s LeanPub page.

Choose Wisely AND Back Out Easily

Alan Cooper (Yes, that Alan Cooper) had a great-sounding Tweet yesterday that made me stop and think:

Instead of choosing the correct path in advance, develop better tools to incorrect paths soonest and without rancor.

I get the point I think Mr. Cooper was trying to make: we need to be able to recover more easily from our mistakes in software. I especially love his point of “without rancor” because we need to be more accepting of the fact that the path to success is littered with unsuccessful tangents.
However, I’ve got a subtle iteration of his phrase I like better:

Do your best to choose the correct path at the start, but know how to figure out it’s an incorrect path, and figure out how to reverse soonest and without rancor.

I completely agree that we need to get in the business and cultural mindset of being OK with failure/mistakes, getting out of them as quickly as possible, and doing it without rancor.
That said, I’d prefer the subtle difference of emphasizing avoiding those mistakes where possible. We should not, repeat NOT get wrapped up in fear or analysis paralysis blocking us from decisions that might lead to mistakes or failures, but we should be doing enough sanity checking to ensure the choice meets business value requirements, fits the teams’ ability to deliver, etc.
In my Leadership 101 talk I make the differentiation between smart mistakes and dumb mistakes. Smart mistakes are ones made when you’ve been thoughtful about your approach. Dumb mistakes are when you dive in to dig a 14’x8’x18” rain garden pit, then realize you’ve dug it right next to your house’s foundation–not the place you want a lot of water sitting for extended periods. (Ask me how I know about this…)
Backing out from unsuccessful choices is critical. First spend a little time planning to ensure you can avoid as many of those choices as possible.

Rethink Your Hiring Critieria

This article on how Google's changing their hiring practices really hit home with me.

I've long viewed learning ability and problem skills as far outweighing where someone graduated from or what their resume history looked like. I've previously blogged about my thoughts on hiring, and  my position descriptions have tended to drive HR departments crazy because they weren't checklist oriented.

I've always been more interested in how well someone's going to approach working as part of a team over what classes on compilers they took, or what certifications they've passed.

Technology changes too fast to focus on criteria like "3.6 years working with .NET 4.5" or "Must have graduate degree in artificial intelligence." I'd rather have people on my team who have made some big mistakes, learned from them, and want to share that knowledge with the rest of their team.

Do your hiring criteria look like shopping lists in the technology buffet? Perhaps you might reconsider reworking those around criteria that focus on your organization's real needs: candidates who can help you quickly and effectively solve problems core to your business needs.

Hire me!

I'm open for work!

Last week I parted ways with Falafel Software. They’re a great bunch of folks, but we weren’t a good match culturally or philosophically. That’s absolutely OK, and we parted on good terms. I’m happy to continue recommending them and calling them friends.

That means, however, that I’m open and available for new opportunities! I’m actively looking for work as an independent consultant, or for any full-time spots where organizations think I might be helpful.

What sort of things can I help you with? I’m passionate about helping organizations deliver great value to their customers, regardless of whether those customers are external or internal. I’ve helped teams build out their testing skills (not just test automation, but overall testing), smooth out quality issues impacting their organizations, and cut out waste throughout their delivery cycle.

That may sound a bit hand-wavy to you, so for more details check out my LinkedIn profile, visual resume, or more “traditional” (eg ‘non-gonzo’)resume.

Want to chat about things in more detail? I’d love to talk with you! Drop me an email at my new Indie digs: jim@GuidepostSystems.com. 

Xamarin Studio: Publishing to Device Fails

Problem: Attempting to publish an app from Xamarin Studio to an iOS 8.x device fails. You may see various error messages about unable to write/find Manifest.plist, and you'll likely see an error message akin to AMDeviceSecureInstallApplicationBundle returned: 0xe8000097 (kAMDInstallProhibitedError).

Solution (mine, at least): Ensure the restriction for Installing Apps is active, not disabled. Under settings, check General | Restrictions | and ensure Installing Apps is allowed.

Dealing with Legacy Codebases? Find me at ThatConference!

I'm honored to have been selected to speak at ThatConference Aug 11th-13th at the Kalahari Resort at Wisconsin Dells.

I'm giving my talk OMG! This Codebase Sucks! which tries to lay out some ideas to help people fix up problematic codebases while continuing to deliver value via new features, bugfixes, etc. My goal for the talk is to help attendees learn how to decide which parts of the system and environment to focus on, and how to figure out which sections of the codebase to start tearing apart or outright burning down and rebuilding.

All of this has to be done in the context of keeping the system in a state where the team can continue to ship on a regular, if occasionally slightly interrupted, pace. After all, accomplishing the organization's mission doesn't miraculously stop for months so you can focus all your delivery efforts on completely re-writing a codebase! (Occasionally it does, but rarely.)

If you've been around legacy software and struggled through this, then I'd encourage you to attend the talk. You might learn a helpful hint or two, and just as importantly, you might be able to share a gem or three with the other attendees. (Yes, I love interactive audiences in my talks!)

Why ThatConference?

If you're unfamiliar with ThatConference, I encourage you to have a look at it. It's a community-spawned conference that rivals many commercial "big" conferences for content. Moreover, ThatConference (and CodeMash) has an amazing amount of hallway interaction between really smart, passionate folks from widely differing domains. You're able to learn how people from Ruby, Java, .NET, JavaScript, and other domains solve the same sorts of problems you're running into every. single. day. and you'll learn vastly different approaches which will help you as you move forward in your own domain.

Time's short, but tickets are still available.

Just. Go. Do. It.

Bonus Material

Just like on good movie DVDs, here's some extra content: the deck from my OMG! This Codebase Sucks! talk:

Handling State for Browser Testing

Marc Escher asked a great question on Twitter about browser testing and state. He actually wrote a Gist on it, but I thought the question merited a response here.

State in Tests

Handling "state" of a system for any test automation is an involved process that should evolve as your test suite does. All the same good design/engineering practices that we use for building good software (abstraction, DRY, readability, etc.) should be applied to our test automation suites. Because, you know, test code is production code.
Here are some thoughts on Marc's great set of questions:

1. What are patterns for creating expected state prior to running browser tests?

"State" is a broad term and many folks may think of different definitions. I think of it as data, environment, configuration. There's a difference between setting up background "state" for a test suite, and having each test set up its prerequisites.
Setting up an environment for a test suite run is a conscious decision based on what's needed for that particular suite to succeed. I regularly use a combination of loading baseline datasets, altering system configuration (turn off CAPTCHA, select a simple text editor, swap mail providers, etc.), and leveraging test-specific libraries, infrastructure, APIs to get the starting environment set up.
Also, it's very, very critical to understand there's a difference between system-wide state (baseline datasets, eg) and state needed for individual tests. No test should ever, ever rely on sharing state with another test. The risk of side effects, especially in distributed/parallel testing scenarios is just too high. You'll regret it if you rely on this. Ask me and Jeremy Miller how we know this.... (ie, school of painfully learned hard knocks.)

2. Is it appropriate for the browser tests to communicate directly with the database of the system under test, creating state in the same manner that you would in an integration test?

I generally prefer to use the system under test's own APIs to create state for a test. These APIs ensure CRUD operations are obeying the system's own rules for its data. Using APIs means you don't have duplicated logic around CRUD ops for your tests, which is a good thing. This way you're not having to maintain separate helper methods to handle changes when the app's underlying DB structure changes, for example.

3. How important is it that browser tests be decoupled from the application under test, such that the only thing required to run tests are the tests themselves, which can be pointed at any applicable URL (dev, test, staging)?

There are a couple different aspects to this, IMO. You want your test suite coupled to the application in the sense you need to leverage the system's own APIs for setup, teardown, configuration, and parts of your test oracles[1]. That said, these calls to the system should be abstracted into a set of helper libraries. The tests themselves should never, ever know how to communicate with the system itself.
For example, you don't want individual tests that know how to invoke a web service endpoint to create a new contact in your Customer Relations Management system. If that endpoint changed, you'd have to touch every test that used that endpoint. That's a recipe for a lot of extra scotch consumption.
Instead of telling the system how to do something, tests should tell a helper function/library what they want done. That library in turn knows how to call a stored procedure to create a user. With this approach, no test ever has to be updated if, for example, the system changes from a stored procedure to a web service for creating new contacts.

Write Tests Like You Write Code

I've generalized a number of things in the above thoughts, but the bottom line is this: use the same ideas approaches for your test suites as your production code. Because tests are production code.
[1] For automated tests, an "oracle" or "heuristic" is the final step in your test after you validate the UI is behaving as expected. It's not enough to leave the test off at that point. You need to check the database to ensure items were properly created, updated, or deleted, for example. You might have an oracle that checks the filesystem to ensure a datafile was properly downloaded.

TIL: Arrowhead Anti-Pattern

Today I Learned: The term “arrowhead anti-pattern” from Jeremy Miller’s tweet. (If you’re interested in software craftsmanship and you’re not following him, change that.)

The “arrowhead” describes the visual pattern made by a nasty set of nested conditionals:

if
   if
     if
       if
         do something
       endif
     endif
   endif
 endif

The above snippet was lifted straight from the great article on the C2 wiki. If you want to take the visual aspect a step further, go see the Daily WTF’s article Coding Like the Tour de France.

Nested conditionals are awful. Avoid them. Read up on cyclomatic complexity and learn to handle things differently in your code. You’ll be happy you did. (See Chris Missal’s article on Los Techies for some other good discussion.)

I’ve long known the troubles this sort of code causes. I just didn’t know the cool name for it.

Learn something every day…

Dear Jeff: Good. For. You.

Jeff: You don't know me, we've never met, but you've run across a nasty spate for your post on how men can help address some of the awful things that happen in our industry. I wanted to add my voice of support to you.

The diversity movement, or whatever that movement names itself, is trying to bring some much needed change to our world. Good for them. Some of their leaders have suffered some horrible things in life, and they've got some powerful stuff they're trying to spread awareness of. Good for them too.

That said, I'm incredibly saddened at the venom and bile you've had thrown at you. Too many in the diversity movement have no room for any voices or any views other than exactly what's put forth by those leaders. Ironically, there's no tolerance for diversity of views or voices.

Worse yet, there are some in that movement who explicity want white males to have no voice whatsoever. They'll couch it in fluffy phrases like "people with power should restrict their speaking to amplifying the words of those without" but at the core they're demanding to stereotype and marginalize a group of people while trying to uplift others who've been stereotyped and marginalized. In what twisted universe is that even logical, respectful, or even close to right?

I'm especially saddened with the reaction you received because you made some terrific points which were shouted down or ignored. Looking to Martin Luther King as a model instead of (literally) screaming profanities at people? How's that wrong?

Emphasizing the need to start early in life and focus on kids? We need more people with your reach talking about this. Asking people to line up with Hacker School Rules and calling out guys for bad behavior? YES YES YES!

Yes, you should have done a few things better. I do wish you'd referenced Shanley Kane's post from the get-go. It's obvious she gave you some bit of inspiration or motiviation. I really dislike her tone and approach, but I think it's important folks know more about her--even if for no other reason to say "I can't agree with her approach, but there's a few things to be learned."

At the end of the day you were adding your voice and thoughts to raise awareness in a horribly sensitive, messy, human problem area. My good pal Leon Gersing has a number of amazing presentations he's done in front of thousands of people. One of his best thoughts is something in the lines of (paraphrased) "You don't need anyone's permission to do what you feel is right."

I'm glad you wrote your post.

Good.
For.
You.