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.
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.
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.
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.
- Habits and expectations from a familiar language can create blind spots when working in a new language.
- 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.