I just read a post on net tuts called What are you using?. Several front-end developers answered the same set of questions about their setup.

Whilst I wasn’t part of the article, I still thought it might be interesting to publish what my answers would have been. I’d also encourage other front-end developers to do the same, as it’s always interesting to read about others tools and processes.

What’s your primary development focus? As a front-end developer my main focus is HTML, CSS and JavaScript. I also work with Ruby and PHP (mostly in the form of WordPress) when I’m building and maintaining templates.

What hardware are you using at the moment? My primary work machine is a 21” iMac. At home I use a 13” MacBook Air. I also have an iPhone 4s and Nexus 7.

Which editor or IDE do you use? Exclusively Sublime Text 2. I love how fast and extensible it is, and every day I learn something new about it.

What software can you not live without on a daily basis? Obviously Sublime Text 2, but I also spend a fair amount of time on the command line using the likes of Git and Grunt, for which I use iTerm2. Other than that, the Chrome Developer tools are increasingly indispensable.

There’s been a lot of talk lately about The Vanilla Web Diet and not relying on jQuery. This lead to me revisiting some of the code I wrote when I was learning jQuery.

A little over a year ago I published a post on how to make a simple JavaScript gallery. In the spirit of encouraging developers to learn the language behind the library, I’ve written a vanilla JavaScript version.

See the demo →

The HTML

The HTML is really simple. We have one main image and a list of thumbnails, each linking to the full sized image.

1
2
3
4
5
6
7

<img id="main-image" src="img-01.jpg" alt="Placeholder">

<ul id="thumbnails">
  <li><a href="img-01.jpg"><img src="img-01-tn.jpg" alt="Thumbnails"></a></li>
  <li><a href="img-02.jpg"><img src="img-02-tn.jpg" alt="Thumbnails"></a></li>
  <li><a href="img-03.jpg"><img src="img-03-tn.jpg" alt="Thumbnails"></a></li>
</ul>

The JavaScript

The amount of code here is fairly concise, and not that much more than last time. Whats more, it doesn’t require the overhead of the jQuery library.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

(function () {

  if (document.querySelectorAll) {

    var links = document.querySelectorAll("#thumbnails a"),
        mainImage = document.getElementById("main-image");

    for (var i=0; i < links.length; i++) {
      links[i].onclick = function (e) {
        e.preventDefault();
        var source = this.getAttribute("href");
        mainImage.setAttribute("src", source);
      };
    }
  }
})();

Now lets step through the code.

Keeping the window object clean

First we wrap our code in a self-executing anonymous function. This keeps our variables from polluting the global scope:

1
2
3

(function () {

})();

Checking for support

Next we’re going to declare the variables we need, but as we’ll be using querySelectorAll, we’re just going to check that the browser supports this before executing our code:

1
2
3

if (document.querySelectorAll) {

}

If the browser doesn’t support querySelectorAll then the browser will skip over the code that follows.

Now we can declare the variables we need. The first will cache all the thumbnail links, and the second will cache the main image:

1
2

var links = document.querySelectorAll("#thumbnails a"),
    mainImage = document.getElementById("main-image");

Switching out the main image

Now we want to loop through all the thumbnails and listen for the click event. When they’re clicked, we change the src attribute of the main image to the thumbnails href value:

1
2
3
4
5
6
7

for (var i=0; i < links.length; i++) {
  links[i].onclick = function (e) {
      e.preventDefault();
    var source = this.getAttribute("href");
    mainImage.setAttribute("src", source);
  };
}

Improvements?

That’s all there is to it. If theres anything you think could improve this code, I’d love for you to share in the comments or maybe even in your own post.

This week I started using Bourbon and it’s accompanying grid system, Neat. I really like the way they’ve been put together and think they’ll be really useful going forwards.

It’s easy to get started with bourbon and neat, and neither of them dictate the way you should structure your application. Lets go over some of the basics.

Installing bourbon and neat

Bourbon and neat are both gems, which makes them really easy to install. Just type sudo gem install bourbon neat into your command prompt and hit enter. Your now ready to harness the power of bourbon.

Setting up a project

In your command prompt, cd into the directory you want to store the bourbon and neat files, then install the dependencies as follows:

1
2
3

$ cd ~/Sites/project/scss/
$ bourbon install
$ neat install

Add the following to the top of your main .scss file:

1
2
3

@import "bourbon/bourbon";
@import "neat/neat";
// The rest of your CSS goes here

Using bourbons mixins

Bourbon comes with lots of really useful mixins and utilities. Making use of them is simple, for example a linear gradient:

1
2
3

.container {
  @include linear-gradient(#1e5799, #2989d8);
}

For more examples check out the docs.

Harnessing the power of the grid system

Many grid systems make you add presentational classes to your HTML which to a lot of us is undesirable. With neat, you don’t need to do that at all. If I wanted to create a container with a primary content area and sidebar, all I would need to do is:

1
2
3
4
5
6
7
8
9

.container {
  @include outer-container;
}
.content-pri {
  @include span-columns(9);
}
.content-sec {
  @include span-columns(3);
}

Your HTML would look something like this:

1
2
3
4
5
6
7
8

<div class="container">
  <div class="content-pri">
      <!-- Main content area -->
  </div>
  <div class="content-sec">
      <!-- Sidebar -->
  </div>
</div>

Neat also does some cool things with media queries. You can define breakpoints by declaring a variable like this:

1

$tablet: new-breakpoint(min-width 767px);

You can then call the appropriate media query like this:

1
2
3

@include media($table) {
  // Your code
}

Again, there are more examples in the docs.

Extending the mixins

Including these mixins is absolutely fine, but your codebase could become bloated very quickly if you find yourself calling the same mixins repeatedly. For example if you used the clearfix mixin on a lot of elements, the following code would appear in your compiled file for every one of those elements:

1
2
3
4
5
6
7
8
9
10
11

.element {
  *zoom: 1;
}
.element:after,
.element:before {
  content: " ";
  display: table;
}
.element:after {
  clear: both;
}

What I recommend is making use of the @extend rule. First you would create a silent class which includes your required mixin. This code will only be compiled if you extend it:

1
2
3

%cf {
  @include clearfix;
}

Then, anywhere you want to use that mixin, just extend your class:

1
2
3

.container {
  @extend .cf;
}

This technique can significantly reduce the amount of repetition in your codebase, which is always a good thing.

Striking the right balance

Bourbon manages to do what many other frameworks have so far failed to do, which is provide you with a collection of best practices without dictating how you structure your code.

I love the fact that my codebase is only going to include the things I need from bourbon, without lots of unused utilities, and my HTML can be as semantic as I want it to be. I strongly recommend giving bourbon a try on your next project.

Testing our websites and apps on devices other than our dev machines can be a pain, but there is a (free) service out there that makes it really easy.

xip.io is a service built by 37signals to solve a common problem. What is xip.io?

xip.io is a magic domain name that provides wildcard DNS for any IP address.

It is really easy to use, and lately I’ve been using it on a daily basis. Here’s how it works:

Let’s say your running a local server at http://localhost:8000. You could also access that via your LAN IP. Here’s how to find your LAN IP on a Mac and on Windows.

Whatever your LAN IP is, paste it into your address bar, with the port number appended e.g. http://192.0.0.1:8000. You should see the same thing that your seeing at http://localhost:8000. If you’ve made it this far, it should all be plain sailing from here.

Now you want to see your localhost site on your mobile. Fire up the browser on your device, making sure you are connected to the same network as your dev machine. In the address bar, type your LAN IP, followed by .xip.io and if you are using a port, append that e.g. http://192.0.0.1.xip.io:8000.

That’s it. You can now test your development code easily on whatever devices you have handy.

Update: I have found that sometimes, it isn’t necessary to actually use xip.io. If it the above doesn’t work for you, try visiting your LAN IP, with the necessary port appended e.g. http://192.0.0.1:8000. Also, remember that you must have your local server running on your dev machine.

I’m going to share a quick jQuery tip: How to add multiple attributes to an element. I see people use chaining to achieve this on a regular basis, but there is a better way.

When adding multiple attributes to an element, the simplest way is to create an object, as shown in the following example:

1
2
3
4
5

$(".main-image").attr({
  "src": "/img/main-image.jpg",
  "title": "This is the main image",
  "alt": "This is the main image"
});

Personally I find this method much more readable and easier to maintain.

These days I use the command line all the time. Something I rely on quite heavily is tab completion, but it can be frustrating when it comes to case sensitivity.

Thankfully, there is a really simple solution to this. Just open your .bash_profile file, found in your home directory. As I use sublime I would do so like this:

1

$ subl ~/.bash_profile

Then add the following line to your ~/.bash_profile:

1

$ bind "set completion-ignore-case on"

Once you have done that, run the source command on that file:

1

$ source ~/.bash_profile

You should be good to go. From now on, your bash prompt will ignore case.

I had completely forgotten about the :not selector until today, when a colleague asked me if there was away to apply a style to a class but exclude one of the child elements with CSS.

Typically this wouldn’t be the ideal solution to the problem but we were unable to change the HTML we were working with. The markup in question was along the following lines:

1
2
3
4

<div class="example-div">
  <span>Label text</span>
  Data text
</div>

What my colleague wanted was for the span to be set in the default sans-serif font, already defined, whilst the rest of the text set in a mono-spaced font.

One way we could have solved it would be to apply the style to the entire div and then reset the span to the default font, like this:

1
2
3
4
5
6
7

.my-div {
  font-family: "Courier New", Courier, monospace;
}

.my-div span {
  font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
}

The problem with this is that we are changing a style which has already been defined, just to change it back to its initial value. Enter the :not selector:

1
2
3

.my-div:not(span) {
  font-family: "Courier New", Courier, monospace;
}

That’s much better. Browser support for this particular selector is actually pretty good too. All modern browsers (Chrome, Firefox, Opera and Safari) and IE9 upwards support it.

I admit this isn’t revolutionary but it was the first time I’d had a reason to use this selector and in the spirit of Chris Coyier’s recent entry on the Pastry Box Project, I decided to write about a problem that I solved today. After all, there is a chance that it may be of use to someone somewhere.

As another year comes to an end, I find myself reflecting on what I’ve learned over the past twelve months. It’s certainly been an important year for me.

Starting off on the wrong foot

At the beginning of the year I was in a job that I found very dissatisfying. I was forced into using outdated technologies and was asked to do several things which I considered to be bad practice. I was also finding it hard to get a new job because I was obliged to work two months notice which potential employers found off-putting.

A blessing in disguise

In February I received a blessing in disguise when the project I was working on got cancelled. I was relieved because the project had been an absolute nightmare and I wouldn’t have wanted my name associated with it in any way. A couple of weeks later I was made redundant as a result of this. I was lucky enough to find a suitable position before my notice period was up.

A shift from client services

The position I found was as a front-end developer at Easyart.com. I knew after my two interviews that this would be the perfect role for me. Previously I had always done client-orientated work, but I really felt like I needed a change in focus which is one of the appealing parts about accepting the position at Easyart.

Learning new skills

When I started at Easyart in March, I had a fairly narrow set of skills. I was fluent in HTML and CSS, knew a bit of jQuery and was getting into Less, but that was about it. Throughout the next few months I learned how to use the command line and GIT, improved my JavaScript skills, started using build tools like Grunt JS and started writing selenium tests.

Goals for 2013

I really feel like I’ve come a long way this year and have learned so much. It finally feels like all the pieces are falling into place. That doesn’t mean I don’t have anything left to accomplish though. Here are a few of my goals for 2013:

1. Redesign this site

This year I stripped away all the design from this site, hoping to give it a fresh lick of paint at some point. Whilst I played with the layout a bit throughout the year, I never really took it any further than that. I haven’t done much in the way of design at all this year so this will be a good chance to get my design skills back up to scratch.

2. Re-build this site on Jekyll

I’ve had a few experiments with Jekyll this year but haven’t fully committed to it yet. I really like how straight forward it is and how snappy it makes the sites that use it too. I still think WordPress is a great CMS, but its just a bit too heavy for my humble blog.

3. Write more

I’ve had some degree of writing success this year, having one article published in .net magazine and another at onextrapixel.com. I also started the year blogging relatively frequently on this site with a handful of tutorials which seemed to go down pretty well, although that petered out later on. I’d like to share and document more next year.

4. Experiment more

Whilst I’ve learned so much this year, I want to make more time for experimentation. Like most developers, I learn by doing so I’m hopefully going to be doing more projects just for the sake of learning. I’d also like to get more involved with open-source projects too.

5. Participate in the community

I feel like I became slightly withdrawn from the web community this year. For example, I had started going to Croydon Creatives, but most of this year I let it slip. Living in North London it’s unlikely I’ll be able to attend every meet-up, but I hope to at least attend a few.

I also want to make more of an effort at the other meet-ups, conferences and workshops I attend throughout the year. I’m an introvert so starting up conversations with people I don’t know doesn’t come easy to me, but I still need to push myself harder in this area.

Onwards and upwards

Well, that’s my brief recap of my year and some of my aspirations for the year to come. All that’s left is for me to wish my readers a happy and prosperous new year.

Last night I discovered a little Sass trick that until now, I wasn’t aware of — working out percentages. Well, I knew it could be done but I assumed it required a complicated mixin or something like that.

So, here is how to simply work out a percentage using Sass:

1
2
3

.content {
  width: percentage( 580 / 940 );
}

Which compiles to:

1
2
3

.content {
  width: 61.70213%;
}

Essentially, all you have to do is pass the target (your desired width) as the first argument and the context (the containers width) as the second and you’re golden.

It’s a very common thing to use JavaScript in our web pages to add interactivity, but in the age of responsive design, we don’t always want that functionality to kick in unless the viewport is the appropriate size.

The problem

You have something triggered by JavaScript on the site you’re building but you want to handle that functionality differently when the viewport is less than 640px.

The solution

What we need to do is:

• Find the width of the viewport
• Check to see if the current width is greater than our target width, and if so, execute our code
• Add a listener to run the above check when the viewport is resized

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// Function to check the width of the viewport
var checkWidth = function() {

  var viewportWidth = $(window).width();

  // If the viewport width is greater than 640px
  if (viewportWidth > 640 ) {
    // Execute your code
  } else {
    // Do something else
  }
}

$(document).ready(function() {

  // Call the checkWidth function on page load
  checkWidth();

  // Call the checkWidth function again when the viewport is resized
  $(window).resize(function () {
      checkWidth();
  });

});

How do you handle JavaScript responsively?

This is how I’ve been handling my JavaScript recently and have found that it works really well, however I am interested to hear how others have tackled this same problem.