Posted on 19 December 2012 by Nick Boyce
One of the things I most like about hacker culture is the acceptance (almost celebration) of failure as an essential part of a the path to success.
This post, and the accompanying discussion on Hacker News had a few quotes I really liked:
As soon as you believe you’re the smartest man in the room, you’re in the wrong room
And this one:
My job is not programming. My job is delivering value using programming.
Posted on 13 December 2012 by Nick Boyce
Part of the way the team has evolved this year has required putting more emphasis on consistent coding conventions and procedures to make our collaboration smoother. Here are a few notes.
Javascript
Google’s Javascript style guide, plus some JSHint config.
CSS/Less
Our own internal styleguide.
HTML
Our own internal styleguide.
Ruby
Nothing yet, but probably the Github Ruby Styleguide in the future.
Git branching
We use something vaguely between git-flow and “Github flow”. In essence, master is always deployable, develop is a shared staging branch, and feature branches are created for major or disruptive features. I could see us moving to git-flow next year.
Project naming
We decided to name our projects after film directors. So far Romero (our internal CSS framework), Kubrick (our next-generation platform in development) and Eastwood (an experimental Backbone-based product page) are active, but I am sure more will sprint to life in 2013.
It’s pretty lean so far, but we’re making refinements all the time.
Posted on 07 December 2012 by Nick Boyce
I’ve been enjoying the Art.sy engineering team’s blog. Their approach and technology stack are spookily similar to what we have in store for the next generation of the platform at Easyart. Even their blog runs on Jekyll just like this one!
As usual, I’ve spent a fair bit of time on Quora this week. The question What is Spotify’s architecture? had an interesting answer from Spotify developer Niklas Gustavsson. They have around 100 backend services, most of which handle only a single task.
Paul Irish’s Javascript Development Workflow of 2013 has a lot of good tips. Things are moving so quickly in this space it’s hard to keep up, so I find myself watching more and more presentations at home where I would have otherwise been watching TV.
HTTP Headers For Fun & Profit lists some interesting HTTP headers returned by popular sites.
There’s a great post called Why Google Went Offline Today and a Bit about How the Internet Works over on the CloudFlare blog from a while back that sheds some light on how some of the underlying mechanics of the internetw work.
The best interface is no interface is very much an approach we are trying to head towards with some of the product customisation screens we’ll launch in 2013. I’m really excited about what next year has in store.
Finally, this post is my first one created and edited in Prose. It’s a really neat tool to create and edit code in Github repos in the browser, and is perfectly suited to (infact, created for) Jekyll blogs like this one.
Posted on 03 December 2012 by Nick Boyce
A humble prediction:
Traffic to Easyart.com from 7" Android devices is going to have a noticeable bump after Christmas.
Google and Amazon are both pushing their tablet products hard this gifting season, and both have pretty compelling products at a great price point. Even I – a dedicated Apple nut – have just bought a Nexus, and I’m going to retire my first generation iPad to the giant eBay in the sky.
When the postman handed the package over, he said “all I am doing is delivering Googles”. That being the case, we’d better get our skates on and set some new breakpoints in our responsive CSS!
Posted on 27 November 2012 by Steve Rydz
A few weeks ago I attended a series of tooling workshops in Brighton. One of the workshops was focused around build process, and particularly Grunt.
Currently we use CodeKit to compile our Less and JavaScript files so we end up with concatenated, minified versions of each. So far this has worked well but we have found it difficult to keep things synchronised between team members.
Soon after returning from the workshops I started to investigate Grunt in more detail and we put a plan in place on how we could use it to aid our build process.
What we came up with was the following file structure:
Site_Name/
|__ public/
| |__ static/
| | |__ css/
| | |__ js/
| | |__ img/
| |
| |__ index.html
|
|__ spec/
|
|__ static-src/
| |__ less/
| |__ js/
|
|__ grunt.js
|__ README.md
The public directory contains anything public facing, including all static assets such as stylesheets, scripts and images. Anything in the static/css/ and static/js/ directories is compiled from static-src/.
The spec directory contains our selenium tests.
This is where we keep all of our pre-compiled files.
Our Less files are broken down into modules. There is a master file that imports all dependencies. This master file is then compiled into CSS, minified and placed in the static/css/ directory.
Just like our Less files, all our JavaScript is broken down into modules. These are then concatenated to a master JavaScript file which is placed in the static/js/ directory. We also create a minified version for production which sits alongside the master file in the static/js/ directory.
Grunt makes the process of performing all of the above tasks very simple. Everything is defined inside our grunt.js file:
module.exports = function(grunt) {
grunt.initConfig({
lint: {
files: ['static-src/js/*.js']
},
less: {
development: {
options: {
paths: ['static-src/less/'],
yuicompress: true
},
files: {
'public/static/css/master.css': 'static-src/less/master.less'
}
}
},
concat: {
dist: {
src: [
'static-src/js/lib/jquery/jquery.js',
'static-src/js/lib/jquery/jquery.cookie.js',
'static-src/js/app.js'
],
dest: 'public/static/js/master.js'
}
},
min: {
dist: {
src: 'public/static/js/master.js',
dest: 'public/static/js/master.min.js'
}
},
watch: {
files: ['static-src/js/*.js', 'static-src/less/*.less'],
tasks: 'default'
}
});
grunt.loadNpmTasks('grunt-contrib-less');
grunt.registerTask('default', 'lint less concat min');
};
Grunt is very extensible and here we are using it in it’s most basic form using (with the exception of Less) only it’s built-in tasks. The goal here was to become less reliant on a third-part app such as CodeKit in favour of a platform that we can easily build upon.
Going forward, this is likely to be the way we do things. We will no doubt build on this in time, making use of more advanced features, and maybe even build some tasks of our own, but even as it stands, this is a good position for us to be in.