Delivering files using NuGet 2 so they're copied to the output directory

I recently had a situation where a NuGet package I was creating had to deliver some supporting DLLs which needed to be copied to the output directory (actually into a sub-directory named /x86). We're using NuGet 2 at work because our internal NuGet feed is managed via ProGet, which doesn't yet support NuGet 3.x. While NuGet 3.3+ gives the copyToOutput option to have content files delivered to the output directory, there's no such support in NuGet 2. In researching how to do this I came across two very helpful posts on StackOverflow which gave me the direction I needed. The posts were http://stackoverflow.com/a/30386836/123147 and http://stackoverflow.com/a/30316946/123147.

The approach I took was to have the files I needed to distribute be included in the NuGet package in the /build folder, as opposed to /content. In fact, I put them in a sub-folder named /x86 which was the desired target location in the output directory. I then used an MSBuild targets file to mark all the files in that sub-folder as always needing to be copied to the output directory. I had not worked with MSBuild targets (or properties) files before - so this approach was totally new to me.

This blog post seeks to expand on using a MSBuild targets file in a NuGet package. The NuGet documentation talks about this technique - but I thought a more step-by-step set of instructions might help others.

The sample code I'm providing in this post is a little different from what I did at work in that there's no sub-folder created in the target directory. I am using a sub-folder in the NuGet package's /build folder, though, so don't have to act on each file individually.

The sample scenario

The contrived example for this post is to create a package which delivers files to the output directory of any project that installs my NeededFiles package; an image and a readme file.

What does an MSBuild targets file do?

If you were to open a Visual Studio project file (e.g. csproj or vbproj) in a text editor you would see it's an XML format which defines properties and actions (i.e. "targets"). I found it pretty similar to a NANT script. What a targets file lets us do is define a target that can be imported into the project file later. The NuGet documentation explains that when a package includes a targets file with the same name as the package in its /build folder the NuGet installation will add an import element to the project file.

What's in the NeededFiles package?

The NeededFiles.nuspec file looks like this:
1. <?xml version="1.0"?>
2. <package >
3.   <metadata>
4.     <id>NeededFiles</id>
5.     <version>1.0.0</version>
6.     <authors>@Rob_Hale_VT</authors>
7.     <requireLicenseAcceptance>false</requireLicenseAcceptance>
8.     <description>
9.   An example of delivering files to the consuming project's output via build targets
10.  </description>
11.     <releaseNotes>Created</releaseNotes>
12.     <copyright>Copyright 2016</copyright>
13.     <tags>Demo</tags>
14.   </metadata>
15.   <files>
16.  <!-- In this instance, the file(s) to be delivered are in the sub-folder named "howdy" -->
17.  <file src="howdy\*.*" target="build\howdy" />
18. 
19.  <!-- The targets file must have the same name as this package -->
20.  <!-- More info: https://docs.nuget.org/ndocs/create-packages/creating-a-package#including-msbuild-props-and-targets-in-a-package -->
21.  <file src="NeededFiles.targets" target="build" />
22 .  </files>
23. </package>

The key lines for what I'm doing are 15 - 22, where the files element is defined. On line 17 I'm added all the contents of a folder called "howdy" to the /build/howdy target folder. This folder contains the image and readme file I want to have delivered

Additionally, line 21 adds the NeededFiles.targets file to the /build target folder.

What does the NeededFiles.targets file do?

Now that the NeededFiles package includes the /build/NeededFiles.targets file we can take a look at what it does.

1. <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
2.   <ItemGroup>
3.     <NativeLibs Include="$(MSBuildThisFileDirectory)howdy\*.*" />
4.     <None Include="@(NativeLibs)">
5.       <Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
6.       <CopyToOutputDirectory>Always</CopyToOutputDirectory>
7.     </None>
8.   </ItemGroup>
9. </Project>

This file is imported by the consuming project. This means when the project is built line 3 declares an element named NativeLibs which is comprised of the contents of the howdy folder (delivered as part of the NeededFiles package). Lines 4 - 7 are acting like a loop, instructing MSBuild to mark each file in NativeLibs so they are always copied to the output directory.

If I wanted the files to all appear in a sub-folder of the output directory I could modify line 5 to be:

<Link>%(RecursiveDir)howdy/%(FileName)%(Extension)</Link>

Summary

At this point the package will deliver the contents of the Howdy folder to the output directory of any project that installs the NeededFiles package. Unlike files marked as content, the files in the build target folder don't even appear in the Solution Explorer in Visual Studio. "It just works."

The source for my contrived example, NeededFiles, can be found at https://github.com/robhalevt/NeededFilesExample

Seven year navel gazing...

The first post of this blog documented that I was preparing to start a new job. That was December of 2008. Seven years seems like a long ago.

On Monday I start another new job.

So I feel like this is a good opportunity to reflect on what these past seven years has meant to me and my career. A chance to thank the universe for what I've experienced, to thank the folks I've met, and to recognize where I think I'm going.

The month after that initial post I started working at MyWebGrocer. I had been hired to work on the eCommerce product and introduce some improvements to the development processes. I had played a similar role at my prior employer by implementing an automated build system and a few other bits of tooling. At MyWebGrocer, however, I was able to expand on that prior work. I led the introduction of a continuous integration server, static code analysis, automated unit testing, some scrum practices, and more. The team I was on kicked ass; our product was pretty stable, we were delivering new functionality, refactoring to reduce complexity and lines of code, and enjoying each others' company. After a few years I took a management position. While I eventually resumed my technical career - for those two years I had the privilege of managing the best team with whom I've had the pleasure of working. When I decided to leave management the MWG executive team was supportive; allowing me to resume my technical career without leaving the company. Not every employer would have done that; I'm appreciative.

My tenure at MWG coincides with my increased participation in the development community around Burlington, VT. I increased my involved with the VT .NET user group which led to co-founding the VT Code Camp. When MyWebGrocer founded the HackVT event they invited me to be on the planning team. I've continued to serve on the organizing team for HackVT. I've met amazing members of our technical community, too. Organizers of other local user groups, students, presenters, sponsors, employers, journalists, writers, etc. My participation in this community will continue regardless of where I work, and I'm confident that MWG's support of the local development community will continue, too. They've been reliable sponsors for VT Code Camp, HackVT, and other local development events.

As I transition into my next role MWG is six times larger than on my first day. I look at how the development team works and I see my fingerprints on a lot of it. It's not been a perfect experience. I've made mistakes and there are elements of what I would have like to have contributed to the MWG experience which are unfulfilled. This is the real world, after all. But these past seven years have (so far) been the highlight of my professional career.

Come Monday, when I start at Renewable NRG Systems I will be a significantly better, and more well rounded, developer than I was seven years ago. I'm eager to dive into a different industry for an organization which has a different corporate culture. New people, new knowledge - it's going to be great!

So thank you to the MWG team for helping me grow professionally. And for your friendships. Thank you to RNRG for the opportunity to challenge myself in an industry I feel is important.

Thanks universe.

What HTTP Status Code to return

A colleague shared a link to http://racksburg.com/choosing-an-http-status-code/ with me today. It contains a nice rundown of when to have your API return certain status code values.

Interesting link to keep

Not really a blog post here. Just don't want to lose the URL for a calendar that has a round up of Vermont based events of interest to entrepreneurs and development folks: http://www.vermontventurenetwork.org/?view=calendar&month=November-2015

End to End testing takedown

Google's Testing Blog has a post, Just Say No to More End-to-End Tests, which does a nice job of articulating my experience with automated testing. Specifically I've found unit testing to be more beneficial than integration testing and integration testing more beneficial than end to end testing (E2E).

The immediate feedback provided by unit tests, which run significantly faster than the other two, helps me as a developer. Using a TDD approach, and frequently invoking my unit tests, the design is refined and failing code is identified quickly. At my current employer we've tied the unit tests into the continuous integration process so that if code coverage drops by 1% or more the build fails. That's a nice defense against having the code atrophy. I also like the closing statement from Martin Fowler's post, Test Pyramid:

In particular I always argue that high-level tests are there as a second line of test defense. If you get a failure in a high level test, not just do you have a bug in your functional code, you also have a missing unit test. Thus whenever you fix a failing end-to-end test, you should be adding unit tests too.

Integration and E2E tests have value, and I'm not arguing they be skipped, but I've found the greatest ROI comes with unit tests.

Bookmarking future reading

A co-worker was passing around a link to a Mozilla document that provides A re-introduction to JavaScript and I don't want to lose the link. It looks to be a thorough article - which requires more time than I can currently dedicate to it, hence the bookmark post.

Nothing to read here, citizen. Move along.

Adventures (and frustrations) in NuGet package creation

I'm frustrated.

And disappointed.

Frustrated and disappointed. But more knowledgeable.

I spent a good part of today trying to get our CI build to create our NuGet packages so the resulting packages list their dependencies without developers having to manually edit the .nuspec file unless they have to. Unfortunately, I've failed, but I know a little more about how to interact with our TeamCity installation and the nuget pack command.

What I learned was that our build process invokes the nuget pack command which creates the package. Reviewing the documentation for that command I read about the IncludeReferencedProjects option which is described as doing the following:

Include referenced projects either as dependencies or as part of the package. If a referenced project has a corresponding nuspec file that has the same name as the project, then that referenced project is added as a dependency. Otherwise, the referenced project is added as part of the package.

"This is great!" I thought, "The solution I'm currently working on has project references that met that description. I won't have to explicitly declare the dependency."

What I was trying to do

Maybe a brief note about the solution is in order. It's for a WebAPI and has several projects in it, not all of which are published as NuGet packages. The projects are:

• MyApp 
• MyApp.Application
• MyApp.Api
• MyApp.Api.WebHost
• MyApp.Repository

With the exception of MyApp.Api they each result in a NuGet package.  Mainly because even though we're moving to have all calls go through the MyApp.Api.WebHost which is the package that's automatically deployed to the web servers, there are some older projects that continue to need access to MyApp, MyApp.Application and MyApp.Repository.

As you would guess, there are project references between some of the projects. For example, MyApp.Api.WebHost references MyApp, MyApp.Application and MyApp.Repository. What we've been doing is modifying the web host project's .nuspec file to declare the dependencies on MyApp, MyApp.Application and MyApp.Repository.

What I tried

Given this configuration I thought the IncludeReferencedProjects option would allow us to only declare package dependencies that existed outside the solution.

So I sat with a co-worker who is very knowledgeable about the TeamCity templates we have. He showed me the how to include that option on the build step which creates the NuGet package. We copied the template to a temporary one to test with, added the option, associated the MyApp build to that template, modified the .nuspec file to remove the explicit package dependency declarations, committed the code, and sat back to see the results.

It didn't work.

The resulting nupkg file doesn't list the dependencies. We then modified the way nuget was run to turn up the verbosity (-Verbosity detailed) and ran it again to see if we learned anything useful. All we saw in our build log was [pack] Dependencies: None. Then my co-worker noticed in the pack command examples that in addition to running nuget pack against the .nuspec file you can also run it against the .csproj file. So we tried that. That change resulted in a number of failing builds because the .csproj files had references to Visual Studio 10 and we're using VS2013 - doesn't make a difference to MSBuild because it knows what version it is, and it didn't matter to nuget pack when we targeted the .nuspec file (presumably because it didn't need it) but when we target the .csproj file it broke. So we changed the project files so:
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
became
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">12.0</VisualStudioVersion>

and
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
became
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />

Neither of these changes fixed the problem. We were continuing to see an error that read:
[pack] Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.  [the path to my .csproj file]
[pack]    at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(String errorSubCategoryResourceName, IElementLocation elementLocation, String resourceName, Object[] args)
[pack]    at Microsoft.Build.Shared.ProjectErrorUtilities.ThrowInvalidProject(IElementLocation elementLocation, String resourceName, Object arg0)
[pack]    at Microsoft.Build.Evaluation.Evaluator`4.ExpandAndLoadImports(String directoryOfImportingFile, String importExpressionEscaped, ProjectImportElement importElement)
[pack]    at Microsoft.Build.Evaluation.Evaluator`4.EvaluateImportElement(String directoryOfImportingFile, ProjectImportElement importElement)
[pack]    at Microsoft.Build.Evaluation.Evaluator`4.PerformDepthFirstPass(ProjectRootElement currentProjectOrImport)
[pack]    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate()
[pack]    at Microsoft.Build.Evaluation.Evaluator`4.Evaluate(IEvaluatorData`4 data, ProjectRootElement root, ProjectLoadSettings loadSettings, Int32 maxNodeCount, PropertyDictionary`1 environmentProperties, ILoggingService loggingService, IItemFactory`2 itemFactory, IToolsetProvider toolsetProvider, ProjectRootElementCache projectRootElementCache, BuildEventContext buildEventContext, ProjectInstance projectInstanceIfAnyForDebuggerOnly)
[pack]    at Microsoft.Build.Evaluation.Project.ReevaluateIfNecessary(ILoggingService loggingServiceForEvaluation)
[pack]    at Microsoft.Build.Evaluation.Project.Initialize(IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectLoadSettings loadSettings)
[pack]    at Microsoft.Build.Evaluation.Project..ctor(String projectFile, IDictionary`2 globalProperties, String toolsVersion, String subToolsetVersion, ProjectCollection projectCollection, ProjectLoadSettings loadSettings)
[pack]    at NuGet.Commands.PackCommand.BuildFromProjectFile(String path)
[pack]    at NuGet.Commands.PackCommand.BuildPackage(String path)
[pack]    at NuGet.Commands.PackCommand.ExecuteCommand()
[pack]    at NuGet.Commands.Command.Execute()
[pack]    at NuGet.Program.Main(String[] args)
[pack] Process exited with code 1

For some reason neither of us understood, the project file was still looking for version 10, even though the file on the build server had version 12 specified. We decided to change the way nuget pack was being called to include the property assignment of the VisualStudioVersion (-Properties Configuration=Release;VisualStudioVersion=12.0).

This got us a successful build and the resulting nupkg file started listing our dependencies as expected.

So the IncludeReferencedProjects option only appears to work when nuget pack targets the project file.

Short lived victory lap

After high fives all around we set about changing the real template for our CI builds. Once that was done we kicked off builds for the projects which used that template. What we found was that even with the changes we made related to the VisualStudioVersion, in both the properties passed from the nuget pack command and the project files, some of the builds kept failing because the version being sought was v10 not v12.

Observations before reverting

What we noticed was the problem seemed to occur when project A.1 was being packed but project A.1 referenced A.2 and the import line that was causing the exception was in project A.2.  For example, during the pack of project MyApp.Account.Api.WebHost the exception line was
[pack] Microsoft.Build.Exceptions.InvalidProjectFileException: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.  F:\Agent\Work\3b114de58491d1e6\src\MyApp.Account.Api\MyApp.Account.Api.csproj

At this point we got stumped because all the project files had the hard coded v12.0 value. Somehow the import is being given the wrong path. We can't find the cause of it and after a half day we had to move on.

Appeal for advice

If anyone knows how we might successfully revisit this and work past the problems; either by telling us why the IncludeReferencedProjects option wasn't working from the .nuspec file or explaining what we have to do related to the VisualStudioVersion, (or something else we're not seeing that you know of) it would be appreciated. Tweet me.

"Coding like a Girl" - great read!

Last night I had the pleasure of attending the second anniversary party for the Girl Develop It! Burlington, VT chapter. It was a chance to see some friends I've made through the local developer community, meet some people in our industry who were new to me, and reconnect with a few of the people who I met the handful of times I was a TA for a GDI event. At one point a conversation I was involved in turned to the challenges of being a technical professional who chooses to dress in a more feminine manner. It was amazing to listen to these accomplished professionals discuss how their choice of outfit would, in many cases, predict how they would be received. At that point Kathleen Dollard recommended a blog post entitled "Coding Like a Girl".

I read it this morning and believe it is worth sharing. The anecdote shared in the post about the experience Tracy Chou, an engineer at Pinterest, had at a technical conference was facinating:

A couple years ago she attended a technical conference and on the first day, she wore a dress. When she walked around the conference, no one came up to talk to her. When she asked people very technical questions about their stack, questions she assumed would indicate that she was a programmer, she was brushed aside and told, “You wouldn’t understand.” She went back home that night really frustrated and flustered. She almost didn’t feel like going to the conference the next day. But she did and wore a nerdy tshirt and jeans instead, and she had a better experience that day. People assumed she was technical and didn’t dilute their explanations to her.

That an industry peer had to change her appearance in order to be taken seriously is disappointing to me as a guy - as a woman it must be infuriating.

I like to think I do a decent job when dealing with folks, I'm reasonably self aware. Yet I know there have been a few times where I've judged other guys who come to a tech event dressed in a suit and assume they're sales people and not "real" technical folks. If I've done that to another guy - with whom I have more in common - what biases do I have around a woman's appearance? Have they colored my interactions with anyone?

We can only do our best, I suppose. I'm going to try and be more aware of my own biases when it comes to appearance and adopt the advice offered in the post, "Assume people are as or more qualified than you" regardless of their appearance. I hope that you take a few minutes to read the blog post, too.

A very important read for software professionals

Alan Stevens has a blog post that I think is a very important read for anyone who is a software professional. I think that this is an especially useful read for developers just entering the field. Do yourself a favor and take the time to read this.

Creating Visual Studio Templates

I spent most of yesterday creating a solution template for Visual Studio 2013 so our developers can begin a project with about an hour's worth of plumbing already done for them. It was an interesting task and one that gave me a lot of satisfaction having completed.  I like knowing that I've reduced developers' time for a 1 hour task to 5 minutes (more on why it's not less than that shortly).

First, there were a few links that proved invaluable:

• Creating Visual Studio templates
• How to create multi-project templates
• How to substitute parameters in a template
• Template parameters
• Visual Studio template schema reference

The process I followed consisted of creating a solution that I was going to use as a reference point. It had all the projects, folders, classes, dependencies, etc. set up. Then I exported each project as a template and went through each one making sure my parameter substitutions were in place. I then tested each individual project template to ensure they behaved as expected. Finally, I hand-rolled a multi-project template that tied them together.  That part was simple enough.

Where I started to hit a snag was that the multi-project template behavior creates a sub-folder for the first project and within that a sub-folder for each project (rather than having the project folders all created as peers of the *.sln file). There doesn't appear to be a way to change that behavior, which is unfortunate, because it prevents NuGet dependencies from working properly.  So while the template creates everything in a matter of seconds, the developer then has to close Visual Studio, relocate five folders to the correct location and edit the *.sln file.  That's why the template only saves 91.5% of a developers time rather than 99.8%.

Still pretty good, though.

Getting to a command prompt from Windows Explorer

Many years ago there was a utility I had installed on my Windows95 or Windows NT box that added an item to the context menu of Windows Explorer allowing me to open a command window with the folder I had in focus as the working directory. Somewhere along the line between Windows Vista and Windows 7 (my current OS) that utility stopped working. I never followed up to find it again and got along without it - though I would miss it from time to time.

Last week a co-worker made me aware that functionality is available in Windows 7, but it's slightly hidden. I have no idea how long it's been an option but am very happy to know about it - and I like to share what makes me happy.

Normally, if you right-click on a folder in Windows Explorer you get the context menu. Here's a shot of what mine looks like:

Context Menu

Yours probably looks similar. But what my co-worker pointed out was that if you hold down the shift key when you do the right-click the menu includes an extra item:

Context Menu, now with shift key

I have no idea why this isn't just part of the regular context menu, but I'm happy to know it's there now.

On the heels of our recent WTF.JS session

Our most recent meeting at the VT .NET user group was a series of lightening talks covering different JavaScript frameworks. Today I was directed to TodoMvc which is a site where the same application has been implemented multiple times using different MV* JavaScript frameworks. It allows developers who are considering the various (and numerous) options to "kick the tires" and see which approach might work best for them.

Neat!

Nice writeup on bulk renaming of files in Windows

Recently I had to rename a bunch of files in a Windows folder to have the same prefix.  I found a page on the Windows Command Line blog that provided a nice write up on a number of techniques around bulk renaming.

Running Our Internal Hackathon

For over a year now one of the best responsibilities I've had at work is to organize internal hackathons for our development team. Recently I told some peers how gratifying it has been to run these events. Some of them asked for more information as they consider introducing a similar event at their own shop.

Format
Ours is a two day event where staff are encouraged to be creative, explore new technologies, work with different folks than they would normally, and have fun. We try to have it be a 100% participation event, but that can be tough with vacations and the like.  We encourage team members who are concerned about a deadline or other conflicting priority to talk to their manager.  We really want to make space for everyone to participate and the managers will attempt to move mountains to encourage participation.  Our event is an exhibition format, not a competition.  The opportunity to stretch, explore and showcase their talents has (so far) been enough of a reward that we've not felt the need to have prizes, judging, etc.

First thing on Day 1 there is an event kick-off meeting.  The point of the kick-off is to build excitement and hit a few points about logistics like food, how we will respond to any production issue that may come up during the event, etc. We also take that opportunity to remind folks about some of the ground rules, and any last minute announcements.  It's worth mentioning that teams can start as early as they like on Day 1, including midnight if they choose, but the kick-off is the official start.

After the kick-off the teams disperse to work on their projects and don't have to come together again until the afternoon of Day 2 for the presentations.  We only expect people to work business hours but they are welcome to stay late or even stay over if that suits them.  We set up a couple of cots in our game room for anyone who decides to stay, or just needs a nap.  We bring in food for the participants, too.  Lunch and snacks on Day 1.  Breakfast, lunch and snacks on Day 2.

We start the presentations around 2:30 on Day 2. Because the event is an exhibition we ask the teams to touch on three questions during their presentations:

• What were you trying to do?
• How did you approach the problem?
• What did you learn?

We've tried two formats for the presentations; "lightning talks" and "science fair."  The first three events we did as "lightning talks" with each team coming up to the projector and PA to showcase their project.  This had the benefit of everyone getting the chance to see each project.  Additionally, we have some remote staff who wanted to see the presentations so we used GoToMeeting to enable that (which had the added benefit of making it something I could easily record).  The down side to this format is it feels long. Additionally, each team could only get 5 minutes to present.  We had to fit all the presentations within a two hour window. Many teams found that to be a challenge. 

With our most recent event we switched to a "science fair" format where everyone would go visit each team's space and hear the presentation.  The advantage to this approach turned out to be the presentations were much more interactive and folks could spend as much, or as little, time as they wanted with each project.  There were a few down sides. A team's members would have to take shifts to visit other projects; someone had to stay behind to demo the team project. This lead to not everyone seeing every project. Remote staff couldn't participate in real time and will have to rely on videos of each team presentation I made using my phone.

The other thing the new format lacked was a clear end of the event.  I think we all missed that and will introduce a way to punctuate the event next time.  Based on the initial feedback, though, the "science fair" format was clearly preferred by everyone involved.

Project Ideas
Even though the event is not a competition we do have some ground rules about the projects.  People pitching a project idea need to have a reasonable answer for at least one of the following:

• How does this benefit the company?
• How does this benefit your Team?
• How does this benefit your dev life/career in our shop?

The interpretation of "reasonable answer" is pretty flexible, but the staff has really respected the spirit of these guidelines.

Once someone has a project they would like to propose they enter it in a shared spreadsheet.  We ask people who are adding a project proposal to list themselves as the "Team Leader/Idea Person." That way other people can talk to them about joining the team. Plus, if they have a good idea but don't want to be the "leader" they can work out roles with folks who want to join the team. Teams can be as small as or as big as their idea requires. We discourage people from working solo because part of this is to encourage people to build relationships across the departments who are participating.

Logistics
The project sign up spreadsheet serves a few other uses. I use it to identify which teams are large enough to assign a conference room. We book all the conference rooms on our floor for the duration of the event so teams have a dedicated space to work on their project. Bigger teams get the bigger conference rooms.  The spreadsheet also allows me to reach out to staff who haven't picked a project so I can facilitate a match or identify folks who are opting out of the event for whatever reason.

Before our most recent event I also set up a survey in Google Drive so people could be included in the head count for the food order.  Our wonderful admin, Meg, needs to order the meals at least a week before the event. Locking in how many people are eating each meal prevents us from ordering too much (we had a fair amount go to waste the prior event when few people stayed for dinner).  The survey also allowed us to solicit information about food allergies or other dietary restrictions that would inform the food order.

Communications during the event, though, are intentionally low tech. Any announcements or group communications are done by sneaker-net.  I go room to room to let each team know when food is available, when the presentation deadline is approaching and anything else that needs sharing. One of the points I make in the event kick-off is that participants should refrain from checking email so they don't get pulled into the normal, daily activity of the business.  Management, from the CEO down, has made the investment in these two days by green-lighting the event - we don't want to squander that opportunity.

Finally, another survey is sent out a few days after the event to ask what went well, what could have gone better and what, if anything, should change.  This is important to inform how we plan the next event.  For example, the change to the presentation format came from a post-event survey.

So...
After running four of these events I believe we've more or less got the process of organizing the event worked out.  The participants, too, seem to be getting the rhythm and sizing their projects to something that can be accomplished in the time frame of the event.  The first few events had teams that were over ambitious and had incomplete projects - which we were OK with as long as they had a good answer to "What did you learn?" :-)

If you're considering organizing an internal hackathon they can be a wonderful opportunity for your team to do a deep dive on some technology, build relationships, and maybe even incubate a new business opportunity.

Free Programming Books

Early in my career I benefited greatly from reading a few books on programming. There were two books in particular that I believe raised the level of what I was doing professionally. First was Steven Feuerstein's Oracle PL/SQL Programming (I think I had the second edition). The other came years later and was Head First Design Patterns by Freeman, Robson, Bates and Sierra.

So I know the benefit of reading programming books - especially when looking for a deep dive on a technology. Which is why I was happy a colleague sent me this link to an index of free programming books on GitHub. It covers a variety of languages and did I mention is free? The link is https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md

No idea if the next book to help me level up as a professional is there, but I'm going to hope so.

Code and slide deck from my April 2014 presentation to VT .NET user group

Last night I presented at the VT .NET on the topic of delegates.  The slide deck and code from my presentation are now available.

• Slides: http://www.slideshare.net/robhalevt/delegation-and-delegates
• Code: https://github.com/robhalevt/20140421_VTdotNET_DelegationAndDelegates 

VT.NET user group 2014-04-21: Delegation and C# delegates from Rob Hale

Javascript Patterns Collection

A co-worker shared this link to a collection of Javascript patterns that is marvelous.  Had to share: http://shichuan.github.io/javascript-patterns/

A realization in advance of VT Code Camp 5

This coming Saturday is our fifth Vermont Code Camp!

Those of us involved in the planning are running around engaged in our last minute preparations to ensure this event will be as successful (or more) than our prior 4 camps.  One of the things we do differently from other code camps is engage the whole tech community in our area.  Most code camps are centered on .NET and other Microsoft platforms - while there are BAR Camps and other events for different technology stacks. But Vermont having such a small population we've found that working with as many of the user groups as we can gets a much more robust set of speakers, exposure to different technologies and a wider sense of community.

So we usually provide a hand out listing the various technology user groups in the area.  Today as I was compiling the list I was struck by how vibrant the Vermont technology scene really is.  Here's the list (sorry for the spoiler VTCC5 campers).  It's a page and a half of groups and events that demonstrate Vermont has it going on!

I'm moving onto the next task to prepare for this weekend - but I'm very happy to be part of such a wonderful community.

Oh, by the way, have you registered for VT Code Camp yet?

Slides from my July 15 presentation to the VT .NET user group

Monday I presented a talk to the VT .NET user group titled "Using the Decorator Design Pattern to Address Cross-Cutting Concerns".  The slides for this presentation are now available on SlideShare at http://ow.ly/n3MxL.  I'm still trying to figure out how to share the source code through that site, though.

Update:

I've uploaded a video of the presentation to YouTube:

Career advice from someone who got lucky

I've got a secret.

It's not a bad secret, I didn't kill a hobo or anything.  

And it's not a particularly well kept secret - lots of folks who know me have heard about it.  

Although I've been a software development professional for nearly 20 years - my degree was in History.

Why am I going public with this confession?  Because one of the things which has happened in the course of my software development career is I'm occasionally hit up for career advice - often from people who have a stronger foundation than I did starting off.  I'm always happy to oblige with whatever meager insights I can offer; but I sometimes feel I need to qualify it with the fact I fell into this career by happenstance.  I'm very glad I did, too, because I've enjoyed myself and had a bit of success in the process.

So when I got an email recently from a member of our local user group asking what skills have helped me my career I thought it would be a good topic to cover as I rediscover my blog.

It's a pretty open ended question when you think about it.  One I would probably better be able to address in a conversation rather than an blog post.  But there are a few things that I can put down which might help him out.
The first thing that I thought of was a post I did several years ago that covers a related topic, staying current.  The post is http://bigpigvt.blogspot.com/2009/01/keeping-current.html.  It's a little dated, obviously, but staying current from a technology standpoint is very important.  One update from the original post, too, is my participation in the user group directly lead to my current job.  The few presentations I did combined with actively asking questions during others' presentations raised my visibility in the local development community.  My current employer knew about me before I knew about them and that gave me an edge in the job hunt.  Local user groups are also a key opportunity to build and maintain your professional network.

Another thing I believe is nothing beats experience.  Getting a programming position if you are not already doing it professionally - after college or during a career change - can be challenging.  You're up against a lot of candidates.  One way to differentiate yourself is to have a history of actually coding.  There's a bit of a chicken and egg issue there, though; how do you get meaningful programming experience if you're not already in a position?  During my tenure as a hiring manager I would advise inexperienced candidates that one approach to that dilemma would be to begin contributing to an open source project.  It will expose you to programming skills and techniques that you won't get from books or many tutorials.  Once your contributions are actually folded into the project you'll be able to cite those contributions to a potential employer.  So go to http://www.codeplex.com/site/search/openings, http://sourceforge.net/people/ or other open source option and get coding!

Finally, what worked for me, and this is definitely because of the non-traditional trajectory my career took, was to be patient and not expect to be programming straight away.  The reason I said I have nearly 20 years as a "software development professional" and not as a "programmer" is because I started out doing customer support for a software company, transitioned to being a software analyst, transitioned to a developer analyst and then finally into a full-fledged programmer.  For me, the process took about 3 years but it was worth it.  My understanding of the software development life cycle is thorough and based on experience.


So now you know my secret.  It's just between us, though, because my other secret is nobody really reads this blog. :-)