Bryant Brabson

Monday, August 25, 2014

One of my team maxims is "Deploy Early and Often." As soon as a minimum viable product is available I want it off the developer's machine and deployed to a server, device, or wherever the final destination is.

Somewhat akin to TDD,
I'm actually expecting the first couple of deployments to fail. Maybe
you're missing a critical JavaScript library or don't have the same
level of access in the test environment as you do locally. These initial
failures are valuable in detecting any hidden or forgotten
dependencies. Ensuring that your product's deployment process is solid
as early as possible will reduce or eliminate the number of nasty
surprises as you approach the end of development. The last thing you
want to do is to earn the dubious 'Works On My Machine' certification shortly before the release.

Whether
your deployment process is manual or based around continuous delivery
get your application out there as soon as possible. Whether you adhere
to Agile or work in Waterfall, don't wait until the last moment to test
your release deployment.

Monday, May 5, 2014

I have a developer new to the team who has an extensive system
administration background. Due to various factors he has been working on
our build processes
rather than writing a lot of code initially. He mentioned that he
enjoyed taking this approach because it was a "good bridge" to writing
code.

That comment caused me to reflect on whether this might be a
good introduction for all new developers. It seems like it, because the
end product is what is important to our customers, not how elegant or
innovative the underlying code is. Yes, of course, there is great value
in well-written, high-performance code but that won't matter if the
deliverable is defective to such a degree that the customer rejects it.

So
how can one defend against distasteful defective releases?
Configuration management is a set of practices that attempts to improve
software quality. One of the important principles of configuration
management is the concept of repeatable, reproducible builds. A continuous integration
(CI) system gets you started down that path by eliminating the
disruptive variables associated with the vagaries of what is installed
on a developer's machine.

Setting up a build server as part of
your CI system isn't a turnkey process however. One frequently needs to
rewrite some code or reconfigure dependencies so that the application
can be built in isolation on the build server, free from any detritus
tied directly to a specific development machine. Once you get to that
point you probably start realizing that you should have made some
choices differently in the application. Essentially you're working from
the outside in, and this viewpoint is really important. Think how much
more efficiently the development team can work if projects are initiated
with the goal of cleanly building on the build server rather than
chasing down build issues specific to one person's development
environment. The exercise of having new developers work within the
configuration process earlier in their tenure rather than later
resonates with me. Understanding the meta pieces that form the
application is critical to deploying it, whether it is developers doing
the deployment or a release engineering team.

I am more concerned
about getting the release right than anything else. Having new
developers- even seasoned developers, for that matter- understand the
importance of writing code that fits easily into a CI environment is
invaluable. For me, this holistic view of the code pays dividends in
efficiency and quality.

Thursday, October 3, 2013

This is on me for not reading the manual, or in this case the GitHub README. But since I installed from NuGet I wasn't aware of any special instructions on usage. Regardless, my Bootstrap view which used AngularJS components wasn't working as expected and Firebug revealed the problem:

NetworkError: 404 Not Found - http://localhost:51293/template/alert/alert.html

Searching through the solution files quickly revealed that there isn't an alert.html or even a template directory. Luckily someone else had the same problem recently so I wasn't left flailing about searching for an answer in a sea of curly braces.

Using 'ui-bootstrap-tpls-[version].min.js' in this case rather than 'ui-bootstrap-[version].min.js' solved The Case of the Missing Template.

Sunday, March 24, 2013

Projects with 31st of December deadlines should be started well in advance of the holiday vacation time crunch. To most this is blatantly obvious. Some of our peers, however, act surprised that Christmas comes on December 25th every year and that most people take time off around that time. (Some folks take a LOT of time off!) I was astonished by the number of messages I received on 12/27 regarding projects with deadlines of 12/31.

Now, don't get me wrong. I am firmly in the camp that believes that ALL of IT is one team, and we all succeed or fail together. And to get even more macro, the entire company stands or falls as one. So, yeah, though it might seem otherwise, I AM a team player.

But...

But what does that say about the person who hasn't managed their
projects properly and are now looking for you to bail them out? Does
that make them a good team player? How is the greater team helped by someone who doesn't properly manage projects with cross-team dependencies? Or, at the least, ask for help prior to crunch time? Resources have to be diverted, which then impacts quality and timeliness of on-track projects.

A crisis on your part does not constitute an emergency on my part?
Now, don't be a jerk about it, but, as a manager you're going to have to decide how much you can assist at this late point in time. The right thing to do, of course, is to help your fellow human being. There are plenty of metaphors equating the corporate world as a brutal jungle, but I hope that your workplace isn't a Darwinian struggle for survival.

There is a corollary to the section title above: Poor planning on your part does not constitute an emergency on my part. The bottom line is that you shouldn't get into this situation in the first place. Plan for contingencies. Look at a calendar when you are planning a project schedule. If YOU are the one that has run out of time it's always better to admit
that you're not going to complete the task(s) at hand on time.

Conclusion
I am not claiming that I'm covering new ground with this post. I'm merely describing a management anti-pattern that seems to be popular in some organizations.

Friday, January 25, 2013

All I wanted to do was get my TFS 2012 Build Server going. (Getting the core components running was quite a struggle.) I expected some initial failed builds so wasn't surprised when I was informed of the following:

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (983): The reference assemblies for framework ".NETFramework,Version=v4.5" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Finding the .NET 4.5 SDK didn't sound too hard to do. It wasn't, and I learned that it was part of the Windows Software Development Kit (SDK) for Windows 8. I downloaded the indicated file, which was named sdksetup.exe. Its size hinted that unfortunately it wasn't a standalone installer but (ugh) a web installer. I gave the sdksetup.exe a go on the server but wasn't surprised that it failed due to lack of internet connectivity through our proxy server. My next idea was to either extract the files that I needed locally or install and then copy the files to the server, which has worked before.

I missed it the first time around, but the Windows 8 SDK had an option to download the required files for installation to a separate computer see ('.NET Framework 4.5 SDK Tools on Windows Vista and Windows Server 2008' after the jump). This is important because- and I missed this initially as well- "The installer for the Windows SDK for Windows 8 is not supported on Windows Vista and Windows 2008 Server." Well, that's pretty cool that I can create my own installer, I thought, and away I went.

Nothing too exciting initially.

I appreciated being able to deselect all of the stuff I wasn't going to need on a build server.

Ugh. More proxy issues, even locally. Shades of Mordac! I could easily download the .NET 4 redistributable though, so I was still undaunted.

Now things started to get silly. Where was I supposed to find sdk_tools4.msi? Searched Google, other folks were wondering the same thing.

Maybe I already possessed sdk_tools4.msi and didn't know it. Everything proved that theory valid. Hoorah! Now I could build my SDK installer, get the builds rolling, and move on.

It wasn't to be. After browsing to my local copy of sdk_tools4.msi and clicking Retry, the SDK builder process gracefully prematurely ended, mentioning something about 'bad payload' or the like. Sdksetup.exe revealed an important secret at this point: a log file! Mine was located at 'C:\Users\[Username]\AppData\Local\Temp\standalonesdk'. The file was thankfully extremely verbose, and I could see all of the failed web requests for various resources.

For example, when I was prompted to specify the location of netfx45_dtp.cab...

I then plugged the URL into a browser which then prompted me to download the file. After downloading, I then specified the location of the file in sdksetup.exe and clicked Retry. It took about 10 minutes or so to get all of the files. Not the most elegant of solutions but hopefully this wasn't something that I was going to have to do often.

Wednesday, January 9, 2013

I really need to spend more time exploring Visual Studio 2012's Team Explorer. I just discovered that after adding a query to 'My Favorites' you'll be presented with a helpful summary of the number of Work Items, their State, and the type of query, such as a Flat List or Tree of Work Items.