Archive for the ‘Limited’ Category

If you’re using version control (you are using version control, right?), the question sometimes comes up as to how often you should commit.

I’m a commit fanatic, I like to commit as soon as soon as I can, no matter how small the change. Other people prefer to wait a little and make large commits all at once. However often you choose to commit, you should make sure it falls within the constraint of being atomic.

This means that each commit is one single, complete change. That is to say that you shouldn’t commit multiple changes at once, nor should you commit a change that is only half done. This is scope in this for different approaches of course “one single, complete change” could be part of a several step refactor as long as the changes stand on their own, so could committing the refactor at once if it is all part of the same unit of work. But the important thing either way is to try and stick to atomic commits.

Think of it like an ACID transaction. Presumably you’re system works before you make the commit and it should work after too. It should contain just one feature so that if you want to roll that specific feature back, you can roll back that one commit without rolling anything else back.

With Git, where people may want to take out of sequence commits, this becomes especially important. People may want to take one of your changes, but not the other, so making sure two changes are in two separate commits is very important. Generally, if your descriptive commit comment (you are writing descriptive comments, right?) contains the word and, you probably need to re-think your commit.

Recently, I was thinking that it must be coming up to ten years since I registered my first domain name, in the next couple of years. When I actually checked, it was two months ago.

In May 2002, I first registered Worfolk.co.uk, now the home of my consultancy company. This was by no means my first venture into the world of web development, I had been developing websites for years before, and programming for years before that. But it’s difficult to put a precise date on any such projects, unlike 7 May, 2002.

Between then and now things have changed a lot – a one point, the Worfolk Online network contained hundreds of websites. It now contains only a few dozen, that are far more focused on quality. While I don’t have screenshots of all of them, the image above shows the evolution of some of the network’s homepages.

Anyway, cheers, here is to a wonderful decade and hopefully, an even better one to come.

Still writing regular CSS? Pfft, you’re living in the dark ages! These days it’s all about two new technologies that are almost identical, so I’m going to discuss them in the same post.

The idea is dynamic stylesheets – bringing concepts we use every day in regular programming and implementing them in stylesheets to avoid duplication and make everything cleaner, nicer and more up to update with current paradigms.

So what can you do with these tools? Here is a quick overview…

Variables

Using a colour everywhere that you might want to change later? No worries, just save it as a variable and if you do need to change it at a later date, you just update the variable and it will be changed everywhere.

@myColour: #FFCC00;

.header { background: @myColour; }
.footer { background: @myColour; }

Mixins

Inheritance! What a sexy thing to have in CSS. No longer do you have to place loads of DOM references in lots of different places. Now you can just write it once and included it wherever else you need it.

.bigBorder { border: #FF99CC 10px solid; padding: 5px; }
.header { .bigBorder; background: @myColour; }
.footer { .bigBorder; background: @myColour; }

Nested rules

This one is a huge time saver! How many times have you had to reference half a dozen elements in one DOM reference? Probably very rarely, but certainly two or three tags is the every day reality. No longer though, because you can now nest your rules.

.header {
	.bigBorder
	
	a {
		font-size: 200%;
	}

In this example, the 200% font size will only apply to a tags inside .header, just as if you had done .header a in your DOM reference.

Operations

Want to make a header colour slightly darker? No worries, just add two colours together.

@mainColour: #FFCC00;

.header { background: @mainColour + #333333; }

But these are just a few of the features of these languages. They allow you to do a lot more – including things like full blown functions that you can pass parameters into, guards and much more.

The main difference between LESS and SASS is that LESS is a client-side JavaScript library (although has now been ported to Node) – you send the browser your .less file and include a JavaScript library that converts it. Meanwhile, SASS is a Ruby Gem that compiles a stylesheet to send to the client each time you edit your .sass file.

To find out more, visit the LESS and SASS websites.

I’m pleased to announce the relaunch of Authority Forums.

Founded in 2005, AF tracks the biggest message boards and forums on a particular topic. So, for example, if you wanted to find out what the biggest Futurama fan forum on the internet was, you would browse to Futurama where you can see each forum ranked according to size, with graphs and historical stats available too.

Over the past month the site has been re-built from the ground up to be faster and easier to use, the design has been overhauled so that it looks much pretty and all the content has been updated too – as you can imagine, over seven years a lot of forums close down and new ones open, so we’ve taken care of all of that.

Following the recent launch of our first Swedish language site, Worfolk 18 is pleased to announce the launch of its first Finnish language site too – Alastomat Kotirouvat.

Worfolk 18 is proud to announce the launch of our first Swedish language site, Nakna Hemmafruar. The content is not unsuitable for anyone under the age of 18.

I’m a big fan of the Flight PHP micro framework, and it’s built-in views component is quite nice when you want to do stuff in a rush.

But recently I have started to use Slim more often as it has almost out of the box support for Mustache templates, whereas Flight does not.

Until now, that is. I wanted to use Mustache with an existing project I had already coded up in Flight, so I’ve now written a wrapper for it and released it on Github. It’s nothing fancy – probably less than 100 lines of code in total. But it seems to get the job done.

So if you’re looking to use Mustache templates in your Flight application, why not give it a go? If you have any improvements, you can always fork it too!

Inspired by Kieran’s recent registration of kjo.sh to use as his own short URL code, I decided to go on a bit of a search for any names which could be similarly useful.

Wouldn’t you know it, Sri Lanka happens to have a top level domain made up of the last two letters of my name – .lk. Seeing that the domain worfo was available, I’ve now snapped it up to form worfo.lk. Boasting an extra three letters on top of the minimum length of domain names, it isn’t the shortest short URLs in the world, but I’m more than happy to make the trade off.

Of course, please remember that clicking a worfo.lk link doesn’t guarantee you won’t end up on a web page containing hardcore pornography.

The first thing you probably think about when I mention Mustache is, “you’ve spelt moustache wrong.”

You would be right. But although the creators of such a project clearly do struggle with proper spelling even more than I do, they have never the less created something really interesting – logic-less templates.

Mustache is a templating system, similar to Smarty or Twig, that was originally written for Ruby and has since been ported to almost every other popular language under the sun (it has not been ported to any languages that exist outside our solar system, to my best knowledge).

The idea is that you separate out your logic from your template. So you would have a view class which handles the logic, and then the actual template file which has your presentation in. Why this extra layer of complexity though?

Well the problem with templating systems such as Twig is that they actually aren’t as separate as we like to think they are. You have control statements like looks and if statements, and then people started adding helpers to templating systems where you could call functions and even pass parameters! This made it a lot easier for us to write the view, but by the time you’ve added all that in, why not just place the PHP directly inside the template – it would be just as simple.

Mustache does a way with all that. In Mustache there are two main types of tags you can have – variables and sections. A variable is a straight replacement in double brackets {{like this}}. Sections contain one extra character so you might have a {{#section}} that wraps this text{{/section}}. A section can then be repeated zero or more times depending on whether you pass it a false value, a true value or an array.

There are a few other tags but this for the most part is everything! You don’t have the complicated control statements, the helper functions or other such syntax to deal with – inside a section which repeats from an array for example, you just call the key name, without having to specify the array variable every time. See the example below.

In Twig, you would do this...

{% for item in list %}
{{item.name}}
{% endfor %}

In Mustache, you just do this...

{{#list}}
{{name}}
{{/list}}

You can argue that there is added complexity in having to create an accompanying view class – and you would be right. But this is optional, and only required if you need to do view-time processing – passing an associative array, just like you would with Twig, works fine too!

I highly recommend giving Mustache a go, I was skeptical at first but once you dive in it really produces some beautifully clean code.

Slim is a PHP micro framework, similar to Flight, Silex and Limonade, not to be confused by the Ruby templating system of the same name. It claims to contain “everything you need and nothing you don’t.”

If functions like you would expect a micro framework to work. Here is the standard example.

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

My favourite part of Slim, however, is actually the Slim Extras bundle which doesn’t ship with it, but can easily be downloaded and dropped in. This adds easy integration for lots of different templating languages – notably Smarty, Twig and Mustache.

So, for example, if you wanted to integrate Twig, just grab the Extras bundle, the Twig bundle, include the relevant file and change your initialisation statement to the following.

$app = new Slim(array("view" => "TwigView"));

That’s all – now you’re away and can call the render method with a filename and data array to render a template using Twig.