Resources to Check for Dead Links on a Website

http://www.brokenlinkcheck.com/
This external service hits your site and follows each link.  It is intelligent enough to check for loops.  Since it is an external service, it may artificially drive up hit count.


Check My Links Chrome Extension
This very handy chrome extension checks link status and places the results in-line.  Fairly turn-key, it even keeps a list of links to not follow that you can add to as you go along.  It seems to have trouble with blogspot controls and extensions, though adding them to the blacklist might be the solution.

Xenu's Link Sleuth
Heard about this one on UTest.  I am eager to try it out.  Free, long history, and automatable: all the right pieces for success.

Add more as you find them to the comments.

StarWest 2014

I viewed StarWest's Virtual Conference offering again.  This and the affiliated Better Software conference are run by Techwell.  A few observations.

1. I loved the talk on Healthcare.gov given by Ben Simo (@QualityFrog).  He communicates how easy it would have been to predict, find and fix the problems that would plague that site for more than a year.  It was a good choice putting him on keynote.
2. To attend one of these conferences will run you or your company into the thousands of dollars.  Attending the tutorials is even more.  This in spite of being sponsored by some of the biggest software providers in the industry.  We are bombarded by ads for the latest ALM or bug tracking tool and they are called talks.  What is such sponsorship getting the attendees?  Who is benefiting from this other than the organizers?  If the conference organizers were a not-for-profit, would they charge the same amount?
3. The online offering tries to simulate the networking opportunities for those who could not attend.  It tries to simulate the marketing side too by giving attendees contact info to vendors.  What about the testing opportunities?  With more than half the talks about web app testing, why aren't tutorial sites and learning apps available and promoted to virtual attendees?

Maybe DEF CON has spoiled me.  $200 for the most frenetic hands-on conference over twice the number of days?  A lot of that is a labor of love and volunteers, but then again most of it is also not sponsored by corporations too.  Maybe I need to bring DEF CON to testers, or testers to DEF CON.  See what shakes out.

Cards Against Mormonism

My brother and I grew up Mormon, but we no longer identify as such.  Nevertheless, the culture is unique, and there are many opportunities for squick, in-jokes and dark humor.  So, like everyone and their mothers, we decided to roll some of those up into an unofficial Cards Against Humanity expansion: Cards Against Mormonism.  A reminder: you may not get some of the jokes if you have never been Mormon, lived in Utah or or are otherwise considered a Gentile.  However, we took great pains to limit the amount of Utah-specific jokes.

The cards themselves were brainstormed under the influence of alcohol and put through the refiner's fire until about 100 unique cards (33 Black and 80 White) emerged.  Once the list was solid, we copied it into the brilliant Cards Against Humanity custom card batch processor.  It worked flawlessly the first time marking Pick 2's and adjusting fonts as needed.  This spat out two PDFs perfect for printing your own Mormon expansion to Cards Against Humanity.

This set is formatted to match the free print-and-play PDF still available on the CAH Website.  Like that set, it is shared under a Creative Commons BY-NC-SA 2.0 license.  You can see the original doc with those that did and didn't make it in Google Docs if you want to try your own hand at it and bring some apostasy to game night.

Sincerely,
DuncanYoudaho and FannyAlgersAbortion

Download Links:
White Cards
Black Cards

Test Early, Test Often

Of late, I have been enamored of testing techniques that come earlier and earlier in the development cycle. It can be called static analysis, design auditing, prospective testing, shift -left or the like, but the research is in: testing before you get something bears fruit in most organizations.  Here I present a few examples from my own experience.

At the start of a sprint, we leave Sprint Planning with the requirements.  The next interaction with developers is when we review their Developer Design Overview document that spells out the development approach and helps QA scope their testing effort.  This developer had chosen to put an error message into a file usually reserved for configuration.  QA saw the DDO and raised concerns immediately.  Why was a message being added to this file when they were usually reserved for the language DB?  With this one question, before QA saw the code, we changed the trajectory of development.  The fix was in before we got our first build, and the story closed with the Sprint instead of carrying over with the do-over.

An even earlier example came when we looked to implement secure communications between two servers.  While I couldn't code my own implementation, I was able to provide recommendations at design-time by staying educated and confirming my understanding with developers who had dealt with crypto.  By starting early, we were on surer footing when troubleshooting and confirming the implementation was sound.

As the examples above illustrate, QA often saves time for developers by defending standards and consistent implementation early in the cycle, but that is not the only savings that comes from shifting left.  Often, test environment issues can also be aided by an early understanding of requirements.  In one case, as story had carried over from a previous sprint which meant we were already behind.  The roadblock was a production issue pulling the developer away from the story.  Instead of sitting on our laurels, QA worked with the configuration manager to make sure our test environments were ship shape before the code was completed.  When the developer's changes passed build verification, we were off and running almost instantly.  Not only did our preparation help us get to the work of testing faster, but it also helped us close more stories as environments were made ready before they could become an obstacle. Not only was I able to test early, but it lead to me testing more and in greater depth.

Most modern test engineers have their own war stories from early testing.  For every story where requirements changed and early notes became meaningless, there are ten stories where early questions lead to greater clarity, fewer bugs, and more time for digging in.  I consider projects that foster this early access for QA to be among the most fruitful and least volatile.

RadioShack LED Strip Driver

I modified the Pololu RGB LED Strip drivers from version 1.2.0 to support Radio Shack's behind the times model that is 30 LEDs controlled in 3-diode sections.  I had to swap the colors around to match this pinout, and I changed the struct to a class (because why not).

The fix was to physically reorder the declaration of red/gree/blue variables in the struct declaration.  This way, when the information is written to the strip, it is sent in a different (and now correct) order.  You can make the fix yourself by changing the file PololuLedStrip.h:

typedef struct rgb_color  {    

   unsigned char red, green, blue;  

} rgb_color;

becomes:

typedef struct rgb_color  {    

   unsigned char green, blue, red;  

} rgb_color;

And here it is on GitHub: https://github.com/RangerDan/RadioShackTricolorLEDStrip

I should probably talk to Pololu on licensing concerns here.  I found the license from the original driver and copied it into my repo.  I couldn't figure out how to fork this properly, so I just re-uploaded it until I understand git a bit better.

C3BO: Proof of Concept using Timbermanbot Schematic

This post is part of a series about building electro-mechnical PIN-cracking robots, R2B2 and C3BO.



This is a proof of concept for @JustinEngler's C3BO (https://github.com/justinengler/C3BO) using transistor controlled relays. It was prototyped by modifying Blink from the Arduino sample project.

The schematic was obtained from Timbermanbot (https://github.com/vheun/ArduinoPlays...) as seen on Hackaday (http://hackaday.com/2014/07/26/pwning...).

In the video, You'll notice I've replaced the touchpad for your finger with a wire to the headphone jack's ground as the circuit ground. The two pieces of copper tape were no longer sticky enough to stay by themselves, so I am holding them down. They press two and 5 with about 8 key presses per second.

OFBC: Putting it All Together

Note: This is part of the Project Write-up for OFBC: One Fluorescent Beer Coaster

After months of effort, we had a circuit, PCB and shell design to accomplish our goal.  Putting it all together meant solving some unique challenges in the home stretch.  By far the most communal part of the project was finishing the circuit.  Parts were bought by three different people.  It took hours of trial runs and four different nights in my shop to finally get the circuit assembled and ready.  In all, the project taught us to keep moving in spite of obstacles.

Internals

The main obstacle was PCB manufacture.  As detailed in that post, uncooperative copper and etchant lead to abominations not fit for solder.  Drill bits broke in PCBs, holes were misaligned, and traces were torn up as we worked and reworked the boards.  The major blunder was the reversed PCBs, but it was tempered by the lack of polar components.  Only the transistor and MOSFET needed to be adjusted when we realized our mistakes.  The quality checks and encouragement as we worked as a definite plus.  There were several times I wanted to just give up and abandon the project.  Truly, I get by with a little help fro my friends.

After the PCBs were in our hands, the task of soldering all the components was a team effort.  One person ran continuity tests on newly etched boards.  Another bridged scratches and pasted down traces.  Buttons (functional and fake) were inserted and crimped at one station while a fourth person began to solder on components.

That moment of truth when the LED lit up was breathtaking all nine times it happened.  When it, more often than not, didn't work on the first try, the scramble to troubleshoot was a team effort as well.  A loose connection, bad trace or through hole in need of a reflow was rooted out in minutes. I can't describe the feelings from closing the box with nine functional copies of the idea sketched out on a picnic table the year before.

Externals

Shell manufacture forced choices between what we wanted versus what we needed.  The mechanical ideas at the outset gave way to manufacturing considerations.  Features were pared back to match timelines, work schedules and summer vacation.  Anyone reading this who has worked in an Agile Development environment will recognize similar decisions they make every Sprint.  To borrow a cliché, "Perfect is the enemy of good enough."  With this in mind, we have an eleventh hour compromise ready: should the 3D printer prove a roadblock, we have arranged for a Wednesday night Hail Mary meeting to turn Ziploc Containers into eternal glory.

The Ziploc idea produced 4 "just in case" models.  We stabilized them with glass beads and hot glue.  The containers became the shell and mount for the PCB.  The beverage lid was provided by another ziploc container hot-glued onto the buttons.  Hot glue for grip and stabilization of the platform finished the job.  See the result in the pic below next to the finished shells.

Luckily, the 3D Printer roadblock was cleared just two days before the BBQ.  Poor quality filament lead to clogged extruders.  After a good cleaning, we were back in business.  5 shells total were produced with various upgrades.  We got a top that nested well with the shell, and the mouse-hole in the shell was added to allow the USB to be passed out of the body.  We did not get impressions in the top to get the lid closer to the lens of the LED.  We also did not get any part of the body held together by magnets.

Final assembly took place at Toxic BBQ itself.  The lights stayed on this year, but we started conversations and passed out some business cards with links here.  We placed a few on the tables farther out that didn't have light, and we presented two to the organizer in a Utilikilt.  Furthermore, it went on display in r00tz and the HHV for most of the convention.

Final Word

I left DEF CON for two years running with a profound sense of my own shortcomings.  I saw people around me doing amazing things, but I couldn't point to similar achievements for myself.  Though not terribly complex (most ideas came from Instructables, after all), the process and coordination required to pull off this simple idea has been eye opening.  It all started by pivoting from planning to doing.  It finished with an 80's-montage-worthy string of late nights and high fives.

Already, these efforts are fertile ground from which numerous other ideas have sprung.  Facing another DEF CON, I'm looking for the next big project instead of lamenting my noob credentials.  Only time will tell how many of these work their way to reality.