Category: Web Development

Categories
Web Development

LIBTYFI – Leave it better than you found it

Some of my fondest memories from childhood are the times my dad let me tag along on his weekly trips across the expanses of Northern Ontario in his 18-wheeler. As you might imagine, a daily ritual on these trips was one of washing up in some dingy restroom1 before eating a greasy breakfast (“two eggs sunnyside up, bacon soft, rye toast please”).

All these years later, the biggest lesson that stuck with me was “leave it better than you found it.” In other words, not only “clean up after yourself,” but also “clean up the mess you found.2” After all, the next guy’s going to appreciate a clean space to start his day.

Old code is like a dirty truck stop restroom.

As part of working on code guidelines for my day job, I read a bunch of the code standards and adjacent posts. None of the documentation, blog posts and idioms (DRY, KISS, etc) really touch on legacy code. I suppose it makes sense since they are generally aspirational documents. At the same time, I think these documents are incomplete without touching on it.

As programming languages and platforms mature and fads of the moment fad away, it’s becoming more and more common for developers to run into old code. Maybe even code that’s predates code standards in a given language. This is certainly the case in my day-to-day.

While it’s relatively straightforward to install IDE tools to format you code properly and keeping it simple can be easy when you don’t have to consider a decade of backwards compatibility. It’s less obvious when you’re not working with a clean slate. What do you do when you encounter ugly code? What about when repeating yourself it the shortest path to a complex fix? Should you re-write an entire library because doesn’t hold up to code standards?

I propose adding LIBTYFI3 to the lexicon of idioms.

If the code is ugly and misformated. Fix it4.

If you’re repeating yourself or having trouble keeping it simple. Step back and assess what you should actually be refactoring. You’ll probably learn something about the application in the process.

If variable and functions are named poorly. Fix them.

If comments are missing. Add them!

If tests are missing. Add them.

In other word, if code is not holding up to current standards, rewrite as much as possible as long as it’s tangentially relevant to your task.

Obviously this is going to take more time than a quick fix. Perhaps, if your task is truly a critical fix you should skip some of these steps. But stakeholder should understand that legacy projects are complex and taking time to do it right will lead to a better product in the long run.

1 – Lest you question my Dad’s parenting choices, I can assure you small town Northern Ontario truck stop restrooms in the 80s/90s were not nearly as sketchy as the image you probably have in your head from movies and TV.

2 – This rule did not apply to toilets.

3 – Libby-fi? Sounds like some poorly thought out Liberal social network.

4 – But please for the love of god, isolate style from functional fixes in their own PRs.

Categories
Culture Web Development

My Coding Origin Story

ascii picard

Earlier today Ben Halpern posted a bit about his coding origin story on dev.to. I thought it might be interesting to share how I got my start.

Growing my family was not an early computer adopter. Computers were expensive and my parents were endlessly frugal. So I don’t share the common origin story for a lot of nerds of my generation, I never noodled around with a Commodore 64 or anything of that era.

My first exposure to computer programming was writing simple routines in Logo on an Apple IIe in grade 6. Logo was very simple, but super valuable as a fundamental building block. My experience taught me the basics of looping and the idea of printing things to the screen and it certainly piqued my interest in programming at an early age.

The next code adjacent thing I remember doing was mucking around with the Windows 3.1 autoexec.bat file on my grandfather’s 386 laptop (which he had left with me for some reason), probably circa 1993. Pre-Internet I have no idea how I knew this was a file I could edit, what it did or what to do with it. Perhaps I read the MS-DOS help files. One thing I did learn quickly is that this file had the power to stop Windows from booting. And this actually taught me the important lesson of remaining calm in the face of utter, self-inflicted code disasters.

My coding memory is a huge one. It happened when my family finally got our first PC, a Compaq Presario 486, probably around 1994/95. Again, I don’t recall exactly how, but I soon discovered BBSes and door games. My favourite game by far was Legend of the Red Dragon (playable here). At this same time, I’d started to dive in to qBASIC. I poured through the source code of the demo programs and read through the included documentation. For some reason I decided to attempt to recreate a local version of LORD in qBASIC — except Star Trek: The Next Generation Themed (of course). I built an ASCII interface, ASCII procedural map generator, random encounters and a rudimentary combat system, a town with shops (armour, weapons and potions), system for tracking progress (goal, xp and levels) and that sort of thing. I retrospect, this seems like a monumental task, something I’d never even think to attempt now. With this experience, I had essentially taught myself all the fundamentals of programing I still use today: procedures, variables, control structures, logic, etc.

My first experience with HTML is probably a little more similar to other developers of my generator — Geocities and Netscape circa 1997. I distinctly remember the first website I built on geocities.com, a Star Wars: CCG “bad trader” list — basically a blacklist of people who’d screwed my friend Jon out of cards online — an HTML table on a repeating star background (groundbreaking stuff!). Having worked with the pre-written example programs source code that shipped with qBASIC years prior, the leap to view source on every single website came naturally. And by this time there were already well developed resources for learning HTML online.

I’m actually a little less certain about my introduction to PHP. I think it may have been Movable Type of my first domain (leggomyeggo.net).

Sprinkled here and there is some formal education and the rest — as they say — is history.

Categories
Web Development

Is Modern Web Development Too Complex?

As someone who has been in the industry for nearly as long as the industry has existed, the trajectory of modern web development is concerning. Oftentimes the “modern” tools seem overly abstract, interdependent and complex. The “modern tools” I’m referring are a range of technologies designed to improve development processes: dependency management (NPM, composer, etc), frameworks (react, laravel, etc) and “DevOps” in general (docker, AWS soup, etc). Slot in any trendy solution of the day.

Or to put it another way…

It’s not that there’s necessarily anything wrong with any of these tools. It’s more that I’m concerned that they are hurting our approach problem solving.

Early this week a Hacker Noon article — Understanding Kafka with Factorio — from a few months ago made it’s way into my work slack.

This post is a prime example of the way of thinking that concerns me the most. For starters, comparing a web development problem+solutions to Factorio — one of the most complex and difficult RTS’ to date — is very telling in and of itself.

The author starts by setting up problem that should be familiar to many developers.

Let’s say we have three microservices. One for mining iron ore, one for smelting iron ore into iron plates, and one for producing iron gear wheels from these plates. We can chain these services with synchronous HTTP calls. Whenever our mining drill has new iron ore, it does a POST call on the smelting furnace, which in turn POSTs to the factory.

So, we have 3 services that depend on each other in a linear fashion. If any one of them fails, the entire system breaks. There appears to be zero fault tolerance and that could be bad.

Enter Kafka…

With Kafka, you can store streams of records in a fault-tolerant and durable way. In Kafka terminology, these streams are called topics.

With asynchronous topics between services, messages, or records, are buffered during peak loads, and when there is an outage.

Neat.

But hang on. Now we have four points of failure instead of three! In fact, we’ve now introduced one single point of failure. If the Kafka layer fails the entire system fails.

Why should we trust Kafka more than we trust the 3 microservices, we built? Are there ways to make the individual microservices more fault tolerant?

Why not both? The author of this post seems like a solid developer who knows what he’s doing. Perhaps the underlying assumption is that our microservices are already as fault tolerate as they could possibly be and we should add Kafka as an additional layer of fault tolerance.

We’ve introduce a fourth complex and specialized technology into the stack. Now we need a Kafka specialist on our team…

This post is not meant to be an analysis or critique of Apache Kafka.

It’s meant to provide an example of the way modern web developers tend to solve problems. We tend to build or implement complicated systems that provide an abstraction layer above problems, without adequately addressing the root problem.

I’m quite concerned that we’re fostering a generation of web developers who are building houses of cards on top of houses of cards, to solve problems that don’t fully understand, without properly addressing those problems.

Categories
Tips & How To's Web Development WordPress

How to Keep Your New WordPress Site Running Smoothly

So you just launched a WordPress site for your business, everything is up and running. Pages load quickly, SEO is better than ever, you paid your development team. Now you’re all set for the next few year, right?

In an ideal world, this would be true. Unfortunately, the Internet is a dangerous place and software is not perfect. With WordPress presently powering 1/4 of the Internet, it is a huge target for hackers and internet miscreants. Left untouched, your site is almost guaranteed to become infected by malware at some point in the future.

Click “Update!”

Clicking that “update” button in the WordPress admin is the single most important thing any WordPress site owner can do. In Windows or macOS these types of security updates can seem like a pain, annoying nag messages that you always dismiss immediately. While these updates are important for desktop computers, in reality, your desktop machine is typically removed from outside attackers by 1 or 2 levels of routers. Your website on the other hand has to be accessible to the broader internet in order for the public to have access to it.

One fact that might be overlooked if you’re unfamiliar with software development is that the vast majority of security patches are in response to a reported issue. What this means is that, potential attackers already have the information to create mass exploitation tools by the time you see the update notification in WordPress.

To put it another way: In my time working with WordPress, I’ve never see a compromised WordPress site that is totally up to date with all updates.

Is It Safe?

One concern that causes many computer users to put off software updates is the fear that something will break. While this fear is not totally unfounded, most software updates are safe, most of the time. When dealing with WordPress updates, you’re looking at new code from different sources. Core updates come from the WordPress open source project, these updates are all vetted by professional developers. Plugin updates are submitted by the plugin author. The experience level of these authors varies widely, they could be hobbyists working on the weekend or large teams of professional developers.

So is it safe?

Minor WordPress Core updates are safe. The minor updates are the updates where the main version number (ie. 4) does not change. The WordPress team takes great care to ensure that updates do not break anything.

Major WordPress updates are probably safe. Again, the WordPress team has a great track record of building in backwards compatibility. So, your site probably won’t break. However there are two caveats. 1) Major features in the WordPress admin will likely look and/or act differently; 2) Some plugins may stop working.

Plugin updates should be safe, but it depends. With a few notable exceptions, most well written plugins will update without issue.The same rule of thumb about major and minor updates apply to plugin updates, a major version update is more likely to break something. A good WordPress site developer will only install plugins that they’ve individually vetted, I never install plugins for my clients that I do not trust.

Be Proactive

A number of plugins and security solutions have started to become available for WordPress over the past few years. They are essentially virus scanners and firewalls for WordPress. By setting these up, you should be able to fend off additional threats or at the very least disable malware if it happens to make it onto your site. A Google search will reveal many good options. My current go to plugin is Wordfence security, I install it on all new sites. I like it because it works well out of the box and it typically does a better job finding malware than the other plugins I’ve tried.

Conclusions

As developers, I think we often do a bad job communicating the importance of ongoing maintenance and security. After all, it’s a little embarrassing to have to concede that this great product you just spent weeks of time and a good chunk of money on, is a giant bullseye for internet miscreants. It can seem like a slimy up-sell to suggest a maintenance contract.

In reality, if you’re comfortable reading and digesting release notes, you should be able to handle keeping WordPress up to date. If you’re less of a tech-DIY person, you may want to get in touch with a developer.

One more thing: Backups

Backups are always a good last resort. I didn’t mention them in this post because backups are typically a poor malware recovery solution. Two main reasons: 1) The type of malware that affects WordPress rarely corrupts content; 2) it can be difficult to pinpoint when a malware infection started, so you won’t know which backup to restore to.

Categories
Web Development

The Problem with NPM

Whenever you run `npm install` it generates a local, project specific /node_modules/ directory with literally 10s of thousands of files and folders.

Why?! WHY?!

I understand that javascript is a simple scripting language, missing many features that are baked in to more traditional languages like PHP and friends.

I understand that many node modules are a work in progress, that are updated frequently.

I don’t understand the benefit off having these packages sitting inside each project directory.

I understand that disk space is cheap and it doesn’t really matter.

…