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”
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”
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
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”
Per annual tradition, it is time for the WordPress.com 2015 in review!
I am going to cut the chit-chat this year and say that 2015 has been a hard year in blogging for me. There have been so many topics I wanted to write on but never finished, was unable to do so (usually lack of time), or lacked the willpower. Further, I have gone through and deleted many of my older, pointless posts in order to refocus the blog and make it a tad more professional (that was one of the reasons behind choosing the current theme). If it seems as if the posts have been slower coming this year, they were. I personally am not happy with the slow schedule I have had, but it was what it was.
That being said, I think the posts I did publish were some of the best quality posts yet. I am pleased with how my posts turned out, especially the tracking cookie and ethics of selling open-source posts. I have slowly but surely been developing my style, perspective, and methodology for my posts, and this year has had the most “mature” form of those qualities yet.
In closing, I wish to thank you, my readers, for supporting this blog, occasionally commenting, putting up with the slowness, sharing with your friends/random people on the internet, and all the support requests. Though I might be slow to reply sometimes, your support means a lot to me. This outlet for my mind’s ramblings has meant a lot to me and it is because of you, for you, do I keep writing. Thank you so much.
Here is to the year that is 2016. May our lives be filled with much joy, surprises, good things, and less stress as we venture into the unknown and into a time “no man has gone before”.
Today is Christmas Day. All around the world people are visiting their family and enjoying spending the time with the ones they love. Children are excitedly opening presents, wondering what could be inside. Music is being played from the radio, CDs and digital devices. People are out feeding the homeless and providing cheer to the hopeless.
It is also the day Christians celebrate the second most holy day of the year: the birth of the incarnate Jesus Christ, when God came down to earth as a man to live with men so He may take away our sins and give us life eternal with God the Father by being crucified and rising from the dead three days later.
I do not make my faith hidden. I have stated many times I am a Christian and firmly believe in God. I may not mention my faith in every post but I do not shy away from making my faith known.
In Matthew 28:18-20, before ascending into Heaven, Jesus gave the following commandment called The Great Commission:
Continue reading “Merry Christmas”
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()”
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
<button> with a
name attribute of “submit” (
name="submit"), it will override the
.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!