Tag Archives: Dev Stack

Reporting test coverage with Blanket.js

Way back in my list of things we’re planning to use I said we were going to use saga for our JavaScript test coverage tool. But since that decision was made, Blanket has updated to support Jasmine and Blanket was always more attractive to me. So instead of Saga, here’s some chat about Blanket.

What is Blanket.js?

Blanket.js is a code coverage tool. It involves almost no effort to set up and provides detailed reports of the line coverage for every file tested.

Why use Blanket.js?

Because having an idication of how well tested your code is valuable. The problem with code coverage in general is that all it is able to check is whether or not a line has been run by your test suite. This means that while it can fairly reliably tell you if something is not being tested, it can’t with any certainty say that something is being tested. As long as you remember this though, it’s handy to have around. Who wouldn’t want a warning that they’ve missed something in their tests?

Blanket is particularly good because it is easy to set up and use, and offers custom reporters to allow its output to be adapted to your needs. Not that we’ve used that.

On the down side, Blanket provides no feedback on how tested a file that isn’t being tested is. This means that it takes a bit of wrangling to get warnings about files with 0% test coverage. I was only really tangentially involved in this but I’ll try to cover it in the future.

We also needed to engage in a bit of code wrangling to get it to play nicely with Require. The final problem it presented was that it cannot be run through the file:// protocol which . Next time, details on these wranglings.

Advertisements
Tagged , , , , , ,

Testing with Jasmine

Historically we’ve sloppy with our JavaScript Unit testing. Jasmine has been part of our lives for a while, but we’ve not followed a Test Driven (and certainly not Behaviour Driven) approach to writing JavaScript.

This changes with this project. The green-pasture of the new code base has removed a lot of the resistance to this (“There’s no point writing tests for this, when everything else is untested”). The introduction of Require has also made it easier to start doing things properly. With require it’s very easy to load in the distinct modules to tests and it’s very clear how to start accessing its functions in a test.

What is Jasmine for?

Jasmine is a JavaScript unit test framework. It encourages Behaviour Driven Development. My understanding of BDD is that it’s basically Test Driven Development but the tests are defined by coherent human-readable descriptions of the behaviour they are testing. Jasmine runs these tests in an actual browser.

Jasmine is not the only one of its kind, but it is a good one and it is the one we’ve gone with. qUnit is also popular. In our case Jasmine’s main contender was RhinoUnit, the most significant difference between the two being that Jasmine runs in a browser while Rhino is Ant based and does not require a browser.

Why use Jasmine?

The only unique attribute of it that lead us to it was that we’ve used it before. However, it has other selling points:

  • Is one of the popular and good frameworks
  • Easy syntax
  • Runs in browser
  • Has a Grunt plugin

The first two points are pretty straight forward. The third is perhaps slightly contentious. RhinoUnit was the main alternative for being our JS testing framework specifically because it doesn’t run in a browser. Not running in a browser is a good thing because it is much easier to incorporate into our Java build process and also means you aren’t plagued by browser differences. The down side is, your tests no longer throw up errors caused by browser differences.

The other nail in the coffin for Rhino as far as we’re concerned is that we’re using Grunt to automate a lot of our work anyway, and with Grunt already part of our work flow adding Jasmine to it is barely a job. This means we can easily automate the running of it. Our automated tests currently only run in PhantomJS, but we can open the tests manually in any browser we want to see how they run. Our Grunt plugin claims that it can be used to run in multiple browsers too, we just haven’t tried yet.

We’re also using Jasmine-jquery. This is a Jasmine plugin which provides some extra functionality to Jasmine at the expense of introduing a dependency on jQuery. We have no problem with this because we’d rather write our tests using jQuery to save time anyway and our JS will either never reference the mighty $ (mobile) or have a dependency on it anyway (desktop) so we shouldn’t be introducing any problems with this (famous last words?)

Next time, using Jasmine

Tagged , , , , , ,

Headless Browsing with PhantomJS

We’re using PhantomJS because it is Grunt’s preferred browser for anything automated that needs one. Like running JS Tests.

What is PhantomJS?

PhantomJS is a headless webkit browser. What does that mean? Well, it’s a webkit browser (like Chrome and Safari) that doesn’t have a visible interface.

Why use PhantomJS?

Because it gives you most of the benefits of running tests in a browser but it goes much faster and less intrusive. I say most because it is not designed to emulate the quirks of a particular mainstream browser, it is its own thing. However, because it is webkit it has a lot in common with others in that family.

Currently our main build process does not include Grunt, so we need to be able to run our JavaScript tests through Gradle as well. Originally our plan was to use JS Test Driver but we found that it does not sit well with RequireJS. There are apparently work arounds to fix JS Test Driver, but we opted instead to adopt Phantom as our test runner. This does mean our automated tests are not running in other browsers, but this should be temporary until Grunt is up and running anyway.

Unfortunately this JS Test Driver vs Phantom debate was something I had very little to do with, so I have no real thoughts on that.

That’s all I really have to say on the matter, if I had much direct interaction with it I’d probably like it less. Its real beauty is in how little I have to do because of it.

Tagged , , , , , ,

Automating with Grunt

Of all the new things from our new dev stack, Grunt is the one I find most exciting. Quoting from the website, Grunt is a task-based command line build tool for JavaScript projects. But what is that?

What is Grunt for

I can’t really think of a more succinct way to put it than that. Although when I first read it, it was pretty meaningless to me so let’s take it apart a bit.

Grunt is run from the command line, but doing so is not complicated so anyone unfamiliar with the command line need not panic.

It is used to run Tasks. What do I mean by tasks? Well, anything. Tasks can be defined and then run with Grunt, providing vast scope for automating repetitive actions in your work flow.

Finally, for JavaScript projects? Well, because it’s written in JavaScript it is best suited to tasks that affect JavaScript. But it already has many plugins for CSS and HTML based actions.

Why use Grunt?

With the addition of SASS and Require to our process we’ve added some complexity to our front end build process. Also, our old system was written in Java meaning it was oblique to members of the front end team or arduous to adjust.

Grunt solves all these problems beautifully. We can use it to automatically compile our SCSS into CSS as we’re working. We can use it to automatically run our suite of JavaScript tests and JS Hint as we are working and we can use it to run the require optimizer to bundle our JavaScript up (say it with me now) as we are working. These things alone were enough to make me fall in love. Boiling all the complexity we introduced by adding new tools to our Dev Stack down to one solution.

However, the goodness continues! Grunt is a Node module, so is written in JavaScript. Our team makes a distinction between front end developers and back end developers. We front end types are reliably confident with JavaScript, HTML and CSS but not necessarily any other language. This means that our Front End Build solution can now be placed into the hands of the front end development team.

We’re not done yet though! Grunt has an active community of plugin developers creating more and more tools we can easily include just by adding it to Grunt. In addition to the ones listed above, we’ve already got one which can base-64 encode images into our CSS to reduce requests on the mobile site and we’ve barely started looking.

A caveat

For all my love and excitement about Grunt it does present a problem to us. The machines we’re using for our CI, running our tests and build process on the repository whenever anyone checks in are currently unable to run it. In the future we’re planning to add it, but right now we’re only using it on our local machines. More on using Grunt in a CI in the future. Presumably.

Tagged , , , , ,

Removing Backbone from Mobile

This week we established a few depressing things.

  1. The mobile site is going to have to support IE because Windows Phones use it.
  2. Zepto doesn’t just not support old IE, it doesn’t work on IE9 and 10 either. This means we can’t rely on it on Mobile.
  3. Backbone depends on jQuery/Zepto more than we thought.

For the mobile site, we are acutely aware of code efficiency and file size. For this reason we are unwilling to include jQuery on it. This has created a spiral of difficulties for us though this week.

Backbone needs jQuery or Zepto’s document ready function to use Routers. We tried a few home-written alternatives and none of them worked. This wasn’t a huge disaster though because we were already having some difficulty with the Router. Because we weren’t using it entirely as intended – just using it to detect which page we were on and run the relevant script we were finding issues. We are not using it to produce a One Page App. Our architecture still involves speaking to the server through Query Parameters, which the Router was not great at handling. So we came to accept that we were going to have to get rid of the Router.

In doing this, we removed Zepto from the page we were working on and found that this broke our Backbone View. With a little digging we established that the View was indeed using Zepto. It makes sense really, we were perhaps a little naive to think otherwise. Backbone uses a very similar syntax to jQuery for binding events, why wouldn’t it use it?

As an interesting aside, Zepto was not being listed as a dependency to require by the View, but it was being loaded into the page. This meant that our require module had acquired a silent dependency on it. This isn’t wholly surprising but I suspect we’ll do well to remember this is possible in the future.

Losing Views was a more serious issue. Without Views, Backbone wasn’t really adding all that much to our app. Between it and Lo dash, we were adding about 8kb to our javascript bundle, but for what gain?

We saw three reasonable responses to this

  1. Provide a fallback, so users on IE would download jQuery to replace Zepto. This would make our lives easy but really destroy the experience for Windows Phone users
  2. Create a custom jQuery build with just the bits Backbone needed and hope it was reasonably sized
  3. Remove Backbone from the mobile site

Falling back to jQuery

This was lazy-me’s favourite solution, but clearly we weren’t going to do this. Even Windows Phone users deserve to use the site in a reasonable way.

Creating a Custom jQuery

We didn’t look deeply into this. I created a custom jQuery bundle without any extraneous modules and still found it far too big for us. I also tried substituting in Sizzle for jQuery in Backbone. All this did was tell us Backbone Views use more than the selectors from jQuery

Remove Backbone from the mobile site

With the other two out, this is what we’re doing. Now that we’ve made the decision I’m ok with it really. Our brief flirtation with Backbone was good but it was not adding enough value to our site to merit the extra file size. This is not a criticism of Backbone, if our application architecture was different then it would be awesome. But most of its work is already being done by the back end, and the rest we will be able to recreate in a smaller bespoke package and by obeying conventions in our coding.

We may well still use it on the Desktop site though, once we get there.

Tagged , , , , ,

Improving SASS with Compass

On Sunday I talked about why CSS is dumb and SASS is awesome, today I’m going to talk about how SASS is dumb and Compass is awesome. That’s not entirely fair, Compass relies on SASS, but it is the thing that really unlocks the potential of SASS with limited effort on your own part.

What is Compass for?

SASS is a language for writing Stylesheets, Compass is a framework built in SASS. This means that while SASS enables all sorts of cleverness, Compass applies that cleverness in ways that should be useful to almost anyone.

Why use Compass?

The two features of compass which are most exciting me right now are CSS3 helpers and Spriting. It does other things too – helpers to automatically adjust values, text styling, a reset file and layout support. These all sound marvellous but I’ve not touched the things yet. Let’s talk about the bits I have played with.

CSS3 helpers are a collection of mixins to help with CSS3. I’m sure this is a surprise to no one. What it means is, rather than writing out multiple lines of browser specific code for any given CSS3 feature, instead you just use one of Compass’ mixins to produce the same result. This resolves the annoyance of writing the same command more than once and also means that when if the browsers settle down and we stop needing the browser specific versions, we can change it in one place and update our commands everywhere.

There’s no reason you couldn’t write this out yourself in SASS, but Compass has had more time put into each mixin than you’re likely to want to and is a hell of a lot easier.

Spiriting, on the other hand, can’t be done without something extra. There are other libraries that do this for you, but the fact that its integrated with your Stylesheets is nice. But what the hell do I mean when I say spriting?

Well, with Compass you can use a diverse set of individual images which can be automatically turned into a single sprite image, with the positioning worked out automatically. Gone are the days of remembering the offset necessary to get a specific icon, instead you just use the icon image and let Compass turn it into a Sprite. I believe the phrase is having your cake and eating it too.

So that’s Compass, a way to really leverage using SASS without re-inventing the wheel or straining yourself in any significant capacity.

Next week, how to set up SASS and Compass.

Tagged , , , , ,

Improving CSS with SASS

Syntactically Awesome Style Sheets is a CSS Pre-processing language. It is not the only one, but it is the one we’ve chosen to use. The other major players in the CSS-Pre-Processor-Fight are LESS and Stylus. Our decision making process between these three and countless others that exist but have less press was not massively sophisticated. We looked at some articles which generally seemed to prefer SASS. That said, they all had good things to say about the others just claimed SASS had a slight edge.

Because writing CSS-Pre-Processor is going to get old fast, I’m going to stop talking about them in general and instead talk just about SASS. Everything about why to use SASS is generally applicable to them all.

What is SASS for?

CSS is stupid. As your selectors start having to get more specific, so you start writing the same thing over and over. If you need to use similar bits of styling with minor differences multiple times (I’m looking at you border-radius), then you’re writing it out again. If you want to keep a consistent colour palette you’ve got to remember what colours you’re using and if you’re changing them, you’ve got to change them all manually. These are hallmarks of a stupid language.

But it doesn’t have to be. What if we stopped writing CSS and instead let it become an output, like what happend to Machine Code back in the mists of time? This sounds radical, but it isn’t really. We’re already pre-processing our CSS before serving it to a client by minifying it, why not expand that process to allow us to write CSS intelligently?

So why use SASS?

Enter SASS. It is a cleverer langauge than CSS which compiles down into valid CSS. This means that using SASS doesn’t create any sort of compatability issue or overhead for your user, just adds some weight to your compile step. But what do you get for this added weight beyond vague claims of cleverness?

As ever, the SASS homepage provides a better summary than I will here, and indeed a better in depth discussion too. But here’s my own summary.

How to use SASS

Nesting

Ever written anything like this?

.aClass { 
	width: 100px
}
.aClass .anotherClass { 
	height: 200px
}

With SASS you can write it like this

.aClass { 
	width: 100px
	.anotherClass {
		height: 200px;
	}
}

This gives you a syntax which better represents the relationship between selectors and involves writing .aClass one less time. Result!

Selector Inheritance

How abou this? Ever needed this?

.aClass, .extendedClass {
	width: 100px;
	border: solid 1px red;
}
.aClass.bigText, .extendedClass.bigText {
	font-size: 2em;
}
.extendedClass {
	border-width: 3px;
}

SASS let’s you extend classes like this

.aClass {
	width: 100px
	border: solid 1px red;
}
.aClass.bigText {
	font-size: 2em;
}
.extendedClass {
	@extend .aClass;
	border-width: 3px;
}

Again, less writing and a better representation of the relationship between classes. But what about the .aClass.bigText selector? That meant writing .aClass twice and writing things twice is everything I stand against. We can’t nest it as before because that would produce .aClass .bigText rahter than .aClass.bigText, but have no fear!

.aClass {
	width: 100px;
	border: solid 1px red;
	&.bigText {
		font-size: 2em;
	}
}

The & represents the original selector and lets us nest the .bigText inside .aClass.

Variables

Let’s say you wanted to have a standard version of blue used across your whole site. Rather than remembering its hex code, you can store it in a variable

$blue: #3bbfce;
.aClass {
	background: $blue;
}

Mixins

Mixins provide parameterizable reusable sections of code. For example, whenever we want a broder radius we need something like this

.aClass {
	-webkit-border-radius: 5px;
	-moz-border-radius: 5px;
	border-radius: 5px;
}

.anotherClass {
	-webkit-border-radius: 2px;
	-moz-border-radius: 2px;
	border-radius: 2px;
}

With SASS, we can boil it down to this


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

.aClass {
	@include border-radius(5px);
}
.anotherClass {
	@include border-raidus(2px);
}

I should also include a note clarifying the difference between SASS, SCSS, and SASS.

SASS is a CSS Pre-processing language. Originally its syntax was modelled on haml and was very terse, keeping keystrokes to a minimum. This was popular with many people but also put others off. I am in the second camp, I want write my CSS using CSS syntax with logical extensions.

To cater to the likes of me a new syntax was developed, Sassy CSS or SCSS. SCSS is a syntax for SASS which looks a lot like CSS and is how I choose to write my SASS. However they didn’t deprecate the old syntax which still exists and is called SASS. So, SASS is a pre-processing language, SCSS is a syntax for SASS, and SASS is also a syntax for SASS. Clear as mud? Good.

I will almost never mean SASS the syntax when I talk about it, because I don’t use it. I also have a habit of using SASS and SCSS interchangeably. Sorry.

And that’s your whistlestop tour of SASS. It makes writing and maintaining your CSS easier without creating problems for the client.

Tagged , , , , ,

Utilitying With Underscore.js

Underscore.js is a utility library which Backbone depends on. I’m afraid I don’t have a huge amount to say about it though because the only reason we’re using it is so that we can use Backbone. Lovely cuddly Backbone.

What is Underscore for?

It provides functional programming support for your JavaScript. This includes tools for manipulating Objects, Collections and Arrays as well as some generic utility functions.

It also supports some baisc HTML templating. This is the only feature I’ve actively used as it is valuable for producing Backbone Views. As a templater it’s pretty simple, which is probably a good thing. It’s been fit for all my extremely limited needs so far. This is tepid praise but based on inexperience rather than any negative feelings.

So why use Underscore?

So that we can use Backbone and because it makes life easier. A bit like functional jQuery.

Well that was short. Let’s talk about Lodash while we’re here. Lodash is a drop in replacement for Underscore. In theory this means that if you write your code base using Underscore, you can then change your mind and use Lo-Dash.

So Why Use Lo-Dash?

It’s a bit bigger but offers performance enhancements and some extra features. It’s also possible to generate specific subsections of Lo-Dash, so you can just get the bits relevant to Backbone and use that instead of the whole thing.
This link from the comments provides a much better answer to this question than I can. Lo-Dash has been designed to provide a more efficient, more consistent and better tested alternative to Underscore. It has been design with compatibility in mind though, so that if you don’t use the extra Lo-Dash features, the two should indeed be interchangeable.

We haven’t decided between the two yet. Lodash sounds pretty good but the whole thing is 19kb compared to Underscore’s 4kb. Taking just a Backbone version will reduce that but right now I don’t know how much. These enhancements sound great but are they 15kb of download better?
John in the comments has pointed out that the size difference is not as great I originally thought. It’s actually more like half a kilobyte.

The good news is since it drops in to replace, we should be able to build around underscore then swap in lodash to see if things are better.

Tagged , , , , ,

Stucturing with Backbone

Backbone.js is a library for giving structure to your JavaScript. It provides a framework that looks very similar to Model-View-Controller to base your app on.

What is Backbone for?

Combined with Require.js, this means our apps can have a well defined and sensible structure that’s starting to look like Object Orientation. I can barely contian my excitement either. No really, I can’t, this is awesome.

So why use Backbone?

Using Backbone means your code can fit into a consistent and comprehensible format. You keep your data in a Model. You keep your Modles in a Collection and you access your Collection through a View.

We’re developing with a view to produce control widgets that can be reused in different places – specifically desktop, mobile, and a summary screen. Using Backbone we can write the Model and Collection code once, only changing the necessary bits in the View to reuse it.

Backbone also provides a Router feature that decides which scripts to run based on the URL. To facilitate this, it can either use or polyfill for the HTML5 History API. This means you can manipulate the url and browser back/forward behaviour without actually changing the page.

We’re planning on sharing urls between desktop and mobile pages. However this is complicated because some things that share a page on desktop are separate pages on mobile. With Backbone Routers this should be possible.

In summary, backbone provides a structure to your JavaScript that makes it easier to write, maintain and reuse.

Tagged , , , , ,

Modularisation with Require.js

Require.js is well covered ground. Smarter people with more experience working with it have got the basics at very least sorted. I’d recommend reading some or all of the linked articles for your Require hit, really. This one by Aaron Hardy in particular is wonderful, although only the last page actually covers Require, the whole thing is excellent. So, with the caveat that there are better places to get this information in place, what is Require.js?

What is Require.js for?

Require is a JavaScript library for Asynchronous Module Definition. It is by no means the only one available, but it is one of (if not the) most popular. Asynchronous Module Definition is an API for defining distinct modules of JavaScript with explicit dependencies. These dependencies can then be loaded asychronously if that’s your bag, although in the real world I have reservations about this. Powerful and unfounded reservations.

So why use it?

The main attraction to me is project structure. Using Require I can write my JavaScript in small cohesive files without any fuss. Gone are the days of sprawling JavaScript files that keep everything together because of a chain of dependencies and a reluctance to separate files based on some faith that they’ll sort themselves out in the end. With require each file is a sensible module of code and the other modules that it has a relationship with are listed at the top of the file. Lovely.

It also kills the risk of accidentally introducing an unintended dependency. I won’t start referencing things I shouldn’t just because they are available to me because making them available is an action that requires a moment’s thought (and it really is just a moment).

The final thing it brings to the party is asynchronous loading. As the page is loading, Require will establish all the dependencies of your Main Javascript file, including nested dependencies and load them asynchronously. When I say Main here I really mean it in terms similar to a Main file in Java – this should be the single starting point for all your JavaScript on the page so the dependencies and nested dependencies should be all the JavaScript on the page. Since all these files are loading asynchronously it should give you a full suite of JavaScript very quickly. It’ll also cache your modules so if a single module is reused on future pages, its already loaded and don’t need to be grabbed again.

I haven’t done any tests of the actual effect of this in reality yet, so what follows is really nothing but prejudice and a resistance to change. Loading modules asynchronously like this means adding a huge number of extra http GET requests to your page load. Sure each file is coming down quickly, but that goes against everything at least one thing that I’ve been taught about web performance – keeping requests to a minimum. However! Require even has suspicious curmudgeons like me covered too.

Part of the attraction of Require over alternative AMD loaders is its optimizer r.js. This can be used before serving your code up to minify, obfuscate and concatenate your modules. So far my only success has been bundling everything into a single file, but I understand it is possible to configure it so that you produce a site-wide bundle and a separate bundle loaded separately for every page. This is my preferred solution based on no actual testing. Fortunately though, once I’ve worked out how to make it go, it should be easy to try all three of these options without impacting the actual code. This flexibility makes me happier than is reasonable.

Next time: details of how to use Require (Spoiler alert: It’s really easy).

Tagged , , , ,