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 essay 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
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

Do we need an IMDB for websites?

Do we need an IMDB for websites? Over the course of my 15 year career as a web developer, I’ve had a hand in dozens (maybe hundreds) of websites. A handful of the top sites I’ve worked on are seen by millions of people; and much like the clapper loader, child wrangler or caterer on a big budget Hollywood film, no one would be the wiser.

Unlike an obscure Hollywood professional, the behind-the-scenes work of a web developer is rarely credited anywhere. Occasionally, our names will be buried on an “about us” or “team” page no one ever visits, sometimes we’ll leave fingerprints in an HTML comment. But the fact that’s there’s no generally recognized method for crediting the hard work that goes into web development (or other creative professions for that matter)… is a little weird and disheartening.

For coders — who don’t have pretty pictures and mockups to post in a fancy shiny portfolio — the de facto industry standard for building reputation and gaining attribution seems to be a github profile. In theory github can be a low friction source to evaluate the work of a potential hire. However, in practice there are many reasons an excellent, experienced developer might have a sparse github profile. For starters, github profiles are public and paid work is usually the intellectual property of the client paying for it, not open for public posting. Secondly, coming up with unique ideas for projects, or extra free time to contribute to existing projects can be a daunting task for a developer who’s busy balancing hobby projects against paying bills and having a life. A sparse github presence should not be seen as an indication of… anything, really.

The IMDB Model

IMDB has a lot of features, some of which might or might not make sense for website listings: user ratings, trivia, things like design and feature history, etc could be interesting for larger well known sites. But the feature I’m most interested in for the purposes of attribution is the “cast and crew” listings.

Essentially, listing every “crew” member of a web team would be a great way to present the type of recognition that I believe people in the industry deserve.

Potentially, more importantly though would be the ability to reference an individual across all the projects they’ve ever worked. On IMDB when you click through to a crew member’s profile you can quickly see all the projects they’ve ever been a part of. This could give employers and colleagues a unique view into someone’s body of work and career progression. A listing like this could fill the gaps between a resume and a github profile. If it works for Hollywood, I don’t see why it wouldn’t work for Silicon Valley.

Humans.txt

In 2011, an organization formed to promote the idea of a included a humans.txt file with all websites.

It’s an initiative for knowing the people behind a website. It’s a TXT file that contains information about the different people who have contributed to building the website.

I recall some minor buzz around this initiative and it looks like they had aspiration to make it a W3C standard. But the buzz seems to have died off very quickly, their website hasn’t changed much since mid-2011.

Humans.txt is the ideal vehicle for the type of information an “IMDB for websites” would need to know about the development team. The service could use humans.txt as a starting point to validate a website, then parse the file itself to suck in data for the listing. From there, unique individuals could be cross referenced using their twitter profile.

That’s it

I’m sure there are a tonne of challenges, as well as interesting directions and potential features, etc…this is admittedly not a fully formed idea.

What do you think?

(crossposted to medium)

Categories
Web Development WordPress

Dear WordPress Get Your 💩 Together

Dear WordPress.org,

Get your shit together!

It is 2016, there is no excuse for allowing any plugins with insecure code to make their way into the plugin directory. Full stop.

The story about Custom Content Type Management stealing admin credentials and other shenanigans, is utterly pathetic. I’d bet this incident is just the tip of the iceberg.

If there is a plugin review process, I have seen no evidence of it. In my experience, plugin updates are made live immediately after updating the repo, regardless of if the plugin has a site crashing bug or a security issue.

The plugin directory situation has gotten so bad that people are starting to avoid installing free plugins.

Fix it. Please.

Sincerely,
Everyone who loves WordPress

PS. I stole the emoji graphic from the great article on The Oral History of the Poop Emoji.