I walk alongside other INFJ’s such as Martin Luther King, Nelson Mandela, and Mother Teresa.

General overview of an INFJ

As Diplomats, they have an inborn sense of idealism and morality, but what sets them apart is the accompanying Judging trait – INFJs are not idle dreamers, but people capable of taking concrete steps to realize their goals and make a lasting positive impact. Though soft-spoken, they have very strong opinions and will fight tirelessly for an idea they believe in. They are decisive and strong-willed, but will rarely use that energy for personal gain

“If you fail to plan, you are planning to fail”, as Benjamin Franklin once said. I’m a massive planner (seriously, you should see my diary…) and believe that you really do need to plan things out thoroughly to meet your goal. You need to work out where the stumbling blocks might be and plan accordingly – a Web Application isn’t a simple straight line to your endpoint, it’s like a country road: winding and swerving all over the place. Planning projects is hard, but it is doable when broken down into small, manageable, bite-sized pieces.

INFJ as a leader

INFJs are often reluctant in exercising their authority, preferring to see their subordinates as equals, coordinating and supervising people, and working hard to inspire and motivate, not to crack the whip. That’s not to say that people with the INFJ personality type have lax standards – far from it – as INFJs’ sense of equality means that they expect their subordinates to be as competent, motivated and reliable as the INFJs themselves.

This is me in a nutshell. I value colleagues, value their opinions, their work patterns, and the work they do – we’re all humans after all, everyone is created equal. What I want is to encourage others to perform better, giving advice and mentoring where required. Work them too hard, set unrealistic goals, or ill-treating them will only create the opposite of what you are trying to achieve.

Piqued your interest? Go ahead and give it a try now to see which one of the 16 personalities you are.

Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.

Or consider a pavement. Some litter accumulates. Soon, more litter accumulates. Eventually, people even start leaving bags of refuse from take-out restaurants there or even break into cars.
Broken Windows, the police and neighborhood safety

So how does this tie into Web Development? Like the example above, if there are “bad things” in the code then developers will be more likely to further contaminate that file with “bad” things”, because the file already needs a refactor. But that refactor will happen next week/month/year (never, most likely) and everything will be right again in the world. So there’s no sense in doing that now and blowing the deadline for the whole project which needs to be shipped in 2 weeks.

Sound familiar?

This solution doesn’t make sense for most programming languages, but it does for CSS due to its weird specificity and cascading nature. You have a new file for each project named shame.css which contains all of the hacks that you have had to add in order to ship on time. This is great because of several reasons:

1. All of your hacks are self contained within a single file, not contaminating the rest of the sane code.
2. You are admitting there are hacks, but each hack should have its own comment saying why it’s necessary, what it does, and how it can be fixed.
3. Have a spare hour? You can easily dive straight in and fix a hack.
4. You can see who was responsible for the hacks ($ git blame -l shame.css).

The forth point is actually not a blame game, but you can possibly spot trends. If one developer is making a lot of hacks with regards to, say, the grid system then they may need to be given a quick chat on how it works and what they were doing wrong – this will make them more productive in the future.

It’s also a file where someone who isn’t that well versed in CSS can place a snippet, knowing that someone will come along and implement it correctly in the codebase in the future.

It’s a sad fact* that many people see no value in service manuals, because many of them have never been in a development environment. Actually, the outlay in a few days work can result in massive payoffs:

1. More refined code
2. Shared code (markup, behavioural, and styling)
3. Brand consistency
4. Maintainability
5. Happy designers and developers

I really cannot emphasise how important everything on that list is, so let’s take them one-by-one.

More refined code

You have already discussed everything in the service manual with the other developers who, hopefully, largely agree that everything in there is sane, useful, and correct. This leads to a greater proportion of the code already having been code reviewed.

Shared code (markup, behavioural, and styling)

Need to add a button? It’s already there. A table? Already there. A carousel? Despite the numerous experiments proving they do not work aside, already there. Which colour do I use for this thing? Already there. How many pixels should this image be here? Already there.

Not only does this allow the developers to focus on their work, it frees up the designers time allowing them to get on with what they like to do best: design. Interrupting a developer also causes massive time wastage, this article entitled “Programmer Interrupted” gives an excellent overview on why it takes ~15 minutes for a developer to get back “into the flow”.

If you’re an agency then you also have the components that you can reuse project after project, just needing to update the CSS to have a unique brand associated element.

Brand consistency

This one is quite obvious: The service manual will define colours, type faces, visuals, and the padding/margin required, all leading to a consistent feeling across the website and their offline stationary, banners, signage, work clothes, etc. This won’t be used just by internal teams, but external as well – make sure they know how your brand should be portrayed.

Maintainability

Let’s take for example the carousel. Update the Javascript for it and every single item will then be updated. You don’t need to update each one individually. Has one of your brand colours been updated from #FFF to #FFE? No problem, just update the SASS variable and it will flow down to everything using it (you are using SASS, right?)

Also, because everything has been determined before a single line of code has been written it means there is far less spaghetti code. Spaghetti code is hard to maintain, makes the barrier to entry point higher for new developers, and causes bugs.

Happy designers and developers

A crucial point; making your staff happy matters. It will improve the office morale, make them work harder which will pay dividends in the quality of work they ship, and creates a friendly working atmosphere where they enjoy coming to work – don’t make them dread the morning alarm clock. It’s also the right thing to do.

Conclusion

So, a service manual isn’t a waste of time. It isn’t just about what colour something should be. It has far more meaning and importance than one first gives it credit. It will save you time and money. Please, use one and make the world a better place. Some excellent service manuals can be found below for your enjoyment:

• UK Government Service Manual
• UK Government Design Principles
• US Government Playbook
• BBC Global Experience Language
• Mozilla Styleguide

* my own personal experience of ~100 clients and organisations

Finally

You can see that, in the code below, we do not call fclose when we throw an exception because the finally will kick in and do it for us automatically.

function example($url) {
    try {
        $handle   = fopen($url, "rb");
        $contents = '';

        if (false === $handle) {
            throw Exception('Failed to open stream to URL');
        }

        while (! feof($handle)) {
            $contents .= fread($handle, 8192);
        }

        return $contents;
    } finally {
        fclose($handle);
    }
}

Deferred

“finally” is an OK method, but then one ends up having try-catch blocks all over the place. It’s much better to have an interface to do it for us. In the programming language Go there is a feature called defer which prevents things from executing until a function has complete. It would be nice to do this in PHP. Consider the following using a Defer class and a closure:

class Defer
{
    private $closure;

    public function __construct($closure) {
        $this->closure = $closure;
    }

    public function __destruct() {
        call_user_func($this->closure);
    }
}

function example($url) {
    $handle   = fopen($url, "rb");
    $contents = '';

    // Magic happens here
    // Pass the $handle into the closure so we have access to it
    // When the function ends the variables will be out of scope and the $defer deconstructor
    // .. will be automatically called, closing the connection.
    $defer = new Defer(function () use ($handle) {
        fclose($handle);
    });

    if (false === $handle) {
        throw Exception('Failed to open stream to URL');
    }

    while (! feof($handle)) {
        $contents .= fread($handle, 8192);
    }

    return $contents;
}

The benefits of this are that you can pass anything into the Defer class to have it destroyed (or any other kind of functionality, come to that) when it goes out of scope: opening files, curl requests, etc.).

This guy could be on to something.

There is a definite huge gap in the market for a quick and easy way to see what’s going on whilst you get ready, without having to look at your phone and then get distracted on Facebook, Clash of Clans, or an email.

The question is: is this that useful? And by that, I mean sure, the weather is quite important… but is it really? I can tell you roughly what the weather will be by the month of the year; December will be cold, take a coat, July will be warm, rock a tee with shorts. The time… sure, but there’s your watch and your phone to tell you that instantly. News stories… you’re there to get ready, not know that Apple have just announced a new MacBook. The one area this interests me is with your calendar; showing you a schedule of what’s happening is really cool and one where you might have forgotten to do something.

I would imagine this is an in-between phase. The ideal solution would be something you can talk and interact with, without having to “look” at it. Kind of like Google Now, how you can say “OK, Google, what will the weather be like today” and it responds accordingly. Think Star Trek, or Galaxy Quest, with a computer ready to fetch and dictate information. Making it extensible would be awesome, imagine saying “Ok, Google, what’s my day like?” and it responds with:

Hi Chris, you have a meeting with Steve this morning in Bath. Traffic is pretty heavy so you’ll need to leave in 20 minutes to get there on time. Don’t forget to take an umbrella and coat, it’s likely to rain and will have a high of 16 degrees. It’s your mum’s birthday today, grab some flowers on the way home.

Like the PC, there’ll be one of these in every home in 20 years time. Now, where’s my chequebook, I need to invest in something…

1. Nesting

I used to write CSS on one line, and then indent the next if it was a child of the previous element. This worked really well and helps to understand inheritance and the way the markup is structured, and means you can see as much CSS on the screen at once as possible. I’ll give you an example:

<div id="header">
    <div class="foo">
        <p>
            <span>Lorem ipsum</span>
            <a href="#">Link</a>
        </p>
    </div>
</div>

#header{...}
    #header .foo{...}
        #header .foo span{...}
        #header .foo a{...}

However, if I now come to change the ID to something different I have to do it on every line. And if I have to change every line that means git has to track that. And if git has to track all those lines, then anyone else making a change means there will be conflicts. As such, it’s no longer a viable option: git should be able to tell you exactly what has changed, without confusion or conflicts for the tiniest change. With SASS this now looks like:

#header {
    .foo {
        span {
            ...
        }

        a {
            ...
        }
    }
}

Changed a element ID/class? Obvious. Changed a property? Obvious. No longer need to sift through the line comparing what had changed manually.

It’s also less code to write, notice that I haven’t had to write #header .foo{…}, I just need to ensure it’s nested correctly. Of course this still gets compiled to the exact same CSS as the first example, so the output is the same.

2. Partials and Imports

When you have a large CSS code base, as we do at Ents24, you really want to separate each component into their own respective file. Need to update the navigation? Head on over to nav.scss. The footer, well, that’s in footer.scss! I know that you can do this in CSS with @import, but that’s a new HTTP connection right there. Have 10, 20, or maybe even 50 of them and suddenly you’re in trouble. Yes, you could minify the files together but that’s still a bit of a hassle. It’s far easier to let SASS do it, and when you have multiple projects which all pick-and-chose the components, it’s a no-brainer.

You can have a master CSS file per project that is essentially a list of @import‘s for each component it requires. Each of those components come from a compiled SASS file, and each of those SASS files can make use of a single base file, variable file, and mixin file to make everything streamlined across your project. For instance, consider this folder structure:

`- sass
    |- _base.scss
    |- _variables.scss
    |- _mixins.scss
    |- grid.scss
    |- header.scss
    |- footer.scss
    |- nav.scss
    |- button.scss
    `- table.scss
`- css
    |- grid.scss
    |- header.scss
    |- footer.scss
    |- nav.scss
    |- button.scss
    `- table.scss
`- project
    |- desktop.css
    |- desktop.min.css
    |- mobile.css
    |- mobile.min.css
    |- widget.css
    |- widget.min.css
    |- foobar.css
    `- foobar.min.css

The sass folder will contain the files you edit, these are then automatically compiled down into their respective files in the css folder (the SASS files with an underscore will not get compiled!), and when those files are updated they will trigger the project files to be updated, and then those will be automatically minified for you to use in production.

You can hopefully suddenly see the huge benefits. desktop.css and mobile.css might actually make use of each of the CSS files, but the widget project might be a tiny thing that people can add to their own sites, and might only require the grid.css and button.css files. You’ve now a consistent brand feel across everything you do for free, and with ease of maintenance. Win.

3. Mixins

And lastly we come to mixins. These are small snippets of CSS which are frequently used throughout your codebase which are often annoying to write. An example of this is rounded corners. Remembering each vendor prefix is a pain and quite honestly I can’t count the number of times I’ve simply used border-radius in isolation and forgotten about old browsers. Update: Although a good example, this is probably bad practice now; you shouldn’t really use vendor prefixes too much, let older browsers degrade nicely.

We can define our mixins in our mixins.scss file, something like:

@mixin border-radius($radius) {
  -webkit-border-radius: $radius;
     -moz-border-radius: $radius;
      -ms-border-radius: $radius;
          border-radius: $radius;
}

And then make use of them in our SASS files:

#header {
    @include border-radius(10px);

    div {
        @include border-radius(8px);
    }
}

This saves us a huge amount of time, makes things easier to maintain, and also gives us a single place to contain horrible things like vendor prefixes, so once you no longer need them you can easily switch them out.

To sum up

I could have talked about variables, but you already know about them and how they make things easier. I could have talked about how you can easily make drop shadows just by using darken($color-x-feature, 10%), but that’s something for you to learn on your own… wait, I just did. I’m trying to say there’s a lot more to SASS than variables. If you’re a project manager or team lead and you’re looking to make your employees happier, more productive, and your codebase more maintainable, then you could do a lot worse than having a quick look at SASS.

if ($theSkyColour = 'blue') {
    // This will always be called, because the value will be "returned"
    // Equivalent of if ('blue') {
}

If you would switch the comparatives around you would end up with:

if ('blue' = $theSkyColour) {
    // I will produce an error
    // PHP Parse error:  syntax error, unexpected '=' in file.php
}

So you immediately know there is something wrong and you can correct it before it lands in production. But is this the best way to go about it? Possibly, it’s a matter of opinion; it’s been around for years and has made its way into some of the largest PHP projects such as WordPress, Symfony, etc.

Disadvantages

1. It’s harder to read: “Is the sky blue?” is much easier for us to understand than “Blue is the sky colour?”.
2. Is maintainability more important than a potential bug? I’m sure there will be people on both sides of the fence, and some in the middle collecting splinters.
3. Nowadays IDE’s tend to prevent this kind of thing from happening, you can set them to give warnings on assignments in conditions.
4. You can use a piece of software like PHP Code Sniffer in your build tool and reject anything that contains these potential nasties.
5. And, most importantly, it isn’t a silver bullet; it will do nothing to prevent the code below from being incorrect or error’ing:

if ($foo = $bar) {
    // I am always run and no errors are ever thrown
}

URI.js is a javascript library for working with URLs. It offers a “jQuery-style” API (Fluent Interface, Method Chaining) to read and write all regular components and a number of convenience methods like .directory() and .authority().

Why use PDO?

The number one reason is security. With plain MySQL functions you need to sanitise the input manually using type casting or mysql_real_escape_string(). With PDO this is all taken care for us and means we no longer have to worry about SQL injection. Great.

The ability to easily migrate to a different database engine (SQLite, Oracle, MSSQL, ODBC, etc.) is the cherry on top of the cake.

How to connect to a database

Connecting is just as easy as in standard MySQL functions, it just looks slightly different. We wrap the connection attempt in a try-catch statement so we can gracefully handle errors. E.g.

try {
    $dbh = new PDO("mysql:host=localhost;dbname=my_db_table", 'username', 'password');
} catch(PDOException $e) {
    echo $e->getMessage();
}

One thing I always do is instantly tell PDO I want associative arrays returned. I prefer them to objects, but your milage may vary. I also say that we want to deal exclusively in UTF8.

// Connection string, UTF-8 encoding, and fetch associative arrays
$dbh = new PDO("mysql:host=localhost;dbname=my_db_table;charset=utf8", 'username', 'password');
$dbh->setAttribute(PDO::ATTR_DEFAULT_FETCH_MODE, PDO::FETCH_ASSOC);

Inserting rows

Finally, some database interaction which lets us use the benefit of PDO – prepared statements. Essentially we insert placeholders into our SQL and define a value for those outside the statement. We do not, I repeat, we do not ever place user input directly into the SQL. This is susceptible to SQL injection.

Secondly, there are two ways to define these placeholders in your SQL statement: Positional and Named. You only ever want to use Named placeholders. Positional are, quite frankly, a silly idea. Positional placeholders ultimately will end up in inserting data in the wrong columns, or selecting data using an incorrect parameter. I’m only going to show you the correct way (in my opinion) so as to not give you bad habits.

// Define the SQL with named placeholders
$sth = $dbh->prepare("INSERT INTO `table` (`id`, `title`) VALUES (:id, :title)");

// Execute the query, replacing the placeholders with their true value
$sth->execute(array(
    ':id'    => 123,
    ':title' => 'I am the title'
));

You can see that we create a variable $sth (statement handler) which calls the $dbh (database handler) prepare method. The SQL should look pretty standard until we reach the :id and :title. These are our named placeholders. We can run this query by calling the execute() function which takes an array of the placeholder data. Quite simple.

The benefits of this are that our data is automatically escaped – we do not have to worry about calling mysql_real_escape_string(), after all we might not be using MySQL. Also, the benefits are that we can call the execute() functions many times without re-declaring the SQL statement, which will speed up our code execution.

// Insert three rows into the table
$sth->execute(array(':id' => 123, ':title' => 'First title'));
$sth->execute(array(':id' => 456, ':title' => 'Second title'));
$sth->execute(array(':id' => 789, ':title' => 'Third title'));

Selecting

Now that you have just mastered inserting data, selecting is a piece of cake, it’s very similar, and also gives us a chance to go over a few new functions.

// Select some data
$sth = $dbh->prepare("SELECT `id`, `title` FROM `table` WHERE `id` > :country_id");

// Execute the query, replacing the placeholders with their true value
$sth->execute(array(
    ':country_id' => 200
));

// How many records did we find?
echo 'We found ' . $sth->rowCount() . ' records.';

// Loop over the data
while ($row = $sth->fetch()) {
    echo 'My ID is ' . (int)$row['id'] . ' and my title is ' . htmlentities($row['title']);
}

To get the number of rows returned you can use the rowCount() function (akin to the mysql_num_rows()), and to loop over the data you can use the fetch() function (akin to the mysql_fetch_assoc()). If you wanted to return all of the rows into a variable without performing a loop you can do fetchAll(). Otherwise there are no gotcha’s here.

Updating data

You’re going to be bored of me saying this, but there is nothing different here than the previous examples:

// Update a row
$sth = $dbh->prepare("UPDATE `table` SET `title` = :title WHERE `id` = :id LIMIT 1");

// Execute the query, replacing the placeholders with their true value
$sth->execute(array(
    ':title' => 'I am the newly updated title',
    ':id'    => 123
));

// Did we manage to update the row?
if ($sth->rowCount() >= 1) {
    echo 'Yup, the row was updated.';
} else {
    echo 'Nope, row was not updated.';
}

Deleting data

Again, nothing too complex:

// Delete a row
$sth = $dbh->prepare("DELETE FROM `table` WHERE `id` = :id LIMIT 1");

// Execute the query, replacing the placeholders with their true value
$sth->execute(array(
    ':id' => 123
));

// Did we manage to delete the row?
if ($sth->rowCount() >= 1) {
    echo 'Yup, the row was deleted.';
} else {
    echo 'Nope, row was not deleted.';
}

Binding params, and execution

This comes down to preference. I prefer the execute() because we are avoiding function calls, speeding up our code, and easier to update. But I’ll go over all three.

bindParam() is asking for a reference. It is not asking for an immediate value, it only receives the value once the execute() function is called. This is probably the most confusing aspect of PDO, so let me give you an example.

// Select some data
$sth = $dbh->prepare("SELECT `id`, `title` FROM `table` WHERE `id` > :country_id");

// Set binds
$sth->bindParam(':id', $tableId);

// Define variables
$tableId = 123;

// Execute
$sth->execute();

This works because, although $tableId does not exist when referenced, it is defined before our execute() call. The reason I do not like this is because it is leaving an uncertainty to the statement. You could quite easily bind the parameter, then change the variable for some reason and cause an error. You also have the problem that literals can not be used since they cannot be referenced. So, bindParam(':id', 123) would result in an error.

bindValue() to the rescue! This works in the same way as bindParam(), but it uses the value straight away, be it a literal or a variable.

execute() is what we have been using in the previous code samples, so does not need an introduction.

The same thing three times?

exec(), execute(), and query()

These all do the same thing, run a query. But they do so in different ways. In my opinion you should only ever use execute() as it is the only one which works with prepared statements which, in time, the other two can become susceptible to SQL injection. They also have their nuances, exec() can only be used for queries that do not return data objects (e.g., SELECT statements), and generally speaking query() is only used on SELECT statements. But since you cannot use prepared statements (e.g., placeholders), I wouldn’t bother with them.

Wrapup

You now know the basics of PDO. You can see it isn’t a scary monster and it really is easy to switch. You now know how to insert, select, update, and delete rows. You know how to safely pass in parameters using placeholders (remember, named not positional!) and so you now never have to worry about SQL injection.

Handsontable is a minimalistic approach to Excel-like table editor in HTML & jQuery. Now with column and row headers!

Making good-looking graphs shouldn’t be hard. Morris.js is a lightweight library that uses jQuery and Raphaël to make drawing time-series graphs easy.

Turn.js is a JavaScript library that will make your content look like a real book or magazine using all the advantages of HTML5. The web is getting beautiful with new user interfaces based in HTML5; turn.js is the best fit for a magazine, book or catalog based in HTML5.

Git allows groups of people to work on the same documents (often code) at the same time, and without stepping on each other’s toes. It’s a distributed version control system.

Brackets is a new open source project founded by Adobe to push tooling on the web forward. Based on the principle that the best developers to build tools for web developers are in fact web developers, Brackets is built in JavaScript, HTML and CSS.

Demonstration and Download

To view a demonstration of the code in action, click here.

You can view the Github repository here.

The PHP backend

This type of program is often used in online games like action bank slots and GoBonanza. It is designed to be flexible — it can handle boards of any size and will place the starting 4 disks in the center. The PHP is also very quick — the size of the board does not really effect the performance due to the way its programmed. It only allows legal moves to be played, each move needs to flip at least one of your opponents disks, if you play an invalid move it will give you the option to skip your play.

A quick snippet of the traversing function in the PHP class

<?php
/**
 * Traverse the board to see if we can take any of our opponants disks.
 *
 * To traverse the board we can add, substract, or do nothing with each X and Y coord.
 * Keep traversing until we reach an empty position, a wall, or our own disk. Once
 * reached an end, traverse back down the coords replacing the disks with our own.
 *
 * @param $xDiff int
 * @param $yDiff int
 * @access private
 */
public function doTraverse($xDiff, $yDiff) {
    // Set variables
    $x = $this->_x;
    $y = $this->_y;
    $continue = true;
    
    // Begin the loop
    do {
        // Work out the new coords to test
        $x += $xDiff;
        $y += $yDiff;
        
        // What is in the next position?
        $next = isset($this->_boardContent[$y][$x])
            ? $this->_boardContent[$y][$x]
            : 'e'; // Edge

        // Have we hit an edge or an empty position?
        if ($next == 'e' || $next == '-') {
            $continue = false;
        }
        
        // Have we reached our own disk colour?
        else if ($next == $this->_turnInPlay) {
            // We are currently at our own disk, move back one so we are at our
            // .. last free (potentially) disk.
            if ($xDiff > 0) { $x--; } else if ($xDiff < 0) { $x++; }
            if ($yDiff > 0) { $y--; } else if ($yDiff < 0) { $y++; }
            
            // Are we where we started?
            while ($x != $this->_x || $y != $this->_y) {
                // Change this disk to the player who just moved
                $this->_boardContent[$y][$x] = $this->_turnInPlay;
                
                // Set the number of disks this flipped
                $this->_disksFlipped++;
                
                // Move back one coord to begin another replacement
                if ($xDiff > 0) { $x--; } else if ($xDiff < 0) { $x++; }
                if ($yDiff > 0) { $y--; } else if ($yDiff < 0) { $y++; }
            }
            
            // We have converted all of the possible disks, exit the traverse
            $continue = false;
        }
    } while ($continue);
}

The Javascript frontend

Javascript provides a real-time view of what disks will be flipped. The traversing function is a virtual copy of the PHP classes.

Functionality to be built

One piece of functionality that is really needed is ensuring a legal move is actually possible. If it isn’t then it automatically skips to the next player, and if that player cannot play a legal move either then it ends the game. I’m not sure if it will be best to implement this in either PHP or Javascript — both options have their benefits.

I am thrilled to announce the arrival of a new stable version of Node.js. Compared with the v0.6 releases of Node, this release brings significant improvements in many key performance metrics, as well as cleanup in several core APIs,

Researchers have clocked light beams made of “twisted” waves carrying 2.5 terabits of data – the capacity of more than 66 DVDs – per second.

Ratchet is a component library for PHP that provides developers with the tools to create real time, bi-directional applications between clients and servers. This is not your Grandfather’s Internet.