Pear Programming

Hack the Gap 2019

Mon, 28 Jan 2019 00:00:00 +0000

I was able to volunteer for Hack the Gap 2019, January 26th-27th, and it was amazing. I can’t imagine how much work it is to put on an event like this and it went as smoothly as I could have imagined. I applaud all of the organizers for putting in so much time and effort to make this work. I personally did very little. I saw a tweet go out a few weeks prior to the event asking for volunteers and mentors and I signed up to help.

Initially I had a morning shift that was just 3 hours volunteering, but I asked for another shift to allow for time to mentor participants. On Saturday morning I was doing my best to greet people on the way into the building, “Hello, good morning! You can sign in at the desk and then take the elevator up to floor 5.” After my greeting duties I spent time helping the breakfast and coffee vendors bring everything up to the event floor and work with several others to setup breakfast for all of the participants. After breakfast setup, I waited to make sure all of the participants had been through the line before getting breakfast for myself and sitting down for introductions and announcements.

Introductions and announcements led to raffles for prizes including books, memberships to coworking spaces, and tickets to a Dessa concert. After intros and raffles the organizers led into forming teams for hacking on projects. The team formation format was similar to the ‘Open Spaces’ format that I’ve participated in at DevOpsDays conferences, however ‘Open Spaces’ is focused on discussion and not hacking. Participants formed a line, and had 30 seconds to pitch the project that they wanted to work on with other people. Then there was a round of people showing interest in the different projects to filter out projects that wouldn’t have enough people or wouldn’t have a team with diverse skillsets to be able to build something in two days of work. The projects that had enough interest and a team with diverse skillsets formed up, were assigned an area for working together, and got to hacking. I was scheduled to volunteer Saturday morning from 7am to 10am, and it was about 10:15am when teams were getting settled into their areas. I left from my morning shift to spend some time at home.

In the afternoon, I came back for my mentoring shift from 5pm to 10pm on Saturday. There was dinner shortly after I showed up, and I introduced myself to the other mentors and volunteers that were helping out on Saturday night. From the perspective of a mentor, things mostly ran themselves on Saturday night and the teams were mostly self-sufficient. The most common problems were teams having issues with Git force pushes, JavaScript syntax, and installing Node.js projects on Windows. I was able to help with about 4-5 small problems while I was there, which may not seem like a lot, but it speaks to the ability of the participants to work together to solve problems as a team.

At 10pm I was exhausted and it was time for me to leave. I was busy on Sunday so I didn’t get to attend the demos in person, but I saw plenty of posts online and the projects looked great. My congratulations go out to the all of the participants. I had a lot of fun meeting everyone and getting to help out in a small way and I would volunteer more of my time next year.

Memorizing

Tue, 24 Apr 2018 00:00:00 +0000

Memorizing syntax and APIs will make you a faster software developer, but not better or smarter.

Interview race conditions

Mon, 11 Sep 2017 00:00:00 +0000

I recently asked an interviewee a question about APIs. The question was along the lines of, “Explain how you would ensure that a signup API allows only unique emails.” The interviewee’s answer was essentially, “check if the email exists before allowing the user to signup.” In many cases this would be fine. The user would sign up and after the record is created the API would check if the users exists and prevent other users from signing up with a duplicate email.

However, if there are multiple ways to sign up that duplication check has to be performed everywhere, if one is missed there could be duplicate emails in the database. Aside from this, to simply “check if the email exists before allowing the user to signup” allows for a race condition.

It could be the case that the form was improperly implemented and allows the user to click sign up multiple times while the user is being signed up. In this case there could be multiple requests in-flight at the same time. Each request to the API could check whether the email for the user is unique, and each one receives the same answer, that the email doesn’t exist yet. At this point each request moves along with creating the user and now multiple copies of the same user exist in the database 😱.

The interviewee wasn’t aware of unique database constraints in SQL databases. Adding a unique constraint to the column containing the users email will ensure that only unique emails can signup, it would also be prudent to store all of the emails in lowercase characters.

These are subtle software problems, that assuredly exist in many different APIs.

In this instance the solution that I outlined is a simple one and this problem can be avoided.

React, Qualitatively Better

Sun, 01 Mar 2015 00:00:00 +0000

React is a pretty great JavaScript library, it’s not a full framework, but it’s an extremely coherent view layer for a web application.

The Virtual DOM is an implementation detail, it allows React to re-render quickly, but this initially differentiating feature may turn into a checkmark if/when all frameworks and view layer libraries implement updates in this fashion. It doesn’t make React special in terms of the DOM. But in terms of providing an abstraction for rendering, the Virtual DOM is huge, React Native and using React to render into HTML5 canvas prove this completely.

React also feels more like server-side rendering than traditional JavaScript client side rendering. It’s a very simple model to reason about, ignore the state of the DOM, keep the state in JavaScript, keeping state to a minimum and let React sort out writing to the DOM. A lot of problems come up when state is kept in the DOM in the form of data attributes and css classes, it forces a lot of manual bookkeeping to deal with updating the DOM, React allows developers to ignore an entire swath of problems.

The API surface area of React is small in comparison to other libraries, it can take much less time to be effective using React. This is a really big deal. The surface area of other well-known JavaScript frameworks is often much larger and more extensive than React. But this smaller API surface doesn’t make React less powerful. Fewer features does not mean less powerful, it simply means the features must be pulled in from elsewhere, like utility libraries such as Lodash.

JSX is simple sugar to allow consumers to write code that looks more like an HTML tag tree than the nested function calls that are output by the compiler. Every <div> is transformed into React.createElement('div'). Functional composability is huge in React, refactoring a component into multiple components is usually very straight forward function extraction.

Early warnings are also a pretty big deal when it comes to React. When I use class= on a React component, console warning messages will be logged asking me if I really meant className=, and it’s right, I did mean className because of specific restrictions in React about HTML properties vs attributes. react-a11y from @ryanflorence provides messages in the same vein as the main React library offering details about accessibility problems with returned spec for the DOM.

React.PropTypes offers development checking around properties passed through components. Warning in development when values passed through components do not match expectations. The checking is intended to be for development only so checking is only informational.

The flexibility of React is understated or not well understood without a good familiarity with React. The interoperability with existing tools is extremely important. React can work with any major library out there, for better or for worse.

The benefits of React are great, it has it’s downsides as many frameworks do. Performance for initial render will never be as good as hand writing DOM manipulation.

React is greater than the sum of it’s parts. It helps to guide you into the pit of success.

Pull Request Review

Mon, 02 Feb 2015 00:00:00 +0000

When developing software with other people, code review is important. It’s a sign that a project or part of a project is nearing completion or a bug is nearly fixed. Code review also allows feedback from other contributors. Opening a pull request can be a learning opportunity for both the implementer and the reviewers.

In open source, a complex pull request should come with an upfront discussion one of the maintainers. The maintainers may have no interest in maintaining the changes you intend to make so it’s best to not waste valuable time if the work is unlikely to get merged. It’s worth the time to have a conversation.

During code review, when I see syntax or a construct with which I am unfamiliar I make a point to ask a question, “Is this correct?”, “How does this syntax work?”, “Is there a clearer way to express this?”. Usually I can learn something from the answer. Avoid finger pointing and using the word ‘you’. “Why did you do it this way,” would be an example of a type of finger pointing to avoid.

If I understand the implementation but I have an idea for how it could be expressed in clearer terms I will offer a suggestion for a fix including an implementation, possibly in pseudo-code.

If indentation is off, I assume the author didn’t see the mistake, and comment where the fix should be made. I like to ask a question like “Would you mind changing the formatting to something like this?” and follow up with a suggested implementation. If three or four lines are hard to read due to formatting or a line is too long, responding with the exact suggested fix is much better than responding with “Fix formatting here.”

I always hope that I don’t have to make nitpicking comments about formatting. I make a habit of reviewing diffs before committing, and checking if there are any obvious formatting mistakes. When I create a pull request I self-review all of the changes, and hope I can fix them before another person reviews, comments, and my inbox is flooded. The self-review is important to me because I will make changes over the course of several commits and all of the commits together may not be cohesive.

The learning part

When reviewing pull requests, sometimes I will see this commit message, “Made changes based on PR feedback.” Those words are hard to read. They can convey several messages including, “I don’t agree with your feedback”, and “I don’t understand what you’re talking about but I’ll make the changes”. It’s very unfortunate for me when I see those words. It tells me the writer wasn’t able to create a meaningful commit message because they didn’t understand the changes or why they might be necessary. It also means I wasn’t able to teach them or they are unwilling to learn.

Humility

Code review is about technical feedback and constructive criticism, does it work, can you understand it today, will the changes be easy to understand tomorrow.

Things to avoid in pull requests

These are simply my personal preferences, I like to stick to taking care of business.

+1’s
Joke responses to feedback
Joke comments on changes
Ignoring feedback
Ignoring tests
Destructive criticism
Demands instead of questions
Finger pointing, using the word ‘you’
Taking feedback personally

Understanding NaN Values

Wed, 07 Jan 2015 00:00:00 +0000

A co-worker recently had issues with NaN values in JavaScript. NaN values are IEEE 754 Floating-Point number values. These values result from an undefined or unrepresentable value in floating point calculations. NaN values are number values despite everything your brain might tell you when you read NaN as ‘Not a Number’. In the case of NaN values it’s useful to forget all logic and intuition, and memorize the facts.

JavaScript reports NaN values as number types, this is correct per the ECMA-262 and IEEE 754 specs.

typeof NaN; // 'number'
Object.prototype.toString.call(NaN); // '[object Number]'

In JavaScript a NaN value is the only type of value that is not reflexive. That’s one way to identify a NaN value. x !== x where x is a NaN value will evaluate to true. The global isNaN method can be used to identify NaN values. However, the isNaN method doesn’t handle converting input to a number. It has a set of gotchas.

isNaN(NaN);   // true
isNaN(0/0);   // true
isNaN({});    // true
isNaN('NaN'); // true
isNaN('str'); // true
isNaN('1');   // false
isNaN([]);    // false

When certain inputs are passed to the isNaN method the behavior is less than ideal. Several false positives are returned. Both Underscore and Lo-Dash handle the shortcomings of the isNaN method by checking if the value is a number.

_.isNaN(NaN);   // true
_.isNaN(0/0);   // true
_.isNaN({});    // false
_.isNaN('NaN'); // false
_.isNaN('str'); // false
_.isNaN('1');   // false
_.isNaN([]);    // false

As written above NaN values are number values so _.isNumber(NaN) correctly returns true for both Underscore and Lo-Dash. Both libraries have had issues filed for incorrect behavior, but the behavior is correct and the answer is usually to point consumers to the _.isFinite method.

Issues also arise when dealing with builtin methods such as Array.prototype.indexOf. NaN values are unable to be found without special handling.

[0,1,NaN,3].indexOf(NaN); // -1

The ES6 draft specifies a solution to the global isNaN method with a new Number.isNaN method. Number.isNaN returns the same results Underscore and Lo-Dash return.

Number.isNaN(NaN);   // true
Number.isNaN(0/0);   // true
Number.isNaN({});    // false
Number.isNaN('NaN'); // false
Number.isNaN('str'); // false
Number.isNaN('1');   // false
Number.isNaN([]);    // false

The ES6 draft also specifies Object.is, offering a better way to determine if two values are equal over the strict equality operator, triple equals. Object.is works as the strict equality operator with two exceptions: NaN values, and positive and negative zero.

Object.is(NaN, NaN); // true
Object.is(-0, +0);   // false
NaN === NaN;         // false
-0 === +0;           // true

When my co-worker was having issues and asking question about NaN values he called ‘wat’ on JavaScript. I took it upon myself to set the record straight, but realized everyone who encounters NaN values must learn about these problems, hence this post. It’s important to understand this behavior is not specific to JavaScript. It is specific to all languages that use IEEE 754 Floating-Point number calculations.

Ruby has the following behavior with regards to NaN values.

Float::NAN.is_a?(Float)  # true
Float::NAN.nan?          # true
(0/0.0).nan?             # true
Float::NAN == Float::NAN # false
(0/0.0) == (0/0.0)       # false

Java has the following behavior with regards to NaN values.

double x = Double.NaN;
Double.isNaN(x);            // true
System.out.println(x != x); // true
System.out.println(x == x); // false

The behavior across Ruby, Java, and JavaScript is essentially the same. Every single consumer of these languages must eventually learn the rules of NaN values. I hope consumers of these languages are now able to understand the issues at hand and deal with them thoughtfully.