Archive for the ‘Limited’ Category

Worfolk Limited has been producing awesome software for many years. Whether we are building web applications and mobile apps for customers or launching them ourselves, I take a lot of pride in making them the best apps they can be, both from a user’s perspective and by leaving the client in the best position going forward.

That quality and attention to detail is now expanding to wearable devices, too.

This starts with Garmin devices, and I’m pleased to announce we’ve launched our first app, Mindful Moments. It gives you timely reminders to live in the present. If you have any of the Garmin watches that can download apps from the Garmin IQ Store (Forerunner 230+, Fenix, Vivo), you can try it for yourself.

It’s written in Monkey C, the version of Java that Garmin devices run on. Going forward, we’ll be developing more apps and making these services available to clients, too.

Leeds Restaurant Guide is incredibly detailed covering so many restaurants with high quality content and imagery. So it seemed only fitting that I should pay as much attention to the presentation as I do the content.

I’ve been using Google’s PageSpeed Insights tool to debug it. Ironically, PageSpeed Insights spends a lot of time complaining about the Google AdSense code that they provide to me. It does however provide some useful tips too.

Compression

Gzip compression costs almost nothing and can drastically reduce the file size you are sending to the client. The server compresses it and the client uncompresses it all of which is done transparently to the user.

It is pretty easy to configure using Apache’s mod_deflate module, and I’ve blogged about how to get it working on cPanel on Hardware Tutorials.

Expiry headers

If you have Apache’s mod_expires, and you almost certainly do, you can set default expiry headers for content using your .htaccess file.

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType text/css "access plus 60 minutes"
    ExpiresByType image/jpeg "access plus 1 day"
    ExpiresByType image/jpg "access plus 1 month"
    ExpiresByType image/png "access plus 3 months"
</IfModule>

This will tell the client it can safely cache the content for a while. Put whatever values in that you think are sensible.

Minify your CSS

Recently I wrote about how to use Gulp to set up a task to compile your SASS/LESS stylesheets. This included instructions on how to minify your CSS. Even if you are just using plain old CSS, you could still create a task to create a minified version.

Minification takes out all the spaces, comments and other unrequired characters so that you have less data that needs to be transferred to the client.

If you’re doing a lot of CSS in your web development, you may have taken to using SASS or LESS to allow you to better organise, code and maintain your stylesheets. These are both great tools. However, the one thing that annoys me is having to remember the command to compile them, given it is often different for each project.

Luckily Gulp, a Node-based task runner, can come to the rescue.

This has the added advantage that you can also pipe it through other tools, allowing you to create maps and minify the CSS all in one command that makes it super easy.

Firstly, you need to add the dependencies so that NPM knows what to install.

{
    "devDependencies" : {
        "gulp" : "*",
        "gulp-sass" : "*",
        "gulp-minify-css" : "*",
        "gulp-sourcemaps" : "*"
    }
}

You can then run NPM install to get all the modules you need. If these are the only modules you are using you will probably need to modify your .gitignore file to ignore the node modules directory.

node_modules/

Now we can create a gulpfile.js in the root of our project directory that will define the tasks we want to run.

'use strict';
 
var gulp       = require('gulp');
var sass       = require('gulp-sass');
var minifyCss  = require('gulp-minify-css');
var sourcemaps = require('gulp-sourcemaps');
 
gulp.task('sass', function () {
    gulp.src('./sass-files/*.scss')
        .pipe(sourcemaps.init())
        .pipe(sass().on('error', sass.logError))
        .pipe(minifyCss({compatibility: 'ie8'}))
        .pipe(sourcemaps.write('./sass-maps'))
        .pipe(gulp.dest('./stylesheets'));
});
 
gulp.task('sass:watch', function () {
    gulp.watch('./style/*.scss', ['sass']);
});

The first task creates a “gulp sass” command that takes the SASS file, converts it to CSS, minifies it, builds the source map and then writes it out. I’ve set the compatibility to ie8, though it could also be ie7, and defaults to ie9.

The second task creates a “gulp sass:watch” which watches the files for changes and then calls the first task whenever it detects a change.

If you are using LESS you will need a slightly different set of dependencies.

{
    "devDependencies" : {
        "gulp" : "*",
        "gulp-less" : "*"
    }
}

The tasks are slightly different too, but basically do the same thing.

'use strict';
 
var gulp = require('gulp');
var less = require('gulp-less');

gulp.task('less', function () {
  return gulp.src('./app/resources/less/*.less')
    .pipe(less())
    .pipe(gulp.dest('./app/webroot/css'));
});

gulp.task('less:watch', function () {
    gulp.watch('./app/resources/less/*.less', ['less']);
});

The end result of this is that rather than remembering what the specific paths for any project I want to work on, I can create a Gulp task and simply run “gulp sass” or “gulp less”. I could even just rename them to “gulp css” to use the same name on every project I work on.

Having worked on a lot of different projects at a lot of different companies over the years, there are some issues that recur time after time. These are problems that maybe we just don’t have satisfactory patterns for, or developers have a blind spot for. But whatever the reason, they certainly merit more attention in order to reduce how frequently they arise.

Below, I’ve listed three with some suggestions as to how to help mitigate them.

Caching

Caching is essential to good performance in most applications. Remember your ABC – Always Be Caching. Indeed, if you ever want to sound clever in a discussion about system architecture, say “have you thought about caching that?”. Caching is the solution to almost everything. But causes some problems too.

For the non-technical, caching is storing information in short term memory so it can be delivered faster. It’s like remembering things. You probably have a big pile of books at home, and you can’t remember most of them, so for most facts you have to look them up in a book. But you can remember a few things, so for the questions you get asked most, you memorise the facts so you can say them quicker. That’s basically what caching is.

The problem is that when you update something, the cache can end up serving the old content, rather than the new. This results in data being out of date and often results in web applications not appearing correctly because the HTML has updated, but the CSS and JavaScript happens.

Here are a few tips to help mitigate such problems:

• Have scripts to clear out your various caches. Make sure you know what/where the cache layers are.
• Understand what cache headers you are serving via you sending via your web server.
• Have a mechanism for changing files such as stylesheets and JavaScript when you release a new version.
• Turning caching off on dev environments is fine, but make sure you have it turned on on your staging/pre-production environment so you can spot potential problems.

Timezones

While Britain insisted that time starts and stops in Greenwich, we did allow the rest of the world to make adjustments at hourly (or even half-hourly) intervals based on where they are in the world. This has caused no end of headaches for software developers. Even within one country, one problem that comes up time after time is that systems go wrong when the clocks are changed for daylight savings.

Every six months it all goes wrong every six months and we promise to fix it by the next time the clocks change, but usually never do. Even Apple got it wrong on their iPhone alarm – twice!

Here are a few tips to help mitigate such problems:

• Set your servers to GMT/UTC and leave them there, regardless of where you are in the world and where DST is in effect or not.
• Use prper DateTime objects, and specify the timezone.
• When sending a DateTime string, use an ISO standard and be explicit as to what TimeZone it is in.
• Unit test DST changes, using a mock system time if required.
• Perform manual testing on the DST switch.

Load balancing

As systems scale, they inevitably need to spread across multiple processes, applications and bits of hardware. This brings a whole new layer of complexity, though, having to keep everything in sync. It’s very easy to lose consistency and that almost always ends in one thing – say it with me everyone, “race conditions”!

There are two common problems we find in this situation. The first is that one node stops working but the other one is working fine, or maybe something as simple as one node having old code on it. You get intermittent problems but when you try it it works fine or at least works fine 50% of the time. It could be that it is hitting the working node but at other times is hitting the other.

Here are a few tips to help mitigate such problems:

• Ensure you can (and ideally do automatically) test individual nodes.
• Use a tool like Chef or Puppet to make sure all your nodes are consistent.
• Have the ability to easily take out nodes that are not working.
• Aggregate your logging where possible so you don’t have to tail them on each individual node.

The second is race conditions. This is particularly prevalent when using a master and slave database setup. You will write the update to the master than query for it the results – but because your second query is a read, it will be passed to the slave, which may nor may not have updated yet with the new information.

Here are a few tips to help mitigate such problems:

• Have the ability to manually specify master or slave so time critical reads can be pointed at the master.
• Ensuring your staging/pre-production environment load balances everywhere your production environment does so you can spot potential issues.
• Where possible, rely on one server for the time as different machines can become slightly out of sync.

A lot has changed since I wrote my first line of CSS – which is probably going on a decade ago now. Other things have been there all along, but have sometimes been overlooked or neglected. Below is a collection of CSS that it is easy to forget exists.

Selectors

Obviously you can use . # * etc, but there are actually far more options. As well as chaining them (p, div) and specifying them being inside each other (p div) you can also specify they must be the parent (p > div) or immediately after one another (p+div).

As well as checking attributes (input[type=text]) you can also do contains (input[title~=something]) and starting with (input[type|=something]).

We’re probably all familiar with :visited and :hover states, but there are actually dozens you can use – :focus, :first-letter, :first-line, :first-of-type, :last-of-type, :only-child, :empty, :enabled and “checked just to name a few.

Sizing in rem

It’s good practice to use em sizing to make everything relative – that way if a user scales up the page then everything stays in proportion (though modern browsers tend to handle this well anyway). But isn’t it annoying that it stacks? A 2em value inside a 2em value will give you a font size of 4.

You can solve this by using rem. Specifying 2rem will make it 2 x the root (html) element of the document – so you can make it all relevant to that and not worry about nesting.

Gradients

You can add gradients as backgrounds and even create complex patterns with multiple colours starting and stopping at different points.

background-image: linear-gradient(bottom, #22E7D2 12%, #3EFFFC 56%, #2FAB24 100%);

Shadows

It’s simple to add a drop shadow to an element.

box-shadow: 10px 10px 5px #888;

You can add it to text as well.

text-shadow: 2px 2px #ff0000;

Box sizing

Tired of having to work out what width you want something to be, then taking off the padding and the border? Sometimes maybe you don’t even have the option to do that because you want it to be 100% wide. Box sizing to the rescue. Set the box sizing to border and it will calculate the width factoring these properties in.

box-sizing: border-box;

Border radius

Want some nice rounded corners? Easy.

border-radius: 5px;
border-top-left-radius: 3px;
border-bottom-right-radius: 10px;

Clipping

You probably shouldn’t clip as it means you’re sending an image to the browser that is too big and then cutting it down. However, the functionality to do it does exist within CSS>

position:absolute;
clip:rect(0px,70px,100px,0px);

There is a background-clip property too.

Columns

Want to present your text in a series of columns? Theres a property for that.

column-count: 3;
column-gap: 5px;

If you’re interested in good user experience design (and who isn’t, right!) then it might be good to get the perspective of someone who actually studies users – someone like a psychologist for example. Luckily, one such psychologist is interested in such matters and has written rather a good article about it.

Over at UX Magazine, Susan Weinschenk has written The Psychologist’s View of UX Design and it provides a very useful breakdown of a lot of UX areas and how she views them. Well worth a read.

These days, we’re all trying to do very clever things in the browser, that take up heaps of system resources. Often, your application will be doing so much that the system can barely cope – and with JavaScript being a single thread language, heavy processing can tie the UI up and make the user think the page has crashed.

Enter web workers – a background process that essentially allows you to do concurrent JavaScript. You can create a background process from a script, and then send messages back and forth between it and the page, ensuring you don’t tie up the UI.

They’re really simple to use too.

var worker = new Worker('worker.js');

worker.addEventListener('message', function(e) {
  console.log('Message from worker: ', e.data);
}, false);

worker.postMessage('Hello, World!');

Then create a simple JavaScript for your worker.

this.addEventListener('message', function(message) {
  this.postMessage(message.data);
}, false);

You can read more about web workers on HTML5 Rocks.

To solve the problem of lots of different scrums wanting to release at the same time, we recently introduced a “release token” – some item that you had to have in your possession to allow you to release – and if you didn’t have it, you couldn’t release anything, thereby preventing conflicts.

Enter Gregory, the Release Bear.

Unfortunately, it was soon felt that tracking down a bear every time you wanted to do a release was too tiresome. So, after only a few days in the job, Gregory was retired in favour of a digital token. Unlucky, Gregory.

Do you need a work queue system but think a message queuing system like Rabbit or Active MQ would simply be too complicated? Probably not, but imagine you did. Enter Beanstalkd. The super simple work queue daemon.

I went down to Leeds PHP for the first time in a while last week, where there was a talk about Beanstalkd. It’s effectively a FIFO queue – you can put a message in the end, and have another process take a message out of the start, the effect being that you can take some of the load off server intensive processes, and do them later when you’re not busy.

I had a play around with it in PHP, using the Pheanstalk and it really is a simple as that to work. You create a connection to your Beanstalkd server, and then just push and pull messages from the various queues, that you can create on the fly, like Mongo.

This is another post about object oriented programming.

Ok, cool, you’re one of the 3% still reading. I just wanted to do a quick post about access modifiers on objects. It applies pretty much regardless of programming language, presuming you’re working with one that supports OO and has the standard public, private and protected for access by sub-classes only.

I think, what we need here is an attitude shift away from using private variables. Often, I see code that uses private variables and I have no idea why.

What I mean by this, is that almost every time I see a private variable, what it actually should be is a protected variable. Indeed, I think the default assumption when creating a variable, should be that you define it as protected.

Lets ignore public variables for the moment. I’ve previously argued you could simply do away with them altogether (that is what getters and setters are for), but in any case, I’m not concerned with them for this post. Lets just focus on private or protected.

The traditional teaching has always been that you should define a variable as private if you don’t want it to be publicly accessible, and giving child classes access to it later on is often an afterthought.

I don’t think this should be the case.

If we’re to adopt a true OO mindset (and it’s been around for sixty years, so given it was invented before most of us were born, you would hope we would have adopted it by now), surely you would work from a perspective that your class will be extended.

Protecting variables from external bodies makes sense, hence not making them public, but to by default place restrictions on what you can do with child classes in an OO world, doesn’t make sense to me. Why have the functionality at all? Why not make everything final if you need such protection?

That isn’t to say there aren’t plenty of instances where there is a reason to do this – but these aren’t the 90% most common use cases, so I think there is a good argument for making protected the default at least.