A Conjuring of Light ends the Shades of Magic trilogy, although apparently a new trilogy set in the same universe is on its way. All the major threads are closed, although some of them felt a little forced and some of the drama was clearly artificial. But at least it all ends, which is one of the major reasons I read this book, only to see how Victoria Schwab's characters will end up.

I felt that this was the more ambitious volume of the three in the series, with all three Antari having to interact, with foreign dignitaries stuck in the royal palace while it was under siege from a demented magical creature who believed itself a god, with ties with families and past revealed, with new places and new magic. However, the book was quite inconsistent. For example, there is a plan to use a spell to seal the god in a body. When it is inside one, they forget about it and fight him with knives and fire and what not. There is a spell that could restore Kell's memory. He wonders if he should use it, then we forget about it. As for Grey London (ours) and Black London (the one where the creature originated), they are completely ignored.

The personalities of the characters also change a lot, with everyone acting brave and selfless (sometimes to stupidity) as if forgetting we are talking about a ruthless street thief, a killer turned sociopath by years of torture and so on. To me it seemed as if the author wanted a tough story, but she couldn't help turning it into a classic hero quest with a happy ending.

Bottom line: I had fun reading the series, but I won't continue with the next trilogy. It's not bad, but it's not above average either.

Kind of obvious, but I wanted to make it clear and to remember it for the future. You want to make something appear or not based on a toggle button, usually done by adding a click handler on an element with some code to determine what happens. But you can do it with HTML and CSS only by using the label element pointing to a hidden checkbox with its for attribute. Example:

Toggle me!   I have been toggled!

Here is the HTML and CSS for it:

<style>
     /*  you have to use a caption element instead of a control element inside the label, so a button would not work and we use a span to look like a button */
     .button {
       border: solid 1px gray;
       padding: 5px;
       display: inline-block;
       user-select: none;
       cursor: pointer;
     }
 
     /* the element after the unchecked checkbox is visible or not based on the status of the checkbox */
     #chkState + span { display: none; }
     #chkState:checked + span { display: inline-block; }
  </style>
  <label for="chkState">
    <span class="button">Toggle me!</span>
  </label>
  &nbsp;&nbsp;&nbsp;
  <input type="checkbox" style="display:none" id="chkState" />
  <span>I have been toggled!</span>

Update: You might want to use an anchor instead of a span, as browsers and special software will interpret it as a clickable, but not input control.

Update: You can, in fact, instruct the browser to ignore click events on a button by styling it with pointer-events: none;, however that doesn't stop keyboard events, so one could navigate to the button using keys and press Space or Enter and it wouldn't work. Similarly one could try to add an overlay over the button and it still wouldn't work for the same reason, but that's already besides the point. Anyway, either of these solutions would disable the visual style of the clicked button and web sites usually do not use the default button style anyway.

There is one reason why you should not use this, though, and that is usability. I don't know enough about it, though. In theory, a label should be interpreted the same as the checkbox by software for people with disabilities.

There is this channel I am subscribed to, with various people discussing or demonstrating software development concepts, with various degrees of success. I want to tell you about this series called CSS3 in 30 Days which is very well organized and presented by a clearly talking and articulate developer, Brad Hussey. He's nice, he's Canadian.

And before you go all "I am a software programmer, not a web designer", try watching it for a bit. Personally I am sure I would have solved a lot of what he demos using Javascript. Changing your perspective is a good thing. Note it is about CSS3, which had quite a few improvements over the classical CSS you may know already.

Here is the first "day" of the tutorial:

Paranoia Agent (or Delusion Agent, maybe) is an anime by famous anime director Satoshi Kon, unfortunately killed by cancer in 2010. His work is always more than it seems, focusing on the inner worlds of people and how they all perceive things differently.

The anime is only 13 episodes and starts with a simple case of violent assault on the street and then becomes stranger and stranger until it is not clear which is real and which is in someone's head. It critiques the repressive Japanese society and human nature in general, it goes from police procedural to slapstick comedy, from horror to psychological drama. The ending is, as they say, a mystery that doesn't stay solved for long. I quite liked the anime and I recommend it highly. It is rarer and rarer to find Japanese anime which is not derivative or simply idiotic.

It involves Russia! The story of how Boris Pasternak's Doctor Zhivago got popularized and received the Nobel prize for literature is fascinating and one of the reasons why my wife and I decided to read it as part of our own private book club. She loved the book, although she admitted she didn't understand a lot. I couldn't finish it because I didn't understand it at all!

Let me get this straight, this is not a bad book, the fault lies solely with me. That being said, I've read half of it before I decided to watch the TV adaptation from 2002 and realized I had no idea who anyone was. I had read half of a book, enjoying the way Pasternak describes individual lives, but I didn't remember one character or scene. And the explanation is simple: this is like Crash, on steroids, had sex with Gone With The Wind and had this bastard child around the first World War in Russia. People have three different names, plus nicknames, that the author just splays around without explanation. Events are described through short chapters that sometimes connect via a character seeing the same things from a different perspective or saying something about a character, using a different name than the one we read about it previously. And all these people keep bumping into each other again and again. Sometimes there is no rhythm in how things are written, sometimes it sounds like poetry. There is huge attention to some details and complete ignoring of others. And so on. It is not an easy book; it requires your full attention.

It is obvious that Pasternak loved people and he described their experiences and toils during times of great upheaval, but for him those paled compared with the love stories and the feelings of the characters involved. I can understand how he was confused on why people thought his book was against the Soviet system, where it was clearly about people. I am sure this book is great, it is just not for me. If you want to try it, I suggest you read the summary in Wikipedia so you understand what is going on and you do not read it in bits of 15 minutes in the subway.

I started watching Killing Eve, the BBC TV series starring Sandra Oh and Jodie Comer, and I quite liked it. So I've decided to read the books it is based on, Codename Villanelle being the first one. The result is a mixed bag. I clearly prefer the TV show, but the book is not bad either. They are, I have to say, quite different.

While both focus on a police woman trying to find a highly skilled female professional sociopath assassin, the show adds a little dark humor, which is both nice and off putting, while the book is going for the full "secret world of spies and weapon technobabble" route, which is also half and half. I think Luke Jennings wanted to write a simple spy story, inspired by the likes of John le Carré, while the show screenwriters have more ambitious goals. Most of the little episodes there are based on stuff in the book, but wholly reinterpreted, the characters changed or added, their fates changed.

But enough about TV. The book is easy to read, but a bit one sided: kill after kill and the chase of the department that has to uncover not only the identity of the killer, but also who are the high placed people who help hide her tracks, without most of the emotional exposition that makes a character relatable. Funny enough, there is more emotional content related to the killer than the cop. Makes you wonder which one of them is the psycho sometimes.

In conclusion, I will not read the rest of the books, but I will continue to watch the TV show. I feel like reading the first book opened my eyes on what the characters were supposed to be and thus Codename Villanelle acted like a nice companion book for an interesting series that I enjoy watching.

I liked Binti, even it is a short story. It is my first contact with the Nigerian-American author Nnedi Okorafor and I loved how African ideas blended with science fiction concepts in Binti. I will probably read the others in the trilogy, sooner or later.

The story is about a girl that leaves her tribe and planet to go to a university she was just admitted to. Just when getting there, an alien race of Medusae kills everybody except her. You will have to read why that happens and how she becomes the ambassador of the aliens, because the story is short enough to get spoiled by a detailed review. The writing is not without flaws and the character is dangerously close to the one in Who Fears Death, but I felt that it made a lot more sense in the context of an interstellar Federation as in Binti.

Read it. It was fun.

Who Fears Death is an interesting book mainly because of the Nigerian background of Nnedi Okorafor, the author, and the subject vaguely inspired by the atrocities in Sudan. The fantasy plot revolves around a girl resulted from intertribal rape who has to deal with the injustices of her world using her magical powers. Imagine a Harry Potter book in a German extermination camp scenario where he is a Jewish girl and you get close. In fact, this and other books on the subject of tribal hatred in Africa should make any white supremacist feel good about themselves, because there is no worse racism than between violent religious uneducated tribes that pretty much look the same.

Yet the book's interesting factor kind of stops there. The African culture references throughout the story keeps it entertaining, but the plot is a classic hero arc with pretty much all of the flaws inherent to the genre. Hero is young and powerless, discovers powers, is guided by mentors that keep from her just about everything there is to know and use up until she needs it, evil villain to whom she has a direct connection and opposition, friends that are there just to support the hero, things that happen for no other reason than they needed to further the story in a particular direction, she has amazing powers but uses them sparingly and often is stopped from using them for moral reasons by her friends and so on. In fact, it gets a lot worse, considering the hero is an African girl who could get killed at any moment by an angry mob just for the color of her skin, moving around in a society where even her boyfriend thinks it's OK to keep things for himself or treat her patronizingly just because of her gender, not to mention the old male mentors.

So while the book is interesting and well written, it does have a major flaw in the way it was structured as a story. Perhaps the docile Black woman who occasionally gets upset and then regrets it resonates better with African audiences, but for a Westerner it might get a little frustrating. It is a book worth reading, mainly because of the culture shock one experiences while reading it, but it could have been better.

Who writes like this in this day and age? Around 10% in the book I was convinced The Great Influenza was written sometime in the middle of last century, when people still did painstaking research and paid attention to every detail, not like now, when researching something involves trying different Google keyword combinations ad nauseam. And how many people can pack so much information and knowledge into a book that is also easy to read and incredibly captivating? Apparently, John M. Barry, with this book published in 2004.

I can't stress enough how much I liked this book. I would give it 6 stars out of 5 just because I rated books with 5 stars and this is an order of magnitude better. Imagine that I only found it because I was curious about the influenza epidemic from 1918, what is popularly known as The Spanish Flu, and at the time I was worried that one book on the subject would clearly not be enough. Not only would it present just one point of view, but surely various interests or lack of resources would influence (pun not intended) the end result. Instead I was shamed, that is the right word, by the amount of care the author used to research and write this book.

In order to explain what the book is about I would have to write a lot about The Spanish Flu, a disease that killed between 50 and 100 million people globally within six months in the middle of a five year world war that killed just 20 million in military and civilian deaths combined. Yet very few people care about it or even know about it. There are few documents about it, no movie that I know of, very few books. Inside the pages of The Great Influenza are the seeds of a dozen Steven Spielberg war movies, various crossings of The Outbreak with The Knick and a few Netflix series - I find it criminal that no one thought about it so far. Therefore, I urge you to first read a little about the disease itself, on Wikipedia and Google like normal people, then read this book. It will blow you away.

John Barry is clearly an investigator at heart. Not only does the work for this book, but clearly empathizes with the people who fought to understand disease and find cures, locked in laboratories and sacrificing everything for understanding. He calls them The Warriors, the name of the first part of the book, where he describes the history of medical science in the Unites States and the people how would ultimately champion it further and fight the outbreak. The second part (out of ten) describes the disease: a type of influenza so virulent that it makes the immune system destroy the body it's supposed to protect. Only from the third chapter on we start reading about how the pandemic started, what influenced its movements, how people reacted and so on. The last two chapters are solely about the after effects (almost as important as the ones during the pandemic). A whopping 10% of the book is just notes and thanks and references.

Also relevant, I think, is the fact that Barry is American and clearly proud of it. The book has a very American centric view, not only because of the nationality of the author, as probably because it would have been a lot more difficult to research the actual events in other parts of the world. Yet even for an American patriot the book is filled with outrage at the way governments and local authorities and narrow minded bureaucrats treated the disease and the people affected by it. For an European as I am, the way a fanatical American president managed to turn an entire country into a weapon, effectively disabling the values that Americans are known for: democracy, freedom of speech, pursuit of happiness, etc, is beyond chilling. America was a sleeping giant way before Pearl Harbor and the way it awakens and consumes everything and everyone that stands in its way is ironically similar to the way the influenza virus swept the world. One of the main reasons people don't know about the disease is because any mention of it that could have affected morale during times of war was censored in the land of the free. The name Spanish Flu itself comes from the fact Spain was not censoring its media at the time.

Bottom line is that I urge everyone to read this book. It's a wonderful example of how one man can dedicate seven years to research and document something as scary, monumental and mysterious such as the great influenza pandemic of 1918, analyse it from multiple viewpoints, name, quote and praise the people who were right in the midst of battle, the unsung scientist heroes of unheard of laboratories and the people who gave them the wind under their wings. Great job, John Barry, great job indeed!

There is a way to execute an installation using msiexec, like this: msiexec /i MySetup.msi /l*v "mylog.log", but what if you routinely install stuff on a machine and want to be able to read the log only when there is a problem? Then you can use the group policy editor to set it up:

1. Run "Edit group policy" (gpedit.msc)
2. Go to Computer Configuration → Administrative Templates → Windows Components → Windows Installer
3. Select "Specify the types of events Windows Installer records in its transaction log"
4. Select "Enabled"
5. Type any of the letters in 'voicewarmupx' in the Logging textbox
6. Click OK

This will create the following registry entry:

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer]
  "Logging"="voicewarmupx"
  "Debug"=dword:00000007

Warning: this setting will add time to the installation process based on the options selected. Here is a list of the possible options:

• v - Verbose output
• o - Out-of-disk-space messages
• i - Status messages
• c - Initial UI parameters
• e - All error messages
• w - Non-fatal warnings
• a - Start up of actions
• r - Action-specific records
• m - Out-of-memory or fatal exit information
• u - User requests
• p - Terminal properties
• + - Append to existing file
• ! - Flush each line to the log
• x - Extra debugging information. The "x" flag is available only on Windows Server 2003 and later operating systems, and on the MSI redistributable version 3.0, and on later versions of the MSI redistributable.

The log files will be found in your %TEMP% folder, usually C:\Users\[your user]\AppData\Local\Temp.

I wrote some unit tests today (to see if I still feel) and I found a pattern that I believe I will use in the future as well. The problem was that I was testing a class that had multiple services injected in the constructor. Imagine a BigService that needs to receive instances of SmallService1, SmallService2 and SmallService3 in the constructor. In reality there will be more, but I am trying to keep this short. While a dependency injection framework handles this for the code, for unit tests these dependencies must be mocked.
C# Example (using the Moq framework for .NET):

// setup mock for SmallService1 which implements the ISmallService1 interface
var smallService1Mock = new Mock<ISmallService1>();
smallService1Mock
  .Setup(srv=>srv.SomeMethod)
  .Returns("some result");
var smallService1 = smallService1Mock.Object.
// repeat for 2 and 3
var bigService = new BigService(smallService1, smallService2, smallService3);

My desire was to keep tests separate. I didn't want to have methods that populated fields in the test class so that if they run in parallel, it wouldn't be a problem. But still, I didn't want to copy paste the same test a few times only to change some parameter or another. And the many local variables for mocks and object really bothered me. Moreover, there were some operations that I really wanted in all my tests, like a mock of a service that executed an action that I was giving it as a parameter, with some extra work before and after. I wanted that in all test cases, the mock would just execute the action.

Therefore I got to writing something like this:

public class BigServiceTester {
  public Mock<ISmallService1> SmallService1Mock {get;private set;}
  public Mock<ISmallService2> SmallService2Mock {get;private set;}
  public Mock<ISmallService3> SmallService3Mock {get;private set;}
 
  public ISmallService1 SmallService1 => SmallService1Mock.Object;
  public ISmallService2 SmallService2 => SmallService2Mock.Object;
  public ISmallService3 SmallService3 => SmallService3Mock.Object;
 
  public void BigServiceTester() {
    SmallService1Mock = new Mock<ISmallService1>();
    SmallService2Mock = new Mock<ISmallService2>();
    SmallService3Mock = new Mock<ISmallService3>();
  }
 
  public BigServiceTester SetupDefaultSmallService1() {
    SmallService1Mock
      .Setup(ss1=>ss1.Execute(It.IsAny<Action>()))
      .Callback<Action>(a=>a());
    return this;
  }
 
  public IBigService GetService() =>
    new BigService(SmallService1, SmallService2, SmallService3);
}
 
// and here is how to use it in an XUnit test
[Fact]
public void BigServiceShouldDoStuff() {
  var pars = new BigServiceTester()
    .SetupDefaultSmallService1();
 
  pars.SmallService2Mock
    .Setup(ss2=>ss2.SomeMethod())
    .Returns("some value");
 
  var bigService=pars.GetService();
  var stuff = bigService.DoStuff();
  Assert.Equal("expected value", stuff);
}

The idea is that everything related to BigService is encapsulated in BigServiceTester. Tests will be small because one only creates a new instance of tester, then sets up code specific to the test, then the tester will also instantiate the service, followed by the asserts. Since the setup code and the asserts depend on the specific test, everything else is reusable, but also encapsulated. There is no setup code in the constructor but a fluent interface is used to easily execute common solutions.

As a further step, tester classes can implement interfaces, so for example if some other class needs an instance of ISmallService1, all it has to do is implement INeedsSmallService1 and the SetupDefaultSmallService1 method can be written as an extension method. I kind of like this way of doing things. I hope you do, too.

I liked A Gathering of Shadows more than the first book in the series, A Darker Shade of Magic. It felt more grounded, more meaty. A large part of the book is split into two parts as Kell and Lila walk their separate paths only to collide in the middle and be tragically broken apart towards the end. There are more characters, more world building.

Not all is rosy, though. There are still huge swaths of pointless exposition, followed by truncated bits of action. In this book, a part of the focus is on a magical tournament that all characters are somehow involved with, so a big part of the story you wait to see what is going to happen when wizards fight each other. And then there are the scenes of battle which are either a few paragraphs long or simply summarized because Victoria Schwab didn't really care for the characters fighting or because she wanted to focus on a (bloody hell, I am so tired of this cliché!) love triangle. I also wish Lila would have had a more interesting arc, other than going to sea for 4 months and returning a world class magician without an actual event to drive her evolution. It's basically a "she read some books, watched some YouTube tutorials and she was smart" story.

I found it funny that this book ends in a gigantic cliffhanger. So large, in fact, that in the acknowledgements at the end the author apologizes. She managed to write four books that didn't end in cliffhangers, so she is allowed this one, she reasons. Is this an emotional need for writers, to hang their readers? Something so powerful that they just have to do it from time to time in order to feel alive? Kind of like magic, eh? :)

Anyway, I am happy to say that I will probably read the next book in the series and not only because of the cliffhanger, but because I am actually interested in what the characters will do. I have other things on my plate first, though.

I have been working in software development for a while now, but one of the most distracting aspects of the business is that it reinvents itself almost every year. Yet, as opposed to computer science, which uses principles to build a strategy for understanding and using computers and derive other principles, in business things are mostly defined by fashion. The same concept appears again and again under different names, different languages, different frameworks, with a fanatic user base that is ready to defend it to the death from other, often very similar, fads.

That is why most of the time junior developers do not understand basic data object concepts and where they apply, try to solve a problem that has been solved before, fail, then start hating their own work. Am I the definite authority on data objects? Hell, no! I am the guy that always tries to reinvent the wheel. But I've tried so many times in this area alone that I think I've gotten some ideas right. Let me walk you through them.

The mapping to Hell

One of the most common mistakes that I've seen is the "Database first" vs "Code first" debate getting out of hand and somehow infecting an entire application. It somehow assumes there is a direct mapping between what the code wants to do and what the database does. Which is wrong, by the way. This kind of thinking is often coupled with an Object Relational Mapping framework that wants to abstract database access. When doing something simple, like a demo for your favorite ORM, everything works perfectly:

• The blog has a Blog entity which has Post children and they are all saved in the database without you having to write a single line of SQL.
• You can even use simple objects (POCOs, POJOs and other "plain" objects that will bite you in the ass later on), with no methods attached.

That immediately leads one to think they can just use the data access objects retrieved from the database as data transfer objects in their APIs, which then doesn't work in a myriad of ways. Attempting to solve every single little issue as it comes up leads to spaghetti code and a complete disintegration of responsibility separation. In the end, you just get to hate your code. And it is all for nothing.

The database first or code first approaches work just fine, but only in regards to the data layer alone. The concepts do not spread to other parts of your application. And even if I have my pet peeves with ORMs, I am not against them in principle. It is difficult not to blame them, though, when I see so many developers trying to translate the ease of working with a database through one such framework to their entire application. When Entity Framework first appeared, for example, all entity objects had to inherit from DbEntity. It was impossible to serialize such an object or use it without having to haul a lot of the EF codebase with it. After a few iterations, the framework knew how to use POCOs, simple objects holding nothing but data and no logic. EF didn't advocate using those objects to pass data around your entire application, but it made it seem easy.

What was the root problem of all that? Thinking that database access and Data Access Objects (DAOs) have a simple and direct bidirectional mapping to Data Transfer Objects (DTOs). DTOs, though, just transfer data from process to process. You might want to generalize that a database is a process and your application another and therefore DAOs are DTOs and you might even be right, but the domain for these objects is different from the domain of DTOs used to transfer data for business purposes. In both cases the idea is to limit costly database access or API calls and get everything you need in one call. Let me explain.

DAOs should be used to get data from the database in an efficient manner. For example you want to get all the posts written by a specific author inside a certain time interval. You want to have the blog entities that are associated with those posts, as well as their metadata like author biography, blog description, linked Facebook account, etc. It wouldn't do to write separate queries for each of these and then combine them in code later. API DTOs, on the other hand, are used to transfer data through the HTTP interface and even if they contain most of the data retrieved from the database, it is not the same thing.

Quick example. Let's say I want to get the posts written in the last year on a blog platform (multiple blogs) and containing a certain word. I need that because I want to display a list of titles that appear as links with the image of the author next to them. In order to get that image, I need the user account for the post author and, if it has no associated image, try to get the image from any linked social media accounts. In this case, the DAO is an array of Post objects that each have properties of type Blog and Author, with Author having a further property holding an array of SocialAccount. Of course, SocialAccount is an abstract class or interface which is implemented differently by persisted entities like FacebookAccount and TwitterAccount. In contrast, what I want as a DTO for the API that gives me the data for the list is an array of objects holding a title, a link URL and an image URL. While there is a mapping between certain properties of certain DAO objects to the properties of DTO objects, it is tiny. The reverse mapping is ridiculous.

Here are some issues that could be encountered by someone who decides they want to use the same objects for database access and API data transfer:

• serialization issues: Post entities have a Blog property that contains a list of Post entities. When serializing the object in JSON format for API transfer a circular reference is found
• information leaks: clients using the API get the Facebook and Twitter information of the author of the post, their real name or even the username and password for the blog platform
• resource waste: each Post entity is way bigger than what was actually requested and the data transferred becomes huge
• pointless code: since the data objects were not designed with a graphical interface in mind, more client code is required to clean the title name or use the correct image format

Solutions that become their own problems

Using automatic mapping between client models and DTOs is a common one. It hides the use of members from static analysis (think trying to find all the places where a certain property is used in code and missing the "magical" spots where automatic conversion is done), wastes resources by digging through class metadata to understand what it should map and how (reflection is great, but it's slow) and in the cases where someone wants a more complex mapping relationship you get to write what is essentially code in yet another language (the mapper DSL) in order to get things right. It also either introduces unnecessary bidirectional relationships or becomes unbalanced when the conversion from DAO to DTO is different from the one in the other direction.

Another is to just create your own mapping, which takes the form of orphan private methods that convert from one entity to another and become hard to maintain code when you want to add another property to your entity and forget to handle it in all that disparate code. Some try to fix this by inheriting DAOs from DTOs or the other way around. Ugh! A very common solution that is always in search of a non existent problem is adding innumerable code layers. Mapper objects appear that need to have access to both types of data objects and that are really just a wishful thinking brainless replacement of the business logic.

What if the only way to get the image for the author is to access the Facebook API? How does that change your mapping declaration?

Let me repeat this: the business data objects that you use in your user facing application are in a completely different domain (serve a different purpose) than the data objects you use in the internal workings of your code. And there are never just two layers in a modern application. This can also be traced to overengineering and reliance on heaps of frameworks, but it's something you can rarely get away from.

Don't get me wrong, it is impossible to not have code that converts from one object to another, but as opposed to writing the mapping code before you even need to use it, try to write it where you actually have need of it. It's easier to write a conversion method from Post with Blog and Author and Social Account to Title with two links and use it right where you display the data to the user than to imagine an entire fantasy realm when one entity is the reflection of the other. The useful mapping between database and business objects is the role of the business layer. You might see it as a transformation layer that uses algorithms and external services to make the conversion, but get your head out of your code and remember that when you started all of this, you wanted to create an app with a real life purpose. Technically, it is a conversion layer. Logically, it is your software, with a responsibility towards real life needs.

Example number 2: the N-tier application.

You have the Data Access Layer (DAL) which uses a set of entities to communicate with the database. Each such entity is mapped to a database table. This mapping is necessary for the working of the ORM you are using to access said database. The value of the DAL is that you can always replace it with another project that implements the same interfaces and uses the same entities. In order to abstract the specific database you use, or maybe just the communication implementation, you need two projects: the entity and interface project and the actual data code that uses those entities and accesses a specific database.

Then you have the business layer. This is not facing the user in any way, it is just an abstraction of the application logic. It uses the entities of the business domain and, smart as you are, you have built an entire different set of entities that don't (and shouldn't) care how data is accessed or stored in the database. The temptation to map them in a single place is great, since you've designed the database with the business logic in mind anyway, but you've read this blog post that told you it's wrong, so you stick to it and just work it manually. But you make one mistake: you assume that if you have a project for interfaces and DAO entities, you can put the interfaces and entities for the business layer there as well. There are business services that use the business data objects, translate DAOs into business data objects and so on. It all feels natural.

Then you have the user interface layer. The users are what matters here. What they see, what they should see, what they can do is all in this layer. You have yet another set of entities and interfaces, but this is mostly designed with the APIs and the clients that will use it in mind. There are more similarities between TypeScript entities in the client code and this layer's DTOs than between them and the business layer objects. You might even use a mapping software like Protobuff to define your entities for multiple programming languages and that's a good thing, because you actually want to transfer an object to the same type of object, just in another programming language.

It works great, it makes you proud, you get promoted, people come to you for advice, but then you need to build an automated background process to do some stuff using directly the business layer. Now you need to reference the entity and interfaces project in your new background process project and you can't do it without bringing information from both business and data layer. You are pressed for time so you add code that uses business services for their logic but also database entities for accessing data which doesn't have implemented code in the business layer.

Your background process now bypasses the business layer for some little things, which breaks the consistency of the business layer, which now cannot be trusted. Every bit of code you write needs to have extra checks, just in case something broke the underlying data. You business code is more and more concerned with data consistency than business logic. It is the equivalent of writing code assuming the data you use is being changed by a hostile adversary, paranoid code. The worst thing is that it spends resources on data, which should not be its focus. This would not have happened if your data entities were invisible to the new service you've built.

Client vs server

Traditionally, there has always been a difference between client and server code. The server was doing most of the work while the client was lean and fit, usually just displaying the user interface. Yet, as computers have become more powerful and the server client architecture ubiquitous, the focus has shifted to lean server code that just provides necessary data and complex logic on the client machine. If just a few years ago using Model-View-Controller frameworks on the server, with custom DSLs to embed data in web pages rendered there, was state of the art, now the server is supposed to provide data APIs only, while the MVC frameworks have moved exclusively on the browser that consumes those APIs.

In fact, a significant piece of code has jumped the network barrier, but the architecture remained essentially the same. The tiers are still there, the separation, as it was, is still there. The fact that the business logic resides now partly or even completely on the web browser code is irrelevant to this post. However, this shift explains why some of the problems described above happen more often even if they are as old as me. It has to do with the slim API concept.

When someone is designing an application and decides to go all modern with a complex framework on the client consuming a very simple data API on the browser they remember what they were doing a few years back (or what they were taught in school then): the UI, the business logic, the data layer. Since business and UI reside on the browser, it feels as if the API has taken over for the data layer. Ergo, the entities that are sent as JSON through HTTP are something like DAOs, right? And if they are not, surely they can be mapped to them.

The reality of the thing is that the business logic did not cross all the way to the client, but is now spread in both realms. Physically, instead of a three-tier app you now have a four tier app, with an extra business layer on the client. But since both business layers share the same domain, the interfaces and entities from one are the interfaces and entities from the other. They can be safely mapped because they are the same. They are two physical layers, but still just one logical business layer. Think authentication: it has to be done on the server, but most of the logic of your application had moved on the client, where the user interacts directly with it (using their own computer resources). The same business layer spread over client and server alike.

The way

What I advocate is that layers are defined by their purpose in life and the entities that pass between them (transfer objects) are defined even stricter by the necessary interaction between those domains. Somehow, through wishful thinking, framework worshiping or other reasons, people end up with Frankenstein objects that want to perforate these layers and be neither here nor there. Think about it: two different object classes, sharing a definition and a mapping are actually the same object, only mutated across several domains and suffering for it. Think the ending of The Fly 2! The very definition of separation means that you should be able to build an N-layered application with N developers, each handling their own layer. The only thing they should care about are the specific layer entities and interdomain interfaces. By necessity, these should reside in projects that are separated of said layers and used only by the ones that communicate to each other.

I know it is hard. We choose to develop software, not because it is easy, but because it should be! Stop cutting corners and do it right! I know it is difficult to write code that looks essentially the same. The Post entity might have the same form for the data layer and the business layer, but they are not the same in spirit! Once the application evolves into something more complex, the classes will look less like twins and more like Cold War agents from different sides of the Iron Curtain. I know it is difficult to consider that a .NET class should have a one-to-one mapping not to another .NET class, but a JavaScript object or whatever the client is written in. It is right, though, because they are the same in how you use them.

If you approach software development considering that each layer of the application is actually a separate project, not physically, but logically as well, with its own management, roadmap, development, you will not get more work, but less. Instead of a single mammoth application that you need to understand completely, you have three or more projects that are only marginally connected. Even if you are the same person, your role as a data access layer developer is different from your role when working on the business layer.

I hope that my thoughts have come through clear and that this post will help you avoid the same mistakes I made and that I see so many others make. Please let me know where you think I was wrong or if you have anything to add.

I was trying to create an entity with several children entities and persist it to the database using Entity Framework. I was generating the entity, set its entry state to Added, saved the changes in the DbContext, everything right. However, in the database I had one parent entity and one child entity. I suspected it had something to do with the way I created the tables, the foreign keys, something related to the way I was declaring the connection between the entities in the model. It was none of that.

If you look at the way EF generates entities from database tables, it creates a two directional relationship from any foreign key: the parent entity gets an ICollection<Child> property to hold the children and the child entity a virtual property of type Parent to hold the parent. Moreover, the parent entity instantiates the collection in the constructor in the form of a HashSet<Child>. It doesn't have to be a HashSet, though. It works just as well if you overwrite it when you create the entity with something like a List. However, the HashSet approach tells something important of the way EF behaves when considering collections of child objects.

In my case, I was doing something like

var parent = new Parent { 
  Children = Enumerable
                .Repeat(new Child { SomeProperty = SomeValue }, 3)
                .ToList() 
};

Can you spot the problem? When I changed the code to

var parent = new Parent();
Enumerable
   .Repeat(new Child { SomeProperty = SomeValue }, 3)
   .ToList()
   .ForEach(child => parent.Children.Add(child));

I was shocked to see that my Parent had only a list of Children with count 1. Why? Because Enumerable.Repeat takes the instance of the object you give it and repeats it:

Enumerable.Repeat(something,3).Distinct().Count() == 1 !

There was no problem that I was setting the Children collection to a List instead of a HashSet, but when saving the children, Entity Framework was considering the distinct instances of Child.

The solution here was to generate different instances of the same object, something like

var parent = new Parent {
   Children = Enumerable.Range(0,3)
                .Select(i => new Child { SomeProperty = SomeValue }, 3)
                .ToList()
};

or, to make it more clear for this case:

var parent = new Parent {
    Children = Enumerable
                .Repeat(() => new Child { SomeProperty = SomeValue }, 3)
                .Select(generator => generator())
                .ToList()
};

In 2014 Yuval Noah Harari became world wide famous for the English publication of his book Sapiens: A Brief History of Humankind. A lot of my friends recommended it, I couldn't turn around without hearing about it, but before I could read it, I watched some videos and TED talks from the guy so I was hearing the slightly whiny voice and I was imagining the face and mannerism of Harari while I was reading the book. And the truth is the book feels just like an extended version of one of his lectures. I found the book interesting, with some insights that were quite nice, but I think it started a lot better than it ended.

It goes through the history of our species, starting with the origins, going through the changes that shaped our society and identity. It goes on to explain, for example, how almost everything our society is based on is a myth that we collectively cling to and give power to. And he is not talking about religious myths only, but also notions like country, nation, race, money, law, human rights, justice, individuality, good, bad, etc. Like a house of cards, once we started to be able to think abstractly and communicate ideas, we've created a world that is based on assumptions on top of assumptions that we just choose to believe. I thought that was the most interesting point in the book and the one that made me think most. If our entire life as a species and as individuals is axiomatic, then how different could lives be if only based on other axioms?

Another great insight was that liberalism and individuality, coupled with the capitalist growth model that is based on a scientific and technological trust in a better future, are very recent inventions. Most of human history, even up to the nineteenth century, people were content with the status quo, were nostalgic about some bygone era that was "golden" and better than today, and people were stuck into their lives with no hope or even thought of changing them. The explosion of new discoveries and conquests comes from a new found hope in a better future, one based on technological progress and scientific discovery. Other ways of living weren't worse, they just were obliterated by people who chose to accept that they don't know everything and started looking for resources to plunder and answers to their questions. In contrast, whole societies and empires based on the holiness of stations manned by people who assumed knew everything stagnated for centuries.

Yet another point that I found interesting was about the state and commercial institutions eroding and replacing the traditional. Before the legal, moral, support, educational and emotional systems were part of the family or the extended community. Now they are outsourced to law, financial institutions, psychologists, schools, which thrive on the concept that we are individuals and need no one.

Harari makes the point that we are the product of evolution, not different from any other animal, but once we went over a threshold, we created new arenas in which to evolve. Something I didn't particularly agree with is his view that hunter gatherers were living a better, more content life, than farmers. Rather than working all day for a very limited diet, they were free to roam and enjoy the seasonal food that was literally hanging around. Further on we went through the Industrial Revolution and people were even more restricted by the rules of technology and industry. A big portion of the book is dedicated to this kind of thoughts about how our success bound us to a way of life we now cannot escape. The author even uses the word "trap".

In the end, Sapiens tries to analyse our state: is it better now than before? It goes through chapters that talk about happiness: what is it? do we have it? does it matter? Harari is probably agnostic, but he does favor Buddhist ideas of meditation and escaping misery by removing craving, and that is pretty obvious by the end of the book.The last chapter contains a short and kind of reused discussion about the future of us as gods that remake the very fabric of our bodies, minds and reality and, of course, the singularity. But while at the beginning each historical step of Homo Sapiens was analysed with scientific attention, with insights that were clearly coming from a lot of thought on the subject, by the end the rhetoric devolved into just expressing opinions.

So, I did like the book. It felt a bit too verbose, because Harari's style is to explain something, then give an example to make it clearer. If you understand what he explained, the example feels superfluous most of the time. I also didn't like that the book started great, with careful analysis and beautiful insights, and ended with obvious personal opinions superficially backed by facts. I could have accepted either one, but having both just highlights the contrast between them.

As a final thought, Harari mentioned Jared Diamond's Guns, Germs, and Steel (1997) as one of the greatest inspirations for the book by showing that it was possible to "ask very big questions and answer them scientifically". I tried reading that and it was way too thorough and heavy. So having something like Sapiens is like light reading for people who are interesting in science but not very bright :)