jQuery 101 UG Samples and Slides


Here is the slide deck and sample code from my jQuery 101 user group talks this week.Thanks you to everyone that attended my user group chats this week.

jQuery 101 Slide Deck

jQuery 101 Sample Code

Posted in Uncategorized | 1 Comment

Come Learn jQuery

After a brief stop in Houston for the Alt Net Houston Open Space and another brief stop in Seattle for Emerald City ComicCon I will begin my trek north for another Canadian user group tour.

Topic: Using jQuery with ASP.NET

Web 2.0 is here to stay. jQuery is a JavaScript library that abstracts away all of the gory details of working with JavaScript for web applications. This session will demonstrate how to add jQuery to your ASP.NET applications today. This session will focus on proper uses of jQuery including how to organize your JavaScript code, how to use selectors in jQuery and how to manipulate your web content dynamically. Along with uses of the standard jQuery library, time will also be spent exploring some of the most useful jQuery plugs-ins.

I will be at the following user groups

April 6th .Net User Group of British Columbia (Vancouver BC)

April 7th Edmonton .NET User Group

April 8th Regina .NET User Group

April 9th Winnipeg .NET User Group

I am looking forward to seeing old friends and making new ones on this tour. Hope to see you there!

Posted in Uncategorized | 4 Comments

Underscoring A Point

This last week I took a great class on TDD and BDD given by Scott Bellware. During  the session   he showed us a cool tool called AutoHotKey. AutoHotKey is a tool that allows you to control your keyboard behaviors. For instance you can use AutoHotKey to substitute the underscore character for a space when typing in a test name

I had a discussion with my co-worker Greg Lawrence about using underscores vs.  CamelCase for our test naming conventions. I have always liked underscores in test names. Test names are like sentences and should be read as such. To drive this point home (and to demonstrate it for an underscore bigot :) I present the following:

Original Test

We hold these truths to be self-evident, that all men are created equal,
that they are endowed by their Creator with certain unalienable Rights, that among these are Life, Liberty and the pursuit of Happiness.





BDD CamelCase Notation


  • ShouldIncludeLife
  • ShouldIncludeLiberty
  • ShouldIncludeHappiness

BDD Notation (Underscored)


  • Should_Include_Life
  • Should_Include_Liberty
  • Should_Include_Happiness

As is self evident (pun intended) the underscored version is much easier to understand and read.  When you generate documentation from your BDD specs which one make more sense? Which will is easier to use by your customers? Which ones can you substitute underscores for spaces when printing documentation? Its pretty obvious which one to choose.

Just a small thought on this march morning.

Posted in Uncategorized | 10 Comments

What’s in a Job Title

One of the most frequently asked for attributes on a credit or job application is Job Title. As an independent business owner I have answered this question in multiple ways:

  • Programmer
  • Software Developer
  • Software Engineer
  • Architect
  • CTO
  • Coder
  • President
  • Jedi Master
  • Etc…

The scary thing about this is there is no real way for a potential employer,  banker or client to certify what I say is legit. This is a fundamental issue with our industry. There is no way to verify whether a person is a quality software engineer or simply a charlatan. And for the record there are more of the latter than the former.

For the most part programmers like to think of software development as engineering. We like to compare ourselves to engineers with a capital E, construction managers, manufacturing process managers, etc. But do we really practice engineering ? What is the bar for calling yourself a software engineer?

I know for a fact that if I need an expert licensed plumber, electrician or ironworker I can take myself down to the local union hall and find someone that has gone from apprentice to journeyman over the course of many years.  And thanks to my friend Eric Anderson I learned that there is such a thing as a Professional Engineer. Here’s the list of requirements for Professional Engineers as taken from the Wikipedia

  1. Graduate with a degree from an accredited four-year university program in engineering.
  2. Complete a standard Fundamentals of Engineering (FE) written examination, which tests applicants on breadth of understanding of basic engineering principles, and optionally some elements of an engineering specialty. Completion of the first two steps typically qualifies for certification in the U.S. as an Engineer-In-Training (EIT), sometimes also called an Engineer Intern (EI).[5]
  3. Accumulate a certain amount of engineering experience under the supervision of a P.E. In most states the requirement is four years, but in others the requirement is lower.
  4. Complete a written Principles and Practice in Engineering (‘PE’) examination, testing the applicant’s knowledge and skills in a chosen engineering discipline (mechanical, electrical, civil, for example), as well as engineering ethics.

For software engineering there is no similar accreditation process. Any Mort i.e (NOOB) with $500.00 and the ability to hit the keyboard with his/her forehead  can become a software engineer overnight.  "Yesterday I couldn’t spell it. Now I are one". This has got to stop.

A few weeks ago I came across a commentary made by my friend Billy Hollis in Visual Studio Magazine Commentary: Is Agile Rock or Disco. In this commentary Billy mentions the following:

The Patterns and Practices group at Microsoft is heavily into agile development. Don Smith is in that group, and, at a conference last May, he said, "It’s hard to do agile without really good developers." I’ve heard variations of the same thing said from others.

But not all developers are that good. Therefore, if Don is right, then agile isn’t for everyone.

The second statement is the core problem we face. It raises the white flag of surrender to all the half ass coders out there. Why shouldn’t we all strive to be good developers? Why is average acceptable? What does the author propose we do with the average programmer?

Because programmers are less than good (LTG) does he propose we have no process whatsoever? It’s because of these LTG developers we need agile practices more not less. I want to point out something carefully at this point. It’s agile practices… not agile! There is no push button template  you can use and whoosh you are an agile coder or development shop. Nope agile is a set of principles and practices.

Adopting agile principles is not quick or easy. It is a lifetime commitment that takes lots of study, practice, mentoring, and continuous education and improvement. There are lots of new terms, concepts and practices to examine, consider and implement. Every company and situation is different and there are a number of useful practices to adopt.

Agile Adoption

In the last year we have moves very heavily from our old RAD way of doing development to a more agile one.  Our goal in this process was to change how we design and develop software in a quality manner. These are the tools and practices we have adopted.

Shared State Source Control

The first practice we adopted was changing from a pessimistic style of source code control into a shared state source code control system. It made no sense to limit a source code file to a single developer (the default behavior of Visual Sourcesafe). We moved to Subversion. Subversion is an industry standard source code control system that’s default behavior is multiple developers working on the same files and merging conflicts. 

Automated Builds

Another principle of agile we have adopted is that of automated builds. Another terms for this is Continuous Integration.  Whenever source code is committed to our repository an automated build fires off, checks out all the code, compiles it and runs a suite of automated tests.  Our goal is to find whether or not our code is in a Red (bad) state or Green (good) state. 

Test Driven Development and Design

Of all practices in agile I find this one to provide the most value.  Any software you build should be accompanied by a suite of tests to verify its long term quality and  integrity.  The ultimate goal of TDD is a good design.  While test driven development does not insure a good design your chances are better that your designs are more sound if they can be tested in an automated way.

I had a conversation with Scott Bellware and Chad Myers last night. We were discussing testing nomenclatures and Chad Developed this list of test types:

  • Proofs  – Code performs as expected.
  • Examples of Client Access (API testing) – API Proving with tests.
  • Specification (BDD) – Documenting intent.
  • Contract Enforcement/Change Confidence – Regression testing

As you can see these nomenclatures provide you with a confidence that your code will work as expected, has its intent documented and allows for long term changeability inherent in all software development.

Pair Programming and Mentoring

Union plumbers and electricians go through extensive apprenticeships before they are accepted  as journeymen. Software engineers should adopt similar practices. Pair programming facilitates knowledge transfer from master to apprentice,  mentor to student and in lots of cases from student to mentor. In the last year I have spent a lot of time discussing these practices with a number of different people I consider my mentors. My mentor list includes Scott Bellware, Jeremy Miller, Chad Myers, Jeffery Palermo and numerous others. These practices are not always obvious or simple so it is a good idea to have a network of mentors to rely on.

Adoption of Dependency Patterns

One aspect of building testable systems is reduction of  development friction. One way to introduce friction is to tightly couple processes together by allowing them to instantiate there own resources internally.  It may seem strange  but information hiding is not necessarily a good practice in the agile space. The concept behind dependency injection is this: if a component or method has a dependency on another class, then  that dependency should be passed (injected) into the consumer.  This give you untold flexibility when it  comes to configuring and reconfiguring your systems.

Daily Stand Ups

In agile development a common set of practices revolve around daily developer meetings also known as stand ups. Every day developers stand in a circle, stands at there desks or in the hallway and talk about two items:  what the did yesterday and what they plan on doing today. This  has the benefit of keeping all  developers in the loop and facilitating communication.

Small Iterations

We all know that estimating timelines on most software projects is a fools errand.  Software estimates follow share a common trait with metrological predictions the shorter the span or time the more accurate the estimate is likely to be. Agile practices acknowledge this as a core principle.  Your applications should be developed in short sprints.  At the end of each sprint there should be "show and tell" for the client that demonstrates the deliverables for that sprint. After the sprint and accompanying demo the next sprint should be planned. And its rinse lather repeat from there.


While not definitive this list is a good start to moving you or your development team closer to being professional software engineers. When you are evaluating a client, consultancy or even a potential employer consider the practices discussed in the list. 

Do you think your a great coder or do you think your development shop is top notch? I challenge you to prove it. Can you develop quality software that stands the test of time ? Do you have software you can modify with a high level of confidence that your modifications don’t introduce software regressions? Can you repeat and improve on your successes? Do you have the processes in place that make this a possibility? When you can answer in the affirmative to some or all  of these questions you are closer to being a true software engineering shop.

Posted in Agile, TDD | 16 Comments

Twitter Conversations : First Refactoring

Thanks for the feedback and encouragement so far. This project has been fun and I hope you keep enjoying it so far.

Refactoring Required

I knew going in that the first cut of this application needed some serious refactoring. The project had dependencies on internet connections , numerous classes contained redundant code and the user interface was lacking. In this first set of refactorings I hope to demonstrate how you can design your applications to be more testable and how to make the code cleaner at the same time. I will also attempt to make the UI better with my feeble UI skills.

First Refactoring: Extracting Interfaces

The first cut of the Twitter Conversations application took a dependency on being connected to the Internet for testing. In order to remove this dependency I decided to extract the an interface from the Twitter.Communications.TwitterRequest class. This process is simple  when using a tool like ReSharper. I simply opened the class source code file, Right Clicked, Selected Refactor->Extract Interface from the popup menu. The following screen shows the Extract Interface dialog from ReSharper.


This process yielded the following interface

   1: Public interface ITwitterRequest
   2:     Function GetTwitterRequest(ByVal URL As String) As String
   3: end interface

After refactoring the interface from the Twitter.Communication.TwitterRequest class I created a new Twitter.Interfaces project. This project would all interfaces for this project including another new interface ITwitterCredentials. I created the ITwitterCredentials interface in order to provide a slightly cleaner design for creating instances of the TwitterRequest class.

   1: Public Interface ITwitterCredential
   2:     Property UserName() As String
   3:     Property Password() As String
   4: End Interface

Once I created the ITwitterCredentials interface I implemented it on a new class Twitter.Communication.TwitterCredentials. I also needed to refactor the guts of the TwitterRequest class. The new code for this class now looks like:

   1: Public Class TwitterRequest
   2:     Implements Twitter.Interfaces.ITwitterRequest
   3:     Private _Credentials As Twitter.Interfaces.ITwitterCredential
   5:     Sub New(ByVal Credentials As Twitter.Interfaces.ITwitterCredential)
   6:         Me._Credentials = Credentials
   7:     End Sub
   9:     Public Function GetTwitterRequest(ByVal URL As String) As String Implements Twitter.Interfaces.ITwitterRequest.GetTwitterRequest
  10:         Dim Credentials As New NetworkCredential(Me._Credentials.UserName, Me._Credentials.Password)
  12:         Dim Request As HttpWebRequest = HttpWebRequest.Create(URL)
  13:         Request.Method = “POST”
  14:         Request.Credentials = Credentials
  16:         Dim Response As WebResponse = Request.GetResponse
  17:         Dim Reader As New StreamReader(Response.GetResponseStream)
  18:         Dim Results As String = Reader.ReadToEnd
  19:         Return Results
  21:     End Function
  22: End Class

After extracting these interfaces I changed the constructors for Twitter.API.User and Twitter.Message.API to receive an ITwitterRequest rather than a concrete class.The following code demonstrates the constructor for the Twitter.API.User class.

   1: Public Class User
   3:     Dim Communicator As Twitter.Interfaces.ITwitterRequest = Nothing
   4:     Dim JsonSerializer As New System.Web.Script.Serialization.JavaScriptSerializer
   6:     Sub New(ByVal TwitterCommunicator As Twitter.Interfaces.ITwitterRequest)
   7:         Me.Communicator = TwitterCommunicator
   8:     End Sub

Of course at this point all of our tests were broken but I waited to do a little more refactoring before fixing the tests.

Second Refactoring: Creating the Disconnected Twitter Service

The next step in the process was to create a disconnected version of Twitter. To accomplish this I took the following steps:

  1. Extracted JSON strings from the various calls to Twitter and put them into our testing project as embedded resource files.

  2. Added code to the testing project that could be used to extract the embedded text files

  3. Implemented the ITwitterRequest interface on a new class called TwitterRequestMock.

  4. Implemented the function GetTwitterRequest to return the appropriate text resource based on the URL.

The first item on the list was to extract the JSON data from actual calls to Twitter. To satisfy the unit tests I created three file extracts:

  • singleuser.txt  – Contains the information for my user account

  • friends.txt – A list of people I follow

  • messages.txt – A list of twitter updates

All three of these files were marked as Embedded Resource files in the Visual Studio project.

The next step was to add code that would allow these files to be extracted from the testing assembly. the following code extracts resources from the currently running assembly (i.e. our unit tests)

   1: Imports System.IO
   2: Imports System.Reflection
   4: Public Class ObjectMother
   5:     Public Shared Function GetEmbeddedResource(ByVal ResourceName As String) As String
   6:         Dim ResStream As Stream = System.Reflection.Assembly.GetExecutingAssembly.GetManifestResourceStream(ResourceName)
   7:         Dim oStreamReader As New StreamReader(ResStream)
   8:         Dim RetVal As String = oStreamReader.ReadToEnd
   9:         Return RetVal
  10:     End Function
  11: End Class

Finally a new class TwitterRequestMock was created. The purpose of this class was to return the proper embedded resource files based on the URL passed to a request. The following code demonstrates the implementation of this:

   1: Public Class TwitterRequestMock
   2:     Implements Twitter.Interfaces.ITwitterRequest
   4:     Private _Credentials As Twitter.Interfaces.ITwitterCredential
   6:     Sub New(ByVal Credentials As Twitter.Interfaces.ITwitterCredential)
   7:         Me._Credentials = Credentials
   8:     End Sub
  10:     Public Function GetTwitterRequest(ByVal URL As String) As String Implements Interfaces.ITwitterRequest.GetTwitterRequest
  11:         Dim ReturnValue As String = “”
  13:         ‘– urls we use so far
  14:         ‘Const UserMessageURL As String = “http://twitter.com/statuses/user_timeline/<<USERID>>.json”
  15:         ‘Const MyMessagesURL As String = “http://twitter.com/statuses/friends_timeline.json?count=200″
  16:         ‘Const FriendsURL As String = “http://twitter.com/statuses/friends.json”
  17:         ‘Const GetUserURL As String = “http://twitter.com/users/show/<<USERID>>.json”
  18:         ‘Const CredentialURL As String = “http://twitter.com/account/verify_credentials.json”
  20:         If URL.Contains(“verify_credentials”) OrElse URL.Contains(“users/show/”) Then
  21:             ReturnValue = ObjectMother.GetEmbeddedResource(“Twitter.UnitTests.singleuser.txt”)
  22:         ElseIf URL.Contains(“friends_timeline”) OrElse URL.Contains(“user_timeline”) Then
  23:             ReturnValue = ObjectMother.GetEmbeddedResource(“Twitter.UnitTests.messages.txt”)
  24:         ElseIf URL.Contains(“friends.json”) Then
  25:             ReturnValue = ObjectMother.GetEmbeddedResource(“Twitter.UnitTests.friends.txt”)
  26:         End If
  28:         Return ReturnValue
  29:     End Function
  30: End Class

I discussed this method with Jeremy Miller and his comment was if possible the text for the JSON strings should be embedded into the unit test if at all possible. I didn’t follow this recommendation because the JSON returns strings are long and very ugly. What are your thoughts on this ?

Third Refactoring: Fixing the Unit Tests

Once this class was implemented I went in and fixed up the unit tests. This was actually pretty simple. Basically I refactored the constructor and <Setup()> of the UnitTests class.

   1: <TestFixture()> _
   2: Public Class UnitTests
   4:     Dim UserAPI As Twitter.API.User = Nothing
   5:     Dim MessageAPI As Twitter.API.Message = Nothing
   6:     Dim Communicator As Twitter.Interfaces.ITwitterRequest = Nothing
   8:     <SetUp()> _
   9:     Sub Setup()
  10:         Me.Communicator = New TwitterRequestMock(New Twitter.Communication.TwitterCredentials)
  12:         Me.UserAPI = New Twitter.API.User(Me.Communicator)
  13:         Me.MessageAPI = New Twitter.API.Message(Me.Communicator)
  14:     End Sub


Now the tests for this application can be run in a disconnected mode.

Fourth Refactoring: Removing Redundant Code

The next step in this refactoring process was to clean up redundant code from the Twitter.API.User and Twitter.API.Message classes. In the first version each method was responsible for parsing data and creating collections of Messages and Users. The code started like the following snippet:

   1: Function GetUserMessages(ByVal UserID As String) As Twitter.Domain.Message()
   2:     Dim ReturnMessages As New List(Of Twitter.Domain.Message)
   4:     Dim UserObjects As Object = JsonSerializer.DeserializeObject(Me.Communicator.GetTwitterRequest(UserMessageURL.Replace(“<<USERID>>”, UserID)))
   6:     For Each UserObject As Object In CType(UserObjects, Array)
   7:         ReturnMessages.Add(New Twitter.Domain.Message With { _
   8:                            .MessageID = UserObject(“id”), _
   9:                            .MessageDate = UserObject(“created_at”), _
  10:                            .MessageContent = UserObject(“text”), _
  11:                            .UserID = UserObject(“user”)(“id”), _
  12:                            .UserName = UserObject(“user”)(“name”), _
  13:                            .ImageURL = UserObject(“user”)(“profile_image_url”)})
  14:     Next
  15:     Return ReturnMessages.ToArray
  17: End Function

The redundant code is the code contained in the For loop. I decided to extract this code into its own method.

   1: Sub PopulateMessages(ByVal ListToPopulate As List(Of Twitter.Domain.Message), ByVal Contents As Object)
   2:         For Each UserObject As Object In CType(Contents, Array)
   3:             ListToPopulate.Add(New Twitter.Domain.Message With { _
   4:                                .MessageID = UserObject(“id”), _
   5:                                .MessageDate = UserObject(“created_at”), _
   6:                                .MessageContent = UserObject(“text”), _
   7:                                .UserID = UserObject(“user”)(“id”), _
   8:                                .UserName = UserObject(“user”)(“name”), _
   9:                                .ImageURL = UserObject(“user”)(“profile_image_url”)})
  11:         Next
  12:     End Sub

Now the code for parsing off message looks like this:

   1: Function GetUserMessages(ByVal UserID As String) As Twitter.Domain.Message()
   2:     Dim ReturnMessages As New List(Of Twitter.Domain.Message)
   3:     Dim UserObjects As Object = JsonSerializer.DeserializeObject(Me.Communicator.GetTwitterRequest(UserMessageURL.Replace(“<<USERID>>”, UserID)))
   4:     Me.PopulateMessages(ReturnMessages, UserObjects)
   5:     Return ReturnMessages.ToArray
   6: End Function

The Twitter.API.User Class is had a slightly different refactoring. Because this API returns a lot of single user information it was necessary to create a function to return a single user object. When a method returned multiople user records a looping structure similar to the one for messages was used.

   1: Public Function GetUsers() As Twitter.Domain.User()
   2:     Dim Users As New List(Of Twitter.Domain.User)
   3:     Dim UserObjects As Object = JsonSerializer.DeserializeObject(Me.Communicator.GetTwitterRequest(FriendsURL))
   4:     Me.PopulateUsers(Users, UserObjects)
   5:     Return Users.ToArray
   6: End Function
   8: Public Function GetUser(ByVal id As String) As Twitter.Domain.User
   9:     Dim Users As New List(Of Twitter.Domain.User)
  10:     Dim UserObject As Object = JsonSerializer.DeserializeObject(Me.Communicator.GetTwitterRequest(GetUserURL.Replace(“<<USERID>>”, id.ToString)))
  11:     Return Me.GetUserFromObject(UserObject)
  12: End Function
  13: Public Function GetMyUser() As Twitter.Domain.User
  14:     Dim UserObject As Object = JsonSerializer.DeserializeObject(Me.Communicator.GetTwitterRequest(CredentialURL))
  15:     Return Me.GetUserFromObject(UserObject)
  16: End Function
  17: Function GetUserFromObject(ByVal UserObject As Object) As Twitter.Domain.User
  18:     Return New Twitter.Domain.User With { _
  19:       .UserID = UserObject(“id”), _
  20:       .UserName = UserObject(“name”), _
  21:       .ScreenName = UserObject(“screen_name”), _
  22:       .ImageURL = UserObject(“profile_image_url”), _
  23:       .Followers = UserObject(“followers_count”)}
  24: End Function
  25: Sub PopulateUsers(ByVal ListToPopulate As List(Of Twitter.Domain.User), ByVal Contents As Object)
  26:     For Each UserObject As Object In CType(Contents, Array)
  27:         ListToPopulate.Add(Me.GetUserFromObject(UserObject))
  28:     Next
  29: End Sub

The nice thing about these refactoring is that when a new property is added to a domain object you only need to change the code in one place.

Fourth Refactoring: The WPF Interface

The final refactoring I added was to implement a slightly improved interface.  This basically consisted of changing the code that calls the Twitter API’s we write and adding three user interface elements. The elements added to the screen consisted of two fields for capturing username and password respectively and a new display element for the showing the Twitter users image. The VB code and XAML code now looks like this:

   1: Private Sub cmdGetThread_Click(ByVal sender As Object, ByVal e As System.Windows.RoutedEventArgs) Handles cmdGetThread.Click
   2:     Dim Communicator As Twitter.Interfaces.ITwitterRequest = New Twitter.Communication.TwitterRequest(New Twitter.Communication.TwitterCredentials With {.UserName = Me.txtUserName.Text, .Password = Me.txtPassword.Password})
   3:     Me.lstResults.ItemsSource = Me.LoadConversation(New Twitter.API.Message(Communicator), New Twitter.API.User(Communicator), Me.txtCriteria.Text)
   4: End Sub
   7: Function LoadConversation(ByVal MessageAPI As Twitter.API.Message, ByVal UserAPI As Twitter.API.User, ByVal TextCriteria As String) As Twitter.Domain.Message()
   9:     ‘– create list of users from comma (,) delimited list of names in text box
  10:     ‘– TODO we should scrub this
  11:     Dim UserQuery As New List(Of Twitter.Domain.User)
  12:     For Each UserName As String In TextCriteria.Split(“,”)
  13:         UserQuery.Add(UserAPI.GetUser(UserName))
  14:     Next
  16:     ‘– get messages for these users 
  17:     Dim messages As Twitter.Domain.Message() = MessageAPI.GetMultipleUserMessages(UserQuery.ToArray())
  19:     ‘– filter messages based on who is in the contents
  20:     Dim FilteredMessages = _
  21:        From Message _
  22:          In messages _
  23:      Where MatchesCriteria(Message.MessageContent, Me.txtCriteria.Text.Split(“,”)) _
  24:      Order By Message.MessageDate Descending
  26:     Return FilteredMessages.ToArray
  29: End Function

   1: <Grid x:Name=”LayoutRoot”>
   2:         <StackPanel >
   3:             <StackPanel Width=”Auto”  Orientation=”Horizontal”>
   4:                 <TextBlock Text=”User Name” Height=”22″ Width=”80″/>
   5:                 <TextBox Text=”” TextWrapping=”Wrap” x:Name=”txtUserName” Width=”151″ Height=”27″/>
   6:                 <TextBlock Text=”Password” Height=”22″ Width=”67.957″/>
   7:                 <PasswordBox  x:Name=”txtPassword” Width=”143″ Height=”27″/>
   8:             </StackPanel>
  10:             <StackPanel Width=”Auto”  Orientation=”Horizontal”>
  11:             <TextBlock Text=”Screen Names” Height=”22″ Width=”80″/>
  12:             <TextBox Text=”rodpaddock,bellware” TextWrapping=”Wrap” x:Name=”txtCriteria” Width=”500″ Height=”22″/>
  13:             <Button Content=”Get Thread” x:Name=”cmdGetThread”/>
  14:             </StackPanel>
  15:             <StackPanel>
  16:                 <ScrollViewer Width=”Auto” Height=”600″>
  17:                 <ListBox Width=”Auto” Height=”600″ IsSynchronizedWithCurrentItem=”True” x:Name=”lstResults”    >
  18:                     <ListBox.ItemTemplate>
  19:                         <DataTemplate>
  20:                             <StackPanel Orientation=”Horizontal” >
  21:                                 <Image Height=”100″ Width=”100″ Source=”{Binding Path=ImageURL}”/>
  22:                                     <StackPanel>
  23:                                         <TextBlock Text=”{Binding Path=MessageContent}”/>
  24:                                         <TextBlock Text=”{Binding Path=MessageDate}”/>
  25:                                         <TextBlock Text=”{Binding Path=UserName}”/>
  26:                                         <TextBlock Text=”———-“/>
  27:                                     </StackPanel>
  29:                             </StackPanel>
  31:                         </DataTemplate>
  32:                     </ListBox.ItemTemplate>
  34:                 </ListBox>
  35:             </ScrollViewer>
  36:             </StackPanel>
  37:         </StackPanel>
  38:     </Grid>

One item to notice is that all of the code for calling the Twitter API is no longer embedded in the Click() event of the Search button. It has been extracted into its own method and no longer relies on user interface elements. This refactoring was done with integration testing in mind. In a later installment we will be looking at testing the user interface along with just the API calls.

Now the user interface looks like:


Google Code

The source code for this project can now be found on Google Code  The URL for this project is:




More Coming

I hope you have enjoyed these posts so far.  Lets take a look at the list from the last post and strike out some tasks that were accomplished in this post:

1. Introduce a Dependency Injection container. For this application I want to use StructureMap.
2. Introduce more mocking to remove dependencies on Twitter (maybe we can write a Twitter mock layer)
3. Further refine the design of the libraries. There’s still redundant code left we can remove.
4. Improve the UI and create some alternate UI’s with MVC  or maybe Silverlight
5. Open up the code to contributions from other developers.

We accomplished quite a bit in this post. Is all of the code done? Not by any stretch. I plan on revisiting all of the items on the list in every refactoring (rinse-lather-repeat)… I will also add new items to the list, like:

  1. Adding Proxy code to the communications class.

  2. Adding error handling to the communications class.

  3. Creating some mechanism for preserving credentials and other settings

RE #5: I did put it in Google code and would be happy to have other contributors. I would especially appreciate help with the UI. 

NOTE: One of the cool things about this process so far is the confidence I have in changes I make to the code. Having a repeatable set of tests is invaluable.


Posted in Agile, DevCenter, TDD, VB, VB DevCenter | 2 Comments