Faster load times for free

What if I told you there exists a simple method to start saving money on servers today and that takes only one line of code to implement would you believe me?

Well welcome to the world of headers, for followers of my blog this is more like an expansion of what we had talked about a few months ago Using status codes and headers

In this entry we are going to talk about the headers that we can start using to reduce server-client communication immediately which has the double benefit of

  • Saving your customers especially those on mobile data charges
  • Reducing the work your server needs to do


The Etag provides a unique representation of the response issued by the server. It is usually a short string that is of meaning to the server. You probably already have unique ids for data entries in your application, this would act as good targets for an etag if however entries are editable you may choose to use a hash of the content.

\\Code example in Laravel PHP


return response($content)
            ->header('Etag', $etag);


An Etag is not of much use if the client doesn’t make use of it. The If-None-Match header allows the server to return appropriate responses for the data if content still there.

use GuzzleHttp\Psr7\Request;

// Create a PSR-7 request object to send
$headers = ['If-None-Match' => '897696a7c876b7e'];
$request = new Request('GET', 'http://yourservice/blogs/57', $headers, $body);


This instructs the client and all other downstream services if the content can be cached.

The main settings for it include:

  • private Instructs cache is specific to a user
  • public Can be cached for use by all clients
  • no-cache Client must re validate all requests
  • no-store Client should not cache anything at all

There are more settings and you should check them out

return response($content)
            ->header('cache-control', 'private, no-cache');


Nothing lasts forever, even data. As such makes sense to inform clients of best by date for the data they have cached. In modern browsers you could use max-age control in the cache-control header.

#Example for django

response = HttpResponse()
response['Expires'] = "Thu, 24 Sep 2015  12:00:00 GMT"


As you get more sophisticated in your caching techniques it may now be time to start using the Vary header. The header allows clients to know if they have valid content based on some condition.

The most obvious example would be if you serve different content for mobile and notebooks then the browser should first check if the cached content is of the same user agent

#Example for ROR

response.headers["Vary"] = "User-Agent"


It is important to note that not all clients respect headers but for those who do, you would be doing yourself and them a world of favor by providing them with appropriate headers

Will you be implementing the headers we have talked about? Talk to us on the comment section below.


Metrics on quality of software

Quality is a term loosely used in the world of software development. I would be hard pressed to mention a project in which quality of the product we we’re building was not mentioned many times over. And while clearly I work with a super team we would be hard pressed to define what quality software actually is having long settled on the I will know it when I see it camp.

Still it does make some sense to at least see what informs our decision making. So lets start

Who is responsible?

The phrase the buck stops here has as much weight in technology as anywhere else. The management believes that quality should come from the developers and the developers believe it should come from management. The truth is, both parties play a critical role in the delivery of a quality product.

    Developers: Software is highly technical, the burden of ensuring its quality rests squarely on your head, this is why you are paid.

    Managers: We developers are not good neither do we care to be good in corporate politics, your job is to enable us do our job by paving the way and then getting out of the way.

Metrics of quality

Despite the amorphous nature of quality, there are still some measures which we can use to get a rough outlook on the product you are building

  1. Reliability

Your product should do what it was built to do dependably. I have put this particular metric as first on the list because if you do not achieve this then nothing else is worth measuring.

Think about this the next time you have a two hour meeting to discuss if the logo should be placed on top of the page or at the bottom.

  1. User Experience

The end goal of all software is to serve humans. I know humans are not nearly as cool as the tech your working on, but every once in a while make sure you have some of them actually using what you are building. You may be surprised at the insights you gain.

  1. Maintainability

Most of the time we spend on software development is on the task of maintaining it. In fact almost all design principles are written with the explicit goal of making it easier to make changes to existing code base or adding new features.

  1. Efficiency

I am saddened by the number of engineers who seem to believe that optimization is yesterdays problem. To this engineers a rude shock awaits them if ever their product is mentioned in a popular outlet such as hacker news.

And even if you have the money to quickly scale up your services perhaps that money would have been better spent elsewhere/

What are some of the measure you use in your own shop? Talk to us on the comment section below


Five reasons to build a CLI for your web app

As web developers, we tend to focus mostly on the web side of the application, and for good reasons too, good UX should be on top of your priority list.

However, it’s important to remember that the developers and maintainers in your application are also users and you need to take care of their experience. And how do you get to please developers? You come as close as possible to their environment, i.e add a command line interface to your application!

Adding a command line interface to your web application has several great advantages as listed below.


The most obvious interpretation of this arises from the fact that you can use your application in multiple environments. However most importantly your application can now be used as part of a bigger application without any need to modify it! Read this to understand why this is important


Application maintenance tasks tend to be rote, unless your audience are brain dead, please spare them the agony of this tasks by providing easy automation switches. This can be as easy as adding tail to all requests or as complex as a command to run a self healing module in your application.


As a dev shop you can not possibly anticipate all the uses your application can have to your users, developers or even future self. Adding a TUI enables a user to script a sequence of commands in your application to cover use cases that you did not think possible.


Lets face it, your web application will likely go down at one point in its lifetime. In this critical time, you really want to still be able to access it and even better run admin tasks.


It is infinitely quicker to carry out tasks on the command line than equivalent tasks on the web interface. For end users the pain of learning to use a TUI far outweighs this benefit, however most developers are quite at home in this environment, spare them carpal syndrome.

Good news

The good news is that all major frameworks provide an easy way to build out your CLI.

  • Laravel Artisan
  • Django Admin
  • Rails runner

Will you be implementing a cli in your next application? Tell us in the comment section below.