Monday, March 5, 2018

Taking an AXe To It: Starting Accessibility Tooling (#CNC2018 #BLOGMORE)

I am rather far behind with my commitment to the #BlogMore challenge in the #CNC2018 campaign. Part of that is, of course, “life is what happens when you are busy making other plans” but more specifically I came to a conclusion that my original outlines were way too ambitious.

My topics as outlined were more suited for chapters for a possible book rather than single blog posts. Thus, I have decided to take something from each of the outlines and get very specific. Rather than do a vague post about Accessibility and Inclusive Design, I will focus on a specific tool that will allow me to address coding and design more directly.

There are numerous tools available that will allow programmers and testers to evaluate websites and applications for Accessibility and Inclusive Design. This post will be about just one of them. aXe is a tool developed by deque. It is open-source, free and runs inside of the browser along with a variety of Developer Tools. Currently, two versions are available (for Chrome and Firefox).

Adding an aXe to Your Arsenal

Installation is straightforward. Start by navigating to the download page for the extension (here’s the flow for Firefox):

1. Click on the Add to Firefox button.

2. Give aXe permission to be added as an extension.

3. After installation completes, this confirmation screen will appear.

4. Depending on how many add-ons you have, you will see something similar to the following on your Firefox browser toolbar.

5. Click on the aXe icon to get a help message. aXe is part of Developer Tools and appears within that context.

My preferred way to open Developer tools is to just click anywhere in the browser main window, right click, and then select “Inspect Element”.

If your installation went correctly, you should see the following. Click on the aXe navigation bar header to see the screen below. If you see this, you are good to go.

Press the “Analyze” button on your chosen web page. I might as well pick on myself. Let’s have a look at

See that output at the bottom? That’s an indication that I have some stuff to deal with.

I hear you saying, “well, OK, that’s… interesting… what exactly am I looking at here?”

A First Pass at your aXe Analysis
aXe gives the user a condensed listing of issues found. Let’s take a look at the listing in more detail:

The top section displays the number of Accessibility violations (in this case, 95 of them). The listing below the violations count is an area that says “Needs review”. These are potential violations, but they may not be. Let’s take a look at one of them:

We can see the issue. The validator cannot actually determine if the color contrast of the title is compliant. The reason is that there is an image beneath it, and that image has varying shades, where in some areas there is definitely a bold contrast, but in a few areas, the “whites of the Tachikoma’s eyes” are right next to the text. Below the issue description is the actual code that is being evaluated.

In this case, I have two choices. I can either tell the system that this is not an issue and move on, or I can consider how to match both the letter and spirit of the issue and fix it. Options are I could remove the image, or I could darken the image significantly so that all areas are in sharp contrast.

Additionally, I can do some sleuthing through the tool by clicking on the “Learn more” link next to the description. I can also click the “Inspector” link and see the element in context with the surrounding code for the page:

Clicking on “Highlight” will focus on the element in question but leave us with the review screen:

Having given the code a once-over, I can now (if I choose) make a decision for a course of action. In this case, I am going to make the executive decision to leave the image as it is and say that it is “not an issue” because, for 97% of the text, there is ample contrast.

By selecting “This is not an issue” and clicking the “Save” button, I update the aXe database and move on to the next issue that needs review.

If you followed along, that should give you some feel for how you can quickly use aXe to validate a number of Accessibility issues on your chosen page. There's plenty more where that came from, to say the least, and I will be getting into more details in future posts, both with aXe and a few other favorite Accessibility tools.

Monday, February 5, 2018

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Mission Two: Blog Outlines and Schedules

Week three and mission two are completed. My thanks to Christian Haas for feedback and some additional commentary in this post :).

This week's homework for Blog More is to complete an outline for each of the three blog post ideas.

1. Post your favorite outline below.
2. Find someone’s posted outline in the group and give them some feedback. What stands out to you? What points were most interesting? What did you want to learn more about? Be kind but specific in your feedback.

Mission 2:  Outlines and Schedules

My Top Three

1. Writing Code around Accessibility and Inclusive Design
  • Intro: a quick explanation as to what Accessibility and Inclusive Design are.
  • Sample Code that is not accessible and why (web example)
  • Using Inclusive Design Patterns to help set the stage
  • Changes to code that will make it more accessible
  • Methods to check and validate such things
  • Sample Code that now IS accessible and why (web example)

My initial thoughts: 
I’m realizing this is a topic I could write examples for every week for a year and probably still have plenty to write about. I will probably have to tailor this down to an introductory article first and then go into specifics about individual inclusive design patterns, etc.

Christian's comments:
I'm curious about this topic as a whole. For me, your first entry could be about setting the stage, with one or two examples showcasing how far the topic could reach. I myself am more interested from a theoretical point of view. It would affect my daily work only if there were info/references to "closed" systems; I'm not working on web UI, but for a dedicated, trained, target audience using Java UI.

My follow-on thoughts based on feedback:
This is an interesting angle and one I hadn't considered. How do we make applications accessible in a more specific programmatic focus? By Java UI I am assuming these are applications that have a command line style interface or otherwise interactions at the Operating System level and not online or via the web. To be honest, I haven't given a lot of thought to how this would work for a command line application, but it's an interesting thought experiment. When I'm writing a script or some interactive piece of code, how Accessible or Inclusive am I making those interactions? Definitely worth considering.

2. Skeleton Keys: a resource for TDD/BDD in the shell and other programming languages
  • What is skeleton-keys?
  • Why would anyone need it?
  • TDD/BDD in the shell? Really?
  • Unit Testing Tools in three languages (bash, ruby, and python)
  • Starting small: structure, tests, and output
  • Compare and Contrast the three languages and approaches

My initial thoughts:
Why did I pick three languages? OY!!! Oh yeah, so I could actually make some comparisons. I think these might end up being rather long (like book chapter long), but on the plus side, once I get this started, I will probably have plenty to write about for a very long time.

Christina's comments:
Bash: yes - Ruby/Python: is there a particular reason to have both? I don't have experience in either language and see (from the outside) they are somewhat similar in terms of capabilities. Mainly procedural with object-oriented additions; weak type system, and interpreted. For a broader coverage, it should have a variation in perhaps at least two of these points. (e.g., using C, C++, Java, C#, Go, or ...). Since you already identify that this can be done in various languages (taking time and effort to write this), I suggest that, if you want three initial examples, they should be quite distinct from each other. Or reduce to two. (Or give particular reason why Ruby & Python)

My follow-on thoughts:
This is a very good point. I picked Ruby and Python mostly because they are languages I'd been either working with or had some recent exposure to and wanted to set up as a way to focus on some starting poitns for those languages. Having said that, they are two languages that fill a similar niche. They're not the exact same, but Christian makes a good point that they are similar enough that they may not prove to be all that interesting a comparison. Perhaps using a language such as Java or C++ would make more sense, though I haven't used either in a meaningful way in a long time. Still, for this purpose, it may make for a more interesting comparison, so worth re-examining.

3. Creating a framework from the ground up (Jenkins, Docker, Protractor, Angular, Jasmine)
  • You Keep using that ‘Framework’ word. I don’t think it means what you think it means.
  • Jigging your Jig-Saw Pieces (short intro/tutorial on all five pieces, including installation)
  • Setting up a basic application to test
  • Puting the onion back together
  • writing the Angular App
  • testing with Protractor/Jasmine
  • putting it into Docker
  • managing it with Jenkins
  • Lather, rinse, repeat

My initial thoughts: 
This would make for a great series with a minimum of five posts for each piece (plus the many that I haven’t even mentioned yet, such as plug-ins or add ons to make the job easier to manage).

Christian's comments:
With your first point about using "framework" wrong, I suspect this title is intentional. Still, is the overall goal to write a Javascript based template project?
If so, I'd be less interested as I don't work in JavaScript (That should not be a reason to change your goal, I understand that), though, if it were pitched as "how to create a template stack with Jenkins, Docker, ..." might be half interested as I'd consider an automation pipeline for different languages. Perhaps this could even be a two-parter: How to set up a build-pipeline with Jenkins & Docker and then specializing it for a JavaScript project, and then specializing it for a Java project for instance... (These are all just ideas, I believe your thoughts go already in that direction...)

My follow-on thoughts:
Yes, the use of the word "framework" in both the title and the shout-out to The Princess Bride reference is in part to say that the word framework gets thrown around a lot and maybe doesn't really mean what a lot of people think it means. My goal is to address the broad areas and try to see how to implement the pieces. Just setting up the scenario would be a series of posts (setting up Jenkins, working with git, creating docker containers, setting up a project, making tests for the project, running those tests, making sure they integrate with the CI pipeline, etc.). Perhaps skeleton-keys could be the project that allows me to put this all together and integrate into a series of posts.

One thing is certain, this challenge series is showing me that there are plenty of things to write about in these spaces and I will probably have ample to write about for a long time.

Monday, January 29, 2018

Code Newbie Challenge 2018: #CNC2018 #BlogMore: Mission One: Blog Ideas

The first official mission for the Code Newbie Challenge has completed. Here are my follow-up and thoughts about this week's assignment.

Mission 1:  Three Ideas

Develop and validate the three blog ideas for this challenge.

Come up with 10 blog ideas, then narrow those down to 3.

This challenge had a lot of great supporting material to help people get into the mindset of what it would take to create a technical code blog post. 

  • Search Twitter for hashtags related to areas of interest.
  • Search blogs that talk about areas of interest. Medium,, FreeCodeCamp, Hackernoon, Codeburst, basecs, Mozilla Hacks, etc.
  • Look at Newsletters like JavaScript Weekly and RubyWeekly
  • Think about things I am actively working on and wish there were posts that answered my concerns.

Aim for ten ideas. Here's the list I came up with:
  1. Examining Accessibility and Inclusive Design (this is my personal touchstone topic, as if I really want to make a transition to writing code, I want to do it in a way that can help me advocate for Accessibility and Inclusive Design better) - Explainer for concepts, tutorial or project for specifics
  2. Walking through Developer Tools that emphasize Accessibility - Explainer
  3. Making a Skeleton Resource for Coding (my biggest problem is getting started, so my overall goal is to make something that will help me do that. I figured I could explain along the way as I make it). Project, possibly tutorial
  4. Writing shell scripts using TDD and BDD principles (using shunit2) - Tutorial, Project
  5. Quick Fixes for Big Headaches (the shell can be your friend) - Project
  6. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine) - Tutorial, Project
  7. Containers for the curious (Deploying Docker on your local machine) - Tutorial, Project
  8. Blending Angular, Protractor and Jasmine into a testing framework - Tutorial, Explainer, Project
  9. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
  10. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer

Narrow it down to 5:
Many of the ideas I came up with are not so many ones I would want to eliminate as they are either peripheral to or prerequisite of what I'd want to write about. By taking my original list and grouping them, I came up with the following more condensed list:

  1. Examining Accessibility and Inclusive Design, Walking through Developer Tools that emphasize Accessibility  - Explainer for concepts, tutorial or project for specifics
  2. Making a Skeleton Resource for Coding, Writing shell scripts using TDD and BDD principles, Example shell fixes to demonstrate the project - Project
  3. Deploying your own little CI Pipeline (Deploying Jenkins on your local machine), Containers for the curious (Deploying Docker on your local machine), Blending Angular, Protractor, and Jasmine into a testing framework - Tutorial, Explainer, Project
  4. Road Rash: Cautionary Coding tales while the wounds are still healing (I did something, I got stuck, it hurt but I figured a way out of it) - Explainer
  5. How Would You Automate This (an actual Series I’m Currently Working On) - Explainer
One of the reasons I ordered this list this way is that I couldn't figure out how to put Road Rash into another location other than as a sidebar, and it felt the weakest of my choices. How Would You Automate This I deliberately put at the bottom as I'm already writing the series. I want to emphasize posts and areas that I'm not already doing or that would actually be new territory for me.

Validate your ideas
I received some great feedback and interest from several people who reviewed my list and who expressed interest in seeing certain topics get covered. That had a lot to do with my grouping and decisions on which topics I would want to focus on.

Pick your top three

The top three and the working titles for each:
  1. Making Your Pages and Apps Accessible Using Inclusive Design Principles
  2. Skeleton Keys - A Project for Getting Started in bash, Python, and Ruby
  3. A Testing Framework From the Ground Up - Jenkins, Docker, Angular, Protractor, Jasmine

Turn In Your Homework 
Turned in to the CNC2018 Facebook group, but also this blog post :).
Bonus Reading 
Here are some additional blog posts to check out:

Saturday, January 27, 2018

Book Review: How To Become A Web Developer: The Career Changer’s Guide

One of the most difficult to pin down topics and titles of the last couple of decades is to define oneself as a web developer. What exactly does that mean, and what skills does one need to know to become one in this day and age?

Julie Torres, one half of the "Code Crush" podcast, has done what I feel is a good job distilling that into an 86 page book titled, specifically enough, How to Become a Web Developer: The Career Changer’s Guide.

Starting with the Prologue, Julie describes the specific circumstances that started her on this journey. With a softening job market during what we now refer to as “The Great Recession,” Julie describes how she moved from being a bank teller to become a junior developer. Her point in sharing this story is to make clear that you don’t need an advanced degree in computer science or have lots of history as a programmer to make the shift into doing web development. This book pledges to help you make that transition. Does Julie deliver on that promise?

Chapter Zero: Prepare for the Journey 

Julie sets out some basic markers to help you make the most of this journey including the idea of starting your job hunt while you start your web development journey. Counterintuitive, but makes good sense. Looking at what is out there, what is required and what skills are consistently being asked for is a great way to tailor your learning path. Utilizing Meetup groups and other resources will also help. Determine how to measure your progress, whether that be a way to check in with an online community or work with a specific mentor or group of people. In this day and age, showing goes a long way and having resources you can demonstrate to show your skill can be a big boost in this process. Code repositories and websites in the cloud to show your work can help tremendously. Don’t be concerned with whether or not you “measure up” to others out there. At the start, you won’t but your journey is yours and that’s what matters.

Chapter One: First, Choose Your Goal

Front End, Back End, Full Stack, Mobile, and a reference to QA by way of automation. This particular part touches me because I am primarily a tester in my work role, but many web development skills are still part of my daily repertoire. I’m glad Julie include testing on the list because many developers do actually make a decision to look at testing as a primary responsibility. The point is, deciding where you want to place your efforts will make a big difference in what you study and in what order. Likewise, there’s no rule that says you have to be permanently committed to any one goal, right?

Chapter Two: Choosing Your First Programming Language

Languages have a lot to do with the applications or environments you want to work on. Java is now a perennial favorite of many organizations because it is ubiquitous. Large corporations use it, Android devices use it, and there’s a large ecosystem for the language. It’s a wordy language, true, but the benefit is that there’s a lot of examples out there to look at and review. JavaScript is a language that has spawned numerous libraries and smaller ecosystems of their own. When you see people asking about Angular, Bootstrap, jQuery, React, etc, those are all specialized JavaScript frameworks. PHP is a great language specific for a large number of existing sites. Python and Ruby are also popular languages that also run in web stacks (Django and Rails, respectively). What you use will depend a lot on what you ultimately want to work on. If your dream job is making iPhone apps, you may want to take a look at Swift. The key is start with where you want to go and then pick what you will work with.

Chapter Three: Paths to Learning

You may be thinking “I don’t have a Computer Science degree” and that’s totally fine. Many of the best developers I’ve know have degrees in completely different disciplines. Whether you choose to go to college, do a coding Bootcamp or use an online resource like freeCodeCamp, the point is you have to put in the time, get frustrated a little and work through the issues you will undoubtedly face.

Chapter Four: What Skills Do You Need?

The foundational skills necessary are surprisingly small. Yes, it helps a lot if you can touch type and do so at a decent speed. Knowing how to use a computer or mobile device well is important especially if you can understand how to open, edit, move and manipulate files and directories. Understanding fundamental math skills and having a good understanding of the scientific method is also very helpful (not mentioned in the chapter and were I to suggest any additional basic skills to include I’d strongly suggest that one ;) ). From there, you will need to learn about how to use the command line of your chosen operating system(s), understanding the basics of HTML and CSS, using a version control system to chart your progress and, on occasion, back up and go to an earlier time to do something different, and understanding of how the Internet works (TCP/IP and HTTP, for example). From there, databases, return codes, error handling, and flow control of programs will come into play. Sounds scary? In truth, it’s fairly straightforward but the devil is in the details. Again, the key here is to understand what you want to do and then plot the course to get there. It will require a fair amount of knowledge buildup and experimentation, as well as false starts and frustrations. Julie goes into some detail in this chapter about the various frameworks available, sample programs and applications you can develop and ways to display them so that people can notice your progress.

Chapter Five: Things to Ignore (at Least For Now)

Depending on what it is you wish to work on, there may be many skills that will be important later on, but that you do not need to worry yourself with at the start or even in the first few years of your progress. You may never have to get familiar with topics like binary, specifics of computer hardware, or the underlying computer networking infrastructure and communicating with the lower layers. There is a list where there are things that will be helpful to understand later on and while I agree with much of the list, I have to take issue with testing being considered not so important. Personal opinion time, I wish more developers would put testing and a testing mindset at the forefront of their learning. It will help encourage more developers to see what they are developing, to begin their work with questions of quality and experimentation in mind and to ultimately help deliver a better product to their users.

Chapter Six: Learning Resources

This chapter includes a list of resources to help fill in key concepts and skills you may need. Many of them are completely free, while some have a small cost associated with them (small is relative, of course). Julie also includes a variety of blogs and websites that can also be helpful (I too am a fan of the Tuts sites and encourage people to check it out).

Chapter Seven: Staying On Track

The chapter starts out with this quote:

"Learning to code is more of a motivational challenge than a technical one." -- Quincy Larson, Founder of freeCodeCamp

On the whole, I agree with that. How we keep ourselves motivated is important, and finding our true motive is also critical. Do we want to make more money? A good place to start but may not sustain us in the long run. Chose methods that will help you stay committed to your goals, such as participating in meetups, hackathons, or other projects you can do with other people to get feedback and feel connected to what you are doing.

Chapter Eight: Career Goals

Just as important as what you want to do is where do you want to do it? Do you want to work for large companies or would you be interested in working for smaller organizations? Understanding the tradeoffs for each is important. Large companies can have great infrastructure but very defined ways of doing things. Smaller companies may be more chaotic and struggle with getting to profitability but the sky's the limit with where you can potentially get involved. You can also work with various employment agencies on a contract basis to rotate jobs and gain experience. Once you have a good enough foundation, you could perhaps hang up your own shingle, so to speak, and freelance. Don't be surprised if you find yourself doing a little of all of that, especially in the first few years.

Chapter Nine: The Job Hunt

Remember that advice in Chapter Zero? Here's where doing all of that this whole time should start helping. If you have been communicating with a variety of people along your journey, they may take an interest in what you have put together and speak with those in their organizations that have a hand in hiring. Resumes still matter at a lot of places, but they are taking a backseat to demonstrable ways that you can show your skills. In this day and age, tools like LinkedIn, GitHub, SlideShare, and a blogging platform can do a lot to boost your visibility as well as have lots of examples of demonstrable skills. Additionally, connect with people and communicate with them. The key here is to start this process well before you need to look for a job so that when you are ready, you have already identified people who you can communicate with. Another bonus is that, if you do this regularly, they will likewise know you are ready and can help you find your next gig.

Chapter Ten: Interviewing

Whether it be initial phone screens, in-person general interviews or technical interviews, you will be judged based on how you respond. Having a good handle on a variety of skills and being able to explain them will go a long way in helping you with these interviews. You may be given a coding challenge to complete, either on-premises or as a take-home assignment. Practice a few of these so that you can feel confident that you can do them if given the opportunity or request. This chapter has a lot of practical advice for specific technical interview questions as well as how to negotiate for salary.

Chapter Eleven: Building a Successful Career

Once you get that first job, realize that it's the bottom rung of a new ladder. There's still much to learn and many areas that you can get involved if you choose to. Pay attention to sticking points in the organization and see if you would like to tackle those challenges. See where the rest of the market is going and if you feel that you are ready to pivot if market forces change. Most importantly, never stop learning.

Along with all of these chapters, Julie shares many personal anecdotes of her own journey that has brought her to where she is today. These vignettes help the reader see what choices she made, both for good or ill, that have helped inform the rest of the text.


For those who are looking for an in-depth guide to learning how to become a web developer, this book doesn't cover those except for skimming the resources needed to accomplish those goals. This is much more of a field guide to allow you to safely manage the trek and it is filled with a variety of markers that you may find interesting along your journey. As the title says, this is a Career Change guide, and those focusing on the "How To Become a Web Developer" are missing the key in the subtitle. This is a guide to navigating a career change. To that end, it meets its goal admirably.

Monday, January 22, 2018

The Code Newbie Challenge for 2018 #CNC2018: BLOG MORE: Introduction

Hello to new readers that are coming across this blog for the first time. To those who have read these pages for a while now, this should not surprise any of you at all ;).

I've decided to take on the Code Newbie Challenge for 2018. There are four "tracks" that you can choose. They are:

Start Coding
Code More
Blog More
Get a Job

I have chosen the "Blog More" challenge for a specific reason. Much of the time on this blog I have talked about testing and peripheral topics from a layman's point of view. I've strived to "speak dude" as often as possible, and to that end, I've kept coding specific stuff to a minimum. that sounds like a simple answer, doesn't it? Well, let's get real here. There's a darker secret. Part of the reason why I don't post code frequently is that I harbor a fear that people will look at my code and think it's simplistic, stupid or just plain lame. To tell the truth, that may happen. Maybe it won't. Regardless, I've always been a little leery of posting code samples beyond language tutorials because I've just been concerned about getting it picked apart.

That's the overwhelming reason why I chose this challenge. I can't get better if I don't actually put something out there, right? I can talk a mean game about what I know about things like automation and web development, but does it really matter if my actual code is lacking? More to the point, wouldn't it make a lot of sense to actually talk about code, show examples, explain it from my perspective and let people who do know about code comment on it?

Sure, it might bruise my fragile ego but isn't that the whole point? How do I expect to learn or actually demonstrate I know anything if I'm not willing to show what I actually know and take the chance that someone might be willing to tell me a better way to do it? On top of that, there may be lots of things I may be doing that are actually interesting and may be helpful to others. Finally, if I can explain what I'm doing in a blog post or several, I can explain it to anyone and draw on it when I write code in the future.

Let's get this party started. Each assignment as part of this challenge will be posted here. This is my own preamble to get the ball rolling. Look for the tags CNC2018 and CodeNewbieChallenge to see posts specifically targeted for this challenge.

Exercise Zero: The Pre Mission

Read 3 tech blog posts you wish you wrote. Jot down why you like them and what you'd change.

Find examples of good tech writing to see what you'd like to incorporate into your own posts, and what you might want to avoid. 

You'll refer back to these later in your challenge.

There are three styles that were described for this challenge. First is the "Tutorial", which actually walks through how to do something. Second is the "Explainer", which take a concept and breaks it down. Third is the "Project" which describes how to do something and gives actual examples that you can follow along and build yourself. The pre-challenge is to pick three examples, (one from each category) that I wish I had written, describe what I like about it, and what I would like to see to improve the piece.

Tutorial: "Protractor for Beginners, Part 1" by Hannah Pretswell

Why a tutorial on Protractor? Because it's what we are exploring as a replacement for our current automation framework. Nothing like a pressing business need to get your mind racing and your thoughts flowing. Hey, you know it will come in handy very soon, right? For starters, let me comment on something I really appreciate. Hannah said she struggled with getting the pieces to work together. Hearing that up front helps me in two ways. First, it lets me know that the tasks ahead may be challenging. Second, she also lets me know that she's done her best to document those frustrations and help let me know that I likely will succeed if I'm patient and follow her advice. Too often, I've gon through tutorials that expect a user to jump in and get moving with little concern over the sticking points. Gladly, that's not the case here.

Another positive is the fact that there are a fair number of repetitive steps. It's tempting to spell them all out, but by doing so, it makes updating a tutorial daunting and thus something the writer would likely not do. Instead, she points to a few additional tutorials already written that explain the process of setting up your environment and making sure everything is working correctly before getting started. Additionally, the resources listed point to the protractor GitHub page. This is a good practice because it lets the user get started with the most recent advice from the maintainer of the framework so that if the instructions change, the writer of the tutorial doesn't have to be the one to change the details on her site as well.

So, what would I have done differently? Truthfully, not much. I think it's a solid opener and it goes through the specifics as the first part of a tutorial should. I suppose I would have liked to have seen some example output of the code as displayed and some output of tests as well. For me, with a variety of tutorials, I think this is a good step so as to show what you could expect. I understand why many people don't in that OS changes and formatting details could put images like that out of date quickly, and it does add overhead to downloading what would in many cases be pictures to demonstrate the output. Still, on the whole, this is a really solid example.

Explainer: Test Driven Development in BASH by Torstein Krause Johansen

This is presented as a talk, but in many ways, that's a great way to explain a concept in a few words, with the impetus on the reader to go and learn more if they are so inclined. Specifically, I like the curt and focused content, the way the information is presented and the walkthrough of the ideas with examples. Each slide builds on the previous one and lets you see why the topic makes sense and the reasoning behind Torstein's approach. I was also excited to learn about shunit2 and I must say I'm more than a little curious at this point.

So what would I do differently? Again this is a set of slides from a talk, and at first glance, I'm guessing the HTML code was put there for a reason, but if the point was to demonstrate bash syntax and how it interacts with a testing framework, the HTML was distracting and made the underlying code hard to read. Again, I may be missing a key context here as to why that was presented that way (perhaps to prevent copying and pasting willy-nilly) but if that were the concern, I could see saving screenshots of the code itself and displaying pictures (great to prevent copy and paste but admittedly a nightmare to update and keep current).

Project: 10 Angular and TypeScript Projects to Take You From Zero to Hero by Dan Wahlin

This interested me seeing as I will be doing work with Protractor and Jasime as a testing framework for Angular apps. To that end, it helps to have something to look at, play with and practice on and these ten projects will allow me to do that. I like that the projects start simple and get progressively more difficult as they go. Each project is laid out with sample images of what you will build with links to each of the projects so that the project page is independent of each of the individual listed projects. The projects are lust listed with a title, a basic description, level of difficulty, a link to the files and some pictures of what the project will look like when completed.

On the whole, this is a nice layout and method. It leaves it up to the individual reader to decide where to expend their energy and each project simply links to the necessary packages to get them done. Were I to do it myself, I would probably split each project out to its own page and try to give some instructions about what to do with each. Having said that, the economy of having ten projects to choose from without a lot of navigation and page dancing is a good tradeoff.

There's the start. The assignments proper start on January 22, which is the same day this post goes live. Feel free to follow along and, as I tackle each assignment, your feedback and commentary is appreciated :).

Tuesday, January 9, 2018

It's That Time Again: The #StateofTesting Survey 2018

As in previous years, I have decided to take part in "The State of Testing" Survey and I encourage anyone else who is actively involved in testing endeavors to do the same. Note: I did not say "testers" need to take it, though that's likely who it's directed to. As I have become more involved in software delivery as a process, software testing is a key part of what I do, but it's not the only thing I do.

As I see it, software testing is transitioning. There will certainly be areas where dedicated testing as a role, a responsibility, and a job title will remain for quite some time to come. However, I also see that testing as a dedicated discipline in many organizations, if not disappearing, is definitely getting to be hazier. In previous decades, I might have been worried about that and truth be told, I was. Today, I take heart in the fact that there is much we all can do to be successful and do meaningful work. as I often remind myself, my mentor Ken Pier was fond of saying "there is always work moving from theory to practice".

The following I am borrowing directly from the Practitest QA Intelligence Blog, so I am presenting it in its entirety below (Thanks, Joel and Lalit :) ):

What is the State of Testing?

The State of Testing™ seeks to identify the existing characteristics, practices, and challenges facing the testing community in hopes to shed light and provoke a fruitful discussion towards improvement.
The final report is translated into several languages and shared globally, further expanding the reach and impact this report has on all of us in the QA world.
This is the 5th year that the QA Intelligence Blog is running this survey in collaboration with TeaTime with Testers, and with your help,  it can be bigger and more comprehensive than in previous years.
Each year the amount of participants has increased, and the final reports become even more valuable as a culminated reflection of testing trends, challenges, and characteristics.
So there you have it, another chance to take part in the State of Testing Survey is upon us. Are you interested in playing along? If so, click below and let's get to it :).


Monday, January 8, 2018

Geek Crush: Star Trek Continues

One of my goals for 2018 is to write about more stuff that interests me and that helps inform what I do day to day. Yes, TESTHEAD is primarily about software testing, but often there is a lot of stimuli that feeds into how I think about testing, and a fair amount of that stimulus cannot be boiled down to "here, use this and it will help you test things better". Still, I think there's a value to it and I want to be able to talk about it in some way, so as in the past, I'm making a heading so that, if you want to play along, you can. If you don't, you can safely skip over posts that don't interest you. That new heading is "Geek Crush", and yes, it's a play on words of Charles W "Chuck" Bryant's podcast "Movie Crush", only it covers a broad range of my geeky interests, many of which help directly or indirectly in my worldview and filter into how I think about testing.

My first entry into this comes courtesy of SacAnime, an event I attended this past weekend with my daughters in Sacramento, CA, USA. We've been going thee past few years and this year I specifically went because I was excited to learn that the primary cast of RWBY was going to be there and I wanted to meet them (a future post will most definitely feature me talking about my RWBY addiction, but not today ;) ). During this event, I learned that there was going to be a special screening hosted by Vic Mignogna of "Star Trek Continues". I went to the screening and left a huge fan and with a great desire to see a lot more.

Disclaimer: Star Trek and all related marks, logos and characters are solely owned by CBS Studios Inc. This fan production is not endorsed by, sponsored by, nor affiliated with CBS, Paramount Pictures, or any other Star Trek franchise, and is a non-commercial fan-made film series intended for recreational use. No commercial exhibition or distribution is permitted. No alleged independent rights will be asserted against CBS or Paramount Pictures.

First off, let's talk about what 'Star Trek Continues" is. For those who were fans of the original Star Trek Series with William Shatner, Leonard Nimoy, DeForest Kelley, Nichelle Nichols, George Takei, Walter Koenig, James Doohan, etc., you know that the original mission was five years to seek out new life in distant star systems and "to boldly go where no man has gone before". Well, the original series was canceled after three years, meaning that mission was never finished, at least not on film. When the movies started up in the late 70s, we picked up with them ten years later and "got the band together again", so to speak, with a lot of stuff happening in between. What happened during the last part of the five-year mission? What causes Captain Kirk to want to take a desk job? Why did Spock return to Vulcan and what led up to that decision? Vic decided that these were questions he wanted to see made into episodes, and thus "Star Trek Continues" does exactly that. It is a web series filmed in the tones, the style, the outfits and the literal zeitgeist of "Star Trek: The Original Series" with Vic Mignogna stepping into the uniform and mannerisms of James Tiberius Kirk. He's joined by Todd Haberkorn as Spock, Grant Imahara as Sulu and Chris Doohan (James Doohan's son) as Scotty.

First off, I have to say that Vic has pulled off something amazing. You literally feel like you are watching the original show, as far as the sets, the sound effects, the clothing and the mannerisms of the various characters are concerned. Vic explained that they went to great lengths to be able to do this because they knew that anything out of place would pull the audience out of the experience. Granted, Vic is not William Shatner and Todd is not Leonard Nimoy, so there are certainly visible differences. They also bring themselves into the roles, too; they are not slavishly recreating Kirk, Spock, or any of the other characters. Still, the feeling of the episodes, the tropes used, the acting style, the lighting, and makeup, all of it makes you feel as though you are watching the original series, down to the music and practical special effects.

I started watching Star Trek sometime in the mid-70s when it was being syndicated as after-school television. I did not have the experience of watching it when it was first on television but I well remember the feeling of wonder and excitement the original series provided to me during my elementary school days. Star Trek Continues brings back those feelings. I'm reminded of Gene Roddenberry's vision. Knowing how obsessive Vic is with his love of the original Star Trek, I am so excited that he made this and I am excited to see the rest of the series. If you are one who enjoyed the original Star Trek and had hoped that one day you might see more of it, here is your chance.

Thursday, January 4, 2018

The Testing Show: CodeNewbie With Saron Yitbarek, Part 1

Happy New Year everyone!

I'd like to present the newly retooled The Testing Show. New theme music (courtesy of my band Ensign Red) and what I hope will be a new streamlined format for the show. I've learned a thing or two about doing audio the past few years and I'm hoping to see us transition a little bit to a broader storytelling approach along with the regular interviews that we do.

To that end, that special guest I was talking about a few weeks back is Saron Yitbarek, the mastermind behind the CodeNewbie website, podcast, Twitter chats and recently the producer of the BaseCS podcast as well as running the Codeland development conference.

I joke during the intro in this show that I feel like a bit of a fanboy here, but seriously, I have wanted to interview Saron for a long time. I was a little nervous asking if she'd be on our show with her level of visibility, so I was overjoyed when she said "yes" and even more so at the natural conversation that we had. She's not just a great interviewee, she's an excellent interviewer as well, so there was a really fun give and take on this show. To that end, I likewise decided that my traditional heavy grammatical editing style wasn't suited for this conversation. Some of the audio may sound a little less slick by TESTHEAD standards, but I feel it adds to the immediacy and excitement of the conversation. I'm not kidding when I say I was a bit giddy at a few spots in this episode.

All right, fanboy gushing aside, this episode covers what I think is interesting ground. Saron is perhaps one of the few guests who has never identified as a software tester, but she totally gets testing. What's more, she totally gets the frustration of getting up the courage to commit to learning how to write code (and yes, it takes courage to do it). It takes courage to be continuously frustrated. She also shares a lot of her ups and downs and frustrations that she has had during her own journey, and how she uses that as fuel to help support others on their coding journeys.

We recorded for almost two hours, and it has been a struggle to decide what to keep the focus on for these interviews. I'm hoping I've captured the best of the conversation, but I'll leave that to you all to decide.

If you enjoy listening to The Testing Show, I'd like to ask you a favor. Please go to Apple Podcasts and give us a rating. If you feel we deserve five stars, please give it to us :). If you feel we deserve less, that's fine too, but please leave a review and tell us why you feel that way. Give us a review as to why you think we deserve five stars while you are at it :). We aim to make The Testing Show the best podcast we can and if you have thoughts about how we can make it better, as the producer, I'm definitely interested.

The Testing Show: CodeNewbie With Saron Yitbarek, Part 1: The Testing shows talks about the process of learning how to code, so we talk with Saron Yitbarek about where and how to start. Tune in to learn more!

Sunday, December 31, 2017

Where Does that Highway Go To?

It's that time again, the end of another year. With it a chance to reflect on some of what I've learned, where I've been, what I could do better and what I hope to do going forward.

This year has been a good one for the Testing Show podcast. In the software testing world, outside of the work I do each day, I would say that this has been my most consistent endeavor. I've been pleased with the episodes we have done this year and I am excited about more episodes that will branch away from the typical topics that we normally cover and aim to strike out into other areas that are important to software testing but may not be solely focused on the testing aspects alone. Also, as it will go live in the middle of this week, I can say there will be one noticeable change. New theme music will be part of the 2018 series of shows.

In my workaday world, I had an odd situation that required an adjustment and a change in work habits for me. I started the year with just a handful of people coming to our office to work each day and quickly that changed into my being the only person coming into the office most days. I felt a bit like the lone lighthouse keeper much of the time, though of course, the team communicated regularly through digital means. This year, as I was the one person coming into the office, our parent company decided it didn't make much sense to pay for a large office space that only one person was using. The office was closed and I was transitioned to being a 100% remote worker. This is a first for me. I've had the option to work from home much of my career, but it was a couple of days a week. I've never worked in an arrangement where I was 100% at home, all the time. That's been my reality since October of this year. I'm adjusting, but I do have to say it still feels a bit strange.

On the family front, my son moved away from home to embrace his dream of being part of the music industry in Los Angeles. I'm proud of him for chasing after his dream, but part of me is way too familiar with the entertainment industry and its many promises made but so few kept. He sends me texts that remind me of myself at his age when I was sure I was going to conquer the world. I have to fight the desire to tell him I know that tone so well, but in truth, I don't know his reality. I remember mine. Therefore, I do my best to hold my tongue and just let him tell me what he is doing and keep the peanut gallery comments to a minimum. It's hard, to say the least. On the bright side, he's more interested in the production and marketing end of entertainment, not being the actual performer, so he has better odds than I had ;).

On the physical front this year, as I tested out a variety of fitness approaches, trying to maintain a target weight and chasing metrics to define quantitatively how physically fit I was, I came to some stark conclusions. Numbers are artificial, they can be gamed, they can be detrimental to long-term success, and most importantly, it's entirely possible to "be fit" and feel completely miserable. That was a conclusion I reached this summer. Yes, I was 194 pounds, but I was also anemic and unable to donate blood, I felt tired much of the time, I got sick more frequently. I allowed myself to put a buffer between that lower point and I voluntarily gained back 20 pounds. Since around November, I have hovered between 215 and 225 pounds. It doesn't sound as dramatic, but it sure feels a lot better. In 2018, my goal is to focus more on body composition and worry a lot less about my actual weight.

Some longer-term initiatives I had to decide that I didn't have the energy or ability to do as often. Weekend Testing Americas is still a thing, but I found myself repeating where I'd been before and decided it was better to step away for a bit. I haven't shut it down, but I determined I needed to let some new blood take a shot or let it lay dormant for a bit. I'm feeling like I have some fresher ideas now, so do not be surprised if you see more Weekend Testing Americas sessions in the new year.

On the speaking front, I have kept my pledge to focus on Accessibility and Inclusive Design as my topics of choice, and those will also carry over into the new year as well. As I get older and I discover that my resiliency and "springiness" isn't what it used to be, many Accessibility and Inclusive Design aspects that were at one-time talking points have become "living points" for me. As such, the lack of sites that follow guidelines and the limited testing being done to help sights be more inclusive matters more to me now than ever. Additionally, I've decided that I want to do some more writing on the topic in 2018, with concrete and specific actions people can take.

As my company is making moves to modernize many of their testing frameworks, I'm taking advantage of the changing landscape to try to learn more about setting up a new framework from the ground up. At the moment, I'm championing an approach that uses Angular, Protractor, and Jasmine over our older successful but decidedly proprietary setup. Our testing team has decided to try a number of experiments and see where they lead us, rather than going all in on a particular strategy. To that end, I aim to learn a bunch of things with this approach and I also aim to talk about it as much as I can. This blog has been lean on my "learning in public" experiments as of late. It's time I got back to that.

My thanks to everyone who has worked with me, interacted with me, been part of The Testing Show podcast as a regular contributor and as a guest, shared a meal with me at a conference, come out to hear me speak, participate in a Weekend Testing session, shown support to the Bay Area Software Testers meetup, and otherwise given me a place to bounce ideas, think things through, and be a shoulder to cry on or to just hear me out when I feel like I'm talking crazy. Regardless if you have done that just a little bit or a whole lot, I thank you all.

Here's wishing everyone a happy, healthy and sane 2018. I look forward to talking with you all in the new year and beyond. Also, thank you, Talking Heads, for the song "Once In A Lifetime" as it has provided me so many clever titles for my year-end posts these past seven years (well, I think they are clever; your mileage may vary ;) ).

Wednesday, December 20, 2017

The Testing Show: Hiring and Getting Hired

It's been a big year for The Testing Show and this is the last episode of the year that is 2017. We were happy to have Gwen Dobson join Jessica Ingrassellino, Matt Heusser and me to talk about the changes that have taken place in the testing market over the past few years.

We riffed on a number of topics including the laws that prohibit asking about salary histories, having that discussion about money and making the best case for your worth, marketing your skill set and leveraging the variety of platforms at our disposal to help sell ourselves and our personal brands.

It's been a great deal of fun to produce and participate in this podcast and I'm looking forward to the new topics and guests we will have in 2018. I am actively working on a two-parter for January with a special guest that you are just going to have to wait and see/hear who it is, but I can say I've wanted to interview this person for a long time and I'm excited about presenting these episodes, along with some other changes for the show in 2018.

With that, please jump in and have a listen to
The Testing Show: Episode 50: Hiring and Getting Hired: