Using Visual Studio with Git Hub

This is one of those great examples of writing a blog post to yourself to remind you how to do something.

If your using Visual Studio 2012 then to add Git support you will need the Visual Studio Tools for Git plugin created by Microsoft’s TFS Power Tools Team (http://visualstudiogallery.msdn.microsoft.com/abafc7d6-dcaa-40f4-8a5e-d6724bdb980c), if your using a later version of Visual Studio then it’s already built in.

If you’re thinking in of using Git Hub as your source control provider then the most basic thing you’re going to need to know is how do you get the Git plugin to link up to GitHub. Here’s a couple of different methods;

Creating a Project in Git Hub

Click New Repository. Enter a new, Select Public or Private and click Create new Repository.

A new repository will be created in Git Hub

Clone the Project in Visual Studio

Now the project has been created in Git Hub you will need to clone it to your machine so that you can start adding files and sync then back.

Open a new instance of Visual Studio and do the following:

  1. Open the Team Explorer window
  2. Click the connect button
  3. In the list of Local Git Repositories click clone
  4. In the URL box enter the HTTP URL from Git Hub
  5. The second box should auto populate with a location on your hard disk
  6. Click Clone

Creating a Repository on Git Hub using the Git Hub app

Rather than creating the Git Hub repo through the GitHub website you can use their app. Once you’ve got the app installed and logged in do the following:

  1. Select the GitHub account you want to add the repo to on the left
  2. Click Create button at the top
  3. Enter a name and click create
  4. The repository will be created in GitHub and automatically sync with the folder on your machine

Adding an existing Repository to Visual Studio

If you already have a repository cloned on your machine but it’s not showing in Team Explorer you can add it by clicking on Add

  1. Click the Connect button to view the list of local repositories
  2. Click add an enter the path to the repository on your hard drive
  3. Click Add
Advertisements

What’s your source control strategy?

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.

3 Months with a Surface Pro 2

Surface Pro 2

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.

 
Surface Keyboard

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.

surface2pro-kickstand

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.

How Green is you code?

Climate-change

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!