Where Automated Testing Would Have Helped

Yesterday I went to implement a new feature in one of our applications and discovered that a previous feature broke with a certain kind of data input. After doing further investigation I discovered the error was due to a mistake in the fix of a merge conflict. A merge conflict is an issue that arises when a developer is trying to combine changes to a file from two places that are not compatible. Usually it is because the file was changed in both places.

Merge conflicts can be large or small but they are one of the parts of software development that requires judgement and can be subject to human error. You might have a function that references variable A at first, then is updated to reference variable B in one update, and then variable C in a different branch (that never had the variable B in its commit history). When you go to merge GitHub will ask if you want to reference B or C. Now the developer must figure out which one is correct. It may be the case that they have to add logic to account for both cases.

In both commits a developer could have written an automated test to check that their changes work correctly. If a developer picks the incorrect variable name (or neither work) then when editing the merge conflict the automated test suite will fail. The developer is saved time from manually checking to see if they made the correct choice. If the team has setup continuous integration then the build will fail and the team will be warned not to merge it. The test also would have served as guidance and documentation to the merging developer of what they should have done to correctly merge the two files.

While automated testing can be a bunch of work on the front-end, this sort of scenario is one where it saves work and time later on. The best part is that when you are writing code is when it is easiest to write the automated tests for the code. This saves you time and effort later on.

Lessons Learned Re-learning Javascript

Below are some lessons I have learned while re-learning Javascript since it has changed so much:

  1. Habits and expectations from a familiar language can create blind spots when working in a new language.
  2. A language like Javascript that changes a lot creates a larger distance between available documentation/solutions and their testing and implementation in your own project.
  3. It is worth slowing down to understand how to appropriately and quickly debug in the new language. It might take a little time to develop the toolset but it pays off so much later on.

Each one of these points has a story. The first one involves me forgetting that Javascript does not have implicit returns. I managed to spend a large amount of time wondering why a Javascript function was returning undefined instead of the result of the expression I put at the bottom of the function. In Ruby the last expression is always evaluated as a return statement. Other developers have argued that Javascript maybe should have thrown an error instead of returning undefined, but either way a bunch of my time was burned because my brain was not looking for the return keyword in my functions.

The second one involves trying to integrate a download feature in my current project. While Googling I found several solutions to allow a Javascript application to prompt a user to download a file. The solutions often involved examples, examples often being some of the best documentation. However they fell flat because we had converted our project to modern Javascript we syntax things like decorators were not reflected in the tutorial example. I had to sit down and understand the difference between the old and new syntaxes so I could translate the older style Javascript code from the tutorial into the newer style code in my current project.

Finally the best thing I did was discover how to quickly run Javascript using Sublime Text’s build system. While it is not helpful for certain front-end code, being able to write a Javascript function with business logic and an example is a great way to narrow in errors before implementing it in the larger project. By speeding up the feedback cycle and understanding debugging, I was able to more quickly produce code that did the right thing.

National Day of Civic Hacking

On August 10, 2018 the organization I help run, Code for Boston, is hosting its National Day of Civic Hacking event at the Venture Cafe at the CIC in Kendall Square. You can register for this event at Eventbrite.

Typically Code for America affiliated brigades run a hackathon every single year, but one of the things we have learned is that while popular, the hackathon format requires a lot of work and people do not always want to spend a weekend indoors. In Boston summer weekends are precious and we know that folks often prefer to be outside if it is nice, so we decided to have an evening Ignite talk event. This worked out well for us because we have not done an Ignite format event in a long time and it enables us to aim to put together a well-run hackathon style event in the autumn.

We are also working to make our events more inclusive. In order to do this we have been trying to have programming to broaden our appeal. We are adding workshop programming to our weekly hack nights so that folks who do not want to hack on a specific project but learn a new skill can participate that way. We are also actively working to help folks start projects. As our old projects spin down we are realizing that our new project intake process does a good job of enumerating the qualities of a successful project but also sets a high bar in helping folks get to that bar. The main thing we are able to help with is recruiting folks for project leadership positions with a Google form and message to our Meetup group. While we have received some feedback that the greater structure around our organization has caused it to lose some of its free wheeling appeal, our attendance appears to be higher this summer than in the past so it seems like it is working.

Motorola Arris Cable Modem Epilogue

After receiving my replacement cable modem from Motorola Arris I went through the process of setting it up with Comcast. Only a week later the new modem suffered from the same problem as the old one. This was frustrating because it meant that the problem I suffered was likely a design flaw instead of a manufacturing error. It also meant I did not manage to find the root cause.

After resetting the modem I decided to take another swing at Googling my issue. This time my Googling was better and I find a thread on Broadband Reports describing similar symptoms to mine. A large number of folks on this forum suggested that the issue was the upload being saturated on the modem causes it to crash. The recommended fix was to go into my router settings and to set a limit on upload going from the router to the modem.

Sure enough this fix appears to have worked, at least so far. I set an upload maximum equal to Comcast’s stated service level speed (they usually provision the upload at a bit faster than that) and have been running my modem without issues for about a week now. If this works and was truly the cause it is frustrating for multiple reasons. First is that given the wisdom of the crowd on the forum, it is likely that Motorola Arris knows about this issue. Yet they did not mention it as a possibility. Second if they did not know about the issue it is disappointing that such a large company lacked awareness of the problem that appeared pervasive enough to generate online conversation. Surely they could do better by their customers.

A Video is Worth 1000 Words

One of my most popular YouTube videos was a screencast I made about using NGPVAN’s MiniVAN software. When I worked at the Connecticut Democratic Party we had a lot of people who needed to understand how to use mobile software and did not want to read instructions and/or did not find the interface intuitive. The success of this video has made me realize that when it comes to communicating how to use software, a screencast can often be one of the best tools in the toolbox.

After realizing that I suggested that we make screencasts for a new application we are launching at work next week. I was not sure that people actually wanted me to make the screencasts so was a little surprised when I was asked if I could do them yesterday. Fortunately the best part of screencasts is they are easy to make. Apple’s Quicktime software has built in screen recording capabilities. It took me only a couple hours to do multiple takes and produce three screencasts that would be really useful for users of our software.

The not surprising thing is Apple has integrated a form of screen casting into their marketing for a while. If you look at some of their ads you can see they are teaching you how to do something new for your iPhone. These ads serve a dual purpose. The first is they teach existing users how to do something on their phone they did not know how to do. The second is they show people who do not have iPhones what they are missing. I wonder how many iPhone users tried making a slow motion video after seeing that ad.

Follow Zagaja.com posts: RSS Feed
This work by Matt Zagaja is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.