Book Review: Team Guide to Software Testability: a #30DaysOfTesting Testability #T9y Entry

Woohoo!!! Day 30 completed on March 31! Truth be told, this was a bit much and I have no one to blame but myself for how this turned out. Still, I feel like I learned a lot and covered a lot of ground. Some of it felt familiar but there was quite a bit of new information and perspectives I had a chance to look at and think about how to implement with my team. It's time to bring the formal "30 Days of Testability" to a close and to do that, I'm going to review a book that, as I came to the Ask Me Anything post, made me realize that the sudden availability of this book wasn't an accident, as one of the authors of the challenge, Ash Winter, was also one of the writers of this book. How convenient :)!

What book did you choose on Day 3 and what did you learn from it?


The book I chose was "Team Guide to Software Testability" by Ash Winter and Rob Meaney.

This version was published with Leanpub on 2019-03-08. Again, mighty convenient :)! While the book is listed as being 30% completed, there is plenty to consider and chew on with regards to testability for apps and navigating how to approach testability for you, your team and your applications. To borrow a line from the Introduction:

"We want to show that testability is not only about testers and, by extension, not solely about testing. It is almost indistinguishable how testable your product is, from how operable and maintainable
your product is. And that’s what matters to your (organisation’s) bottom line, how
well your product fits your customer’s needs."

Testability goes hand in hand with predictability. When an application responds in a predictable manner, we are able to interact with better certainty that we will see the results we expect. That, in turn, helps inform the testability or lack thereof of our applications.

Testability Mapping allows users and teams to get a better feel for the areas of their application that are working well and those that still need to be worked on. When we have a low understanding of the underlying testability architecture, we often struggle with anything approaching effective testing. To help address that, it's important to take stock of the testability of our applications and see how far afield that might take us (applications are rarely monolithic today, they have dependencies and other components that may or may not be obvious.

Our testing environments should be set up and configured in a way that allows us the maximum understanding of its underpinnings. Doing so lets us get started with testing and receiving meaningful feedback from the application. Paying attention to these environments and periodically addressing the testability helps make sure that complacency doesn't come into play. Environments are not static, they grow and develop and the technologies that are good for one period of time may be inadequate later.



Bottom Line:

Even at 30% complete, there is a lot of good information in this book. Is it worth purchasing as it currently is, with the idea that more will arrive over time? I say "yes". If the idea of helping your team develop a testability protocol sounds exciting and necessary, there is a lot to like in this book. Check it out!!!

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.

BOTTOM LINE:

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.

Laws and Guidelines: Accessibility for Everyone: Long Form Book Review

IT's been a fun ride, but it's time to close out my long form review of Laura Kalbag's "Accessibility for Everyone".

I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

LAWS AND GUIDELINES

If you have ever set yourself down to reading the actual guidelines for WCAG, the U.S. ADA Section 508, or other guidelines for complying with requirements, you have probably felt a bit of frustration while reading them. That's because they are written in a legalese that only attorneys would love. Additionally, one of the biggest reasons that Accessibility projects are undertaken in the first place is because there is a threat of legal action, if not currently then in the future at some point. The retail chain Target and the UK airline Bmibaby are two high profile examples where legal action was taken due to sites not being Accessible to all users.

As mentioned above, in the USA, Section 508 is the part of the Americans with Disabilities Act that deals with making electronic communications available to everyone. It specifically has teeth when it comes to government agencies purchasing and using products. As I had mentioned in other posts in this book review series, my current company went through a large scale Accessibility project because a large entity wanted to purchase our product, but that product has to meet Section 508 guidelines. You may be asking, "was it a government agency?" The answer is, "Yes."

Europe has its own standard similar to Section 508. It's called the European Accessibility Act, developed to work along with Article 9 of the United Nation’s Convention on the Rights of Persons with Disabilities (CRPD).

Many of these legal guidelines point to WCAG and consider compliance with it to be sufficient to match the legal codes. As Laura points out, there are four fundamental principles that underly the WCAG guidelines (the following is right out of the book):

• Principle 1: Perceivable—information and user interface components must be presentable to users in ways they can perceive.
• Principle 2: Operable—user interface components and navigation must be operable.
• Principle3: Understandable—information and the operation of user interface must be understandable.
• Principle 4: Robust—content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

WCAG hs three levels of conformance. Those levels are 'A', 'AA' and 'AAA' with the greater number of letters the more complete the conformance. Different organizations will aim for varying levels, with 'AA' being the most common. Achieving an 'AAA' rating is the ideal of Accessibility and Inclusive Design, but may not be feasible for many organizations, as it requires a lot of time, energy, and cash outlay to achieve it.

The key point of this section is the fact that Laws and Guidelines are all well and good if we want to ensure that we are not running afoul of legal commitments, and they have a tendency to "keep us honest", but that's a poor place to be keeping our focus. Much better would be if we were to consider that we are doing these things because they are the right things to do because we want to include people into our product usage because at some point every one of us will face Accessibility issues of some kind.

RESOURCES

Laura provides a lot of additional reading options for Accessibility, Coding Patterns, Animation, ARIA tags, Assistive Technologies, Color and Design, CSS, HTML, Guidelines, Internationalization, Planning and Research,  Performance, Typography, Subtitles and Captions, SVG Graphics, Usability, Validators and Inspectors, Video and Writing/Readability. There's a lot to dig into here and its safe to say that using these as a jumping off point, even if you only explore half of them listed, you will walk away with a lot of new skills and understanding of Accessibility that will stand you at least a head above many of your peers.

WRAPPING IT UP

If you have stuck with me this far, you probably have surmised that I like this book a great deal. It takes a broad and sometimes sticky topic and makes it "Accessible to Everyone". This is not a coding book per se, though it does have some code examples. It's not a design book, though it does cover a number of design ideas and techniques. It's not a "how" book in a strict sense at all. What it is is a "why" book, and at that level, it succeeds admirably. It's written in a plain and understandable style while not being patronizing. The examples are clear and easy to understand. The sections of the book build upon each other and allow the reader to "level up" with each chapter. The ordering makes sense in that they help shape why we should care before we get into the nuts and bolts of what we should do. Laura has put together a book that is focused, distilled and lacking "the boring bits", which of course falls into line with the ethos of "A Book Apart" and its publishing style. Would I consider this a worthwhile addition to my book library? The fact that I have done a long-form review like this should be ample evidence that I do, but even without this commitment, I consider "Accessibility for Everyone" to be a book that I will turn back to as I need to. The Resources section itself is worth the purchase of the book, but what you get in the preceding chapters will provide a great deal in helping anyone get a better feel for and a desire to want to make Accessivility a primary focus of their programming and testing efforts.

Evaluation and Testing: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

EVALUATION AND TESTING

Laura's main point of this chapter is that we can do all of the work, follow all of the guidelines, dot all of the 'i's and cross all the 't's and still fall well short of the intended goal if our implementation doesn't actually help our end users achieve their aims. Having been part of several Accessibility initiatives over the last five years I can attest that unanticipated things show up in testing or require the original hypothesis to be reconsidered.

That's great, so what is suggested? Well, for starters, make a plan. Whether that be a formal test plan or a series of conversations ons specific topics, the point is that there are a lot of criteria to be considered when looking at an Accessibility issue and creating a remedy for it. What approach will you use? How will you gauge progress? How will you document the testing progress? How will the testing results and recommendations be fed back into the development process? These are standard questions for any software tester, and how they are handled will vary between organizations, but they all go through this process in some manner if they wish to be successful.

One way to get a head start on looking at Accessibility issues is to become familiar with the WCAG standard. Different countries have their own standards, but WCAG is intended to be International, and as such will have a broad range of areas to look at. At times a local standard has some additional details that are relevant to that area, but usually looking at WCAG and meeting the requirements there will most of the time satisfy local requirements. The few that don't can be handled on a case by case basis.

The best test strategy is to literally use the product in the way that the intended customer will use it. If you need to rely on a screen reader, turn your screen off, or even better, find a dark room and do it so that you have limited ability to see the target machine. This is an example of persona testing taken to the next level, but I can attest to the fact that it is effective.

If you have the ability to participate in code reviews you have a chance to help shape the product at a fundamental level. Even if you don't, getting together with the programmers during the story workshop to discuss requirements can go a long way in helping to set up the necessary processes to ensure success. Also, a lot of the structural elements for Accessibility exist in the HTML and CSS, as well as other web technologies. That means that they can be looked at and confirmed to exist with automated tests. Still, don't be lulled into thinking you can automate all of the testings, as a lot of Accessibility comes down to the user experience. As of yet, that's proven to be a very tricky area to put automation into. For now, it still requires an empathetic human.

There are lots of tools available to the programmer and tester looking to validate their Accessibility work. Laura includes several that I would also consider excellent, such as:

W3C Markup Validation Tool
WebAim WAVE
Color Oracle

Laura has a much larger listing in the Resources section of the book.

KEY TAKEAWAY

The best way to test for Accessibility issues is to actively encourage and set up opportunities to test with people that actively use Accessibility software and devices. If that's not possible, then persona based testing is required and will have to stand in as the next best thing. There are lots of avenues and ways to test, lots of available tools, but ultimately it all comes down to one thing; can your intended audience of your product use it effectively? If there is a need for assistive technology, can that technology help provide a comparable experience for all of your users? If that sounds like a tall order, that's because it is. As I stated earlier, and as Laura also makes continuously through the book, we can work on Accessibility techniques but they don't amount to much if our users are frustrated in their goals. The best way to help ensure that doesn't happen is to test our implementations often.

Accessibility and HTML: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

ACCESSIBILITY AND HTML

This is the payoff point. With solid, well-structured HTML, most of the struggle to make sites accessible becomes very simple. That's it! Oh, wait, you want to know what that actually means, don't you ;)? Well of course and that's the meat of this chapter.

Many of us learn the basic HTML tags and we think that's all we have to do. Not much to it, except for the fact that there are lots of parameters for nearly every tag, and understanding those parameters can help immensely in making sites more accessible. Turning off CSS in your browser can be very informative, as well as jarring. Pretty sites get reduced to a listing of text and spaces only and with it a much clearer idea of how your pages are actually structured and it also shows how a screen reader would walk through it. If you find yourself scrolling through a bunch of stuff to get to the main content, imagine how it will feel to a user utilizing a screen reader waiting for it to "get to the point already".

Being effective with headings can do a lot to help structure your page in a meaningful way. Think of an outline for a paper or presentation. You put certain elements at those levels for a reason, right? Make sure to use your heading tags the same way (h1 - h6, etc.). Lists are also helpful to break up the content and make it more readable, so use the proper list elements (ol, ul).

Forms are a prime location for people to add extra code to help make sure that the user is putting the right information in. The downside is that, for many using accessibility tools, these enhancements will be confusing at best and completely bypassed at worst. Also, while it's a common convention to put a red asterisk to mean that information is required, having a tag call out that it is required, or literally spelling it out is better.

For many users, the keyboard is not just the primary input tool, it is the only input tool. Therefore, it is wise to use conventions that are well known and understood. Be careful making your own conventions or overwriting long standard actions.

Skip links are found at the start of many documents. Since users may be familiar with the content they are after and know how to find it, presenting them with a navigation bar they have to address each time can be both training and time-consuming. Putting a skip link in means the user jumps over the navigation elements and gets right to the main content on the page.

Tab order is critical, so make sure that users can get to the content they need in as few steps as necessary by using the (tabindex) option.

It should be no surprise that HTML that is generated from WYSIWYG editors is often literal, overly verbose, and overloads each tag with meta details that are better put elsewhere, so paying attention to how your code is formatted is important. Additionally wherever possible, try to keep structural aspects in your HTML and move the style elements, wherever possible, to CSS.

Another important aspect to consider when writing HTML for accessibility is the notions of "Progressive Enhancement and Graceful Degradation". In a nutshell that means "start from a basic framework and add the aspects and elements that allow for the specialized tools while keeping the base experience similar for all users. Likewise, Graceful Degradation is the idea in the opposite direction. If something fails or doesn't apply due to a user's method of access, don't just shut them out. Instead, make it possible to view as much of the content as possible, even if some of it is unoptimized.

If' you've been around Accessibility any significant length of time, it's likely you have come in contact with WAI-ARIA tags. WAI-ARIA stands for Web Accessibility Initiative—Accessible Rich Internet Applications and is helpful in allowing for certain tasks to be described in a more effective way, beyond what HTML and CSS ever intended. If you have ever heard a screen reader counting down and declaring the percentage progress of a file being downloaded, odds are that behavior is being defined in an ARIA tag.

Each of these areas is described in more depth, but they are not comprehensive breakdowns of each. As I will mention again when I do my summary review, Laura is not writing a "what" or a "how" book as much as she is writing a "why" book. As the title states, this is "Accessibility for Everyone" and that goes beyond the role of the programmer trying to make the site. The nuts and bolts are important, but the philosophy is even more so.

KEY TAKEAWAY

Meaningful HTML is the key, and to make HTML meaningful, we need to understand what it's best suited for and when it's better to let something else (CSS, ARIA) step in and take care of things like styling and more advanced interaction. Structuring documents effectively and understanding how to place the most important information up front helps everyone, not just those in need of assistive technologies. Also, it's good for the soul to see what your site tells you without the eye candy present. If it's a mess and hard to distinguish what is what, that's exactly the experience users who need assistive technology will have.

Content and Design: Accessibility for Everyone: Long Form Book Review

As seen in my last few entries, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

CONTENT AND DESIGN

Laura makes an interesting point in that all technology is assistive in some capacity. If we didn't have a keyboard, a mouse, a microphone, or speakers, how would we interact with the device? To that end, it helps to think of each aspect of how we interact and consider ways that we may be hindering the use of these basic tools. To borrow from the book directly here's a nice and succinct way to consider the four primary Accessibility domains:

1. Visual: make it easy to see.
2. Auditory: make it easy to hear.
3. Motor: make it easy to interact with.
4. Cognitive: make it easy to understand.

By contrast, if there is a limitation in one of these areas, we need to be aware of and prepared to make it possible to get the same (or similar) information into the other domains.

Sometimes people want to "shake things up" when it comes to design and approach. We might think it's silly to hold to "outmoded conventions" when it comes to icons and other things (I'm sure that there are many people who look at a Save icon who have never interacted with a floppy disk before). Still, the problem with that is that changing it to something new will potentially alienate and confuse those people who vividly remember what a floppy disk is and that it is nearly universally associated with "Save".

Methods of good accessible design are not that arcane, and many of them are already being implemented and you may not be aware of it. a navigation par that has descriptive listings can be a quick summary of a site's contents. It's tempting to pack sub-navigation bars and sub-sub-navigation bars in as a way to really economise and make information quickly available. For the mouse user, that may be true, but for a keyboard only user, sub-navs can be frustrating. Additionally, using mouse hovers to cause areas to pop out and be selected, again, is both non-intuitive and renders those not using a mouse unable to access the content unless an alternative method is provided. Using breadcrumbs or links to show where you have been previously can be helpful for those with cognitive disabilities as well as being just a nice thing to work with when you have to do several views in a hierarchy. Knowing where you are in that hierarchy shaves time and releases stress.

Links have had a long history on the web and their standard look and feel have helped make it easy for people to determine what tet makes a link, whether you have been there before, and something descriptive to tell you what the link represents. "Click Here" is a terrible linking convention. "Learn more about our services" works a lot better.

Writing for the web and for the greatest possible audience requires a balance. In my personal writing and anytime I try to write for my blog, I make a standard assumption that a sixth grader can read what I type. I don't always succeed, but that is the goal. To that end, breaking up paragraphs, using lists, bullet points, and other conventions to break up the flow is very helpful. Also, when possible, I encourage people to "speak Dude". If it's not possible to get a point across without technical jargon, that is understandable, but most of the time, we don't need to get overly flowery or "express overabundant facility via grandiose verbiage". That example is grammatically correct but bothersome to read.

Fonts can be rendered in a number of ways and it's important to realize that many font styles might look "cool" but could be painful to read. Using standard typesets and making the calling of the print easy for the user goes a long way in making the experience usable by as many people as possible.

Picture carousels, button increments and other cool uses of web "eye candy" can indeed show off your site and its features, but it can also be a chore to navigate through for users who are not able to use a mouse or view the pictures. Forms should allow for conventions that help make the process of filling them out as easy as possible, with prompts when something isn't correct, if possible, to be shown to alert an error before the users try to submit the form. Also, pages and content are able to change without the user doing anything on the page themselves. Dynamically updating copy is a reality, and making ways to alert users to that is important.

Color and color contrast can be a make or break for many people. Not enough contrast can mean it will be very difficult to see what is being displayed for some people. Higher contrast usually is better, but that may "clash" with your overall design aesthetic. Perhaps, but one can argue that your design is flawed if a sizeable population of your users can't even read the site. Also, color swatches by themselves without other identifying details like a text description can also lock users out of making relevant choices.

One of the longest standing and simplest to look for Accessibility issues is not using Alt text for a picture or an image that has significance to the page and the user's experience and reason for interacting with it. Icons such as Open, Save, Copy, Paste, if rendered as pictures, should absolutely have some other indicator of what that picture is. An Alt tag helps with that for those who cannot or choose not to display the pictures. A readable text description is also important, and the more descriptive. The better. "Picture of a girl next to a car" is OK. "Photograph of a woman standing next to a 1985 Alfa Romeo across from the Huntington Beach boardwalk" is even better.

Additional areas to consider are providing alternatives to content. Using the four domain examples, think about anything you are presenting and how that content may be locking people out. Consider alternative ways to provide that information. A video presentation? Provide closed captioning for hearing issues and a transcript for those with vision issues.

KEY TAKEAWAY

We often err on the side of what's easiest for us and we make decisions based on our normative experiences. Therefore, it's not surprising that a lot of design issues happen not because people are being deliberately callous but because they are trying to be expedient. To borrow from the old Larry Wall Perl maxim, we need to make sure "there's more than one way to do it" whenever possible. That's going to require some extra work, certainly, but the increased usability for more people will likely make up for that. Take some time to look at your site or app and think "what could be stopping people from interacting with this? How can I make it easier for them? How can I make it possible for the most people to benefit from my site or app?"

Disabilities and Impairments: Accessibility for Everyone: Long Form Book Review

As I mentioned yesterday, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. This is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book!!!

ACCESSIBILITY FOR EVERYONE

DISABILITY AND IMPAIRMENTS

One of the misleading aspects of Accessibility is getting a handle on exactly who is impacted and how many people that actually is. We look at disabilities and impairments as a single issue and try to address them when it is often the case that many people don't just struggle with one accessibility issue but with several. Vision, hearing, mobility, and cognitive impairments can run a spectrum from mild to severe/total in people. If we look at the US, nearly 38 million people deal with a disability (12% of the population). 16% of people in the UK have a disability. I personally have been dealing with impaired vision over the past few years, which is normal for people of a certain age and older. With my readers, I'm basically a normal computer user. Without my glasses, I now struggle mightily to make sense of what I'm seeing.

Language is important here. "Being disabled" speaks with a sense of finality, while "has a disability" means it is an issue a person deals with but it doesn't define the totality of who they are. Laura emphasizes this latter terminology, and I think it's a good approach. It helps eliminate the idea of disabled people being something other than or outside of ourselves. If we address Accessibility as something everyone will have to come to grips with at some point, it's easier to consider and plan for development, because we've framed the discussion as we can all expect to "inhabit the disability" domain at some point.

It helps to consider what disabilities we might be in for at some point. Laura makes an excellent breakdown of a variety of issues that people deal with in the disability sphere. Color blindness varies and shows up in men 16 times more frequently than it does in women (yes, women can deal with color blindness, too). Eyesight loss can be caused by many different things and can range from afflictions like glaucoma, cataracts, macular degeneration, astigmatism, etc. Auditory impairment can come in different flavors as well. There's total hearing loss, which has a number of causes, and gradual hearing loss, which is more common. Motor impairments can range a number of causes, including cerebral palsy, multiple sclerosis, rheumatoid arthritis, muscular dystrophy, ALS, etc. Traumatic injuries to the brain and spine can also cause motor impairments, ranging from impaired movement to total paralysis. Cognitive impairments are also an issue, affecting things like memory, attention, problem-solving, text processing and math processing. Dyslexia also falls into this area and some dyslexic users use screen readers to assist them in reading information on pages.

Laura also hits on a point that I often use when I talk about Accessibility, in that there are what we call "primary disability" and what I refer to as "situational disabilities" and what Laura refers to in the book as "environmental disabilities". The point being, you may be a normative user most of the time, but a situation occurs that temporarily makes you a disabled user. Noisy environments, having to deal with a different language, low light levels, and other environmental issues can greatly impact the way that you interact with your applications.

KEY TAKEAWAY

Statistics can be helpful, but they don't tell the whole story. We do much better when we can humanize the situation, and get into the worldview of our users, whoever they may be and whatever issue(s) they may be dealing with. By understanding the possible range of issues, both primary and situational/environmental, we can get a better understanding of how and where we can address Accessibility issues.

Accessibility for Everyone: A Long-Form, Multi Part Book Review

One of the things I find frustrating about technical books is that I often use them for a period of time, get an insight or two, go off and work on that insight for a while, and then I put the book down or look at something else until I'm in the mood for another insight, and the process repeats. Much of my technical library gets used this way. As such, I have hundreds of books that I have read part of, dozens I have read all the way through, very few that I have read cover to cover in a short period of time.

That makes it difficult to do timely reviews for certain books, so I decided I wanted to change that. Therefore, for the next undetermined number of posts, I will be reviewing Laura Kalbag's "Accessibility for Everyone". I have discussed with Laura my intention to do this, and she has given me her approval. Some may remember my chapter by chapter breakdown of Alan Page's book "How We Test Software at Microsoft" or Zed Shaw's "Learn Ruby The Hard Way". I'm planning on doing something similar this go around. However, this is going to be a review of the book and my own personal take on the concepts and ideas. I do not in any way intend for this to be a replacement for the book or otherwise want people to consider that reading my long form review basically means it's a Cliff Notes version of the book. I'm excited that books like this get written and I want to support Laura and other authors out there. If you think this book sounds intriguing, buy the book. It's officially available as of today :).

All right with that out of the way, let's get into it.

ACCESSIBILITY FOR EVERYONE

Let's start with Heydon Pickering's Foreword. For those not Familiar with Heydon, he is the author of "Inclusive Design Patterns", another book that I want to do a proper review for as well. He points out that dealing with Accessibility is a step out of the comfort zone for many, and admittance that we have, at times, not been kind to some of our users and also to acknowledge that people use their technology and the Internet differently. By thinking and designing inclusively and considering Accessibility up front, we can better serve a more diverse group of people, and that is a worthy end goal in and of itself. I wholeheartedly agree.

CHAPTER ONE: CONSIDERING ACCESSIBILITY

Generally speaking, Accessibility and Inclusive Design don't fall into the lap of one person. There's no single arbiter that determines if a site is Accessible, and if you are part of an organization that is set up that way, let's just get this out of the way now... "you're doing it wrong" (btw, that's me injecting color commentary, Laura didn't say this specifically ;) ). Accessibility doesn't happen in a vacuum and it cannot be addressed separately from the rest of the development of your site or app.

Are there excuses to be made for why Accessibility is not something every organization considers from the outset or places great emphasis on? Absolutely. Some see it as boring, or the connection with the beneficiaries is hard to pin down. We're afraid we'll do it all wrong, and the most likely candidate for peak excuse is "it's too hard and there's too much to do". Laura hits every one of these out of the park. I'm intimately familiar with every one of these resistance statements and yes, all of them can be true, but we can also rise above them if we are so determined.

Ultimately, Accessibility is making a choice to include as many people as possible. For some, that will mean making specific modifications to communicate with assistive technology. Laura uses a simple example to drive the point home with doorknobs. Doors with round knobs are less accessible than doors that have levers that can be twisted. Laura makes the point that even her dog can open a lever handled door (though she frequently wishes that were not the case). A sliding door with a motorized movement and proximity detector to open would be the most accessible and would work for everyone, but may be impractical to implement everywhere. In this case, the lever knob is as inclusive as possible and as practical. It's definitely better than the round knob. Tones at signal crossings, closed captioning, simple and clear signs, and my personal favorite example that I love to hate, IKEA assembly instructions ;).

To successfully approach Accessibility, one of the best ways to put us into that mindset is to develop Empathy. It's easy to dismiss products that don't serve our needs when there's nothing preventing access to us. At that point, it's a matter of taste and aesthetics. However, it becomes a different issue when a product conspires to work against you because of dense text, dependence on mouse or touch controls, use of certain elements or not using them to deliberately or not deliberately but unknowingly locking people out of using them. The fact that I now have to wear readers has had a profound effect in the way that I interact with technology today.

The symbol of Web Accessibility today is the "screen reader". In fact, for many people, the screen reader is the start and finish of many Accessibility initiatives. If you mix Dragon Naturally Speaking into the mix, hey, you're off to the races. Alas, it's not that simple, and there's a lot of other issues related to Accessibility. Screen readers do however emphasize the fact that the mouse is effectively unusable, and that keyboard navigation is essential, and that is a big wake-up call to a lot of people when their mouse or trackpad isn't part of the workflow. See Empathy above ;).

KEY TAKEAWAY

Accessibility has a vocabulary all its own, and it can feel like there's a bit of an "in crowd" mentality to those not familiar with it. I admit to feeling the same way the first time I saw the #a11y hashtag and wondering what it meant. I was happy to be an ally, but then later learned that a11y was a way to say "Accessibility" in a shorter way ('a' with the number eleven between the 'y' because accessibility is 11 characters long). that's clever but it takes asking to understand what it means, and that's a bit of a metaphor for Accessibility in general. We want to make the web and apps accessible, yet sometimes getting into the "club" to understand Accessibility is harder than it needs to be. Laura is throwing down a gauntlet and saying that Accessibility needs to be something everyone on the development team has a stake in and takes part in, hence the book title, Accessibility for Everyone.

Aedificamus: Book Review: The Science of Yoga

When I made a commitment to lose weight, get back into shape, and take control of my aging process, I had to come to grips with the fact that years of weight lifting had left some parts of my body in less than optimal condition (yes, elbows, I’m looking at you). Finding exercise I could do that would be effective, help develop strength, flexibility, & endurance, and overall not exacerbate issues I already have, friends encouraged me to look into yoga.

I’d long eschewed yoga because of the tendency of people to put a lot of “woo” into it. As a software tester, I’m a professional skeptic. The pronouncements around yoga had long been high on spiritual and cosmic wonders, touted as a cure all for everything from depression to cancer. Also, I’m comically non-flexible, so I figured this was just not for me. Over time, though, I decided to try it, and in the course of a few months, I saw some marked improvements in my physique and strength, but also in my overall mood. In short, I felt great, and yoga practice had a hand in that. But still, come on, all these goofy claims… isn’t there someone out there willing to take on the topic and do a MythBusters on the “woo” of yoga?

Turns out that, yes,  there is.

William J. Broad is a lead Science writer for the New York Times, so he has the skeptical science part down. He’s also a long time yoga practitioner, starting his practice back in 1970. He, too, was curious about many of the claims, and decided it was time to examine the history and scientific research. The Science of Yoga delivers on its title, in that is investigates, objectively, the benefits and the detrimental aspects of yoga.

Yoga is a fascinating culture. It’s both ancient and totally modern, deeply tied to ancient Indus Valley history and practiced for millennia, and it is the hip go-to cultural balm for our busy times today. It’s steeped in Hindu tradition, and actively used by those with no understanding whatsoever of its long history or spiritual connection. It ties together isometric physical training, breathing, meditation, focus and body manipulation into a fully systemic training approach. It’s adherents can approach the subject with a reverence bordering on hagiography. Broad does his best to be objective, skeptical, and play by the book, but at times even he admits that what science has studies and objectively reported on doesn’t entirely add up with the combined experience of its adherents, including himself.

The book is broken up into several sections, addressing the history of yoga, and really only covering a small slice of the yoga experience. Each section takes on a bit of the history surrounding claims, including anecdotes and historical references to writings and studies done in India, Europe and the U.S. & Canada. He then shows where scientific studies have been performed (or not), the limitations of said studies and shortcomings, as well as where findings are contradicted or confounded by everyday practice. While Broad makes the point early on that science does not have all the answers, it corroborates more than it refutes.

Several broad chapters look at specific areas like overall health & fitness, weight loss & metabolism, mood & psychological health, risk of injury & healing properties, sexual health & performance, and creativity. The short answer is that there is some hard science behind many of these aspects, and in many cases, the science backs up many of yogas claims. It also debunks a fair number of them, but not without accompanying controversy. Yoga is touted as a way to get yourself slim and toned because it boosts your metabolism. Science shows that the opposite is true, it actually slows metabolism, but in that slowing, it also helps the body recover and heal in ways that would be unlikely in the absence of yoga. This seems to be the cadence of the book. There are claims, science either supports or refutes the claim, but in the process, something about the refutation supports another aspect as to why that benefit occurs. Many questions are answered, but just as many fresh questions arise.

One of the chapters in the book deals with injuries, and for a discipline that prides itself on being very safe, yes, you can certainly hurt yourself doing yoga. Having said that, the number of injuries compared to other activities, including being sedentary, pales in comparison to the overall benefits. Plus, most injuries can heal, and an alteration of one’s routine are all that is needed to avoid such injuries in the future.

Added to the chapters is a list of who’s who in the history of yoga, a chronology of developments, discoveries and explorations, and a lengthy bibliography and end notes that adds close to a hundred pages to the core text.

Bottom Line:

"The Science of Yoga" answers a number of questions, and raises many more. Broad makes clear that science is a discipline that observes data and outcomes, and reports on the results. In many cases, claims do not hold up, but while debunking one myth, a discovery shows where yoga is getting it right, and opens up avenues to new ideas and new studies. This book scratched both my skeptical itch and my exploratory yearning itch at the same time. It made me feel more aware of the realities, but just as excited about the possibilities. If the idea of getting under the mystical layers of yoga intrigue you, and you like the idea of putting claims to the test and seeing where those tests lead, or may lead, then “The Science of Yoga” is an enjoyable read.

Book Review: Practical Web Development

Does it seem like I am starting off a lot of my posts lately with an apology? If so, it's because it feels like I've fallen off the wagon of things I should be doing (and stopped doing) because life interfered. One of those areas is the book reviews I pledged I would do more of this year. It's gotten so bad that I had to basically tell a number of publishers to hold off on titles they send to me until I can get through my back log. Don't get me started on the figurative stack of Python books I'm looking at right now (I can't say literal because they are PDF's, but trust me, there are a lot of them!). Also, as many of you well know, I do not do short reviews ;).

Still, the best way to get back on a horse is to just climb back on, so without any further ado...

At this point in time, programming for the web is a multi-faceted endeavor. There are so many choices and approaches that can be used, and technologies that can be called into action, that it is impossible to master them all. Gone are the days of basic HTML and some CGI scripts being all you’d need to deliver a web experience. Don’t get me wrong, there are still sites out there that are basically this simple, but they are outnumbered by sites that offer much greater interaction, customization and the ability to display on multiple platforms. To do that effectively, more is needed.

The challenge with most web development books (or programming books of any type, actually) is that it takes several hundred pages to cover everything needed, or the books end up being lean and abstract, with the reader having to do a lot of their own research and tinkering to create examples of their own or make the samples provided work.

"Practical Web Development" by Paul Wellins (Packt Publishing) takes a slice down the middle. It doesn’t pretend it will be able to show you everything in great detail, but it does looks to give some "practical" examples with the most common elements and some exercises to work and build on. Wellins progresses from basic HTML, CSS and JavaScript to using PHP, MySQL jQuery, AJAX, History API, XML & JSON, MongoDB, Responsive Design, Foundation framework and Node.JS. Make no mistake, that’s a lot of ground to cover in 276 pages.

So how well does Paul traverse this formidable mountain range of topics?

Part One of the book focuses on the central elements of a “stack” that allows a web site to exist in the first place, and gives an overview of the technologies that work with that web server.

Chapter 1 covers THE WORLD WIDE WEB, specifically where it’s been, where it is, and where it looks to be going. It’s a whirlwind history lesson that covers a lot of technologies that we take for granted today. For the purpose of the book, the emphasis is being placed on HTML, CSS, JavaScript and PHP, with a back end database using SQL. Therefore, up front, five “languages” need to be learned to be effective and use the book. Fortunately, the amount of each language that is needed to be learned will grow with each subsequent chapter, so you get a chance to use each of them as the book professes.

Chapter 2 focuses on the basics of HTML and the most common tags used for markup of pages. Rather than give an exhaustive run down of all the tag elements, Paul gives us the ones that are the most useful and likely to be used when developing a basic site (headings, paragraphs, links, form elements tables and divs, which are best described as self contains rectangles of HTML). Paul also makes the distinction between the structure of a document (which is done with HTML) and the styling touches, which are handled in the next chapter.

Chapter 3 covers what Paul feels are the most useful aspects of CSS, which is all about the syntax that affect the overall look and feel of your pages. The structure of the box model is central to CSS and being able to manipulate the data in a variety of boxes (often the aforementioned HTML div’s) helps to keep the style elements both contained and optimally configured. A recommendation for the use of Firebug or Development Tools in your respective browser is also recommended, as there are a lot of possibilities within CSS and ways to apply them.


Chapter 4 takes us on a tour of JAVASCRIPT with a dose of Programming 101, and builds on some of the basic building blocks of of all programming languages while focusing on the core elements that make JavaScript useful in web pages and applications, specifically as a client side programming language. Variables and variable declarations are covered, manipulation of strings and numbers, operators, control flow, functions, and objects all get a brief but focused examination. The final part of the chapter talks about using the Document Object Model (DOM) and ways to work with objects, properties methods and events. Again, it’s a high level view, but one in which you feel like you can relate to what’s being presented.

Chapter 5 introduces PHP, which is a language designed specifically for server side interactions. Again, like the previous chapters, this section focuses on what most users would need to make something work on the server using PHP, not a complete rundown of the syntax. This chapter also goes through the basics of what you need to do to check if your web host is set up to support PHP and what to do if it isn’t.


Chapter 6 adds more about PHP, specifically in conjunction to working with a MYSQL database. The chapter starts with a basic understanding of databases in general ,and then MySQL in particular. It introduces the way that databases work and how MySQL fits into the web stack. phpMyadmin is covered as well, which allows you to administer a SQL database via the php utility. It also walks the user through several commonly used database commands and fundamental queries.

Part II of Practical Web Development aims to help us break away from the model of multiple pages where a few will suffice, and to get away from static pages to those that are more interactive, dynamic and responsive to the platform it is being displayed on.

Chapter 7 covers JQUERY, which is a JavaScript library that emphasizes a small footprint. It uses CSS selector style syntax that specify DOM elements. Again, the coverage is not exhaustive, but it give enough to show the general approach to using jQuery as part of your page development and the most likely to be used aspects of the library.

Chapter 8 focuses on AJAX (Asynchronous JavaScript and XML) which is really a handful of different techniques that allow for data to be retrieved in small pieces without requiring the entire web page be reloaded. jQuery has several methods that allow for AJAX to be used. $.load and $post both allow for portions of the screen to be replaced with fresh HTML, dynamically generated or programmatically placed.


Chapter 9 covers THE HISTORY API, which becomes very important when you start creating a site that is based primarily around a single page. rather than direct a user to the previous site they were on before coming to ours, the History API allows the users to navigate back to states of the page, or to allow for a bookmark URL to represent the state of the page bookmarked.


Chapter 10 focuses on using XML (extensible Markup Language) and JSON (JavaScript Object Notation) as data formats to be used as an alternative to HTML.

XML files can be seen as small databases. XML Schema defines the structure XML files, while XSLT creates stylesheets for converting XML into different formats. SimpleXML allows for paged to be created and processed using PHP. JSON is a lean format that gets processed like JavaScript objects in the browser, and therefore requires much less overhead.


Chapter 11 introduces us to MONGODB, which is a type of NoSQL (not relational) database. It’s more readily known as a document database, and it stores JSON objects that are grouped into collections. Web applications are capable of communicating with the MongoDB using PHP.
.
Part Three of the book moves away from the underpinnings of the technology and deals with methods that help the loo and feel of the users experience, regardless of the platform being used.


Chapter 12 focuses on MOBILE FIRST, RESPONSIVE DESIGN WITH PROGRESSIVE ENHANCEMENT (go ahead, say that ten times fast ;) ). The key idea is that, based on the platform it is being displayed, the page will dynamically tailor itself to display optimally for that device. Desktops, tablets and phones have radically different screens and needs, and Responsive Design aims to help with that. One of the key aspects of this chapter is to encourage you to focus on mobile development and display first, and then work back. Additionally, another JavaScript library called EnhanceJS allows for different experiences to be displayed depending on the browser being used or the platform accessing the content.

Chapter 13 introduces FOUNDATION – A RESPONSIVE CSS/JAVASCRIPT FRAMEWORK. The idea behind Foundation is that it lets us focus on developing a site without having to reinvent the wheel on the responsive part. By using a grid system, you can determine how many areas can be used depending on the size of the screen, so that the site expands and reformats based on the grid. Foundation also includes a number of UI enhancements that make it easier to put together navigation, image display and other details that make interacting with a site easier based on the available real estate.

Chapter 14 closes out the book with an introduction to NODE.JS, which is, at its core a fundamental break with all of the rest of the web development options discussed in the previous chapters. Rather than require a whole host of technologies, everything can be written within Node, which then translates everything to native JavaScript (and by extension HTML, CSS, etc.). This can be done using the Express framework, which is described in basic detail, and the idea of templating (which is what PHP does), using handlebars.js.


An Appendix section describes BOOTSTRAP - AN ALTERNATIVE TO FOUNDATION. The same exercises Paul described in Chapter 13 he tackles here, but uses Bootstrap.JS. It meets a similar goal, i.e. making a mobile-first, responsive site without having to reinvent the wheel to provide the responsive part.

Bottom Line:

The title of the book is Practical Web Development, and a special emphasis needs to be placed on the “Practical” part of the title. Paul has strived to make a book that is accessible, easy to follow, and lean enough to be usable without getting the reader lost in the weeds. I’ve long been looking for a book that would be a soup to nuts title, one that could be the starting point for someone to start with developing for the web, and have a single source to get up and running. Is this that book? It’s pretty darn close! There’s lots of additional areas that could have been covered, but to his credit, Paul has made a title that hits the high points, and a few divergences that are interesting if not mandatory. For a lean and straightforward primer on modern web development approaches, this is a great place to start.

Book Review: Ruby Wizardry

Continuing with the “Humble Brainiac Book Bundle” that was offered by NoStarch Press and Humble Bundle, I am sharing books that my daughter and I are exploring as we take on a project of learning how to write code and test software. Part of that process has been to spend time in the "code and see" environment that is Codecademy. If you have done any part of the Ruby track on Codecademy, you are familiar with Eric Weinstein’s work, as he’s the one who wrote and does updates to the Ruby section (as well as the Python, JavaScript, HTML/CSS and PHP modules).

With "Ruby Wizardry", Eric takes his coding skills and puts them into the sphere of helping kids get excited about coding, and in particular, excited about coding in Ruby. Of all the languages my daughter and I are covering, Ruby is the one I’ve had the most familiarity with, as well as the most extended interaction, so I was excited to get into this book and see how it would measure up, both as a primer for kids and for adults. So how does Ruby Wizardry do on that front?

As you might guess from the title and the cover, this book is aimed squarely at kids, and it covers the topics by telling a story of two children in a magical land dealing with a King and a Court that is not entirely what it seems, and next to nothing seems to work. To remedy this, the children of the story have to learn some magic to help make the kingdom work properly. What magic, you ask? Why, the Ruby kind, of course :)!

Chapter 1 basically sets the stage and reminds us why we bought this book in the first place. It introduces us to the language by showing us how to get it ("all adults on deck!”), how to install it, make sure it’s running and write our first "Hello World” program. It also introduces us to irb, our command interpreter, and sets the stage for further creative bouts of genius.

Chapter 2 looks at "The King's Strings" and handles, well, strings. Strings have methods, which allow us to append words like length and reverse written with dots ("string".length or 'string'.reverse). Variables are also covered, and show that the syntax that works on raw strings also works on assigned variables as well.

Chapter 3 is all about Pipe Dreams, or put more typically, flow control, with a healthy dose of booleans, string interpolation, and the use of structures like if, elseif, else and unless to make our Ruby scripts act one way or another based on values in variables and how those values relate to other things (such as being equal, not equal, done along with other things or in spite of other things, etc.).

Chapter 4 introduces us to a monorail, which is a train that travels in an endless loop. Likewise, the chapter is about looping constructs and how we can construct loops (using while as long as something is true and until up to the point something becomes false, along with for to iterate over things like arrays) to do important processes and repeat them as many times as we want, or need. Also, it warns us to not write our code in such a way to make an infinite loop, one that will just keep running, like our monorail if it never stops.

Chapter 5 introduces us to the hash, which is a list with two attributes, a key and a value,  as well as the ability to add items to arrays with shift, unshift, push or pop. Additionally we also learned how to play with ranges and other methods that give us insights as to how elements in both arrays and hashes can be accessed and displayed.

Chapter 6 goes into talking about symbols (which is just another word for name), and the notation needed to access symbols. Generally, the content of something is a string; the name of something is a symbol. Utilizing methods allows us to change values, convert symbols to strings, and other options that allow us to manipulate data and variables.

Chapter 7 goes into how to define and create our own methods, including the use of splat (*) parameters, that allows us to use any number of arguments. We can also define methods that take blocks by using "yield".

Chapter 8 extends us into objects, and how we can create them and use them. We also learn about object IDs to tell them apart, as well as classes, which allow us to make objects with similar attributes. We also see how we can have variables with different levels of focus (Local, Global, Instance and Class) and how we can tell each apart (variable, $variable, @variable and @@variable, respectively).

Chapter 9 focuses on inheritance, which is how Ruby classes can share information with each other. this inheritance option allows us to create subclasses and child classes, and inherit attributes from parent/superclasses.

Chapter 10 shows us a horse of a different color, or in this case, modules, which are a bit like classes, but they can't be created using the new method. Modules are somewhat like storage containers so that we can organize code if methods, objects or classes won't do what we want to do.  By using include or extend, we can add the module to existing instances or classes.

Chapter 11 shows us that sometimes the second time's the charm, or more specifically, we start getting the hang of Refactoring. Using or operators to assign variables, using ternary operators for short actions, using case statements instead of multiple if/elseif/else statements, returning boolean variables, and most important, the removal of duplicate code and making methods small and manageable.

Chapter 12 shows us the nitty-gritty of dealing with files. Opening reading from, writing to, closing and deleting files are all critical if we want to actually save the work we do and the changes we make.

Chapter 13 encourages us to follow the WEBrick Road, or how we can use Ruby to read and write data from the Internet to files or back to Internet servers using the open-uri gem, which is a set of files that we can use to make writing programs easier (and there are lots of Ruby gems out there :) ).

Chapter 14 gives some hints as to where you, dear reader, might want to go next. This section includes a list of books, online tutorials, and podcasts, including one of my favorite, the Ruby Rogues Podcast. It also includes interactive resources such as Codecademy, Code School, and Ruby Koans, and a quick list of additional topics.

The book ends with two appendices that talk about how to install Ruby on a Mac or a Linux workstation and some of the issues you might encounter in the process.

Bottom Line:

For a "kids book", there's a lot of meat in here, and to get through all of the examples, you'll need to take some time and see how everything fits together. The story is engaging and provides the context needed for the examples to make sense, and each section provides a review so that you can really see if you get the ideas. While aimed for kids, adults would be well suited to follow along as well. Who knows, some wizarding kids might teach you a thing or three about Ruby, and frankly, that's not a bad deal at all!

Book Review: Build Your Own Website

With the "Humble Braniac Book Bundle" still underway, I felt it only fitting to keep the trend going and review books that are geared towards kids and those who want to have a quick introduction to the worlds of programming, web design and engineering. My daughter and I are exploring a lot of these titles at the moment, and one that caught my eye was "Build Your Own Website", primarily because it promised to be "A Comic Guide to HTML, CSS and WordPress", and that indeed it is.

I should probably mention that by "a comic guide", it does not mean in the funny sense (though some of it is), but in the illustrated, graphic novel sense. For those familiar with NoStarch Press and their "The Manga Guide to..." series of books, Nate Cooper's writing and Kim Gee's artwork fits very well in that space. What's more, "Build Your Own Website" follows the same template that "The Manga Guide to..." books do, in that each section starts with an illustrated graphic novel treatment of topics, and then follows on with a more in depth prose treatment of each area.

So what's in store for the reader who wants to start on a mission to make their own site from scratch?

Chapter 1 starts with our protagonist Kim looking forward to her first web design class, and shows that inspired and excited first timer's desire to get in and do something. It's followed by an explanation of the tools needed to be downloaded and do the work necessary to complete the examples in the book. All of the exercises and examples can be done for free, all you need is a web browser or two, a text editor, an ftp client (the book recommends FileZilla; it's the one I use as well) and you can get a free WordPress account at http://www.wordpress.com.


Chapter 2 talks about The Trouble with HTML, and how Kim and her dog Tofu meet up with the Web Guru, who introduces them to the basics of HTML, paths and naming conventions, loading pictures and following links, the hierarchy of files and directories that make up a basic web site, and a dragon called "404". The second section goes into details about all of these including explaining about document structure, HEAD and BODY tags, the items that go in each, embedding images, and a basic breakdown of the most common HTML tags.


Chapter 3 shows us how Kim Makes Things Look Great with CSS. Well, Glinda, the Good Witch of CSS helps Kim do that (graphic novel for kids, gang. Work with me, here ;) ). Glinda shows Kim the basics of CSS including classes and IDs, inline styles and external stylesheets that can be referenced along with inline styles, effectively creating a "cascade of styles" (CSS == "Cascading Style Sheets"). The chapter also discusses using div's for creating separate sections and blocks that CSS can be applied to, and ends with commonly used CSS properties.


Chapter 4 is where Kim Arrives in WordPress City, and where the examples focus on, of course, WordPress as a composition platform. Kim gets introduced to what WordPress is, which is a Content Management System (CMS), and the conventions of creating both blogs and websites. Kim is introduced to the Dashboard, creating posts, using the Visual editor, structuring her site, using Categories and Tags, using the Media Library to store media items, and the overall Theme to be used for the site. Each of these is covered in greater detail with examples in the second prose part.


Chapter 5 takes us to Customizing WordPress, and the myriad options that Kim can use to make her site look the way she wants it to. She is introduced to the Appearance panel, the difference between free and premium Themes, plugins such as Buy buttons or sharing posts on social media, Widgets that perform special functions that can be replicated for sections or each page, changing the navigation options to get to your pages quickly, and how each of the elements of WordPress are built on HTML and CSS (as well as things like JavaScript, PHP, Ruby, etc.).


Chapter 6 brings us to The Big Launch, where Kim and Tofu navigate the realities of hosting the site and how to set up hosting so that they can display their finished site to the world. There's lots of options, and most cost some money, but not very much (plans ranging from $5-$10 a month are readily available). Registering a domain is covered, and many sites have an option to install WordPress and use it there.


Bottom Line:
"Build Your Own Website" starts with some basic HTML and CSS, and then spends the bulk of the second half of the book introducing you, the user, to WordPress. For those looking to see the nuts and bolts of making a web site from scratch, including making the navigation elements, more involved interactions, and other esoteric features of web sites outside of the CMS system that WordPress provides, you will be disappointed. Having said that, if the goal is to get a site up and running and using a well designed and quick to use interface, WordPress is a pretty good system, with lots of flexibility and ways to make the basic formatting of a site nearly automatic. Younger web development acolytes can get in and feel what it's like to design and manage a site. To that end, "Build Your Own Website" does a very good job, and does it in an entertaining and engaging manner.

I would recommend this as a good companion book with "Lauren Ipsum", so as to give some high level computer science interaction. Both books also show that young programmers can get in, see what is happening, and become curious as to what comes next. From there, focusing on books that deal with JavaScript or frameworks for setting up sites will be less of a jump, because we can look back at WordPress and its CMS and say "oh yeah, that looks familiar". "Build Your Own Website" sets up a nice foundation, and makes a good jumping off point for those further explorations.

Book Review: Python for Kids

As I have been working with my daughter to learn programming, we have been focusing on learning Python.  We chose Python primarily because it was something I felt we could both come at from a similar frame of reference. I had worked with Python but in limited capacity, and Amber had not really worked with any programming languages. By working on Python, we could be somewhat closely matched with what we were learning.

NoStarch Press has a number of books that are ideally suited for younger programmers, and to that end we both decided to look at the books together. We will be doing three “for Kids" books reviews during February, provided we can get through all of them. All journeys have to start somewhere though, and this journey will start with Python for Kids. I should also mention that, for a limited time, you can get Python for Kids as part of the NoStarch and Humble Bundle "Humble Brainiac Book Bundle" offer, which comes with a lot of other additional books.

Python for Kids is written in a way that lets the user, whether they are kids or adults, readily get into the material and see how the examples work and try them out for themselves.

Chapter 1 starts out with installing and using Python 3, so right away Amber and I had to adjust to the new syntax (Codecademy’s Python modules are still based on Python 2).  Be aware that there are some subtle differences with Python 3, one of the main ones being the parentheses required when using the print(“text goes here”) function (yeah, like that ;) ).

Chapter 2 introduces the user to calculate values using simple equations via operators, using parentheses to ensure the desired order of operations, and creating and using variables to store values for use in those calculations.

Chapter 3 introduces strings, lists,  tuples, and maps, each of which allows the user to manipulate text in a variety of ways. Each of the approaches has rules as to how to move items and how they are represented, ranging from simple strings with are just quoted sentences, up to maps which have keys and values that can be called as needed.

Chapter 4 introduces the user to drawing methods, and in this case, that involves using a module called turtle (which in turn uses a tool called tinter). Using this tool, we can actually draw the turtles movements with lines moving left and right, moving forward and backward, as well as starting and stopping with up and down commands.

Chapter 5 focuses on asking questions and responding based on the response the system gets. For experienced programs, this i about if statements and their related commands (elif, else)  and how commands allow for combining conditions (using and/or) and converting values (using int, str, float and none).

Chapter 6 talks about “Going Loopy” which, as you might guess, deals with handling loop conditions and repetitive tasks. for and while loops are covered, and break conditions are shown to, well, break out of loops.

Chapter 7 talks about ways to recycle code and reuse it defining and using Functions and importing Modules. Variable scope is also covered so as to see where values are assigned, used and passed back and forth.

Chapter 8 focuses on the things in python, otherwise known as classes and objects.  this chapter covered the details of classes and how they an be used to create instances, and how objects can be created, call functions to work with objects, and assigning object variables to save values in those objects.

Chapter 9 covers the various built-in functions available in Python, those that we can import into Python programs and use directly (functions like abs, bool, print, float, int, len, etc) as well as howe to open and manipulate files.

 Chapter 10 covers a variety of helpful modules, such as copy, keyword, random, shuffle, and the sys module that allows the user to control the Python shell itself, reading input with stdin, writing output with stdout, telling time with the time module, and using pickle to save user information in files (yes, there’s a module called pickle ;) ).

Chapter 11 revisits turtle, and how we can use it to draw a variety of items. including basic geometric shapes, changing the pen color, filling shapes and reusing steps in functions to combine drawing shapes and using multiple colors in one function call.

Chapter 12 covered using tkinter to make “better graphics” and my oh my does this take me back. I used Tcl/Tk back in the 90s for a number of things, and the syntax to use tkinter is very familiar.  Simple shapes, event bindings so objects can move when keys are pressed, using identifying numbers to move shapes and change colors are all covered here.

Part II gives the user a chance top practice the programming chops they have developed in the first Part by making a ball bouncing game called, appropriately enough, Bounce!

Chapter 13 starts out using the tinter module, in which we can create a class for a ball and move it around the screen.  Coordinates can be set so that it will bounce off of the top and corners of the screen, and a randomized option so the ball has a dynamic movement.

Chapter 14 continues with creating classes for the paddle, and using coordinates to see if the ball hit the paddle. Event bindings tie the left and right arrow keys to control the  paddle,  and make it so,  if the player misses the ball, the game ends when the ball hits the bottom.

Part III continues the ideas so far shown with “Mr. Stick Man Races for the Exit”.

Chapter 15 shows how to make graphical images of, you guessed it, a stick man (using GIMP to make the actual images) and making the backgrounds of the images transparent so they won’t cover up other things.

Chapter 16 covers creating a Game class making a background image. By using functions called within_x and within_y, we can determine if items have collided with other items. We also discover Sprites and a sub-class, PlatformSprite, to draw the platforms on the screen.

Chapter 17 walks through the details for taking the pictures we created for Mr. Stick Man back in Chapter 15 and setting up options for the figure to move, turn and jump.

Chapter 18 finishes off the Stick Man game, and shows that putting together a working game is not trivial, but it’s also not a huge endeavor either.  We focus on using the images we made for Mr. Stick Man so he appears to be running, use  collision detection to tell if he hits the sides of the canvas or another object, and have Mr. Stick man drop if he runs off the edge of a platform. We also make a door that Mr. stick man can go through, ending the game.

The book also provides an Afterward that discusses some additional options for doing basic game development Alice, Scratch and Unity3D, PyGame, which is a dedicated library for making games, band a discussion of other programming languages and a super quick look at what they do , where to get them, and what it takes to make a   “Hello, World!” program. The Appendix highlights keywords in Python, and the glossary defines a number of words kids might not hear in their everyday interactions.

Bottom Line:

Python for Kids clocks in at a little over 300 pages, but you won’t feel like it as you work through it. There are numerous small projects and samples to examine, and all of the solutions to the puzzles and challenges are available at http://python-for-kids.com/. While this book is geared towards kids, there’s plenty in here to keep adults engaged and focused. Often, programming books are plagued with the “implied knowledge” trap that happens so often, where small projects give way to bigger ones, without a clear understanding of how the jump was made. Python for Kids does a very good job of avoiding that problem. Having kids as the primary audience, they take their time explaining key areas, and yes, for programmers with a little work under their belts, this is going to probably seem remedial, but as an introduction to Python, I think it’s first rate.

If you are looking to give your kids a kick start in learning how to program, if Python seems like an interesting language to start with, and if you’d like to have a couple of tangible projects to play with and augment as you see fit, then Python for Kids should be on your short list of programming books… provided having fun while learning is a priority.