Man It’s a Hot One

From the New York Times:

The continental United States had its hottest month of May and the third-hottest month of June. Japan was walloped by record triple-digit temperatures, killing at least 86 people in what its meteorological agency bluntly called a “disaster.” And weather stations logged record-high temperatures on the edge of the Sahara and above the Arctic Circle.

Fish Shell

For the past couple years I have been using mostly ZSH as the shell on my Mac because it has special features. However, over the weekend, I discovered and have been trying the fish shell. So Far using the fish shell has been enjoyable compared to using ZSH. It includes some of the features I really enjoy about ZSH but also has lots of features that quickly help you recall terminal commands or look up their documentation. It provides all its extra features by default. This was a big improvement from dealing with ZSH which required add-ones and configuration to fully expose its best magic.

As the fish site says, it works out of the box:

fish will delight you with features like tab completions and syntax highlighting that just work, with nothing new to learn or configure.

While it is worth understanding bash, using a shell like fish on your personal machine can make life an inch easier as you engage in software development.

Why Code for America and Code for Boston Take Donations

Yesterday someone asked me why Code for America was soliciting for donations via email. The answer ends up being mundane: Code for America is a non profit so they run entirely on donations. Some are from big donors and tech companies but some also come from smaller donors. Folks can donate to Code for America and earmark it to Code for Boston and that’s how we pay for pizza, events, etc.

Since folks at Code for Boston donate their time we try to not ask for direct donations and focus on corporate contributors, but other brigades operate more like a co-op where people put in money for food every week. We have considered asking members for donations before but so far have been lucky enough to generally not have to do that.

Over the next few months I will likely be doing more fundraising for Code for Boston to make sure we have money in our account to cover our expenses. While we are not in danger of running out of pizza money, raising capital can help us put on better events and reimburse some of the developer and core team expenses that we want to cover. If your company or organization wants to sponsor Code for Boston get in touch or donate online.

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.

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