Make Code Great Again

There’s very little code that’s completely independent of other code. A simple “hello world” in your favorite language relies on the code powering your language. As your objective gets more complex, you start relying on more and more code to get things done. Your code depends on other code, which depends on other code, which … you get the idea.

An unfortunate side-effect of code dependency is yours inherits the flaws of other code it relies on. As a result, your code sucks because the code it relies on sucks. Instead of getting on a soapbox about poor code, since we’ve written and released our fair share of it, lets focus on how you can make code great again.

 

YOU can make code great again

Recently I’ve been working with Node.js and MySQL. When I needed a dump of the database, I leaned on a module called mysqldump to get the job done. It exports queries that can build and populate the database as a .sql file.

While the process worked flawlessly, there was very little flexibility in how the dump works. You get a file. You may pick the location and the name of the file, but that’s it. It must be a file. This worked perfectly for the module’s author, but other users have different needs and environments to work in. In my case, my application is running on an ephemeral filesystem, which means files don’t stick when the server shuts down. Storing the dump on the server doesn’t work for me.

Great module.

any plans to add an option to save the mysql dump to s3 instead of to local disk file? looks like this might be changed by expanding line 151?

Alternatively, could you have on option to turn off the file creation on line 151 and instead return the datadump in the callback so the user can do the s3 upload themselves?

Tim

Source: https://github.com/webcaetano/mysqldump/issues/7#issue-153757451

Apparently I’m not the only one with the same problem. Tim wanted the content of the dump instead of a file written. He even identified the line of code where the file was being written.  Four lines of code later, the module can hand you the dump in a callback instead of writing the file.

Trump Approves This Code

“You made a pull request and it was accepted. Cool story, bro.”

Thanks 🙂

Lets focus on how to make code great again, though.

  1. Use Other People’s Code
    Seems like a moot point since most code relies on other code, but you need to make a conscious effort to use what others have written. Before you start writing code, check if someone else has written something you need.I could have written a dump module myself, but it’s likely to have had all sorts of bugs in it. The great thing about other people’s code is at least one other person is using it. The extra users will help unearth flaws in the code, making it more bulletproof.

    Making code great starts with consolidation of effort. Instead of everyone writing their dump implementation, we focus the energy on making a good one. We can write wrappers around it for different use-cases, or tweak the core to improve how it works, but we don’t get ahead by having ten versions, each with their own peculiarities and bugs.

  2. Share Your CodeIf the author didn’t share his module, I would either be writing my subpar version of the module or living with the bugs its bound to have. For example, someone noticed mysqldump didn’t terminate the connection to the database when it finished the dump. Despite an existing test suite and continuous integration, the author never noticed it. It was a really trivial issue though; one line of code added and the problem disappeared.

    Sharing the module gave others the chance to use it and discover the bug. The solution being shared also allowed others to get the fix instead of having to discover and fix the problem on their own.

I wish I had more insight to offer, but I’m still working on these two: intentionally using more of other people’s code and sharing more of mine. I’ll write more on the subject when I have a better understanding of how to make code great again.

Laptop Failure Playbook

screen-repair

Something in my laptop died a few days ago. I’m hoping it’s a simple change and it’s back to its (very) old self. Thank God I was able to get my hands on an alternate machine to use in the interim.

While the scary prospect of not having a machine to work from was avoided, I had to go from a fresh installation of Windows 7 to something that resembled my work environment. No easy feat since this particular machine is a culmination of software and configurations from the last six years.

Continue reading Laptop Failure Playbook

CJS-Task 0.0.8 Release

The JavaScript ecosystem encourages creating and using small utility functions and libraries.

While this encourages code reuse and interoperability, you’re left with the responsibility of writing glue code to marshal oft misaligned paradigms to accomplish your objective.

CJS-Task was created with the desire to bring simplicity by acting as a high-quality glue between all the pieces you’ll use.

How? A few tricks.

Continue reading CJS-Task 0.0.8 Release

The First 419 Guy was an American Child

One day, however, a new sort of ad appeared in the pages of several dailies: an appeal from a certain Prince Bil Morrison.

The prince was of noble birth and hailed from the far reaches of Nigeria. All he wanted was some American pen pals.

So moving was the wording of the ad that the papers had published his mailing address free of charge. Should not the poor prince find some good old American correspondents?

Continue reading The First 419 Guy was an American Child

ES6 is Over-Engineering JavaScript

Don’t let acronym fool you. npm is more than node’s package manager; it’s the package manager for all of JavaScript.

It houses great big libraries like React, Electron and socket.io. It also contains itty-bitty snippets of code. Code so small you’d expect their behavior to be native to the language.

This has turned JavaScript into a language with a small, serviceable core and lots of useful extensions available in npm.

ES6 is expanding the core of JavaScript.

Not by adding things that currently don’t exist in the JavaScript + npm realm, but by introducing new ways to do things we could already accomplish before.

This seems like a very bad idea to me.

Continue reading ES6 is Over-Engineering JavaScript

JavaScript ES6 is Doing Too Much

Swiss Army Knife

This is a Swiss Army Knife. The Handyman, to be precise. According to the site, it has 24 functions. Can opener, scissors, nail file, pliers, wine opener, bottle opener, wood saw, toothpick, nail cleaner … the list goes on.

Conceptually, it’s really great to have one thing that does so much.

Realistically, Swiss Army Knives have not replaced the need for single-purpose devices in any of those categories.

It’s doing too much to be good enough at one task to replace a device crafted specifically to solve a single purpose in any of those categories.

I fear ES6 is introducing tools that make JavaScript do too much.

Continue reading JavaScript ES6 is Doing Too Much

Deeper

Have you watched Inception?

kvudiamroxpkjgivyqja

 

It’s a really interesting movie where people can enter the dreams of others. I don’t wanna ruin it for anyone but the ability to enter dreams is infinite.

You can enter the dream of someone who is sleeping in a dream. Dream within a dream.

My first dream was to design for the internet.

The moment I saw the Cartoon Network website in the late nineties, I knew that’s exactly what I wanted to do. I learned how to use Photoshop, Illustrator, picked up HTML + CSS, designed MySpace pages and built a static website.

The static website was the accomplishment of my dream. I designed a website, coded it up, published it on the internet and got paid handsomely for it.

Almost immediately after, I was unsatisfied.

Continue reading Deeper

Expensive

I have nothing but respect for game developers. What they create are nothing short of technical feats and they tend to work with anemic budgets.

If you think a second is fast, bear in mind the benchmark to reach in game development is processing and rendering sixty times a second! To put this in perspective, most websites are unable to process and render sixty times a second despite doing far less work.

Imagine how much code is powering this League of Legends fight

 

How do game developers accomplish these awesome feats? They gain a working knowledge of the environments their games run in and figure out how to take advantage of it to accomplish their goals.

More practically, they identify what makes it impossible for their code to reliably run sixty times a second. The source of the limitation is labeled expensive and they use their knowledge of the environment to create clever ways to workarounds.

As web developers we can learn a lot from this practice. We need to understand what keeps our websites from running smoothly and work around them.

Continue reading Expensive