Just Some Excel Helpers and Respective Unit Tests

Just some semi-elegant stuff I’ve conjured up recently to get column names in Excel and do some other functional things.  I wrote this code in a true TDD fashion.  It still, for some reason, seems odd to me to write tests in VB, since it was always a language that encouraged dirtiness.  But alas, this is fairly solid stuff.

Imports NUnit.Framework

<TestFixture()> _
Public Class HelperTests
    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnLetterSingleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(3)
        Assert.AreEqual(theLetter, "C")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnLetterDoubleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(29)
        Assert.AreEqual(theLetter, "AC")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnDoubleLetterThirdAlphabet()
        Dim theLetter As String = Helper.GetExcelColumnLetter(56)
        Assert.AreEqual(theLetter, "BD")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
   Public Sub TestHelperGetExcelColumnTripleLetter()
        Dim theLetter As String = Helper.GetExcelColumnLetter(2356)
        Assert.AreEqual(theLetter, "CLP")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnTripleLetterSomething()
        Dim theLetter As String = Helper.GetExcelColumnLetter(14999)
        Assert.AreEqual(theLetter, "VDW")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
        Public Sub TestHelperGetExcelColumnTripleLetterTheEndOfZzz()
        Dim theLetter As String = Helper.GetExcelColumnLetter(18278)
        Assert.AreEqual(theLetter, "ZZZ")
    End Sub

    <Test()> <Category("Presenter Helper Tests")> _
    Public Sub TestHelperGetExcelColumnF1C1()
        Dim theColumnF1C1 As String = Helper.GetExcelColumnF1C1(3, 6)
        Assert.AreEqual("C:F", theColumnF1C1)
    End Sub

End Class

I churned out each of these tests, the first few I did at one time, counting out where the column “letters” would be derived at various column numbers.  It almost got confusing a few times.  All tests of course went red and I began coding the innards of the method.

What I came up with, after a few gotchas here and there is this.

Public Class Helper
    ''' <summary>
    ''' This method gets the appropriate "A" thru "ZZZ" column header for Excel based
    ''' on a passed in long data type.
    ''' </summary>
    ''' <param name="colNum">Pass in a long type to derive the appropriate column header letter.</param>
    ''' <returns>A string of the appropriate "A" thru "ZZZ" header letter.</returns>
    Public Shared Function GetExcelColumnLetter(ByVal colNum As Long) As String
        Do
            GetExcelColumnLetter = Chr(65 + (colNum - 1) Mod 26) & GetExcelColumnLetter
            colNum = (colNum - 1) \ 26
        Loop While colNum > 0
    End Function

    ''' <summary>
    ''' This method returns the ("A:ZZZ") part of the Range("A:ZZZ") column interface.
    ''' </summary>
    ''' <param name="firstColumn">Enter the first column to start the range with.</param>
    ''' <param name="secondColumn">Enter the second column to end the range with.</param>
    ''' <returns>A string formatted as A:ZZZ is returned from this method.</returns>
    Public Shared Function GetExcelColumnF1C1(ByVal firstColumn As String, ByVal secondColumn As String) As String
        Return GetExcelColumnLetter(firstColumn) + ":" + GetExcelColumnLetter(secondColumn)
    End Function
End Class

If you work with Excel frequently you know all about F1C1, which I decided to stick on the end of the GetExcelColumnF1C1.  Not sure if it really makes sense, but since so much of Excel is kind of just mess, I figured it might conjure the right thought in a coder’s mind.

kick it on DotNetKicks.com

Technorati Tags: Office 2007,Office,Excel,VB,TDD,Unit Test

del.icio.us Tags: Office 2007,Office,Excel,VB,TDD,Unit Test

User Stories

The mumbo jumbo of use case, requirements gathering, and all that are a necessary evil of software design.  We developers cannot unfortunately just haphazardly build our UIs and other such things.  It is necessary that in some way the user interface is dictated by the users.

In the past, especially with waterfall, this has been a massive failure point for companies having software built.  The UI not reflecting actual use or features of what was actually needed (vs. what is asked for, because we all know that what is asked for usually isn’t really what someone wants).  To get to what someone actually wants and needs takes multiple sessions of sitting and going through the UI.  This of course entails all the underpinning architecture and functionality too.

The crux of all this is it eats up valuable developer time, which is why the solution in the past was always to put people in between the developers and the users.  However, that just means there is another communication failure point between the user and the developers.  Major problem…

Enter, User Stories.

User stories in the agile, sometimes eXtreme Agile sense, provide an alternative way to get specifications and requirements without the customer shooting themselves in the foot.  It has been documented so many times the customer either goes beyond or doesn’t provide even close to what they should in the requirements and causes development to slow to a minimum speed.  Sometimes development functionally stops while developers “thrash” and struggle to find day to day tasks.  This effectively kills a project.  I myself have seen entire projects, with burn rates in excess of a quarter million dollars (yeah, that’s $250,000) a month effectively not achieve a single tangible task because of faulty and ill planned requirements.

User stories are simple, so simple that they almost cause a customer to make the application request what it should be, simple!  A simple application is by far the most useful application for a user.  The second things get complicated it is usually because of ill planned requirements that state too much or too little in the way of what is actually needed.

A user story goes something like this, “A user can create a document to provide a customer bill.”  The story doesn’t tell a developer what type of document it needs to be.  The story doesn’t tell a developer that it needs put in a particular place or put into a bit stream or anything in an implementation sense.  The story simply states what the user needs to do to perform a business need.

The user story is something that should be able to be placed on a brochure or pamphlet as a selling point of the application.  If it is something you wouldn’t put in a document like that, it is highly likely that you’ve either given too much or too little information in the user story.

Some specifics about user stories, and identifying a good story versus a bad or unusable story is that they must be;  independent, negotiable, valuable to the customer, small, and very important to the developer, it must be testable.

I run into a little problem with project managers, scrum leads, or whoever taking these and estimating schedule times based off of these things, but some very well respected agile proponents suggest that a user story must also be estimatable (which is not a word really, so maybe it is just a joke).  I assume that they intend to schedule and estimate a project plan of some sort with user stories.  This can be done, but a team should not be dictated a strict schedule based entirely off of user stories.  In a very Six Sigma, Lean, Agile way estimates at this level are still NOT measurable with a high level of accuracy, there is still a double digit percentile of risk involved that must be mitigated if planning is done at this level.

But I digress, back to the user stories…

Beyond the Written User Story

Beyond the basic user story there are other elements of what has to be done.  The most important part, more so than even writing down the user stories, is to communicate the user story.

During the iteration the team must get these stories and organize them in a way to have current work, backlog, and done.  Each of these unto itself is worth an article each, but I’ll continue on with user stories.  Keep in mind though that each of these points is very specific in the use of user stories.

The Gurus

For more information check out InfoQ for some decent articles.  For the master of user stories check out Mike Cohn over at Mountain Goat Software.  Mike has an article titled “Advantages of User Stories for Requirements” which is a must read!

So get your user stories together, or fail.  Stick out tongue [:P]

Technorati Tags: Agile,Project,Software,Planning,User Story

del.icio.us Tags: Agile,Project,Software,Planning,User Story

Brutal Week

Some weeks just suck.  From the first minutes ticking away on a Monday one can see these types of weeks coming.  When just absurd off the wall stuff starts to break.  Next the complex things break that have easy solutions, just that no one has ever seen the breakages to know the solutions.

My last week was like that.  Having just returned from the Oregon Brewer’s Festival I sure hope that this week is an improvement in smooth flow.  I have big plans for this week.  First off there are major functional pieces I need to get done ASAP.  I’m on a good course, even after losing 3 plus days last week to interruptions (build issues, breakages, code problems, visual studio problems – you name it, it happened).  On Thursday I have a brown bag on the PIAB, which at this point I’m not prepared to the level I’d like.  I still need a few more demo examples and such.  Then on Friday I want to fully begin implementation of the PIAB into our architecture.  Overall, a rather big week of things to do.  In addition I’m going to be packing and preparing to move from one end of town to the other.

…I tell ya, never nothing to do.

Slashdot Quote

Someone was saying something about not seeing IT jobs in the help wanted section of the newspaper.  In response someone wrote, and I quote,

“Employers don’t really expect IT people to be looking at dead tree medium for jobs.”

Seriously, if you’re in IT and you’re digging through the newspaper, you’re doing the industry and especially yourself a disservice.

I had to post this, as I love the “dead tree medium” reference.

Why Refactor?

This is why one writes unit tests and refactors.  Re: line # 13:47

[13:39] Jabley: I reverted the last change I made and it is still broke. Grrr!

[13:45] Adron: ok

[13:45] Jabley: I am just trying to figure out how the f*** to salvage this.

[13:45] Adron: kewl.

[13:45] Adron: not sure what kind of advice for that situation.

[13:45] Jabley: I desperately need to refactor my code

[13:45] Adron: I just punish myself and write it over if I fail on such a grand scale…

[13:45] Jabley: There isn’t any

[13:45] Adron: and refactor a ton…

[13:45] Adron: prevents the situation from happening.

[13:45] Jabley: Thats what I am considering

[13:45] Adron: …at least mostly prevents it.

[13:46] Jabley: I know what I did wrong but I can’t figure out how to make it write in the current app without a full rewrite. That full rewrite would be a ton better because I can refactor the code, which it needs, and start it correctly with UTs

[13:46] Jabley: write = right

[13:47] Jabley: Jeez I want to kick myself in the balls right now

[13:52] Adron: ouch.

So live and learn, WRITE UNIT TESTS AND REFACTOR, the alternatives are painful.  Big Smile [:D]

Technorati Tags: Refactor

del.icio.us Tags: Refactor