To create my blog entries I decided I'd use a custom AngularJS directive. It's not strictly necessary, but it does allow me to apply a consistent template to my posts which means I can control their structure (to some extent) and presentation centrally. It's also an excuse to use AngularJS :)

The Final Product

Let's take a look at the code for the directive:

app.directive('blogPost', function() { //by default say it was posted today var curDate = (new Date()).toLocaleDateString(); return { restrict: 'C', //isolate the scope scope: {}, transclude: true, templateUrl: 'app/partials/blogpost.html', controller: function($scope) {}, link: function($scope, element, attrs) { //setup some initial values $scope.title = attrs.title || 'template blog post title'; $scope.posted = attrs.posted || curDate; $scope.author = attrs.author || 'template author'; } }; });

Now let's break down what each element of this is doing.

Restricting the Directive

A directive can be restricted to only apply when defined in a certain set of ways: as an element (E), as an attribute (A) or by class (C) - or as a combination of these.

For example you may want to be able to call upon a directive in existing markup by using an attribute, or determine this should only be defined by it's own tag, or you may wish to be flexible in how the directive is used and allow it to be defined in all ways possible.

In this case we're using the class restriction as I want to be able to apply some styling based on this being a blog post so we kill two birds with one stone.

Isolating the Scope

We need all our blog posts to have their own scope so we can define their title, posted date and authorship - if we don't isolate the scope then all instances of this directive would share the same scope and therefore the same details.

We don't set anything in the scope as we don't need to in this example, a blank object will do.

Transclusion

This throws a lot of people, but I think its more simple than it sounds. The way I think of transclusion is as "include content here", where the content is the inner HTML of the element the directive is defined upon. For example if we have the following template for a directive:

And we use this directive in our HTML like this:

Here's some content that we want to transclude.

Then the content within our "my-directive" tag will be pulled into our template wherever we specified the "ng-transclude" attribute.

The Template

The template provides structure to our post giving it a heading and a sub heading with the posted date and author. Finally, we have a DIV with the ng-include directive which acts as our "include content here" marker. The inner HTML of the element we defined the blog post on is pulled and dropped into place here - in our case this inner HTML is the markup for the blog post.

//{{title}}

{{posted}} by {{author}}

The Controller

This directive has no controller, but if it did this would be the place to put any logic, in particular any that manipulated the DOM and/or scope. When designing AngularJS I usually take the approach of moving business logic and server access into services and leave only logic that mediates between the view and model in the controller.

The Link Function

The link function is called for each instance of a directive (in contrast to the compile function which is called once for all instances). It is a chance for us to setup the directive, in this case we simply read the attributes of the element the directive is defined upon to get the title, posted date and author details of our post (and set some defaults if they are undefined), then set them into the scope for use in the template.

Further Work

This was a quick example to serve a simple purpose, but I can see ways to improve or extend this:

Only display a summary of each post and use routes to show full content
Swipe left and right on mobile to navigate posts (i.e. next/previous actions)
Use MarkDown or similar to avoid needing to wrte HTML in posts
Persist blog posts in a database

Admittedly I'm not the voice of long experience having only recently made the change from permanent employment to contracting, but in that time I have still formed a pretty solid opinion on my new career - and I love it.

I suppose to explain why I love contracting I need to start by saying something about me personally - I love to learn and to explore new ideas. This trait may well be one of the reasons I gravitated toward computing as a field, I can think of few industries where change is so relentless and fast paced.

I loved my permanent job for many years, as evident in the length of time I stayed, but more latterly I felt I was in danger of being institutionalised, which in and of itself isn't necessarily a bad thing. But in a business where there wasn't much exploration of new technical ideas or approaches I felt it was time to do something new.

Since leaving permanent employ I've had the opportunity to explore and use many of the current tools, frameworks and methodologies used by the web development community - for example: AngularJS, Symfony 2, Doctrine 2, RESTful APIs, Bootstrap, Responsive Design, GruntJS, Bower, PHPStorm, GIT, Vagrant, Composer, Test Driven Development to name a few.

The other great thing about contracting is that in addition to bolstering existing skills and working on new ones while in a contract, you can work on these between contracts as well. I've spent some of my time since my last contract working with AngularJS and Symfony 2 to recreate an old website of mine, Eye On MOGS, the only hold up for release is the onerous amount of data input required to populate its database. I've also explored AngularJS, Symfony and RESTful APIs in an example Todo Application, something which can be extended and improved over time.

I've explored Bootstrap and Responsive/Mobile First Design in this website, the Todo Application and will be applying these new skills to Eye On MOGS and future projects - mobile is a force you can't afford to ignore on the web these days.

I have a few other projects in mind for the future including a keyboard management library in JavaScript, a system for managing my own work where I am debating whether to use the MEAN stack or LAMP with Symfony 2 and Doctrine as frameworks (in either case I would opt for Bootstrap and AngularJS on the front-end) and an "infinite whiteboard" app inspired by Google Maps which I hope will work well in conjunction with a tablet and pen to provide an infinite sheet of paper on which I can design ideas.

Contract PHP/JavaScript Developer

//BLOG