Friday, July 01, 2022

Laughter and creativity - Peter Pendleton Eckersley

It cannot be more sufficiently emphasized that, that pioneer adventure was born in laughter, was nurtured in laughter, and died in laughter.

And I want to believe that if only people would see their jobs; if only people would see their lives in terms of its humor, of its excitement, and that a job well done deserves laughter.

Not the solemnity of the pompous administrator on top of it.

If we could only see that the thing that we do is a God-given thing, for heaven's sake,  because it's creative and it's fun and it's exciting.

Then, I think, all these certificates, all these rules, all these rather dull regulations might be seen to be unnecessary.


Peter Pendelton Eckersley - on the bureaucracy that came at the start of the BBC

Thursday, June 09, 2022

Plant trees while you search for error descriptions

 Ecosia logo

Ecosia is a search engine that uses some of the money they make from selling advertising to plant trees. You make a small change to your search behavior and they plant some trees. It's simple.

There's even an extension for Chrome to make it your default search engine. (You should install it 😉)

Under the hood it uses Bing to provide the search results, so you'll still get high-quality results. This isn't some random, small company trying to compete with Google on Search.


That all sounds good, but I've done a bad thing.

I've changed a default setting.

Shock. Horror!

For my Error Helper extension for Visual Studio, the default is now (as of v2.4) to search with Ecosia.

Changing default settings is something you should only do with great care and for very good reason as it can surprise, confuse, and frustrate the people using the software.


If you're not aware of my extension, it provides some additional options when you right-click on an entry in the Error List. The one of particular interest here is the option to easily search for the text of the error message. Sometimes, error messages don't give you all the information you need to address an issue and so it's necessary to ask the internet for help.

Screenshot showing the context menu options added by the extension

But I did it for a very good reason.

I wanted to help raise awareness of Ecosia, and in turn, help create a world with more trees in it.

This will help plant a few trees based on usage and people not even realizing anything's changed.

The impact on existing users of the extension will be minimal as it will continue using whatever they were using with the previous version. Even if that was the old default.


I'm just trying to do something to help other people make the world a slightly better place with minimal effort on their part.


Don't want this? That's ok, you can still configure the extension to use, Bing, Google, or StackOverflow as the search engine of choice.


If you're very upset by this, simply send me your receipt for your purchase of the extension and I'll give you a full refund. (Just kidding, the extension is free!)


Sunday, May 29, 2022

Creating binary logs from Visual Studio

 [Again, this is mostly for my own reference, so I can find the link again quickly in the future]


It's possible (and well documented) to save detailed and binary log files when compiling code with MSBuild.

But, if you are getting different results when using MSBuild and Visual Studio, it isn't as easy to create the equivalent logs from Visual Studio.

Well, my search-fu may not always find it, but there is a way to do this. Details at https://github.com/dotnet/project-system-tools#getting-higher-fidelity-logs-from-vs-vs2022-onwards 


Thursday, May 26, 2022

Testing against old versions of Visual Studio

[This is mostly for my own reference, so I can find the link again quickly in the future]

Partial screen shot of the Visual Studio Installer showing multiple versions installed on the same machine

If developing Visual Studio extensions, it can sometimes be useful (and necessary) to have different versions of Visual Studio installed.

Previously I achieved this by having preview and non-preview versions installed and being careful about how and when I updated them to newer versions.

However, I recently had to also test against a version older than I had installed on any of my machines.

Well, it seems the lovely people on the Visual Studio team already have this scenario covered.

It's possible to get older versions of VS that don't prompt for updates. This allows the installation of multiple versions on the same machine without having to worry about updating them.

Get them from:

https://docs.microsoft.com/en-us/visualstudio/releases/2022/release-history#fixed-version-bootstrappers



Tuesday, May 17, 2022

Why a bug fix should "always" include new tests

Ok, maybe not always, but please don't start by assuming you're the exception.

(Note that exceptions should come with an adequate, documented explanation.)


So, imagine the scenario: You find something wrong in the code base, so you fix it.

Simple enough and almost certainly a good thing. 

But, consider the bigger goal that we don't just want a codebase with fewer bugs in it we also want a codebase that is easy to maintain, so that future bugs or changes (there will be some) are also easy (and quick) to address.

By adding or changing code without adding tests, we risk making future changes harder/slower.

Going back to the bug you fixed. How was it discovered? I'm going to assume it wasn't because of a failing test.

It was probably found by someone using the code/app/service/whatever or looking at the code. Either way, a manual process.

And how was the change tested? Again, I'm guessing manually.

So what happens when someone has to change something near or related to that code again in the future?

They'll have to test it manually again. But, also, they need to work out (or remember) how to test it manually and work out what all the scenarios they need to test are. Then they have to do that testing in its entirety and without human error. This is unlikely to be fast, thorough, or accurate.

But, also, what if the place where the error in the code was found wasn't the only place that error had been made? Have you really, manually reviewed the entire codebase to look for such an error? How do you know that you really checked *everywhere*? Was that a good use of your time? Additionally, how will you make sure that any future changes to the code don't reintroduce the same bug? Either here or in another part of the codebase? Are you really going to add that to the list of manual checks that are made as part of every code review? I suspect not.

Suddenly, taking the effort to write some automated tests doesn't seem like such a waste of time. Doing so can often be faster than manually retesting something while working on it. Also, having something that checks your code for bad practices, inconsistencies, and anti-patterns is much faster than manually reviewing all but the smallest codebases.


But, what if you don't know how to write tests? Or you don't know how to write a good test for this specific scenario? Well, you find out. Ignorance isn't an excuse.
If working on a codebase as part of a team, ask them. Your whole team wants to work together to create better software and that includes having a codebase that is easy and better for them all to work with.


Maybe I'll write more on getting started with testing or testing difficult things in the future. Don't worry, though; there are a lot of resources about this already on the internet (& elsewhere).



<RantOver />