Alberto on code life

I have found myself lately learning all sorts of new things. I am mostly using this very known video courses web site. Every course is between 5-10 hours broken down to sections and clips. And this is when my mind goes blank  TL;DR sometimes you need to take a break. Take your brain to.. golf Regardless on whether you are coding, reading a technical book or taking an online course at some point or another you may find yourself being stuck on he same lines of code, or paragraph in a book, or rewinding the video of that course. This is it; your brain has had enough. You need to "F5" your brain cells. And this you do by either getting up and taking and stroll around the cubicles or get out in the open air and have your eyes look towards the horizon.. or.. whatever makes your brain disconnect for a while from the task at hand. So towards the new year and in the midst of the holiday season and the time resolutions are being made through the best intentions of being kep

Job hunting for a software developer is a full time job. One polishes and hones one's skills and CV, scours the placement advertising sites and goes out to the world to seek one's next challenge. Ever since the late '90s of the previous century some things have changed and some have not when it comes to looking for a new job. TL;DR tech recruiters have changed . Online presence and you Towards the end of the last century all we had was CVs and not so polished web sites to send our CVs to. Placement companies did their best to make their sites shiny and down the road they even had job posts online with an appropriate submit button to post your CV for a position. In time they also made agents for you to set your job preferences and have the agent send you a notification when a relevant search came up with results. And then somewhere in the second decade of the new century something changed. Your online presence became much more important, not only when looking for a j

"... and then the interviewer coined an expression. I stared wide eyed as it hit me... microservices or not the monolith looms behind every feature... and it is a distributed monolith" TL ;DR not what y ou think read on. From monolith to microservices to monolith What is it that fascinates developers all over the world with microservices? Some say it is the separation of concerns into tiny services focused on one task. Some say it is the scaling capabilities the architecture provides. Others like the fact that there is no single point of failure. Or is there? I came across this video and article  by Ben Christensen about the perils of a miscoservice architecture to become a distributed monolith. And then it hit me. It is not only what is described in the article as signs and perils of a distributed monolith. Consider a set of microservices "perfectly" orchestrated. They each pass around different DTOs, even if duplicate ones, that can evolve in separate p

.NET Core is: A substantial rewrite of .NET in the making A better .NET A multi-platform .NET A way to leverage an amazing language like C# over Linux and IoT (based on Linux) .NET Core is not: A one stop shop  - yet  Only for web Only for cloud development

In this part we will focus more on the process of changing a system architecture and the design at hand  than on code. After trying different approaches in an effort to not change the architecture entirely, with no success, there is only one thing to do. Change the architecture entirely.  TL;DR Brace yourselves, major changes are coming. And they are good! For a recap here is  Part 1 ,  Part 2 ,  Part 3  and  Part 5 What this change is not The system at hand is an on premise system. It does not run in the cloud. I dare say that it does not even run on the same network as the customer's other services. It is an island with a closed network with no access to the world outside including the client's kitchen. These things exist to the extent that remote debugging is not possible, not even plugging a USB key after installation (if there is a USB port on the machine). I plan to address debugging such systems in a post after the series is over so stay tuned ;) About the proces

The implementation of the proposed architecture is at hand. We dive into the change and see how Redis (or any other message queue or pub/sub broker) makes our life easier.  TL;DR Time to make the change. Read it all! For a recap here is  Part 1 ,  Part 2 ,  Part 3  and Part 4 Components of our example GitHub branch Our monolithic example will be divided to three processes: Producer Redis (3rd party broker) Consuming Processor Thin client After we are done with the change, the server will look like this: On to the code The Dataflow library from the previous part will be removed in the consumer. Now that the processes are separated the consumer is super fast up until the actual processing which takes around 1 second. The different components will work directly with Redis which will in fact be the backbone of our pipeline. Ten producers are being used to send messages into 10 Redis lists. Each list has a key named {Producer_i} where i is the number of

In this part of the series we will see how our code, after having evolved from a simple event call to a concurrent mess, will first and foremost get a bit into shape and then being throttled to produce best results. TL;DR The light at the end of the tunnel is not oncoming traffic. More parts are here:   Part 1 and Part 2 ,  Part 4  and  Part 5 Before we start I urge you to go read through the documentation. These are the links that hlped me write this post and learn how to use the Dataflow Library Dataflow (Task Parallel Library) Walkthrough: Creating a Dataflow pipeline Walkthrough: Using Dataflow in a Windows Forms application How to: Write messages and read messages from a Dataflow block Update: On Post and SendAsync  On Post and SendAsync in TPL Dataflow Let the data flow GitHub branch This may be "old" tech for some or all of you but it was new to me when I decided to pop my head out of the "company" man role and into the consultancy role