Tuesday is Link Day!

Performance

Presentation on “Smaller, faster websites” by Mat Marquis: https://bocoup.com/weblog/smaller-faster-websites

The website obesity crisis (presentation): http://idlewords.com/talks/website_obesity.htm

What developers should know about performance: https://medium.com/@christophelimpalair/developers-what-you-should-know-about-web-performance-550cef1040d8

What I’ve learned from monitoring four years of web page bloat: http://www.soasta.com/blog/page-bloat-2015-web-performance-monitoring/

Articles about how web performance affects revenue: https://wpostats.com/tags/revenue/

Avoiding Temptations that Harm Website Performance: http://calendar.perfplanet.com/2015/avoiding-temptations-that-harm-website-performance/

Progressive enhancement

Jeremy Keith hits a million nails on the head: “Server-side rendering is not a fallback; client-side rendering is an enhancement.” https://adactio.com/journal/9963

What “progressive web apps” mean for the web: http://developer.telerik.com/featured/what-progressive-web-apps-mean-for-the-web/

Interaction is an enhancement – an excerpt from Aaron Gustafson’s new book: http://alistapart.com/article/interaction-is-an-enhancement

The article that first described progressive enhancement: http://hesketh.com/progressive_enhancement_and_the_future_of_web_design.html

Reimagining Single-Page Applications With Progressive Enhancement: http://www.smashingmagazine.com/2015/12/reimagining-single-page-applications-progressive-enhancement/

Accessibility

The modern web is broken for people with disabilities: https://www.thoughtworks.com/insights/blog/modern-web-fundamentally-broken-people-disabilities

Mozilla accessibility QA engineer tells us what the basics of accessibility are: https://www.marcozehe.de/2015/12/14/the-web-accessibility-basics/

Learn about accessibility in just 20 minutes: http://accessibility.parseapp.com/

On accessibility and the lack of proper HTML: http://www.iandevlin.com/blog/2016/01/opinion/on-accessibility-and-the-lack-of-proper-html

Free web accessibility tools round-up: https://medium.com/bread-crumbs/free-web-accessibility-tools-round-up-b83a33797789

Mobile

Why you shouldn’t bother creating a mobile app: https://medium.com/inside-birdly/why-you-shouldn-t-bother-creating-a-mobile-app-328af62fe0e5

The App-ocalypse: Can Web standards make mobile apps obsolete?: http://arstechnica.com/information-technology/2015/12/the-app-ocalypse-can-web-standards-make-mobile-apps-obsolete/

Instant Loading Web Apps with An Application Shell Architecture: https://developers.google.com/web/updates/2015/11/app-shell

Design/UX

Dark Patterns: fighting user deception worldwide: http://darkpatterns.org/

A rant: how are website still screwing up these user experiences: http://www.troyhunt.com/2016/01/its-2016-already-how-are-websites-still.html

Simple inline error message pattern: https://www.paciellogroup.com/blog/2016/01/simple-inline-error-message-pattern/

Three principles for using design successfully. No 1: Start with design, and don’t just end with it: http://blogs.wsj.com/accelerators/2014/02/21/john-maeda-three-principles-for-using-design-successfully/

Brad Frost is writing a book on Atomic Design, which you can read for free here: http://atomicdesign.bradfrost.com/

How to make sense of any mess, a free online book on information architecture: http://www.howtomakesenseofanymess.com/

Beyond the style guide: https://24ways.org/2015/beyond-the-style-guide/

How to do a UX review: https://24ways.org/2015/how-to-do-a-ux-review/

Business

Psychological pricing strategies (mammoth set of tactics!): http://www.nickkolenda.com/psychological-pricing-strategies/

The perfect storm in digital law: http://alistapart.com/article/the-perfect-storm-in-digital-law

What customer experience excellence looks like: “Customer experience is 10% technology and 90% culture”: http://www.gerrymcgovern.com/new-thinking/what-customer-experience-excellence-looks

Helping VIPs care about performance: https://24ways.org/2015/helping-vips-care-about-performance/

Teams/general development

Rachel Andrew on confidence and getting overwhelmed: https://medium.com/@rachelandrew/web-industry-confidence-and-overwhelm-e161313405c8

What RESTful actually means: https://codewords.recurse.com/issues/five/what-restful-actually-means

What do we ask in Stack Overflow: http://jkunst.com/r/what-do-we-ask-in-stackoverflow/

Yahoo gets rid of QA: http://spectrum.ieee.org/view-from-the-valley/computing/software/yahoos-engineers-move-to-coding-without-a-net

JavaScript

A useful JavaScript glossary: https://github.com/HugoGiraudel/SJSJ

Microsoft open sourcing the Chakra JavaScript engine: https://blogs.windows.com/msedgedev/2015/12/05/open-source-chakra-core/

An “operating system”, with lots of apps, in JS: http://os.js.org/

“Every JavaScript project you should be looking into”: http://www.javascriptoo.com/

Amiga emulator in JavaScript, with games: http://scriptedamigaemulator.net/

The service worker cookbook: “a collection of working, practical examples of using service workers in modern web apps”: https://serviceworke.rs

You don’t need jQuery: https://github.com/oneuijs/You-Dont-Need-jQuery

4 JavaScript design patterns you should know: https://scotch.io/bar-talk/4-javascript-design-patterns-you-should-know

Use React? here’s a cheat sheet: http://reactcheatsheet.com/

CSS

Flexbox Froggy – learn flexbox with a fun game: http://flexboxfroggy.com/

Flexbox support is pretty good, except for IE: http://caniuse.com/#feat=flexbox

And there’s now an IE 8/9 polyfill: https://github.com/10up/flexibility

Web components that can be built purely using css, NO Javascript: http://technical.nailfashionsweden.se/web-components-that-can-be-built-purely-using-css-no-javascript/

“Just add water” CSS animations: https://daneden.github.io/animate.css/

Tools and resources

Security Panel debuts in Chrome DevTools: https://developers.google.com/web/updates/2015/12/security-panel

Dictionaries and Word Lists for Programmers: http://organicdonut.com/2015/12/dictionaries-and-word-lists-for-programmers/

Some good videos to watch, mostly JavaScript: http://fettblog.eu/top-talks-to-watch-2015/

Big list of “free for development” services: https://github.com/ripienaar/free-for-dev

Use console.table for easier logging: https://umaar.com/dev-tips/82-console-table/

SpaceHolder – A space-themed image placeholder service: https://spaceholder.cc/

How to use Chrome DevTools like a Pro: https://medium.com/jotform-form-builder/how-to-use-chrome-devtools-like-a-pro-b9bd414870e3

Each year this online advent calendar has fantastic articles: https://24ways.org

And so does this performance-specific advent calendar: http://calendar.perfplanet.com/

And finally

History of the web: http://www.w3.org/2012/08/history-of-the-web/origins.htm

See websites in old – I mean REALLY old – browsers: http://oldweb.today/WWW/20151225064327/http://info.cern.ch/hypertext/WWW/TheProject.html

GCHQ going open source? https://github.com/GovernmentCommunicationsHeadquarters

zty.pe, a typing game: http://zty.pe/

For the geek in your life: Star Wars Kama Sutra: http://www.amazon.com/dp/1519483058/

Unit testing in WordPress

One of the things I really appreciate about developing in the .Net stack is the fantastic unit test support. Using mocking libraries like moq and leaning on the power of nunit to handle my dependencies means I can write unit tests that truly do test just the unit under test. True unit tests are useful for three very important reasons:

  1. That the code is doing what it should
  2. That the code handles unexpected inputs correctly
  3. That after refactoring the code continues to do what it did before

A robust, extensive suite of tests – both unit and integration tests – are crucial for good quality software and, fortunately, have been pretty common in the .Net development world for a long while.

When developing for WordPress, however, it’s not always been that way. I remember not so many years ago that test of any kind wasn’t something often talked about in the WordPress community. I guess we were focussed on getting code shipped.

Things have changed, and automated testing is now a recognised part of the WordPress development workflow. One of the problems with the WordPress Unit Test Suite, as pointed out by Greg Boone, is that it’s not actually a suite of unit tests – it has dependencies like a MySQL database, so would be more correctly called a suite of integrations tests. Pippin also calls these kind of tests “unit”, but they are definitely integration tests.

I’m at risk of over-egging this point, so please read this good description of the difference between unit and integration tests.

To ensure the large WordPress plugin I’m currently building is as good as it can be I want to build a suite of (true) unit tests. That means I need way of mocking WordPress functions (such as do_action, apply_filters and wp_insert_post) and globals such as $current_user and – crucially – $wpdb. It turns out there are a few options, which I’ve briefly investigated. I’ll be using WP_Mock and the PHPUnit test double features.

The well-known WP_Mock from the clever guys at 10up is the backbone of mocking WordPress. It allows you to mock any WordPress function with some simple syntax:

\WP_Mock::wpFunction( 'get_permalink', array(
            'args' => 42,
            'times' => 1,
            'return' => 'http://example.com/foo'
        ) );

This will mock the get_permalink method when the only argument is the integer 42, ensuring it is only called once, and returning the string ‘http://example.com/foo’. Clever stuff.

There are other static methods in the WP_Mock class which allow you to:

  • Mock a method which returns the same value (a pass-through method)
  • Mock the calling of filters and actions
  • Mock the setting of actions and filters

Mocking $wpdb turns out to be pretty simple, as I can use the built-in test double functionality in PHPUnit. Sample code in the MockPress project wiki shows I can do this:

// in my test setUp method:
global $wpdb;
unset($wpdb);

// whenever I want to mock a $wpdb function I set up the method to mock:
$wpdb = $this->getMock('wpdb', array('get_var'));
// and set the value I want to be returned from my mock method:
$wpdb->expects($this->once())->method('get_var')->will($this->returnValue(1);

// now I can check the mock returns what I want:
$result = $wpdb->get_var("select anything from anywhere");
$this->assertEquals(1, $result);

I now just have to ensure my code is written in such a way as to make unit testing easy! I can highly recommend The Art of Unit Testing by Roy Osherove if you want to get into this deeply.

WordPress Calypso

Recently Automattic have announced the release of Calypso, a next-generation interface to manage WordPress.com or Jetpack-enabled sites. It’s a very ambitious project, but I believe they have some of the best developers in the world. Plus Andy Peatling, who I’ve had a huge amount of respect for since he initiated the BuddyPress project, ran the team.

The interesting thing for developers is their choice of technology stack. Calypso is a single-page app, powered by Facebook’s React library, node.js, with data coming from the WordPress REST API. All mod cons, and the interface is certainly beautiful, easy to use and very fast.

But I have to admit I have concerns about single-page apps, and the “modern” approach of total reliance on JavaScript to power a UI. JavaScript is the least robust of the Holy Trinity of web technologies (HTML, CSS and JavaSscript) as it does not gracefully handle errors. Many sites fall into the trap of thinking they can rely on JavaScript when they can’t. CSS is in the same boat, although if you get *some* CSS then whatever you get will be used to style the page. If you get just *some* JavaScript the likelihood is that nothing will work. It’s clear that the only resource which we can really count on – and even then, it’s not 100% guaranteed – is the HTML.

So, using my favourite progressive enhancement testing tool (turning off JavaScript), what do you see in Calypso when javaScript fails? This:
no-js

Unfortunately there’s nothing there, just the WordPress logo. Perhaps showing the “unsupported” message by default would be better, as this is what the Calypso app redirects to wordpress.com/browsehappy if the browser doesn’t support some modern JavaScript APIs or is iOS version 5 or earlier.

Here’s the (JavaScript) code that checks whether the browser cuts the mustard, with comments from me:

(function() {
    function isSupported() {
        var ios, version, ua;
        ua = window.navigator.userAgent;
        // check if the browser supports window.history, which allows changing the displayed URL without refreshing the page
        if ( ! window.history ||
            ! window.history.pushState ||
            ! window.history.replaceState ||
            ! ( '__proto__' in Object.prototype )
        ) {
            return false;
        }
        function getFirstMatch( regex ) {
            var match = ua.match( regex );
            return ( match && match.length > 1 && match[1] ) || '';
        }
        ios = getFirstMatch( /(ipod|iphone|ipad)/i ).toLowerCase();
        version = getFirstMatch( /version\/(\d+(\.\d+)? )/i );
        // check if the browser looks like iOS version 5 or earlier
        if ( ios && version < 6 ) {
        // disable for now because it is breaking Chrome on iOS
        //return false;
        }
        // if we get here we know we can run the app
        return true;
    }
    if ( ! isSupported() ) {
        window.location = 'https://wordpress.com/browsehappy?url=' + encodeURIComponent( window.location );
    }
})();

And this is the “unsupported” message (with cute Nessie image):
unsupported

OK, on to performance. As I’ve mentioned Calypso feels really fast. One of the principles for the project was speed, and it shows. It’s also responsive, which for a powerful “app” such as this is no mean feat.

The resource stats show that it’s pretty big, however (this is from Google Chrome dev tools for a new post edit page):

all-resources

The breakdown of requests shows a large amount of JavaScript (as you’d expect) and quite a lot of CSS:

Resource type Requests Total filesize
All 93 1.9mb
HTML 1 2.2kb
CSS 22 322kb
JavaScript 17 1.4mb
Images 12 13.5kb
Fonts 17 137kb

I was surprised at the amount of web fonts, which led me to look at the dependencies on other domains. Here’s how that breaks down (again, this is for a edit post page):

Domain Requests Description
gravatar.com 7 Avatars
fonts.googleapis.com 5 Web font stylesheets
fonts.gstatic.com 11 Web fonts
wp.com 34 Stats collection, jQuery, stylesheets, favicons and widget HTML
wordpress.com 13 Stylesheets, main JavaScript files
google-analytics.com 2 Analytics tracking
olark.com 1 Chat facility, presumably for customer support

I ignored subdomains and XHR requests (which are the requests to the API to get data) for this table.

Better stats that don’t rely on me manually counting rows in dev tools could be got from WebPageTest, and I may do that when I figure out how to get WebPageTest to log in to Calypso.

My conclusion from this very quick investigation is that while Calypso is a very slick web app (whatever “web app may mean) its total reliance on JavaScript means it could easily break for users on low-powered devices or using it dodgy network conditions. If the aim of WordPress is to democratise publishing then this has to be for users is the worst of browsing scenarios as well as those of us lucky enough to have fast machines, modern browsers, and fast and stable networks.

My belief is that the WordPress team know this, and that work is already under way inside Automattic to enable things like server-side rendering and handling of POST requests. And, in the mean time, the classic admin interface is still available.

What this means for the huge plugin ecosystem will be very interesting to find out. That’s a topic for another post!

Crash Test Dummies

Crash test dummie reading "Crash Testing for Dummies"No, this isn’t a post about the band. It’s about real crash testing, also known as progressive enhancement testing.

Of course, this had to be Another Progressive Enhancement Post, didn’t it!

Ever thought about why car manufacturers test their cars under crash conditions? Is it because people deliberately drive their cars into walls or ditches? No; not usually, anyway. They test the safety of their cars because we live in an unpredictable world where things go wrong, all the time. Exceptional circumstances surround us every single day. Often we experience near misses – sometimes we’re no so lucky.

In fact, things go wrong on the roads so often that we’ve created thousands laws and guidelines that try to minimise the possibility of these exceptional circumstances occurring. We have speed limits and training before anyone can get behind the wheel of a car. We have street lighting and pedestrian crossings, kerbstones and crash barriers.

Yet things still go wrong on our roads. Sometimes through carelessness and stupidity, sometimes though negligence. Sometimes the blame can’t really be applied to anyone in particular.

Car manufacturers invest in making their cars safe, so that when the unexpected happens – which, at some point, it will – the occupants and other road users are kept as safe as possible. We expect nothing less, and safety features are rightly promoted to help sell cars. That’s good; we should strive to create a safer world where possible.

Yet on the web it’s a different story. No-one believes that things never go wrong online. In fact in my experience there’s rarely a web browsing session where something didn’t break. Images fail to load, sites respond so slowly they appear to be down, JavaScript throws an error because two scripts from different 3rd parties can’t co-exist, web fonts don’t load and so text is invisible. The list of what could – and often does – go wrong when loading websites goes on, and on, and on.

What’s happening here? Do we as web developers, designers, business owners not realise the inherent unpredictability of the Internet? Do we not understand that the web was designed to be like this – to keep going even if all that is delivered to the browser is the HTML? No, many of us understand but sweep this reality under the carpet.

We are dummies.

We’re dummies because we chase after the latest JavaScript framework-du-jour without considering if it supports the core principles of the web. We overload our pages with unoptimised images and gargantuan CSS files generated by a pre-processor. We fail to deliver first and foremost what our users fundamentally require – the content.

We’re dummies because we leave the crash testing to our users – the very people we should be protecting from those exceptional circumstances! And then we have the gall to complain that they aren’t using the latest browser or operating system, or that their device is underpowered. Here’s the reality for you: even when browsing conditions are optimal, things still often go wrong.

So, in my opinion are JavaScript frameworks bad? Do I detest CSS pre-processors? Do I have an allergy to beautiful imagery online? No, of course not. It’s our use of these tools which I rail against. Enhance your pages as mush as you want, but start from the beginning. Semantic HTML content and forms.

Don’t be a dummy.

Sunday is Link Day!

Business / project management

“Case studies and experiments demonstrating the impact of performance optimization on user experience and business metrics.”: http://wpostats.com/

It’s always the right time to revisit the beans-up-noses article: https://medium.com/uie-brain-sparks/beans-and-noses-21c16ac5cade

Uncle Bob chimes in on Volkswagen: http://blog.8thlight.com/uncle-bob/2015/10/14/VW.html

“Welcome to Traction Stack, a curated directory of marketing resources from six years of research for Traction, the bestselling book that helps businesses and projects of all kinds get traction.”: http://tractionstack.com/

Prevent feature creep: http://www.productstrategymeanssayingno.com/

How to avoid personalisation project pitfalls: https://econsultancy.com/blog/66819-how-to-avoid-personalisation-project-pitfalls/

Mobile

Google tells business leaders not to concentrate on mobile apps: http://uk.businessinsider.com/google-exec-says-mobile-apps-confuse-consumers-2015-11

And the stats show that hoping your mobile app will become popular is like hoping you’ll win the lottery: https://medium.com/swlh/mobile-app-developers-are-suffering-a5636c57d576

Case study on having push notifications in a web app: https://developers.google.com/web/showcase/case-study/beyond-the-rack

A good overview of the different ways of implementing web apps for mobile: https://medium.com/@franciov/installable-pinned-or-progressive-apps-5b4997ecbf49

Wait, what? Mobile browser traffic is 2X bigger than app traffic, and growing faster: http://venturebeat.com/2015/09/25/wait-what-mobile-browser-traffic-is-2x-bigger-than-app-traffic-and-growing-faster/

A publishing company abandons native apps: https://atavistinsider.atavist.com/goodbye-native-mobile-apps/

Design

From pages to patterns – practical tips for moving to modular design: http://alistapart.com/article/from-pages-to-patterns-an-exercise-for-everyone

Lovely UI: a collection of mobile UI elements: http://www.lovelyui.com/

Loads of responsive navigation examples: http://navnav.co/

Not sure if I’ve linked to this Designing for Performance book; if not I apologise: http://designingforperformance.com/

Using web fonts the best way: https://helloanselm.com/2015/using-webfonts-in-2015/

gov.uk design principles: https://www.gov.uk/design-principles

Even the U.S. government has a style guide now: https://playbook.cio.gov/designstandards/

Design thinking comes of age: https://hbr.org/2015/09/design-thinking-comes-of-age

Web field manual – lots of good design resources: http://webfieldmanual.com/

Performance

Adding custom performance metrics: https://speedcurve.com/blog/user-timing-and-custom-metrics/

Transcript and slides for Scott Jehl’s talk “Delivering Responsibly”: https://www.filamentgroup.com/lab/delivering-responsibly.html

Fantastic idea – Facebook will slow down their network every Tuesday so employees can experience the web as most of the world does: http://uk.businessinsider.com/facebook-2g-tuesdays-to-slow-employee-internet-speeds-down-2015-10?op=1?r=US&IR=T

The ad industry is starting to realise they are a big part of the performance problem: http://www.iab.com/news/lean/

Consumers still value performance over content: http://www.marketingcharts.com/online/consumers-still-value-performance-over-content-in-the-website-experience-60553/attachment/limelight-consumer-website-experience-expectations-oct2015/

Zeldman, the godfather of the web, reflects on performance over the years: http://www.zeldman.com/2015/10/21/web-performance-today/

Great front-end performance primer for full-stack (i.e. back-end) devs: http://www.nateberkopec.com/2015/10/07/frontend-performance-chrome-timeline.html

Calculate a performance budget: http://www.performancebudget.io/

Web font anti-patterns: http://bramstein.com/writing/web-font-anti-patterns.html

Accessibility

Ever wondered what screen readers actually sound like? Here: http://thepaciellogroup.github.io/AT-browser-tests/

Accessibility wins – showcasing good accessibility: http://a11ywins.tumblr.com/

Using the tabindex attribute: https://www.paciellogroup.com/blog/2014/08/using-the-tabindex-attribute/

A11y Rocks! An album for accessibility: https://heydon.selz.com/item/560c04b8b798720c187917e6

Simple guide to web accessibility testing: http://www.softwaretestinghelp.com/what-is-web-accessibility-testing/

Super-quick accessibility testing – just add a CSS file: http://www.karlgroves.com/2013/09/07/diagnostic-css-super-quick-web-accessibility-testing/

Progressive enhancement

Jake Archibald on implementing modern progressive enhancement: https://vimeo.com/144768071

Flipkart changed from having a native app to a progressive website: http://tech-blog.flipkart.net/2015/11/progressive-web-app/

Building an offline page for the Guardian: https://www.theguardian.com/info/developer-blog/2015/nov/04/building-an-offline-page-for-theguardiancom

There are no “buts” in progressive enhancement (slides): http://www.slideshare.net/AaronGustafson/there-are-no-buts-in-progressive-enhancement-redev-2015

Jason Garber bangs on about it. You must be getting the message by now, yes? http://sixtwothree.org/posts/designing-experience-layers

Good collection of resources: http://dsgnwrks.pro/resources/why-you-we-should-care-about-disabled-javascript/

A big deal: Google advocates progressive enhancement to help with SEO: http://googlewebmastercentral.blogspot.co.uk/2015/10/deprecating-our-ajax-crawling-scheme.html

Resources, tools, libraries, all that good stuff

Bing have a mobile friendliness checker: https://blogs.bing.com/webmaster/2015/11/12/mobile-friendly-test

There’s a whole new post-CMS world out there: http://www.thenewdynamic.org/

“The one-stop place to find the information and tools you need to help you learn, build, and move the web forward.”: http://www.w3.org/developers/

Fantastic interactive site showcasing Firefox’s dev tools: http://devtoolschallenger.com/

See who’s tracking you online with this Firefox add-on: https://www.mozilla.org/en-US/lightbeam/

Firefox also have a really useful screenshot command: http://meyerweb.com/eric/thoughts/2015/10/22/firefoxs-screenshot-command/

The search engine for source code: http://nerdydata.com/ (limited results, but I quickly found a site using one of my Open Source libraries)

Load testing for websites and APIs: https://loadfocus.com

An image comparison tool, can be put into a build process to check for visual regression: http://yahoo.github.io/blink-diff/

Passwordless authentication: https://auth0.com/blog/2015/09/30/auth0-passwordless-email-authentication-and-sms-login-without-passwords/

Lots of documentation in one place: http://devdocs.io/

Geek life

What’s that? A browser API for taking payments? Yes please: https://github.com/WICG/web-payments-browser-api

New HTML elements proposed: <panel> and <panelset>: http://radar.oreilly.com/2015/11/panels-and-panel-sets.html

A think-piece on the changing form of the browser: http://rehabstudio.com/thinking/the-changing-form-of-the-web-browser/

Technical debt: more than just code: https://the-pastry-box-project.net/kate-daly/2015-October-11

FLIF – free lossless image format: http://flif.info/

HTTP is obsolete. It’s time for the distributed, permanent web: https://blog.neocities.org/its-time-for-the-permanent-web.html

Google is 2 billion lines of code, in one repository: http://www.wired.com/2015/09/google-2-billion-lines-codeand-one-place/

Designing for accountability, designing for broken-ness: http://russelldavies.typepad.com/planning/2015/09/designing-for-accountability-designing-for-broken-ness.html

Development

Guidelines on implementing REST, from the NSA (TL;DNR: put a back-door in it for us … not really :0): http://jaco.by/2015/11/06/the-nsas-guidelines-for-implementation-of-rest/

The Terence McGhee Software Ninja Class Hierarchy: http://terencemcghee.com/FileStore/Tech/1D0C454A70AC3AEF01BB1BAAD94C8753.html

Uncle Bob on making things future proof: http://blog.8thlight.com/uncle-bob/2015/10/30/futureproof.html

Is programming poetry? https://medium.com/unpublishable-elsewhere/is-programming-poetry-aa137a2ac3ca#.gb2egezd1

Who Dictates Software Quality: Client or Coder?: http://www.bitnative.com/2014/01/28/who-chooses-quality-client-or-coder/

Front-end developer handbook: http://www.frontendhandbook.com/

The configuration complexity clock: http://mikehadlow.blogspot.dk/2012/05/configuration-complexity-clock.html

Programming sucks: http://www.stilldrinking.org/programming-sucks

CSS

Experiments from Jen Simmons: http://labs.thewebahead.net/

Create and maintain style guides using CSS comments: https://github.com/jonathantneal/mdcss

Nice example of a generic CSS system: http://corpuscss.com/

Making the cascade your friend: http://simurai.com/blog/2015/09/09/back-to-the-roots/

Free e-book – transforms in CSS by Eric Meyer: http://www.oreilly.com/free/transforms-in-css.csp

Flexbox cheatsheet: http://jonibologna.com/flexbox-cheatsheet/

JavaScript

Some useful JavaScript utilities, including a C#-like stringFormat: https://github.com/michd/js-util

Making a site work offline with Service Worker: https://css-tricks.com/serviceworker-for-offline/

Using the oninput event handler with onkeyup/onkeydown as its fallback: https://mathiasbynens.be/notes/oninput (note to self: do this)

Stats on the performance of different JavaScript frameworks on mobile devices: https://joreteg.com/blog/viability-of-js-frameworks-on-mobile (I don’t hide the fact I’m unconvinced by the current obsession with frameworks)

Content aware image cropping: https://github.com/jwagner/smartcrop.js

The definitive source of the best JavaScript libraries, frameworks, and plugins.: https://www.javascripting.com/

Copy text to the users clipboard: http://zenorocha.github.io/clipboard.js/

12 rules for professional JavaScript: https://medium.com/@housecor/12-rules-for-professional-javascript-in-2015-f158e7d3f0fc

The looping evolution: http://developer.telerik.com/featured/the-javascript-looping-evolution/

Write a flowchart in text, see it instantly updated: http://adrai.github.io/flowchart.js/

And finally…

Convert images to LEGO: https://github.com/Wildhoney/Legofy

The wah wah machine. If this doesn’t make you smile you have no soul: http://www.wahwahmachine.com/

Like maps? Go down a mappy rabbit hole: https://mapzen.com/blog/escape-from-mercator

Magic playlist – song suggestions based on what you like: http://magicplaylist.co/

Visualise events in history (powered by Wikipedia): http://histography.io/

A new way to choose what to read next: http://www.openingthebook.com/whichbook/