Announcing QUnit-Metro!

Leave a reply

As I started learning about writing JavaScript apps for Windows 8, I progressed through a few sample projects and found my way easily.  After all, I’ve been writing HTML and JavaScript for the past 10 years…  this shouldn’t be difficult.  I did however find that my practice of Test Driven Development to be nearly impossible to achieve.  You see, out of the box, Visual Studio 2012 and Windows 8 do NOT provide for unit testing your JavaScript.  However, if you opt to write your app in XAML, unit testing is available.

This was unacceptable, so I went to the drawing board.  I dug up my favorite unit test framework, QUnit and started to work with QUnit to test my sample Windows 8 projects.  Alas, QUnit expects to run in a browser and have full access to the DOM.  For those of you who have not developed a Metro app yet, you will find that DOM manipulation is very hard to do.

So, <TimAllenVoice>I re-wrote it!</TimAllenVoice> I have forked QUnit 1.5 and added some bindings to get it working in the Metro environment.  The result is something that I call “QUnit-Metro”.

By the time this post is published, I will have presented the framework at Tech Ed 2012’s Speaker Idol competition.  This is a very exciting time for me, as I have never presented at Tech Ed before.  Sure, I’ve done Code Camps and local user groups, but never anything of the size of Tech Ed. My hands are trembling with excitement as I type this post from the conference floor, mere hours before the competition starts.

I will post screenshots, a starter tutorial, and a quick screencast showing the framework over the next day or two.  For now, check out QUnit-Metro at:

http://bit.ly/QUnitMetro

Thanks for reading…. and I’ll update you with more Metro and Unit testing goodness over the next few months.

Stop that Build! Don’t waste time building projects in Visual Studio

Leave a reply

Some time ago, I ran across this conundrum:  Why does Visual Studio continue to build projects when a dependent project failed to compile?

So, I took it upon myself to figure out how to stop the Visual Studio compiler from building projects unnecessarily.  That is:  stop building immediately after it encounters an error.

My solution took the form of a Visual Studio macro.  

  For the uninitiated: that means writing some Visual Basic code to manage the IDE.  

  For the initiated:  You can cringe with me…  😛

So, I opened the Visual Studio Macros IDE and attached an event handler to the BuildEvents object in the EnvironmentEvents module with the following code snippet:

    Private Sub BuildEvents_OnBuildProjConfigDone(ByVal Project As String, ByVal ProjectConfig As String, ByVal Platform As String, ByVal SolutionConfig As String, ByVal Success As Boolean) Handles BuildEvents.OnBuildProjConfigDone

        '-- When the build of a project fails
        If (Not Success) Then

            '-- Cancel the remaining builds in the Solution
            DTE.ExecuteCommand("Build.Cancel")

            '-- Write a polite message to the OutputWindow that's logging all information about this build
            DTE.ToolWindows.OutputWindow.ActivePane.OutputString(vbCrLf & vbCrLf & "Build failed while compiling " & Project)

        End If

    End Sub

Pretty simple, and prevents Visual Studio from running through all of the projects.

Next time, I’m going to attach a timer and start recording my build times to see how the solution has grown.

How to put NuGet in your DVCS

Leave a reply

Something I struggled with some time ago was what appeared to be a conflict of rules.  Consider the Joel Test, where rule #2 states:

Can you make a build in one step?

In order to accomplish this, most developers place copies of any library dependencies into their source control.  With the advent of NuGet, this seems even easier:  just push copies of your nuget generated packages folder into source control as well.

However, in today’s world of distributed version control systems (DVCS) like git and Mercurial it is strongly discouraged that you place binaries into the repository.  This leads to an impasse.  How do we allow a 1 step build, while keeping NuGet out of the repository.

I solved this problem for my team by writing a simple batch file and adding the command-line nuget.exe to the root of my solution folder. 

I added ignore statements for my packages folder, but added the repositories.config file to the git repository.   My .gitignore looks something like this:

I then built a simple batch script to assist in reloading the nuget packages for my solution.  The batch file looks similar to the following:

 1: nuget install Fritz.TomatoTasks.Webpackages.config -OutputDirectory packages
 2: nuget install Fritz.TomatoTasks.Web.Testpackages.config -OutputDirectory packages
 3: pause

To note:  the INSTALL command asks nuget to grab the versions of packages specified in the packages.config files from the nuget repository and install them.  The -OutputDirectory switch specifies that the files are to be written into the standard packages folder.

Each time I add a project to the solution, I copy and paste a line into this file.  This prevents us from having to worry about the storage of binaries, and we can add a command to our continuous integration server’s script to call this file in order to rebuild the solution from source control.

Do you have a way to improve my process?  Let me know in the comments below or on Twitter at:  @csharpfritz

Only 7 lines of code please

Leave a reply

I ran across this question at Programmers.StackExchange discussing a coding guideline that states “Methods should not exceed 7 statements”.  I find these types of guidelines and the reactions to them quite amusing.

Let’s not forget the SOLID modeling principles before I begin to ramble.  Go ahead and review them for a minute.  I’ll wait…

Got it?  ok…  Programming Guidelines are written by Alpha Geeks for more intermediate and junior coders.  A rule like this one is set forth to force the uninitiated to think about how they can break down their objects and methods into much smaller, re-usable chunks.

 Consider this:  if the junior developers on your team are writing methods with 7 lines of code or less, you’re reducing the chances they’ll publish code with high cyclomatic complexity.  You’re project should end up with much simpler, less complex code just because of this rule.

Senior developers and architects who write boiler-plate code may violate this rule.  If you know WHY this rule is in place, then you know the hows, whens, and wheres about violating the 7 lines of code rule.  Those individuals are thinking about keeping complexity metrics down, and code coverage high.

Should you be writing 7 line methods?  A quick glance through one of my personal projects and the only ‘large’ methods I find are in unit tests…  and I’m okay with those.

Try using this rule for a week and see how it forces you to craft your code.  You might be surprised what you get.

Scrum Practice: The 15:5 doc

Leave a reply

As my role within our scrum project team has evolved into a lead developer, I find myself in more and more design and collaboration tasks with my developer teammates.  I was initially going through oral and white board design sessions with my team to convey how the technical design for the sprint was evolving.

However, our team has grown to 5 developers (including myself), 2 QA analysts, a product owner and our scrum master. I’ve found that my verbal communication approach is simply taking too much time away from coding.  In discussion with my director and our scrum trainer, we settled on a practice called the “15:5 document”.  I have not found discussion of this technique on the web, and will share what I have found over the past week of using this approach.

The 15:5 document receives its name because it takes 15 minutes to write, and only 5 minutes to understand.  This document is a complementary document to the User Story, and I store them as an attachment to the User Story in Team Foundation System (TFS).  This isn’t a full-blown design document, but more of a place-setting.  It is the springboard of tribal knowledge a developer needs in order to get about 40-50% into the design of a user story’s tasks.  The remainder of the design is confirmed through periodic code-reviews when builds are pushed.

Typically, I load the document with:

  • An entity-relationship diagram from Visio or a photo of one scrawled on a whiteboard
  • Some bullet points describing the diagram
  • A sample database table design if necessary
  • A scribbled wire-frame of what the UI may look like

I was thinking of putting together an MSWord template for this type of document, but these 3 sections seem too easy to simply build out as I write out my designs.

Give it a shot…  I’d appreciate any feedback or options of other scrum design practices.  You should see more scrum flavored posts in the coming weeks as I adjust to this role.