Often enough I have to explain my way of going about setting up a CI/CD pipeline with multiple deployment platforms. Since I am a bit tired of yapping the same every single time, I’ve decided to write it up and share with the world this way, and send people to read it instead ;). I will explain it on “live-example” of how the Rome got built, basing that current methodology exists only of readme.md and wishes of good luck (as it usually is ;)).

The typical evening/morning (depends on readers interpretation of 4am) consists of me working through mountain of outstanding tickets, with breaks taken by browsing the good ole stack overflow. Most of it consists of down-voting and copy/pasting in one of my “This isn’t a free-coding website, show us your work” templates. But tonight I’ve run into a truly great question – where the user wants to loop his application until user quits, and have some conditions depending on his choices.

Interview. The part of hiring people that is invaluable and yet, done oh so wrong by most of the companies. I can’t count how many companies I’ve spoken with, only to be turned off after first five to ten minutes of it. Last week was one of those, where I gave up on the company in short 10 minutes after walking through the doors.

Long gone are days where single-threaded software was a viable solution, nowadays even a proper simple hex editor is running multiple execution stacks to achieve whatever it does. And when we need that there are two main options – Multithreading and Multiprocessing. While I don’t feel like going into the whole debate of which one is better (and why the answer is multiprocessing), let’s just have a very quick look at how they perform CPU-based tasks. And, spoiler alert, threading fails at it big time (which won’t be a surprise to anyone who have used them).

Dealing with legacy (accepted euphemism for manure) code is an integral part of every company that develops software. You cannot escape it; you cannot avoid it, you can only roughly manage the level of it in the codebase. And because of that, every piece of code eventually gets to the point where it has to be up-cycled so it will meet with the new business requirements. What it, usually, means is that it needs to be faster, better and stronger. And this is what we will do today. We will start by looking at some awful code, analyze the shortcomings, figure out how to overcome them and, eventually, turn this piece of legacy into a scalable service.

This may sound a bit counter-intuitive at first. In the end how the hell you will know that you didn’t wind up with a “management consultant” as your new CTO if you do not interview them? Well, it is a valid point but let me explain this concept with a case study from some time ago. It all started in a warm spring evening when my phone rang. It was one of my old clients, and he was in trouble.

At x20x we deal with a lot of APIs, and even more data. And while python is usually fast enough, there are parts that require blazing fast performance. This is where a programmer is left with couple options:
– Optimize python routines
– Rewrite parts of your code to Cython
– Write the required code in C/C++ and expose this functionality to python.
Generally speaking, optimizing python routines is the most important step but it will also get you only to a certain point after which you cannot improve it anymore. When that is not enough you have to either write the parts in Cython or write them in C/C++ and then include them inside your Python. I personally dislike Cython (reasons won’t be included in this article); so I strongly lean toward C++ extensions. That also comes with multiple options, but in this article I will explain the easiest, and my favorite, way to do it – with Boost.Python.

As I did mention in latest post about using Visual Studio for Linux development, I do a lot of low-level work, very often involving ASM and C. And while there is a lot of sophisticated software for new technologies, even C++, ASM and C development seems unloved to say the least (asmCharm, please!). Because of that, low-level developers write their own tools that harness the power of ssh, rsync, toolchain and all the coolness that is needed just to make the process a little less of a hassle. And that is how watchbuilder was born and conceived, as a necessity.

Before we will get to the more technical topics, I figured out that I will share one amazing way to develop C++ code for Linux easier and more pleasant than you ever thought it can be. And you will achieve that by getting Windows with latest Visual Studio. If you want to skip the boring personal story, search down to “oh boy” ;).

Ah the Codility, project that was born out of necessity and over the time turned into a monster that does exactly the opposite of what was intended. A tool that every recruiter loves, every wanna-be programmer fears and every person who writes software, in a commercial environment, laughs at (if they don’t, they should!). And all this hatred comes from a very simple reason – Codility doesn’t test programmers; it tests ability to google and use notepad. And I am not just blindly ranting, so bare with me, while I explain the top issues I have with Codility.