Monday, December 10, 2007

The Proactive Pair Programmer

It has been a little over three weeks since the MediaLogic software developers have decided to adopt pair programming. Team work has always been a very important part of the software developer culture at MediaLogic. I like to think that we have created a culture where no one person is the super star. We all have our particular strengths and weaknesses. When faced with a difficult or seemingly impossible problem it is comforting to know that you can simply ask for help. This open environment coupled with the right people can help you produce amazing code.

While pairing with various developers I have realized that one must be focused and proactive. Pair programming can be very difficult at first. I found that the most difficult part of pair programming was paying attention when I did not have the keyboard in my hands. Secondly, I learned that the inactive pair must be proactive and think ahead. Being proactive and forward thinking will greatly improve your focus and concentration. When we pair at MediaLogic we do a little thing called ping-ponging. The steps are as follows:

  1. Adam writes a test.
  2. Mo makes the test pass.
  3. Refactor if needed.
  4. Run tests and check for green bar.
  5. Mo writes a test.
  6. Adam makes the test pass.
  7. Repeat steps 1 through 6.

During the first step my pair must be thinking about how to satisfy the test and what the next test is. Furthermore, the inactive pair must be constantly challenging and questioning the design. You and your pair must keep in mind that it is the code being attacked and not the developer.

In my experience pair programming forces you to write better code. When pairing it is more difficult to suggest taking a shortcut. However, I must admit that this mentality to produce quality is solely based on the team. For example, if two weak programmers who take shortcuts pair together the quality of the code will be poor. On the other hand if at least one of the developers is strong short cuts will be less likely and quality will be up. I consider myself lucky as I work with a small team of very exceptional software developers. Over the last few weeks I have cut very few corners as a result of pair programming. As a result we are producing higher quality code that will more maintainable down the road.

Another benefit of pair programming is cross training and exposure to new ideas and ways of thinking. After one week of pair programming I feel like I have learned more than I normally do in one month of working on my own.   

Lastly, I have noticed that I am no longer distracted by email, instant messenger and my urge to read blogs. When pairing you do not have the luxury of checking your email or favourite blog. Let's face it, it would be poor etiquette to read your email with your pair sitting beside you. Pair programming is a very exhausting and rewarding experience. Paring requires that you try and stay one step ahead of your partner. At times this will require an immense amount of brain power to figure our your partners next move. Hopefully this will help you develop a passion to yell out "I know what your doing" or "I know where you are going with this". This passion or skill of active thinking can spill over into other parts of life too. Another benefit of pair programming is that it allows you to share success and failure. Failure or frustrating problems are never fun to deal with. Pairing allows you to attack problems together as a team. No two people think alike. This diversity allows each person to contribute different ideas and perspectives as to how a problem should be solved. A pair also allows you talk your problem out. Some times its just good to have someone to bounce your ideas off of. The process of explaining your problem out loud can be a very helpful tool. Other than over coming problems pair programming allows you to share success. I find that shared success is much more rewarding. This may be a paradigm shift but pair programming allows for human interaction to be a more pervasive element in the software development industry.

Cryptic NAnt Scripts

I've only had the privilege of working with a few NAnt scripts but most of them are very cryptic. They use XML attribute names delimited by periods. The following property name is distinguishable but not very clear.

<property name="base.dir" value="${project::get-base-directory()}" />

With the advent of fluent interfaces and striving to make our code more readable lets make our NAnt build scripts readable. I'm sure that NAnt has a naming convention but who cares lets be pragmatic about this and make our build files easier to read. Let us think of those who are looking at NAnt for the first time. On a side note Resharpers NAnt support kicks ass. My only complaint is that I can not rename a file set ID.

Here is an example of the type of build script that I would like to introduce.

<?xml version="1.0"?>

<project name="ProtocolBuilder" default="test">

  <property name="debug" value="true" />

 

  <property name="baseDirectory" value="${project::get-base-directory()}" />

  <property name="buildDirectory" value="${baseDirectory}\build" />

  <property name="toolsDirectory" value="${baseDirectory}\tools" />

  <property name="libraryDirectory" value="${baseDirectory}\lib" />

  <property name="sourceDirectory" value="${baseDirectory}\src" />

  <property name="applicationSourceDirectory" value="${sourceDirectory}\app" />

  <property name="testSourceDirectory" value="${sourceDirectory}\test" />

 

  <property name="applicationLibraryName" value="${project::get-name()}.dll" />

  <property name="testLibraryName" value="${project::get-name()}.test.dll" />

  <property name="xunitConsoleArguments" value="${testLibraryName} /sr /report-type:Text /rf:${buildDirectory} /rnf:Report" />

 

  <fileset id="libraryFilesSet">

    <include name="${libraryDirectory}\**\*.dll" />

  </fileset

 

  <fileset id="toolsForTestingFileSet">

    <include name="${toolsDirectory}\mbunit\bin\**.dll" />

    <include name="${toolsDirectory}\rhino.mocks\Rhino.Mocks.dll" />

  </fileset>

 

  <fileset id="testReferencesFileSet">

    <include name="${toolsDirectory}\mbunit\bin\MbUnit.Framework.dll" />

    <include name="${toolsDirectory}\rhino.mocks\Rhino.Mocks.dll" />   

    <include name="${buildDirectory}\${applicationLibraryName}" />

    <include name="${libraryDirectory}\**\*.dll" />

  </fileset>

 

  <fileset id="applicationSourceFileSet">

    <exclude name="${applicationSourceDirectory}\**\AssemblyInfo.cs" />

    <include name="${applicationSourceDirectory}\**\*.cs" />

  </fileset>

 

  <target name="killNotepad">

    <exec

          program="${toolsDirectory}\pskill.exe"

          commandline="notepad.exe"

          failonerror="false"/>

  </target>

 

  <target name="initialize" depends="killNotepad">

    <delete dir="${buildDirectory}" />

    <mkdir dir="${buildDirectory}" />

  </target>

 

  <target name="compileSourceCode" depends="initialize">

    <csc output="${buildDirectory}\${applicationLibraryName}" target="library" debug="${debug}">

      <sources refid="applicationSourceFileSet" />

      <references refid="libraryFilesSet" />

    </csc>

  </target>

 

  <target name="compileSourceCodeAndTests" depends="compileSourceCode">   

    <csc output="${buildDirectory}\${testLibraryName}" target="library" debug="${debug}">

      <sources>

        <include name="${testSourceDirectory}\**\*.cs" />

        <exclude name="${testSourceDirectory}\**\AssemblyInfo.cs" />

      </sources>

      <references refid="testReferencesFileSet" />

    </csc>

  </target>

 

  <target name="copyTestDependencies"

    <copy todir="${buildDirectory}" flatten="true">

      <fileset refid="toolsForTestingFileSet" />

  </copy>

    <copy todir="${buildDirectory}" flatten="true">

      <fileset refid="libraryFilesSet" />

    </copy>   

  </target>

 

  <target name="test" depends="compileSourceCodeAndTests, copyTestDependencies"

    <exec basedir="${toolsDirectory}\mbunit\bin"

      useruntimeengine="true"

      workingdir="${buildDirectory}"

      failonerror="false"

      program="mbunit.Cons.exe"

      commandline="${xunitConsoleArguments}" />           

  </target>

 

</project>

Sunday, December 9, 2007

NAnt Build Script Improvement - Being Pragmatic

For the last six months our team has dealt with the annoyance of forgetting to close our Report.txt file before running the test target of our NAnt Script. If you have no clue what I am talking about I will give you a little bit of background on our build process. Our team does not use Visual Studio to build our projects. Rather we use a NAnt script. Our NAnt Script has a target called "test" that runs all tests in the solution using an xunit framework. The results of the test are written to a notepad file in the same directory where the code is built. If the Report.txt file is not closed before running the test target you receive an error that the directory is in use. This error occurs because the build script is trying to delete a directory where a file is in use. Even though we only waste several seconds a day or minutes in a week we decided to get pragmatic about the problem. One of our developers created a target called KillNotePad that uses a SysInternals tool called PsKill. PsKill is a program that allows you to specify the process name or id that you would like to terminate(kill). Please be warned that this will kill all instances of Notepad. Fortunately, I do not use notepad but NotePad++. Therefore when I kill notepad notepad++ stays open. The build script I am using is very similar to the one described on Jp's blog you can also find it in the Nothing But .Net source code from November 2007 http://jpboodhoo.googlecode.com/svn/trunk/ 

The original clean target simply tries to delete the build and deploy directory and fails if the Report.txt file is open.

<target name="clean" >

  <delete dir="${build.dir}" />

</target>

The new clean target is now dependant on the killNotePad target. This means that the KillNotepad target will be run before the clean target.


<target name="clean" depends="KillNotepad">

  <delete dir="${build.dir}" />

</target>

 

<target name="KillNotepad">

  <exec

        program="${tools.dir}\pskill.exe"

        commandline="notepad.exe"

        failonerror="false"/>

</target>

The following is just one example of how you can solve this problem. The wonderful thing is that we do not all think alike. I'm sure that you can come up with a different solution a better solution.

 

Saturday, December 8, 2007

Quick Tip: How To Read and Write a Test

This is just a quick post. Hopefully in the next little while I can post a more in depth description of how a test should read and written. If you questions leave a comment and I'll make sure to follow up in my next post if I am able to.

If you are using JP's Resharper templates may I suggest changing your "record" live template to place the cursor in the playback. The reason I suggest placing the cursor in the playback is based on how a test should be read. A test should be read and written bottom up. By working bottom up you are explicitly setting a goal. The goal is to write code above the last line that will satisfy your assertion.  Lets work through some sample code to get a better understanding. I am assuming that you are familiar with Rhino Mocks and the system under test concept(Its a factory method).

[Test]

      public void Should_Leverage_the_task_to_retrieve_a_list_of_interviewee_Roles_Builders()

      {

          using (mockery.Record()) {

              Expect.Call(mockTask.RetrieveRoleBuilders()).Return(new List<IBuilder>());

          }

 

          using (mockery.Playback()) {

              CreateSUT().Build( mockXmlTextWriter);  // start reading here

          }

      }

 The following test simply states the following:
"When the build method is called we expect the task to call its RetrieveRoleBuilder method and return a  list of IBuilders"

This can be refined even further to:
"When a build occurs we expect that the task will retrieve a list of role builders."

Change your record live template so that you are writing tests bottom up

The original record live template:

using (mockery.Record())
{
$END$
}
using (mockery.Playback())
{  

}

The modified live template:

using (mockery.Record())
{

}
using (mockery.Playback())
{
$END$
}

Monday, November 12, 2007

My Nothing But .Net Experience

People over processes. I truly believe this was the theme for our nothing but .net experience. Other than JP's superb technical expertise it was my classmates who made the experience truly enjoyable. I can honestly say that my classmates were there to help one another grow as software developers. Even better we didn't spend the entire time talking about the technical world. It was a time to reflect and speculate about our futures. From this experience I witnessed a level of team interaction and communication that I have not seen in awhile. Everyday I was able to start up a new conversation with a different developer. It was a time to build new friendships and network. This sense of community is so important. My friends have told me that the Edmonton .Net User Group is very much like this. If anything I would love for the Calgary .Net User Group to adopt this sense of community, to build a network of developers who share knowledge and rely on one another. Some times I get the feeling that some of the presenters are up there to just pimp their consulting services and knowledge. This is not a community I want to be a part of. 

It has been awhile since I could honestly say that I was excited to be a software developer. This course has once again ignited my passion for software development. If anything I hope that my notes reflect my new values. For the first time in a long time I know exactly the skill sets, technologies that will help me propel my career on a new path.

My notes below are not 100% complete. That being said I have about 20 pages of notes.

If you are interested in the source code that we produced you can find it on JP's blog.

Hopefully our team photographer Clement Lo will put his photos up on flicker.

Please check out the following two blogs for more reviews.

Time Line

Day Start Time End Time Class End Time JP,Mo
Sean and I *
Monday 8:30 AM 11:45 PM  
Tuesday 8:30 AM 11:15 PM  
Wednesday 8:30 AM 2:45 AM 6:00 am
Thursday 9:30 AM 1:30AM (???)  
Friday 9:30 AM   5:00 am

*Its amazing how you loose track of time sometimes. JP, MO, Sean and I had a few late nights as a result. Thursday was a really rough day on only 2 hours of sleep. As a result I propose changing the name of the course to Nothing But .Net Extreme Edition

Day 1

Context Switching

Context Switching happens very often in the asp.net world. Context switching occurs when a person has to switch their focus from one thing to another. Context switching happens when asp.net developers shift focus from .Net to CSS to JS. Essentially a Asp.net Developer ends up being a .Net developer, A CSS developer, A JS Developer and designer depending on where you work. Software developers who develop desktop applications (WPF) typically work in context.

MVC

MVC is very exciting. Microsoft finally gets the importance of testing.

Keyboard use

  1. Take further control of Alt+Space in resharper change your key bindings for lunchy from Alt+Space to WindowsKey+Q.
  2. Get launchy if you don’t have it. Its an application that lets you launch applications using your keyboard. http://www.launchy.net/

Books I should Read:

  1. Enterprise integration patterns. By Gregor Hohpe
    • This book talks about service orientated applications
  2. Applying UML Patterns by Craig Larman
  3. MIT Open courseware had the biggest impact on JP’s career.
    • Lab on software engineering
    • While partaking in this course JP realized that he had no idea what OO was.
    • The project that JP worked on was Gizomo ball its now been updated to boggle
    • Learned all his fundamental patterns here.
    • Would have been one of the first ones offered if you are looking for it.
  4. Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas
    • This book was way ahead of its time.
    • Although I am only half way through this book it is already becoming one of my favourite books.
  5. Agile Principles, patterns, and practices in C# by Robert C Martin and Micah Martin
  6. Nhibernate in action recommended by James Kovacs.
    • JP has read Hibernate in action
  7. XUnit Test Patterns: Refactoring Test Code by Gerard Meszaros
  8. The Art of Unit Testing by Roy Osherove.
    The Book is still being created however you can download the first chapter from http://the.artofunittesting.com/
  9. Hackers and painters By Paul Graham.
    Its all about being Creative.

Tip about Mocking

In the mapping layer do not mock the persistence store. This is where the persistence store needs to be tested. You can map the persistence store in the service layer.

SVN Rules

Acronym for using SVN
UMATC

  1. Update
  2. Merge
  3. Add
  4. Test
  5. Commit

Music JP Listens to

Music that JP listens to : Zero = one = everything. Sounded pretty cool need to check this band out. Here are some samples http://www.last.fm/music/pronobozo/Zero+%3D+One+%3D+Everything
Listen to the track Reinvent while you program it is so awesome. In addition to that I learned he enjoys techno music.

JP and his MAC

JP Uses quick silver on his mac. JP seems to be a little obsessed with his mac. I think he wants me to buy one. I bet if I look real hard I can find the apple sales man who will sell us our mac note books at the end of the course.

His IPhone kicks ass.

Interfaces and the industry

The industry is moving towards not using I any more for interfaces.

Quote

“Pick the hill you want to die on.”

Nobody want’s to die for an unjust cause. Pick your battles wisely some causes are not worth fighting over. For example, do you want to destroy relationships and stress over whether or not the letter “I” needs to placed in front of a Interface.

A hill that is worth dying over is whether or not to use acronyms for variable names. Expressive variable names allow for your code base to be more maintainable.

ReSharper Tip

Shift F12 will bring you to the last problem.

Testing

Use logical Assertions. One assertion per a test.

All unit testing frameworks work based on reflection. Hence the attributes [Test] [Testfixture] etc.

Characteristics of good tests

  1. Focus on testing one thing
  2. Should not depend on another test. Order not important
  3. Should not change the state of the system. They must leave the system in the state it was in before.

Using Tools (MBunit, FinalBuilder, Nant, FxCop)

Don’t tie your self to a tool. This was in regards to MBUnit. Learn how the testing framework works but not do not work in the mind set that you will always use the same tool. If you live by the tool you will die by the tool. Even though tools make your life easier do not expect them to be around forever. You need to understand how the tool works underneath so that you can adapt and change otherwise you will go the way of the dodo bird. I.E natural selection will weed you out

FinalBuilder

FinalBuilder GUI for creating an deployment/installer.

Nant

List of all NAnt targets
http://nant.sourceforge.net/release/0.85-rc1/help/tasks/

 

Number of Projects JP uses in a solution

In a solution JP Only uses three projects

  1. Test
  2. App
  3. Build

The reason for the build project is to match the physical folder structure. Once JP puts the source up check it out. This structure allows you to use NAnt to decide how many assemblies are created.

Managing Dependencies

You can use FxCop policies to catch dependencies errors if you really need to. On the flip side your developers should understand which layers can talk to one another. If you are resorting to using FxCop have a good look at your team and perhaps revaluate what must be done.

Events

Multicast delegate is the out of the box observer pattern.
Read that post on building your own cab Jerry miller

Quote

“You know only as much as you know now.”
Do not worry about who knows more than you. Just focus on the fact that you will know more tomorrow than you know today. One should only worry when they are no longer learning.

Testing

The compiler is an early Test. But does not prove your stuff works.

Random

Defensive coding.

Higher order functions. This is functional programming.

Principle Tell don’t ask. The Hollywood principle.¸

The Highlander Principle

There can only be one. The name of this principle kicks ass.
Also know as the one with the most wins

Decorator vs Proxy

  • Decorator guarantees that all calls will be forwarded to the object that is being decorated.
  • Proxy may not always pass the message along to the wrapped object.

Naming Conventions

You should not have to use the name of the pattern in your class names. This was definitely a misconception for me. Some exceptions are the abstract factory pattern.

Day 2

So many Quotes

"Your greatest failure can be success."

  • Most people who achieve success stop doing the things that made their success possible. Once you achieve success you should stick to the routine and practices that brought you success.
  • You can save your self 2 hours every day.
    • Time is wasted:
      • Reading Blog.
      • Reading emails.
      • Watching the stock market.
      • Reading the same news story from different sources.

"You don’t need to know everything."
Once in a while its good to spike a topic just understand what it is.

"General Knowledge and when to spike"
Stay informed about new topics and technologies but only drill down deep into a topic when you are required to.

"A solid core"
With a solid base spiking topics like Nhibernate and monorail would take a lot less time because you have a good base understanding.

"Tools"
Use the tool knowing that you can produce the same things without the tool. ~Jimmy Nelson.

"Live by the tool die by the tool"
Don’t become tool dependant. If the tool changes it could destroy your career. Kind of like understanding how to use tortoise svn before using Visual SVN. Live by the tool die by the tool.

"Find the Higher Level Abstraction"
This type of thinking can help you solve the complex problems

"Think out side the box . Find the box."
~Andrew Hunt Pragmatic programmer.

"If you want something go after it."
JP wanted to enter the consulting world so he made the effort to contact Carl Franklin and .Net Magazines to get word out. It did not just happen by magic.

"Be Honest"
Be honest in your delivery. Don’t be fake. Be honest when you don’t know something.

"Make a list of what you want"
When JP was younger he made a list of what he wanted and put it on his mirror as a reminder. Today he has new list.

"Success does not happen by magic"
Like everybody JP was not an instant success. Its hard to believe that his first course was only Feb 2006. His first course Only had 4 people show up all of which were friends. Today 17 people attended his course 10 of which flew from different parts of the world to attend.

"The secret is simple. Hard work, focus and direction"
There is no magic to this its all about hard word focus and direction. This means you need a plan, an end game, a goal. Your goal should be something that seems almost impossible. Your goal should be meaningful. Don't just climb the corporate ladder.

"Years of experience does not actually equate to experience."

  • Recall the story of the two athletes born with the same gifts. One athlete works to make his gift better while the other does not. Even thought it may seem like some people have a head start because of genetics hard work can still give you the upper hand.
  • Your success can only equal the amount of hard work you put in.

"Better to ask for forgiveness than it is to ask for permission."
At the start of my career I use to exercise this all the time. Now I ask for permission. I think it is time that I go back to my old ways.

"Front load your investment"
JP talks about how his first 5 years of his career he sacrificed to develop his craft. This is front loading your investment. Some of us are sacrificing to be here at the boot camp. We are ramping up our skills so that the learning curve is not as steep for us. After this ramp up our learning will steadily increase. We will not have as much trouble learning new topics with our solid core. This type of ramp up is often provided by top notch universities.

Test driven Design

Helps you create code from the perspective of the client.

Aggregates

The difference is the boundary of control. The Library is an aggregate for the books collection. To access the collection of books you go through the library.

Composites

It’s a structure you can walk. Components and leafs. Iterators help walk a composite. Using the composite pattern you can introduce a visitor. Visitors, Composites and Iterators all work together nicely. A good example is a file structure: Folders are components and files are leafs.

The command pattern and composite pattern could be used for a remote. I believe Head First Design Patterns has a good example of this.

Functional Programming

Higher order functions. Functions that return functions

Specification

From a specification you could generate a SQL statement. This sounds really cool.

Version Control

Check out Pragmatic version control using subversion by Mike Mason.

SVN Tip

Branches should be short lived.

Software that JP uses (Find more in the video)

  • My Uninstaller.
  • ESET anivirus
  • FOSITReader
  • QueryExpress
  • FileMon and regmon – save time by learning these.
  • Regulator for building regular expressions.
  • winSnap. Seesm better than snippit
  • ZoomIn to get colors on the screen. RGB values.
  • Windows Clippings
  • BurnCDC BurnCDCC

Spike Aspect Sharp

It was mentioned and I’m not sure what it is. Could be a castle project.

Testing

  • Interaction based testing is white box testing.
  • State based testing is black box testing.

Mocking Classes instead of interfaces

If you are mocking a class then those methods and properties invoked must be marked as virtual. The reason for this is that Rhino Mocks uses reflection. If you cannot change the class use the proxy pattern as a work around.

J Flowers and mike Roberts on Building Check out their blogs.
If anybody knows why I wrote the above let me know.

Domain Specific Language

  • Check out antlr
  • Binsor is for winsor.
  • Brail is also a DSL.
  • Rhino ETL
  • Rake http://rake.rubyforge.org/
  • The pragmatic programmer has a chapter on the importance of DSL's. Man was that book ever ahead of its time.

Awesome Tip from James on getting really high admin rights on a windows machine

Open Command Prompt and type
At [Time] /Interactive C:\Windows\System32\cmd.exe

At the specified time a command prompt will open with privileges higher than the admin.
If you navigate to regedit in this command prompt you will be able to see much more information. Local System /sam

It’s on Keith’s Browns blog

Learning from our mistakes

We decided to conclude the night by going to a bar to perform a class retrospective on the last two days. Perhaps due to our sleep impairment this sounded like an awesome idea. However we all forgot that bars typically play loud music making it difficult for a group of 17 people to hear one person talk. Like any agile team we decided to adapt and made the most of the experience.

Day 3

Separation of Responsibility in Action

The domain model and the DTO’s allow the domain and the UI to evolve separate of one another.

Service Layer

The service layer is a gateway because anyone can consume it. Hence, you could use this for a webserivice. The service gateway is an entry point. Application start up would be placed in the service layer.

When to use Catch and Throw

Only catch and throw when it’s meaningful. For example:

  • Database connections.
  • The Domain Layer.
  • The global exception handler could catch all exceptions that have not been caught and logged.
  • When catching an error one could log the error and allow the application to continue if it is a non critical error.

Logging

  • Logging can have levels. This allows you to decide how much information to show. You can turn the log level on and off. We will be building our own logger. By programming to an interface we can swap new loggers in if we need to. During the course we will swap Log4Net in using the adapter pattern.

Things JP needs for development (Check out the screen cast)

  1. Story card
  2. Story Document (Media Logic should start doing this one)
  3. Prototype

Happy day and worst day Iterations

Happy day Iteration is where the application only works with valid data. This helps develop software quickly for the client so that can review it. Worst day iteration is where you focus on validating all data used in the application. This iteration could be preformed first if needed but typically can follow the Happy day iteration.

Model View Presenter

A view does not have to be a full page. A view could simply be a text box and drop down. The presenter decrease coupling between the view and service. The presenter is directly between the view and service.

View Template

An ASPX page is a view template.

DTO’s

DTO’s should not be interfaces. If DTO’s are Interfaces they cannot be serializable. The view template gets its info from the rendering context ie the presenter passes along the rendering context.

The aspx.cs is the View.

How to read a test

Read from bottom up.

For example:
When the presenter initializes it will ask the task dependency to do something.

The "Expect calls" and "Setup Results" are things that you are delegating to. You are asking these things to do something. By being able to read a test the code will be much easier to understand.

Difference between Expect and Setup Results

The Expect calls are the things that you are testing.
Setup results are necessary evils to allow for a test to pass. They are things that your mock objects depend on but are not the focus of the test.

Integration Test

  • Watin - Allows you automate testing of a web application. http://watin.sourceforge.net/
  • Selenium – Another
  • Water Not sure if this is a real one. Perhaps I misheard.

Don’t hide knowledge

This is what open source is all about, but why does it have to stop at open source. Once you learn to share your knowledge and allow others to benefit from your experiences and knowledge you will open yourself up to a whole new world. You will allow for yourself to grow in ways that you could never imagine. Those who hide knowledge are insecure and hiding behind a facade.

I did not know you could do this with ToString()

Using ToString on a value type you can format the output.

Int I = 22;
I.ToString(“Department 0”);

The result will replace the 0 with 22 which is the value of “I”.

Department 22

Fluent interface

Read Domain driven design
Role interfaces can constrain the actions you see as you construct the sentence. RhinoMocks uses Role interfaces.

Cross cutting parts of your application framework

Examples are logging, globalization, security, etc. These are services that are available at all layers of the application.

Book to Read

  1. Hackers and painters

More Quotes

  1. Giving a gift without expecting a thank you in return.
  2. Although you can steal the product of my creativity, you will never be able to steal my creativity.
    I might have butchered this a little but you get the point.
  3. Challenging the engagements and building the networks.
  4. Every single person can be leader.
  5. Sometimes leader’s stand alone.
  6. It is easier to ask for forgiveness than it is to ask for permission. How often have you asked to spike a topic but been turned down. Next time if your gut says go for "just do it" (Perhaps I can get Nike to sponsor me.).

Passive View vs Supervising Control

<To busy listening to take notes.>

Mapping pattern

It can be found in other places than the database. Most people associate the mapping pattern with the database layer. Here are some situations where the mapping pattern may be used.

  1. From a Domain Object to a Dto
  2. From a Dto to a display element.
  3. and vice versa for above.

Maintainability

Maintainability is the most important ility. Maintainability is based on the skill of the weakest developer. This explains the higher turnover rate at ThoughtWorks. If only the “all star” developer can understand the code than your code is not maintainable. The code must be understood by all if not most developers on your team.

A Harsh Reality

Most developers will not make the switch into OO or TDD. To help you make the cut check out JP’s blog post on 14 steps to become a better developer. If you do these steps the lowest common denominator will be much higher. Most importantly remember that some people will have to do a lot of unlearning.

MVP

Becoming an MVP gets you a ton of free software plus a free subscription from msdn. Also code better whatever that is can get you some free stuff as well. According to JP blogging a lot can help you get this status. You have to blog good consistent posts for at least 6 months. John Bristow will help Canadians local developers get there MVP status.

Awesomely Funny Quote Some time after 9:30 PM

My name is JP; I am a presenter with a dependency on the service layer.

Poor Man’s Dependency Injection

Essentially this is when you use the constructor of a class to inject the dependency.

For example

Public CarPresenter() : this (new CarTask()){}

//Above is the poor mans dependency injection

Public CarPresenter(CarTask task){

Task = this.task;

}

To replace poor mans dependency injection you could replace it with a service locator or factory. However the best solution would be using a container like Castle Windsor.

Object Mother

This class creates DTO`s in different states in the test library.

Resharper Stack Trace

Ctrl + shift + D

Design by contact

Once again learn how to do this yourself before using a tool. Besides it is fun to learn how the tool works. This will make you much more valuable developer you will be able to roll our your own creation or use a tool. If you live by the tool you will die by the tool.

Billy mcathady blog.
The name above is wrong if anyone knows what it is let me know

http://www.codeproject.com/csharp/designbycontract.asp

Pattern Can Not Help in Certain Situations

Throwing layer of indirection will not help you solve a solution. If you can not even hack a solution together there is no way in hell patterns will help. You must be able to hack a quick solution together before you can create a solution that uses patterns

Funny

“The simplicity of webforms, Not”. This was in regards to how events are bubbled up on the repeater when a button is clicked. In case you didn’t know the event is ItemCommand on the repeater this event is fired when a button is clicked.

Attack the Code Not The developer (Detach Yourself from Code)

If you notice that block or section of code is not up to par attack the code. Let the developer who wrote the code know that it is simply not acceptable or as JP would say stinks or weak. This is by no means an attack on the developer but an attack on the weak code. Unfortunately, to learn this lesson we sacrificed one of our own to JP to absorb JP’s comments. To be fair the developer pairing with JP was rather tiered and it was about 11:20pm after an 8:30 am start.
Detach yourself from the code. Don’t allow for bad code to be written by others. Let them know, it’s not the person you are attacking it’s the code. Unfortunately it’s the person who wrote the code but still remember it’s the code we are attacking.

More Funny Quotes

The following takes place right after JP finished attacking a developer’s code.

“When we get to the mapping layer I pity the fool who has to pair with me” ~JP

This was in regards to how much more difficult the testing is going to get. By the way its 11:51 PM on Wednesday. His new Nick name is JP the Tyrant. As I recall JP assigned himself this new nick name.

Premature optimization

Premature optimization is the root of all evil. We often do this when we optimize before we know that we need to. For example, some developers decide to make a class generic before even knowing if the generic class will be used. To counter premature optimizations only write as much code as you have to. Additional behavior or changes will allow you to refactor your solution in turn optimizing your code.

A light bulb just clicked

Clearly one of the most fundamental things that I have realized today is that you need to write as much code as you can to become a great developer to reinforce concepts etc. ~12:06am

OH No Red Bull

We now have red bull and I’m scared of super hyper JP. Jean-Francois decided the team need a pick me up and purchased red bull for the class. Sadly we did not have vodka to accompany the Red Bull.  ~12:20am
Read more about JP’s adventures with caffeine at Justice Grays Blog
My favorite quote from the post is:
“JP Jearly pimp-slapping some over questioning OO principles”

Red Bull Update
JP is now typing at an insane speed and is talking a million words a minute If I don’t survive remember me as a kind person. ~1:00

Here is a Tip:

Solve the problem and then refactor. Essentially write the dirtiest nastiest code obviously with tests and the refactor the bitch.

Damn you can Test Webforms

Now this is real eye opener. Beyond testing the presenter in the MVP pattern you can test utility classes and other classes that you create that are bound to webforms.

Premature generalization

If you only have one case you do not have to generalize until you have two or more cases. Only do it when you have to.

Exciting

JP will be showing us how we can remove the code behind completely.

24 Hour day

I think this is first ever for Nothing But .Net but MO, Sean, JP and I spent the remainder of the night talking until 6:00 am. Sean and Mo decided to drive back home well I took JP up on his his very gracious offer to sleep for two hours in his hotel room. Thanks JP I really appreciate your generosity.

 

Day 4

Getting Started Learning Some New Developer Habits

Read JP’s post getting started learning some new developer habits.

http://www.jpboodhoo.com/blog/GettingStartedLearningSomeNewDeveloperHabits.aspx

Another Quote

Ok it’s not exact but we talked about seeing the path. After being exposed to seeing so many new things we were asked if we could see the path that we would like to travel. If you can see the path I urge you to travel the path.

Thin Service Layer

The store exercise is using a thin service layer.

Over Specification

The Xunit book mentions over specification for mocking.

Where does JP use Identifiers in his domain model?

The key is located on the domain object for example car.ID.

The identifier can then be used on the service objects who obtain there data typically from DTO pushed down from the Presenter. For example

CarTask task = new CarTask()

Task.FindBy(carDto.ID);

Obviously there is much more to this but it’s a start.

SUT = System under Test

XUnit SetUp Method

The setup method should only be used for setting up hard dependencies with the System Under Test.

The combination of SUT and Dynamic mocks makes the test less brittle. With brittle tests one change could cause many tests to fail.

Setup result is a necessary evil to test other functionality that depends on it. Setup result is not what we are testing. We are testing our expects and assertions.

AutoMocking

AutoMockingContainer is combination of RhinoMocks and Windsor Container.

Oren Eini has a nice little post about AutoMocking
According to Jacob Eleutin Technology the AutoMockingContainer

  1. Decouples your tests from your constructor
  2. It simplifies your tests.
  3. It helps reinforce good mock usage.

For more information check out this post by Jacob

With the AutoMockingContainer we can remove our dependencies because it uses reflection to create the SUT and pass mocks into the constructor of the SUT therefore dependencies do not have to be passed into the constructor.

Personally I find the tests a little hard to read when using the AutoMockingContainer. However I did whiteness first hand how the AutoMockingContianer could have saved us from modifying a whole whack of constructors when we added a new parameter to a constructor.

Mock Naming Convention

It’s easier to find all the mocks in a test fixture if you prefix all mocks with mock.

Unit Test Tip

Don’t waste time refactoring test code.

TDD in JP's words

JP was able to explain TDD eloquently with the following phrase.

“With test driven development design is up and in front of your face all the time”

Why UML diagrams suck for up front deign

If one designs a UML diagram before coding and practices TDD more often than not the final solution will not match the UML diagram. As you design your code your focus will be placed on writing code that is easy for the client to understand. The client by definition is the consumer of the test code you are writing. This code will ultimately be easier to understand and use. It's to bad that you could not be their but JP described the process of designing a kick ass up front UML diagram with some Kick ass sound effects.

Comments Suck...

If you are using comments more often than not it means that your code is not expressive enough.

Strict and Not strict Mocks

Strict mocks should rarely be used. A strict mock is maintenance nightmare waiting to happen. If anything other than your expectations are invoked a strict mock will blow up.

A strict mock is created with the CreatMock method on Mock Repository in RhinoMocks.

Non strict mocks are forgiving and return default values if an unexpected method or property is invoked. Reference types will return null and value types will return 0. To create a non strict mock you can invoke the Stub or DynamicMock method on the Mock Repository in RhinoMocks

Types of Dependency Injection

There are three types of dependency injection

  1. constructor
  2. setter
  3. I’m not sure what the third is. If some knows fill me in. ???????

Dependency Inversion Principle

Both high level and low level components depend on abstractions. By not doing this you increase the coupling between low level and high level components.

Read Eric Evans Domain Driven Design

  • anti smart client patterns its only two pages.
  • Anti corruption layers.

JP Mentioned that we will cover Temporal Patterns if we had time

Temporal patterns allow us to manage things that change. If we do not get to it I found this article http://martinfowler.com/ap2/timeNarrative.html

Day 5

Visitor Pattern

  • Its simple but the implementation can be complex.
  • Double dispatch this is used in conjunction with a composite pattern.
  • Allows you to remove for loops.
  • Could visit a list to get the total count of a list, total price.

We spent a good part of the morning removing countless for loops with the visitor pattern. I can not wait to apply the visitor pattern on a real project.

During this topic I had a chance to pair program with JP in front of the class. I finally understand how proper pair programing works. I also know see the benefit.

There are two types of books

  1. Core books
  2. API Books

Only read API books after you have read and understood core books. Some core books that you might be interested in are

  1. Domain Driven Design By Eric Evans
  2. Head First Design Pattern by Eric and Elisabeth Freeman
  3. Pragmatic Programmer by Andrew Hunt and the KFC Guy (David Tomas)
  4. Code Complete
  5. Patterns of Enterprise Application Architecture
  6. ETC....

Headphones to check out

Shure530 headphones 600

AutoMockingContainer

When you have time have a look at AutoMockingContainer abstract class to understand how it works.

Look up Erin Jenson. He wrote the abstract testfixture.

Integration Tests

The integration folder structure should be the same as the unit structure.

Acceptance tests

Acceptance tests go in the root of the test folder in the acceptance folder. If the test is not written in .net it goes in another folder.

Check out

http://sleepoverrated.com/

Lazy Load

You can leverage Yield to perform lazy load.

Duck typing

Look it up.

Watin

Allows you automate testing of a web application.
http://watin.sourceforge.net/

Topics that still need to be covered

  1. get rid of MVP
  2. Domain validation
  3. Mapping from the datatables to DB
  4. Web service
  5. Smart client
  6. Role Based security
  7. Unit of work
  8. Lazy load
  9. Money bag.
  10. propagate validation to UI
  11. Global error handler
  12. Handling state in a testable way.
  13. Testable ways to deal with security
  14. DSL for validation that lives outside the application
  15. Effectively testing the mapping layer.
  16. View orchestration.

Building Your Own Front Controller

  • Can be query string or IHttphandler.
  • Sorry didn’t right many notes but I look forward to spiking this kick ass topic real soon. Maybe I’ll put a post up or two if I have the time.

Another 24 Hours day

Once again JP, MO, Sean and I got to talking and lost track of time before we knew it, it was 5:00 AM.

Wow if you made it this far congratulations !

Sunday, November 4, 2007

The Quest to Become a Better Software Developer Continued

Tomorrow is my first day of perhaps one of the most highly regarded and talked about courses that a software developer could attend. That's right, I have decided to take the plunge not just to my bank account but to become a better software developer. Incase you have not clued in yet I am talking about JP Boodhoos Nothing But .Net 5 day boot camp. After attending one of JP's presentations and having the pleasure of JP consulting for Media Logic I was more than impressed with his skill level. It's hard to believe that JP is only 4 years older than I am. Perhaps one day in the not to distant future my skill level will be equal to that of JP. In the mean time I have outlined a clear plan as to how I would like to achieve this goal. Perhaps the most important thing to remember is that it's about having fun. This was clearly evident when JP was working for Media Logic.

If you are interested in attending Nothing But .Net I suggest you check out JP's Blog. JP has even posted good and bad comments from students of his course on his blog. Saving me the trouble Mo has an excellent post containing links to past students who have posted their reviews and impressions of the course. Perhaps one of the most notable similarities among the reviewers is that most people have identified this course as life and career altering. I can only hope that this course has the same affect upon my career. Once I complete the course I hope to post my impressions of the course.

Here is an overview of the course that I copied from JP's Blog .

Overview

Nothin’ But .Net is a five day boot camp that will focus on pragmatically applying .Net within the context of developing a working N-Tiered application. Registrants will learn about advanced features of .Net (2.0/3.0) as they are applied to the task of building a complete application from the UI layer all the way down to the mapping layer.

WARNING!!!!

If you are expecting to come to this course to learn about how to have VS.Net automatically generate an “application” for you, then this course is NOT for you.

This course is all about taking control of the .Net framework and having it work the way you want. This course will place a heavy emphasis on getting back to the basics and making .Net do things the way you want it to, in a predictable and testable way.

This course will focus on a code centric view of application development vs. the typical databinding/designer magic covered by many typical .Net courses. You will walk away with a deep understanding of fundamental aspects of .Net and how these pieces can be used to develop and deliver enterprise scale applications.

Core Concepts Overview
  • Expanding the capabilities of developing with VS.Net - Enter ReSharper (a productivity add-in for Visual Studio .Net)
  • There’s more to life than generated code
  • Automation for the developer
  • Generics ( they’re not just for collections )
  • Back to basics - Rules Of Good Object Oriented Design
  • Dependency Injection
  • Object Relational Mapping in .Net
  • Applying the dependency inversion principle
  • Domain Driven Design
  • Passive View/Supervising Controller (Model View Presenter)
  • Creating layered architectures
  • Driving out functionality and design through testing
  • Taking Control Of Databinding
  • Behavior (Test) Driven Development
  • Core design patterns applied
  • Pragmatic Productivity Tools For Developers

Sunday, October 28, 2007

Is Your IDE Hot or Not?

Finally a web site dedicated to rating the appearance of your IDE.

http://idehotornot.ning.com/

This now validates my theory that not only does a developer have to keep his or her looks in check but now attention must also be focused on the appearance of ones development environment. This explains the recent spike in transparent user interfaces over the last few months. Recent research indicates that the use of a transparent interface by a software developer is an attempt to look cool*. This trend has been more evident over the last few months. I have noticed more and more developers switching to applications that provide transparent capabilities. Such applications include Console 2, TaskSwitch, Vista in general. I'm sure Justice Gray the self proclaimed metorsexual developer has loaded his PC with a vast array of applications that sport the transparent look of 07. Further proof can be found on Justice Grays list of metrosexual developers. I know for a fact that JP Boodhoo and Mo Khan have both pimped there machines with all kinds of slick looking applications. These two developer have had their names proudly inducted into the definitive list of metrosexual developers found on Justice Grays blog.

John Lam has come up with a rather interesting theme based on the Vibrant Ink theme for Textmate (whatever that is... Long live windows....).

Installing new themes in visual studio is really simple. You can install themes under tools---->options---->Environment---->Import and Export Settings
or use the wizard
tools---->Import and Export Settings

Make sure to copy your current settings before applying any of these themes.

Here is my current attempt to up my coolness with the Vibrant Ink theme. I must say its rather pimp.



Here is a closer look.



* To my knowledge there has not been a study conducted to prove the coolness of software developer when using applications that have transparent capabilities.

Friday, October 5, 2007

Me Against the World

Recently I was reminded of the following quote.

I know it seem hard sometimes but
Remember one thing
Through every dark night, there's a bright day after that
So no matter how hard it get, stick your chest out
Keep your head up, and handle it.
-Tupac Shakur

Monday, September 24, 2007

Design Principles and Patterns

Several hours ago I started to read Head First Design Patterns. Although I am only several chapters into the book my understanding of patterns is already broadening. As I read Head First Design Patterns I am increasing my "programmers vocabulary". This means that will be able to speak more fluently with other software developers. Rather than going into a verbose conversation about the details of a solution I can simply spew out the name of a design pattern.

Head First Design Patterns has enlightened me as to why design patterns are important. A common misconception is that patterns are nothing more than using object oriented design principles. Not all design patterns are obvious, even those who are well versed in object oriented programming may not be able to reproduce many of these design patterns. By understanding design patterns you can jump right to creating proven solutions that work. Needless to say good OO skills are always necessary. After all OO principles are the basis upon which design patterns are built upon on.

Here are a few design principles that I have been introduced to.

  1. Take what varies and encapsulate it, so it does not affect the rest of your code.

  2. Program to an interface not to an implementation.

    The one misconception with this design principle is that you must use an interface. In fact this principle refers to using a super type in place of a concrete type. Hence, you could replace the world interface for super type. Program to an super type not to an implementation.

  3. Favor composition over inheritance.

  4. Strive for loosely coupled designs between objects that interact.

  5. Classes are open for extension, but closed for modification.

Sunday, September 23, 2007

The Often Forgetful but Important Value Type

More often than not we take the little things for granted. Value types are one of the many unappreciated heroes of the .Net Framework. Value types are used on a daily basis without ever giving a second thought to performance or impact. The following post aims to characterize and explain what a value type is.

There are three categories of value types

  1. Built in types
  2. User defined types (Structures, Struct)
  3. Enumerations

General Guidelines for all value types

  • Value types contain their data directly.

  • Value types are stored in an area of memory known as the stack. The stack allows for variables to be created, read, updated and removed quickly during runtime with minimal overhead.

  • When you assign between value types the data is copied from one variable to the other. For example

    Int32 AdamsAge = 24; //Stored at memory address 1
    Int32 YourAge = age; //Stored at memory address 2

    YourAge = 30;

    AdamsAge will remain as 24.

    Thus an assignment between value types stores the data in two different areas of memory on the stack. This contrasts the behavior of reference types.

  • All value types are derived from System.ValueType.

  • All types are derived from System.Object. This means that methods may be called on value types.

  • Value types have an implicit constructor. Thus, a deceleration unwittingly instantiates the type automatically. The new keyword does not have to be included as you do with classes. The default value is usually 0 or null. As a rule of thumb you should always assign a default value.

  • As of .Net 2.0 the Nullable type is available. Nullables allow you determine if a variable has been assigned or not. A nullable type is an instance of System.Nullable. System.Nullable is a structure.

    For example boolean values may now have three states true, false, null(not selected).

    Syntax

    Nullable<bool> isVisible= null;
    bool? isVisible = null;

    A Nullable variable has the following additional properties HasValue and Value.

    For more information regarding Nullables please read the following article MSDN.


1. Built in Types

The general guidelines above apply to all built in types. Built in types are base types provided by the .Net Framework. Built in types are used to build other types. The most common types are:

  • Char
  • Boolean
  • Int32
  • Double
  • Decimal
  • DateTime
  • String Yep, that's right string is not a value type. String is in fact a reference type.

2. User Defined Types

A structure is a composite of other value types. Structures behavior is almost identical to that of a class. An example of a simple structure would be a point on a grid. The point type contains two integers X and Y. X being the horizontal location and Y being the vertical location.

The point structure could be created as follows. As you can see this point structure is very simple.

public struct Point

{

   int x;

   int y;

}

The following point structure is much more complex and offers more value. This example exposes a constructor and several methods to change the X and Y coordinates of the point.

public struct Point {

    private int x;

    private int y;

 

    public Point(int x, int y) {

        this.x = x;

        this.y = y;

    }

 

    public int X {

        get { return x; }

        set { x = value; }

    }

 

    public int Y {

        get { return y; }

        set { y = value; }

    }

 

    public void MoveUp() {

        Y += 1;

    }

 

    public void MoveDown() {

        Y -= 1;

    }

 

    public void MoveLeft() {

        X -= 1;

    }

}

Getting in the spirit of test driven development here are a few tests to illustrates how this structure works.

[TestFixture]

    public class PointTest {

        private readonly int xStartPos = 8;

        private readonly int yStartPos = 9;

        private Point point;

 

        [SetUp]

        public void SetUP() {

            point = new Point(xStartPos, yStartPos);

        }

 

        [Test]

        public void Should_Move_Down_Once() {

            point.MoveDown();

            Assert.IsTrue(point.Y == yStartPos - 1, "Should have moved the y axis down by one(Y-1).");

        }

 

        [Test]

        public void Should_Move_Down_Twice() {

            point.MoveDown();

            point.MoveDown();

            Assert.IsTrue(point.Y == yStartPos - 2, "Should have moved the y axis down by two(Y-2).");

        }

 

        [Test]

        public void Should_Move_Down_Up() {

            point.MoveUp();

            Assert.IsTrue(point.Y == yStartPos + 1, "Should have moved the Y axis up by one(Y+1).");

        }

 

        [Test]

        public void Should_Move_Left() {

            point.MoveLeft();

            Assert.IsTrue(point.X == xStartPos - 1, "Should have moved the X axis left by one(X-1).");

        }

    }

structures usually are more efficient than classes. A structure should meet the following criteria.
  • Logically represents a single value.
  • Has an instance size less than 16 bytes.
  • Will not be changed after creation.
  • Will not be cast to a reference type.

3. Enumerations

Enumerations allow you to assign values to symbols. The primary benefit of enumerations is to improve code readability. Instead of passing an arbitrary number into a method one can pass in a meaningful symbol. The following is an example of an enumeration.

 

public enum CarManufacturers { Honda, Acura, BWM, Audi, Mazda, Hyundai, GM }

 

public class Car {

    private CarManufacturers manufacturer;

    public Car(CarManufacturers manufacturer) {

        this.manufacturer = manufacturer;

    }

 

    public CarManufacturers Manufacturer {

        get { return manufacturer; }

    }

}

 

//We can now easily check the manufacturer of a car

 Car car = new Car(CarManufacturers.Honda);

 

 if(car.Manufacturer.Equals(CarManufacturers.Honda))

    Console.Write("Honda");