I've seen companies that have no form of source control, companies using backups as source control, people still using Source Safe along with a whole bunch of actual good source control solutions such as Git and SVN. But when I say what's your source control strategy I don't mean what tool are you using, I mean how are you using it.

Checking you're code into source control adds many benefits such as merging, versioning, reverting etc, but to get the most out of it you really need a strategy to define how you will use it. There is no one right way and the strategy you use ultimately depends on your team size and what you are doing.

Here are a few example strategies:

The didn't know about a strategy approach

You've got a source control solution, you're regularly checking your code in but you've never made a branch.

This is actually quite common. Everyone is developing against the same branch, you've got all the benefits of seeing who changed which piece of code, you can revert when you need to revert and when you do an update there's some help with merging.

What you don't get though is the ability to have work happening in parallel and one being released before the other. If you needed to do a release either you have to have a way of hiding the unfinished updates as the code is pushed to live or some way of reverting just those bits.

A branch for every feature

The other extreme is to have all development work happen on a new branch. When it's ready to be release the code is merged back into the trunk and then released (plus some testing along the way).

The advantages of this are your trunk is always the same as what's on live meaning emergency fix's can be made without trying to find the last release in the source control history. Developers can also work separately without stepping each other toes and can release.

However with more than one development happening at the same time, whoever merges second could have a big job on their hands. All that branching is also going to be time consuming.

Updating branches often

So you're using branches and to avoid a tricky merge are keeping the branch up to date regularly, possibly daily. Anyone who's tried to merge a feature branch after 3 months of development can testify that it doesn't always go smoothly and can take some time.

Only updating the branch at the end

You've decided to accept the large merge at the end of the project. You don't like it but figure all those small merges during the project actually add up to more time than one big one at the end. You can then also concentrated on getting the feature built without the regular merge distraction.

A tag for each release

If you've ever needed to find a previous release and only have the history to go on it can be hard. If there's no comment that says release to live you are basically guessing based on release date and last commit.

A tag is basically the same as a branch and if its part of your release plan, you've got a good way of finding each release to live.

A branch for live, a branch for dev

In this setup you have a live branch that always match's what's on the live site. There's less need for tags as commits to this branch are normally also a release to live, and because the branch is always in sync with live, emergency fix's are taken care of.

The downside with this approach is everyone is working on the dev branch, so exceptions should be made and feature branches used when it makes sense.

So…

So there are some of the strategies I've come across, but there will be plenty more. What you do ultimately relates to what kind of work you do, how frequently you release and what kind of team size you have. But the one thing you must do with all of them is make comments on each commit. If you don't then source control becomes virtually useless.

I've had my Surface Pro 2 for around 3 months now, I was one of the people to pre-order and got it on the release day. I personally find reviews written by people that have had a device for a day a bit useless hence this review comes after 3 months with the device.

A bit about me

I also find reviews a bit useless unless you know what the reviewer needs from a device. We are not all the same and therefore need different things from a device. I don't need this device for work, but I do take it to work every day to use at lunch. As an app developer I needed something that I could use Visual Studio on, but I also wanted something that would function as a tablet on my sofa at home. My other devices are an iPad 3, iMac and Sony Vaio.

Onto the Pro

In the same way that the Xbox One has its name because it is the one device you need connected to your TV (at least according to Microsoft it is), the Surface Pro 2 could be called the Surface One, because it is the One PC you need. It truly is a tablet and laptop in one package. I write code on this thing almost every day and then do everything I would do on my iPad like email, games and web. Xbox Music on a tablet is also a dream to use and the fact that you can stream any song for free has made it a much better solution than my iPad.

When I got the Pro out of its box, my first thought was wow this things heavy! I was thinking of it as a tablet. When I gave it to my parents to hold, there reaction was wow this things light! They were thinking of it as a laptop. Depending on your perspective this is exactly what the weight is like. As a buyer what you need to consider what is important and what is too heavy. For me I know that compared to the new iPad this thing is miles away, but its not too heavy for a tablet. My Sony Vaio on the other hand as a laptop that I wanted to take to work, was too heavy. It required taking a bigger bag and its power supply due to the awful battery life. So after 3 months, speaking as someone who wanted one device, this thing is seriously light!

Battery life is the next consideration and let's just say, its got enough.

But what about the Keyboard

Surface is known for it's keyboard which has become one of it's biggest selling point, but also it's most popular criticisms along the lines of not being a great tablet if you need a keyboard to use it.

The keyboard is an optional accessory, to use Windows 8 you don't need it. When I sit on my sofa I don't use the keyboard, I actually pull it off. The on screen keyboard is a dream to use and I can't really fault it. But if you have a Surface Pro you're almost definitely going to want the keyboard accessory to get the most out of the device.

Despite having a Pro 2, I opted for an original Touch Cover. This was firstly because it was cheaper and secondly because I wanted a colour (did I mention my Vaio is bright orange). The Touch Cover 2 keyboard only came in black and although the Type Cover 2 has colours I really wanted to go for touch over type.

Typing on the Touch Cover can be an odd experience that will largely be dependant on how often you use it and how well you can type. As you type you can get a feeling that your making mistakes, even when you aren't. Then on occasion you will type a letter and nothing will appear, this leads you to start typing harder to ensure your getting the key presses. In reality you probably missed the key or keyboard completely. Key combinations can be another issue as the idea of holding down ctrl when nothing actually moves can be a little weird.

How well the Touch Cover keyboard works for you I think would largely be down to what you use it for. This article for instance has been fine. I'm doing constant typing and as such my fingers are learning the keyboard. Writing code on the other hand where it's a combination of autocompleted words, symbols, keyboard shortcuts and moving around files a lot can be a bit harder.

Was the Kickstand a good idea

Simple answer yes.

Would I recommend it?

It really depends what you want it for;

If your mainly after a device for typical laptop usage and aren't really interested in tablet usage, don't buy this device. The kickstand is great but it isn't as good as a laptop.

Equally if you mainly want a tablet and don't have much use aside from that don't buy the Pro version. The regular has some merits or an iPad may still be the better option.

If you want to use some classic Windows software such as real games (not that tablet games aren't real but you get what I mean) then get this device if you like the form factor.

If you want a tablet for work, get this device. It will be far more usable than any other tablet on the basis that it can do everything.

If you just want one device for all scenarios then this is also the one to get. It works that way for me, and if I ever did want it for work as well getting it's dock would make it perfect at that job to.

Talk on climate change is something that you cant have missed. This years winter is further evidence that irrespective on debate about the cause something is happening. Many of us now use energy saving bulbs, by appliances with high energy ratings and ensure our homes are sufficiently insulated all to cut down on our energy consumption and the effect it has on the world.

But as developers what about the code that we produce? Do you ever consider how much pollution is caused by the energy required to deliver web pages to users or for an app to function, and what could be done to minimise that pollution.

Ironically many of the things that we can do will ultimately also make an improvement to our users (obviously throwing more servers at a performance issue isn't going to reduce power consumption so their are exceptions).

Here are some examples:

Reducing the number of web requests

Quite simply the less requests a browser needs to make for files the less power it uses to do so. The benefit fir the user is that a browser will generally only make 7 simultaneous requests, so its also faster. We can easily do this by:

• Bundling CSS and JavaScript files
• Using image sprites rather than multiple images
• Ensuring caching is set properly so that files aren't repeatedly being requested when the browser already has a local version

Reducing the amount of data that we send

If we don't send as many bytes then its going to require less packets to send it, which will ultimately require less power to send them. It will also take the user less time to receive them.

• Optimise images to a sensible size. There's no point sending an image 10 times the resolution that's going to be viewed. There's also no point in using images in a format with a larger file size when it looks the same
• Minify CSS and JavaScript files to make them as small as possible
• Don't include CSS and JavaScript that isn't being used. How much of that jQuery UI framework are you actually using. Use the tools around to only include the bits you need
• Write APIs that only include the data that is needed, or give the consumer parameters to choose what fields they have. If your calling an API only get the data you need
• Use JSON services over XML, they have less mark-up

Think about what your code is doing

Lastly just think about what your code is doing:

• Are you making multiple calls to a database for the same data
• Are you posting a list to a server to sort it when the client could instead
• Are you re-loading an entire page just to sort a list
• How many objects are you needlessly creating on the server
• Are you appending string objects when you should be using a Stringbuilder

All these things will ultimately improve the performance of your code as well as reducing power consumption. You may be in a position when you haven't done any of this because performance isn't an issue, but power consumption is. The savings you make may be tiny, but tiny changes made by thousands of people leading to the power used by millions of people can have a profound effect.

Also turn your computer and monitor off when you go home!

Having a good UI is possibly one of the most important aspects of any development. It doesn't matter how perfectly the code executes, if the thing looks awful people won't use it. But it is an area that a lot of developers struggle with.

There have always been things like website skins that you can buy, but I've never been a huge fan of these. It's always seemed odd that you can use an open source CMS for free that has had hundreds of man hours put into it, but a decent skin would cost you £100, and even then would still need a lot of work doing on it.

Thankfully there are some free resources that not only help with the css and making a site responsive, but they also include some fairly decent fonts and layouts.

Bootstrap

Bootstrap is possibly the most popular css framework for building sites with right now. Even Microsoft have adopted it into all the templates that ship with Visual Studio 2013.

One of the main things Bootstrap gives you is a standard set of css classes for doing things like grids and responsive layouts. When people start using a common set of classes to achieve the same thing, things get a lot more compatible and you can already see that starting to happen with Bootstrap.

Bootstraps grid system works on having the illusion that your page is divided up into 12 columns. You then have a set of classes to assign to a div that contain a number, that number is how many columns the div should span over. A bit like a colspan on a table.

These grids are responsive though so as your page shrinks down to a tablet and mobile size it will automatically recognise that the columns won't fit horizontally and start rearranging them underneath each other.

As a starting point Bootstrap also has some templates of common layouts to get you started.

Bootstrap also has default classes for forms, form fields, headings and lists that will give your site an initial face lift.

Foundation

Foundation in many ways is very similar to Bootstrap. It also has a grid system for layouts and also helps with making a site responsive. There are also default styles for headings, lists and forms but they have also taken things a step further and started to encroach on jQuery UI's territory with things like tabs and dialog windows.

I haven't heard of as much industry support but there site is full of documentation and videos on how to use the framework.

Pure

Another CSS framework with yet another grid system. Pure appears to be much simpler than the first two and offers many of the same features. Their site has some good templates that in some ways cover more scenarios that Bootstraps. Personally out of the three I would go with Bootstrap as it appears to have a much higher adoption.

Normalize

If the CSS frameworks seem a little overkill for what you're after have a look at Normalize. The concept is simple, by including this CSS file in your site as the first CSS file it will overwrite all the default browser styles to create consistency and something that looks a little nicer.

There's been many incidents where I've seen CSS produced that includes a style for every single html element try overcome the differences on browsers, which is a good idea (this is basically what normalize does except someone's written it for you), but the styles have all been set to the same thing which is generally margin:0, padding:0. On some elements this is fine, on lists though, not so much.

Another option I've seen is to define a style on *.* which is equally as bad.

Fit Text

Like it or not people are accessing sites from all kinds of devices these days with all kinds of screen sizes. If your site doesn't scale then you're going to lose visitors. One issue you will ultimately face at some point is font sizes. These can easily be changed using media queries but another option is to use FitText.

FitText is a really simple bit of JavaScript that will scale your text to fit its containing element. You do have to call a function for each element you want to scale, and it does only work on the width rather than taking the height into account. But it is very cool. Just make sure you have a look at the code because it's so small this isn't something you will want in a separate JS file.