Installing a desktop on Ubuntu 18.04 server

Ubuntu 18.04 Server does not come with a desktop by default, but any of the normally available desktops can be installed with the tasksel util.

sudo apt-get install tasksel

List available desktop installations (and other installs/collection of packages):

tasksel --list-tasks

Select required desktop from displayed list and install, e.g.:

sudo tasksel install lubuntu-desktop

Wait for install to complete, reboot, done.

Another global Microsoft Azure outage today: how many outages have there been over the past few months?

Microsoft’s Azure cloud service had another major global outage today as a result of DNS issues, that impacted access to Office 365 (maybe it should be more realistically called Office 360-ish, give or take a few days of unexpected outages each year) and other services like Teams and Sharepoint.

There’s been a number of other significant outages over the past few months, which doesn’t give a good impression of Microsoft’s cloud reliability.

There was the multifactor access issue in November 2018 that again left users unable to logon for several hours.

In September 2018 there was the ‘weather related incident‘ related to a lightning strike near one of their datacenters in Texas. Although it only impacted Azure data centers in Texas, for some reason this outage had a cascading impact impacting access to Office 365 and related services across the US, with some users unable to access services for at least a day.

In June 2018 there was the datacenter cooling issue that took down access for most of Europe, another outage that lasted several hours.

What’s interesting in all these cases is that an issue impacting an Azure datacenter in a specific regional area impacted access to service across a much wider geographic area. You would think (or hope) there’s some planned level of cross region failover support for Azure services, but maybe there’s not?

Good code feels good, bad code feels bad : Trust your instincts

There’s been many attempts over the years to measure code quality with quantifiable metrics, such as cyclometric complexity (a measure of complexity caused by nested conditional branches). An experienced developer who has seen good code and bad code will have an instinctive feeling whether code is good or bad. Gut feel is valuable because it’s almost always right. If you look at code and it feels wrong, you’re probably right. Based on experience, you get a feeling that something’s not right. The difficult part is nailing down what’s not right, and then refactoring to make it better.

There’s been a number of best practice principals established over the past decades of software development that have stood the test of time, and are widely accepted. There are many other ideas and concepts that are topics for hot debate, but these few core ideas seem to be largely accepted by most developers.

In order to understand what it is we’re aiming for, I’ll take a stab at defining what I consider to be the core qualities of good quality code. Quality code is:

  • easy to read, and easy to understand
  • easily testable (with unit tests)
  • easy to fix, and easy to modify

You could expand this list with many other factors, but I think these distill the essence of high quality code. There’s a direct relationship between these qualities and the complexity of the code too. Remember cyclometric complexity measures the complexity of code based on number of branches – code that has a high number of nested branches with a high cyclometric complexity count would probably fail all the above qualities: deeply nested conditional code is usually difficult to read and understand, hard to test, and also usually hard to fix and modify.

As a broad generalized statement, simple code is usually high quality code, complex code is usually poor quality (based on the factors above).

The problem is, it’s not easy to write simple code, it takes time, effort and experience. It’s pretty easy to write complex code, but simple code usually takes considerably more time and effort. Without thought and attention, even as you work on simple code over time, there’s a danger that the code becomes more complicated the more changes are made to it. It takes effort to keep code simple, to keep it from deteriorating over time.

Best Practices for Writing Quality Code

There’s a number of established best practices in software development, many of which if followed help you towards writing code that achieves the 3 points above (easy to read, easy to test, easy to fix). Bob Martin in his book Agile Software Development, Principles, Patterns, and Practices, captures a number of these in the SOLID mnemonic:

  • Single Responsibility Principal
  • Open Closed Principal
  • Liskov Substitution Principal
  • Interface Segregation Principal
  • Dependency Inversion Principal

Other popular industry best practices include DRY (Don’t Repeat Yourself), and the YAGNI (You Ain’t Gonna Need It) idea also contribute and guide you towards developing simple, quality code.

Many of these concepts are deeply rooted in the first of the SOLID principals, the Single Responsibility Principal. If you have a Class that ‘does one thing and does it well’ (another common way this principal is expressed), or a method that does one thing, this code is typically easy to read, easy to test and easy to fix.

Many other best practices and guidelines tend to result indirectly in achieving the same desirable results. In many cases regardless of the approach or best practice followed, the ultimate result is code that does one thing and does it well. Code with this ultimate quality meets the criteria of easy to read, easy to test and easy to fix.