Tags: book

375

sparkline

Thursday, March 23rd, 2017

“What have they done to my library?” - Caitlin Moran

That library was a Pandorica of fabulous, interwoven randomness, as rich as plum cake. Push a seed of curiosity in between any two books and it would grow, overnight, into a rainforest hot with monkeys and jaguars and blowpipes and clouds. The room was full, and my head was full. What a magical system to place around a penniless girl.

Monday, March 6th, 2017

What should you think about when using Facebook? – Vicki Boykis

To be clear, every company currently does some form of this tracking of users. There would simply be no other way to measure operations. But Facebook has quite clearly been tiptoeing outside the bounds of what is ethically acceptable data business practices for a while.

A thorough round-up of Facebook’s current data collection practices and what you can do about it.

I swore I wouldn’t write another book - Web Designer Notebook

Thinking of writing a book? Here’s some excellent advice and insights from Yaili, who only went and wrote another one.

Let me say this first: writing a book is hard work. It eats up all of your free time and mental space. It makes you feel like you are forever procrastinating and producing very little. It makes you not enjoy any free time. It’s like having a dark cloud hanging over your head at all times. At. All. Times.

Thursday, February 16th, 2017

Be More Careful on Facebook | Incisive.nu

Much of our courage and support comes from the people we read and talk to and love online, often on the very networks that expose us—and our friends—to genuine enemies of freedom and peace. We have to keep connected, but we don’t have to play on their terms.

Monday, February 13th, 2017

Discovering Resilient Web Design with Jeremy Keith

In which I attempt to answer some questions raised in the reading of Resilient Web Design.

Tuesday, February 7th, 2017

Audio book

I’ve recorded each chapter of Resilient Web Design as MP3 files that I’ve been releasing once a week. The final chapter is recorded and released so my audio work is done here.

If you want subscribe to the podcast, pop this RSS feed into your podcast software of choice. Or use one of these links:

Or if you can have it as one single MP3 file to listen to as an audio book. It’s two hours long.

So, for those keeping count, the book is now available as HTML, PDF, EPUB, MOBI, and MP3.

Tuesday, January 31st, 2017

The Schedule and the Stream

Matt takes a look at the history of scheduled broadcast media—which all began in Hungary in 1887 via telephone—and compares it to the emerging media context of the 21st century; the stream.

If the organizing principle of the broadcast schedule was synchronization — millions seeing the same thing at the same time — then the organizing principle of the stream is de-contextualization — stories stripped of their original context, and organized into millions of individual, highly personalized streams.

Monday, January 16th, 2017

Bring on the Flood · thewalrus.ca

Most of these dystopian scenarios are, after all, post-apocalyptic: the bad thing happened, the tension broke, and now so much less is at stake. The anxiety and ambivalence we feel toward late-stage capitalism, income inequality, political corruption, and environmental degradation—acute psychological pandemics in the here and now—are utterly dissolved. In a strange, wicked way, the aftermath feels fine.

Wednesday, January 11th, 2017

Making Resilient Web Design work offline

I’ve written before about taking an online book offline, documenting the process behind the web version of HTML5 For Web Designers. A book is quite a static thing so it’s safe to take a fairly aggressive offline-first approach. In fact, a static unchanging book is one of the few situations that AppCache works for. Of course a service worker is better, but until AppCache is removed from browsers (and until service worker is supported across the board), I’m using both. I wouldn’t recommend that for most sites though—for most sites, use a service worker to enhance it, and avoid AppCache like the plague.

For Resilient Web Design, I took a similar approach to HTML5 For Web Designers but I knew that there was a good chance that some of the content would be getting tweaked at least for a while. So while the approach is still cache-first, I decided to keep the cache fairly fresh.

Here’s my service worker. It starts with the usual stuff: when the service worker is installed, there’s a list of static assets to cache. In this case, that list is literally everything; all the HTML, CSS, JavaScript, and images for the whole site. Again, this is a pattern that works well for a book, but wouldn’t be right for other kinds of websites.

The real heavy lifting happens with the fetch event. This is where the logic sits for what the service worker should do everytime there’s a request for a resource. I’ve documented the logic with comments:

// Look in the cache first, fall back to the network
  // CACHE
  // Did we find the file in the cache?
      // If so, fetch a fresh copy from the network in the background
      // NETWORK
          // Stash the fresh copy in the cache
  // NETWORK
  // If the file wasn't in the cache, make a network request
      // Stash a fresh copy in the cache in the background
  // OFFLINE
  // If the request is for an image, show an offline placeholder
  // If the request is for a page, show an offline message

So my order of preference is:

  1. Try the cache first,
  2. Try the network second,
  3. Fallback to a placeholder as a last resort.

Leaving aside that third part, regardless of whether the response is served straight from the cache or from the network, the cache gets a top-up. If the response is being served from the cache, there’s an additional network request made to get a fresh copy of the resource that was just served. This means that the user might be seeing a slightly stale version of a file, but they’ll get the fresher version next time round.

Again, I think this acceptable for a book where the tweaks and changes should be fairly minor, but I definitely wouldn’t want to do it on a more dynamic site where the freshness matters more.

Here’s what it usually likes like when a file is served up from the cache:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      return responseFromCache;
  }

I’ve introduced an extra step where the fresher version is fetched from the network. This is where the code can look a bit confusing: the network request is happening in the background after the cached file has already been returned, but the code appears before the return statement:

caches.match(request)
  .then( responseFromCache => {
  // Did we find the file in the cache?
  if (responseFromCache) {
      // If so, fetch a fresh copy from the network in the background
      event.waitUntil(
          // NETWORK
          fetch(request)
          .then( responseFromFetch => {
              // Stash the fresh copy in the cache
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      return responseFromCache;
  }

It’s asynchronous, see? So even though all that network code appears before the return statement, it’s pretty much guaranteed to complete after the cache response has been returned. You can verify this by putting in some console.log statements:

caches.match(request)
.then( responseFromCache => {
  if (responseFromCache) {
      event.waitUntil(
          fetch(request)
          .then( responseFromFetch => {
              console.log('Got a response from the network.');
              caches.open(staticCacheName)
              .then( cache => {
                  cache.put(request, responseFromFetch);
              });
          })
      );
      console.log('Got a response from the cache.');
      return responseFromCache;
  }

Those log statements will appear in this order:

Got a response from the cache.
Got a response from the network.

That’s the opposite order in which they appear in the code. Everything inside the event.waitUntil part is asynchronous.

Here’s the catch: this kind of asynchronous waitUntil hasn’t landed in all the browsers yet. The code I’ve written will fail.

But never fear! Jake has written a polyfill. All I need to do is include that at the start of my serviceworker.js file and I’m good to go:

// Import Jake's polyfill for async waitUntil
importScripts('/js/async-waituntil.js');

I’m also using it when a file isn’t found in the cache, and is returned from the network instead. Here’s what the usual network code looks like:

fetch(request)
  .then( responseFromFetch => {
    return responseFromFetch;
  })

I want to also store that response in the cache, but I want to do it asynchronously—I don’t care how long it takes to put the file in the cache as long as the user gets the response straight away.

Technically, I’m not putting the response in the cache; I’m putting a copy of the response in the cache (it’s a stream, so I need to clone it if I want to do more than one thing with it).

fetch(request)
  .then( responseFromFetch => {
    // Stash a fresh copy in the cache in the background
    let responseCopy = responseFromFetch.clone();
    event.waitUntil(
      caches.open(staticCacheName)
      .then( cache => {
          cache.put(request, responseCopy);
      })
    );
    return responseFromFetch;
  })

That all seems to be working well in browsers that support service workers. For legacy browsers, like Mobile Safari, there’s the much blunter caveman logic of an AppCache manifest.

Here’s the JavaScript that decides whether a browser gets the service worker or the AppCache:

if ('serviceWorker' in navigator) {
  // If service workers are supported
  navigator.serviceWorker.register('/serviceworker.js');
} else if ('applicationCache' in window) {
  // Otherwise inject an iframe to use appcache
  var iframe = document.createElement('iframe');
  iframe.setAttribute('src', '/appcache.html');
  iframe.setAttribute('style', 'width: 0; height: 0; border: 0');
  document.querySelector('footer').appendChild(iframe);
}

Either way, people are making full use of the offline nature of the book and that makes me very happy indeed.

Monday, January 9th, 2017

Resilient Web Design | susan jean robertson

Well, this is nice! Susan has listed the passages she highlighted from Resilient Web Design.

In the spirit of the book, I read it in a browser, and I broke up my highlights by chapters. As usual, you should read the book yourself, these highlights are taken out of context and better when you’ve read the whole thing.

Tuesday, January 3rd, 2017

What I Read in 2016 - TimKadlec.com

Tim’s book recommendations have always been solid. Here’s his year-end list. I’m honoured that he not only read Resilient Web Design but also gave it all the stars.

Indie Microblogging: owning your short-form writing by Manton Reece — Kickstarter

Here’s an interesting Kickstarter project: a book about owning your notes (and syndicating them to Twitter) to complement the forthcoming micro.blog service.

Monday, January 2nd, 2017

2016 reading list

I was having a think back over 2016, trying to remember which books I had read during the year. To the best of my recollection, I think that this is the final tally…

Non-fiction

  • Endurance by Alfred Lansing
  • The Rational Optimist by Matt Ridley
  • The Real World of Technology by Ursula Franklin
  • Design For Real Life by Eric Meyer and Sara Wachter-Boettcher
  • Practical SVG by Chris Coyier
  • Demystifying Public Speaking by Lara Hogan
  • Working The Command Line by Remy Sharp

Fiction

  • The Revenant by Michael Punke
  • The Adjacent by Christopher Priest
  • Helliconia Spring by Brian Aldiss
  • High Rise by J.G. Ballard
  • The Affirmation by Christopher Priest
  • Brodeck’s Report by Philippe Claudel
  • Greybeard by Brian Aldiss
  • Fictions by Jorge Luis Borges
  • The Long Way to a Small Angry Planet by Becky Chambers
  • The Dark Forest by Cixin Liu
  • Death’s End by Cixin Liu
  • The First Fifteen Lives of Harry August by Claire North

Seems kinda meagre to me. Either I need to read more books or I need to keep better track of what books I’m reading when. Starting now.

Sunday, January 1st, 2017

In Praise of On Resilient Web Design by Jeremy Keith

I’m really touched—and honoured—that my book could have this effect.

It made me fall back in love with the web and with making things for the web.

Front-end Style Guides by Anna Debenham

Anna has just published a lovely new version of her excellent little book on pattern libraries. EPUB, MOBI, and PDF versions are yours for a mere $8.

Wednesday, December 28th, 2016

Radical Technologies: The Design of Everyday Life, now available for pre-order | Adam Greenfield’s Speedbird

Adam Greenfield’s new book is almost here at last, and it sounds like it has pivoted into quite an interesting beast.

The many formats of Resilient Web Design

If you don’t like reading in a web browser, you might like to know that Resilient Web Design is now available in more formats.

Jiminy Panoz created a lovely EPUB version. I tried it out in Apple’s iBooks app and it looks great. I tried to submit it to the iBooks store too, but that process threw up a few too many roadblocks.

Oliver Williams has created a MOBI version. That’s means you can read it on a Kindle. I plugged my old Kindle into my computer, dragged that file onto its disc image, and it worked a treat.

And there’s always the PDF versions; one in portrait and another in landscape format. Those were generated straight from the print styles.

Oh, and there’s the podcast. I’ve only released two chapters so far. The Christmas break and an untimely cold have slowed down the release schedule a little bit.

I’d love to make a physical, print-on-demand version of Resilient Web Design available—maybe through Lulu—but my InDesign skills are non-existent.

If you think the book should be available in any other formats, and you fancy having a crack at it, please feel free to use the source files.

SF Mistressworks | women science fiction writers

Reviews of twentieth century science fiction novels and anthologies by women writers.

Monday, December 26th, 2016

High Performance Browser Networking (O’Reilly)

Did you know that Ilya’s book was available in its entirety online? I didn’t. But now that I do, I think it’s time I got stuck in and tried to understand the low-level underpinnings of the internet and the web.

Monday, December 19th, 2016

Deep linking with fragmentions

When I was marking up Resilient Web Design I wanted to make sure that people could link to individual sections within a chapter. So I added IDs to all the headings. There’s no UI to expose that though—like the hover pattern that some sites use to show that something is linkable—so unless you know the IDs are there, there’s no way of getting at them other than “view source.”

But if you’re reading a passage in Resilient Web Design and you highlight some text, you’ll notice that the URL updates to include that text after a hash symbol. If that updated URL gets shared, then anyone following it should be sent straight to that string of text within the page. That’s fragmentions in action:

Fragmentions find the first matching word or phrase in a document and focus its closest surrounding element. The match is determined by the case-sensitive string following the # (or ## double-hash)

It’s a similar idea to Eric and Simon’s proposal to use CSS selectors as fragment identifiers, but using plain text instead. You can find out more about the genesis of fragmentions from Kevin. I’m using Jonathon Neal’s script with some handy updates from Matthew.

I’m using the fragmention support to power the index of the book. It relies on JavaScript to work though, so Matthew has come to the rescue again and created a version of the site with IDs for each item linked from the index (I must get around to merging that).

The fragmention functionality is ticking along nicely with one problem…

I’ve tweaked the typography of Resilient Web Design to within an inch of its life, including a crude but effective technique to avoid widowed words at the end of a paragraph. The last two words of every paragraph are separated by a UTF-8 no-break space character instead of a regular space.

That solves the widowed words problem, but it confuses the fragmention script. Any selected text that includes the last two words of a paragraph fails to match. I’ve tried tweaking the script, but I’m stumped. If you fancy having a go, please have at it.

Update: And fixed! Thanks to Lee.