John Louros

Lately I have been working on a single-page application (SPA). From a high-level perspective, the goal is to provide a documentation portal for a set of RESTful APIs. The APIs themselves were designed with Swagger, so all information could be easily discovered and consumed from the Swagger output (JSON file containing path, resource definitions, security details, so on). Additional information, not provided by Swagger, is written in markdown files and presented in a separate location (things like getting started guides, how to authenticate, so on).

With the reoccurring need of PowerShell to manage infrastructure setup, monitoring and deployment, it's vastly important that we have the right tools in place in order to keep PowerShell scripts organized and properly maintained. Nowadays, the development of software applications require a common set of strategies/practices so developers can feel confident about making new changes and/or refactoring existing code. Techniques like test-driven development are quite common in the object-oriented programming world. Unfortunately, when it comes to infrastructure code, developers tend to ignore the same strategies. Mostly due to time constrains or the lack of reliable tools to test PowerShell, Shell or Batch scripts.

As you might have noticed, I have been absent from this blog from the last couple of months. Not that I ran out of topics or I don’t want to share my opinions, it’s just “life got in the way”. Putting it bluntly, my priorities shifted so I choose to spend more time doing other tasks. Obviously, I could spare a few minutes here and there to write a new blog post, but sometimes you just need a long period of reflection to observe and rethink what to do next.

OpenSSL became publicly known (unfortunately) for the wrong reasons. Their development team got the typical backlash that System Administrators usually get: if everything is working fine nobody cares, as soon as something bad happens everybody loses their mind. I'm obviously talking about the Heartbleed bug. Before Heartbleed was found, it was estimated that 61% of all Apache servers used OpenSSL to handle TLS/SSL connections. As soon as it was found a lot of people freaked out. Successfully using this exploit could allow an attacker to read a target server memory, extract its private key and ultimately mount a man-in-the-middle attack . On the other hand, OpenSSL development team consisted of 11 contributors and a budget of less than $1 million a year (most of it from donations). In a world where even large Corporations, with almost unlimited resources, consistently release buggy software, a team of eleven developers should be allowed to make a few mistakes.

Whether we like it or not, JavaScript has been exponentially growing in popularity. While the benefits can be obvious, there as some side-effects that are usually overlooked. As more and more features are being pushed to modern web browsers (making it compelling to build web applications that work in almost every device), on the other hand feature fragmentation is getting worst every day. We can point fingers at all the different browser vendors and their constant push of new updates. To make matters worse, the same browser might have different versions for Desktop and Mobile devices (Chrome != Chrome for Android != Android Browser). Some of this problems could be avoided if everyone always ran the latest versions (and Google Chrome started off with great ideas to make that possible) but the reality is very different. Take a look at can I use to have a rough idea of feature reach and disparity. At a higher level, consider how many people still use Windows 7 (and uses IE)... Does everyone upgrade to the latest iPhone or Samsung Galaxy as soon as they come out? Most Android phones aren't even compatible with the latest Android version. If fragmentation is gigantic in the most used mobile OS, imagine how big that is problem if you account for all available web browsers. To be fair fragmentation is an issue if your audience uses a diverse variety of browsers and you are using brand new browser features. Both problems are easily identifiable, fixing them might not be so easy. Anyway, just be aware of this issues when you're working on web applications. Now that we are done the warnings, let's jump into a practical example.