DEV Community: kohloth

Linux for the layman

kohloth — Sat, 08 Jun 2019 15:43:28 +0000

Originally published at socket-two.com on 30th Apr 2019.

For the past decade, charts depicting operating system market share in the context of laptop and desktop computers have looked much the same. Wherever you look, you will see that windows has consistently dominated by a large margin, occupying about 90% of machines. MacOS has consistently been a distant second, at 7% - 8%, and the remaining slice of the pie - a very thin slice - has always been the claim of the paradoxically plump little penguin, Linux.

Why is Windows so popular? Is it because it is better? Or is it just because it is what people are used to?

Maybe a small patch of light can be shed on the answer to this question in the form of another question: In the context of I.T., what percentage of the global population is a demographic that fears the prospect of unfamiliarity, and will go to considerable lengths to avoid it?

A few summers ago, I was sat with some friends in a garden just after dusk. The chiminea burned with a warm glow, and the birds were just settling. Such a scenario can garner a predisposition to philosophical thoughts, and the Linux-loving part of me could not be restrained from a small attempt to proselytise. (Unfortunately for some, Linux-converts often harbour this urge).

I explained how the customisability of the operating system allowed me to be more productive and comfortable while working. In particular, I described the convenience that emerged from the expressiveness and directness of the command line as an interface, and the power that came from the command line's applicability within repeatable and automatable bash scripts. I also talked a bit about how operating-system-level, configurable keyboard shortcuts could be set up to very easily open - and switch between - programs: Something that sped up my workflow considerably when using Vim, Terminator, and Chrome in unison as a fragmented development suite.

"That's all very well..." began one of my good friends, clearly having taken aboard the gist of my descriptions. "But if you're not a computer programmer, if you just use a computer for common day to day stuff...word processing, surfing the web, playing music, watching films...Windows is fine."

I nodded with a frown, and granted that it was true. His point about Windows being fairly well suited to such tasks was technically correct. But then something very interesting dawned on me. While Windows is fine for the majority of most people's casual computing needs, even at this level, Linux is arguably, demonstrably better - although personal preferences abound. An accessible Linux distro, such as Ubuntu, will actually provide the rudimentary operating system features that all users lean on with a reliability, efficiency and, crucially, a user-friendliness that can make Windows look like the unusual, obstinate one.

It also occurred to me since the discussion, that getting used to modern Linux is, relatively speaking, very easy. The learning curve involved in transitioning from any version of Windows to Ubuntu Linux or Linux Mint, is no more painful than transitioning from Windows XP to windows 7, or from Windows 7 to Windows 10, when the operating system is only used for basic tasks. That is to say, it is not very painful at all. Linux's unpopularity, in the context of this, and it's excellent suitability for all users and it's free price tag could be considered paradoxical.

Before going any further, I ought to clarify that I am not claiming that Linux is fundamentally, or objectively speaking, necessarily a better tool than Windows, in and of itself. However, I am claiming that a large number of computer users are likely to be pleasantly surprised if they put the effort in to make the switch, and that the effort is trivial.

In a similar way, I would not ever claim that a rubber mallet is, objectively speaking, a better tool than a steel claw hammer. Even in consideration of a specific scenario when a worker must hammer large softwood parts into place without damaging them, I would not claim that the rubber mallet could be said to be objectively superior - A worker may have an excellent technique with the claw hammer, they may feel that it is lucky. A wide variety of marginal things could make the contrary tool more conducive to productivity. However, in consideration of the simple fact that the rubber mallet distributes force more evenly over a greater surface area, I would draw attention to the existence of an advantage that is obvious, significant, and widely applicable.

Arguing this theory to my friend, citing the user interface, relaxed attitude to updates, increased stability, and ease of software installation yielded a response that was similar to my own. He nodded and frowned a little. No verbal response was forthcoming, but the message was clear.

"That may be true...it may be...but I am not really inclined to take the proverbial leap of faith."

Therefore, as a Linux devotee, I will attempt to make a more compelling case for the adoption of Linux here. However, before I do, I would like to reiterate that this is not an academic, evidence-based discussion, or a claim that Linux is fundamentally superior. It is, however, a collection of points that I would like the reader to consider, in support of the theory that Linux is (Specifically Ubuntu Linux and Linux Mint), in many ways, more convenient and user-friendly than Windows when undertaking common, causal tasks. It is for this reason, and within these parameters, that I make my argument.

Linux for the Layman

The graphical interface

As the user in consideration is not necessarily technically proficient, and perhaps coming from a Windows environment, it is not unreasonable to assume that the graphical user interface will be their primary method of interacting with the machine. Therefore, it is important to their unimpeded use of the system that the graphical user interface is good. It is the glue that holds together all the computers windowed applications, and is the operating system function that the user will be most acutely aware of. It should be intuitive, ideally attractive, and it should implement the most useful of features well. Customisability is a valid concern here, but only when customisation is important and significantly advantageous to casual tasks. When considering the components of the user interface, the most important parts to a casual user will likely be the program launcher and dock (aka the "start bar"), the window management system, and the default file browser program.

The Windows start menu and dock is probably its most iconic feature. The concept behind its earliest incarnations is simple. Users may click on the bottommost, leftmost button to see a list of installed programs, and click on one of these programs to launch it. When a program with a graphical user interface opens, a small box representing it is added to the dock, and when it closes, this disappears.

The publication of Windows XP saw the start menu pop-up exhibit a few more features than it's Windows 95 / 98 predecessors, now also consisting of a list of frequently used programs, utilities, and file system locations. It's not hard to imagine that these were handy additions for most users. In particular, a clear link to the control panel was probably helpful in directing casual users to the system configuration when they needed it.

Windows 8, however, introduced a dramatic reinvention of the start menu, whereby the small pop-up was replaced by a full screen list of shortcuts, utilities and file system locations. Furthermore, attention-grabbing widgets such as weather reports, news stories, and even some thinly-veiled product promotions were added. Windows 8.1 and Windows 10 paid heed to the outraged objections that were voiced by it's user base, and reverted back to the pop-up that users were familiar with. The attention-grabbing widgets, however, still remained a part of the menu. Windows 10 still also exhibited some of the unusual graphical interface behaviours that were previously introduced as the result of a "touch screen device first" design philosophy that was present in Windows 8. Buttons remained large and square, and a propensity to display relatively large quantities of information within small spaces persisted. Graphical components still slid in and out from the side and bottom of the screen in response to (often, unintended) user gestures.

In my opinion, the Windows graphical user interface peaked at the perfect balance between features and simplicity with Windows XP, and has since become a bit of a debacle.

Top: Windows XP launcher bar. Mid: Windows 10 launcher bar. Bottom: Linux Mint launcher bar.

It's interesting to note that the Linux Mint launcher bar has more in common with the Windows XP start bar than the Windows 10 start bar does. As such, Windows users who preferred the Windows XP start bar or had a hard time adjusting to the Windows 10 start bar should have no trouble using the Linux Mint start bar. What will appeal to casual users and experienced users alike is that it is simple and uncluttered. It is immediately obvious that there is an exhaustive list of categorised programs which can be scrolled through or searched. The off / standby / lock screen controls are quite easy to locate. There is also a link to the control panel, which, while unlabelled, is a pertinent addition. Programs that are opened appear as blocks within the dock, which again, is something that Windows users will find amicable.

The Windows file manager is liveable, at best. Nearly all the basic features that a casual user would benefit from are included. There is support for a list view, a thumbnail view, sorting, and renaming. There is an address bar in which the user may paste file system locations. There is also a sidebar that can be used to show either a file tree (quite essential for reorganising files), or a list of shortcuts.

Despite the presence of these basic features, a key feature related to file reorganisation is lacking. It is not possible to have multiple file system locations open in one windowed instance of the program by means of tabs or split panes. This can equate to an inconvenience when reorganising files. For example, a user who is simultaneously browsing music and organising their photo collection will need to have 2 (or more) separate windows open. If they want to minimise, maximise, move, or close these windows, they will have to do so one window at a time. Juggling file browser windows can get frustrating when it has to be done several times a day.

The aesthetics of the Windows file manager are mostly inoffensive, and will please people who like clinical shades of white and blue. The list of buttons, controls and icons that create the slightly odd assemblage at the top of the file browser are, however, quite cluttered, and despite being labelled, feel unintuitive.

Top: Windows 10 file manager. Bottom: Linux Mint's default file manager, Nemo. Note that Nemo is shown here in the context of a dark system UI skin.

Windows users will be pleased to learn that the vast majority of Linux distributions do have a graphical file manager, and that the default Linux Mint file browser, Nemo, is incredibly similar to the Windows file manager.

What is different, is that it's aesthetic appearance can be completely changed with a variety of skins, and that there is also less clutter. Clearly iconographic buttons on the top left take users backwards, forwards, or further up the directory tree, and buttons on the bottom left switch between a list of bookmarked locations and the file tree. It will also let the user create tabs and panes, as depicted in the screenshot above, for the easy reorganisation of photos, music, documents, or javascript files, for those so-inclined.

Regardless of which file manager is favoured by the user, each system will not object to the installation of a third party one. However, the file manager in Windows is slightly more engrained, which will cause it to more readily steal precedence when various exceptional dialogues and shortcuts are invoked.

The last thing to consider is the desktop environment itself. In an operating system, the desktop environment defines the global appearance of the system - toolbars, buttons, dropdowns, icons, dialogues, and in some cases, the overall look of entire programs (particularly native ones, such as the file manager). The desktop environment also defines the means of organising program windows and general workspace that a user will have.

The windows desktop environment itself is decidedly not bad. Like the file manager, it provides a fairly well-rounded set of features. However, as it is even more fundamentally engrained into the system than the file manager, and as it has few customisation options, users are stuck with it - which can be a problem if you have even a few small qualms. Using it several times a week, a few small qualms can amount to a large inconvenience. In the year 2019, this is not a particularly intensive usage frequency for the average office worker, photographer, or film-watcher.

The desktop environment in a Linux system, by contrast, is completely customisable and furthermore, entirely replaceable.

A Linux user may install a dark theme consisting of dark backgrounds and light text if they wish. This can be helpful in reducing both eye strain, and battery consumption - intents not exclusively associated with programmers. Dark themes can also be more stylish, and a user interested in wowing their friends with a beautiful green, red, dark, light, silken or metallic skin can do so quite easily, if they are so inclined. The installation of Compiz fusion effects can even grant them the mage-like power of drawing fire onto the screen, or turning it to water to create ripples over a video conference display or desktop background. Another, more pragmatic way to take advantage of desktop environment modularity is to install a tiling window manager, which can automatically organise windows for you, even as you open them, based on a variety of configurable criteria. Admittedly, this something that only technologically intrepid users will want to pursue, however.

Many Linux desktop environments have supported multiple workspaces for quite some time now, which afford users the ability of distributing windows over an array of multiple, virtual desktops. This is a way to manually group related program windows when multitasking. Windows does have such a feature, but it has only recently been introduced.

Software

Windows, generally speaking, only has one well-established, commonly-used method of installing software. The user will download some form of executable file (typically an exe or msi), and then execute it to prompt the operating system to begin interpreting and assimilating it. It is not a bad system, and is particularly forgiveable when the user knows exactly what they want to install before they run through these steps. However, opening a browser, and trawling through a list of search results, and then a list of available downloads is a bit of a chore. And just as importantly to a casual user, and even more so to the uninformed user, there is always the risk of inadvertently downloading an executable that will actually install a virus.

Linux is known for it's manual installation procedure that involves running a textual command featuring the keywords make and install. However, most versions of Linux also support a "browse, download and install" type system, similar to Windows equivalent described above. For Debian and Ubuntu systems, the "exe" file has an extension of "deb", and for the intent of a casual user, it works in the same way: Installation is just a matter of double-clicking.

However, Linux does have a better way of installing software. A directory of vetted, recommended, free software, is Linux's pocket ace. Windows does not have a system that is comparably mature, popular and populated. It is distinctly advantageous when a user is installing a specific program, and also when a user is looking for any program that will fulfil a particular purpose.

For example, if a user wants to watch a video on their hard disk, but it is in an obscure format, they may elect to install the VLC video player. To do so, they can press one button to open a terminal, and then type sudo apt-get install vlc. After a few seconds, the VLC player will be installed. If the system requires other software for VLC to work, that will be installed at the same time - everything will be taken care of automatically. This is something that a casual user will appreciate, no doubt. It is no fun hunting around for a missing runtime or DLL file.

On the other hand, if the user is looking for a graphics editing program, but they do not have a specific one in mind, they may see a list of programs available for automatic installation simply by issuing the command sudo apt-cache search paint, for example, and then elect to subsequently install one with the apt-get install [x] command - where [x] is the name of the program.

This information is slightly impertinent, as these examples depict the "casual" user interacting with the operating system by means of the console. However, consider that the commands are simple. Consider also, that users may use a variety of excellent graphical programs to leverage these commands on their behalf. These programs will similarly search the online software directory and install things from it without necessitating the typing of console commands. Synaptic Package manager (shown below) is one such tool, and it comes installed as standard on some systems.

It's also worth acknowledging that Windows has a tendency to come packaged with useless programs - bloatware. This is a bit of a low blow, as it is often computer manufacturers that decorate the operating system with such atrocities. Still, it is, for many users, an expedient affliction. This can be troublesome for the inexperienced, as such a demographic will rarely be able to distinguish between resource-hogging measles and important operating system utilities. For this reason, many users will not even attempt to clean them up, and will be perpetually pestered by pop-up splash screens, registration reminders, and unwanted auxiliary program launchers.

Heckling

A freshly-converted Windows-to-Linux user is likely to be beamish in response to the distinct lack of heckling.

Prior to Linux exposure, it's not uncommon for a windows user to think that restarting their computer in response to a software installation, uninstallation or update, is a ritual common to all computers. However, the architecture of Linux is such that required restarts are very rare indeed, which is of benefit to all.

The other, more pervasive and inconvenient form of heckling that all Windows users suffer, is the compulsory update.

Every so often, a Windows user will finish what they are doing on the computer, and tell it to shut down. Preparing to go on about their business, they will notice (if they are lucky) that the computer is not actually shutting down, but that it will actually spend the next five to fifteen minutes installing updates. The impact of this can range from a minor inconvenience to a major personal disruption.

For instance, shutting down an office computer after a hard days work, an employee may suddenly become aware that they neglected to send an important email. Their train leaves from near the office in fifteen minutes time, but their computer is now temporarily inoperable, which means they will either send the email or miss their train. Laptops given to overheating can also suffer in the event that a user closes the machine and stuffs it into their bag, not realising that it has not respected their instruction to turn off. The third sticky situation consists of the requirement of a restart, necessary to complete the installation of a critical program, that imposes the time-consuming installation of the software update as a bundled action.

Linux Mint, by contrast, never forces a user to install updates. It will never pester users to install updates, either. Updates are installed when the user deems it appropriate. It is rarely important that Linux software is kept up-to-the-minute with updated software.

Stability, security, and efficiency

The most casual of users may not be particularly excited by the concepts of stability, security and efficiency, but nobody wants to experience a crash, and nobody wants to find out that their computer has been infected with some form of key-logging, web-cam-spying personal-file-encrypting virus.

In my personal experience, (and I don't see any reason why it would be substantially different for other users), Windows is more likely to hang, crash, or present you with an error dialogue when you were, in actuality, expecting an output that did not make reference to your computer's emotional state.

Should an error arise on a Windows system, you generally only have two options - to read a troubleshooting guide, hoping that there will be something in there that applies to your situation, or to wait for Microsoft, the software developer, or Microsoft in conjunction with the software developer to issue a fix.

As Linux is an open-source system with a transparent implementation, an experienced developer has the additional option of digging around in the system in an attempt to fix it themselves. An inexperienced user may not have this option, but they do have the additional option of reaching out to a network of passionate people, (or searching Google for records of others who have done this) in hope that someone has already taken the initiative to remedy the problem. As the code is open-source, and eligible for improvements issued by many pairs of qualified hands, this is often found to be the case.

In regards to viruses, most viruses are written to target Windows. This is, certainly, because it is more popular, and perhaps, because it is perhaps, less secure. A Linux system can be hit by a virus, but this is dozens of times less likely to happen, relative to Windows computers.

Linux is also substantially lighter than Windows on several fronts, which brings a number of boons that everyone can appreciate. Its installation payload is smaller, and therefore faster to download. Once installed, it takes up less space on the hard disk, leaving more room for photos, videos, and other applications. It has the novel advantage of being USB bootable, too, meaning anyone can run Linux once on their computer without making any permanent changes to it. This can be valuable for those seeking to try before they buy, and also for those who want to use an operating system that they are used to, regardless of the configuration of the machine placed in front of them. Lastly, Linux is faster to install. The last time I installed Windows and Linux together in one sitting was a few years ago, but it is still fairly relevant to note the difference in installation duration. Windows took about three hours. Linux took about thirty minutes.

It should also be mentioned that some versions of Linux (Crunchbang, Lubuntu, Xubuntu, Puppy Linux) are specifically designed to run well on machines with very low specifications. This creates an option that is preferable to the installation of obsolete versions of Windows, when attempting to breathe life into old or small, specialised, low-power computers.

Room for growth

The last advantage that a casual user will gain by adopting Linux is definitively, a latent one. As previously mentioned, a high level of configurability, and a potential high level of automatability are among Linux's greatest aspects. This is a benefit that does not come quickly or easily, in comparison to the benefits described above, and therefore, a casual user will not experience these benefits initially. However, Linux's openness and large support network of enthusiasts does mean that such effects do, however, come incredibly easily, when compared to Windows equivalents. Therefore, a prospective Linux convert may confidently come to the operating system comfortable with the knowledge that should they decide that they want to gain more control over the system, that it will not fight them as they attempt to do so.

Caveats

As illustrated by the above, there are a number of factors that make Linux a fantastic solution for the casual user. However, there is one clear, but relatively small disadvantage to using Linux, which must be mentioned if this article is to be complete.

Some software vendors do not create Linux-compatible versions of their programs.

Acknowledging this is a bit of a low-blow against Linux, as the issue is generally only attributable to the actions of third party software vendors. (And of course, capitalist third party software vendors cannot be blamed for very prudently conserving resources. Such a strategy is unbecoming to a pleasantly indiscriminatory, global software repository, but is often a wise choice for the business itself).

There is one clear effect of this. A user that is heavily-reliant upon a handful of specialised, third-party programs will typically find that, upon switching to Linux, they can no longer easily or conveniently use perhaps 10% - 40% of the specialised, third-party programs that made up their former, Windows-based collection.

This is not a huge concession, however, and will typically only affect less casual users, as:

Most programs that most people are likely to use are available to install natively. Examples: Google Chrome, Mozilla Firefox, Spotify, Skype, Minecraft, VLC media player and Thunderbird Mail. The availability of Chrome and Firefox are notable, as web browsers are capable of serving as the foundation for a variety of other applications.
Some more specialised programs do, in fact, have native installers. Examples: MySQL Workbench, Audacity, Blender, Godot.
Some more specialised programs provide assistive mechanisms to get their software working on Linux, in lieu of a fully-fledged native installation candidate. Examples: Adobe Creative Suite, Unity game engine, Visual Studio, Reaper audio desk.
Some programs that do not have native installers can be replaced with highly similar Linux equivalents. Examples: Microsoft desktop calculator -> Linux desktop calculator. Notepad -> Gedit. Microsoft Office -> Open Office.

Furthermore, in the event that one of the considerations above is not applicable for any given program, a variety of approaches can serve to circumvent or mitigate the loss. A user may:

Install Linux alongside Windows, and boot into Windows when they need to perform work on Windows-only programs. This can be a hassle, but for programs that are used infrequently, in isolation, and particularly for long periods of time, this is a perfectly reasonable solution.
Install the Windows-only program on WINE, a Windows emulation system that runs Windows programs inside Linux. This circumvents the need to use substitute software, and the need to boot into Windows. However, Windows programs running in WINE can sometimes exhibit bugs.
Install a full Windows virtual machine inside Linux, to run Windows programs inside of. The complete sovereignty and integrity of a full virtual machine will ensure that Windows programs will run exactly as they would within a native Windows installation (with the possible exception of a slightly noticeable drop in the speed of performance). Running Windows inside a virtual machine program that is nestled inside Linux provides the advantage of simultaneousness. Workflows involving the simultaneous use of Windows and Linux programs are made viable.

These software-loss mitigation strategies vary greatly in convenience, effect, and difficulty in engagement. Therefore, inexperience with Linux, and a hunger for specialised programs can, in some situations, make mitigation of software loss harder, to some degree. However, despite this, for most casual users, a judicious application of each viable strategy can usually sufficiently nullify the effect of a (typically, small) measure of "program loss".

Afterthoughts

In consideration of the above, it could be said that Linux, under the consideration of a casual user, is:

Easy to learn.
Quick and safe to try or install.
Highly user-friendly, and for some distros, not particularly dissimilar from Windows.
Easy to populate with a variety of safe, free software.
Flexible, and easy to establish basic customisations upon.
Convenient.
Free.

I hope that any readers who were previously unfamiliar with Linux can now see it as a very approachable option for new or existing, home or office computers, and, in the absence of any potential crunch points for required, semi-specialised software, will be keen to adopt it.

The quest for the perfect CSS complexity management technique

kohloth — Sat, 08 Jun 2019 15:34:43 +0000

The following is an except from: socket-two.com.

Standing at the end of the second decade of the second millennium, and surveying the front end web development scene, scores of frameworks, methodologies, and miscellaneous technical solutions can be seen scurrying over each other, reaching upwards and outwards for the prizes of validation, market share, and architectural elegance. Crowds of developers look on - some cheering for their favourites, others feeling bewildered by the sheer amount of new blood, perpetually holding onto their gold until they have fully studied every investment option.

Webpack holds a gleaming silver sword up to the sun and cries out, while gulp sits beside her on a chariot marked 'node'. He adjusts his armour and wonders a little nervously if they are really on the same side or not. A middle-aged Grunt plods slowly around the arena circumference with tree-trunk limbs, bashing away any lingering obstacles with its buckler.

In the raised centre, a wild-eyed, long-haired, juggernautian React has temporarily floored Angular, and stands tall to strike a pose. A round of chanting swells, in admiration of the gladiator's power and grace. However, a younger, more nimble contender named Vue casually ambles up the slope to where they preside, and prepares to enter the hottest part of the fray with a confident, but unassuming disposition.

Although most theatre-goers have their attention directed towards the centre of the stadium, a rather novel skirmish has developed near the entrance among the gladiatorial animals, and is beginning to draw substantial interest. Atomic, the fox, is biting at the ankles of BEM the bear. The commotion attracts a couple of tigers and a lion. A woman dressed in fashionable robes, standing to your left, notices you watching, and shouts into your ear.

"He'd better be okay! I have 150 gold bet on this bear leaving the stadium with blood still in it's veins!".

Another well-dressed man nearby chimes in. "The fox is no threat." He exclaims loudly. "I have 250 gold on that bear, and I'm not at all worried! It can handle an adversary of any size!"

"I have 5 on the fox.", pouts a boy with shabby hair, turning around with an indignant countenance. "What about you, old man? What do you think of the animals?"

The elderly figure standing on your right looks slightly bewildered and blinks a few times, as if waking from a dream. "It's all Greek to me...", he croaks into the air, while eyeing the horizon. "In my day, we didn't even have animals in the stadium."

CSS: A blank canvas

For an arena where one fully-fledged programming language clearly dominates, front end development houses a surprisingly large number of actively-competing software packages and methodologies. This can be frustrating to a developer, when the onus of knowing them all may rest upon their shoulders. However, its also a wonderful thing to behold, as it is a testament to the beautiful, boundless flexibility of javascript as a language, and also the industrious spirit of the community.

However, this article is not about Javascript. It is about an entity that is afflicted by a similarly wonderful problem: CSS.

The CSS specification gives us a declarative language that is, in essence, incredibly simple to understand and write. But as with javascript, when the language is employed on larger projects, its simplicity, flexibility and unopinionatedness can give rise to illogical, labyrinthine codebases, if not wielded carefully. Devising a strategy to manage complexity is a responsibility that is wholly appointed to the developer - or the development team and community, if deferred to.

This brings us to our point of departure.

How can a lone developer, or development team, avoid the emergence of unmanageable or unnecessary complexity when writing CSS for projects of non-trivial size? Where techniques differ, what are the merits of each?

Up until recently, there were no formalised systems to help developers manage CSS complexity. In the past, stylesheet authors were only guided by their own opinions of the CSS specification, and by unofficial, naturally-emergent best practices which were cultivated by their fellows - typically expounded within books, articles, and chatrooms.

Today, several formal CSS organisation systems exist. Most are similarly unofficial. Among them are BEM, OOCSS, SMACSS, MCSS, AMCSS, Atomic CSS, and the irreverently-named, FUN CSS. BEM and Atomic CSS are paticularly interesting studies, as they are among the most popular, (or most infamous, depending on who you ask), and also the most unconventional. BEM is particularly relevant in our enquiry, as it was specifically designed to tame voluminous CSS codebases.

With this in mind, this discourse will examine two types of CSS organisation practice - those categorised as sets of general rules, and those categorised as formalised systems.

Full article: socket-two.com.

The seduction of off-the-shelf solutions

kohloth — Sat, 08 Jun 2019 15:29:34 +0000

Originally published at socket-two.com on 10th Feb 2019.

"Le Gastronomer"

Imagine the following scenario.

It's 09:53 on a Monday morning. You're sat at your desk, at work. Sunlight is filtering in through the blinds of the open plan office space, settling on the rustic wooden floorboards. The office dog scratches the side of its head and creates a cloud of particles, which is somehow both majestic and a little bit unpleasant. You are surrounded by a quiet ambiance, a mix of eager enthusiasm for the week ahead and the lamentations for another weekend gone by.

You've touched and organised all of the email that's accumulated in your inbox since you left on Friday, and recall the final discussions that you had with a hip new client of yours. "Le Gastronomer" - a high-tech city bar and restaurant with a novel menu and funky architecture to match, situated in a central location.

They are commissioning your organisation to make them a web app that serves as their very own, branded food blog, an automatic grocery stock management and ordering system, and, of course, a public presence that permits potential patrons to inspect the menu. You recall that the client was also quite keen to be able to have a high level of control over promotional banners, which, you've agreed, they can configure to appear in several areas of the site. The banner behaviour is also to be dependent on many variables, including the time of year, the time of day, ambient temperature, larder stock levels, dish popularity, and the manual input of site administrators.

At 10:00, you have a meeting with the developers, a producer, and a project manager to discuss how you will build the application. The client has agreed to pay a reasonable amount for the software, but they don't have remarkably deep pockets, so their funds will not permit you and your team a leisurely pace. There isn't much room for mistakes. But you've had your coffee, and its a new, unspoilt project and relationship (for now).

The clock ticks over and the meeting starts. You run through the list of requirements with the team. The developers sit - hunched over, listening carefully, with bright eyes, and a kind of still, impassive intensity that reminds you of a pack of dogs waiting for a bowl of food to touch the ground. As soon as you've said your piece, there's a torrent of implementation suggestions, but after a bit of discussion, the key requirement of the site blog has become focal, and the idea of using an off the shelf solution, Wordpress, has taken hold.

"Getting rid of the need to develop an article-management system would save a lot of time."

"This sounds like a good idea, we don't want to reinvent the wheel."

"Wordpress has a rich ecosystem of extensions - there are several banner managers to choose from, which will cover that requirement."

"It's a very popular system - the codebase is robust and well-tested."

"Client's love it - the interface is simple."

These arguments seem fairly compelling, so the speculation gradually settles down into satisfaction as the team collectively exhales, and one of the developers leans over to help an intern download and install the Wordpress source code into his development environment - to demonstrate it to him. Everyone seems quite content.

But then an oblique figure that has been sat squirming in the corner finally pipes-up.

"I'm not sure if this is such a good idea".

Regarding the concept of "off the shelf" software.

Whenever you sit in an application design meeting like the one described above, the most fateful decisions you can make are decisions regarding the inclusion of third-party code. In particular, its important to correctly identify which parts of the software should be delegated (if any) and, when presented with multiple options, which vendor packages you will use.

Its a very reasonable thing to want to reduce development time by draughting in third party software to serve as ready-made puzzle-pieces, especially in a commercial environment where time is tight. Viewed from afar, this logic is sound, and when done judiciously, the practice of scavenging for parts can work out very well. But in reality, teams are often so keen to save time, that they don't realise they are sabotaging the project, and making things harder and more time consuming for themselves, by jamming a square peg in a round hole. This can be disastrous, and can give rise to a colourful cornucopia of maladies, which I will discuss below.

Pandora's third-party package

Arguments against using third-party code in your application.

Customisation

It may not be customisable When third party code is used in a project, its generally considered good practice to keep it separate from the application code that is written by the project developers. This usually means a combination of storing it in a separate directory, omitting it from version control, and sometimes, allowing it to update itself. Therefore, its generally considered bad practice for a project developer to make changes to third party code. If nothing else, any changes the project developer may impart will be lost if the third party code gets updated. With this in mind, third-party code is considered immutable. It cannot be adjusted or customised - at least, not by means of opening the third party code in a text editor and making modifications directly - which is the method that gives the most control. A well written third-party library will contain mechanisms that allow it to be customised in other ways, such as accepting a configuration object, or allowing base classes to be extended. However, crucially, its common for situations to arise where the modification in behaviour that you need to achieve cannot be implemented gracefully. In such situations, you have two ugly options. 1 - Tell the client that you cannot deliver the feature they've asked for, or 2 - write some horribly hacky code...which, will usually negatively impact the application in some way.
It takes longer to customise The allusion that the previous point makes to "code that is not directly modifiable" should illustrate how vendor code can sometimes be more time consuming to customise.
Customising it may have behavioural side-effects The first point should also provide some explanation for this. A hacky customisation can have several negative effects, and one of these is the introduction of bugs. For example, suppose the client decides that the great big "play" icon that appears inside video thumbnails looks obnoxious and they want it removed. The library doesn't have a configuration parameter for hiding the button, and the HTML is immutable, so the developer issues a hacky fix by hiding the button with CSS. The client is happy, as the play button is gone, and they can still play the video by clicking on the general thumbnail area. However, as the play button contained an aria-label attribute, and is now hidden, users accessing the website with screen readers can no longer perceive the video. Here's another example. Consider a situation involving an online shop, where the client wants the "Item added to your cart" message to disappear after 5 seconds, instead of lingering about indefinitely. Again, if there is no inward-reaching configuration option that enables this behaviour, the developer may, for instance, issue a hacky fix where they force the whole page to reload after 5 seconds. The cart message is now gone, but the site visitor may have noticed that their screen went blank for a short period, and their viewport may have scrolled back to the top. This type of thing can be fairly inconsequential by itself, but as these hacky fixes add up, its not long before the overall user experience turns into digital detritus. If the developer had full control, the fixes would be as natural and as fluid as the water over Niagara Falls.
It may compromise the integrity of the codebase Sometimes, hacky fixes don't cause bugs straight away, but they do create fertile ground for other bugs to breed. Usually, bugs brought about from an established illogical codebase are more sinister, as they have a tendency to go unnoticed. They might silently prevent 1 in 10 customers form completing the checkout process, or perhaps continually expose sensitive information. The mechanism for this phenomena is fairly straight-forward: A hacky fix is an illogical fix. When a developer is working on an illogical codebase, its easy for them to inadvertently write logical code that interacts badly with the previously established illogical code (which, while in isolation, was quite innocuous). This results in new, illogical bugs that may not be beknownst to the company.

Fit for purpose...?

Its designed for a general purpose Any given off the shelf software that purports to take a large chunk of work off your hands is not designed to be a perfect fit for your project. Almost by definition, it's designed to be a relatively satisfactory fit for many projects. Therefore, in regards to features and customisation, you will necessarily find that the solution is not ideal in one of two ways. 1 - it is not flexible enough to meet your needs (see above). Or, 2 - it contains so many bells and whistles and customisations, that its not optimal. This brings us to the two points below.
Computational inefficiency Bloated software may be sluggish, and run slowly. This computational inefficiency may manifest as excessive page load durations, unresponsive interface elements, sticky scroll bars, crashes, and increased hosting costs.
Complexity - developmental inefficiency Creating a bespoke module for a slim, purpose-built application is likely to be far simpler than creating a bespoke module for a complex system that requires a lot of pomp and ceremony. In the case of the complex system, the module will likely need to be authored in absolute terms that describe its functionality and declare its parameters in a much broader (and frequently, redundant) context. For example, creating a "Hello world" module for the Joomla CMS, a developer will need to write about 100 lines of code, separated across 5 files. To create that same module in a slim system however, its not unlikely that this module could be authored as one line within one file.
It can be slightly less portable Many projects that include third party code use some kind of automated tool to manage the acquisition of, and updating of, vendor code. Nuget, npm, and Composer are examples of package managers such as these. Npm is a specific type of package manager, known as a dependency manager. What this means, is that when you install one piece of third party software, npm will automatically install all the pieces of third party software that the software you specified is dependent upon. It also installs their dependencies, and their dependencies, and so on. This can sometimes result in very deeply nested directory structures, and large collections of files. When the time comes to move your application to a different environment, moving these files can take quite some time. The process can be made faster by omitting the vendor files from the transfer process, and then using the npm command line utility to install the packages once the transfer is complete - but in this case, you now need to ensure that the command line utility is installed on the destination device. This is not a deal-breaker for most developers, but it can be sufficiently annoying to warrant avoiding package-managed dependencies altogether on very small projects that need to be easily transportable.

Ownership

It's worth being alert to the fact that all the negative things that exist within this "ownership" group of negatives (with the exception of the first) are unique to projects that utilise vendor software. All of these hindrances can be completely avoided if vendor software is not used.

It may be incomprehensible Before electing to use a particular off the shelf solution, ensure that developers can easily learn how to make use of it. Comprehensive documentation should be available. If not, at the very least, the codebase should be logical and readable. This is particularly important if the software is obscure, and generally unknown in the software development world. Using a third-party solution that is poorly documented, uncommonly used, and generally incomprehensible is a reliable way to initiate a project that is doomed from the outset. Its worth bearing in mind that it certainly, in some situations, can be faster to build good software and document it well, than it is to try to borrow software and decipher poor documentation.
It's not under your control If you can't edit the code, you don't have full control over the code. You may be at the mercy of the third-party developers who authored the solution.
It's usage is restricted From a legal perspective, software that you create is owned by you, or your company, and as such, the terms that govern its usage are wonderfully straight forward. In opting to use third party software, you may be agreeing to a variety of limitations. For example, the type of application it can be used in, if you are allowed to profit from it, and how many developers can leverage it at the time of authorship. Sometimes, being able to dispel this looming concern is enough to warrant ditching third-party dependencies. Discouragingly, some clauses in software usage terms are quite vague and unclear. The usage terms of the popular React framework gave some would-be converts cause for hesitation, as it implied that the library could not be used to support any software that was in competition with Facebook. In 2002, Douglas Crockford released his "JSMin" software with an accompanying licence stating that it was only to "be used for good, not evil", which, caused some organisations sufficient anxiety to request that the clause be removed. Hilariously, the licence was amended to allow "IBM, its customers, partners, and minions" permission "to use JSLint for evil".
It can be expensive Third party developers may charge you to use their software. Generally speaking, this can make adoption rates lower, decreasing the size of the community, and the likelihood that people can help you out if it goes wrong. Furthermore, as a commercial asset, commercial code may be obfuscated, or otherwise made unreadable, to protect revenue. This may also make it harder to modify or inspect. And of course, expensive software will put you out of pocket.
Abandonment Vendors sometimes close up shop and abandon their package. They might decide that the software has been made obsolete by a superior invention, they may no longer have time due to other commitments, or they may simply loose interest. This can be a problem. The only thing worse than being dependent on software that you do not control, is being dependent on software that nobody controls. Sometimes, on the contrary, software release activity is remarkably effervescent, and software developers release version after version of their package with short intervals. This is generally a good thing, as you can bank on the software being up-to-date, and relatively well guarded against emergent bugs and security flaws. However, the darker side of this is that it can occasionally contribute to the incomprehensibility discussed above. Experiencing a bug with vendor software is incredibly frustrating when the only guide you can find to help you fix it is written with a different version of the software in mind. Frequently, I have been dependent on guides and documentation that do not even state which version of the software they are for. Its more common for this to be a problem with community created guides, such as blog posts, but on numerous occasions, I have found this to be the case with documentation too. Again, this frustration fits in strongly with the notion of control - or lack thereof.

Interoperability

As mentioned above, some third party software can be hard to customise, and this can generally be traced back to the third party developers (understandably) not being cognisant of, or amicable to all possible use-cases and adaptations of their solution. For similar reasons, a larger portion of third party software is also hard to integrate with other systems. When working with software that is composed of a large number of third party solutions, a river-crossing problem often starts to develop: The fox and the grain can be in the boat or on the shore at the same time, but not the fox and the chicken. The chicken can be near the grain, but only when the farmer is also present. As more and more third-party elements are introduced into the equation, the more likely you are to find that some of your packages do not work well among themselves. And therefore, the solution that you must come up with to let them coexist becomes increasingly more elaborate, hard to maintain, and ridiculous. This fact alone can cause project development to slow to a grind, and create negative impacts on the delivery schedule that are several orders of magnitude greater than those of an in-house solution.

Was it worth it?

If, when you started reading this article, you were entirely sanguine about the prospect of using third party software to save time, I would hope that by now that any unbridled enthusiasm you had has been calmed. I would hope, however, that I have not killed off this enthusiasm completely.

Having observed many projects degrade as the result of thoughtless code borrowing, and a lesser amount of projects genuinely benefit from judicious borrowing, my intention is not to feed inflexible phobias of prefabricated solutions. My intention is to instill a sense of caution in developers or producers who think that off the shelf solutions are a simple, conservative, risk-free way to develop custom software with greater efficiency. The decisions that are made regarding the usage of third party software are very important, and need to be approached with care. They need to be preceded with a discerning understanding of the contending packages, and a careful examination of how well these intersect with the project requirements, and each other. But most importantly of all, remember - when developing bespoke software, sometimes it really is more efficient to start from scratch!

Revisiting the architecture for "Le Gastronomer"

Having established that the legitimacy of an off the shelf solution is a question of the projects nature, lets revisit the hypothetical "Le Gastronomer" project and discuss the merits and pitfalls of the Wordpress proposition.

Before we begin, I should confess that the "Le Gastronomer" scenario is ever so slightly unrealistic. In a project team of about 4 - 8 people, as we have here, if all of the developers but one have understood the "Le Gastronomer" project requirements, and are advocating a Wordpress implementation, its not a very discerning team. Due to its low learning curve, Wordpress does tend to get overused and abused when constructing websites, but dedicated development teams are not typically to blame for this.

Regardless, let's begin by examining the development team's remarks. Each statement has an element of truth, but each statement is also flawed. None of the statements fully pertain to the real nature of the project requirements, or the scenario at hand in general.

"Getting rid of the need to develop an article-management system would save a lot of time."

It is true that out of the box, Wordpress will give you robust and sensibly feature-rich blog-post-based CMS functionality. Using Wordpress will circumvent the need to write code for an admin backend, user authentication, an article administration user interface, and database create, read, update and delete operations. However, in the grander scheme of things, and in the context of this project, its not true that this will save a lot of time. The development of such features are bread-and-butter for many developers, and can be written from scratch in less than a week. Any time that would be saved by using Wordpress for this website would be lost - probably several times over - to fixing issues arising from trying to bolster a light, fairly encapsulated platform with inventory management system integration, and heavy customisation requirements.

"This sounds like a good idea, we don't want to reinvent the wheel."

This is an unsound analogy. Building an article management system from scratch is not so much reinventing the wheel, as it is choosing to construct a sleek, efficient lightweight chassis over grabbing a suboptimal one from the scrapheap. (No disrespect intended to Wordpress - it does have valid use-cases ¹.)

"Wordpress has a rich ecosystem of extensions - there are several banner managers to choose from, which will cover that requirement."

This is the most flawed statement of all. It is true that Wordpress has a rich ecosystem of extensions, and there are undoubtedly some good ones for managing banners. However, the client has very specific requirements regarding the behaviour of the banners. There is also some very advanced functionality that has been described, in which the data that governs the banners must be carried over from a wide variety of subsystems, including weather APIs and a stock level manager. The chances of finding an existing Wordpress banner manager that does all this is nil. Finding one that does some of it, and then hacking it to do all of it, is a terrible idea when compared to the prospect of simply creating it from scratch.

"It's a very popular system - the codebase is robust and well-tested."

This statement alludes to the fact that popular systems tend to be very stable. The logic goes like this. The more people use the system, the greater the collective effort is to keep it watertight, and the more impenetrable, and generally bug-free it is. On the other hand, however, it could be said that the more people use the system, the greater the collective effort is to find exploitable weaknesses, among hacker circles. I am playing devils advocate in acknowledging this though. The countermeasures established in popular software do tend to outweigh the effect of hackers trying to bust open something big.

"Client's love it - the interface is simple."

Many clients do tend to favour Wordpress over other content management systems, as the result of its simple administrators interface. This is a veritable point, but its not particularly relevant if using Wordpress will cause the software architecture to collapse in on itself.

Using third-party software responsibly

This has been a philosophical article, so lets go the whole-hog and close with some analogies. Consider the role of a software developer to be similar to the role of a musician, illustrator, writer or mechanic. All of these roles require the author to carry out a creative process. In a creative process, lots of factors govern success, and as such, one of the best words to describe the effort is "artistry".

A good artisan takes pride in their work. They work carefully and methodically. They do not make rash decisions, or act impulsively. When making architectural decisions, keep these qualities in mind, and you should have some degree of protection from adversity.

Lastly, lets consider the creation of software to be like the creation of a vehicle:

If you want to create a boat that you can live on, don't take a small life raft and pile on a toilet, aga, four-poster-bed, writing desk, cross trainer, sauna...It will sink.
If you want to make a robust tank that will survive even in the most hostile environments, don't take the thickest armour plating money can buy, only to stick it all together with spit and honey. It will be fragile.
If you want to make a vehicle that flies and dispenses fast food, don't just chop a burger van in half and solder the back end of a plane onto it. It will be inelegant, and hard to subsequently modify.
If you want to create a car that runs smoothly, don't go to the scrap heap and collect a Toyota gearbox, a Volvo engine, a Mitsubishi clutch, a Skoda axle, and a variety of wheels - It will not run smoothly. And if when it breaks down, it will be confounding. ²

Instead, if you want to make your own vehicle of any kind, consider building it from scratch to exactly meet your requirements. You may find, after some investigation, that it won't take any longer to build it from scratch, than if you were to have had a "head start" by sourcing existing parts.

If, after careful thought, you have a strong conviction that you can save time by using spare parts, then make sure that you learn about what all the parts do, and how they all fit together before you start assembling. Carefully select a variety of compatible parts that will give your vehicle the features that you have in mind. If you can't find a suitable part on the scrapheap, don't angrily grab the wrong part and say "to hell with it". Make that part from scratch - when your engine is purring, you won't regret it. Once you have all your parts, - one of each necessary component - don't rush the job too much - put them together carefully, with pride and with love.

And if the foreman ever tells you that there is no time for love in your work...find somewhere else to work - lest you end up nothing but an ineffectual, disinterested mercenary! Sublimated love is what makes the software strong!

Footnotes

¹ Please do not misconstrue my comments about Wordpress and Joomla as criticisms of each piece of software, in and of themselves. Both systems have valid use-cases, and I am personally a fan of Joomla, and have admiration for the Joomla project. Please understand that I am only criticising decisions to use either of these pieces of software when they are not the correct choice for the project at hand.

² Please do not misconstrue this analogy as an attack on any of these particular vehicle manufacturers. I am only describing how mixing parts of disparate origins can result in a dissatisfactory and irregular whole.