I started to read the book in French, so as to remember the language from my high school years, but then got lazy and after a chapter read it in my native Romanian. The literal translation would be In the Forests of Siberia, but for some reason it was translated as The Consolations of the Forest in English. Either title is misleading, as the forests are not really relevant to the story and the whole thing is a personal journal of a French misanthrope who decided to spend six months alone on the shores of lake Baikal.
I am unfamiliar with the work of Sylvain Tesson, he is a journalist and a traveler and I couldn't compare this with other things he wrote, but judging by Goodreads' description of him, this must be his most famous book. Did I like it? I didn't dislike it. In itself is a daily journal and has very little literary value other than the metaphors Tesson uses to express his feelings. Some land true, some simply don't work. There are no detailed descriptions of the landscape either. The author does not paint with his words, he mostly whines. If there are people around, he will insult their nation and their presence in his thoughts, while being civil and hospitable to them; if there are no people around, he will complain about the nature of society, humanity, religion or state. Left alone for a while, though, he will start to be more positive, inspired by nature, but also by the books he devours and then annoyingly feels compelled to quote from.
Some of his emotions ring true, it makes the read compelling and generates thoughts of how the reader would feel or act in the author's stead. Some descriptions sound exactly like what most people, alone in the (proximity of the) woods would produce if their only company were liters of vodka. What I am trying to say is that the book is a journal written by an egotist, therefore describing only him. The beautiful lake, the woods, people, dogs, the wild bears or anything else are just props so we can all bask in his personality... which is pretty shitty. Just as a small example: in four months of journal he mentions his need of random women coming into his hut twice. He mentions he has a girlfriend once. After getting dumped via SMS he whines continuously about how he lost the love of his life which now has no meaning and only his two dogs (received as pups when he got there) helped him through it. After the six months pass, he just leaves the dogs there, proclaiming his love for them.
So, an informative book about how a random French writer asshole felt while living alone in the cold Russian wilderness, but little else. Apparently there is a 2016 movie made after the book. You might want to try that.
I've always had the nagging feeling that someone who writes well could do wonders with the Lovecraft "mythos". A lot have tried and most have failed miserably, because Lovecraft was weird and his horror feelings came from being really intolerant of almost anything, but I am still trying to read things inspired by the man in hope I would find something very good.
Unfortunately, Shoggoths in Bloom is one of the shortest stories in this collection of short stories by Elizabeth Bear, is only loosely based on Lovecraft's ideas and is not horror. In fact, none of the stories in the book were horror and some weren't even fantastical, but verged on personal or perhaps historical fantasy. The quality was inconsistent, with some shorts being nice and others a nightmare to finish. Funny thing is one of the stories I liked, Tideline, I had listened to before on the Escape Pod web site.
Bottom line, Bear seems to be an accomplished writer and her writing is good, but I wouldn't recommend this collection, from the standpoint of quality, but also because it uses a Lovecraft concept to sell something completely different.
Sonar Source code static analysis rule RSPEC-3906 states: Delegate event handlers (i.e. delegates used as type of an event) should have a very specific signature:
Return type void.
First argument of type System.Object and named 'sender'.
Second argument of type System.EventArgs (or any derived type) and is named 'e'.
The problem was that I was getting the warning on a simple event declared as EventHandler<TEventArgs>. Going to its source code page revealed the reason in a comment: // Removed TEventArgs constraint post-.NET 4.
In 2015 I was so happy to hear that Cory and Lori Cole, game designers for the Sierra Entertainment company, were doing games again, using Kickstarter to fund their work. Particularly I was happy that they were doing something very similar to Quest for Glory, which was one of my very favorite game series ever. Well, the game was finally released in the summer of 2018 and I just had to play it. Short conclusion: I had a lot of fun, but not everything was perfect.
The game is an adventure role playing game called Hero-U: Rogue to Redemption and it's about a small time thief who meets a mysterious bearded figure right after he successfully breaks into a house and steals, as per contract, a "lucky coin". The man gives him the opportunity to stop thieving and instead enroll into Hero University as a Rogue, rogues being a kind of politically correct thieves, taking from the rich and giving to the poor and all that. You spend the next 40-50 hours playing this kid in the strange university and finally getting to be a hero.
You have to understand that I was playing the Quest for Glory games, set in the same universe as Hero-U, when I was a kid. My love for the series does not reflect only the quality of the games, the humor, the nights without Internet where I had to figure out by myself how to solve a puzzle so that I could brag to my friends who were doing the same at the time, but the entire experience of discovery and wonder that was childhood. My memories of the Sierra games are no doubt a lot better than the games themselves and any attempt of doing something similar was doomed to harsh criticism. So, did the Coles destroy my childhood?
Nope. Hero U was full of puns and entertainment and rekindled the emotions I had playing QfG. I recommend it! But it won't get away from criticism, so here it is.
Update: I've finished the game again, going for the "epic" achievement called Perfect Prowler, which requires you don't kill anything. I recommend this as the start game because, if you think about it a bit, it's the easier way to finish the game. To not kill anything you need to sneak past enemies, meaning maxing your stealth. To defeat your enemies (which is also NOT the rogue way as taught at the university) you need to have all sorts of defenses, combat skills, magical weapons or runes, etc. By focusing on stealth you actually focus on the story, even if sometimes it is annoying to try to get past flying skulls for ten minutes, saving and reloading repeatedly, until your stealth is high enough. Some hints for people doing this:
Sleeping powder is your friend, as it instantly makes an enemy unresponsive and does not alert other enemies that are standing right next to them
Sleeping powder works on zombies, for some reason
Demolishing a wall with a Big Boom while guards are sleeping next to it does not hurt said guards, even better, they magically disappear letting you plunder the entire room
If someone else kills your enemy, you didn't kill anything :)
The achievement says you have to not kill things, you can attack them at your leisure as long as you flee or use some other methods to escape
Anyway, the second run made me even more respectful towards the creators of the game, as they thought of so many contingencies to allow you to not get stuck whatever style of play you have. And this on a game that had so many production issues. Congratulations, Transolar!
And now for the original analysis:
What is great about the game is that it makes you want to achieve as much as possible in a rather subtle way. It doesn't show you X points out of Y the way old Sierra games did, but it always hints of the possibility of doing more if you only "apply yourself". Yes, it feels very much like a school. And I liked it. What's wrong with me?
I liked the design of the game, although I wish there was a way to just open a door you often go through, rather than click on the door and then choose Open from the list of possible and useless options like Listen on the door or Look at the door. I liked that you had a lot of actions for the objects in the game, which made it costly to just explore every possible option, but also satisfying to find one that works in your favor.
And the game is big! A lot of decisions, a lot of characters and areas to explore, a lot of quests and a lot of puns. Although, in truth, even if I loved the QfG series for their puns, in Hero-U it feels like they tried a little bit too much. In fact, I will write a lot about what I didn't like, but those are general things that are easy to point out. The beautiful part is in the small details that are much harder to describe (and not spoil).
The biggest issue I had with the game was the time limits. The story takes the hero through a semester of 50 days at the university and he has to do as much as possible in that time. This was good. It makes for a challenge, it forces you to manage the time you have to choose one or the other of several options. You can't just train fighting skills for weeks and then start killing critters. However, each day has several other time limits, mainly breakfast/class, supper and sleep. You may be in the depths of the most difficult dungeon, took you hours to get there, if it's supper time, your "hero" will instantly find his way back so he can grab some grub. You don't have the option to skip meals or a night's sleep, which would have been great as an experience and very little effort in development, as he already has "tired", "hungry", "injured" and other states that influence his skills.
This takes me to the general issue of linearity of story. The best QfG games were wonderful because you had so many options of what you could do: you could explore, do optional side quests that had little or nothing to do with the main story, solve puzzles in a multitude of ways (since in those games you got to choose your class). Hero-U feels very linear to me: a lot of timed quests with areas that only open up after specific events that have nothing to do with you, the items you get at the store change to reflect the point in time you are in, a choice of girls and boys to flirt with, but really only one will easily respond to your attempts at romance, the only possible ending with variations so small as to make them irrelevant and so on. And many a time it is terribly frustrating to easily find a hidden door or secret passage, but be unable to do anything with it until "it's time". You carry these big bombs with you, but when you get to a blocked door you can't just demolish it. I already mentioned the many options you have to interact with random objects in the game, but the vast majority of them are useless and inconsistent. QfG had some of these issues, too, though.
An interesting concept are the elective classes, which are so easy to miss it's ridiculous. Do not miss the chance (as I did) to do science, magic or healing. It reminds me of QfG games you played as a fighter and then started them again as a mage or thief. The point is to take all your tests (and since you get the results a few days later) you need to know your stuff (i.e. read the text of the lectures and understand what the teachers are saying). Unfortunately, the classes don't do much to actually help you. Science gives you a lot of traps and explosives, healing gives you a lot of potions and pills and magic gives you sense magic and some runes. You can easily finish the game without any of them and it is always annoying to have to run from the end of your classes (at 14:00) and reach the elective classroom on another floor, having to dodge Terk and also considering that you might want to do work in the lock room, practice room, library, recreation room and reception, all in one hour (you have to get to the class by 15:00). And the elective eats two hours of your time, just in time for (the mandatory) dinner.
And then there is the plot itself. I had a hard time getting immersed in a story where young people learn at a university teachers know is infested with dangerous creatures that students fight, but do nothing to either stop or optimize the process. Instead, everybody knows about the secret passages, the areas, but pretend they do not. Students never party up to do a quest together. There are other classes in the university, not only Rogues learn there, but you never meet them. Each particular rogue student has a very personal reason to be in the university, which makes me feel it's amazing that the class has seven students; in other years there must have been a maximum of two. You get free food from all over the world, but you have to buy your own school supplies. There are two antagonists that really have absolutely no power over you, no back story, and you couldn't care less that they exist. Few of the characters in the game are sympathetic or even have believable motivations.
Bottom line: I remembered what it was like when I was a child playing these games and enjoyed a few days of great fun. I felt like the story could have had more work done so that we care about the characters more and have more ways to play the game. The limits often felt very artificial and interrupted me from being immersed in the fantastic world. It felt like a Quest for Glory game, but not the best ones.
It is worth remembering that this game is the first since the 1990s when the creators were working in Sierra Games. They overcame a lot of new hurdles and learned a lot to make Hero-U. The next installments or other games will surely go more smoothly both in terms of story and playability. I have a lot of trust in them.
Time is very important. It pays to save, explore an area, reload and go directly where you need to go.
Stealth is useful. There is an epic achievement to finish the game without killing anything. That feels a bit extreme, but it also shows that items and combat skills may be less relevant than expected.
Exams are important: save and pass the exams so you can get elective classes. I felt like every part of the story was excessively linear except elective classes which you can even miss completely because you get no help with them from the teachers or the game mechanism.
Some doors towards the end cannot be opened and are reserved for future installments of the series.
You can lose a lot of time in the catacombs for no good reason. Don't be ashamed to create and use a map of the rooms.
This is another post discussing a static analysis rule that made me learn something new. SonarSource Rule 3898 says: If you're using a struct, it is likely because you're interested in performance. But by failing to implement IEquatable<T> you're loosing performance when comparisons are made because without IEquatable<T>, boxing and reflection are used to make comparisons.
There is a StackOverflow entry that discusses just that and the answer to this particular problem is not actually the accepted one. In pure StackOverflow fashion I will quote the relevant bit of the answer, just in case the site will go offline in the future: I'm amazed that the most important reason is not mentioned here. IEquatable<> was introduced mainly for structs for two reasons:
For value types (read structs) the non-generic Equals(object) requires boxing. IEquatable<> lets a structure implement a strongly typed Equals method so that no boxing is required.
For structs, the default implementation of Object.Equals(Object) (which is the overridden version in System.ValueType) performs a value equality check by using reflection to compare the values of every field in the type. When an implementer overrides the virtual Equals method in a struct, the purpose is to provide a more efficient means of performing the value equality check and optionally to base the comparison on some subset of the struct's field or properties.
I thought this was worth mentioning, for those performance critical struct equality scenarios.
Skyward is Brandon Sanderson at his best... and worse. Yes, his best characters have always been young rebellious loud mouths with a penchant for over the top lines and punny jokes. And yes, this is a young adult novel with a classically clichéd plot. I feel guilty for liking it so much, but hey, it apparently works! Personally I feel it's a shame Sanderson spends a year writing a book and I finish it in two days, but at least he's not George R. R. Martin!
The whole idea revolves around this society of humans, driven underground by an alien force. They live on a planet surrounded by a sphere of debris few can get through and attacked periodically by alien fighter planes and bombers that the humans must repel in order to survive. And here is this heroic little girl who dreams of becoming a pilot fighter despite her father being universally despised for being a coward and leaving the field of battle. Determined to clear her and her father's name, she enrolls in a school for cadet fighters and discovers she has what it takes to protect her friends and save humankind.
Sounds familiar? It should, every story lately seems to be about the same character. Is it an interesting and engaging character? Yes. Is the world weird and familiar enough to be enjoyed? Yes. If this is all you need, you will love the book. And of course, it's the first book in a series. I need a little more, though, and I feel that the twists were terribly predictable and there were holes everywhere in the world building. If you only focus on the characters, as the author did, you enjoy the book. But as soon as you try to imagine yourself there, things start to make little sense and whatever you would do, it would not be what the characters in the book do. Plus... that fighter! Deus Ex Machina much?
Bottom line: lovely book to read in a few days and feel you are a reader, but the story is as standard as they come and the only nice thing about it is that Sanderson wrote it.
Visual Studio has a very interesting feature called Rule Sets. You basically create a file where you declare which warnings from analyzers will be ignored, displayed as info, warning or error. With the built in code analysis, but also with the help of a plethora of extensions and NuGet packages, this can be a very powerful tool. I am using VS2017 Professional for this post.
Create a rule set
Let's start with creating a new project (a .NET Framework console app) called Rulesets, which will create the standard Program.cs file and a solution for the project. Next, right click the solution in Solution Explorer and go to Add → New Item, go to the General category and select Code Analysis Rule Set. Name it whatever you want to name it, I will call it default.ruleset, then save it.
At this point you should be in a rule set editor, showing you a list of rules grouped by code analyzer id. Press F4 or go to the little wrench icon so that the Properties window is open, then give your ruleset a name (Default Rule Set) and save the file (ctrl-S).
You can create as many of these files and they will be saved in the Solution Items or as a file in a project (I recommend the former) and associate them to any number of projects. Let's assign the new rule set to our project: Go to the solution properties, select Common Properties → Code Analysis Settings, then select as many projects as you want in the list in the right. Then click on the little dropdown arrow an you should be prompted with a list of possible rules, including Default Rule Set. Select it.
Obviously, you can just choose a Microsoft included rule set instead, but those do not take into account your own extensions/packages.
Note: in order to start an incremental process, let's say starting with the minimum recommended settings from Microsoft and then adding stuff to it, use the Include element in a .ruleset file. The files coming by default with Visual Studio can be found at %ProgramFiles(x86)%/Microsoft Visual Studio/2017/Professional/Team Tools/Static Analysis Tools/Rule Sets. Example:
From the Visual Studio GUI you can click on the folder icon in the rule set editor top bar to include other sets and the wrench icon to open the settings.
This helps a lot with having small variations between your projects. For example a tests project might have different settings. Or the data access layer project might have auto generated files that don't respect your coding standards. You can just create a new ruleset that includes the default, then disables some of the rules, like mandatory class documentation.
Note that the rule set editor is not perfect. It will only show the rules as defined in the current file, ignoring the included sets. That is why if the default for a rule is None and you set it to Warning in your base set which you then include in another set where you set it back to None, it will not be saved correctly. Some manual checks are required to ensure correctness.
A list of analyzers
Now, I've noticed a list of possible extensions for Visual Studio that use this system. Here is a list of the ones I thought were good enough, free and useful. Visual Studio extensions:
Microsoft Code Analysis 2017 - Live code analysis rules and code fixes addressing API design, performance, security, and best practices for C# and Visual Basic.
Security Code Scan - Detects various security vulnerability patterns: SQL Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), XML eXternal Entity Injection (XXE), etc.
MetricsAnalyzer - analyzer extension to check if you code follow metrics rules
Moq.Analyzers - Visual Studio extension that helps to write unit tests using Moq mocking library by highlighting typical errors and suggesting quick fixes
Code Cracker for C# - analyzer library for C# that uses Roslyn to produce refactorings, code analysis, and other niceties
Visual Studio Intellicode - this is interesting in the sense that it uses AI to improve your code and intellisense
Roslynator 2017 - A collection of 500+ analyzers, refactorings and fixes for C#, powered by Roslyn.
SonarLint for Visual Studio 2017 - Roslyn based static code analysis: Find and instantly fix nasty bugs and code smells in C#, VB.Net, C, C++ and JS.
clean-code-net - Set of C# Roslyn analyzers to improve code correctness
CommentCop - Analyzes (mostly) xml comments and provides code fixes. Uses Roslyn C# code analyser.
NuGet packages:
StyleCop.Analyzers - there is also a StyleCop extension, but weirdly it does not use the Rule Set system and you just run it manually and gives you warnings that you can control only through the extension configuration
Asyncify-CSharp - an analyzer and codefix that allows you to quickly update your code to use the Task Asynchronous Programming model.
The packages above are NuGets you install in your project. Just check out the list from NuGet: NuGet packages containing Analyzer. Many extensions also have a NuGet counterpart. It's your choice if you want to not bloat your Visual Studio and choose to install analyzers on a per project basis. There is one advantage more in using project packages: the analysis will pop up at build time and you can thus enforce not being able to compile without following the rules in the set.
Curating your rule sets
So you've learned how to choose a rule set for your projects, how to create your own, but what do you use them for? My suggestion is to work on a complete rule set (or sets) for your entire company and then you can just enforce a coding style without having to manually code review everything.
If you are like me, then you probably installed everything in that list above and then tried it on your project... and you got tens of thousands of warnings and errors. How do you curate a rule set without having to go through every single message? I see several ways of doing this.
The perfect project
Some people/companies have a flagship technical project that they are very proud of. It uses all the latest technologies, it is perfectly written, thoroughly code reviewed by all the members of the team. It can do no wrong. If you have such a project, just enable all possible rules, then disable all that make suggestions for change. In the end you will have a rule set enforcing your coding style, for better or worse.
Start from scratch
The other solution is to start with a new project, then review every message until you get none. Then start coding. An iterative process, for sure, one you will never finish, but it will be good enough after a while and it will also engage your team in technical discussions on how to improve their code, which can't possibly hurt.
Add analyzers one by one
Start with a rule set where all rules are disabled, then start reviewing them one by one, as you either chose to disable them or refactor your code. This solution may be the worse, because it gives excuses to just stop the process midway, but it might be the only one available. Anyway, try to install extensions and packages one by one, too.
Start from the coding standards
Perhaps you have a document describing the coding standards in your team. You might start from it, then look for the rules that enforce it. I think that this will only make you see how woefully inadequate your coding standards are, but it might work.
Other notes
I've had the situation where I created derived rulesets from the default one (using Include) and somehow they ended up with an absolute path for the default ruleset file. It might be an issue with how the editor saves the file.
By default, rules in the ruleset editor are grouped by analyzer ID, but multiple analyzers might manage the same rules, so always manage rules individually, else you will see that enabling or disabling an entire group will change other groups as well and you won't know where you started from.
The ruleset editor is not perfect. One very annoying issue is with ruleset inheritance (doesn't load the parent rules). One example is that you want to have a general ruleset that does NOT include an analyzer (let's say the XUnit one) and then you want something inheriting the base ruleset to DO include the XUnit analyzer. While you can do it by hand, the ruleset editor will not allow you to make these changes, as the original ruleset will have every XUnit rule disabled, but the editor for the unit test one will not know this. There are two solutions for this:
Have a very inclusive basic rule set, then remove rules from the others. This is not perfect, as there could be circular needs (one set has one rule and not the other, while the other has them the other way around)
Have a lot of basic rule sets, split on topic. Then manage every rule set that you need as just includes. This works in every situation, but requires you edit the used rulesets by hand. In the case above you could have a special DoNotUseXunitAnalyzers.ruleset, for example.
A third solution that I do not recommend is to never include anything, instead just copy paste the content of the basic ruleset in every inheriting one. While this works and allows the editor and whatever engine behind to work well, it would be a nightmare to maintain.
Conclusion
I've discussed how to define and control static code analysis in your Visual Studio projects. If nothing of what is available is up to your standards, Roslyn now allows making your own code analyzers in a very simple way. Using code analyzers (and refactorings) can improve productivity, engage the team in technical analysis of standards, enforce some coding standards and help you find hard to detect errors in your code.
I am a .NET programmer living and working in Bucharest, Romania.
Posts are divided into programming and misc.
Check out the icons above on how to contact or chat with me.
Unless otherwise specified, all code or any type of work you find on this blog is under MIT license. While I welcome attribution, I don't require it. Just use anything in any way you see fit. Consider it completely and utterly shared for the lulz.