Author: William

Introduction to Foster Care

I’m going to go a little off-topic for this blog today and talk about something that’s not technology related but is important to me: foster care. My wife and I have been certified foster parents for several years now, and I find that there are a number of common misconceptions about what foster care is and how it works.

What is foster care?
Foster care is a way to provide homes and families for children who, for whatever reason, do not have parents who are able to care for them. Sometimes that means no living parents or parents who are currently unable to care for children; other times, this is children who have been removed from their homes due to abuse or neglect.

Generally foster care is intended to be a short term solution until the children can be reunited with family members – if not their parents, then other relatives who would be willing to adopt. The actual length of “short term” may vary – children may be in the foster care system for days or years.

There are approximately 400,000 children in foster care in the United States, including nearly 7,000 in Wisconsin.

Who can be a foster parent?
To be a foster parent, you must be at least 21 years old, have sufficient income to cover your own needs, have sufficient room in your home for a child, complete the training requirements, and pass a criminal background check. Most importantly, you should be prepared to love a foster child as your own!

Many people believe they couldn’t do foster care because they wouldn’t be able to love a child and then give them up again, and in fact the primary goal of foster care is reunification – returning a child to their family. I won’t lie – giving up your child is one of the hardest things you’ll ever do, if not the hardest. But by loving them anyway, you can make their lives so much better.

What does it cost to foster / Do foster parents get paid?
Being a foster parent is a volunteer job; like having biological kids, it’s one of the most frustrating and most rewarding things you’ll ever do. The government does provide a (nontaxable) stipend to help cover the costs of caring for the child; in Wisconsin, this rate is $238/month for level 1 care (generally, caring for a relative) and ranges from $394-$511/month depending on the age of the child otherwise. There is an additional rate for children with special needs; at the higher end, a child who needs around-the-clock care may qualify for a total stipend of up to $2000.

Online, I’ve seen comments both from people who think foster parents shouldn’t be paid at all (in which case there would be even more of a shortage, as many of us couldn’t afford it) to those who think foster parents are just in it for the money (that extravagant $13/day to cover the cost of caring for a baby!) It probably comes through here that I think both views are ridiculous; as a friend of mine put it, sometimes the foster care stipend only covers your gas for driving your kid around – but it helps!

Foster kids are covered by Medicaid, and those under 5 are also eligible for WIC benefits. The income of the foster parent does not matter for Medicaid/WIC eligibility.

Who are the kids?
There is a wide variety of children in foster care – from newborns to high school graduates, from kids with no health problems to those who are extremely medically fragile, from single kids to large sibling groups, from those with a plan for reunification to those who will need an adoptive home. Generally speaking, you can assume that the kids have suffered through some level of trauma – if nothing else, that of being removed from their parents. They all need parents who can be patient with them as they deal with change and uncertainty.

How can you get involved?
Not everyone is suited to be a foster parent – it can be physically and mentally exhausting and you do have to have a suitable home. For those who can’t take on a child full-time, other options to help include providing respite care (where you care for a child for a few days or even just a few hours) or even just helping new foster parents with meals when they’re feeling a bit overwhelmed. Most importantly, realize that foster kids aren’t any “less” or “real” than biological children; I love both my biological child and my foster child, and they’re both my kids.

Parsing doubles in Finland

One problem I had this week is that a piece of code which had, for the previous few years, been perfectly behaved suddenly started crashing for a new customer. This was the first time I’d seen the code run on a Finnish system, so a problem with internationalization seemed like the obvious place to start.

Running the software on a fi-fi system, I found that a call to Double.Parse was causing a FormatException: Input string was not in the correct format.

The issue here was that the code was attempting to parse a string which contained a software version number, e.g., “2005.100”. In a US English environment, this works fine – that gets parsed as 2005.1. In a German environment, this works fine – that gets parsed as 2005,100. Finnish, however, doesn’t use the period as either a decimal separator or a thousands separator, so when the system tried to parse the string, it didn’t recognize it as a number.

The solution is to pass in the second parameter for Parse, which (at least in C#) is an IFormatProvider. When no IFormatProvider is given, the system defaults to InstalledUICulture, which means it was trying to interpret the string according to the system’s locale settings. By passing in InvariantCulture, I force it to ignore the locale settings and interpret the input as an English (no country) string.

Double.Parse(version, CultureInfo.InvariantCulture)

As a result, this value – which is always stored in the same format – is also always read in the same format, and the end user sees the same behavior regardless of the computer on which the code is being run.

On work, burnout, and recovery

A while back, I was asked what I would change about my job. My answer was that I would like to have more vacation time.

In other words…what I would like to have for my job…is less of it.

The funny thing is, I like my job. It’s consistently challenging. I have to do and learn new things all the time. The hours are semi-flexible, the dress code is practically non-existent, and the cafeteria is a major perk.

All that – and it’s still easy to get burned out. I’ve been in the same job for seven years, now. There have been a few title changes – software developer to software developer II to senior software developer – the people are different, the languages are mostly different..but I’m still programming. Now, I like programming – I like technology in general – but I’ve never done the same thing for so long. I get bored and want to move on to something else.

So why not move on from programming? A big part of it is the money, of course – being a software developer pays really well. I’m getting older and I have a family to support, which makes jumping around harder. On top of that, this is something that I CAN do long-term – there are new challenging all the time, which is what makes it interesting. And yet – I get burned out.

There are different ways of fighting it. Sometimes I go to programming conferences, which helps me get excited about coding again. Sometimes I work on my book – I love teaching, and my book (which I’ve been writing sporadically for a few years now) is one way to do that. But sometimes I feel like I just need a break. In 2016 my wife and I spent two weeks in Europe, and it was amazing; for two weeks I completely cut myself off from work, blocked email from my phone, and just relaxed. I needed that.

Little bits of vacation – a day here, a day there? It’s not enough. I end up answering work emails and don’t clear my mind. I need a real break, one where I focus on something that’s not work related. A week at BGGCon, focused on playing board games with my friends. A few weeks in Europe, focused on traveling with my family.

I like my job. Time away from it helps me to be better.

Improving query performance in SQL Server with recompile

This week I ran across a new-to-me option in some T-SQL code I was reviewing: OPTION (RECOMPILE). It turns out that this option improves performance by forcing SQL Server to recompile the query rather than using the plan it already generated.

Wait, what? Don’t we save time by saving a query plan and reusing it?

Generally, yes. When you first run a stored procedure, the SQL engine will figure out a plan for that procedure and cache the plan for reuse, thus saving the time of recomputing the it each time the procedure is run. The problem comes in when a plan is generated that makes sense for the current database state and parameters, but doesn’t make sense when those change. For example, suppose you have a table with ten million rows; different approaches are required if you want to retrieve ten of those rows vs seven million of them.

Generating the query plan

When the stored procedure is executed, SQL Server looks at the distribution statistics it has about the data in the tables the procedure references and uses this data to guess at the best way to run the query. Assuming that the statistics are up to date, it can generally make a fairly good guess; for example, it may choose an index seek if it expects to return a small number of rows, but a table scan if it expects that a significant percentage of the table will be returned.

Parameter sniffing
Sometimes, the output of the procedure depends heavily on the value of a parameter; one value might result in returning one row, while another returns a million rows. When you run the procedure, SQL Server sniffs the parameters and uses whose to choose the query plan. If a query is called with literal values, you get one plan for each call, but if it is parameterized, the same plan is used the next time the procedure is called even if the value of the parameter is very different. If the procedure behaves similarly as the parameter varies, this works fine, and you save the cost of creating a new plan each time. If it doesn’t, however, you can end up with a plan that is orders of magnitude slower than optimal.

Recompiling
Telling SQL Server to recompile forces it to create a new query plan rather than reusing the old one. When the old plan was “good enough”, this is a bad thing – generating the plan is expensive. In some cases, though, the performance improvement from using a better plan easily overwhelms the cost of recomputing that plan.

One way to do this is to alter the stored procedure to include the WITH COMPILE option; this tells SQL Server not to cache a plan, so the query plan is regenerated each time. Alternatively, we can add OPTION (RECOMPILE) at the statement level, in which case only the plans for that particular statement, rather than the entire procedure, will be regenerated.

Being bossy with SQL Server
Forcing a recompile isn’t the only way to take control away from SQL Server. Another option is to use the OPTIMIZE FOR hint, when you know that the plan for a particular value will work well for a wide range of possible parameter values; in this case, you use domain knowledge to improve on what SQL Server could manage with statistics alone. You can also use OPTIMIZE FOR UNKNOWN to keep SQL Server from optimizing based on the particular value that was passed in.

Remember the disadvantages of taking control away: you lose the performance benefits of reusing a query plan, and if you make a bad choice as to what value to optimize for (or the data changes to make it a poor choice), you could see much worse performance than if you just leave SQL Server alone to do its own thing. As usual, you want to tell SQL Server how you want it to process something (rather than just what you want it to do) only when you have a good reason for doing so.

Goals for 2018

I’ve never been a believer in New Year’s resolutions; there’s a reason it’s a cliche to start a new exercise program in January and abandon it by February. Resolutions tend to be things that people would like to do…and by the end of the year, they become things that people would have liked to have done.

At the same time, goals can be worthwhile – especially if they’re SMART goals. A SMART goal is one that is specific, measurable, actionable, realistic, and time-bound.

SMART Goals
Specific: It is clear exactly what the goal is.
Measurable: It is clear whether the goal has been achieved.
Actionable: It’s clear what actions need to be taken to achieve the goal. “I will be a millionaire in a year” isn’t actionable; “I will spend at least two hours per week writing” is.
Realistic: The goal is something you can realistically achieve within the given time bound.
Time-bound: There is a deadline for when the goal will be accomplished.

For 2018, I’ve decided to set New Year’s commitments. Why commitments instead of resolutions or goals? Because I’m committing that these are things I will get done this year (and I’ve actually set up a penalty for if I fail to accomplish any of them). In 2018, I am committing that:

  • I will publish at least one book – this will probably be either my computer science textbook or my first novel.
  • I will apply to speak at [at least] two conferences – probably the two I spoke at in 2017 and any others that look good.
  • I will update my blog at least once per month.

None of these goals are based on things outside of my control; I’m not resolving to make six figures from my book (although it would be nice!), have my talks accepted, or write an outstandingly brilliant post; I’m simply committing to doing the work, and posting a public record of that commitment. When I’m running on way too little sleep because the baby was screaming all night long, I won’t have the option to say “oh, I guess I have a good excuse for not meeting my goals this month” – I have this commitment to hold myself accountable.

Are you setting goals for 2018?

That Conference Follow-Up

We’ve finished another That Conference! This was my third year attending, but my first time as a speaker.

As much as I love the name (I’m going to That Conference next week. Which conference? That conference!) and the location (who doesn’t want to spend the better part of a week at a water park?), as much as I love the opportunity to spend three days focused on learning…I think what I get most out of That Conference is an opportunity to recharge. To recover from burnout. To get excited about programming again.

One thing I’ve struggled with is the “hallway track”; I know that many people go to conferences specifically to talk to other developers (often at the cost of even going to the talks!) – That Conference even schedules a half hour break after each session to allow for this – but as someone with a severe hearing loss (and an introvert) I have a very difficult time inserting myself into conversations. This year was easier for two reasons: I met an online friend in person for the first time, and giving a talk provided a ready conversation topic, so I was able to have much more in the way of meaningful interactions than I have in years past.

I’ve uploaded the slides for my accessibility talk; there are a lot of extra details in the presenter notes that I included for reference but didn’t have time to actually work into an hour-long talk. Accessibility is an issue that a lot of people are talking about these days, but that many companies still aren’t taking as seriously as they should; often it’s still an afterthought (or a no-thought). That Conference has been trying to encourage the voices of underrepresented groups (their current goal is to have half of the speakers be women), so I’m hopeful that we’ll also continue to see more work on reaching out to people with disabilities. Last year a number of speakers (including at least one of the keynotes) showed videos without captions, and I wasn’t seeing that this year – I don’t know if that’s just coincidence or if people are keeping accessibility in mind.

I’ll be speaking at MKE.NET in a few weeks, on sorting algorithms, and I definitely plan to be back at That Conference next year.

Accessibility and HTML5: Semantic Elements and More

A div for everything and everything is in its div…

If you’ve been working on websites for a while, you’ve no doubt had a few that seem to be just div after div, where the div explosion serves to place or style each part of the page as needed. The problem is, a div by itself doesn’t tell the user (or, more to the point, the user agent) anything about what the div contains, and the styling is likely to be lost on someone using a screen reader.

In HTML5, we have the semantic elements, which generally act like divs – they’re block elements that contain other elements – but also provide meaning; each tag describes what it contains, which allows a user agent (such as a screen reader) to handle it appropriately. We still use divs, when no semantic element is appropriate, but they should no longer be the first choice. The semantic elements include:

  • <nav> encloses a navigation block; this will often contain a list of links, but not every list of links needs to belong to a nav. Screen readers may be able to go directly to the nav section or skip it if not needed.
  • <main> is for the main content of the document; it should contain only content that is unique to that document, not content repeated across multiple pages. User agents will often be able to navigate directly to the main content block, bypassing navigation links. At most one main element should exist in a given document, and it cannot descend from an article, aside, header, footer, or nav element.
  • <article> describes a self-contained block; it could be moved to another page and still make sense on its own. A page that consists of one self-contained block of content will simply hold it inside a <main> element, but multiple blocks that do not depend on each other will be <article>s instead. An <article> can contain other <article>s that are related to it, such as comments on a story.
  •  <aside> contains information which is tangentially related to the primary content, but isn’t required to understand it; this content is likely to be visually represented as a sidebar or pull quote.
  • <figure> encloses some self-contained content, which may be (but is not required to be) graphical in nature. Each <figure> may contain one <figcaption>, which provides a caption for everything contained in the figure; this groups all of the contents and provides a way to refer to them even if the page layout changes.
  • <section> is a…er…section of the document; it groups together part of the document, such as a chapter. Sections generally come with headers and should contain content that logically belongs together.

If none of the above signpost elements are appropriate, then we look for a more specific element, such as <address>, <blockquote>, or even <p>. Only if the content doesn’t have any semantics do we use the plain <div>. It’s a bit more work, but it allows the user agent to process each type of content according to its own rules, according to the user’s desires.

Lack of accessibility: my experience

We’ve been talking about guidelines for making websites accessible in general, and how to make them screen reader accessible in particular. Now let’s get away from the how and look at the actual impact of this work. Here are a few times when I’ve been impacted by a lack of accessibility.

  • Some years back, someone lent me an instructional video for West Coast Swing. The instructor was trying to explain how to dance in time with the music, and you were supposed to listen to the beat while he pointed up and down, which would have been great – except he also SAID “up” or “down” each time, so I couldn’t actually hear what he was trying to point out!
  • When Netflix started doing streaming video, there weren’t any captions. Many people complained (including myself) and Netflix told us that they were in the process of adding them. A few years later, they added streaming captions…for the first five seasons of Lost.
  • When listening to podcasts, it’s not unusual to have people sometimes speaking over music, which makes them harder to understand.
  • When I’ve been to conferences, speakers often show video with no captions.

In many cases, these aren’t even difficult things to fix. The dance instructor could have simply pointed rather than speaking, there’s no reason to have music on in the background when recording speech, and of course adding the already-existing captions to more of their streaming videos was well within Netflix’s capabilities if they had prioritized it. For speakers showing video, captioned versions are often available (sometimes the captions just need to be turned on!), and adding captions to original videos is fairly straightforward with modern video editing software. In each case, the problem isn’t technological; the problem is people either not thinking about the needs of viewers with hearing impairments or simply not caring.

Fortunately, things are improving. Netflix was sued under the Americans with Disabilities Act and now captions pretty much everything. Conference organizers are starting to pay more attention to accessibility. I’m in the process of booking a cruise as I write this, and the cruise ship provides assistive listening devices, sign language interpreters, and open captions on some movies. Movie theaters are now required to provide some way (usually Captiview, which is not a great option but is way better than nothing) for deaf patrons to follow what’s being said.

I’m writing this from the perspective of someone with hearing loss, because I’m deaf, but I’m sure people with visual or mobility impairments could provide a similar list of issues. What’s happening lately, partially through awareness and partially through political/legal action, is that more service providers are considering what they need to do in order for their product to be truly usable for everyone.

Testing for accessibility: Web Content Accessibility Guidelines

What makes a website accessible?

The answer, of course, is that a website is accessible if it is usable by all people, regardless of disability. When building a website, however, we need something a little more concrete; we need a way to test whether the website is accessible, without having to have people with a hundred different impairments actually testing it. That’s where the Web Content Accessibility Guidelines (WCAG) from W3C come in. Following the guidelines doesn’t guarantee that your website is usable for everyone, but it’s a good starting point for handling the most common accessibility issues. The guidelines help insure that all users can both access the content and navigate the website.

How important is the WCAG standard?

Many countries require that their government websites follow the WCAG standard (the US uses Section 508 guidelines, which are expected to require AA WSAG compliance, described below). Last month, a federal court ruled that having an inaccessible website is a violation of the Americans with Disabilities Act (ADA), and the Justice Department has successfully sued companies (including Carnival and Wells Fargo) over lack of accessibility (both physical and online). The ADA requires that places of public accommodation be accessible to the disabled, and websites which directly sell goods or services, or connect to physical locations which do, have been ruled to be places of public accommodation and thus subject to the ADA requirements.

How are websites evaluated?

WCAG includes three levels of compliance: A, AA, and AAA. A is the minimum level of conformance; a website that does not meet the level A requirements is simply not usable by people with certain disabilities. These are things that every accessible website MUST do. AA requirements make the website easier to use; these are things that every accessible website SHOULD do. Finally, AAA requirements are going “above and beyond” to make things easier for people with disabilities; they are things that a website MAY do. In order to claim compliance for a particular WCAG level, every part of the website must meet every WCAG requirement for that level (as well as for the levels underneath it).

What is covered?

The WCAG standard is composed of four basic principles, with a number of guidelines that lay out specific requirements for meeting those principles. The principles are:

  • Perceivable. This is the most straightforward: information must be presentable to the user in a way that he or she can perceive. This includes things like text alternative for non-text content (pictures, recorded audio, recorded video), not communicating information solely by color, allowing the user to resize text, etc.
  • Operable. This means that a user is able to navigate the website. This includes obvious things like being able to navigate using a keyboard alone, without losing focus, but also things like not having anything that flashes more than three times per second, which could trigger a seizure.
  • Understandable. This principle at first seems more subjective; who’s to judge whether the text of a website is understandable or not? Guidelines here include that the browser can determine what language the page is in, explaining abbreviations (such as by putting the first use of the abbreviation immediately after the expanded form, as we did with WCAG and ADA above), and making the website perform in predictable ways (for example, having consistent navigation).
  • Robust. The website can be interpreted reliably by a variety of user agents – this is any piece of software acting on behalf of the user, such as a screen reader. This includes things like closing tags (so that the site can be parsed correctly) and associating labels with their corresponding fields.

Getting started

Because the standards include things like website navigation, the easiest way to meet them is to design in accessibility from the very beginning. Failing that, the guidelines are relatively straightforward to test for, and many of the accommodations, such as providing alt text for images, are fairly trivial to make. Even small changes like this can make a huge difference for someone trying to use your site, and many of them benefit your typically-abled users as well.

When to say “I don’t know”

Many years ago, I taught middle school math. One day a student asked me a (non-math related) question that I didn’t know the answer to, so I told her that I didn’t know. She then got annoyed with me because apparently, teachers are supposed to know everything.

I was reminded of this recently when seeing comments about hiring people because they weren’t afraid to admit in an interview that they didn’t know something. Apparently this is somewhat uncommon, which suggests that an awful lot of people are trying to BS their way through interviews.

Of course, nobody wants to hear “I don’t know” to every question, but assuming that you’re qualified for the job you presumably can answer most of them. This applies to working as well; I’d much rather you tell me that you don’t know how to do the task you’re assigned than pretend you already know and get in over your head.

So, here are some acceptable ways to say “I don’t know”:

  • I’m about 80% confident that this is the answer, but I’d have to double check to be sure.
  • I haven’t worked on that functionality, but Jim would know. Let me conference him in.
  • I can’t give a firm deadline for when the project will be completed because we’re waiting on feedback from QA. I’ll follow up with them and see when they expect to be done testing.

Here are some less acceptable ways to do it:

  • I don’t remember. [And I’m too lazy to look it up]
  • I don’t know. [And I can’t be bothered to find out]
  • It was exactly 1,429.3. [Or some other BS answer]

Simply put, if you don’t know something but can find out the answer or direct me to the person better suited to answer the question, that’s just fine. If you are the person who should know the answer, but for some reason you don’t, then you should be finding out; don’t just shrug it off or (worse) make something up. Nobody (well, except apparently some 7th graders) expects you to know everything, but if you’re being lazy or BSing the answer, people won’t be particularly eager to work with you.

tldr: You don’t have to know or remember everything; just be honest.