Trying the 13" Retina MacBook Pro

I have a love hate affair with my current home setup. You may have noticed a trend this last year. I have been trying out different Macs to find the perfect combination. Yeah, its a little sad but for a techie its both interesting and “worth it“! Since i stopped being self employed i have been struggling to find the “perfect“ setup.

Right now, i have an 11“ Air for my personal stuff and presenting, and a 27” iMac for occasional freelance work and media stuff. They are a good combination. However, i have ended up with my digital life scattered all over the place. The iMac has two different OSX installations* hosting 3 different user accounts. In trying to create separation i have created a mess.

The 11” Air is showing its age**. I wondered if its time to go back to having a single machine for everything.

One box

For years, i had a little white 13” Macbook i used for everything, it was fast enough.

My needs peaked in 2008-2011 when i was studying, running + Lion and using a Mac Mini as a TV system. I constantly had 3 different Macs on the go. My media server, my personal / studying machine, and my work machine.

When i became employed, i sold my work machine and condensed the work machine and media server into an iMac. I’m now wondering if its time to fold all of my computing into a MacBook again. Completing the circle!

I’m not going to need it.

I suspect i have a lot of “optimisations” i’m simply not going to need. For 2-3 hours coding a prototype i really don’t NEED a 27“ Display. For knocking out a blog post on a train or notes at a conference a smaller laptop is nice but the different between the 11” Air and 13” rMBP is slight.

Even with my media, since getting Sky TV the Apple TV is used rarely. I don’t buy many blu-rays or DVD to convert so performance there is nice, but not essential.

Two Weeks

The Air and iMac combo is nice, i could spend a small fortune upgrading either of them. However, instead i am trying to consolidate. Hopefully this MacBook can do it all***. I have two weeks to find out.

(*) A snow leopard install which is a preserve of my old “freelance work account”, all my old client data / project files. A new “Mountain Lion“ install for media serving and general browsing and stuff.
(**) I stupidly brought the model with 2GB ram, not 4GB, safari now runs a like a dog :(
(***) This is my third attempt, the last two attempts (a 2012 MacBook Air and a 2012 Mac Mini) both ended with returns.

Published: 13 January 2013 | Categories: , Apple Permalink

Cub - File Base Publisher.

A few days ago i started work on a new side project, a tiny site publisher inspired by Textpattern, Jekyll and Second Crack.

The basic premise is simple, i wanted an easy way of publishing blog posts and longed for something “simple”. There are loads of static site generators and CMS’s out there, so you may wonder why i choose to create yet another one. Well, boredem and curiosity i guess!

Cub consists of 3 parts, a tag engine (lifted from Textpattern), a file parser (borrowed heavily from second crack, at least for now) and a renderer (i wrote that bit).

Like Textpattern, Cub tries to keep the code simple. It’s precedural and fast. It renders content out to HTML as quickly as possible and then caches it to save the effort in the future. Uncached pages render in 20-50ms and cached pages render around the 11ms mark.

Cub is not truly static, each page is generate at request allowing for the intergration of dynamic content such as comments and twitter feeds.

The tag parser and the structure (section, page, form) is from Textpatten (hence Cub is GPL) but the implmentation behind most of the tags is bespoke. The and structural tags (like ) work like thier textpattern equivalent.

So far the main challenge has been working with flat files, specficially retreving data sorted by ‘posted’ date. As far as i can see there are two methods.

The first method uses the file names themselves, prefixing the file name with the posted date so content/hello-world.md would become content/2012-10-08-hello-world.md. This then allows you to easily output files in posted date order.

The second method is a little more complex, but alot more flexable. Inside each file there is a piece of meta data containing the date the content was posted (eg “posted: 08-10-2012”), when rendering this information is used to sort the posts.

The second method has a big drawback, it requires the reading and processing of every file in a given section to render the index page. This is less than ideal.

In practice the performance cost seems to be minimal, in a quick benchmark comparing method two to method one the difference was less than 10% (over 128 content files). The flexibilty comes from the meta data format, method two could potentially sort by any peice of metadata so thats the way i have gone for now.

Right now, cub is an experimental project. Its been very enjoyable hacking on something simple and lightweight. I intend to keep pushing on it too see where it goes.

Cub is up on github, feel free to take a look at github.com/jamieknight/cub.

Published: 11 November 2012 | Categories: Development Permalink

Be yourself

Something which I got into a discussion about today is the marketability of generalist developers versus deep specialists. Here are some quicks thoughts and observations:

1: it’s easier to be known for something specific.

Being associated with a specific thing makes it easier to raise your profile. For example, being know as the JS guy or the accessibility guy helps people to remember you. Rightly or wrongly generalists seem to fall under the radar a little.

2: Generalists are valuable in small teams

At the BBC I work in a large department but on a small focused team. Having a small team is nice, it helps avoid to much communication overhead and it’s easier to organise.

However for a small team to be effective we have found that having at least 1 team member with a broad skill set is very valuable. In my team we have a software engineer with deep backend knowledge and two front end devs with deep front end knowledge. We also have a generalist who has a broad understanding of both.

The generalist works well to bind the team together, working across many tickets and getting many things rolling. As a team we are exploring how best to operate and how best to share knowledge effectively. Pairing, code reviews and ‘show and tell sessions’ seem effective so far. We’re trying to avoid getting too process driven but its early days.

Back to the point having a generalist in a small team helps with flexibility and prevents silos.

3: Generalists reduce risk.

If your working only with deep knowledge specialists and someone becomes unavailable at short notice it can be difficult to continue forward momentum. When I was self employed this burnt me hard a number of times. Generalists provide some mitigation, worse case they can dive in with some degree of confidence.

So in short generalists rock but it can be hard to get known for anything.

Finally, there are a wide range of generalists, in my view it runs right through the stack with designer / front end, front end / PHP and PHP / java & database etc.

So back to the point, is there an optimal employment strategy? Do you really have to specialise to make the most of your career? At this stage I don’t think so, at least not for the first few years. It’s best to be yourself and see where that takes you first.

Published: 5 November 2012 | Categories: Opinion Permalink