Category Archives: Events


inetaWhat have I done recently? I’ve been focusing on regional and national speaking opportunities and community outreach. I taught Git in January in Vegas and in San Francisco in February, I compared Amazon and Azure in San Francisco in February, in March I’ll share What’s new in Visual Studio 2013 in Pasadena, and the highlight is I’m currently speaking at FluentConf. This has been an awesome opportunity to focus on bringing content to users where they are. I’m really glad to be able to share and learn together with you. Looking for slides for these talks? Grab the slides. Want me to speak at your user group or conference? Request me through INETA or drop me a line.

Git Training

QuigonheadshotWow, that was fun.  I had the pleasure of training 174 people (42 in-person, 132 virtually) for an 8-hour session on Git.  Thanks to GoDaddy for sponsoring the event.  It was incredibly fun to run with the audience from “How do I install it?” at the beginning of the day to “So that’s how you rebase” at the end.  And tribute to the attendee who pointed out the similarities between me and Quigon in the image to the left. Here’s some of the things we spoke about:
  • “Thinking in Git” is a presentation I love giving where our focus is taking the knowledge you’ve gained in TFS or SVN and transferring it into Git.
  • We speak of who uses Git.  Ultimately I love to reference the open-source web stack from Microsoft on CodePlex.  When you click download, you’re greeted not with a TFS link or even an SVN link; you’re asked to “clone or fork in git.”  If anyone needed a nudge that Git is the new normal, that sounds like it.
  • We speak of the beauty of distributed version control systems, overcoming the “subversion dilemma”: “do I commit now and inflict incomplete code on all of you or do I not commit and lose the benefit of source control.”  Thank you to Eric Link for the excellent metaphor.
  • We walk through installing all the Git Tools for Windows.  It was fun to reference the new kid on the block: SourceTree, a free Git GUI by the makers of JIRA.  (It still fascinates me that KDiff3’s installer pops up /behind/ Git Extension‘s installer.)  The cream of the crop is how Git puts a bash shell on my Windows box.  I’ve mis-used that countless times for running shell scripts on Windows.
  • We walk through the staging area, commit, checkout, branching, merging, push, and pull, and reference the SVN and TFS similarities.  All attendees can now recite by heart the great long command to rule them all:

git log –oneline –graph –decorate

  • After lunch, we walked through “Git, GitHub, and GitFlow”, a great presentation where we review what Git gave us “in the box,” and what new things we can do should we choose to also add GitHub and/or GitFlow.
  • A trip through git aliases eased some peoples fingers as they typed “git log –oneline –graph –decorate” for the 279th time.  :D
  • A great question was how to version database content, so I got to demo both SQL Source Control from Red Gate Software and the built-in Database Projects.  (spoiler alert: the workflow in SQL Source Control is far and away worth the cost of admission.  I’m sorry Database Projects, but the master copy is the database, not the text files.)  Though neither tool is great at dumping SSIS Packages to text files, normal database objects like tables, stored procedures, and views work just fine.
  • Other insightful questions led us on journeys of transferring repositories from TFS and SVN to GitHub Enterprise, or transferring from one Git host to another.
  • We got to experience a standard open-source contribution model as we all forked a repository I created for the purpose, cloned it to our machines, changed it in interesting ways, pushed, and created pull requests.  The hilarity ensued as we watched me demo merging interesting situations.
  • We talked a lot about how to reorder, refine, adjust, and route around commits using “git rebase” and “git cherry-pick”.  (That’s when our minds really started spinning.)
  • The final picture from Labyrinth referencing “initial git training” was priceless.
Ultimately, it was a day well spent for all.  Thank you to all who attended and made it a fantastic day.  Want me to do a training at your user group or wish to sponsor a corporate training for your company?  Drop me a line. Rob

SQL in the City London

I had a wonderful time attending SQL in the City London.  It’s really great to see the new versions of the tools and exchange new ideas with friends.  Towards full disclosure, I’ve been a Friend of Red Gate for as long as I can remember, and also spoke at SQL in the City last year in both Austin and Seattle.  This year was a new format: leading attendees through a focused journey of continuous integration and deployment together in one large room.  It worked well. There was also a small off-track room seating about 20 to 40 down a winding hallway, though with such a large attendee base, there was usually no room.  It did help us focus on the main event, but it did remove some of the free-flowing discussion that only a small group can bring. The opening discussion was pretty much a spot-on repeat of last year.  We did the deployment balloon game, and successfully deployed only one of our 5 or 8 groups of balloons.  It’s a wonderful object lesson, though having seen the example and corresponding slides last year, it didn’t really grab my attention.  My fellow attendees seemed to enjoy the presentation — a wonderful reserved optimism that speaks volumes of the glorious British culture.  Breaks between classes helped us absorb the material and yielded great discussions.  We also queued very well for afternoon tea.  There wasn’t much space in the venue to hold us when we weren’t sitting down, so the displays and conversation areas were loud and cramped, and most of us either spilled out of the building or back into our seats.  “A Day in the Life of a DBA” concluded the day, and seemed like it could’ve been a wonderful discussion.  Alas, I quickly zoned out as it turned into a gripe session about everything DBAs hate about developers, networks, management, users, life, and why getting woken up is not fun.  All else being equal, I wish I had fit in the smaller room. I’m really enjoying how the tools are maturing and coming together into a great suite, targeted nicely both towards on-premise use and cloud deployments, both tools to facilitate developers and tools to facilitate IT pros.  David Atkinson did a wonderful demo of continuous integration using the Team City plugin that drives SQL Compare, SQL Data Compare, SQL Docs, other tools, and in short order, database migrations.  Justin Caldicott and Grant Fritchey did a wonderful back-n-forth demo — from both developer’s and IT’s perspective — of the challenges of deployment and how Deployment Manager really saves the day. Deployment Manager is struggling because it’s one of the few Red Gate tools that requires you accept their paradigm rather than fitting into a niche inside your process.  (SQL Compare, SQL Data Compare, SQL Monitor, .NET Reflector, ANTS Profiler, and even to a lesser extent SQL Source Control all get plugged into an existing workflow with ease.  Deployment Manager really needs to own the deployment process.  This is especially difficult to swallow since the IT Pro’s bread and butter is to ensure deployment is seamless, painless, and exact.  Like any good DBA, they get very OCD about it.  Deployment Manager asks the business to “trust us, we’ll do the right thing.”  Automation is wonderful, but black boxes scare people.  Deployment Manager seeks to walk this fine line, and does a descent job, but it is a very hard sell.  Alas, I digress. I got tapped with only a few moments notice to lead a group discussion about Database Migrations — a topic I’m quite passionate about.  Of the 3 groups of 20-or-so, I chose the biggest challenge — the group that didn’t own any Red Gate tools.  We quickly got the standard gripe out of the way: the tools are expensive, and then we began exploring both the challenges of Database Migrations and the solutions that we were proposing.  (It was fun getting to use the royal “we” to discuss Red Gate for a few minutes.)  The methodology proposed seems very solid, and I’m really excited to see how they execute on this vision.  In a true continuous deployment system where the build server fully owns deploying all assets (web sites, command lines, services, GUI tools, and databases) the lynch pin to completely avoiding babysitting it is Database Migrations.  I’m really excited to see this product come to life.  The group seemed very receptive, and some said they’d give SQL Source Control a try.  (SQL Source Control is a great gateway drug into the Red Gate toolchest.) SQL in the City is a wonderful event, and I really enjoyed attending again this year.  I’d highly recommend the free day of training and insight into Red Gate tools, and wish only that there were more of them in cities closer to me.  Many thank yous to Annabel and her team who went above and beyond to make this even a wonderful success.  Well done.

Git, GitHub, and GitFlow at PhxJUG

It was my pleasure to present the follow-up to Thinking in Git, “Git, GitHub, and GitFlow” at the Phoenix Java Users’ Group last night.  It was a wonderful discussion.  We began by reviewing the basic methodology of Git, comparing it to SVN, and in general comparing distributed version control systems to client/server systems.  We then looked at the features and benefits of GitHub, an online Git repository and social coding community.  We then looked at GitFlow, a workflow for creating features and publishing versions.  You can download the slides here.

Backbone.JS presentation at Phoenix JavaScript Meetup

It’s my pleasure to present Backbone.JS at this evening’s Phoenix JavaScript Meetup.  Backbone is a great library for achieving separation of concerns in client-side code.  It is a great addition to your botique of client-side libraries, offering an a-la-carte, unopinionated framework for pub/sub eventing, declarative DOM event binding, one-way model binding, a great client REST mechanism for data persistence, and routers for “hash-bang” in-page view navigation.  You can get the slides and content here.  Most of the pages work without a server-side data store, so you can safely ignore the node content.  When you’re ready to fire up the full monty, run npm install in the code directory, then node server.js to launch the server, and connect with your favorite browser.  Happy coding!

Comparing version control systems: SVN, HG, and GIT

It was my pleasure to talk about version control systems: svn (subversion), hg (mercurial), and git at the NWVDNUG.  It was a great discussion about the value of DCVS (Distributed Version Control Systems) vs. Centralized Version Control Systems.  We also hit the main purposes of source control: (1) to facilitate collaboration among developers and (2) keep an audit history of the code changes.  Our purpose was a paradigm change, so our content was really driven by slides, the corresponding discussion, and the questions and answers we delved into.  You can download the slides from  Enjoy!


HTML5: A Primer

It was my pleasure to speak at the Phoenix Java User Group this evening, discussing HTML5.  By all accounts, it was a very fun evening, and of course, I’m sure I enjoyed it most of all.  The slides for this evening’s discussion are available here.  If you’re really curious about HTML5, I suggest you watch the HTML5 Camp Videos and in particular Stephanie (Sullivan) Rewis, a great HTML5 intro.

Thinking in Git

I had the great pleasure of presenting at SEVDNUG with my son this evening.  He was a wonderful asset, and a great star.  When we were all done, I think his was the bigger applause.  I look forward to presenting with him again.

Our topic was Git, the new hotness for version control. 

The Abstract of the talk is:

Have you ever looked at Git because it was trendy, but stumbled away dazed? Git isn’t your father’s source control system, but most of your knowledge of TFS, SVN, or other source control systems transfer over just fine. We’ll take your existing knowledge of your Commit / Update VCS and we’ll layer in the methodologies, tools, and communities that Git uses. What’s the difference between pull and update? Isn’t branching and merging dangerous? Can I get colored icons in Windows or Visual Studio? How do I contribute to a GitHub project? We’ll graph Git’s actions in blocks and compare it to git command results. You’ll come away thinking in Git, ready to easily leverage the additional power.

Quite humbly, I think we rocked the house.

What is Git?

Git’s website has a pretty good (if a bit verbose) description of Git:

“Git is a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server. Branching and merging are fast and easy to do.”

Git’s Methodology

Git really has two main tricks, and the focus of all our discussion is to explore in depth these things:

1. Git has 4 repository locations: the working directory, the staging area, the local repository, and remote repositories.  Once you can visualize where your data is, Git is easy.

2. Git’s magic is just moving labels between nodes.  We may call them branches, tags, HEAD, etc, but it’s just an identifier for a node to Git.  If you understand how your labels move as you commit, everything else is gravy.

History of Git

Git was created by Linus Torvalds in 2005.  He’s famous for a few other projects … like Linux.  I heard it said once that Linus would take over the world — perhaps not with Linux, perhaps instead with Git.

Where is Git used?

Git is used by most major source control hosting firms, and has become a staple at most social coding avenues:

1. GitHub is the quintessential Git hang-out.  It offers both open-source and private repositories (cost is quite reasonable), and really focuses on the social end of coding.  (It’s hard to describe the atmosphere and wonderment that is GitHub.  You really need to try it to see it.)

2. BitBucket is the mecca for Mecurial open-source projects, and now provides Git hosting.

3. CodePlex is the open-source hangout for Microsofties, and includes hosting for TFS, SVN, and most recently, Git.

4. SourceForge is the old hub of open-source, originally for CVS, now known for SVN, and more recently, they’ve added support for Mercurial and Git.

Want more evidence that Git is ubiquitous?  Go to Microsoft’s uber-mecca for open-source — to their project for MVC, Web API, and Razor at  Now click on Source Code, and click Connection Instructions.  Ya know what you see?  A Git url.  No “or SVN”.  No “or TFS”.  Nope.  All you get is Git.

Clearly Git is winning in the realm of version control systems.

Elements of Source Control Systems

There are 4 main elements to a source control system:

1. GUI Tools

2. Command-line Tools

3. Node Graph / Commit Log

4. Storage Map

Looking at these 4 elements in an SVN realm, we get something like the following:

1. TortoiseSVN provides an excellent front-end for the pointy-clicky people.

2. svn command line is great for power users and for automating and scripting things.

3. svn log from either the command-line or TortoiseSVN, and you’ve got a great view of SVN’s history.

4. SVN has really two spots where code lives: the SVN Server, and your Working Directory.

Here’s a graph of the 4 spots in SVN:

svn parts

Using those same quadrants, we can enumerate the toolset for Git in Windows:

1. Git Extensions works great as a Git GUI.  TortoiseGit does ok, but it forces us to look at Git as if it was a SVN repository.  The two can install seamlessly on the same box, playing nicely together.

2. msysGit is the Git engine and command-line tools, though posh-git is an interesting PowerShell plugin.  Most every other tool either depends on or installs msysGit.

3. kdiff3 comes with Git Extensions, and is a great way to browse git’s commit history and node graph.

4. Git’s storage system includes four main sections:
1. The working directory — the check-out folder in Windows
2. The staging area — the code you’re getting ready to commit
3. Your local repository — this is where the majority of the meat is
4. Remote repositories — places where you share the code — you need not have these, or you could have lots of connections to remote repositories

The graph we used for git’s parts looks like this:

git parts

Now let’s spend a bit more time with the 4 storage areas in Git:

Working directory we know from SVN, TFS, CVS, and other acronymed alphabets.

We’re familiar with “the server”, but in this case “the server” is on our local machine — the “local repository”.  That’s kinda weird, but kinda cool.  Now I can commit when I’m at a good stopping point, even if I’m not completely done with the task.  Ever get “code complete but untested” but want to save your progress but not break the build?  That’s the local repository.

The staging area is also a little weird.  Why would I have a place between my working, checked-out files and my repository?  Well, it allows you to commit parts of things without needing to commit the other parts of things.  In time, and with great skill and training, this allows you to commit part of the file if the other parts of it don’t need to be committed yet.  It’s a great place to build smaller, more purposeful commits.  Alternatively, you may find you don’t need this, and you’ll use the “just get it in already” or “-a” flag to the commit command.

Remote repositories are the most curious.  We’ve got a distributed version control system where everyone has a copy of every commit.  I can push my changes to you when I’m ready — as a big clump.  Or maybe I’ll push them to the CI server.  Or maybe I’ll push them to a colleague for code review before I commit to “the build”.  Or maybe on a small project, I just keep my source tree alone on my machine and have no remotes.

Everything but the “Remote Repositories” is on my local machine.  I can do everything needed with these while on a plane — without network access.

We now have the 4 parts of a source control system in Git.  It’s not scary once you know how it works.

Git Commands

We did a great job of showing the git commands and mapping their results in a node graph made of felt and string.  It was truly a performance, and to do justice, I’d need video.  We didn’t tape our presentation, but is a similar video, and the one I used for the majority of the inspiration of this section of the demo.  Me and my son took a bit different route, but this video does very well.  “A non-cyclical graph node isn’t scary when it looks like this.”  He’s holding up a tinker toy, I’m holding up felt and string.  The audience laughs, settles into their comfortable seats, and we’re off to the races.

Here’s a summary of the Git commands and the learning we can get from each one.  Go download msysGit, install it, then open up a command prompt or Git shell and follow along.  If I’m commenting on one, I’ll add “// <–” to highlight something.  Don’t include these as you’re typing the commands.

Start it off:
git init // <– get the repository started; we typically copy an existing repository, but this is simpler for now

Adding files:
Go create a file, add content to it, and substitute your file’s name for “<filename>“, and leave off the < and >.
git add <filename> // <–It stored the file in the repository right here
git status // <– it shows we’re on the “master” branch (trunk in SVN speak), and that the file is in staging
git commit -m “some message” // <– it added the label “HEAD” to it here, “HEAD” means “working directory is here”
git log // <– each commit has a sha1 hash that uniquely identifies it

The sha1 of each commit is a hash of:
1. The content of the objects
2. The hashes of the parent node(s)

Add another file or two, and git log starts looking pretty tasty … and pretty verbose.
git log –oneline –graph –decorate // <– this shows the graph node lines, the first 1/2 dozen characters of the hash, and branch labels — very, very handy.  After about the third or fourth time typing this, you too will make a shell alias or a batch file to do it easier.

The .git directory:
So now that we have some nice content in the local repository, let’s go pillaging through the .git folder.  This .git folder is the actual repository data.  There are quite a few tasty nuggets in here, and understanding how they work is very helpful.  Open a few in your favorite text editor.  But DON’T SAVE THEM!  Don’t brick your git!  :D

– open the HEAD file — it’s the sha1 of the commit that the HEAD label points to.

– open a few files in the refs folder — they’re also text files that contain the sha1 of the position of the label that is their name.

– look through the objects folder, and note that the first 2 digits of the sha1 is the folder, the rest of the sha1 is the file — this is where the actual content is stored, zlib compressed.  Open this in a text editor, and you’ll get some pretty zany zaph dingbats.


In Git, by convention, most things are done in branches.  Branches are very, very cheap in git, they’re just labels.  Let’s experiment with branching and merging, and see why they aren’t nearly the pain you’ve experienced wit non-distributed version control systems.

git branch somebranch // <– This creates the branch but doesn’t switch to it
git checkout somebranch // <– This switches to it
git status // <– check that you’re on the branch you thought you were on
now create a file, add it, and commit it
git log –oneline –graph –decorate // <– note that somebranch and HEAD moved, master didn’t

It’s worth re-emphasizing that git’s branches are just labels on nodes.  We didn’t copy all the files when we branched, the repo is no bigger for having the branch.  It’s merely another name for the node besides it’s sha1 hash name.

Merging (fast-forward):

Merging is also no big deal in git.

git checkout master // <– get back to master
git merge somebranch // <– merge somebranch into master
git commit -m “merged somebranch” // <– commit this change
git log –oneline –graph –decorate // <– note that master now moved to match somebranch and HEAD

We just moved the label — very simple.  The paths didn’t diverge, so we needed only push the master label forward.  Gorgeous.

Delete the Branch:

In git, a branch is just a label.  If we don’t need to refer to the commits by label anymore, we can remove the label.  It doesn’t delete code, and we can always get back to the node by it’s sha1 hash.  It merely removes the label from the node.

git branch -d somebranch
git log –oneline –graph –decorate

Branch / Merge (not fast-forward):

git checkout -b branch1 // <– checkout -b creates the branch and switches to it in one shot
create a new file, add it, commit it
git checkout master // <– get back to before this new file was added
git checkout -b branch2 // <– simulate a second developer
create another new file, add it, commit it

We now have an interesting scenario: we have two “ends of the trail” — two “tips”.  So let’s merge them together.

git checkout master // <– get back to home base
git merge branch1 // <– merge in the first branch
git commit -m “merge branch1”
git merge branch2
git commit -m “merge branch2”
git log –oneline –graph –decorate

See the nice diamond shape?  Pretty!  Try that with your silly little linear-only SVN.

Also notice where your tags are.  HEAD and master are at the top of the graph, but branch1 and branch2 are still where they were.  We could merge this new master into them (fast-forward), but we probably don’t need to.  More than likely, once this feature is done and integrated and enough time has passed, we can just delete these branch labels.

Working with Remote Repositories:

Now that we’ve got the hang of adding, committing, branching, and merging, and watched how it affects labels in our local repository, let’s take a wander through how we can share this code with others.

Create a new folder outside the previous folder.  Rather than git init in this new folder, let’s “initialize” this repository by linking to the previous repository.

git clone ../path/to/other/repo

The “path” can be a windows file path, it can be an http url, it could be git://  It doesn’t matter where it came from, when we’re done here, we have an exact duplicate of the other repository.  Prove this to yourself by running git log:

git log –oneline –graph –decorate

You’ve got all the history, all the tags, but something is interesting.  You’ve not only got your own HEAD and master labels, you’ve got some new labels: origin/master and origin/HEAD (and any other branches).  These new labels show you where the remote connection is.

git remote // <– this one lists the remote links you’ve configured
git remote -v // <– this one gives you the path to the other repository

Now from here, we need to talk a little logistics.  In TFS or SVN land, we did update and commit.  Those two commands are the commands we use in Git when talking about transitioning from and to our working directory and local repository.  So what do we call it when we’re moving between our local repository and a remote repository?  Pull and push.

git pull origin master // <– get latest from them to my local repository
git push origin master // <– send my latest changes to them

If there’s no major changes when I pull, I just commit to fast-forward my tags to the end of the line, and we’re good to go.  If there were changes on both sides, I may need to resolve a conflict before merging.  Git gives me the standard “theirs”, “mine”, “fix it” — both as diffs in command-line or as pretty diff compare views in GUI tools.  When I’m done, I commit, and it’s now combined together.

By convention, we’ll probably want to designate one copy of the repository as “the master copy”, and all push and pull to that one (unless unusual circumstances allow us to push and pull intermediary content between members of our team).  Though git technically doesn’t need a “server to rule them all”, it’s always nice to have a central place where we can back up the corporate assets and where the CI / Build process can look to for “the latest and greatest”.

Advanced Topics

It wouldn’t be fair to leave you in the dark about these advanced keywords that come in very handy.  Alas, it also wouldn’t be fair for me to confuse you with these details while you’re first learning git.  These tools are immensely handy though, and when you’ve got time, Google each of these terms:

git reset
git rebase
git cherry pick
git stash
git flow

Bringing it Together

We’re now concluding where we began: Git has really two major things that differentiate it from the SVN / TFS methodology we’re used to:

1. Git has 4 repository locations: the working directory, the staging area, the local repository, and zero or more remote repositories.  We saw how we could work with the staging area (git add; git status), and in time we’ll see how this view of the commit-in-embryo can be a great tool for forming cohesive, descriptive commits.

2. Git’s magic is just moving labels between nodes.  We saw throughout the command demos that as we made changes, we just created nodes and moved / added / removed labels from them.  These “branches” weren’t expensive, they were just organizational tools.  If a “branch” node path doesn’t work out, just abandon it, go back to master, and try again.  It’s not a lock-step linear process where everyone inherits my mistakes.  It’s just a system of nodes.

Git can now be a very, very powerful tool.  Given the popularity and pervasiveness of git, I foresee it’s just a matter of time before git is the new svn, and svn becomes the next cvs … or worse, the next SourceSafe.  And if you learn nothing else from this presentation of “Thinking in Git”, learn this: friends don’t let friends use SourceSafe.  :D

Great Git Resources

Extending ASP.NET MVC

It is my pleasure to speak tonight at the SEVDNUG about extending ASP.NET MVC.  This talk grew out of an impromptu talk I gave at Desert Code Camp 2011.2.  The speaker didn’t show for a class titled “Real world MVC”, so I took it and ran with it.

In this talk we’ll look at some common and some less-common extension points for ASP.NET MVC:
  • Routes
  • Route Constraint
  • Html Helper
  • Action Filter
  • Value Provider
  • Action Result
  • Model Metadata Provider
  • Dependency Resolver
The goal is to keep your code DRY (Don’t Repeat Yourself), and many of these tools make it much easier to centralize cross-cutting concerns.

Grab the code and slides we’ll work with from here.

Desert Code Camp 2011.2

Desert Code Camp is always such a pleasure, and I’m pleased to be able to speak twice this time.  I’m teaching two topics: Backbone and Qunit. Backbone is an MVC framework for JavaScript.  Much like you wouldn’t stick your entire program in a click even handler, why would you stick all your client-side code in a jQuery click event handler?  Backbone gives you the structure to create well architected client-side code.  Backbone is also light enough and modular enough and not opinionated enough to get you quickly to an on-ramp.  Download the slides and sample code we’ll play with here. Qunit is the JavaScript unit test framework used by the jQuery team to test jQuery.  It is a great red/green test harness for doing very elegant testing of client-side business logic.  Download the slides and sample code we’ll play with here. If you enjoyed this talk, leave me a comment.  If you didn’t like it, tell me how I can do better. Rob