| Comments

Lately I’ve been doing a lot of re-paving of machines and I never had my favorite tools on them, nor did I want to spend the time to re-install a set of tools that I knew I would blow away each day anyway.  Mostly my daily builds have been to do some scenario validation and is quite repetitive.  However there are times where a stable build combination comes along that I keep for a while to work on customer apps or sample development.  When these times happen I find myself needing my helpful little utilities more frequently.

Recently I’ve been trying to learn Git, a version control system that has been gaining popularity over the past few years and is quite cool and agile.  I am generally a huge fan of GUI tools because I feel that they are more in line with how I use other parts of the operating system/tools.  When exploring Git, however, I wasn’t a fan of having to re-install any of the tools over and over and do configuration, etc.  That’s when I discovered portable Git.  It immediately made me realize how dumb I’ve been all this time across machines and renewed my love for portable tools.

What is a portable tool? 

Quite simply it is a tool, regardless of size, that can run with no other dependencies than those that it comes with in the directory or executable.  No requirement of “oh you must have Foo framework 1.0.2.123 installed to use this” as the portable tools completely operate on their own.  Now some are single, small executables.  Others are full-blown programs that bring some serious runtime environments with them.  But both don’t require anything to pre-exist and can run without installation.

I took one of my 8GB USB drives (Costco was having a sale – 3 8GB sticks for $24!!) and started loading up my favorites.  Here’s what it ended up like:

portable tools directory

Now I use other tools on a more stable basis and when Windows 8 goes into more stable releases, I’ll probably lock to on-the-metal installs for those.  I also don’t require any huge amount of tools all the time, but like my favorites.  So what are those directories?

  • DiffMerge – a great, simple-but-visual tool to help do file or directory diff checking and merging if desired.  Some like WinDiff a lot, but I’ve been liking DiffMerge lately.
  • Git – as mentioned above, this is the portable Git tools which provides a bash or command prompt environment.
  • Inkscape – a vector-based graphics tool
  • Notepad2 – my absolute favorite simple text editor
  • Notepad++ (npp in the above image) – another great text editor.  Why two you ask?  The one thing I like about Notepad++ is that I can open up multiple files at a time and do find/replaces across multiple files.  I don’t always do that, but it is a time saver when I need it.
  • Sublime Text – yet another text editor.  When looking for cool portable tools I found this one.  I’m not sure I’ll use it given Notepad2/++ but since it is in the picture, I thought I’d explain it.  Some say it is the TextMate for Windows.
  • “portplat” – more on this in a bit.
  • _ninja – I wish I could tell…but, well can’t

This USB is now extremely helpful to me on a regular basis.  After loading up a new machine I have instant access to tiny little things that just make me more familiar and immediately productive.

NOTE: There are a few more that I use more infrequently but I think I’ll add to my USB key like reflector-type tools.

In writing this post I wanted more…a lot more and started looking around.  Then I found PortableApps.com!  I felt like a complete idiot when I discovered this because I thought I was so cool to seek out portable tools and here was this site who already aggregated them for me and went above that and made it easy to acquire them!

What they do is provide a “Portable Apps Platform” that serves as basically a mini-launcher for a set of portable tools.  In addition to my folders above, here’s what my USB key now allows me to have as well:

Portable Apps Platform

Now I should note that my existing tools (with the exception of diffmerge and git) are all available through this Portable Apps Platform tool setup.  I was already set up in my ways so I figured no need to change what I already had.  The Portable Apps Platform tool has a directory of a ton of apps:

Portable App Directory

Notice the scrollbar in that image above?  There is lots of stuff here.  Most I would never need, but nonetheless it is there…even portable games!

So now I have versions of some browsers on my USB and two of my other favorite tools I didn’t even know were portable: 7-zip and Console2.  The great thing as well is that any configuration you make for these portable tools travel as well…so my customizations for my Console2 environment are on the USB drive and I don’t have to set up my fonts/colors each time!

Within each tool there are likely customizations that you may want.  For example, I like having the “Open With…” settings on my context menu for Notepad2 and Notepad++ for convenience.  On my USB key I keep a setup.bat file with any special configurations for each tool that I want (that may either not be kept in the portable environment or may be machine-specific like the context menu).  I quickly run that and am ready to use my tools how I’m familiar with them. 

Some tools also have config files built in to their environments, like Git.  I was sick of continually typing git config –global user.name “Tim Heuer” and other config each time I set that up.  Luckily a few questions on Twitter and Paul Betts was able to point me to the obvious.  So now I have a customized .gitconfig file on my USB key and whenever I use the bash environment my settings are already there!

So what’s missing?

I’m feeing liberated with these tools lately that now I’m frustrated I can’t get everything in an install-free environment! 

Please don’t rant about Mac, Linux, whatever OS environment lets me do that.  I’m on Windows and it doesn’t for everything.  Yes…the registry lives…I deal with it.

There are a few things I wish that were portable that would complete me.

  • Visual Studio – ah, someday maybe, someday.
  • Paint.NET – While Inkscape is awesome, it isn’t as familiar with me as Photoshop-esque tools.  Paint.NET is the closest to that and would be awesome to always have around.
  • Fiddler – nuf said.
  • Silverlight Spy – extremely cool tool

It’s not a long list, but these are some regular tools that I wish were portable. 

So there you have it. If you haven’t discovered a portable set of tools, you should get out a USB key and load some up. Who knows when you’ll find it handy!

| Comments

It seems like a daily question I’ve been answering lately when working on internal email discussion groups and folks report an issue, my initial response is: what build combination are you working on? 

As a part of my job, I like to ensure the fastest resolution (or awareness depending on how you look at it) to issues that affect our product.  This involves staying on top of ‘latest bits’ as we call them.  Every morning I come in and install the latest Windows build as well as the latest Visual Studio build.  We have an automated Hyper-V environment that makes it easy to get the initial Windows builds up and going and then I selectively apply VS on top of that.

So if it sounds so simple, why do I ask that question to people that ask?  Allow me to show you a few diagrams.

The above is a *snapshot* of just a few of the branches that affect the tools area that I work on.  This is not representative of the entire branching structure, which is huge. 

NOTE: This diagram is automatically created for you from Team Foundation Server…you select the branches of interest and it visualizes for you.  There is also an awesome feature to track changes which I’ll note below.

The red box items make up the different teams working to bring together the holistic view of some of the core developer experiences.  Since they aren’t *just* working on my stuff, nobody can live in a single branch together in harmony.  You can see that the spread of varying levels of branches required to get something working is pretty broad.  And merge (we call them RI/FI) processes are on different schedules and managed to reduce conflicts as much as possible.  The above is just one piece of the puzzle – the developer tools.  Windows has a similar ancestry view we have to deal with:

The red boxes here are basically other Windows teams that we need stuff from to get our product working as well.  These RI/FI process go through many, many checks and if any regressions, they don’t allow merging, which can cause issues if you are waiting on a fix to come to your branch!

So the answer to whether something should work at any given time during development milestones has different answers depending on where you got your bits from.  I’ve personally resorted to hosting a page on our team wiki with the title Tim’s Guide to Finding a Build Combination™.  I’ve also added a few helpful scripts to get any missing pieces aligned for builds.  So now I’ve got my daily build routine down to a science.

Occasionally there are times where a fix is completed and I look back at my tracking bugs.  Sometimes you’ll get a team that just fixes things and you aren’t given a chance to test out private bits, or whatever…so you have to go hunt down where the fix is at and when it will come to you.  In most source control systems there is a good mechanism for viewing/following a changeset.  In TFS I think they’ve nailed the feature to do this in two ways of visualization.  You can “track changeset” and choose a timeline view or branch view…it is awesome for pinpointing just where a fix is working the way through the source depots.  Here is a view of a bug using the branching view.  Green shows which branches has the fix (changeset):

Here is another bug using the timeline view showing me when the fix made it to certain branches:

For me, this has been invaluable to really identify when/where things are and determine a predictable path for resolution on issues as they converge.

Managing a process to get a Good Daily Build™ is not always easy when you need pieces coming from two different organizations which are very large and working in many, many branched source depots.  But staying on top of things so you can quickly help your customers/partners move forward progress is a very rewarding experience.  My daily routine has helped me stay on top of the core issues at hand and determine a daily quality on the mainstream scenarios as our customers see them, which isn’t always caught with test automation or unit tests all the time (but yes, we have those too).

Well, a new build just came out…time to update my wiki!