Checking Entropy

Attention is a Precious Resource

2013-08-20T00:00:00-07:00

I had an MRI last week. While I was laying in the machine quietly listening to the cacophony of clashes, clangs, beeps, and buzzes I was surprised at how calm I felt.

Usually overwhelming, discordant noise really bothers and stresses me. I find it difficult to think or process and answering the simplest of questions feels like a Herculean task.

But I didn’t feel like that in the MRI.

Since I didn’t have anything else to be doing, I thought about this and why the noise here wasn’t bothering me. Then, I realized that the answer was in the question. I didn’t have anything else to be doing.

I’m not stressed out by having too much noise, I’m stressed out by having too many demands on my attention. The volume and discordancy (generally from kids) is just a manifestation of demands on my attention.

While I was laying there in the MRI, there was no other demand on my attention. I could simply focus and be in the moment. I could ignore the noise (not something I can do with kids) and just focus on my thoughts.

I think back on other times when I feel stressed and it’s almost always when there are too many demands on my attention. Tasks clamoring for attention or people clamoring for answers or input. When I can just focus on one thing at a time and move methodically from one task to another, I’m much happier and less stressed.

Now, I’m trying to be in the moment. When I talk to someone, I’m focused on the conversation, not reading emails. When I talk to one of my kids I get down on their level so I can look them in the eye. When I’m finding myself feeling overwhelmed, I take a deep breath and walk outside to look at the trees. It only takes a couple minutes and I’m back at my desk feeling better, and dealing with the demands one at a time.

I’ve never been very good at introspection, but I have to hope that episodes like this help me be better. Recognizing what works well for me helps me create a happier, healthier, more productive environment - for both work and life.

Now with More Min

2012-03-08T00:00:00-08:00

I just setup support for minifying CSS and HTML in the blog for better performance.

I created a new Rake task to minify the HTML and CSS based on Jekyll Deploy Scripts.

# Usage: rake minify desc "Minify files" task :minify do system "java -jar _build/yuicompressor.jar --verbose --type css -o assets/themes/the-program/css/style.min.css assets/themes/the-program/css/style.css" system "java -jar _build/htmlcompressor.jar -r --type html -o _site _site" end # task :minify

Now I can just run rake minify to prep my HTML/CSS for production.

HumanDigest

2012-03-01T00:00:00-08:00

I saw the humanhash project a while back and it looked perfect for something I needed to do in QAtab. The only problem was that humanhash was written in Python.

Over the last few days, I took the time to read through the Python code, and run the script locally in small bits to understand what it was doing and how it was doing it (an activity that was hampered by the fact that I don’t know Python).

Once I understood its behavior in Python, I re-created it in Ruby and turned it into a gem.

You can now use human_digest (gem) in your projects too!

Managing CSS - An Introduction

2012-02-23T00:00:00-08:00

I’ve been working with CSS for almost 10 years. In that time it has always bugged me that CSS frequently devolves into a mess of conflicting styles and long stylesheets. I’ve been thinking about how to make the situation better and doing some research on what other people have done, and this is the first in a series of blog posts where I will explore ways and means of managing CSS files.

Goals

Any time you set off on an “expotition” you need to have goals in mind. Goals help you evaluate your pathways and give your destination a shape.

Organization and Maintainability

There should be some order to the styles. Some sense of what goes where. It’s painful to have the same selector appear in 3 different files so that you have to figure out which one is the best place to edit.

In addition to keeping the styles organized, it’s important that they’re readable. When writing traditional “code”, a coding style guide helps ensure that everyone is writing code in an agreed on format. Bringing this concept to CSS can help keep your styles and attributes organized.

Performance

CSS files can easily balloon to 10’s of KB - granted not that big on the grand scale of things but it’s important to do what you can to minimize file sizes (and the number of CSS files) in order to keep web sites performing well.

Documentation

In order for styles to be used effectively, they need to be documented. This let’s new people work with them and provides a framework for review and discussion. We’ll even explore the QA benefits that can be found in documentation.

Vocabulary

It’s difficult to talk about something unless you have a shared vocabulary. We need to agree on certain concepts and what they mean. I’m going to lay out a simple vocabulary here but I suspect that the Vocabulary will become an element of Documentation by the time we’re done.

You may disagree with some of these terms - that’s ok. The important thing is that you understand what I mean when I use them. Some of the terms are likely to be self-evident and industry-standard - that’s ok too. I’m explicitly documenting them so that there are no questions.

The top of the page. Usually a shared block of HTML that appears on all pages of the site and includes logo, navigation and other common page elements.

The Header should not be confused with the head tag.

The bottom of the page. Usually a shared block of HTML that appears on all pages of the site and includes additional links, copyright and other supporting page elements.

The Footer should not be confused with the footer tag.

Gutters

If a page has a fixed width design then, the space between the left and right edges of the content and the left and right edges of the browser window.

I’m using the term Gutters rather than margin so as to prevent confusion with the margin style.

Wrapper

The wrapper bundles up several different parts of a site together. It includes the Header, Footer and Gutters. The Wrapper will be largely unchanged from page to page (apart from some possible navigation state indicators).

Content

The content is the meat of the page. It’s “why we’re here”. Content will be different from one page to another and even the design of the content area may be different from one page to another.

It can be on the left or on the right or both. The sidebar usually contains navigation and additional content in support of the Content. Think of it like an aside for the Content.

Mast

This is usually a banner above the content. We’re not lumping it in with the Content because there are frequently similarities in Mast between pages and it often spans both the Content and the Sidebar.

What’s Next

Now that we have some goals and a vocabulary, we can start a dialog. My next blog post will focus on organization and maintainability - how CSS file(s) can be structured and ways to think about CSS. We’ll look at what some other folks have said and try to work towards a common, stable foundation.

How I use HTML5 Boilerplate

2012-02-08T00:00:00-08:00

I’m a big fan of HTML5 Boilerplate but there’s a few things I do differently…

The Beginning

<!doctype html>     <html lang="en"> 

I find that I don’t need a whole lot of CSS that is IE-specific to fix display issues. Therefore, I don’t need the variety of classes on the html tag.

I prefer being able to target each version of IE individually because it allows me to apply changes to more recent versions but not older versions.

For example, I use CSS3PIE to get rounded corners and drop shadows in IE8 and under. However, sometimes applying CSS3PIE to an element in IE7 causes issues with the display when it works just fine on IE8. Being able to target the browser versions individually let’s me provide the rounded corner effect to IE8 users while IE7 users get the squared off corners.

The Head

<head> <meta charset="utf-8"> <title></title> <meta name="viewport" content="width=device-width,initial-scale=1"> <script> var _gaq=[['_setAccount','UA-XXXXX-Y'],['_trackPageview']]; (function(d,t){var g=d.createElement(t),s=d.getElementsByTagName(t)[0]; g.src=('https:'==location.protocol?'//ssl':'//www')+'.google-analytics.com/ga.js'; s.parentNode.insertBefore(g,s)}(document,'script')); </script>  <link rel="stylesheet" href="/css/styles.css"> </head>

Since most of the sites I’ve built to date are fairly static sites (as opposed to web apps) I don’t need the power (and overhead) of Modernizr. I do however still need some HTML5 love for older IE browsers so I use the html5shiv. I like to keep it locally (rather than on a Google CDN) because it lets me control the version that’s used. I’ve had problems before with other JS libs not playing nicely with html5shiv and had to upgrade to a pre-release version of it to get everything working.

I know that many people (including the HTML5B folks) advocate putting the Google Analytics code in the footer. It does work there, but it means that you can’t use GA anywhere else safely without using the var \_gaq = \_gaq || []; construct. If I have it in the head then I know that GA is available and I can just use it as expected. I do like the slimmed down version of the code from HTML5B so I’m starting to use it and, since the code is in the head, I don’t have to worry about the succint _gaq setup killing any other _gaq calls which might happen if GA is at the bottom of the page.

Finally, I always put the link tag for CSS below any script tags because “a stylesheet followed by an inline script blocks subsequent downloads” ([Steve Souders](http://www.stevesouders.com/blog/2010/09/22/newtwitter-performance-analysis/)).

The Body

<body> <div id="container"> <header> </header> <div id="main" role="main"> </div> <footer> </footer> </div>   </body>

Not much to see here. Marking up and styling a page is a totally different topic for a different post.

On Scripts

<script src="/js/libs/jquery-1.7.1.min.js" type="text/javascript"></script> <script src="/js/plugins.js" type="text/javascript"></script> <script src="/js/script.js" type="text/javascript"></script>

The way that the scripts are added in the final page is fairly standard so I’d like to talk about how I organize them behind the scenes. I never liked the libs/ vs mylibs/ organization structure; I was never sure what should go where.

I resolved the issue by just using libs/ and plugins/

libs/
plugins/

I keep jQuery and html5shiv (and DD_belatedPNG but I’m starting to drop support for IE6 so that will go away) in libs/ while all of my jQuery plugins go in the plugins/ directory. I always keep both a development and a minified version of each lib and plugin around. This makes it easy to debug when I need to.

In Total

Here’s what you get when you add it all together.

<!doctype html>     <html lang="en">  <head> <meta charset="utf-8"> <title></title> <meta name="viewport" content="width=device-width,initial-scale=1"> <script> var _gaq=[['_setAccount','UA-XXXXX-Y'],['_trackPageview']]; (function(d,t){var g=d.createElement(t),s=d.getElementsByTagName(t)[0]; g.src=('https:'==location.protocol?'//ssl':'//www')+'.google-analytics.com/ga.js'; s.parentNode.insertBefore(g,s)}(document,'script')); </script>  <link rel="stylesheet" href="/css/styles.css"> </head> <body> <div id="container"> <header> </header> <div id="main" role="main"> </div> <footer> </footer> </div>  <script src="/js/libs/jquery-1.7.1.min.js" type="text/javascript"></script> <script src="/js/plugins.js" type="text/javascript"></script> <script src="/js/script.js" type="text/javascript"></script> </body> </html>