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 :)

So I was writing this class and I was frustrated with the time it took to complete an operation compared to another class that I wanted to replace. Anyway, I am using Visual Studio 2017 and I get this very nice grayed out font on one of my fields and a nice suggestion complete with an automatic fix for it: "Use auto property". Why should I? Because I have a Count property that wraps a _count field and simply using the property is clearer and with less lines of code. It makes sense, right?

However, let's remember the context here: I was going for performance. So when I did ten million operations with Count++ it took 11 seconds, but when I did ten million operations with _count++ it took only 9 seconds. That's a staggering 20% increase in used resources for wrapping one field into a property.

The idea is nice: multiple versions of the same city of London, somehow named the same, even when the countries and the languages and the magic is different from world to world. Then there is the magician who can go between worlds and the charismatic female thief who accidentally steals from him exactly in the moment of a great change in the structure of power between these worlds.

While I liked the idea and even enjoyed the characters, I felt like Victoria Schwab was more in love with the story than with the characters. Barely sketched, they do things because they do things, not because of an inner drive that makes a lot of sense for them. Even the villains are standard psychopaths doing bad things because they like doing bad things. Plus they kind of suck. I liked A Darker Shade of Magic, I think I may read the rest of the series, but I barely managed to feel anything for the characters. Whenever something needed to happen, some prop or person appeared right then and there. Everybody had stunted emotions that only seemed to push people to action when the plot required it, rather than as a natural consequence of feeling something and plot holes were a plenty.

The bottom line is that I can't recommend this book to anyone, even if I enjoyed reading it.

On the 3rd of August I get this email from IFTTT, a service I have been using to automatically post Blogger posts to Facebook: Hello siderite,

Facebook has recently made significant changes to their platform. One of those changes includes removing the ability for third party applications, like IFTTT, to publish status messages, link posts, and photos on your behalf to your personal Facebook profile.

The following three Facebook actions will be removed from IFTTT starting today, along with any Applets that used them:

• Create a status message
• Create a link post
• Upload a photo from URL

While it’s unfortunate to see some of your favorite Applets removed, we support Facebook’s decisions to evolve their platform in the way they best see fit.

Thank you for your understanding.
The IFTTT Team

It was nice that at least they warned me, but how can anyone imagine that the best way to announce breaking changes in your clients' systems is to write an email that says "from this very second we are going to rip it all away from you"? Even funnier, they link to this Facebook policy change link that was published on April 24th and which announces their own breaking changes starting from the 1st of August. See, IFTTT? This is how you warn your customers: three months in advance.

Strangely enough, some of the applets work, while some just disappeared. I don't mean disabled, I mean completely gone, with no trace or warning on what they had been. Probably these will soon be gone as well. So expect (from this very second) that blog posts will not appear regularly on Facebook until I fix the problem with my own tool. On the other hand, you can always subscribe to the blog itself via RSS, a well proven technology ever since 1999 (that's the reason they partied then). You know that something is good quality when engineers name it: the first letter of its acronym comes from another acronym and when you don't understand what it means even if you have all the words.

Imagine Me Gone is one of those books that I thought I should read because it received prizes for great writing. Maybe I'm too stupid to understand why something that doesn't say anything in the first 5% of it is a good book. The subject is great, too: a family of five people that each describe their lives while battling crippling depression.

I think Adam Haslett found a good way to convey depression: talk endlessly about random pointless things, describe the weather, the way light bounces off of things no one cares about, don't actually express anything or mention anything interesting and occasionally say something really heavy or personally relevant with the same boring and bored rhythm and style. It makes sense, it's the way people feel when in the thralls of this terrible affliction: nothing matters, nothing stands out, it's all grey and pointless. However, a good book means more than just making the reader feel suicidal, it has to have some story to care about, some characters that stand out, anything than just forcing the reader to fight throwing away the book in boredom.

That is why I couldn't even begin to finish the book. I wasn't interested in the depressed description of someone I couldn't care less about, talking about how she handles the depression of others. I can only assume that the high marks for the book are coming either from writing that went completely over my head or from people who were affected by mental illness in the family and read about themselves and got the book. My family is not without its share of psychological problems, but I've had just about enough of it as it is.

I've read some books in Alastair Reynolds' Revelation series and I more or less liked them. So when I've heard of a new book from the same author I've decided to try it. The result is mixed. For most of Revenger I disliked the characters and the story, but the ideas in it made me want to see what was going to happen next.

What you need to understand is that this is a straight pirate story, only set in the future and in space. It starts with two girls that decide to leave their world and join a spaceship crew in order to make some money. Only they get jumped by pirates, so one of the girls must fight the system and her own nature to become hard enough to find the pirates and save her sister.

The problem is that the characters are hard to empathize with, are pretty inconsistent and always stretch belief in this world in which space crews are uneducated louts speaking in jargon and going from world to world in search for ancient technology they cannot understand that was left by long gone alien races. The only part of the book that made me want to read the next one was the very end, the rest was people acting weird, not thinking too much and speaking a lot.

Bottom line: I can't recommend the book. I might read the next one, after all the books in Revelation Space had wildly varying degrees of quality. The ideas are nice, the implementation is what hurts the book.

I liked Dreadnought, the first book in the Nemesis series. It was fresh, with a sympathetic character that went through some major changes in life. The team was interesting, the villain, too. A bit too female centered, a bit naive, but hey: it's about a teenage transgender superhero. What could I have expected? It says something about the book that I read the next one in the series.

Unfortunately, I almost disliked Sovereign. The discussions about weird sexuality (without actual sex scenes) and the characters that are connected to transgender issues increased, the character development stalled, some people simply disappeared (Danny's parents say two phrases in total in one appearance), the villain's motivation is stupid, the heroics are random and the drama and tension that should have kept a reader to the edge of the seat, curious to see what will happen next, are almost non existent. When people die, the heroes kind of shrug it off: "oh, we killed some people. Sucks!" Not an actual quote, but it felt like this. And the only reason why they find out about the villainous plan is because the head vil is literally inviting Danielle to his mansion to explain said plan. Some things happen just because the story couldn't go on without them, and it's painfully obvious. I understand April Daniels may have identified too much with her characters and is not eager to torture them, but the book felt like a kiddie show in written form.

I finished the book, but I won't be interested in the future of the series. And it's too bad. I felt that this concept was going places.

Ruthana Emrys wrote the short story The Litany of Earth as a reinterpretation of Lovecraft's The Shadow over Innsmouth, where the people of Innsmouth were actually the victims of persecution from the government. Extending the story to the first book in a trilogy, Winter Tide acts as a sequel to the Lovecraft short, telling the story of some of the few people of the water working with the US government to investigate the misuse of their magical rituals.

If in Shadow over Innsmouth, the horrible fish people were being righteously rounded up by the authorities and interned into camps, their town and traditions forcibly destroyed, in this book they are the victims of persecution, a subspecies of humans that just wants to be left alone. Their magical rituals are more about communion than power, but some of them can be terribly misused, like the body swap technique. This gives the author opportunity to add to the story the Yith, ancient race of mind travelers who have the only concern to archive the experiences of sapient beings before they go extinct - with the added horror that they face any extinction event themselves by mass swapping into another civilization, leaving those poor souls displaced in unfamiliar bodies and facing certain doom - depicted by Lovecraft in The Shadow Out of Time, as well as hint of a body swap misused as means of trying to achieve immortality, as told by Lovecraft in The Thing on the Doorstep. So when one of the last females of the water people is asked to help by an FBI agent, she decides to put aside her distrust and horror and help the ones who murdered her people in the purpose of at least preserving her race's reputation and preventing the use of their magical arts in the terrible world wars the air people were waging.

You have to admit when you think Lovecraft, you don't often imagine a gay female author writing about the importance of diversity, community and love, yet this is what Winter Tide is. And it has a quintessentially female style of writing, where the lead character helps the people she should normally hate in order to bring peace, she solves problems by bringing people together and treating them with familial love and encouraging their differences rather than using violence. Her purposes are selfless and she wields power not as a sword, but as shelter.

While the style felt a little too formal and the pace was rather slow at the beginning, I found myself wanting more by the end of the book. It felt like a strange melange of Lovecraftian lore, notoriously difficult to bring to a modern form - yet Emrys did it effortlessly - and a style of writing that brought it back to a more ancient feel, thus relating modern themes in a work that still tastes like Lovecraft. The second book in the series, Deep Roots, just came out and I intend to read it as well.

I am sure I only heard of this book because of the agenda of some of the sites I visit, but I do not regret reading it. Dreadnought is about a teenage boy obsessed with comic book heros who secretly wants to be a girl. When he gets his wish (plus some awesome superpowers) he has to deal with the lack of understanding from parents and people he thought of as friends. At first I thought "Oh, no, I fell for it again. It's going to suck! It's going to be Sense8 on paper. I am going to read the entire book about how bad cis-people are". I am glad that it wasn't so, so before you automatically dismiss the book, think again.

While the main character is transgender, this only adds some complexity to it, without polluting the main thread of the story, which is a typical teenage superhero saves the world kind of thing. The way the world is described reminds me a bit of Wild Cards and maybe also some of those Union Dues books about powered people who get screwed over by politics and unions that were so popular on Escape Pod: metahumans are common, some of more power than others, heroes have leagues and are commonly recruited (and financed) based on their abilities, bad ones always try to take over the world while a majority of them are doing whatever they can with what nature gave them. The issues the main character has revolve mostly on how her bully of a father is messing her life after the transformation. Her parents want "their son back" and try to "fix" what happened to her. Meanwhile she is hunting for the biggest supervillain there is, trying to deal with her asshole family, handling the pressure from superhero adults who try to tell her what to do before explaining anything and ... do homework for school.

This is not a masterpiece, mind you. I enjoyed the book, which is rather short and pretty naive, because I actually thought the story was interesting, however it is mostly typical YA crap with a fresh perspective. A second book in the series from April Daniels is already out, Sovereign, and I intend to read it as well. I hope it's at least as good as Dreadnought. I was kind of hoping that it would be a different hero in each book, but it's the same in each. If you like that kind of diversity between viewpoints, I really recommend you read the Wild Cards series. It's huge, though.

Just after finishing some mediocre books from Brandon Sanderson I started with Oathbringer, as if to remind me why I like this author so much. As Lift would say, the book is awesome! It's not without its flaws, but it is a mammoth in size, great in quality, epic in scope.

The third book in The Stormlight Archive, ambitiously planned as a ten book series, Oathbringer focuses more on Dalinar Kholin rather than Kaladin, who one might think was the main character of the series. Yet it also expands the characters already introduced and brings even more. There are histories that explain what is going on: the Voidbringers are back, another Desolation has begun, Parshendi will become agents of chaotic destruction under the control of mighty Odium, their god, who wants nothing more than to bring the end of the world, and the only hope comes from Heralds, Knights Radiant and people united against their common foe. But is that what happens? Who are the Voidbringers, really? Why are parshmen awakening, but instead of agents of destruction most behave like normal people who have just woken up from stupor? Are the Radiants united under the same purpose? Are they even the good guys? Where are the Heralds and who among them are still sane? Who's god is Odium and what does he really want? And when spren become corrupted by one god or another, what happens when you bond one? All these questions make for not only a good exciting read, but an intelligent one, as well. I felt the adventurous reader, the engineer and scholar in me all enjoy the book.

As for the bad part, the book is, as were the others in the series, quite large. Maintaining pace, or indeed even pretending there is one for the entire book, is impossible. Some parts are bound to bore, while others to annoy when perspective inevitably switches away from them. Sanderson paints each character as the hero of their own story, creating understanding and compassion for almost all and bringing them up and down as the story progresses, and while this is a worthy goal and a mark of a good writer, it takes a toll on the reader who would rather just root for the good guys. Probably worse of all, the next book in the series is optimistically planned for 2020, which means another two years of yearning for the mere continuation of the story. It is a book that feels more wide than it is long and waiting for fifteen years for the series to end so one can read it all it is not manageable either. So yeah, my biggest complaint with Oathbringer is that it is too good.

I loved the Reckoners series and Elantris. Funny enough the Mistborn series that Sanderson is known for threw me away and some of the recent attempts like Legion felt just bad. Yet The Stormlight Archive is a series I can get behind and invest in its characters and enjoy. Oathbringer is just a part of it, but a good part. Bring on the fourth shard of the story, Brandon! I need to unite them all!

Well, it ended a while ago, but I've just now got around to watching the last episodes from the sixth and last season of The Americans. It was a very interesting concept, following around two Russian spies that pretend to be a normal two kid and a picket fence couple while doing missions for the KGB on American soil. Luckily, it was set during the height of the Cold War, not now, so none of that fake news Twitter bull.

It was well played, too: Mathew Rhys and Noah Emmerich are both great as the Russian male agent and the unknowing FBI agent who moves right next door on one of faith's whims. However, it was Keri Russell who shone throughout the sometimes uneven run of the show. I mean, people knew her from Felicity, where she was a cute cheerful university student, but in this show she is seductive when she needs to get someone's trust, ruthless and unstoppable when she needs someone dead, unwaveringly loyal to her home country and hard as a rock underneath her ever changing appearance and disguises.

You can't run a show for six seasons and not evolve your characters (well, a lot of shitty shows do that), but The Americans excels in making the main characters have to face not only the consequences of their missions, but also the consequences of normal people living their lives. If Nadiejda the spy grows throughout the show, so must Elizabeth the wife and mother. I especially admired the twists and turns of Philip's moral qualms and how he wanted to reconcile his different personas while Elizabeth chose splintering apart as her way to cope.

Now, not all is well with this show. There were seasons when nothing interesting was actually happening. Henry's character never evolved away from a stupid kid that asks no questions and is missing from the series for entire seasons, while his sister not only was figuring it out, but was also recruited as a "second generation" agent. Admittedly, Holly Taylor was annoying as hell in that role, but she didn't write her character's script. I also suspect that people got turned away from the show by the brilliant portrayal of a loyal Russian agent by Keri Russell. She was too hard, too Russian, too human for comfort. I can only admire both her and the show developers for going all the way in with her character.

All in all, I have mostly good things to say about the show and if you have not watched it, I highly recommend it. It seems to me that this show has enough followers to warrant a full feature film production in which the actors could shine in a one-off mission spy movie. I am also curious on what Keri Russell will do other than a rumored Star Wars appearance that I believe is a poor choice for someone who shone so brightly in a real role.

About the ending... it actually ends. It's not one of those shows that get cancelled without any preparation, leaving everything in limbo. However it is also one of those endings that is generic enough for them to have planned it seasons ago. We see some of the consequences spell out, but there is not enough time to really understand where it all leads to. It was nice to see the reactions of the characters to the sudden end, but it was certainly not enough to make a statement about the real outcome of their actions.

Brandon Sanderson wrote two short books about the Legion character, which is different from the Legion character from the Marvel comics and TV series. It is basically about a guy who hallucinates other people around him, specialists that help him solve "cases". People are not sure in what box to put him. Is he schizophrenic, is he multiple personality disorder, something else? It doesn't really matter, since he is functional and (with the help of his imagined personalities) brilliant.

Yet, while the character can be compelling, the stories are rather boring. The joking punny positivism of Sanderson's characters is barely there, while the setup is that of classic detective stories. There is no fantasy like in Cosmere, nor are there interesting ideas that blow your mind. Just short average books about a quirky detective. It can't get less original than that, I believe.

Bottom line: without some serious redesign of the concept, I doubt Legion is a character that warrants further exploration.