Tags: writing

529

sparkline

Wednesday, April 10th, 2019

Some Unsolicited Blogging Advice - daverupert.com

When you greet a stranger, look at his shoes.

Keep your money in your shoes.

Put your trouble behind.

When you greet a stranger, look at her hands.

Keep your money in your hands.

Put your travel behind.

Wednesday, March 20th, 2019

Very Dictionary. Because ‘very’ makes your writing stale.

Improve your word power:

Using ‘very’ + adjective makes your writing stale. This dictionary finds you a less dull, alternative word. It’ll help make your writing more convincing and engaging.

Friday, March 15th, 2019

Other people’s weeknotes

Paul is writing weeknotes. Here’s his latest.

Amy is writing weeknotes. Here’s her latest.

Aegir is writing weeknotes. Here’s his latest.

Nat is writing weeknotes. Here’s their latest.

Alice is writing weeknotes. Here’s her latest.

Mark is writing weeknotes. Here’s his latest.

I enjoy them all.

Sunday, March 10th, 2019

Regarding the Thoughtful Cultivation of the Archived Internet

Jason contemplates his two decades of blog posts, some of which he now feels very differently about:

Tim Berners-Lee’s idea that cool URIs don’t change is almost part of my DNA at this point, so deleting them seems wrong. Approximately no one ever reads any post on this site that’s more than a few years old, but is that an argument for or against deleting them? (If a tree falls in the woods, etc…) Should I delete but leave a note they were deleted? Should I leave the original posts but append updates citing my current displeasure?

Thursday, February 28th, 2019

Getting help from your worst enemy

Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.

Words become walls.

I love this post from Ben on the value of plain language!

We’re not dumbing things down by using simple terms. We’re being smarter.

Read on for the story of the one exception that Ben makes—it’s a good one.

Write on your own website | Brad Frost

Writing on your own website associates your thoughts and ideas with you as a person. Having a distinct website design helps strengthen that association. Writing for another publication you get a little circular avatar at the beginning of the post and a brief bio at the end of the post, and that’s about it. People will remember the publication, but probably not your name.

Monday, February 25th, 2019

Marty’s mashup

While the Interaction 19 event was a bit of a mixed bag overall, there were some standout speakers.

Marty Neumeier was unsurprisingly excellent. I’d seen him speak before, at UX London a few years back, so I knew he’d be good. He has a very reassuring, avuncular manner when he’s speaking. You know the way that there are some people you could just listen to all day? He’s one of those.

Marty’s talk at Interaction 19 was particularly interesting because it was about his new book. Now, why would that be of particular interest? Well, this new book—Scramble—is a business book, but it’s written in the style of a thriller. He wanted it to be like one of those airport books that people read as a guilty pleasure.

One rainy night in December, young CEO David Stone is inexplicably called back to the office. The company’s chairman tells him that the board members have reached the end of their patience. If David can’t produce a viable turnaround plan in five weeks, he’s out of a job. His only hope is to try something new. But what?

I love this idea!

I’ve talked before about borrowing narrative structures from literature and film and applying them to blog posts and conference talks—techniques like flashback, in media res, etc.—so I really like the idea of taking an entire genre and applying it to a technical topic.

The closest I’ve seen is the comic that Scott McCloud wrote for the release of Google Chrome back in 2008. But how about a romantic comedy about service workers? Or a detective novel about CSS grid?

I have a feeling I’ll be thinking about Marty Neumeier’s book next time I’m struggling to put a conference talk together.

In the meantime, if you want to learn from the master storyteller himself, Clearleft are running a two-day Brand Master Workshop with Marty on March 14th and 15th at The Barbican in London. Early bird tickets are on sale until this Thursday, so don’t dilly-dally if you were thinking about nabbing your spot.

Tuesday, February 19th, 2019

An Interview with Nick Harkaway: Algorithmic Futures, Literary Fractals, and Mimetic Immortality - Los Angeles Review of Books

Nick Harkaway on technology in fiction:

Humans without tools are not magically pure; they’re just unvaccinated, cold, and wet.

SF is how we get to know ourselves, either who we are or who we might be. In terms of what is authentically human, SF has a claim to be vastly more honest and important than a literary fiction that refuses to admit the existence of the modern and goes in search of a kind of essential humanness which exists by itself, rather than in the intersection of people, economics, culture, and science which is where we all inevitably live. It’s like saying you can only really understand a flame if you get rid of the candle. Good luck with that.

And on Borges:

He was a genius, and he left this cryptic, brilliant body of work that’s poetic, incomplete, astonishing. It’s like a tasting menu in a restaurant where they let you smell things that go to other tables and never arrive at yours.

Saturday, February 2nd, 2019

“It turns out” « the jsomers.net blog

It turns out that “it turns out” is a handy linguistic shortcut for making an unsubstaniated assertion.

Wednesday, January 16th, 2019

The World’s Writing Systems

What a lovely timeline of civilisation. This site makes for a nice companion piece to that database of dimensioned drawings—they’re both delightful to explore.

Signal v Noise exits Medium – Signal v. Noise

Traditional blogs might have swung out of favor, as we all discovered the benefits of social media and aggregating platforms, but we think they’re about to swing back in style, as we all discover the real costs and problems brought by such centralization.

Monday, January 14th, 2019

Writing for hiring

Cassie joined Clearleft as a junior front-end developer last year. It’s really wonderful having her around. It’s a win-win situation: she’s enthusiastic and eager to learn; I’m keen to help her skill up in any way I can. And it’s working out great for the company—she has already demonstrated that she can produce quality HTML and CSS.

I’m very happy about Cassie’s success, not just on a personal level, but also from a business perspective. Hiring people into junior roles—when you’ve got the time and ability to train them—is an excellent policy. Hiring Charlotte back in 2014 was Clearleft’s first foray into hiring for a junior front-end dev position and it was a huge success. Cassie is demonstrating that it wasn’t just a fluke.

Alas, we can’t only hire junior developers. We’ve got a lot of work in the pipeline right now and we’re going to need a full-time seasoned developer who can hit the ground running. That’s why Clearleft is recruiting for a senior front-end developer.

As lead developer, Danielle will make the hiring decision, but because she’s so busy on project work right now—hence the need to hire more people—I’m trying to help her out any way I can. I offered to write the job description.

Seeing as I couldn’t just write “A clone of Danielle, please”, I had to think about what makes for a great front-end developer who uses their experience wisely. But I didn’t want to create a list of requirements, and I certainly didn’t want to create a list of specific technologies.

My first instinct was to look at other job ads and take my cue from them. But, let’s face it, most job ads are badly written, and prone to turning into laundry lists. So I decided to just write like I normally would. You know, like a human.

Here’s what I wrote. I hope it’s okay. I don’t really have much to compare it to, other than what I don’t want it to be.

Have a read of it and see what you think. And if you’re an experienced front-end developer who’d like to work by the seaside, you should apply for the role.

Monday, December 31st, 2018

2018 in numbers

I posted to adactio.com 1,387 times in 2018: sparkline

In amongst those notes were:

In my blog posts, the top tags were:

  1. frontend and development (42 posts), sparkline
  2. serviceworkers (27 posts), sparkline
  3. design (20 posts), sparkline
  4. writing and publishing (19 posts), sparkline
  5. javascript (18 posts). sparkline

In my links, the top tags were:

  1. development (305 links), sparkline
  2. frontend (289 links), sparkline
  3. design (178 links), sparkline
  4. css (110 links), sparkline
  5. javascript (106 links). sparkline

When I wasn’t updating this site:

But these are just numbers. To get some real end-of-year thoughts, read posts by Remy, Andy, Ana, or Bill Gates.

How I write conference talks. — Ethan Marcotte

I can relate to Ethan’s 16-step process for writing conference talks.

Step 14 is the most important.

Saturday, December 29th, 2018

Words I wrote in 2018

I wrote just shy of a hundred blog posts in 2018. That’s an increase from 2017. I’m happy about that.

Here are some posts that turned out okay…

A lot of my writing in 2018 was on technical topics—front-end development, service workers, and so on—but I should really make more of an effort to write about a wider range of topics. I always like when Zeldman writes about his glamourous life. Maybe in 2019 I’ll spend more time letting you know what I had for lunch.

I really enjoy writing words on this website. If I go too long between blog posts, I start to feel antsy. The only relief is to move my fingers up and down on the keyboard and publish something. Sounds like a bit of an addiction, doesn’t it? Well, as habits go, this is probably one of my healthier ones.

Thanks for reading my words in 2018. I didn’t write them for you—I wrote them for me—but it’s always nice when they resonate with others. I’ll keep on writing my brains out in 2019.

Saturday, December 22nd, 2018

The ‘Future Book’ Is Here, but It’s Not What We Expected | WIRED

Craig writes about reading and publishing, from the memex and the dynabook to the Kindle, the iPhone, and the iPad, all the way back around to plain ol’ email and good old-fashioned physical books.

We were looking for the Future Book in the wrong place. It’s not the form, necessarily, that needed to evolve—I think we can agree that, in an age of infinite distraction, one of the strongest assets of a “book” as a book is its singular, sustained, distraction-free, blissfully immutable voice. Instead, technology changed everything that enables a book, fomenting a quiet revolution. Funding, printing, fulfillment, community-building—everything leading up to and supporting a book has shifted meaningfully, even if the containers haven’t. Perhaps the form and interactivity of what we consider a “standard book” will change in the future, as screens become as cheap and durable as paper. But the books made today, held in our hands, digital or print, are Future Books, unfuturistic and inert may they seem.

Sunday, December 16th, 2018

Oh Hello Ana - Blogging and me

A personal history of personal publishing from Ana—it’s wonderful!

When I was feeling low and alone I would recall how happy I used to be before I was working in tech. I would remember my silly fan sites, my experiments, my blogs and everything that I loved so much that made me become a developer.

Sunday, December 9th, 2018

What I Learned in Six Years at GDS ◆ 24 ways

Blogging about what you are working on is is really valuable for the writer because it forces you to think logically about what you are doing in order to tell a good story.

It’s also really valuable to blog about what you’ve learned, especially if you’ve made a mistake. It makes sure you’ve learned the lesson and helps others avoid making the same mistakes.

Thursday, December 6th, 2018

Mistletoe Offline

This article first appeared in 24 Ways, the online advent calendar for geeks.

It’s that time of year, when we gather together as families to celebrate the life of the greatest person in history. This man walked the Earth long before us, but he left behind words of wisdom. Those words can guide us every single day, but they are at the forefront of our minds during this special season.

I am, of course, talking about Murphy, and the golden rule he gave unto us:

Anything that can go wrong will go wrong.

So true! I mean, that’s why we make sure we’ve got nice 404 pages. It’s not that we want people to ever get served a File Not Found message, but we acknowledge that, despite our best efforts, it’s bound to happen sometime. Murphy’s Law, innit?

But there are some Murphyesque situations where even your lovingly crafted 404 page won’t help. What if your web server is down? What if someone is trying to reach your site but they lose their internet connection? These are all things than can—and will—go wrong.

I guess there’s nothing we can do about those particular situations, right?

Wrong!

A service worker is a Murphy-battling technology that you can inject into a visitor’s device from your website. Once it’s installed, it can intercept any requests made to your domain. If anything goes wrong with a request—as is inevitable—you can provide instructions for the browser. That’s your opportunity to turn those server outage frowns upside down. Take those network connection lemons and make network connection lemonade.

If you’ve got a custom 404 page, why not make a custom offline page too?

Get your server in order

Step one is to make …actually, wait. There’s a step before that. Step zero. Get your site running on HTTPS, if it isn’t already. You won’t be able to use a service worker unless everything’s being served over HTTPS, which makes sense when you consider the awesome power that a service worker wields.

If you’re developing locally, service workers will work fine for localhost, even without HTTPS. But for a live site, HTTPS is a must.

Make an offline page

Alright, assuming your site is being served over HTTPS, then step one is to create an offline page. Make it as serious or as quirky as is appropriate for your particular brand. If the website is for a restaurant, maybe you could put the telephone number and address of the restaurant on the custom offline page (unsolicited advice: you could also put this on the home page, you know). Here’s an example of the custom offline page for this year’s Ampersand conference.

When you’re done, publish the offline page at suitably imaginative URL, like, say /offline.html.

Pre-cache your offline page

Now create a JavaScript file called serviceworker.js. This is the script that the browser will look to when certain events are triggered. The first event to handle is what to do when the service worker is installed on the user’s device. When that happens, an event called install is fired. You can listen out for this event using addEventListener:

addEventListener('install', installEvent => {
// put your instructions here.
}); // end addEventListener

In this case, you want to make sure that your lovingly crafted custom offline page is put into a nice safe cache. You can use the Cache API to do this. You get to create as many caches as you like, and you can call them whatever you want. Here, I’m going to call the cache Johnny just so I can refer to it as JohnnyCache in the code:

addEventListener('install', installEvent => {
  installEvent.waitUntil(
    caches.open('Johnny')
    .then( JohnnyCache => {
      JohnnyCache.addAll([
       '/offline.html'
      ]); // end addAll
     }) // end open.then
  ); // end waitUntil
}); // end addEventListener

I’m betting that your lovely offline page is linking to a CSS file, maybe an image or two, and perhaps some JavaScript. You can cache all of those at this point:

addEventListener('install', installEvent => {
  installEvent.waitUntil(
    caches.open('Johnny')
    .then( JohnnyCache => {
      JohnnyCache.addAll([
       '/offline.html',
       '/path/to/stylesheet.css',
       '/path/to/javascript.js',
         '/path/to/image.jpg'
      ]); // end addAll
     }) // end open.then
  ); // end waitUntil
}); // end addEventListener

Make sure that the URLs are correct. If just one of the URLs in the list fails to resolve, none of the items in the list will be cached.

Intercept requests

The next event you want to listen for is the fetch event. This is probably the most powerful—and, let’s be honest, the creepiest—feature of a service worker. Once it has been installed, the service worker lurks on the user’s device, waiting for any requests made to your site. Every time the user requests a web page from your site, a fetch event will fire. Every time that page requests a style sheet or an image, a fetch event will fire. You can provide instructions for what should happen each time:

addEventListener('fetch', fetchEvent => {
// What happens next is up to you!
}); // end addEventListener

Let’s write a fairly conservative script with the following logic:

  • Whenever a file is requested,
  • First, try to fetch it from the network,
  • But if that doesn’t work, try to find it in the cache,
  • But if that doesn’t work, and it’s a request for a web page, show the custom offline page instead.

Here’s how that translates into JavaScript:

// Whenever a file is requested
addEventListener('fetch', fetchEvent => {
  const request = fetchEvent.request;
  fetchEvent.respondWith(
    // First, try to fetch it from the network
    fetch(request)
    .then( responseFromFetch => {
      return responseFromFetch;
    }) // end fetch.then
    // But if that doesn't work
    .catch( fetchError => {
      // try to find it in the cache
      caches.match(request)
      .then( responseFromCache => {
        if (responseFromCache) {
         return responseFromCache;
       // But if that doesn't work
       } else {
         // and it's a request for a web page
         if (request.headers.get('Accept').includes('text/html')) {
           // show the custom offline page instead
           return caches.match('/offline.html');
         } // end if
       } // end if/else
     }) // end match.then
   }) // end fetch.catch
  ); // end respondWith
}); // end addEventListener

I am fully aware that I may have done some owl-drawing there. If you need a more detailed breakdown of what’s happening at each point in the code, I’ve written a whole book for you. It’s the perfect present for Murphymas.

Hook up your service worker script

You can publish your service worker script at /serviceworker.js but you still need to tell the browser where to look for it. You can do that using JavaScript. Put this in an existing JavaScript file that you’re calling in to every page on your site, or add this in a script element at the end of every page’s HTML:

if (navigator.serviceWorker) {
  navigator.serviceWorker.register('/serviceworker.js');
}

That tells the browser to start installing the service worker, but not without first checking that the browser understands what a service worker is. When it comes to JavaScript, feature detection is your friend.

You might already have some JavaScript files in a folder like /assets/js/ and you might be tempted to put your service worker script in there too. Don’t do that. If you do, the service worker will only be able to handle requests made to for files within /assets/js/. By putting the service worker script in the root directory, you’re making sure that every request can be intercepted.

Go further!

Nicely done! You’ve made sure that if—no, when—a visitor can’t reach your website, they’ll get your hand-tailored offline page. You have temporarily defeated the forces of chaos! You have briefly fought the tide of entropy! You have made a small but ultimately futile gesture against the inevitable heat-death of the universe!

This is just the beginning. You can do more with service workers.

What if, every time you fetched a page from the network, you stored a copy of that page in a cache? Then if that person tries to reach that page later, but they’re offline, you could show them the cached version.

Or, what if instead of reaching out the network first, you checked to see if a file is in the cache first? You could serve up that cached version—which would be blazingly fast—and still fetch a fresh version from the network in the background to pop in the cache for next time. That might be a good strategy for images.

So many options! The hard part isn’t writing the code, it’s figuring out the steps you want to take. Once you’ve got those steps written out, then it’s a matter of translating them into JavaScript.

Inevitably there will be some obstacles along the way—usually it’s a misplaced curly brace or a missing parenthesis. Don’t be too hard on yourself if your code doesn’t work at first. That’s just Murphy’s Law in action.

Tuesday, December 4th, 2018

Mistletoe Offline ◆ 24 ways

They let me write a 24 Ways article again. Will they never learn?

This one’s a whirlwind tour of using a service worker to provide a custom offline page, in the style of Going Offline.

By the way, just for the record, I initially rejected this article’s title out of concern that injecting a Cliff Richard song into people’s brains was cruel and unusual punishment. I was overruled.