Annihilation, by Jeff Vandermeer, is a very short book that seems to be inspired by the Strugatsky brothers' Roadside Picnic. The same timeless quality, thoughtful introspective characters and a weird area that seems to defy the laws of physics and biology. But nothing is truly revealed, or learned, other than the somewhat senseless thoughts that the main character has. The other three women quickly succumb to the influence of "Area X", so we are left with a weird chick moving around in an unexplainable place with unfathomable rules. If Dallas' Pamela would have woken up from a dream at the end of the book, it would have meant just about the same as the actual ending.

I only read the book because of the upcoming movie. I am fairly certain that it will be better than the book, which manages to bore in half the pages of a decent story. It isn't that I disliked it, it's that I did not actually like anything in it. Everybody is acting crazy and without context and in the few pages that bring some context, it's the boring relationship between the lead and her husband and I couldn't care about any of them.

I am sorry, but when you write a book about a scientific expedition, it's customary you write about characters that behave like scientists, not like directionless drunkards with self-traumatic histories. I don't understand how this book won any science fiction award. It is well written, but it's barely average. I am not going to read any of the other books in the trilogy.

Update for .NET Core 3.0:

Seems for .NET Core 3.0 the solution is much simpler:

• install the Microsoft.AspNetCore.Authentication.Negotiate NuGet package
• add authentication in ConfigureServices like this:

  services
      .AddAuthentication(NegotiateDefaults.AuthenticationScheme)
      .AddNegotiate();

• use the authentication in Configure (above app.UseAuthorization();)

  app.UseAuthentication();

No need to UseIISIntegration, UseHttpSys or anything.

Original post:

If you get the System.InvalidOperationException "No authenticationScheme was specified, and there was no DefaultChallengeScheme found." it means that ... err... you don't have a default authentication scheme. Solution:

• Install NuGet package Microsoft.AspNetCore.Authentication in your project
• add

  services.AddAuthentication(Microsoft.AspNetCore.Server.IISIntegration.IISDefaults.AuthenticationScheme);

  to the ConfigureServices method.

Update: Note that this is for IIS integration. If you want to use self hosted or Kestrel in debug, you should use HttpSysDefaults.AuthenticationScheme. Funny though, it's the same string value for both constants: "Windows".

Oh, and if you enter the credentials badly when prompted and you can't reenter them, try to restart Chrome (as in this answer)

I was working on this web ASP.Net Core 2.0 project that was spewing a lot of "Application Insights Telemetry (unconfigured): ..." messages in the Debug Output window. At first I thought I should just remove the Microsoft Application Insights NuGet package, but it didn't work. By default, it will still use insights even if you don't have it referenced anywhere in your code.

The solution is to do have installed Microsoft Application Insights NuGet package, but then set

Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.DisableTelemetry = true;

somewhere in Startup.cs (the constructor is fine).

Apparently, in the preview versions of Visual Studio 2017 there is an option under Options → Projects and Solutions → Web Projects → Disable local Application Insights for Asp.net Core web projects, too.

Update: A comment suggested you need to Disable the automatic loading of hosting startup assemblies which can be done in two ways:

1. setting ASPNETCORE_preventHostingStartup to True or 1 in the project properties → Debug → Environment variables
2. Doing something like

   WebHost.CreateDefaultBuilder(args)
       .UseSetting(WebHostDefaults.PreventHostingStartupKey, "true")
       ...

   - available from .NET Core 2.0

Either of these works, and although I agree with Andrei that the underlying issue for the unwanted telemetry is the automatic loading of hosting assemblies, I feel like the first option, the one that actually contains the word Telemetry in it is better for reasons of readability. But it's good there are three options to choose from.

The Atrocity Archives tells the story of a technical computer geek enrolled by force in the British governmental organization that keeps us safe from supernatural threats. By Charles Stross' own admision, as a mix of Len Deighton and H.P.Lovecraft by way of Neil Stephenson (with a bit of Le Carré and Flemming thrown in for good measure), the book seeks to bridge the emotional catharsis of facing one's fears (the realm of the horror) with the desire to reveal the truth of the thriller. Bundled with it, the short story The Concrete Jungle, continues the saga of our protagonist.

I liked the book. A master of technobabble and fast paced intelligent action, Stross first came to my attention with the wonderful Accelerando, which I will never stop recommending. In the Laundry Files series, he tackles with equal humor horrors that could suck the universe dry of energy and life and things like bureaucracy (less efficient versions of the same thing) in government agencies. The pace is alert, the writing good and easy to read, the characters sympathetic if a little too shallow, funny, punny and, once I got into it, this book was almost impossible to put down.

I don't know if I will continue with the rest of the series, but as science fantasy goes, The Atrocity Archives is a pretty good book.

This is actually a TypeScript module resolution thing. The shape of the import name tells TypeScript what kind it is. The relative path imports always need a directory specified, so './myModule' and not 'myModule'. That's because myModule could be the name of an already declared ambient module.

Well, it's more to it, but the takeaway is that you have an import like import {something} from 'folder/something' and you want a similar import with a file from the same folder, you don't just delete folder/, you replace it with a dot, like this: import {somethingElse} from './something-else'

I used to put all my work in a folder called !Projects, for the simple reason that it would make it the first folder to appear in the file explorer. Due to a limitation in WebPack, Angular cannot work with paths containing the exclamation mark character.

Written as a 19th century explorer's memories, this book subtly achieves several things, effectively and decently. First of all, it is a sort of fantasy, although really if one removes the dragons, it's pretty much normal history. Second of all, it is a feminist story, but one done well. Instead of describing the horrible things done to women by evil cardboard characters, we get an intelligent and driven female hero that makes the most of her advantaged situation to expand her goals and enrich her life, despite social norms, but supported by friends and loving family. She is young, attractive, but not extraordinarily so, and her fascination towards dragons and science books leads her towards a career normally reserved for men. She is inspiring as a model, rather than complaining about her helplessness. She gets by through her efforts and skill, not by magically being gifted super powers. The fact that the action is set in a reasonably old period so that folk don't get touchy about it, but close enough so that it describes people that thought themselves the pinnacle of civilization helps with making the reading comfortably remote, but seriously instructive. Thirdly, it is written in an easy to read way, a personal memoir that can be understood by adults and children alike.

As such, I think A Natural History of Dragons is one of the few books that can claim to have made the world a better place, as it provides both escapist pleasure and educational value. That doesn't mean it's a perfect book. Marie Brennan's educated Victorian noblewoman style starts off as refreshing, but quickly gets old, the details providing less and less context and just filling up space. The book is well written, but at times I just wanted to get past the way people were dressed or how the architecture influenced the mood of the main character. The title is misleading at best, as the story is marginally related to dragons and instead focusing on one person and her incidental fascination with them. You learn almost nothing "scientific" about dragons but you sympathize while you observe this young woman desperately trying herself to understand more.

In conclusion, this is a book that I would gladly give to a hypothetical young daughter to read. As an adult, it is light enough to be enjoyable. The world is built thoroughly and perhaps the next books will be more action packed, while expanding on our view of it. The story is a bit lackluster, but nothing to complain about. It reads as a light fantastical autobiography. A more alert pace would have made it more accessible, but it would have probably detracted from the character's voice.

I really tried to read and enjoy this book, which is highly rated and reviewed, which makes me wonder whether there is something wrong with me. Whatever the reason, I couldn't even finish it. Everything in this book is grating my senses, from the writing style to the scenes details, from the editing to the basic story outline. If you've read Dexter (the book the TV show is based on, not the TV show itself) you will have found a similar plot, but as I thought that book was bad, this one felt worse. I can't imagine who in their right mind would give this a full rating.

I've found a blog post by the author, Matt Hilton, that describes the unfortunate period in which he wrote the book. His seventeen old daughter just died. Maybe that affected the writing style, maybe the fact that it was written in several versions that then were edited into this one. I don't know. He has my sympathy for his loss, but not for PreterNatural. In his situation I would have expected to at least get the grief part right. Instead the character lives with the mind of his family's murderer in his head and has humorous dialogues with it.

It's a bad book. I won't recommend it in any way. Considering this is the first and only book in the Carter Bailey series, I think even the author probably agrees with me.

New Scientist is a science oriented news site that has existed in my periodic reading list for years. They had great content, seemingly unbiased and a good web site structure. But they went greedy. Instead of one in ten articles being "premium" now almost all articles I want to read are behind a pay wall. While I appreciate their content, I will never pay for it, especially when similar (and recently, event better) content can be found on phys.org or arstechnica.com completely free. So, I feel sad, but I need to remove New Scientist from my reading list. I understand there is an effort in what they do and that quality requires investment and cost, but brutally switching from an almost free format to a spammy pay wall is unacceptable for me.

The quote So what's the moral of this story? - Moral? Our stories don't have those! perfectly describes the narrative of LaRose. The book is well written, there are a lot of very well described characters that go through their own arcs that intersect often and in uncommon ways, but you are just left with knowing a bunch of people better than before you began reading the book.

Louise Erdrich describes an intertwining world of traditions, history, real life, strong emotions, cool heads and above all, the feeling that it all somehow makes sense (without it actually reaching that point). It could have easily been completed at the middle of the book or continued for a few more volumes, it lacks finality, with the last chapter feeling forced in the way that it tried to complete some concepts. I can imagine Woody Allen saying "It involves Native Americans" after reading it for twenty minutes.

Given what I've said above, it's difficult for me to rate such a book. I enjoyed reading the words, but did not enjoy the book. I ground the words into submission with the whole intention of finishing the story and then reading something else. I loved the characters, even if the myriad of details about them did not interest me in the least. I learned about a people that is, as the book itself recognizes, rapidly going extinct. Is this a good book? Yes! Would I have read it if I knew what I know now? Probably, because I am vain like that. Should I have read it? Probably not.

Bottom line: I will rate it above average, because it most obviously is, but that's about the only reason.

I have invented a new way to write software when people who hold decision power are not available. It's called Flag Assisted Programming and it goes like this: whenever you have a question on how to proceed with your development, instead of bothering decision makers, add a flag to the configuration that determines which way to go. Then estimate for all the possible answers to your question and implement them all. This way, management not only has more time to do real work, but also the ability to go back and forth on their decisions as they see fit. Bonus points, FAPing allows middle management to say you have A/B testing at least partially implemented, and that you work in a very agile environment.

A year and a half ago, as I was going from miserable job interview to the next, I was asked what I think about code review. At the time I said that I thought it was the most important organizational aspect of writing code. I mean you can do agile, waterfall, work on games or mobile apps or business applications, use the latest or the oldest, the best or the worst technology and still code reviewing helps. I still think that way now, but recent experiences with the process have left me thinking of refining my understanding of it. This blog post is about that.

The Good

Why is code review good? The very first thing it does is that it forces you to acknowledge your work. You can be tired and fix one little thing in a lazy way and forget about it and it might work or it might break something, but when you know you have to publish what you did you do things less lazy, more documented, more thought out. It doesn't matter that no one will ever look carefully on the review, as that you are thinking there is the possibility of it.

Second, and obvious, is that any mistakes you made are more likely to come to the surface when someone looks at the code. It doesn't mean people blame you for mistakes, it means the mistakes don't come and bite you in the ass later, when your work is supposed to be making money for some poor bastard somewhere. This is very important because we tend to work on systems more complex that we can or are willing to understand. If a group of people who together understand the system is reviewing work, though, you learn not only about the inevitable code errors you introduce, but also about the errors in judgement or understanding or in the assumptions you made.

Then there is the learning aspect of it. Juniors learn from seniors reviewing their work, they learn from code reviewing each other and everybody learns from reviewing work made by anyone else. It opens up perspectives. I mean, you can review some method that was copy pasted four times in order to do the same thing to four different objects and learn how not to that, ever! No matter how much you would want to when coming in at work hungover and hoping for death a little. For example, I've only recently learned to comment on my own code review before submitting it. Some might say comments in the code should do that, but sometimes you need more, as anchors for discussion, which obviously cannot be carried in code comments. (well, they can, but please don't do that)

And there is more! You get documentation of the code for free. When someone doesn't understand what the hell is going on, they ask questions, which leads to you answering in whatever code review software you use. This will remain there for others to peruse long after you've left the company and went on to slightly RGB shifted pastures. I still dream of a non intrusive system that would connect reviews to the code in your IDE, so you can always see a list of comments and annotations for whatever you are looking at.

One of the benefits is that code review makes everyone in the team write code in the same way. For better or worse. I will detail that in a moment, but think about what it means to read a piece of code, trying to understand it, then switch to the next one and see it written in a completely different style. You waste a lot of time.

Finally, I think the confidence code review gives you can lead not only to better code, but also faster code. More on this comes next. This is controversial, but I think you can use code review to check your code, but only if you trust the reviewers. You might fire off commit after commit after commit, confident that your peers will check what you, normally, would have to double and triple check before committing. It's risky, but with the right team it can do wonders.

The Bad

OK, so it's a great thing, this code review stuff. I knew that, you knew that, why are you wasting your finger strength? Well, there is a dark side to code review. I've heard some purists insist on some rules for code review with which I am not completely comfortable with, for example. I invite said purists who also read my blog to come rant in the comments below. Also my recent experience which touches on said rules and introduces others. Let me detail the bad.

There are programmers and programmers, projects and projects, management and management. Where one developer writes some code and hopes people will look at it carefully and instruct them on what they could improve, some people just lazily write something that kind of works, thinking whoever will do the code review will also do the work of making their code remotely usable. Where in some projects developers remain working after hours because they want to see their code do good and the project succeed, in others people couldn't care less: they do their time and break the door when the bell rings. Don't expect careful code reviews then. And there is the management issue, which might protect the developers from anything unrelated to coding or they might pester them with meetings and emails and processes that break concentration, waste time and surely do not help with the attention span of a code reviewer. But in all of the worst cases above, code review is still good, just less effective.

One of the rules I was talking about above was to never commit code unless its code review was accepted. Note the bold font on the never. It was like that whenever I heard the rule. Sounded bold. But I completely disagree with that.

First, if you have developers that you can't trust to commit something, don't let them commit. Either find someone better or do something with their privileges, a system that prevents them from committing. Same goes for people you can't trust to read the code review and update the code afterward a bad or defective commit.

Second of all, you might work on a file that should appear in more code reviews. No, the system where you do the work, ask for review, then shelve the files so you can work on the next thing doesn't work! It takes time, concentration and leads to bad resolves that break your code. Just commit the first thing and move to the next. When your review comes back full of bugs, just finish what you are working on, commit that, then return to the code and implement fixes for the issues found. That is a problem for code review software that can't understand a file committed after changes were made to it doesn't mean you want to include all the changes since time immemorial. That's a software issue, though. Just create a new review and somehow link it to the other, via comments or notes. Creating a personal branch for all developers or other crazy ideas like that are also crap.

Not committing work that you've done means delaying your other work, testing, finding problems in it, etc. Having to juggle with software in order to submit to a rigid process that is indifferent to the overall pace of development and the realities of your work is stupid. Just work, commit, review, test, rework. It's what we do.

It's also, I think, an error in judgement to force code review. As good as I think it is, you can work without it. It is an optional process, so keep it that way. Conditioning development on an optional process makes it mandatory. It might sound like a truism, but people don't seem to realize things unless you articulate them.

And then there is human nature. If you ask me to code review for you, I will stop what I am doing and perform the review, because if I don't, you can't commit. It hurts my work, because it breaks my concentration. It hurts your code review, because I am not focused enough. Personally I am best at reviewing in the morning. None of the organizational crap happened yet, no meetings, no emails telling me to write other emails, no chat messages asking questions that I have no desire to answer. I am rested, I am a bit pumped from making the minimum physical movements required to get me to the office and so I am ready to singlemindedly focus on your review. It shouldn't matter that you committed the code yesterday. I'll get to it when I get to it.

The Ugly

The ugly is not only bad, but also disturbing. It's not a characteristic of the code review per se, but is more related to the humans involved in the process. Code review has some nasty side effects on certain people and in certain situations. Let's discuss this for a bit.

I was saying above that it's good everybody writes in a certain way. That actually may stop people from innovating in the writing of code. Do it this way, that's the pattern we're using, you will hear, without the slightest hint of the possibility to improve on that pattern. Same thing might happen with new ideas that you might feel need to be introduced in the project, or some refactoring, or some other creative work that would make you proud and motivated to continue to do good work. As I said above, it's a people problem, not a process problem, but when it happens, it stifles innovation, creativity and ultimately the fucks you give on what happens to the project as a whole.

Code reviews, like any other communication medium, may be abused. People may be attacked or shamed by others who don't really like them. They might not even be junior and senior, as it might involve time in the firm rather than technical skill, or some other hierarchical or social advantage. Ego fights can also erupt in code reviews, which can exacerbate the problem if they are blocking reviews. Arguments are good, pissing contests are ugly, that kind of thing.

Reviews waste time. That's really not a people problem, it's a process problem. All processes, that is. You need to put in the work to do a good review. Just glancing over and saying "it looks good", without trying to understand what the code is supposed to do, is almost worse than refusing to do the review. I am plenty guilty of that. Instead of thinking about what the guy did and trying to help, part of my brain just keeps rummaging on what my current development task is. This is another argument to separate reviewing from code writing. You need your zone for both. When code review waste rather than spend time, that's ugly.

Finally, I think one major issues with code review is that it encourages lazing off on unit testing, proper testing, refactoring and even simple writing of the code. This is a management issue, mostly, and it's ugly like vomited shit. When people write horrid code filled with bugs assuming that code review will fix their lack of interest, that's ugly. When you are urged, more or less vigorously, to skimp on the unit or manual testing because the code review was accepted, that's ugly. But when you are trying to improve the general quality of the code and the answer is either that you don't have time for this or that any change is unnecessary because the code review passed or even when you are unwilling to do the refactoring, knowing what a hassle will be to send it through review, that's damn ugly. It means you want to do more than your share and you get stuck in a process.

And on that note, I end this wall of text. Process before people is always ugly.

Comments and opinions, if you dare! :)

I just read a very cool article (Understanding Default Parameters in Javascript) and my takeaway is this smart piece of code to enforce that a parameter is specified:

const isRequired = () => { throw new Error('param is required'); };

function filterEvil(array, evil = isRequired()) {
  return array.filter(item => item !== evil);   
}

So all you have to do is define the isRequired function in a shared library file and then use it in any function that you write.

Are you a bit put off by the fact you can use functions as default parameters? Welcome to Javascript, a language that seems designed by Eurythmics

What the hell have I tried to read? It felt like a Google bot trying to describe random YouTube videos, a meaningless brainstorm of a neural network trained on black and white images, an intentional insult to anyone attempting to make sense of the book. At a mere 260 pages (on my smart phone) I thought that no matter what the subject or writing style, I would finish it, but after 60 pages of understanding nothing and using all my will power to continue, I've decided to call it quits.

It "helped" that I had no idea what I was reading. I just picked a book at random from my library and started it. I didn't know Herta Müller was a Nobel laureate for literature, I didn't know she was part Romanian, nor did I know of the Romanian movie based on the book. I could just read and enjoy the content. Or not. I don't know how I can describe this book in a way that is comprehensible. I had to read the synopsis of the movie in order to understand what The Fox Was Ever the Hunter tried to say! I am Romanian, I've lived through communism, even if I was just a kid at the time, I should have no reason not to at least understand the basic plot of the book, but I didn't get it. Eyes just glossed over the pointless descriptions, unnamed characters identified by body characteristics or clothing, useless details and unrelated chapters. One chapter ended in "The comb's teeth were blue." It wasn't a particular comb, it didn't feature in any interesting way in the story (had it been one), it was just a piece of detail that should have conveyed the lack of interesting things in the gray communist era or something. The book is filled with stuff like that.

Bottom line: I didn't find any positive thing to say about this book. No sentence that made me feel something, no interesting fact, no eye opening writing style, no plot or character that made any sense or brought any pleasure as I was reading it. It was like being so thirsty that you try to drink desert sand. It works just as well as this book. I hate it with fervor.

Persepolis Rising went into an interesting direction. One that I don't particularly like, but interesting nonetheless. The seventh book in the Expanse series is happening about 30 years after the sixth. You have to remember that lifespan is slightly longer in the future, so that's not a show stopper or a revamp with new characters. It also featured yet another condescending asshole who wants to rule everything using the protomolecule.

Now, the thing I love about The Expanse is the locality in the Solar System, the exploration of the near future society of space that is mere decades away from now (assuming we discover the Epstein drive, hmm...) Moving the action on other planets in other systems, more into the future and messing with alien tech doesn't help that. Instead it is turning it into yet another Stargate or similar franchise, where they just up the ante until there is no more up and people are bored. The authors have dodged the same bullet a few times in the past, though, so it just may be that they are aware of this and careful to thread the fine line between hard sci-fi and the ability to relate to what is going on in the story.

There isn't much about the story that I can tell without spoiling it. Some dudes want to go Roman Empire on the 1300 solar systems available and "civilize" humanity. Holden and the crew of the Rocinante have different ideas. However, the book basically ends in a cliffhanger so if you hate that kind of stuff, I recommend you postpone reading it until the eighth book is published. I liked the writing, the pacing and again I read it in mere days. Is it a masterpiece, not really, but it reads well. Now I have to wait until I can get my hands on the next book to see where the story is going, but considering that plans are to end the series with the ninth book, I wonder if I shouldn't just wait until they are all written and spare myself the misery of ending up with another, larger, cliffhanger at the end of the next part of the story.

Conclusion: I liked it, but I would much rather have read another dozen books about the Belters and how they made their home in the asteroids. If you think about it, the last few books did away with even the pretense of space colonization realism and it is always a small pain seeing how the stories always favor planets, which are not only less rich with the type of materials needed in space, but also have a lot more limited space. Asteroids can support trillions of people, and that in this Solar System alone. But that's another rant altogether. Just make sure you calculate the exact energy and reaction mass you want to spend in reading and then waiting for the next part of the story, which may not be published yet.