A programmer’s nit-picks

Programmers are notoriously nit-picky. We have opinions, stances, and preferences on just about everything and tend to get into frivolous (and often heated) arguments and discussions about our nit-picks. Compiled language vs. interpreted language? Nit-pick! Tabs vs. spaces? Nit-pick! Braces on same line or new line? Nit-pick!!!

In fact, programmers are so passionately nit-picky we invented a process to force our nit-pickyness onto others when they contribute code to our open source projects: code reviews! We even prefix some of our comments with “Nit:” for emphasis! (Do understand I am using hyperbole here. Code reviews are a good thing and I am grateful for them.)

Lately I have been reading the book RailsSpace (1st edition website) to expose myself to the Ruby programming language, Ruby on Rails, and MVC. I am not actually running any of the code, simply reading the book, code and all. It has been rather interesting and I may have to write a post on the experience when I finish it.

Continue reading “A programmer’s nit-picks”


Experiencing technical debt

In many metrics, I am young. I am 21 years old and fresh out of technical college with my A.A.S in website development. I am young in world and workplace experience as well as wisdom. I physically look young. I am told I look, on average, approximately two years younger than my current age (this has been going on for at least four years now). I am a young programmer, having only been a part of the world of code for three years. My coding style, abilities, and knowledge is limited. I am young.

However, though I may be young, in many ways I am not young. I have coding knowledge that earned me the nickname of a reference guide among my internet friends. I have coding abilities that, even as a one year programmer, impressed a then-four year programmer.

I have also seen with my young eyes sights often only experienced developers speak about. I have experienced within my limited experiences events only programmers of age understand. I have knowledge of things I probably did not need to know and sometimes wish I did not learn until later.

One of those things is technical debt.

Technical debt, in layman’s terms, is simply junk that exists in a system that should be cleaned up because it is a mess, is getting out of hand, and is giving you a headache but has yet to be dealt with. It may lie in the build pipeline, in code, in graphic creation, in documentation, in tools and workflow. Wherever it is, it is something that is not good and should be corrected to meet modern standards, guidelines, or ideals. Yet nobody has done anything about it for so long (for a variety of reasons) that the debt has become part of “it is just how things work around here.”

Continue reading “Experiencing technical debt”

Semantic HTML5 elements and the element

Talk about a confusing combination.

While working on my capstone early in the morning (something I should never do but keep doing it anyway) on 16 October, 2015,  I noticed the test <h1> headers I placed on a page were smaller than the <h2> elements and roughly the same size the <h3> headers! Despite not possessing complete clarity in thinking and logic, I decided to hunt down the culprit. Because the strange phenomenon was occurring in Firefox, Chrome, IE, and MS Edge as well as mobile browsers, I started the hunt by searching my site SCSS for something that could be causing it; perhaps I had written an overzealous selector. Though I surprisingly could not find any rogue styling, I was determined to find the cause. That was when I remembered something: I had dealt with certain headers being smaller than others a long time ago on a different project. I also remembered the culprits: the semantic elements newly introduced with HTML5 to help structure and layout a page (instead of using <div>s everywhere).

I quickly changed all instances of the new elements to “plain old” <div>s and reloaded the page. Suddenly, the faulty headers snapped back to their proper size. With the issue solved, I turned off my laptop and went to bed wondering what exactly was going on and what could be done to remedy it.

The next day I looked into the matter, whipping up a demo page to compute the font sizes of headers when contained in the various semantic elements and compare it to a div wrapper (as a baseline) and a semantic element nested in a semantic element. You can find the demo on CodePen. Throughout the rest of this admittedly more observational post, I will be frequently referring back to the demo as I discuss my findings, so keep that tab open! 😉

One thing I should note: I could be totally wrong about all of this. I am not an expert in any one topic or area. This is merely my deduction based on observations and experiments. If you do happen to be an expert and have an accurate explanation, feel free to state it and teach me a thing or two!

Continue reading “Semantic HTML5 elements and the element”

JS – Avoid duplicating addEventListener()

I see this mistake way more often than I should. Someone adds an event listener with an anonymous function callback to an element (like a button) then puts it in a a function that may get called multiple times. While this very common setup may seem harmless, it can create some serious issues.

The problem is this setup will add multiple listeners to the element, a new one each time the function is called, meaning three calls will add three listeners, then when the event is triggered the callback will be run three times. This JSFiddle demo clearly shows the scenario in action.

Continue reading “JS – Avoid duplicating addEventListener()”

Watch what you name your form inputs!

I came across this little snafu yesterday while working on my capstone, which I was able to reproduce in all the major browsers.

If your form has any form of <input> or <button> with a name attribute of “submit” (name="submit"), it will override the <form>‘s JavaScript .submit() method and throw an error when you try to call it (as I do in the same code above)!






Internet Explorer 11

Changing the attribute’s value to anything else, even “form-submit”, will prevent the method from being overwritten. So be aware of what you name those inputs! They could introduce some pretty nasty bugs! It took me a bit to track this down because it was behavior I did not expect!


Notepad.exe in HTML5 and JavaScript

On the morning of 10 October, I tired of working on my capstone and had finished contributing a patch to an open-source project, I decided I needed a small, fun, project to quickly create as a change of pace. A few minutes later, either inspirational or pure randomness stuck: recreate Windows Notepad.

Continue reading “Notepad.exe in HTML5 and JavaScript”

WordPress – Load enqueued JavaScript in async or defer

Lately I have been working with WordPress, creating a complete website (even original theme) with it for my college capstone. Generally, things have been fair but there have been some things I have wanted to write a rant-y blog post about (but will not because I value my readers too much 🙂 ). One of those things is loading JavaScript into a site.

According to the documentation, wp_enqueue_script is “the recommended method of linking JavaScript to a WordPress generated page.” So as a good developer I have used this for loading my JavaScript. Aside from the rather crazy parameter order and defaults, I was quickly irked by the inability to load scripts asynchronously. After much searching though the WordPress docs and various programming sites, I came across the following article which uses a simple hash to denote async scripts, use the clean_url hook to filter all external URLs for JavaScript files (although file extensions are only hints) and add the async HTML attribute. However, the function was a bit too naive and limited for my taste (what if I wanted to defer a script?), so I wrote my own function using the basic idea of that snippet, which is the topic of this article. 🙂

Continue reading “WordPress – Load enqueued JavaScript in async or defer”