brendan forster

Should I make this object a singleton?

shift.key@gmail.com (Brendan Forster) — Mon, 20 May 2013 00:30:00 +0000

Note: This is just a first pass on the post, as I need to touch on various tools I've used in the past to identify these constraints. But let's start with the concepts.

Someone asked me a question yesterday along the lines of, well, this:

@nickhodgemsft Roger, cheers @shiftkey thoughts? Will it be better to create a life long Crypto obj rather than this twitter.com/HDizzle84/stat…
— HDizzle (@HDizzle84) May 19, 2013

Singletons? My first instinct was to reach for the hose and dampen such discussion down immediately before someone got hurt.

But no, that's not right. I need to explain myself.

So I wanted to put together a simple guide on how to determine when the Singleton pattern is a suitable use case - yes, it gets a bad reputation due to misuse, but there are some scenarios where it does add value (and is often necessary).

How expensive is it to create?

Imagine you have a database connection - say SqlConnection - and you create an instance of it to connect to a database?

TODO: show windbg object dump of a SqlConnection object

Inside this SqlConnection object you should see a bunch of underlying resources - these are the components which make the magic happen when you perform a "SELECT * FROM Table" in your application.

Many of the objects you create in your application are probably simpler than this - classes to hold data, for example - but once you start interacting with the underlying platform and identify various bottlenecks in your applications understanding what resources are hiding where is invaluable knowledge.

The other thing to keep in mind with objects is what they encapsulate. If your classes interacts with the network, storage or attached devices, for example, you are likely to face specific rules with how you use access these resources.

An example: if you're ever making concurrent web requests to a specific domain, .NET will actually throttle you to two concurrent requests. You can change this if you know where to look but the defaults are designed to be "good enough" for most scenarios.

Another example: database connection pools - a finite number of connections which are managed and reused over the lifetime of an application - instead of arbitrarily creating, using, and then destroying connections each time we need them.

What about my memory footprint?

So assuming the above constraint isn't affecting your classes, you might be able to get away with creating objects whenever necessary.

But what if you're making a mobile app? Memory becomes a significant constraint on any mobile applications - and the more moving parts you have in a mobile application, the more you need to optimise to reduce the impact of those moving parts.

I don't need to worry about that, my stack has generational garbage collection (GC).

But that's not actually a solution - more like a crutch. GC isn't a free lunch - it's overhead that you're now invoking periodically (technically GC will run whenever it needs to, which is often at the worst possible time due to memory pressure) because you were lazy with how you structured your application.

TODO: demonstrate .NET performance counters around GC, with a sample that does stupid things

What about multi-threaded code?

This is the hardest part to discuss, because multi-threaded code is hard. Really hard.

If your object is immutable (that is, you can call the same function on an object as many times as possible until the end of time and you'll always get the same result) then it might be possible for it to be used as a singleton object.

TODO: discuss the simplest gotcha - two threads entering a function at the same time

TODO: discuss where basic locking will cause you different sorts of headaches

TODO: what would Ayende do?

But I just want to use it as a global object

Please don't. This introduces unnecessary coupling into your application, at the value of saving a few keystrokes.

TODO: explain the god object pattern and why it is bad

TODO: outline where this is utterly unavoidable and you need to suck it up and just God Object that sucker

What's the damn answer, Brendan?

Ok, so if you've read this far - I thank you.

So when should you consider wrapping an object in the singleton pattern?

Firstly, beware of how multi-threading actually works - no, the TPL is cheating.
If it's expensive to create, consider it.
If it's touching underlying system resources, consider it.
If you need to optimise for memory usage, consider it.

Feedback is Welcome

Did I miss something? Get something wrong?

Yet Another "Add LESS to your ASP.NET MVC Project" Post

shift.key@gmail.com (Brendan Forster) — Sun, 12 May 2013 13:00:00 +0000

You've probably done this too

If you kicked off a new ASP.NET webapp recently, somewhere after File -> New Project you probably got excited about using a CSS preprocessor like LESS or SASS because:

nobody writes CSS directly anymore
it's supposed to make your life easier
something with unicorns and rainbows

This post isn't about that. This is about the little quirks I had to jump through to get a usable development environment for writing LESS code.

NOTE: This uses the bundling features in MVC4. If you're using a version of MVC which is older than that, go upgrade. Bundling is so nice.

Step 1 - The Installer-ation

To NuGet!

PM> Install-Package dotLess

Go run that in a new project. I'll wait.

Done? Great, so go write a little LESS code (I've just called this file sample.less for the purposes of this demo):

@color: #4D926F;

.site-title a {
  color: @color;
}
h3 {
  color: @color;
}

And then include it in your Razor layout...

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>@ViewBag.Title - My ASP.NET MVC Application</title>
        <link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
        <meta name="viewport" content="width=device-width" />
        @Styles.Render("~/Content/less")
        @Scripts.Render("~/bundles/modernizr")
    </head>
    <!--  and more stuff here obvs -->

But you're application doesn't know about how it can transform LESS code into CSS. That's where bundles come in.

Step 2 - Dude, where's my bundle?

Bundles are an easy way to merge and minify resources in your application (such as JavaScript files and CSS stylesheets). In addition to being a lovely convenience, it's actually a great way to improve site performance (fewer HTTP requests, reducing size of response payload).

So go back to NuGet and use this:

PM> Install-Package System.Web.Optimization.Less

And add your bundle to the appropriate location within BundleConfig.cs

public class BundleConfig
{
    public static void RegisterBundles(BundleCollection bundles)
    {
        // NOTE: existing bundles are here 

        // add this line
      bundles.Add(new LessBundle("~/Content/less").Include("~/Content/*.less"));
    }
}

Bundles support a limited subset of wildcard syntax, but you can include multiple folders within a bundle.

So this LessBundle gives you the ability to combine and minify files when running the application in <compilation debug="false" /> mode, and it takes care of transforming LESS code into CSS - without needing to update the layout everytime you add a new file to the project.

Editor's note: I wasn't aware of this package on the last runthrough - instead I found this LessBundle code in a gist from @benfosterdev which looks very similar to the source for that package, so I'll give him kudos for it.

Step 3 - But wait, there's more!

But what about when testing locally? Well, bundles are rather lazy in development mode:

no minification
no bundling
in fact the files just appear as LESS resources to the browser

So you still need to tell your application how it can serve LESS files to the browser, independent all this bundling work.

dotLess will apply transforms to your web.config when you install it through NuGet to provide handlers which can process a specific LESS file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="dotless" type="dotless.Core.configuration.DotlessConfigurationSectionHandler, dotless.Core" />
  </configSections>
  <!-- these probably do something useful -->
  <dotless minifyCss="false" cache="true" web="false" />
  <system.webServer>
    <handlers>
      <!-- for IIS7+ -->
      <add name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
    </handlers>
  </system.webServer>
  <system.web>
    <httpHandlers>
      <!-- for IIS6 -->
      <add path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
    </httpHandlers>
  </system.web>
</configuration>

Editor's Note: when I last ran through these steps I didn't get these config transforms applied on install. I was really looking forward to a rant here because I'd gone through the hard yards to add these handlers by hand - but of course it worked this time.

So these handlers allow you to compile an individual LESS file and see the results in the browser.

Oh, and don't forget to remove the handlers in your config transforms when you go to production (this is an example of the Web.Release.config transforms file).

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.web>
    <compilation xdt:Transform="RemoveAttributes(debug)" />
    <httpHandlers>
      <add xdt:Transform="Remove" xdt:Locator="Match(type)" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler, dotless.Core" />
    </httpHandlers>
  </system.web>
  <system.webServer>
    <handlers>
      <add xdt:Transform="Remove" xdt:Locator="Match(name)" name="dotless" path="*.less" verb="GET" type="dotless.Core.LessCssHttpHandler,dotless.Core" resourceType="File" preCondition="" />
    </handlers>
  </system.webServer>
</configuration>

Custom server headers - bad for your health?

shift.key@gmail.com (Brendan Forster) — Sat, 04 May 2013 06:00:00 +0000

I just finished another project with a customer which involved a pentest (penetration testing) review for their upcoming launch. And as usual, this involves hiding a bunch of headers that IIS and ASP.NET serve up on each response.

In particuar:

Server (from IIS)
X-Powered-By (from IIS)
X-AspNet-Version (from ASP.NET)
X-AspNetMvc-Version (from ASP.NET MVC)

Why? Because sending these headers in your response exposes information about your server to clients (including the bad guys). Troy Hunt explains it in more detail but our approaches differ slightly:

I've just focused on the ASP.NET stack
this approach doesn't require any changes to IIS
I don't care about IIS 6 (it shipped with Windows Server 2003, so that'll be 10 years soon!)

NuGet all the pain away

So I was going to write a NuGet package to solve this problem but I was then pointed to this package from David Duffett - Dinheiro.RemoveUnnecessaryHeaders. Thanks for saving me the time, David!

So go grab it from NuGet:

PM> Install-Package Dinheiro.RemoveUnnecessaryHeaders

You can do this by hand if you want - in fact, I'll explain the package behaviour here.

First, it applies a config transform to remove the X-Powered-By and X-AspNet-Version headers:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <system.web>
    <httpRuntime enableVersionHeader="false" />
  </system.web>
  <system.webServer>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
  </system.webServer>
</configuration>

Next, we use WebActivator to hook into the PreApplicationStart event to run some custom behaviour:

[assembly: WebActivator.PreApplicationStartMethod(typeof(MyWebApplication.App_Start.RemoveUnnecessaryHeaders), "Start")]

This method takes care of two things. The first is disabling the X-AspNetMvc-Version header, and then registering a module to remove the Server header.

public static class RemoveUnnecessaryHeaders
{
    public static void Start()
    {
        DynamicModuleUtility.RegisterModule(typeof(RemoveUnnecessaryHeadersModule));
        MvcHandler.DisableMvcResponseHeader = true;
    }
}

And there's an important note about this code - it's only supported for IIS7+. Just a heads up.

public class RemoveUnnecessaryHeadersModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        // This only works if running in IIS7+ Integrated Pipeline mode
        if (!HttpRuntime.UsingIntegratedPipeline) return;

        context.PreSendRequestHeaders += (sender, e) =>
        {
            var app = sender as HttpApplication;
            if (app != null && app.Context != null)
            {
                app.Context.Response.Headers.Remove("Server");
            }
        };
    }

    public void Dispose() { }
}

That PreSendRequestHeaders event is the last opportunity ASP.NET gets to intercept the response (including reading headers set by IIS) before it gets sent to the client.

Defaults are good - except when they're not

Just about all of the teams I've worked with have had this requirement as part of their go-live checklist (or raised by a security review) which made me think...

Why aren't these headers disabled by default?

And why does it require changes in so many different places in IIS and ASP.NET?

A footnote on X- Headers

If this is the first you are reading about this issue, HTTP headers which are prefixed by X- are custom headers which are not part of the HTTP spec. It allows servers, frameworks and applications to include custom metadata in HTTP requests and responses.

My favourite example of this is Twitter's Rate Limiting API, which sends custom headers with each API call that an application makes:

X-RateLimit-Limit: 350
X-RateLimit-Remaining: 350
X-RateLimit-Reset: 1277485629

As a consumer of Twitter's API, my application would need to look for these headers and understand the values.

Recently Cristian pointed me at RFC 6648 which, as it clearly states, is about:

"Deprecating the "X-" Prefix and Similar Constructs in Application Protocols"

It's very RFC-y in it's wording - and it's also only a year old which is really young in RFC time - but it's definitely something to keep in mind when designing custom headers for your application to serve or handle in the future.

Internet Sabbatical - An Experiment

shift.key@gmail.com (Brendan Forster) — Mon, 26 Nov 2012 12:00:00 +0000

As this year comes to a close (a few more things to do yet) I wanted to try something different over the holiday season - an internet sabbatical.

A What?

From 21 December (when I jump on a plane for the holidays) to 6 January (when I jump on a plane to come back for work) I plan to "go to ground" and avoid the internet.

Why?

I am burned out - plain and simple.

I would love to just "power on through" like it wasn't a problem but I've been doing that for the past few weeks already and its not changing much.

Plus I intend to spend a bunch of time here:

Doing stuff like this:

And it has terrible phone reception anyway (yay!)

The Ground Rules

Here's the low-down:

No Internet Access
No Twitter/Facebook
No checking emails
No computers or things that will let me code

But I won't go completely off the reservation:

Phone - to keep in contact with friends and family, but that's it
Xbox - I'm keen to play some Assassin's Creed III (or other games) so that's included

And given I won't have technology to report on my progress (pen and paper perhaps?), you'll just have to wait and see how I go.

Happy Holidays

If you need to get in touch with me over the holidays, there are "old-school" methods (see above) but otherwise I wish you all a happy and safe holiday season and we'll see you all in 2013!

What's my secret? An unoffical unconfirmed guide

shift.key@gmail.com (Brendan Forster) — Sun, 23 Sep 2012 12:30:00 +0000

Introduction

After surviving TechEd Australia - as well as hitting some important deadlines for a client - I was looking forward to getting back into various side-projects again now that things are coming back to (realtively) normal.

I fired off an email looking for tips from my colleagues what they do to help get creative, and one of the replies I got back was this:

I find the third question silly coming from you. You are one of the the most productive and creative people I know and I wish I knew your secret to it.

Sorry mate; but you don't get to be an MVP, a main member on Code52, talk at conferences and so on and then ask others how they are productive and creative :p

Share your secret already ;-)

So I owe someone a blog post to explain myself.

Brendan's Unofficial Unconfirmed Guide To Being Awesome

First up, some warnings:

This is me speaking from my experiences only.
I will often suggest things which I do not do. Yes, that makes me appear hypocritical. No, it is not intended.
Please consult with a medical professional before taking any of the below advice.
This is all subject to change.

Without further ado, let's dive in...

Make time for it

While I appreciate that there are many developers who are happy "dark matter" developers, I've always seen a correlation between awesome developers and developers who will spend time improving themselves outside of work hours.

Don't feel bad if you're not someone who obsesses over code outside of work. But don't feel that it's out of reach.

Not sure where to start? Start small. Set aside a half hour once a week.

Can't find time in the evenings? Why not try and get up earlier instead?

Note: As many people who know me will testify, I am not a morning person. I'll generally find a couple of evenings each week to hack on various things late into the night - it's an old habit I still haven't shaken from my university days - as that's when things are quieter and I can focus better on things. Your milage will vary.

Set yourself goals (even small ones)

To ensure you're making the best of youur spare time, set some goals up front to ensure you work towards something tangible and useful. Starting small with your goals will help.

To illustrate this, here's a few goals which I would like to work on over the coming weeks/months:

learn about Neo4J and graph database concepts by building a proof-of-concept accounting webapp
learn about DirectX and de-rust on my C++ skills by building a Windows 8 app

See how they can be considered daunting goals?

Let's break that first item down a bit:

Read up on concepts behind graph databases
Getting Neo4J setup on my local machine
Experimenting with working with Neo4J and the REST API
Getting a simple webapp setup to interact with Neo4J (Ruby/Python?)
Sketching out the app idea
Build out a small piece to demonstrate the app

You get the picture - take a big piece of work and break it down into manageable chunks.

By tackling something in chunks you also get a number of other benefits:

be able to demonstrate learning earlier on (e.g. interacting with an API first before building the app)
get feedback without investing significant amounts of time (and put it aside if its not fun)
be able to work on multiple goals at the same thing (rather than procrastinating because you're stumped on something)

Of course it looks like Dave Tchepak beat me to the punch on this with a more detailed post earlier in the year, so I'll defer to him on this.

Don't just read and watch

It's easy to sit down and read some blogs on a topic and think to yourself "Well that was easy!" It's easy to watch some screencasts on a subject and think "I know X now, great!"

I want to challenge you to go beyond the passive learning and build something based on what you've learned. The size of it doesn't really matter, but I've always found it important to take the things I've learned and apply them to the real world.

This helps in several ways:

demonstrating that I was paying attention
leaving the hand-holding of the blog posts/screencasts and work without that safety net
reinforcing the learning while it is fresh in my mind

I love blog posts and screencasts, but these days I try and balancing consuming posts/screencasts and creating things.

Don't be afraid to fail

It can be daunting when faced with something completely new and unfamiliar. With the amazing pace that technology and software moves at these days, it's impossible to keep up with everything. And that's OK.

Focus on what you could use at work.

Focus on what you're interested in.

Focus on what might make you a better developer.

Dive in, try something, don't be afraid to make a mistake. Because you will. And that's OK.

Just make sure you learn from your mistakes, or that you make different mistakes.

Here's a couple of little experiments I've worked on in the past that haven't come to fruition (yet?):

bringing WebRat syntax tests to automating testing of WPF apps
weaving async/await code to trace when background tasks fail silently
backporting WinRT APIs to .NET so that libraries and apps can transition to the new APIs more easily

I could weep for things that didn't eventuate, but life's too short.

Share all the things!

And how will we know how awesome you are if you don't tell us?

After parking my blog ages ago (mostly because I was never really "happy" with it and I'd compulsively tweak things), I've started to come around to Hanselman's words: "Every developer should have a blog". I'm a habitual Twitter user and thoroughly enjoy the medium for what it is, and I know that I spend time which I should be spending on blogging.

To compensate for this, I publish a lot of my stuff on GitHub. Yeah, its lazy. But its out there at least. Even this blog is public - and its just a static site generated using Jekyll and hosted on Heroku.

Don't be afraid to write - for example, my last post on git aliases got several "Hey you missed X" comments on it because I wrote it in a rush and missed a couple of details with the end script.

If people only blogged perfect posts I'd never end up blogging anything.

Feedback

I'm running out of words and I bet you guys are getting tired of me over-sharing, so I'll tie this one off here. What have I missed? What did I say wrong? Let me know in the comments.

Why You Should Care About Git Alias

shift.key@gmail.com (Brendan Forster) — Sun, 16 Sep 2012 12:30:00 +0000

Why do I need alias?

One of my favourite bits of "feedback" from Mercurial users is that "you don't need to type out the full command with hg - git is dumb" or something like that. While they're not totally incorrect here, they are comparing the out of the box experiences between git and hg.

Mercurial will recognise shorthand for commands when you type enough characters to distingush the right command, like:

hg com -> hg commit
hg sta -> hg status
hg sum -> hg summary
hg ci -> hg commit

That's right, hg does aliases too...

Git however will scream at you when you mistype a command. And you will swear in return (either at yourself or at git).

So to save yourself from screaming in the future, you can customise git to recognise custom commands. It will save you so much time.

Aliases are stored per-user in the .gitconfig file - or in the .git/config file for a repository. All the below scripts will install in the global config file - but you can drop the --global parameter if you don't want that behaviour.

Adding shorthand as aliases

Here's some shorthand commands for the common git tasks:

# git st
git config --global alias.st "status"   
# git co 
git config --global alias.co "checkout" 
# git ci
git config --global alias.ci "commit"   
# git br
git config --global alias.br "branch"   
# git df
git config --global alias.df "diff"     
# git lp
git config --global alias.lp "log -p"

These are some of the common examples from the here.

Customising existing commands

My favourite example of this is a prettier output from git log - so you can see at a glance the activity on the branch you are currently working on:

# git lg
git config --global alias.lg "log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit --date=relative"

Of course, someone far smarter than me wrote this one...

A few simpler ones:

# git com -> checkout master
git config --global alias.com "checkout master"

# git fe -> fetch latest changes
git config --global alias.fe "fetch origin"

# git hr -> hard reset state of master
git config --global alias.hr "reset origin/master --hard"

# git me -> get my user name
git config --global alias.me "config user.name"

And you can even embed scripts into an alias. Here's a couple of simple scripts to see what commits have been added for today (by me any by others):

# git today
git config --global alias.today "!git all --since='12am' --committer=\"`git me`\""

# git today-all
git config --global alias.today-all "!git all --since='12am'"

# git bn -> get current branch name
git config --global alias.bn "!git for-each-ref --format='%(refname:short)' `git symbolic-ref HEAD`"

Do you see where we're going with this? :)

Mashing commands together

Remember how in my last post I mentioned a rather verbose workflow for merging in changes?

Well let's take it away with one simple command: sync

# git sync
git config --global alias.sync "!git update && git co master && git pull && git co @{-1}"

But that's rather basic - it doesn't actually rebase my branch that I'm on.

Let's do a slightly different command: resync

# git resync -> sync repository and rebase current branch    
git config --global alias.resync "!sh -c 'BRANCH_NAME=$(git bn) && git com && git fe && git hr && git rebase master $BRANCH_NAME'"

Note how this one uses aliases defined earlier in the post for readability? Yeah, it's rad.

I'm lazy, give me the gist of it (lol pun)

I'm checking some other git repos I have lying around to ensure I have all my aliases in one spot, but in the meantime open your ~/.gitconfig file (check C:\Users\{username}\ if you're on Windows) and paste these values under the [alias] node. If the [alias] node doesn't exist, create it.

Got a cool alias you want to share? Fork the gist above!

My Git Habits

shift.key@gmail.com (Brendan Forster) — Sun, 16 Sep 2012 06:30:00 +0000

First up, a disclaimer: This is just one person's opinion and should be treated as such.

If you workflow is similar, that's great. If you workflow is radically different, that's great too. With things like git its very easy to have different workflows, so I'll just be speaking from my experiences here.

Introduction

Generally speaking, my git flow is based off the documentation for contributors to the NancyFx project. When working on features, this is my high-level flow:

Create a local branch for the feature
Work on your feature and get it reviewed -- you do code reviews, right?
Merge the changes into master
Push the changes up to the remote repository

How does that look from the comamnd line?

git checkout -b ReallyCoolFeature master
... stuff gets done ...
git add -u . -- add all removes and modifies to the staging area
git add . -- add new files to the staging area
git commit -m "#1234 implemented" -- associating commits with work items is awesomely helpful
git checkout master
git pull origin/master
git merge ReallyCoolFeature
git push origin master

Note: Yeah, I like to be explicit with my remotes and branch names in these commands. Haters gonna hate.

But that's all fairly straight-forward and not really leveraging the new states of mind that git makes possible.

Rebase all the things

Where git truly comes into its own is with rebasing. For those who aren't familiar with it, rebasing allows you to change the history of a branch. This is generally considered very bad™ to do with public repositories but when you use it only locally it gives you so much control over everything.

For example, have you ever:

used a branch for multiple, disparate tasks that you wish you could reorder for readability?
accidentally forgot to save a file and had to spread a task over multiple commits as a result?
wanted to update an old branch to the latest changes and avoid merge conflicts?
wanted to split out a branch into multiple branches and process them separately?

If you consider a branch to be a chain of commits - with a parent commit representing the creation point of the branch - then rebasing is the operation to:

change the creation point of a branch
change the order of the commits in a branch
change the commits in a branch - squash commits together
remove commits from a branch

At this point you are probably thinking "Oh man, I'm going to nuke my branch and lose all my work" but if you look more closely at what the rebase does, you'll find that its a lot safer than you think.

A rebase operation will

set the repository to the new creation point
create a temporary branch just for this rebase operation
apply the commits one by one to ensure they apply cleanly
update the pointers for the branch and remove the temporary branch
set the repository to the last commit of the new branch

When I say "ensure the commits apply cleanly" here, I indicate that git will ensure that additions and subtractions to each file make sense. If they don't (for example, the file has changed significantly enough), it will pause and ask the user to manually confirm the commit.

At any point during a rebase that requires user input, you can abort and git will roll back to the state it was in before the rebase operation started.

Speak English, Brendan!

So I got side-tracked a bit just then. Apologies.

So what do I use rebasing for?

reordering - if I do a bit of code cleanup during my work, that remains separate from the current task and can be put before/after when reviewing code
squashing - generally speaking, your commits should be granular enough to be easy to follow. But sometimes things go too far and you want to bring related commits together (e.g. missed deleting a file from the previous commit)
splitting - if you've got a complex branch you could split it up into multiple branches and integrate them in gradually.

All of this is possible by using interactive rebase - before it kicks off the operation, it displays the commits available and allows you to specify the operations to perform.

Note: There's two minor differences when you squash commits together. One operation, fixup, is intended to merge a commit without including the commit message. The other, squash, will bring the commit message across and allow you to edit the commit message after the squash.

Merging is overrated anyway

Yes, that might be a controversial thing to say at this point. Merges are considered important to indicate when two branches have been brought together. But I submit to you, the jury of the internet - do we really need it? I'm not advocating abandoning merges at all - they have a purpose, which is to indicate changes additional to the branch being merged in.

If I can rebase a branch on top of the current master, I've just avoided the need for a merge commit completely (it becomes a fast-forward merge and the pointers are moved forward). I can then push and get on with the next task.

I guess this comes back to how you use branches. Git works excellently when you create a branch for a task, integrate the code into master, and delete the branch once its reached the end of its useful life.

Not everyone can work that way (that might be a rant for another day), but I see this a discipline issue rather than a pro/con of the tool itself.

My Opinionated Git Flow

So with a slight tweak to step 3, my flow becomes:

Create a local branch for the feature
Work on your feature and get it reviewed -- you do code reviews, right?
Rebase the branch on master
Push the changes up to the remote repository

How does that look from the comamnd line?

git checkout -b ReallyCoolFeature master
... stuff gets done ...
git add -u . -- add all removes and modifies to the staging area
git add . -- add new files to the staging area
git commit -m "#1234 implemented" -- associating commits with work items is awesomely helpful
git checkout master
git pull origin/master master
git rebase master ReallyCoolFeature
git checkout master
git merge ReallyCoolFeature --ff-only
git push origin master

Combine that with some hot git alias action (this is getting fairly long as-is), you can strip away much of those commands into a simple "sync" step which you run against the branch you are working on.

What's next?

I could go on about using reset and cherry-pick commands and head further down the git rabbit hole, but I think the next posts should cover these things:

git alias - seriously, this is like crack for scripters
a general rant about discipline when managing commits - git has corrupted my brain, and I've found myself applying concepts to situations where I have used other VCSes (even TFS, not using git-tfs or tf-git)

Sharing my personal backlog with the world

shift.key@gmail.com (Brendan Forster) — Mon, 16 Jul 2012 10:30:00 +0000

Ever since I got back from holidays a few weeks ago I've been in a bit of a rut trying to tackle the backlog of stuff I've been meaning to do (projects half-done, contributions I've promised other people, things I've been meaning to blog about).

The Experiment

This experiment comes down to three simple things:

maintain a list of tasks which need to be done (ordered by priority)
focus on one thing at a time
make it visible to the world to add some peer input to the situation

For the tool to make this happen, I've decided to use Trello. After using Trello for the Code52 projects in the past, I felt that it was the best fit between ease of administration and ease of viewing.

The board is hosted at https://trello.com/board/public-backlog/50039c94fe5e1f8037b9b583.

What can you do?

You should be able to leave a comment on any of the items currently there. What sort of comments would help? Things like:

"Can you explain this one?" (I've been too brief with a task which may be complex)
"Can you do this sooner?" (this is something you are interested in)
"Can I help out with this?" (this is something you might be able to help out with)

Caveats

This is something that I'll flesh out over the next few days and there may be some details missing.

There are some items on the list which are deliberately vague - I'll indicate which tasks are "teasers" at this point in time, but I've got no issues with you seeing where they sit in my priority queue.

And there are some things which I just can't plain talk about (but really need to do anyway) so I'll need to figure out a way to represent them properly. Not everything on my plate at the moment is OSS work :)

So I accidentally a web guy MVP

shift.key@gmail.com (Brendan Forster) — Sun, 08 Jul 2012 10:30:00 +0000

So I just had this little email land in my inbox last week.

Congratulations! We are pleased to present you with the 2012 Microsoft MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in ASP.NET/IIS technical communities during the past year.

After the chaos of first half of the year (which I still want to get back to, just trying to summon the energy again after a brief respite to head over to NDC this year) this caught me off-guard, but has been an honour to accept nonetheless.

I'll comment a bit further on the details once I've signed away my life and get an idea of what's involved, but given the ASP.NET dev stack (well, the good bits anyway ::smileyface::) is now on Codeplex I'm keen to spend some time digging into that and helping out wherever my powers might be of benefit.

There's also shiny things coming along in the upcoming release (I've hacked a bit on Web API, and Single Page Apps is on my radar but I haven't used in anger) which are on my never-ending TODO list.

Introducing code52

shift.key@gmail.com (Brendan Forster) — Tue, 03 Jan 2012 10:30:00 +0000

Back from a self-imposed internet break (taking a phone which doesn't do 3G coverage and going rural is a good way to do this) and Paul and Tobin couldn't wait to kick off our new collaborative project.

There's a bit more of a blurb on the website - its an idea we're still wrapping our heads around by using a bit of trial and error.

We're already hard at work on our first project and we'd love to see people drop into the Jabbr room and get involved. Amd pf course, there's a Twitter account too to follow.