Full title "Factfulness: Ten Reasons We're Wrong About the World – and Why Things Are Better Than You Think, by Hans Rosling, Ola Rosling, Anna Rosling Rönnlund", this is a book that everyone should read. It's not a masterpiece, in fact it feels banal, but it's this banality that makes it so powerful. Hans Rosling is capable of showing with actual proof that your world view is really really wrong. And not only you, but also the politicians that are supposed to fix the world, the specialists that are supposed to find solutions to all of our problems, the reporters who are supposed to report on the news and the large majority of people are just as confused as you are.

And it is proof of the power of the book that someone like me, who knew who Rosling was and watched his very inspiring TED Talks, was still surprised by its content and teachings.

The book claims that the instincts that helped our ancestors survive are clouding our judgement of the much less dangerous, but more abstract modern world we live in. Rosling enumerates ten, with anecdotes that feel like scenes from TV dramas only to make you doubt who is the villain and who are the heroes. It is the main idea of book that only by working with fact based information we can make the best decisions and take the best possible action to move us forward.

This is not a book that will amaze you with its writing style, it will not make you laugh out loud, nor is it intended to make you feel good, although it probably will. It is facts about things that you felt you knew, but in fact were ignorant of. It is for example heartbreaking to read the part about immigrants in Europe dying and being taken advantage of because of really dumb European laws, not because of their destination countries regimes or from poverty. It is uplifting to know how much the world has changed for the better in just a few decades and all over the place. As a Romanian, I've always assumed that the rest of the world was rich and plentiful outside the Iron Curtain and that the recent improvements in life style were caused mostly by the fall of Communism in the area. I had no idea how similar life was for so many around the time I was born and that life has improved dramatically all over, not just here. It is empowering to know that women make more or less children in consistent correlation to their income and not their culture, religion or regime. When people don't need to have children, they don't make them, regardless of what Mao, the Pope or anyone else says.

Bottom line: you have to read this just as much as you have to get a general education. It simply should be taught in schools.

I had this annoying warning that appeared whenever I would build my Wix setup project. I know, Wix sucks, but what can you do? The warning was warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "SomeProject\Some.dll", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

What is worse, the warning would come in the VS Errors window with no warning code, so I couldn't even supress it. And yes, the text above does show a warning code, but it just wouldn't be intrepreted by Visual Studio.

In order to fix it, apparently I had to set ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch to None, as according to this StackOverflow answer. But where should I add this wonderful property? It didn't work in the .wixproj file, it wouldn't make a difference in the projects mentioned in the warning.

In the end, I decided to customize my build! Final solution:

• add a file called Directory.Build.props to your solution folder
• paste in it

<Project>
 <PropertyGroup>
   <ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>None</ResolveAssemblyWarnOrErrorOnTargetArchitectureMismatch>
 </PropertyGroup>
</Project>

I will show you some code, like in an interview question. Try to figure out what happened, then read on. The question is: what does the following code write to the console:

class Program
{
    static void Main(string[] args)
    {
        var c = new MyClass();
        c.DoWork();
        Console.ReadKey();
    }
}
 
class BaseClass
{
    public BaseClass()
    {
        DoWork();
    }
 
    public virtual void DoWork()
    {
        Console.WriteLine("Doing work in the base class");
    }
}
 
class MyClass:BaseClass
{
    private readonly string _myString = "I've set the string directly in the field";
 
    public MyClass()
    {
        _myString = "I've set the string in the constructor of MyClass";
    }
 
    public override void DoWork()
    {
        Console.WriteLine($"I am doing work in MyClass with my string: {_myString}");
    }
}

I am doing work in MyClass with my string: I've set the string directly in the field
I am doing work in MyClass with my string: I've set the string in the constructor of MyClass

Permanent Record is a very well written book. Ed Snowden has the rare capacity of deep introspection and when he explains what happened and why, he makes connections to his upbringing, events in his life and the world and has a very clear view of his internal processes when making any decision or taking action. He also has a way with words. He's a guy easy to either hate or love, obviously, depending on how prone to envy one is.

There are several important takes from this book.

One is how extraordinary Snowden's position was to make him able to do what he did. Not only is he this brilliant guy who lives in his head and plans everything in advance, not only did he have specialized training on how to do what he did and get away with it, but he was given free access to the underlying technology of the CIA and the NSA. As he himself admits, he was on a list that probably contained under a dozen people, and that only from incompetence and lack of oversight.

Another is that every large organization is the same. Be it the NSA, the state run companies or private corporations in any country, they all impose hiring limits that they break by using contractors that don't affect the count (or their declared principles). It's amazing how similar my own experiences were, but in (supposedly) very different contexts. The contractor system is a global disease that too few benefit from and too many are affected by.

A more salient point is that technology is what happens when there is something we can do. We will ultimately do it, just because we can. As much sympathy I have for Snowden, his actions will probably have short lived consequences. The machine to get all the data from everybody is already there. No one will put that genie back into the bottle. If anything this book helps the very people who the author hopes to thwart by giving them valuable intelligence in the mindset of the whistleblower and on the limitations and vulnerabilities of their technical, administrative and indoctrination systems. As I was saying before, the chances that Snowden happened were astronomically small. Now they are orders of magnitude smaller.

It was devastatingly depressing to read how few places in the world are even marginally free of the American hegemony. Ironically, he had to go to Hong Kong to maximize his chances of remaining free. That says something terrible about the state of the world. I felt like the most hard hitting bits were those that explained what the government would do to discredit him (or anybody in their way), using deeply personal histories, fabricating evidence if none found or amplifying the one that does exist. This makes Snowden even more outstanding, for being a guy with very little dirt in his life to be turned into a weapon.

On a more personal note, it's amazing that reading Permanent Record, I was reminded most of Gary Sinise's autobiography than anything else. Thinking of what Snowden did, a family tradition of serving the country military and strong patriotic spirit is not what would first come to mind, yet that applies to him and he did what he did because he strongly believed in his country and in service to it. Even now, hunted by the US government in the most blunt, unimaginative, bureaucratic and cruel way possible, like big bullies do, Ed Snowden still loves his country and believes in it.

At a glance, Permanent Record is a book on hacking. As a child, Ed starts understanding how the world works and manipulates it to his advantage, only to grow up working in an organization that has hacked the Constitution and society as a whole in order to manipulate it to their advantage. People of our generation grew up with at least the illusion of a fair society, people who would take you at your value and judge you on it, whatever the outcome. The new hacked society cannot see you as you are, to the point that makes you doubt yourself of who you are. There cannot be a fair process of evaluation anymore because everyone comes out distorted.

This is a must read book and I recommend it highly to all adult readers of any level or education. It's easy to read, captivating and relatively small. Fair warning: it's not a happy story.

Let's say you have a Type and you want to find it by the simple name, not the entire namespace. So for string, for example, you want to use Boolean, not System.Boolean. And if you try in your code typeof(bool).Name you get "Boolean" and for typeof(bool).FullName you get "System.Boolean".

However, for generic types, that is not the case. Try typeof(int?). For FullName you get "System.Nullable`1[[System.Int32, System.Private.CoreLib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e]]", but for Name you get "Nullable`1".

So the "name" of the type is just that, the name. In case of generics, the name of the type is the same as the name of its generic definition. I find this a bit disingenuous, because in the name you get encoded the fact that is a generic type or not and how many generic type attributes it has, but you don't get the attributes themselves.

I admit that if I had to make a choice, I couldn't have come up with one to satisfy all demands, either. Just a heads up that Type.Name should probably not be used anywhere.

Welcome to my new blog!

Please let me know what you think.

I've had some issues with Blogger and that pushed me towards the step that I have been too lazy to make for so long a time: my own domain and hosting. So, from today on, my personal blog is at https://siderite.dev. I am working on it, still, so forgive the occasional hiccups.

Let me know if anything is wrong or, even better, that everything is right!

Siderite

(d=n=>('0369'.includes((f=n=>n>9&&f([...''+n].reduce((s,v)=>+v+s,0))||n)&&f(n))&&'Fizz'||'')+(/[05]$/.test(n)&&'Buzz'||'')||n)*(i=n=>n>100||console.log(n+': '+d(n))+i(n+1))*i(1)

One of the best things you could do in software is unit testing. There are tons of articles, including mine, explaining why people should take the time to write code in a way that makes it easily split into independent parts that then can automatically tested. The part that is painful comes afterwards, when you've written your software, put it in production and you are furiously working for the second iteration. Traditionally, unit tests are great for refactorings, but when you are changing the existing code, you need not only to "fix" the tests, but also cover the new scenarios, allow for changes and expansions of existing ones.

Long story short, you will not be able to be confident your test suite covers the code as it changes until you can compute something called Code Coverage, or the amount of your code that is traversed during unit tests. Mind you, this is not a measure of how much of your functionality is covered, only the lines of code. In Visual Studio, they did a dirty deed and restricted the functionality to the Enterprise edition. But I am here to tell you that in .NET Core (and possibly for Framework, too, but I haven't tested it) it's very easy to have all the functionality and more even for the free version of Visual Studio.

These are the steps you have to take:

• Add coverlet.msbuild NuGet to your unit tests project
• Add ReportGenerator NuGet to your unit tests project
• Write a batch file that looks like
  
  

  @ECHO OFF
  REM You need to add references to the nuget packages ReportGenerator and coverlet.msbuild
  IF NOT EXIST "..\..\packages\reportgenerator" (
    ECHO You need to install the ReportGenerator by Daniel Palme nuget
    EXIT 1
  )
  IF NOT EXIST "..\..\packages\coverlet.msbuild" (
    ECHO You need to install the coverlet.msbuild by tonerdo nuget
    EXIT 1
  )
  IF EXIST "bin/CoverageReport" RMDIR /Q /S "bin/CoverageReport"
  IF EXIST "bin/coverage.opencover.xml" DEL /F "bin/coverage.opencover.xml"
  dotnet test "Primus.Core.UnitTests.csproj"  --collect:"code coverage" /p:CollectCoverage=true /p:CoverletOutputFormat=\"opencover\" /p:CoverletOutput=\"bin/coverage\"
  for /f "tokens=*" %%a in ('dir ..\..\packages\reportgenerator /b /od') do set newest=%%a
  "..\..\packages\reportgenerator\%newest%\tools\netcoreapp3.0\ReportGenerator.exe" "-reports:bin\coverage.opencover.xml" "-targetdir:bin/CoverageReport" "-assemblyfilters:-*.DAL*" "-filefilters:-*ServiceCollectionExtensions.cs"
  start "Primus Plumbing Code Coverage Report" "bin/CoverageReport/index.htm"​

  
  
  and save it in your unit test project folder
• Optional: follow this answer on StackOverflow to be able to see the coverage directly in Visual Studio

Notes about the batch file:

• newest is the current version of ReportGenerator, if that doesn't work, change it with whatever version you have (ex: 4.3.0)
• the DAL filter tells the report to ignore projects with DAL in their name. You shouldn't have to unit test your data access layer.
• the ServiceCollectionExtensions.cs filter is for files that should be ignored, like extension methods rarely need to be unit tested

Running the batch should start dotnet test and save the result in both coverage.opencover.xml and also some files in the TestResults folder. Then ReportGenerator will generate an html file with the coverage report that will get open at the end. However, if you followed the optional answer, now you are able to open the files in TestResults and see what parts of your code are covered when opened in the Visual Studio editor! I found this less useful than the HTML report, but some of my colleagues liked the option.

I hope this helps you.