Alberto on code life

This is a start of a series starting on some simple old fashion code and evolving such code to something more modern. I will not use buzzwords like microservices  or containers. This is beyond the scope of this article. What I will try to show is how to approach the past and future decisions step by step by way of refactoring and introducing new technologies.  TL;DR There is none, read it all Disclaimer The idea for this series is taken from a real life "war story". I am however not the least bit inclined to disclose the source. Nor does any part of the code reflect the full and actual system, the idea for the post has stemmed from. Parts 2-5 are here:  Part 2 ,   Part 3 , Part 4  and Part 5 Part 1 - Old School The code for the old school code is pretty straight forward and resides on the master brunch of this GitHub repository . Initial architecture The initial architecture of the system looks as such: Consider an application with two major threads; On

I have recently come across the concept of a code review board. At first it was an awkward moment; My change set was out there for all the world to see and comment. I admit I was stressed about it and with good reason. What I will do in this post is put the record straight, as far as I am concerned, on the good, the bad and the ugly of public/social code reviews. And since in the near future my code will be standing there naked for all to see on some public repository, this should make for a very good exercise on what to expect and what to reject when it comes to review boards. TL;DR Code reviews are good. Review boards meh... Past (nearly) perfect At some point during my searching for topics to write I recalled some articles I wrote back in the day on CodeProject . And I also do remember that, unless your article was pure garbage, review of the article and comments where polite, leveled and cool headed. Social media was not that proliferated and people did not openly enjoy putti

Someone asked me to write a post about how I approach new technologies. There isn't really one way to do that and what works for me may not work for someone else. Having said all that let's explore the different options standing before any developer who wants to explore a new technology. TL;DR Put time in your calendar and go for it. Τα πάντα ρει, μηδέποτε κατά τ' αυτό μένειν - Everything flows, nothing remains the same - Heraclitus We are living in a world where you see a new framework or a new language pop all the time. It was less than a year ago that Angular took the web by storm and went head to head with its predecessor AngularJS and React and then VueJS popped it's head to say Hi. Who would have thought Python would become the go to language for cyber security, or that Go would become the next hot thing. So let's stop beating around the bush and get to it. Go Online When I started to plow my way through technology all we had was BBS message boards and

Exciting news! We can now go back and forth in time without a Delorian with  WinDBG Preview for TTD! Hopefully a post with this will come soon! Update 25/10/2017 : Unfortunately Time Travel debugging works well only with C++ currently. Since there are quite a few blog posts on the subject of C++ I chose not to pursue the matter any further until a version for .NET comes out.

Always Test! There is no argument whatsoever that unit tests are essential to every software nowadays. Beyond their initial use they serve as regression tests during code changes. They are also used in build environments and CI/CD to ensure merges do not negatively affect your code. And sometimes they are considered as an alternative to QA on server side code. TL;DR "It depends" This is where I currently live, server side code, and unit tests are an essential part of every feature in every sprint.  I will not go into the textbook "what are unit tests" Q and A. I assume dear reader that you know it by heart. However in case you don't know this Wikipedia entry should get you started. Opinions on unit tests in OO languages In general unit tests are used to verify the correct behavior of a module, hence in C# only the public methods of a class should be tested. Some consider testing protected or private methods unacceptable. And then there is this quote fro

The Past It has been well over 6 years since I had my code reviewed by my peers. As a development team leader I had reviewed the code of my developers, however most of the time they didn't review mine. This was due to either them being juniors or mostly uninterested. I had asked for reviewing and I always got a "A OK" answer. The organizations I worked for did not really enforce this either. They were busy releasing to customers and to damnation with technical debts (or tests but this is another story). TL;DR When in Rome do as Romans do What to look for in a code review My take on what to look for in a code review is quite simple. Abide to the overall design agreed Be more strict to juniors as they got a more detailed design hand-off. Be more lenient to reasonable changes by seniors or seasoned developers. Ask for the logic behind the change and maybe debate the change to a degree of common ground and understanding. Find bugs   Yes there may be tests and a