Top 5 Albums of 2014: The Contenders

For the first time in the at-least-a-decade since I started doing these top 5 lists, I almost completely forgot to do one this year. It wasn’t until I happened to be on my blog this morning and my “On This Day” widget reminded me that I realized it was time for the list again.

Maybe I’ve just been too busy. Maybe there hasn’t been much good music this year (at least, good to my jaded and picky ears). Maybe it’s because I turned 40 this year and I’m now officially too old for anyone to care about my opinion on anything. Whatever the case, this year’s list was almost an afterthought. Almost.

But now I’ve remembered to do it, and if time allows I might just give the final list the attention it deserves. For now, we start off as in every year, with the list of contenders: all of the new albums I’ve purchased in 2014. (As if you needed further evidence of how out of touch and irrelevant I am… I not only still care about albums… I still buy music.)

Since my list of full albums this year is so short, I’ve decided to include for consideration EPs — even one that’s a reissue of an EP from 1996 — and, for the first time, my own music.

Aphex Twin — Syro
Beck — Morning Phase
Boards of Canada — Hi Scores 2014 Edition [EP]
Com Truise — Wave 1
The Darcys — Hymn for a Missing Girl [EP]
Foo Fighters — Sonic Highways
J. Law — The Phoenix
Jenny Lewis — The Voyager
Lusine — Arterial [EP]
Magma — Rïah Sahïltaahk
Pink Floyd — The Endless River
Room 34 — Thru
Room 34 — 5mi
Röyksopp & Robyn — Do It Again
Tycho — Awake
U2 — Songs of Innocence
Umphrey’s McGee — Similar Skin
“Weird Al” Yankovic — Mandatory Fun
Yes — Heaven and Earth
Zero 7 — Simple Science [EP]

Update (12 December 2014): I used a “smart playlist” in iTunes to find all of the music in my library that was released this year, but I discovered a couple of albums that I actually bought on CD (how quaint) were missing because Gracenote didn’t fill in the release year. And so we have the addition of Foo Fighters and Pink Floyd to the list. Wait, what year is it again? I also had to add in the new Yes album, which isn’t in my library anymore because it’s so awful I actually deleted it. (Spoiler: It’s not making the final list.)

Very useful WordPress tip for editing systemwide options

In the process of searching for a solution to a very specific WordPress problem (getting the “Add Media” overlay to default to “none” for the link — no one I know ever wants it to default to inserting a link), I came upon a very useful general tip for WordPress.

WordPress stores a ton of settings in the wp_options data table. But a lot of those settings are not directly accessible for editing in WordPress admin. Or so I thought.

Turns out, it’s not linked anywhere in the admin interface, but if you have the Administrator role, you can access an All Settings page that allows you to edit any record in that table (except serialized data) by going to this URL:

http://YOUR_URL/wp-admin/options.php

Watch out… you have the potential to really mess things up here, which is why it’s not easier to get to. But it’s a handy way to easily update an option, if you know what you’re doing, without having to log into the database directly.

Oh… and if you want to fix the specific problem I was trying to solve at the beginning of this post, look for image_default_link_type and set it to “none”.

The (highly biased) case against CSS preprocessors

Everybody who’s anybody is using CSS preprocessors!

Or so it feels. I’m an old-school vanilla CSS curmudgeon, and the more I’ve dipped my toes into working with CSS preprocessors (specifically, SCSS with Compass), the less I like them.

As I see it, there are three main problems with vanilla CSS:

No variables. Honestly this is probably the only problem I really have with CSS. I’d like to be able to set variables for things like colors that I use throughout a site. To a lesser extent, I see the benefit of “mixins” — reusable chunks of CSS.

Redundant code. It really depends on how you conceptualize your CSS structures, but it is very easy to fall into a habit of writing the same CSS code over and over again, resulting in bloated, hard to maintain files. While I am guilty of this just like anyone else, I find that if you format your CSS code properly you can combine properties efficiently to avoid redundancy without needing any external solutions.

Lack of programmatic logic. Here I’m thinking about things like conditional statements, and also math operations. This is probably as much of a strength as a weakness. CSS is a stylesheet, not a program. It’s a set of rules to be applied to formatting a document. There’s nothing programmatic about it. But still, as CSS selectors become more complicated and convoluted, it is clear that in some cases light programming logic would be helpful.

The real question is, do CSS preprocessors actually solve these problems? Or, more specifically, do they solve them without introducing new problems that are at least as bad as the ones they’re trying to fix?

For me the answer has been, and continues to be, no, they don’t. But I’m trying to get a more tangible explanation for why that is, rather than the simple gut feeling that’s been driving me away from using them up to this point.

What are other people saying?

My first stop in trying to answer this question of why I dislike CSS preprocessors was Google. I wanted to see what other people were saying, pro and con. Here are some interesting blog posts I found, going back a few years to the early (or at least earlier) days of CSS preprocessors:

The problem with CSS pre-processors
This article by Miller Medeiros was the first one I came across a few months ago when I initially pondered this question, and at the time it was all I needed to satisfy myself that I was not crazy for wanting to avoid CSS preprocessors.

So, assuming preprocessors do solve the problems with vanilla CSS, what are the problems they introduce? And how bad are they, really?

I need to get specific to my own situation for a minute here. I have a former coworker who is a firm believer in SCSS, and now that he’s gone, I’m left to maintain and extend the code he was writing. This experience casts my aversion to CSS preprocessors into stark relief.

Maintenance can be a challenge

The most obvious issue with using a preprocessor is that the output CSS is not exactly easy to hand edit, and worse, you shouldn’t hand edit it, because your changes don’t end up back in the original SCSS (or whatever format you’re using) files. If someone else goes back in later and edits the original SCSS and generates new CSS, your changes will get lost.

But let’s set that matter aside for a minute. In a broader sense, one of the key challenges for any web developer is to build code that is easy to maintain. Not just for you to maintain, but for whoever comes after you to maintain. Face it, you’re not going to be working on this project forever. At some point, someone else is either going to need to take it over, or throw away what you did and start fresh.

If you’ve ever jumped into an existing project midstream, or been handed the task of maintaining something someone else built — especially if it’s something built by someone who is no longer around to answer your questions — you know that it’s rarely an ideal situation. Even if the previous developer left copious documentation, it can take hours of picking apart their code to really get a firm understanding of how it all works. This is true with plain CSS too, but at least with plain CSS it’s a lot less work to track down a particular piece of troublesome code.

It’s non-standard

What happens when certain features of your favorite preprocessor get rolled into a future version of vanilla CSS? What happens if similar (but incompatible) features of a different preprocessor become the standard? In short, what if everything you’re doing right now becomes obsolete? How long are you going to hang on to doing things your old way with your no-longer-relevant preprocessor, before you have to scrap it and start over, or at least rewrite big chunks of your code to fit the new way everyone is doing things?

Call me a curmudgeon, but having been a professional web developer for over 18 years I’ve seen a lot of technologies and design trends come and go. I’ve always been skeptical of anything non-standard. I never used VBScript or ActiveX, I never embraced Flash, and in general I’ve done everything I could to both champion and adhere to open standards as much as possible throughout my career.

Suffice to say, resisting CSS preprocessors is just in my blood. They just don’t feel right to me. I’d rather do without features I want, if they’re not part of the standard, than resort to a non-standard workaround to make them happen… especially if it looks like there’s a reasonable chance they’ll be added to the standard at some point in the not-too-distant future.

A couple of quick steps to improve the Yosemite UI on non-Retina Macs

I’m guessing most Mac users running a Mac that can handle it have already updated to Yosemite, or will soon. I’m the kind of user who always runs OS updates whenever they’re available.

I’m not a huge fan of Apple’s decision to make Helvetica Neue the new system font in Yosemite. I like Helvetica, but I don’t love it. I prefer something with a little more personality, a little less ubiquity. That said, I do prefer geometric and Grotesque-type fonts over humanist fonts… and I was really sick of Lucida Grande, which I never really liked in the first place.

My first reaction when I tried the Yosemite beta was that it looked half-assed. The final version is a bit more polished, but it still feels poorly thought out. Or, at least, it did until last weekend when I was at an Apple Store and I saw Yosemite on a Retina MacBook Pro for the first time.

Wow.

Retina is clearly what this interface was designed for, and eventually that’s how we’ll all be experiencing it. But for now, and for a while to come, most of us will probably be stuck with non-Retina Macs and the inferior presentation of Yosemite’s refined UI that they deliver.

That said, there are a couple of things you can do to improve the experience. Part of why Yosemite doesn’t look great on a non-Retina Mac is that there’s too much subtle stuff going on that just kind of gets mucked up when you don’t have that precise definition on letters and icons. You can improve this aspect of the UI immensely by reducing its use of transparency. Open up System Preferences and switch to Accessibility. Check the box labeled Reduce transparency.

Screen Shot 2014-11-06 at 12.11.23 PM

Another optional change you may wish to make is to darken the menu bar and Dock. This is more of a matter of taste, but personally I like the darker look. Switching this on essentially inverts the colors, so your menu bar has a nearly black background with white text, and the Dock becomes translucent dark gray, instead of translucent white.

Once again in System Preferences go to General and check Use dark menu bar and Dock.

Screen Shot 2014-11-06 at 12.11.16 PM

Now enjoy your new OS!

Responsive images with srcset in WordPress

As a developer, I am somewhat conservative. I believe strongly in the importance of web standards, and I am reluctant to be an early adopter of any new techniques or, even worse, non-standard workarounds for limitations in existing standards. I’d rather live with the limitations until a proper standard — or at least a de facto standard — takes hold.

One of the latest issues to challenge my approach has been responsive images. I’ve settled into a pattern of going with “1.5x” quality images, trying to strike a balance between quality on large high-res displays and a reasonable file size. But it really doesn’t do either very well.

Today’s issue of A List Apart features an exciting article:

Responsive Images in Practice

Yes! In practice! Let’s do this!

There have been a couple of competing proposals for handling responsive image sets, and I am pleased to see the srcset attribute begin to emerge as the winner. The biggest plus it has for me is that it degrades gracefully for older browsers that don’t support it.

Well, before I had even finished reading the article I started thinking about how I could leverage the build-in image sizing mechanism in WordPress to use srcset. I haven’t looked around — I’m sure someone else has already created a plugin that perfectly nails what I am attempting to do here. And, to be honest, I haven’t extensively tested this code yet, although I did drop it into a site I’m currently working on, just to be sure it doesn’t throw a fatal error and that it actually does render the HTML <img> tag as advertised.

function img_with_srcset($attachment_id, $default_size='medium', $echo=true) {
  $output = null;

  // Get image metadata
  $image = wp_get_attachment_metadata($attachment_id);

  // Set upload directory for image URLs
  $upload_dir = wp_upload_dir();
  $upload_url = $upload_dir['baseurl'] . '/' . dirname($image['file']) . '/';

  // Build array of sizes for srcset attribute
  $sizes = array();
  foreach ($image['sizes'] as $size) {
    $sizes[$size['width']] = $upload_url . $size['file'] . ' ' . $size['width'] . 'w';
  }
  
  // Sort sizes, largest first
  krsort($sizes);

  // Get image alt text
  $image_alt = get_post_meta($attachment_id, '_wp_attachment_image_alt', true);

  // Generate output <img> tag
  if (!empty($sizes)) {
    $output =  '<img srcset="' . implode(', ', $sizes) . '" ' .
               'src="' . $upload_url . $image['sizes'][$default_size]['file'] . '" ' .
               'alt="' . esc_html($image_alt) . '" />';
  }
  
  // Return/echo output
  if ($echo) {
    echo $output;
    return true;
  }
  else {
    return $output;
  }
}

Let’s just examine what’s going on here.

The function takes three input parameters. An attachment ID, a default size (for the old school src attribute), and a boolean for whether to echo the output or just return it.

First, we get the attachment metadata and put it into $image. You can see more about what the wp_get_attachment_metadata() function does here.

Next, we set up the $upload_url variable to be the full base URL to the WordPress uploads directory. That’s because the metadata output only includes the filename of each sized image, not its full URL.

Then we loop through all of the sizes in the metadata output, generating a series of strings containing the image URL and its width, for use in the srcset attribute. We put these into an array because we need to manipulate the list a bit: we need to sort it so the largest images come first, and then later we need to implode() this into a comma-separated string.

Of course we also need the image’s alt text, so we grab that with get_post_meta() which you can read more about here.

Finally, assuming we actually have some size data, we build the <img> tag, complete with srcset attribute! Then we either echo or return it, as determined by the $echo input parameter.

Something else I’d like to try with this is taking it a step further by adding a filter that processes page content, looking for <img> tags, and automatically inserts the appropriate srcset attribute.

There you have it. I welcome anyone who’s reading this to give the function a try in your WordPress site, and let me know how it goes!