As I was coming up with a cool little blog topic to start the year, I kept stopping and scrapping this and that idea. The reason I was experiencing difficulty formulating my thoughts properly was not a lack of material. The
real cause for my hangup was that I felt I needed to be original, non-trivial and most of all, I just had to be correct.
This last thing was fatal, I now realize. It prevented making any sort of rational investigation. I needed to permit myself the necessary latitude to try something new and fail. As the adage goes, Nothing ventured nothing gained. Once I got around this hangup, I could properly begin to write again.
I feel that this is a very dangerous tendency. It takes courage to make something new. It takes more courage to admit that something you made or thought was wrong and correct that mistake.
Luckily the scientific method makes it fluid to pivot opinions based on new evidence. As programmers, developers, engineers, we are nothing if not scientists, and we should always be using the scientific method. Always.
It’s OK to be wrong sometimes
As an example of this, I recently came across a blog post written a couple of years ago that stated JavaScript is a bubble. Gritting my teeth, I proceeded to read the article and then the predictably contentious comments.
The article was of course wrong. Reports of JavaScript’s demise had been greatly exaggerated. What I found interesting was that the article also linked to a follow-up by the author which offered a retraction. I thought this was cool, because it showed that the author was human, and that they were capable of recognizing their errors.
I imagine there are many blog posts, articles and lots of other types of original content that probably never see publication because the author was fearful of not being somehow 100% right. My feeling is that for personal blog posts, we should be embracing the unknown and have the courage to expose our own ignorance. I would hope to be corrected in a kind but firm manner if and when I make a technical mistake or have an incorrect concept. It’s what makes feedback a valuable gift, and I would hope to do the same for any colleague or fellow blogger. It’s the only way we can learn and grow.
Here’s to making lots of mistakes in the new year. Cheers!
Spent a nice couple of weeks on holiday in Texas visiting Austin, San Antonio, and Del Rio. In between catching up, eating, and general merrymaking, I learned a neat little trick to better interpret and protect Google Analytics (GA) data and traffic.
Most of the time you want your site to only record outside hits, in other words traffic that is not from your own (possibly numerous) visits. Naturally this applies to businesses as well as blogs. Secondly you also want to make sure your site is the only one actually generating the hits to your tracking code.
The solution to both of these issues is to set up custom filters1 in GA.
Find your IP address. (Google “My IP” for your public IP address).
Log into your GA dashboard.
Select Admin tab and select the account you wish to manage.
Under Account column, select “All Filters”.
Press the “+ Add Filter” button.
Name your new filter, Own IP or something similar.
Filter type should be left “Predefined”.
Select filter type “Exclude” from dropdown.
From the “Select source or destination” dropdown menu, select “traffic from the IP addresses”.
From “Select expression” dropdown, select “that are equal too”.
Finally, enter your IP address and save.
If you have a larger company or website, naturally you would wish to set up a domain-type of filter3.
Include only real traffic
A second type of filter that may be advisable in order to prevent possible tomfoolery is one that makes sure only actual traffic from your site is being recorded.
It is well known that you can easily find and read the GA tracking code using the developer console of any modern browser, unless, you know, it is hidden as an environmental variable. Although there is little real danger from having this code publicly available, it is possible that some Internet ne’er-do-wells may utilize it to spike traffic at you. It sounds outlandish, but this fake traffic could ostensibly screw up your reporting and possibly induce the webmaster (i.e. you) to investigate the sites that are generating the hits, (a very poor advertising tactic indeed)4.
I actually saw this type of activity on a previous blog I held, mostly from Russian and Chinese sites, so there you have it.
To make sure your traffic data is clean and accurate, simply create a new custom filter that only accepts hits from your desired domain.
Again, (from Admin on GA dashboard,) select your site.
Click “+ New Filter”.
Name it Defence against the Dark Arts or something similar.
Select “Custom filter”.
Select “Include”.
Under “Filter Field” dropdown select “Hostname”.
Enter your desired domain name. Use backslash to escape special characters, like so: nchristiny\.github\.io
Save your awesome new filter.
Enjoy your clean GA data.
As always, any feedback or questions are most welcome. Feel free to contact me via Twitter or email. Thanks for reading.
It is pretty straightforward to plunk in a source file, URL or text input into Nu Html Checker and validate your markup to see that it cuts mustard. I recently reviewed the HTML for this site, and I have been generally obsessing about it and HTML outlines.
HTML Validation
Why validate?
Like any code HTML gets sticky quickly if you are not adhering to guidelines as you craft it. Guidelines matter and they exist for a good reason. If you ignore validation as you throw up your pages, errors are likely to accumulate until a catastrophic error will force an investigation with its attendant costs. This is not a case of technical debt, rather of laziness or worse, indifference. The case for validation is that if you have been making your pages validate as they go up, then during inevitable catastrophic failures you can use the validator as another useful tool to narrow down and fix a bug rather than as a source of noise.
Accessibility
HTML validation and outlines create structure to your website and this makes it organized logically and legibly for screen readers. This is the prevailing wisdom as I understand it, so validating and making sure your HTML outline makes the most sense for accessibility concerns. From https://validator.w3.org/nu/about.html:
There are some markup cases defined as errors because they are potential problems for accessibility, usability, interoperability, security, or maintainability because they can result in poor performance, or that might cause your scripts to fail in ways that are hard to troubleshoot.
Along with those, some markup cases are defined as errors because they can cause you to run into potential problems in HTML parsing and error-handling behavior—so that, say, you’d end up with some unintuitive, unexpected result in the DOM.
Validating your documents alerts you to those potential problems.
Apart from HTML validation, there is an online accessibility validator which can help determine what else may be missing in terms of accessibility.
Plain old correctness (in spec)
It just feels right. Experimentation and breaking the rules are admirable qualities of your friendly neighborhood hacker, however there certainly is a time and place for experimentation. Folks, it is cool to rely on the established spec for serious projects. Pinkie-swear.
Knowing when to look the other way
Building on the previous statement, sometimes it is OK to just overlook certain things. For example, for my page the only things that currently show “error” or “warning” are for the Creative Commons License, which are relatively minor gripes.
To illustrate a great point, this blog post by Coding Horror’s Jeff Atwood nails the ambiguity: Learning the rules of the validator, even if you don’t agree with them, teaches you what the official definition of “valid” is.
HTML Outline
An document outline provides a graphic representation of the sections of your markup as they relate to each other, which is fundamental to present the page correctly to the user. According to spec, the relationships of these elements leads to the structure of the document and its outline. There are arguments against the effectiveness of the new HTML5 outline guidelines, but I am using them in conjunction with the traditional h1 - h6 scheme as this is backwards compatible.
Here are a couple of tools available for working with HTML outlines:
The validator complained that there was a Bad Value, and that “Illegal character in query.” This was the suggested code snippet auto generated by Google Fonts. After a little search it turns out the pipes ‘|’ were responsible. I switched those to %7C to resolve the encoding issue.
I had the aforementioned errors and warnings about the Creative Commons tag which also happens to be auto-generated. I decided to sacrifice that in the interests of sanity.
Finally for my outline, there were some rather embarrassing header mix ups that I promptly fixed, making my HTML outline tree a lot smoother. There were also “Untitled Section” labels on my sidebar and footer sections. This made me a bit leery due to accessibility reasons1, so I researched how to put invisible headers on them for screen readers. This solution that works as of this writing was found on this Stack Overflow answer:
The headers are now invisible, but allow screen readers to see them. Overflow hidden is to hide scrollbars.
My final HTML outline:
1. Sidebar
1. Sidebar Nav
2. Code or Die live to code
2. Early Coder Reading List
1. Beginner:
2. Intermediate:
3. Advanced:
3. My Sublime Prefs
1. User Preferences
1. Font
2. Theme
3. Packages
4. Key Bindings
2. Bric-a-Brac
4. Setting Up
1. Basics
2. Setup
1. Install Command Line Tools
2. Configure Sublime Text from the command line, subl.
3. Bash profile and UNIX environment
4. Homebrew
5. Install sqlite3 with Homebrew
6. Install postgres with Homebrew
7. Install a Ruby Manager with Homebrew
8. Install Ruby using a Ruby Manager
9. Install git with Homebrew
10. Install node with Homebrew
11. Install Ruby gems
12. Install bash using Homebrew
3. Conclusion
5. Hi MTV
1. Licensed under Creative Commons
Perhaps it seems a little nit-picky but I learned quite a few new things for such a cursory glance into the spec. Learning to validate you HTML is important and the less these practices seem like esoteric nuisances, the more I can learn to do things correctly. If at some juncture I aim to transgress, then I know what exactly I am breaking and why.
HTML5Doctor “For accessibility reasons, we recommend each sectioning element have a heading, even <aside> and <nav> … If you don’t want these headings to be visible, you can always hide them with CSS.” ↩