I'm an experienced web developer, software engineer, and leader. Welcome to my blog. If you need to reach out you can continue the conversation with a tweet to @geedew. I hope you find what you are looking for here. You can also find me on Github and StackOverflow.

The Case for Critical Assets

When it comes to first impressions, it can be said a website is made or broken by them. A modern website that relies heavily on scripting is likely self inflicting a performance hit. This hit can be caused by the generic advice given for speeding up a website, ironically. Many web speed tests give an immediate failing grade for not using a content delivery network (CDN) for every single one of your assets. But in the case of critical scripts and styles, this can be the exact wrong advice.

Critical scripts and style are the assets that must load prior to effectively loading content. For instance, a site might use Modernizr to sniff for features to further load content or other scripts. It might use jQuery to create DOM elements and place them on the page. It also might use @media queries to alter, import or change the layout of the page. If any of these situations exist, a new or returning user will have to wait for that file to load on the page prior to being able to view any content. I’m not going to argue if a site needs to be doing those things first, but if it is, then it’s going to cause a ‘hiccup’ for first time rendering. A cached asset may negate this on further loads and that’s why caching and cache control is a good thing to use. But this does nothing to help a first impression.

[caption id=”attachment_571” align=”aligncenter” width=”500”]DNS lookup times are killing time DNS lookups are killing time[/caption]

Read More

Javascript Frame Busting or Proper Apache Headers

I’m a fan of David Walsh; whom recently posted a snippet of JavaScript to block an iFrame.

1
2
3
if (top.location != self.location) {
top.location = self.location.href;
}

[caption align=”aligncenter”]View this on gist.github.com[/caption]

But you can and should invest in a better solution. As one of the solutions pointed out on Stack-Overflow shows you can add the SameOrigin header at the server level. It works and works well. You can even allow certain pages over others.
A quick Apache solution looks like this:


  # ...
  
   # Allow some urls, block all others; whitelisting
   
    # Block any site from applying an iframe.
    Header always append X-Frame-Options SAMEORIGIN 
   
  

This technique works in all browsers and is something you can’t just turn off by disabling JavaScript (ie. It’s more secure).

Also note the Apache parameters for the the whitelisting. If you want to block your entire site from iFrames, then you do not need the LocationMatch. Otherwise, any strings that you put in the regex, if found in the url, will not block iFrames. This is useful if you do not want to block a page thats purpose is to be in a frame (like a bookmarklet script).

CSS-wide Keywords and All selectors

For a time we struggled to reset browser styles. Resetting has become the first thing many applications do. Resetting also evolved into normalizing and then into the ‘do all pages need to look the same‘ approach. User Agent (UA) styles are an unfortunate design goal that each version of each browser may apply to elements. There has been little you could do to stop that from occurring; other than implementing the same interactions in pure Bootstrap form and ignoring the elements altogether.

This has begun to change. Largely due to the maturity of web development and the advent of Shadow Dom and Web Components, developers now gain new tools to battle UA styles. Firefox 27 released a very powerful and possibly destructive standard. Now you are able to easily reset all UA styles with a single CSS attribute.

1
*{ all:unset; } /* I do not approve (* is bad perf); but can you feel the weight lifted from the shackles being released?! */

Read More

Working with Ansible

I think that the year 2013 could be remembered by most web developers as the year “DevOps” became a vital part of the workflow. From the growth that dev tools like Vagrant and Docker have seen (Docker wasn’t around before 2013) it’s sometimes hard to keep up with all of the scuttlebutt.

Ansible follows in line with it’s two closest competitors, Puppet and Chef. It fills the role to scientifically create the server/software layer your code is written against. A well written Ansible task will move a server from nothing to a fully working, ready to use process that can be repeated without differences.

Read More