This is by no means a ‘definitive’ guide or a ‘correct’ guide. The correct way to learn a language and all of it’s quirks and good parts is entirely subjective. However, there are some logical places to start, and to further progress to.

JavaScript

First up, JavaScript. Learn JavaScript. Not jQuery, not MooTools, not some other library or even framework. Just the language. It’s functional, prototype based, event driven and whatever else programming - it’s important to understand the quirks and odd parts of the language, as well as all of it’s wonderful and elegant parts. JavaScript is a lovely language to work with, and it’s future is looking even brighter with the arrival of ECMAScript.next around the corner..

(I’ve tried to keep the resources linked to free / open-source so that everyone can dive in to and enjoy the stuff here.)

Resources

Books

There are some fantastic free books for learning JavaScript.

Eloquent JavaScript

JavaScript Enlightenment

Once you’ve read one or both of those (maybe read JavaScript: The Good Parts or something else instead, who knows!), you’ll have a really good knowledge of the language as a whole.

At this point I’d recommend delving a little deeper in to the more complex parts of the language - or at least acknowledging that there’s a bit more to come back to. These are the bits that I find really important:

Scope (variable scope, execution contexts etc) and Hoisting

Every language has it’s own scope rules etc, it’s important to know how JavaScript’s work. Hoisting is also essential to understand (or else you might wonder why you can’t call a function, that you’re sure you should be able to etc). Seriously, hoisting is overlooked sometimes, but it’s important.

What you need to know about JavaScript Scope

JavaScript scoping and hoisting

Functions and function scope

Closures

Closures took me a while to grok (sometimes I still wonder if I fully understand them, especially when it comes down to memory leaks etc), and are seemingly complicated on the surface. However, they are everywhere, and a fundamental part of JavaScript development. Basically, they are a very clever way of referencing variables etc that were originally part of a different scope. Due to the way JavaScript scoping works, an inner function has access to it’s parent functions scope (and therefore all of its variables etc), say you return this inner function, it will still have access to things from the parent scope. That’s my pathetic explanation, these will help much more:

Closures from MDN

Closures in JavaScript

Closures: Front to Back

JavaScript closures

Use cases for JavaScript closures

What is a closure in JavaScript

Anonymous functions and immediately-invoked function expressions

Immediately-invoked function expressions are commonly used in JavaScript, they’re a nice way of creating a new scope to avoid global pollution etc. They’re all over the place, but jQuery plugins make common use of them if you’d like to see them in the wild.

Immediately-invoked function expression

Anonyous function

Design Patterns

Learning JavaScript design patterns e-book

Understanding design patterns in JavaScript

’This’

It’s important to understand exactly what ‘this’ is, and in what context (otherwise you can end up headbutting things when the context changes within an event handler, or something similar). But, it’s also important to understand that you can change the context of ‘this’ with things like call and apply. ‘this’ is at your mercy ;)

What is ‘this’ in JavaScript

Better JavaScript - what is this?

Changing The Execution Context Of JavaScript Functions Using Call() And Apply()

Prototypes and prototypal inheritance

JavaScript isn’t a classical OOP language, it doesn’t have classes or anything like that. However, it is a prototype based language, and prototypes are beautiful once understood. Whilst you may not personally be creating your own function constructors, prototypes or instantiating anything with the ‘new’ keyword it’s still imperative to know this, in my opinion, as it’s critical to how JavaScript works ‘under the hood’ and prototypes are everywhere (array prototype, string prototype…).

Protoypes in JavaScript

Understanding prototypes in JavaScript

Prototypes and Inheritance in JavaScript

Introduction to Object-Oriented JavaScript

‘OOJS’ (a random find, but an enjoyable read)

Function declarations VS Function expressions

There is a difference (relates back to hoisting too).

What is the difference between a function expression vs declaration in Javascript?

Memory leaks and garbage collection

There’s a bit of a misconception that because JavaScript is a garbage collected (rather than you allocating and de-allocating memory manually) language, you need not pay attention to memory and how it works. This really isn’t true, you need to be aware that JavaScript ‘tracks’ it’s memory usage via references - when something no longer has a single reference to it, it can be cleaned up. Things like event handlers can easily cause a memory leak if not cleaned up properly. It’s important that things in your code that need them have an exit strategy. I tend to opt for a simple destroy() method, it’ll unbind necessary event handlers, null out things it needs to etc (even better when you can add these things in to a common prototype…). Be aware that traditional ‘circular references’ are handled very well by modern browsers, this should only really bother you in IE7 and below.

Understand memory leaks in JavaScript applications

Memory Management

High-Performance, Garbage-Collector-Friendly Code

Managing Memory in Windows Store Apps

jQuery

jQuery is a library that makes it a breeze to work with the DOM, perform AJAX requests and all sorts of other things.

It’s nothing but good old vanilla JavaScript under the hood, don’t think you need jQuery for everything, use it where it aids you.

Resources

books

jQuery fundamentals

A graphical explanation of JavaScript closures in jQuery (this is nice as it gives you an overview of closures from earlier but in a jQuery context)

Backbone.js

Now, once you’ve been working with JavaScript and jQuery (or whatever combination of libraries) for a while, you’ll start to crave structure, maintainability, state management and lots of other things that stop you ending up with a spaghetti code mess.

It’s not that you can’t achieve well structured, awesome code without a framework - it’s not that at all, it’s just that it’s a bit easier when you’re following tried and tested methods / patterns etc. In this case there’s a bunch of MV* frameworks at your beck and call - Backbone, Ember, Angular, Spine and so on. These give you the things you need to get the job done - models, views, controllers, routers, views etc.

The only reason I’ve named this section Backbone.js is it’s the one I work with the most, and felt I could link to the best resources on. The others are equally great.

Resources

Books

Backbone Fundamentals

Backbone.js memory management

Backbone.js has recently added some really handy methods for aiding memory management - listenTo() and stopListening(). However, it’s still important to understand what’s going on with these methods, how Backbone.js handles event bindings and how things worked “in a time long ago”. They’re not magic save alls (unfortunately), you still need to know where you’re referencing things.

Backbone.js And JavaScript Garbage Collection

Zombies! RUN! (Managing Page Transitions In Backbone Apps)

Really with frameworks, I just recommend playing around. Some are very opinionated - Ember.js for example, some just give you minimal building blocks - Backbone.js. There’s no right or wrong really. Should views and models have direct references to each other? Or should they communicate purely via an Event Aggregator? Both are totally fine, it depends on what you need to build, and what it needs to do.

I hope this helps somebody in the pursuit of learning JavaScript. And remember, JavaScript is everywhere. Fancy some server action? You’ve got Node.js, fancy writing a Windows Store App? It’s cool, you can do that with JavaScript. Also, dig right in to source code. I’ve learnt a bunch reading through code behind things like Backbone.js.

Today marks one year of me in my first, proper grown-up job - and therefore one year at Audacious and as a fully fledged front-end web developer.

I graduated from Northumbria last July, and fell in to my current role a month later. It’s been all go since then!

Working for a start-up as a first hire has been not only an honour (graduates are sometimes perceived as ‘risky’ after all) but a whirlwind adventure.

I’ve learnt a lot, and can happily say that I’ve improved a lot along the way. That, for me, feels like an arrogant thing to say. But, in a start-up environment, you have to learn and create quickly. I learnt to learn quickly along the way, too, I guess.

One of the hardest things to learn was that failure is inevitable. That failure may be the inability to think of a solution, the fact that a solution isn’t as good as you wanted it to be, the fact that you don’t understand or can’t grasp something, breaking something unintentionally…and I’m sure the list goes on.

At heart I try to be a perfectionist and do things the ‘right’ way - which is of course always up for debate anyway. Sometimes, the right way isn’t apparent the first time. Sometimes a working, but less beautiful, version comes first. I had to learn that you need to just accept that less beautiful version sometimes. You will quickly learn how to make it better - and then you will make it better. Nobody will laugh at you. Everybody has to start somewhere.

You will fail. You will shout. You will cry (maybe). You will swear. But you will also succeed. We sometimes forget to take a step back and appreciate that people are using the things we’re making. Real people. Not all of the feedback will be positive, but for every bit that is you can think “I built that”.

I’ve learnt to be a sponge. I love to soak up the knowledge of those around me - I get to work with some very cool and talented developers. That knowledge may not necessarily be linked to the technologies I work with or things I do, but there’s no bad-learning. If you want to see how something works, look and ask questions. I’m quiet, but I’ve got much better at asking questions, and unless you work with some odd developers, people love to talk about and explain the things they’re passionate about. Someone will always know something you don’t, and you’ll always know something someone else doesn’t. Everyone has different strengths, and when they come together to create something, that’s pretty awesome.

This industry is friendly. It’s crazy, but if you contact a magazine or a book and ask to contribute, they’ll probably let you. If you ask someone on Twitter if they fancy ‘hacking’ something together with you, they’ll probably say yes, or express interest. If you’re stuck, people will happily help you - heck, Stack Overflow et al are dedicated to it.

It’s been a good year. I’ve made 660 Github commits, adding 327,155 lines to the codebase. Some (many) of those lines were shocking and have been re-factored in to something good since. Something I’m happy with. Thankfully that doesn’t last long - if you can look at code a month later, and still think it’s great, some guy somewhere said you weren’t trying hard enough. It’s true, you’ll want to change ALL THE THINGS a few weeks later, you’ll just pick new things up that often, but remember to give yourself a pat on the back at least some of the time ;)

I don’t know if this will be of use to anyone, but this is a Gist that I put together (and update periodically) with Git commands that I use frequently. I like having a reference I can quickly go to, and it may benefit someone out there :)

So, I’ve really wanted to get back in to blogging. I’ve been neglecting my writing itch for a while. I have my ‘regular’ blog over at Tumblr, sure, but that’s for cute rat pictures and general tid-bits. This space is where I want to write about web related topics. My personal site is always sorely neglected by me, usually due to time (and laziness, of course).

In previous carnations it’s used WordPress, it was last using ExpressionEngine (which I’ve always been fond of). However, I wanted something I could get up and running quickly, very quickly, this time. No starting from scratch with stylesheets, templates, databases, CMS installation etc. Not because I don’t enjoy hand crafting a site from the ground up, but because I realised it just wasn’t going to happen…anytime soon.

Enter Octopress.

Octopress is an insanely awesome framework for Jekyll, that’s Jekyll the static site generator that powers Github Pages.

I decided to set up Octopress on my own hosting; instructions are available for deployment to Github Pages, Heroku or via Rsync.

My hosting is provided by Webfaction, who to be quite honest are incredible. There’s no affiliate links or anything like that here, I just really appreciate them as a solid host, offering a lot of features.

The steps to setting up Octopress on Webfaction were easy-peasy.

First, I installed Octopress itself following the official guide.

That’s our blog set up locally.

I then decided I would use Rsync for deployment.

Then it was just a case of configuring my Rakefile using the settings found in the deployment section of this well written guide.

If you’ve found your way here looking for Webfaction and Octopress advice, the only thing the above guide really misses out is how to add your SSH key to Webfaction’s authorised keys list. It’s okay though, all of that information is here in the official Webfaction guide.

And that was that, I ran the rake commands as per the Octopress instructions and everything was live and working. Simples.

(At this point you will want to go and create a repository somewhere though, and commit your blog’s source there).

Everything about Octopress is…well, just swell for a geek. You write your posts using Markdown. If you want to insert code snippets, that’s not a problem. Templates are fully customisable, but a lovely HTML5 theme comes as standard. Deployment is painfully simple.

The hope is that this will get me writing again :)