Speedy Mondays (Super Mondays July 2013)

To be honest, the mood at the Beehive at Newcastle University was anything but speedy, as the region basked in the ongoing heatwave. Regardless, the July Supermondays had a need for speed, from optimisation to psychology. There was also mention of a new usergroup (JSNortheast, meeting the first Monday of every month).

Richard Powell: Speed and Front End Development

Richard Powell gave a three-prong attack for considering speed in development: load time, perception of speed, and back end development. Of these, load time is the most important: apparently 80-90% of website load time is on the front end. (Even tumblr doesn’t get this right).

Much like Stephen Jones at a recent WP meetup, he recommended optimising and minifying files (for CSS using sprites/icon fonts/base 64 encoding, and concatenating JS and CSS files), obfuscating (JS variables), gzip txt files (70% file reduction). He also discussed being defensive about plugins (e.g. rather than using a tap navigation plugin, it could be done in 3-4 lines of code) loading JS last (even with Async, it doesn’t always work), and using lazy loading. And think about coding efficiently!

In regards to runtime, his analogy for DOM Interaction was memorable: “think of it like taking the dog for a walk and it making a mess: you have to touch it, but you don’t really want to.”

He pointed out that CSS positioning can be expensive: opacity, transforms, and surprisingly static positioning (browser has to recalculate on each load). One nice way to stop something being slow is to give it a rotate position of 0 (it gives it its own engine).

He gave a plea for API devs to think about how they serve up the content, and also not send people off on a wild goose chase to other files for more info.

He made notes in relation to perception (a theme carried on in the following talk): a site with progressive loading feels faster than one without, and to not block the API.

Out of the three, he emphasised the need for load time most (which requires collaboration).

Not sure if loading or…

Slide of the night.

Finally, he points out that it’s worth thinking about the tools we can use for testing: Chrome Dev Tools are good, and sites such as JSLint that let you compare code.

Graham Morely: the Psychology of Speed

Being in a car can be fast, but nothing feels quite so fast as being in a go-kart careening down a hill. Morely focused on how web designers and developers can make a site feel faster.

As it turns out, the speed of a site can have serious business impact. Examples Morely cited included Amazon tests that 100ms of extra load time=1% drop of sales, a page on Yahoo being 400ms slower causing 3-9% increase ‘black clicks’, and Mozilla getting 60m more downloads by increasing speed of download on their page for IE (and conversely the cost of 1s delay: 7% conversions, 11% page views , 16% decrease satisfaction).

Interestingly, speed isn’t always important: ATMs that dispensed money too quickly weren’t trusted.

He quoted Souders’ rule that  satisfaction = perception – expectations and used it as a guideline for work: people are happier with a site that feels faster than they’d expect it to. That said this can be done with information tricks e.g. if you’re in a search sites: going beyond “search hotels” to “search 52,420 hotels” with a loader looks faster.

He cited Neilsen’s studies on page times (though noting they’re perhaps 10 years old):

  • 0.1-0.2s =  instantaneous
  • 0.5-1s = immediate
  • 2-5s = flow, as it takes about 2s for a person to turn a page and find their position.
  • 7-10s (has to be) captivating

You should only spend 10s or more if it’s a natural break in user flow (you may wish to have alternate solutions such as let the user leave the page and email them when the task is done).

He helpfully gave a number of resources to investigate:

Mobile design guru Luke Wobrewski has also just written about perception of speed on mobile.

Oli Wood: Optimising Canddi

Oli Wood spoke from a recent project (Canddi) and his trials and tribulations attempting to optimise it. Above all, his key messages were to measure for what’s important (for them is how many inbound customer requests can be processed) and to just attach it (“Back of a fag packet calculations can be good enough”).

There are no silver bullets (they got expensive machines, hosting, PHP-FDM, all sorts of things, none really worked)

… aim for a silver shotgun cartridge (lots of little small things that can be nailed).

There are no silver bullets… aim for a silver shotgun cartridge.

More practically, he pointed out the importance of testing somewhere not live (as the team use AWS, they can clone and get a ‘good enough’ results) and to use realistic data (get enough on the test site to be good enough, no more) with defined test scenarios.

Build a pipeline view (find where the bottlenecks are).

Identify symptoms (what you can see) but solve problems (your 100% CPU usage could be that you need more machines, or just that you write crappy code).

Do less big things less often (doing big commands only when you have to).

Do frequent things much faster, avoid waiting, pull less data (“who writes MySQL? Who writes SELECT *?”). Hunt for collisions

Cache the painful thing: in memory (can be very effective, even in PHP), with tools such as redis (“almost one-click install, insanely quick”)/memcache (may be slightly better as it spreads across machine), url/browser cache

Use the tools:

  • Ab (“install with one command on Apache, and does a quick and dirty hit”. It’s useful for testing in background) +  Seige (far more detailed in regards to flags which can help to pinpoint where breakpoints are) and EC2 instances. “Install 2 or 3 ubuntu boxes, add EC2 on them and then test”
  • Use iostat (will tell you pretty much everything) or sar (-p is also very useful as it can tell you how busy multiple machines are), strace (“terrifies the life out of me” as it tells you what happens inside the processor “run it, get the text file, google the crap out of it”), iftop (for networks), xdebug + webgrind (don’t run on a live server!) as well as mongo tools such as mongosniff (‘terrifying, powerful, but go to google groups for it’. nginx is faster than apache (sadly)
  • They were on PHP, then moved to nodejs and with regis (if you can get it)

Your aim is to create a loosely coupled components which are horizontally scalable to make the business work (much like the 80/20 rule, beyond a certain point, “it just turns into geekery”). They managed to get the site 10x faster.

Elixr: Paul Callaghan

Paul Callaghan discussed Elixr, a new programming language that runs off Erlang. It’s still in its early stages but has been adopted by Soundcloud amongst other companies, and looks to be to ruby programmers what Coffeescript is for python devs. He pointed out a few useful concepts from the language such as creating a pipeline (a series of actions that can then be tracked in various places).

 Stefan Dantchev: Birthday Attack when randomisation probably helps

The night finished with high stakes of cryptography breaking. Well not quite. Dantchev’s examples were more theory than practical, but an interesting exploration of what we need to be aware of when it comes to code breaking and hashes. He used The Birthday Attack scenario—given a room of people, who many need to be there before it’s likely two share a birthday?—as a means of showing how this works, namely that you use a recursive (factorial) function of the likelihood of it not happening to figure it out. (For birthdays, that number therefore comes up as 23 people, at which point it’s just under 50%).

 

iOS Newcastle: Optimising Objective-C and North East App Showcase

The rare UK heatwave meant that most people were outside enjoying the sun. However, a dedicated few chose air-conditioned entertainment at Clavering House for iOS Newcastle for talks about Objective C and a showcase of locally-made apps.

Objective-C Best Practices

Alan Morris

With a long background in programming (he started at age 7!), Morris worked for Orange and Accenture (he admits he stayed at both “far too long”) before co-founding(?) Little Red Door. While over the years he’s learnt a number of languages, he admits that Objective-C “is the first I’ve learnt in depth”. He gave the following tips:

  • Know how to use #include, #import (stops recursion), and @class (e.g. don’t use #include in headers, instead use it to look for functions rather than constantly calling header files at compile time)
  • Beware premature optimisation. The developments in Objective-C mean that there are various ways to optimise your code (e.g. a numerical iterator loop is slow, a for in object loop is faster but doesn’t give an index, the scary looking but fastest and index giving enumerateobjectsinblock function). However, he used the great phrase “premature optimisation” for the scenario where you believe that one function will be faster whereas in real life the difference is minimal. He advises just to write how you know, test, and check if there are bottlenecks.
  • Coding standards: while these are needed for big teams, they’re just as useful for smaller or even single person teams. Set up practices so you know whether you use YES or TRUE for booleans.
  • Style guides: Little Red Door are now pretty strict on getting well structured style guide PSDs from their designers right down to properly named layers. While it does have an initial time outlay, Moore believes that it pays off in terms of less back-and-forth for missing or ambiguous elements when it comes to implementation (There’s actually been a big push for good style guides recently, such as the Style Guide Boilerplate).
  • Code comments: think about time spent vs time saved, and add comments as per why the code is doing something rather than what to do. (A recent article on comments for commits emphasises the same thing.
  • Reduce asset sizes with 9 slice images and related techniques. In a recent project, his team managed to reduce UI assets from 40Mb to 10 using this technique (which is akin to the akin to the sliding doors/CSS clips methods in HTML), and then to 6 with ImageOptim (though a tip from Morris: turn off the XCode caching!) .

For me as a PHP (and occasional Python) developer, Objective C has always been a bit of a mystery to me. However, the new number and array literals as of XCode 4.4 means that it’s a lot closer to other languages (no need to end arrays with ‘nil’ anymore). Similarly, Dict now has a key:value format far more similar to python.

His tips on carious shortcuts reminded me of David Pogue’s suggestion that everyone knows 80% of various computer actions, but a different 80%.

Local App Showcase

There was also a showcase of local apps:

  • Balance Guide (£0.69) is a guide for personal money management by Mindwarp Consultancies (represented by Julian Moorehouse).
  • Scouting for Boys (free) is a repository for UK Boy Scout archives (in soft launch) by Matt Glover. Matt used UIPageView Controller, CocoaPods (a technlogy that created strong debate!), iCarousel, and LBYouView (a scraper for Youtube) for it.
  • Slumber (normally £1.29, £0.69 for this week) an app by Little Red Door that plays white noise, maternal and fetal heartbeats etc). It was based on a toy sheep that did a similar thing. (It also uses iCarousel). Bizarrely, it has a good following in Tel Aviv and Iran!
  • Booths (free) is a shopping/groceries network by Hedgehog Lab that allows for shopping lists etc. It’s based on standard core data (though he admits the dev admits now use magical ones),  Mapping stack, and Pixate (a stylesheet for apps using CSS, thus getting around having to roll out iOS updates for style changes). He also mentioned the data is piped from WordPress, which wasn’t their choice (normally they’d use Python and Django).
  • The Tyneside Speakers Club app (free) represents a group that has been meeting twice a week in Whitley Bay for 42 years. The app is a way to get younger people interested in the meetup through videos. “There have been loads of downloads, but unfortunately the people in Turkmenistan haven’t shown up.”

There are a number of apps in review stage as well, such as one on the art of the Metro.

In terms of older but still interesting apps, one attendee released an app that shows you how sudoku can be solved as well as an acclaimed version of The Game of Life!

On the non-iOS front, some devs are expimenting with Launchpad and internet of things.

Other things

  • Organiser Matt Glover took part in the Middlesbrough Hack Day and came second, using the FB SDK and cameras. The winning app used twitter search terms and libraries to measure whether the tweets were positive or negative, for reputation management.
  • There are speaker calls for iOS Dev UK.
  • Finally, if you’re interested in a Macbook Air, there’s one for sale. (Who needs Craiglist when you have meetups?)

WordPress North East

As a queue of people waited with umbrellas outside the nearby City Hall to watch young Gosforth performers, a small band of people made their way through the maze of Northumbria University’s Sutherland Building for the inaugural WordPress North East.

Building a Better WordPress Application

Regular NE developer event speaker Phil Brown extended his speaker repertoire to WordPress. He pointed out a lot of bad practice in WordPress such as content logic in the theme, repeated (i.e. sloppy code), and difficulty in portability.

His rules:

1. Do not write your application in functions.php

Do it in a custom plugin instead, and keep your theme for presentation! Otherwise, any custom post types etc will disappear should you change your theme. It could be that Themeforest practices are to blame for this being so widespread. For an example of how to do this well, see Woocommerce.

2. Every action should be hooked

function my_plugin_start(){
//fire up app
} 
//wrong 
my_plugin_start(); 
//Right add_action('plugins_loaded', 'my_plugin_start'

3. Use WordPress

Look at options API and posts for not only storing content but as a generic data store for anything that has multiple items, as it’s a powerful API.
Other ones of interest are

  • Custom post types and post meta
  • roles/capabilities, user meta
  • Options and transients
  • Scheduler
  • Remote HTTP

4. Use plugin dependencies

Unlike a lot of plugins (e.g .Drupal), WordPress unfortunately doesn’t allow for plugin dependencies out of a box.

However, there are ways around it, check out Scribu e.g .

if ( !class_exists ('plugin_x') )){
wp_die ('Plugin Y requires plugin x');
}

5. Standardise code

While this isn’t a given, it helps with building on the site (and more employable!)
Check out the WordPress Coding Standards (and it doesn’t hurt to peruse the PHPDoc either!)

6. Choose your PHP version

Decide this early, as it can be a pain to change, particularly if you want to sell a theme or plugin. The standard right now is 5.1.1 but most people are now on more recent versions of PHP. Phil uses 5.3 as most have it (and allows for namespacing etc), though 5.3 also looks interesting with an inherit-like ‘trait’ class.

7. Avoid global scoping

A bad habit of WP coding is that a lot of code has global scope, which can lead to conflicts.
One way to get around it if you have PHP 5.3 is closures (as per jQuery)

add_action('init', function() {
 // do something
});

or with older versions, namespacing.

8. Activation hooks

Activation hooks are useful for once-only (and be able to be ported)

9. define( ‘WP_DEBUG’, true)

This will show you issues that wouldn’t come up usually.
Other good debuggers are DebugBot(?).

10. Release your code

It gives you an oppportunity to show your stuff, and even get feedback. Good plugins to look at include WordPress SEO by Yoast, and Advanced Custom Fields.

Optimising WordPress Images

WordPress Northeast event organiser Stephen Jones spoke of many of the issues for image uploads. They are:

  • File sizes: restrict image size (WP Image Size Limit), reduce baseline (Imsanity), or optimise (WP Smush.it). For theme images: use the right image types (easier for devs than users!) and optimise them e.g. with Codekit “the best $25 I ever spent”
  • Getting images at the right size for slideshows etc: can be done with commands (add_image_size—though needs the Regenerate Thumbnails plugin for any changes!) or a plugin (WPThumb which unlike the beleaguered TimThumb, should be secure!)
  • Per device: can be done with media-queries, or the Hammy plugin. Zurb Foundation is also playing in the space for solutions.
  • Delivery method: get it faster with a CDN e.g. CloudFront, MaxCDN; use sprites e.g. SpriteCow (but don’t go overboard on them!). Also think about using Lazyload, icon fonts.

There was an interesting discussion about the WordPress CDN that is available via Jetpack’s Photon: while it has some advantages (particularly if you’re on shared hosting), it is quite slow.

The next event is TBC but will feature Richard Carter talking about responsive theming (and other talks are welcome). In the interim, over at Lancaster they’re holding a WordCamp on July 13-14 2013.