Andy Taylor

1140px CSS Grid Retired

Tue, 09 Apr 2013 21:57:51 +1000

It’s been about two and a half years since I released the 1140px CSS Grid. Initial response was exciting; lots of people used it. However, a lot has happened in that time. When it was released, the concept of Responsive Web Design was in its infancy (I’d never heard of it). Over time, I—and the rest of the web community—have learnt how to do Responsive Web Design properly.

I’m not comfortable with people continuing to use the framework. It was never really a great solution; just an early experiment that a lot of people participated in. It was a one size fits all, desktop first, templated grid system. In short, not how you should make a responsive website.

So it is now retired.

Jekyll Reading Time

Sun, 07 Apr 2013 11:32:00 +1000

Some of my posts now include an estimated reading time. I did this by taking the Liquid Filter, number_of_words and—based on a reading rate of 180wpm—used other Liquid filters to convert it to an approximate reading time. Here’s the template code:

{{ page.content | number_of_words | append: '.0' | divided_by:180 | append: 'min' }}

For this post, it will output: 1.6944444444444444min

Unfortunately the X.XXXmin figure is a bit verbose. I’d prefer a whole number, or at least X.Xmin. Without append: '.0' I was getting a whole number, but it wasn’t rounded. So 1.9min would be 1min. Liquid provides more filters which could limit the figure to X characters, but they haven’t been implemented by Jekyll.

A reading time on very short posts seemed a bit silly. I found a clever bit of template logic on Stack Overflow that enabled me to only show it on posts that are greater than 250 words. It’s a bit hacky, but it essentially uses truncatewords (without actually truncating the words), then establishes if the post is longer than the truncated length to create an if statement.

{% capture truncated_content %}
  {{ page.content | truncatewords: 250 }}
{% endcapture %}
{% if page.content != truncated_content %}
  {{ page.content | number_of_words | append: '.0' | divided_by:180 | append: 'min' }}
{% endif %}

Because I couldn’t get Liquid/Jekyll to round the number. I wrapped it in a span with the class .time. My friend Josh wrote a jQuery script for me that rounds it to the nearest whole number:

<script type='text/javascript'>
  $(document).ready(function() {
    $(".time").text(function (index, value) {
      return Math.round(parseFloat(value));
    });
  });
</script>

Media Queries are a Hack →

Sat, 06 Apr 2013 10:08:34 +1100

Ian Storm Taylor puts forward the idea that Media Queries make writing modular CSS difficult:

The big buzzwords in CSS these days are “modular” and “responsive”—and for good reasons. But we’re still trying to achieve those goals with the wrong tool: Media Queries. What we actually need is a tool that doesn’t exist yet: Element Queries.

It’s a really interesting read. He proposes that to write modular CSS, the query should be based on the width (or other variable) of the element, not on the width of the screen. For example:

.widget (min-width: 300px) {
  font-size: 0.8em;
}

It’s a great proposal. But it also left me wondering how it would work in practice. I imagine nested elements wouldn’t be an issue:

.widget (min-width: 300px) ul {
  list-style: none;
}

But what if you needed to add a pseudo class selector?

.widget (min-width: 300px):hover ul {
  color: #888;
}

Does that break the syntax? Wouldn’t the Element Query need to be chained to the element? If so, while we’re throwing around proposals, could we make the syntax a little less verbose:

.widget(width>300px):hover ul {
  color: #888;
}

Multiple queries could be linked with an ampersand:

.widget(pixel-density>=2 & height<100px) {
  line-height: 1em;
}

Using Sass would make this both modular and self-contained:

.widget {
  font-size: 0.8em;
  &(pixel-density>=2) {
    &:after {
      content: 'Retina';
    }
  }
  &(width>300px) {
    font-size: 1em;
    &:after {
      content: 'Greater than 300px';
    }
    &(pixel-density>=2) {
      &:after {
        content: 'Greater than 300px and Retina';
      }
    }
  }
}

However they’re implemented, I’d love for Element Queries to become a reality.

∞ Read this on andytaylor.me

The Implied Elements of Pagination

Tue, 02 Apr 2013 21:24:09 +1100

Pagination can take many different forms. However, it’s generally made up of labels, indicators, arrows, or some combination of the three. There’s no single perfect implementation. But we can get close by considering each of these elements, in context, before they are removed—or implied.

First, you should look at the type of content being paginated, and—more importantly—how it’s sorted. This should define the language used for labels. In most cases, contacts are sorted alphabetically, blog posts are sorted reverse-chronologically, and search results are sorted by relevance.

When paginating their results, Google use the labels Next to load more results and Previous to go back from pages other than the first. They also use a page indicator to show which page you are on (more on that in a minute).

Google use Previous and Next. They also indicate which page you are on.

This is clear. You start on the first page and move left-to-right to the next page. You always know where you are, and what clicking Next or Previous will do. This labeling makes sense for paginating content sorted by relevance (or alphabet). It does not, however, for paginating chronologically sorted content.

Blogs are almost always sorted in reverse-chronological order. This means the newest content is on the front page, with subsequent pages containing older content. If the label Next was used on the front page, the user could only assume this would take them to the next page of content; it’s the only option. The user may comprehend the label, but it isn’t the clearest option. Older or even Older Posts is more explicit.

The pagination system should also be consistent throughout a site. On a post page, if the label Next was used, the user would have very little idea whether they would be taken to the next-newest or the next-oldest post. With chronologically ordered content, Newer and Older aid the users comprehension more than Previous and Next.

Google give the user every element possible to aid comprehension. But they are not all necessary. Pagination is such a strong design pattern that, when you remove detail, the user’s brain fills it in. If Google’s pagination is cut in half (as below) both the top and bottom halves work on their own.

The top of Google’s pagination

Removing the bottom means there are no labels and no numerical indicator. However, the left and right chevrons imply Previous and Next, and the oooooooooo replaces a traditional numerical indicator. This still gives the user a fairly clear¹ idea of where they are and what clicking each arrow will do.

The bottom of Google’s pagination

Removing the top makes this far less graphical, yet equally—or more—clear. There are no arrows but direction is implied; Next is to the right of the page, and Previous is to the left. Bing do exactly this:

Bing’s pagination

Designers can make good use of these implied elements by considering, and then removing them. But if they aren’t considered, they can confuse the user.

I would argue that in the case of reverse-chronologically ordered content—whether arrows are used or not—Newer should always be to the left of the page and Older to the right. In turn, when content is sorted by relevance or alphabet, Previous should always be to the left of the page and Next to the right.

The pagination on this blog (usually obscured by infinite scrolling).

The reason for this is the page indicator; it may be implied, but it’s always there. English reads left-to-right, therefore, a list of numbers should be written left-to-right.

Bing’s pagination reversed

In the above example I’ve reversed Bing’s pagination. If the page indicator was removed, this might appear to make sense. But with it present, it clearly doesn’t. If the indicator (or labeling, arrows etc.) is going to be implied, the other elements should still follow the left-to-right pattern.

When elements of pagination are removed, they are still implied. Consider these implied elements next time you’re designing pagination.

As red and yellow are similar hues, users with colour blindness may struggle to differentiate the red o.
↩

Yet Another New Bloody Design

Fri, 29 Mar 2013 09:16:54 +1100

Five months ago, I retired my Tumblr ‘blog’¹ and set up Jekyll to replace my personal site. I’ve written more in that time than I did in the three years prior; as a result, more people seem to be reading, too. I’m writing more, partially because I wanted to write, and partially because I had a system—both front- and back-end—that aided writing. There are many other static site generators that use Markdown files for content storage, but Jekyll is working for me.

There was nothing particularly wrong with the old design. However, my personal site has always been a good place to experiment, which is why I’ve redesigned it, yet again. I’m now using Sass, which is excellent; I’ve used REM sizing extensively; added syntax highlighting for code blocks (like in this post; added silly Emoji post dividers (that have very little device and browser support); and added keyboard shortcuts that haven’t been exposed in the UI yet.²

There’s still lots of things I want to experiment with and refine. But it got to the point where I thought it was good enough to ship.

I put blog in quotes because I did very little writing on my old blog.
↩
m toggles the menu, → takes you to the previous post and ← takes you to the next. There’s also a couple of more useless ones like ar to open Archive, ab to open About and h to go home. Try typing twitter. Mousetrap is brilliant.
↩

Learning to See →

Mon, 25 Mar 2013 10:33:34 +1100

Oliver Reichenstein’s love letter to Design. A must read. Here’s a snippet from the conclusion:

It is not the hand that makes the designer, it’s the eye. Learning to design is learning to see. Naturally, what designers learn to see as they improve their skills is usually related to design. Doctors don’t see web sites in the same way as web designers, just as web designers don’t see radiographs as doctors do. Our experience sharpens our eyes to certain perceptions and shapes what we expect to see, just as what we expect to see shapes our experience. … There are not distinct groups of “designers” and “non-designers” — it’s a continuum. And there is no such thing as the worst or greatest designer, since design requires a lot of different talents that can’t be directly compared. Some have deeper imagination, are better with the purely functional aspects, have more talent in polishing details, have better technical skills, and some will shine with an unbreakable will to ship. It is a long way from novice to pro, but what we all have in common is the trained ability to see what others don’t, to create what others can’t see but only feel.

∞ Read this on andytaylor.me

Leaving Feedburner

Sat, 23 Mar 2013 13:12:16 +1100

I was a little surprised that Google didn’t decide to shut down Feedburner along with Google Reader. However, it seems like it’s only a matter of time. So I’ve deleted the feed and re-directed it to the un-feedburnered feed.

If it works correctly, the feed URL should update in most feed readers. But feel free to update it to http://andytaylor.me/feed manually.

Sorry for the hassle.

Pen Type-A

Sat, 23 Mar 2013 09:43:24 +1100

I’ve wanted a Pen Type-A since I first heard about CW&T’s Kickstarter campaign to manufacture them a couple of years ago. As I missed out on the original run, I’ve been patiently waiting for availability.

I checked their site every couple of months, but it was almost two years before they were available again. I purchased immediately.

It arrived yesterday and it is already one of my favorite objects. Its parts are machined out of solid stainless steel; it feels amazing. Because the pen and case are machined so precisely, the pen slides into its case slowly, forming a pneumatic seal. This results in a delightful pop sound as you pull it out again.

The genius of this pen is that it’s simply a housing for the (Internet) famous Pilot Hi-Tec-C refill cartridges, which are available in four line widths (0.25, 0.3, 0.4, 0.5) and over 30 colours (although the only sane colour to use is black). The sharp, solid line these cartridges make, leave the pen you were using before looking dull and blurry.

I couldn’t find anywhere to purchase refills in Australia. The Hi-Tec-C is called G-Tec-C in the US, so I’m not sure if they aren’t available, or if they simply go by another name. Pilot Australia sell a pen called Hi-Tecpoint, but the casing doesn’t look anything like the Hi-Tec-C or G-Tec-C. JetPens sell refills, but by the time you add international shipping, they weren’t cheap. They are, however, all over eBay (ughh), so I ordered ten for $12.

The Pen Type-A feels like it’ll last a lifetime. Hopefully refills are still available when I’m 90.

Sublime Text 2 Replacement Icon →

Fri, 01 Mar 2013 23:23:14 +1100

After being convinced to give Sublime Text 2 a try, I’m digging it. However, I didn’t like the icon at all. So I made a replacement.

Download it on GitHub. There’s and .icns for Mac and .ico for Windows, but I haven’t tested the latter.

∞ Read this on andytaylor.me

Draft. Version control for writing →

Fri, 01 Feb 2013 11:34:58 +1100

Not too long ago I wrote a post about writing in version control. I essentially argued that keeping plain text or Markdown files in version control—using GitHub for collaboration—was a far better solution than Track Changes in Word, or any other existing solution.

There is, however, a huge barrier to entry. Even when using the elegantly simple GitHub Mac app, the learning curve is too steep for most people to try it. Essentially, I identified a problem, but the solution I posed was far too nerdy.

Today Nate Kontny announced a project called Drafts:

A lot of folks try to end up learning Git, which is a popular version control system used by software developers. It really is a great tool if you’re in software development. But even as a developer it’s full of headaches. Writers don’t need all this added complexity and overhead to manage versions of their work.

Draft solves this. Draft is a distraction free editor that auto-saves as you type. But as you go along, you can mark major versions of your work.

When you share your document, any changes your collaborator makes are on their own copy of the document, and you get to accept or ignore each individual change they make.

This sounds brilliant; a simple solution to a real problem. At this stage it’s a web app. In the future I’d love to see a native app to compliment the web service. Something that gave you a local file of the most recent version. So you could work offline, so you could use your favourite editor—but most importantly—so your master copy wasn’t tied up in a web service.

A native app could be as invisible as Dropbox, with all collaboration actually taking place on the web. Or it could be a full blown editor with all the collaboration features of the web app.

I’m looking forward to trying it.

∞ Read this on andytaylor.me

Open Source Design

Wed, 23 Jan 2013 21:47:46 +1100

While looking at Google Analytics for this site, I started noticing some unknown page titles. It was immediately obvious that a few people had taken the source from GitHub and started using it with their own content.

It took me a significant amount of time to get Jekyll functioning exactly as I wanted it to. The reason for putting the source on GitHub—other than to host it on GitHub Pages—was so that people could peep the code, and to learn how to use Jekyll, just as I had done.

However, I never intended the design to be reused. The last iteration of this site was ripped off. It wasn’t on GitHub, but it was a 100% static site, so the source was available with any browser. There’s a general understanding in the web community that stealing design is wrong; there was no doubt that this was a ripoff.¹

But when the source is on GitHub, I can somewhat see the other side of the argument: ‘it’s on GitHub, that means I can take it and do with it what I please’. But I’m not sure that’s right. Just because it’s there for you to see, doesn’t mean it’s there for you to use entirely as you wish. That’s why many repositories contain licenses.

I don’t think it’s right, but I can see the grey area.

I should’ve stripped out the design and open sourced it as a sandbox/boilerplate. I should’ve included a licence.² I shouldn’t of assumed that people wouldn’t take it in its entirety. It is now a private repository.

I’d love to hear people’s opinions on this. Hit me up on Twitter or hi@andytaylor.me.

There was lively debate about this on both Twitter and Dribbble. All of which have disappeared from the internet. However, I still have .webarchive’s.
↩
I wonder if this would’ve made a difference.
↩

Writing in Version Control

Sun, 16 Dec 2012 23:16:44 +1100

Git and I have only recently become friends; I had no idea what I was missing. If you’re new to Git, it’s a free and open source Distributed Version Control System (DVCS). When a file—or project—is version controlled with Git, every change is reversible and its entire history is saved. You can get up to speed here.

When I used Tumblr, my local- and live-copy of each post quickly got out of sync, because I’d make some edits directly into the Tumblr editor. Now that I’m using Jekyll, all my blog posts are saved as plain text Markdown files in Dropbox. This means I always have access to them. But more than that, it means I always have access to the master copy. And because the entire site is version controlled with Git, I know exactly what I’ve changed, down to the line.

Which got me thinking. Developers have been using version control forever, but have writers? Do many of them even know version control exists? Sure they’ve used Word’s Track Changes, but do they know how much better it could be?

Tools like GitHub’s Mac and PC Git GUI apps, mean you no longer have to touch a command line; changes are visual and easy to understand. Maybe it’s my resistance to MS Office, but a Git GUI seems far easier to understand and follow than Track Changes.

Imagine an author and editor collaborating on a book. As the author writes, they’re committing each substantial addition or change. They then have a complete history of every meaningful change they’ve made through the entire process of writing a book; mind-blowing on its own. Plus, each time these changes are pushed to GitHub¹, they’re backed up, safely stored in an off-site location.

The editor could feasibly comment on each commit if they really wanted to. However, it seems like the really powerful part is when they start editing. The editor makes all their edits and the author can merge them one by one, understanding what changed, and rejecting changes they disagree with.

This is obviously an over-simplified example, but think about the possibilities. The benefits of version control are applicable to everything from blog posts to multi-author books.

Want to try it out? Download GitHub for Mac (or Windows), save a text file with some content in a folder, then drag that folder to the app. It’ll ask you if you want to make it a local Git repository, let it. You can then write your first Commit summary (a note on what you’ve changed—or in this case added), unselect the sync toggle button (because you’re not syncing with a remote yet), then hit the Commit button. Every time you make a change, write a short commit message outlining those changes and hit the commit button again. The entire history is kept in hidden files within that folder. It’s that simple.

GitHub is a remote server for Git repositories. You can use Git locally without ever pushing it to a remote server; however, the real power is evident when you collaborate on a project with others, and to do that you need a remote server. If you’re looking to test the waters with a private repository, BitBucket is an alternative to GitHub that lets you have up to five collaborators on a private repository for free.
↩

Pull Quotes

Sun, 02 Dec 2012 13:10:55 +1100

Pull quotes are common in magazines, but you don’t often seem them on the web. According to Wikipedia, a pull quote is a ‘quotation or excerpt from an article that is typically placed in a larger or distinctive typeface on the same page, serving to entice readers into an article or to highlight a key topic’.

I found a pull quote technique by Maykel Loomans which is quite clever; it uses HTML5’s data-attribute and CSS’s content to include a pull quote in the page, without it being a repetition of content. Because the content isn’t repeated, it’s invisible to screen readers and services like Instapaper. However, his technique relies on adding a class to the <p> element, along with data-pullquote="". As Jekyll uses Markdown to store content, you can’t just add a class or data-attribute to a paragraph. Markdown does however, parse blocks of HTML. I decided to use a CSS attribute selector—instead of a class—to insert the pull quote with as little markup as possible:

<p data-pullquote="Pull quote content"></p>

That’s pretty bare bones. An empty paragraph tag with the data-attribute, data-pullquote. It’s possible to use CSS to pull the content from data-pullquote and insert it into the page. First make the empty element visible:

p[data-pullquote] {
  display: block;
}

Then use a :before selector to add the content to the page, giving it some basic styles:

p[data-pullquote]:before {
  content: attr(data-pullquote);
  float: right;
  width: 200px;
  margin: 0 -5% 0.5em 30px;
  padding: 0;
  font-size: 22px;
}

I also wanted multiple pull quotes on a page to alternate between floating left and right; I tried selecting them with nth-of-type:

p[data-pullquote]:nth-of-type(odd):before

Unfortunately that didn’t work, nth-of-type was finding every odd paragraph, instead of every odd paragraph with data-pullquote. So I ended up having to use a class to optionally pull a quote to the left:

p.pull-left[data-pullquote]:before {
  float: left;
  margin: 0 30px 0.5em -5%;
}

It’s more markup, but it does allow me to choose which quotes I pull to the left.

Stables and Volatiles →

Sun, 25 Nov 2012 18:20:30 +1100

This piece by Michael Lopp is primarily about engineering, but it speaks to the entire process of making ‘things’ in teams. ‘Stables’ are process driven; they want to make safe things, the right way. ‘Volatiles’ are disrupters; they live for making the next amazing thing.

This part particularly struck home:

Once you’re successfully past 1.0, you have a choice: coast and die, or disrupt. No one in history has ever actually chosen coast and die; everyone thinks they’re choosing the path of continued disruption, but it’s a very different choice when it’s made by a Stable than by a Volatile. A Stable’s choice of disruption is within the context of the last war. They can certainly innovate, but they will attempt to do so within the box they bled to build. A second-generation Volatile will grin mischievously and remind you, “There is no box.”

You start a project with the craziest of ideas; some make it, some don’t. You end up with a good—sometimes great—thing, and some baggage from the process.

Within the context of that project, you may never be a Volatile again. You’ve got your thing, now you need to maintain it, you need to gradually make it better. You couldn’t possibly do that new feature with all that baggage, could you?

Will your thing ever be distinctly better unless you bring in some new Volatiles? Hopefully just being aware that you’re becoming a Stable is enough to somewhat counteract the fact that the baggage is undroppable.

∞ Read this on andytaylor.me

Getting Back Into RSS

Thu, 22 Nov 2012 20:35:05 +1100

Lots of people use Twitter instead of RSS these days. I’ve been in that camp for at least three years, but I’ve recently got back into to RSS.

I used to subscribe to lots of high volume, multi-author sites. Seeing ‘1000+’ on my Google Reader tab every day was overwhelming. Eventually my usage dwindled to the point where I only had a look every couple of months.

I now read a different kind of site; lower volume, usually with a single author. I can subscribe to about twenty of these for every one, high volume site.

And so I purchased Reeder for Mac and decided to give RSS another go. Here’s a few principles I went by:

Favour low volume
Favour individuals
Favour original content
Avoid links blogs with little or no commentary
Know who you’re reading; rename feeds to include the author
Don’t hesitate to unsubscribe

Here’s a tip: Mark everything as read. After one day, if a feed has more than five new items, consider unsubscribing. It’s worth it.

Oliver Miles Alway Taylor: The First Week

Tue, 20 Nov 2012 21:44:05 +1100

This is a collection of Day One posts that chronicle the first week of my sons life. I was concerned that they would be lost if they remained locked in a proprietary app. So I compiled them here.

Monday, September 10, 2012.

In scrubs and ready to go; I had to wait half an hour, but when I went in, it all happened.

The spinal block was already in. I sat down next to Jane and reality finally sunk in.

Oliver was born within what felt like 5 minutes. It was 12.31pm. I went over to the heat table with the midwife while she cleaned all the white shit (vernix) off him. She got me to dress him; which I did well, I think.

We then took him over to Jane’s chest. He stayed there for a while, before being weighed and measured—3.32kg (7.31lb).

I then took him out to the midwife’s office. Mum, Dad and Les were there. Dad had a bit of a cold so he didn’t have a hold, but the grandmas did.

We took him into recovery to see Jane and to do skin to skin. This worked well and he even took some boob pretty easily. The midwife was amazing and helpful.

They gave Jane OxyContin, which made her sick. But it passed pretty quickly.

He had another feed once we got upstairs and then went back to sleep for about 5 hours. As much as I wanted him to be awake and ‘do stuff’, it was nice to ease into it with a not-at-all stressful afternoon.

Just born

Day Two

I got into the hospital at about 10.15am; I wanted to skip peak hour and get a bit of extra sleep.

Jane attempted to have a sleep while I edited the photos from the first day.

In the arvo, another amazing midwife helped me give him his first bath. It was pretty cool. Until that point I hadn’t really held him without his clothes on; he was so incredibly soft.

Jane also got out of bed for the first time after her cesarean. I helped her have a shower.

It seemed like the afternoon went quite quickly; there was lots of things to do.

Chilling on his second day

A Couple of Rough Nights

We came home on Friday. Everything was great at the hospital with Ollie, but Jane was pissed because they kept missing her meds and not answering the buzzer.

Our obstetrician was fine for her to go home a day early, so we did.

We left the hospital at 6.30pm to skip some of the peak hour traffic. Everyone told me I’d be scared shitless of driving with him in the car. I was actually fine; reverse psychology maybe.

The first night home was the first prick of a night. We both went to bed at about 12.30am; I passed out instantly. Jane woke me up at 2.30am and he hadn’t slept at all. Jane slept less than I did, but we essentially swapped every two hours until he finally fell asleep on my chest at about 5.30am. I was listening to Hypercritical to keep me awake; so maybe John Siracusa’s dulcet tones finally put him to sleep.

Realising I was going to be nursing him many, many times with nothing to do, I subscribed to heaps more podcasts. Late night TV drives me crazy.

We had a few theories as to why he didn’t sleep: Jane eating onion; probably not. No fucking reason; probably not. We settled on the theory that Jane’s milk had come in properly, and he just wasn’t used to having more that a few millilitres of colostrum.

A few days in, ready to go home.

Saturday Night Was Great

Jane got up to feed him once. But he essentially had a four and a six hour block of sleep. Killer.

Sunday Night Was All Over the Shop Again

We went to bed at 11ish and again, I passed out straight away. Jane woke me at 12.30am in a bit of a state. He hadn’t slept again. The same problem as Friday; every time we lay him down he cried. And like Friday, it was pretty uncontrolled too. You’d hold him and he’d be perfectly peaceful, then bang, screaming in pain.

Eventually he fell asleep on my chest again, so I sent Jane to bed. Half an hour later (about 3am) I tried to put him down. As soon as I got into bed and comfortable, he cried.

Changed and swaddled, I took him back out to the couch and he slept on my chest till 4.30am. I must have fallen asleep for the last half hour too.

I took him to the bedroom and attempted to put him down, but he cried. It was designated feed time anyway, so Jane got up to feed and settle him, then all three of us slept till 11am. A good, solid block of time. But I tell you what, I was still fucking tired.

Sunday was also our dog Lily’s first night home. It all went really well. She was a bit baffled by the crying but was a good girl. Can only imagine what it’ll be like when she hasn’t had enough exercise and Ollie has another night like that. Time will tell.

Hypercritical

Mon, 19 Nov 2012 13:23:27 +1100

Almost 100 episodes in and Hypercritical is ending. For me, this is sad news. Every Saturday morning I got a nerd fix—like Saturday morning cartoons for an adult.

Podcasts afford you the luxury of absorbing information without needing to actively seek it out; I absorbed more from Hypercritical than any other podcast.

Where else would I have learnt about high- and low-level programming languages or how Apple’s new Fusion Drive might actually work? It’s not that I couldn’t source the information elsewhere; it’s that I didn’t have to. It came to me once a week, every week.

John is the kind of nerd I want to listen to. Last week many people were taking, and writing, about Apple’s possible switch to ARM processors for Macs. Some think they will, others don’t. But no one else really explained why; John went into the history of RISC and CISC architecture, giving background—and therefore implicit explanation—that no one else seemed to.

The area of Mac nerd podcasts and blogs is often described as an echo chamber; however, Hypercritical is quite a few steps closer to the metal. And that’s why I’ll be sad when it ends.

SearchLink: Automated Markdown Linking →

Sun, 18 Nov 2012 09:24:32 +1100

Brett Terpstra seems to spend countless hours writing scripts that make menial and repetitive tasks quick and painless; SearchLink does just that. Brett:

SearchLink is a System Service for OS X that handles searching multiple sources and automatically generating Markdown links for text. It allows you to just write, marking things to link as you go. When you’re done, you run it on the document and — if your queries were good — have your links generated automatically without ever opening a browser.

It essentially means you can type [Brett Terpstra](!g) and—when run—it will grab the first Google result for the search term ‘Brett Terpstra’.

There are plenty of other arguments: (!wiki) searches Wikipedia, (!def) fetches a dictionary definition, (!yoursite.com) does a site search. It can even grab links to the Mac App Store and iTunes.

If your link text isn’t descriptive enough to return a good result, you can be more specific with search text after the argument. I.e. check [this](!g "SearchLink Brett Terpstra") out.

It requires the JSON Ruby Gem to be installed to the system version of Ruby. I’m using Ruby Version Manager so sudo gem install json didn’t work straight away. Josh Dick in the comments pointed out how to make it work with RVM:

Open the SearchLink.workflow file and change ‘Shell’ to /bin/zsh. Take the contents of the script and save it as SearchLink.rb somewhere, then replace the contents of the script in Automator with:

[[ -s $HOME/.rvm/scripts/rvm ]] && source $HOME/.rvm/scripts/rvm
ruby ~/path/to/SearchLink.rb

Remember to change the path to wherever you saved SearchLink.rb.

∞ Read this on andytaylor.me

HTML Entities or Decimals

Sat, 17 Nov 2012 10:05:54 +1100

I had issues with the RSS feed for this site. The feed validator was telling me that using a HTML entity like ‘ was invalid. I don’t know much about XML, but it seemed strange; I had escaped the character; I hadn’t just pasted in a ‘curly’ quotation mark.

Turns out XML doesn’t like some HTML entities. Using ∞ for the infinity symbol isn’t good enough, you need to use the HTML decimal ∞. However, it seems that using & for an ampersand is valid. XML is an indiscriminate beast.

I guess that’s why SmartyPants et al. convert characters to HTML decimals rather than entities; the decimal will always work, the entity won’t.

I’ve updated the character reference table on Style Manual accordingly.

Use Alfred.app to Create a New Jekyll Post →

Thu, 15 Nov 2012 12:26:22 +1100

So simple, so useful. Aaron created a simple shell script—executed with Alfred—that takes a ‘template’ Jekyll post, dates and names it, then moves it to a drafts folder.

I modified it slightly to work for my setup¹: Typing post post-slug into Alfred instantly opens a new post template in TextMate.

Pair this with my OS X service to insert the current date and time, and the friction is almost completely removed from creating a new post.

I don’t use a drafts folder. Instead I either use published: false or draft: true in the YAML Front Matter. The latter is a custom thing that does actually publish the post, but keeps it hidden from Index, Archive and RSS. The former is Jekyll default, and makes Jekyll ignore the post all together.
↩

∞ Read this on andytaylor.me