Sunday, November 13, 2011

My First Week on a MacBook Pro

I’ll admit it, I’ve been a Microsoft fan boy for all my life.  I’ve only owned Microsoft products (even a Zune!), never really gone outside my comfort zone and experienced the “other side”.  For the last week, I’ve been working on a MacBook Pro and, must admit, am really enjoying the experience.  From my employer, I had the option between a PC and a Mac laptop.  I chose a Mac for a couple for a couple of reasons:  1.) I wanted to broaden my OS horizons and learn something new and 2.) The option of potentially doing Mac iOS development is now an option.  I can create a Windows VM (which I have) on a Mac but the other way (creating a Mac VM on a Windows machine) doesn’t work out so well.  So, with that, here’s been my first experiences with the Mac and why I’m enjoying it.


Setup was a breeze.  Within a few minutes I was up and running with OS X Lion.  Once loaded, I was excited to get started so, off to the App Store I went.  The first thing you’ll want to do is to sign up for a free App Store ID.  This will enable you to download things from the App Store, both free and paid.  There are many great Apps in the App Store to get you started!  I’ve also notice that installing applications are easy, it’s literally a drag and drop into the Applications folder.  It takes away all the “Next, Next, Next” that a Windows setup has a user to do.


  • VMWare Fusion (paid) - this is a great VM product for Mac.  Since I still do the majority of my development in .NET, I needed a Windows machine to develop in.  I had an option of Boot Camp (basically dual booting) into Windows or creating a VM.  I chose a VM for a variety reasons.  Creating a Windows 7 64 bit VM with Fusion was super easy.  It first asked to give it a user name and password and it was off.  I didn’t need to enter any other piece of configuration data.  The VM has been running smoothly all week.  Full disclosure:  I did upgrade the RAM to 8GB and have dedicated 5.5GB or RAM to my VM.
  • Alfred (free in the app store) - this is a quick productive tool designed to keep your hands on the keyboard.  With Alt + Space bar, we can launch Alfred and have it search what we are looking for whether it be locking your system to searching for something locally or on the internet, Alfred can help.
  • Twitter (free from app store) - the Twitter app for the Mac is fairly impressive.  It has a time line bar and everything that Twitter has to offer in a good layout and it’s easy to use.


Developer Tools

  • XCode - this is the IDE of choice for Apple development.  While I did experience some serious lag in downloading this application, once up and running it does install easy.
  • HomeBrew - package management tool

Blogging Tools

For me, I find it best when I write a blog to initially write in a “distraction free” writing zone.  That is, an application that is full screen, I can’t see any notifications nor icons that tempt me to get distracted.  Often I’m ADD and just want to click on the next shiny thing so a good distraction free writing tool helps me immensely in writing!  I was looking for a good one for a Mac and found two free ones and haven’t made up my mind which I enjoy more:
  • FocusWriter - I am admittedly writing this blog post in this tool.  I like the fact that you can create and Import/Export Themes.  I am a big fan of a high contrast theme so the first thing I done was created a “Retro” theme with a black background, black foreground, and green text.  Back to the good ole green screen it is!  FocusWriter has a Timer that will go off after set number of minutes.  This is useful if you are using a Pomodoro technique and it also helps keep me focused for a set number of minutes.
  • OmniWriter - this is another great distraction free writing tool.  This gathers more senses than just your sight.  Omniwriter envelopes you in a zen like environment complete with a soothing background and writing space and playing zen like music.  It definitely puts you in a much more relaxed state to allow your ideas to flow freely.

Key Observations

I’ve consistently heard that Apple is great at improving things and that “it just works”.  I have found this to be true in the different accents they put on their product.  Some things I noticed are:

Power Brick

First off, it’s a relatively small power brick that you can easily pack away.  There are small, yet useful improvements such as cable management that allows you to clip the cord to itself not to mention the magnetic plug that plugs right into the laptop.  The little adapter where you can plug the power brick directly into the wall or attach a longer power cord to the power brick for more cord length.  Typically I just use the power brick and not the longer power cord as this is easier to pack away in a bag.


Having this concept of multiple Spaces I found very useful.  With a 3 finger swipe, I can just swipe between spaces.  This is useful to help organize the applications I’m in.  I typically use this by having my Windows VM up in a space and having other applications that are native to Mac in another space.  This allows me to switch and organize my spaces easily without minimizing/maximizing a bunch of windows.


While I’m mostly a keyboard guy, I was amazed at all the Apple TrackPad can do.  This is much more sophisticated than the TouchPads I’ve used on a Windows machine.  With the TrackPad you can do a three finger swipe to move between workspaces or a two finger click to bring up a context menu or just swipe from side to side in your browser to go between web pages or just do a two finger swipe or down instead of scrolling.  Apple has really made use of the TrackPad and has brought it up to an entirely different level. 

Backlit Keyboard

To be honest, I never thought I’d use a backlit keyboard.  I thought, what’s the use.  I have found a use!  In our Team Space, we enjoy the room dimly light.  It’s easier on the eyes than all the bright halogens.  Since it’s dimly lit, the backlit keyboard provides just enough soft light to make it an enjoyable experience.
Display The display is fantastic!  I got the 15” glossy screen and am enjoying the experience.  It has a nice, sharp, high resolution screen that is much crisper than the ones I have seen on Windows hardware.

Wrap Up

There are many other aspects I’m enjoying but those are my top 5, not in any particular order.  My first week with a MacBook Pro and I’m really enjoying “the other side”.  The broadening of my horizon has proved useful and would encourage PC users to try out the Mac.  I am enjoying the small footprint, both in size and weight that the MacBook Pro has to offer.  There are some “oddities” with keyboard shortcuts such as Command + C to Copy instead of the good ole Windows Ctrl + C to Copy but am learning everyday!  I’m anxious to continue learning new things about the Mac whether it be hardware or software in the coming days.

What other tips/tricks and/or apps do you have that you find useful (free or otherwise?)

Thursday, June 23, 2011

Scrum Outside of Software Development

I shared the Scrum methodologies to a teacher friend of mine the other day and focused on the Daily Stand Up.  Explaining that this meeting should be short (time block it to 60 seconds/person if need be), yet informative and having everyone answer the following 3 questions:

-What did you do yesterday?
-What are you doing today?
-What roadblocks do you have?

He had an "ah ha" moment and went on to explain how many communication issues this would solve and how much more efficient they could be working if they just practiced this one facet of Scrum.  They plan to implement the daily stand up starting with next year's school year.

At the core, Scrum is about delivering value to customers.  Isn't this what we do on a daily basis?  Professionally, we need to deliver value to our clients; personally, we need to deliver value to our families, friends or ourselves.

-If you're a developer, the value is delivering quality software to your customer.
-If you're a sales person, the value is accurately selling a product to potential customers.
-If you're an author, the value is creating a solid piece of work to your publisher.
-If you're a student, you need to deliver quality homework to the teacher/professor.

I heard of a story of a stay at home mother using a Kanban board (same as Scrum but differs where Scrum has Sprints, Kanban is a continuous workflow) to help manage her tasks throughout the day.  She developed swim lanes and put post its up as her action items and watch them move through the process until they were done.  It was something big and visible and she felt a sense of accomplishment and accountability while watching post its move across the board.  Of course, since the work was "laid out" she could give some of those post its to her spouse to get done.  Maybe she had a swim lane dedicated to her spouse (aka the "Honey Do" list), I'm not sure.

This got me thinking, Scrum is a framework and really can be applied to about anything.  While some would argue just because you could, should you?  While that's a topic for another discussion, the Scrum framework is very versatile.  While Scrum has gained traction particularly with Software Development, it doesn't end there.  Scrum can be applied to a wide array of projects, both personally and professionally.

Let’s take a look at the Scrum framework.  Here’s a graphical representation of it:


We can practically apply these concepts outside of software development.  I’ll use a Sales Person and an Author as two examples through the process.  How?  Think of each stage in the following manner:

1.  Vision – this step is not shown but this step is your final goal; what do you want to accomplish.

  • Sales Person – this could be a territory to cover, preparing for a presentation, any type of goal(s) you need to meet.
  • Author – this is the book or piece of work that you want to create.
  • Coach – to win a game

2.  Product Backlog – this is your high level to do list, the planned work.  Questions like how do you obtain the vision or the goal you want to meet?  Some examples could be:

  • Sales Person – high level list (by company, territory, etc.) of cold calls, follow up calls and/or visits you need to make with customers or potential customers.
  • Author – this could be the chapter titles or chapter ideas for the book
  • Coach – determining the high level, measurable areas of where the team needs to improve in order to win

3.  Sprint Backlog – this is a more detailed account of work to be done.  Break down the high level product backlog into manageable tasks that can be accomplished within a Sprint (2-4 weeks or whatever that time frame may be).  If something unexpected comes up (aka life!) that needs immediate attention, add it to your Sprint Backlog, and consider the additional amount of work it will take and if anything in your current Sprint can be pushed off to the next one.

  • Sales Person – specific call list of who to call or places to visit
  • Author – taking a chapter and determining sub topics, developing a chapter outline
  • Coach – specific activities, exercises, drills for specific player or players to execute

4. Daily Scrum Meeting – the idea of a small feedback loop for your team.  If you are a team of one, this may be reflecting/reviewing for yourself to get yourself re-aligned with the goals such as an author or Sales Person.

  • Coach – gathering the team around, getting re-aligned with the goals

5. Potentially Shippable Product Increment – think of this as your potential deliverable to your client.  This does not necessarily mean that this will be delivered to the client but that this unit of work is done, completed, and “production ready”.

  • Sales Person – finish a specific block of calls or visits of customers
  • Author – finishing a complete chapter and delivering it to the publisher
  • Coach – having the team reach certain goals incrementally and being able to execute to win the next game!

Scrum has a wide variety of applications other than just for software development.  While I’ve only given a few simple examples, I hope it aided in broadening your thinking regarding the application of using Scrum and how it can apply to different areas.

What other areas of life or activities have you practiced Scrum in?

Additional Resources:

Monday, May 2, 2011

Installing and Configuring Cruise Control .NET

Cruise Control .NET serves as a good Continuous Integration (C.I.) Server.  CCNet works with many applications and is relatively quick and easy to setup.  CCNet is primarily configured using XML.

This tutorial will outline how to install, setup, and configure a CCNet project using MSBuild. I’m installing this on a Windows 7 SP 1 instance with IIS 7 installed and CruiseControl.NET v 1.6.

  1. Download Cruise Control .NET
  2. Accept all the defaults for installation

Post Installation

Once installation is complete, do the following:

  1. Verify that the “ccnet” virtual application exists in IIS
    1. If it doesn’t create a Virtual Application underneath the Default Web Site and point it to C:\Program Files\CruiseControl.NET\webdashboard
  2. Give the “Network Service” Account both “Modify” and “Read & Execute” rights to the following folder: “C:\Program Files\CruiseControl.NET\webdashboard\packages”
    1. Note: Not doing this will give you an Access Denied error message when attempting to install packages
  3. Populate the Administrator’s password
    1. Open the dashboard.config file (C:\Program Files\CruiseControl.NET\webdashboard)
    2. Look for the following XML snippet: <administrationPlugin password="" />
    3. Populate the password string with your admin password. The password does not have any limitations other than it can’t be blank.
  1. By default, the CruiseControl.NET windows service is not started. Start it.

Once these steps are complete, you can browse to http://localhost/ccnet and should see the following screen:



Installing Packages:

  1. Click on the “Administer Dashboard” link
  2. Enter the Admin password you entered in the dashboard.config file
  3. The list of available packages to install will be on the right hand side.

Configuring of CruiseControl.Net

The project configurations and the build tasks are all configured in the ccnet.config file (C:\Program Files\CruiseControl.NET\server)

*Note that when changing this file, you need to restart the CruiseControl.NET service

Here’s an example of building one solution using MSBuild and running automated tests after the build using MSTest. (Thanks to Ben Hall for the sample file)

  <project name="HelloWorld">
        <executable> C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe</executable>
        <buildArgs>/noconsolelogger /p:Configuration=Debug</buildArgs>
        <logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MSBuild.dll</logger>
      <xmllogger logDir="C:\CCNet\HelloWorld\Logs" />

Additional Resources

Tuesday, January 25, 2011

Evolution of Automated Testing

In the Agile world, and increasingly, in software development in general, automated testing is a key ingredient in delivering quality software. It's one of the many reasons why Agile has become so successful and is a component to any long-term, sustainable effort. Automated testing blurs the lines between the QA and the Dev. Both parties need to work together to produce a solid piece of software.

If your code has been developed in a "non-Agile" way, meaning code that is not easily testable, we need to work on paying back that technical debt. (Technical debt is anything in your code that wasn’t done cleanly. You know it’s there, and eventually you’ll have to pay it back. Unfortunately the interest rates are usually obscene!) There are many ideas on ways to do this, including Defect Driven Testing (find a bug, write a test).

Today I don’t want to discuss writing testable code for new features, but rather how to deal with our current technical debt. How do we move our code (and developers!) from a manual testing process to a more automated testing mindset?


clip_image003 clip_image001 clip_image005

How do we get there? Iteratively, of course!

Always use an iterative, phased in approach when introducing automated testing to your development team. Remember, the goal isn’t to fix everything overnight and make sure everything is being done The Right Way. That approach often creates so much churn that the team gives up and reverts to old habits. Our goal is create lasting, sustainable change.

First, let's define different umbrellas of automated testing:

  • Manual - tests which cannot be automated, it requires human interaction and a human eye.
  • GUI - tests that will mimic the user clicking buttons in the UI to perform end to end testing
  • Functional - tests that can provide end to end functionality testing that occurs right below the user interface level.
  • Integration – tests requiring an external source such as a database.
  • Unit - tests that are all on the front end, no external sources required but which test a small amount of code.


    Phase 1


    With legacy code, we all start with manual testing. A QC person manually tests the same test case over and over again throughout the entire system through different releases. The goal is to move off of the manual boat and onto a more automated boat!


    Phase 2


    While most of our tests are still manual, an introduction to automated GUI testing has begun. Typically, in legacy code, the business logic and the user interface is tightly coupled. Because of this, GUI tests are the only automated way to provide a full, end to end test of the system. GUI tests mimic the end users actions on the screen. It's as if a person is there performing actions on the screen. While GUI tests are slow, brittle, and prone to error, this is not the ideal way to automate tests but is the biggest bang for the buck to start off with that typically requires very little, if any, code refactoring.


    Phase 3


    Introduce a new form of testing, the integration test. This layer of testing is not designed to be end to end as a GUI test does, it does test smaller chunks of code but are more reliable than a GUI test and can be ran much more frequently. Starting out, integration tests can be hooked up to a Continuous Integration (CI) server to alert the developers if they have broken a build and get it fixed sooner rather than later.

    This is the first major paradigm shift that developers need to learn is to how to write code that can be easily testable. This type of testing will more than likely require code refactoring in order to create independent tests.

    In this phase developers need to start thinking about how to loosely couple their code in order to further test it. Ultimately we want to move into a very dumb User Interface.


    Phase 4


    Unit testing is the fastest, most reliable type of test but tests the smallest amount of code. With unit testing, we create mock objects, run the data through a method or a small group of methods, and test the result. These tests are fast because they do not require connections to external sources like a database or a remote service.

    More code refactoring will be required in this phase. This phase will further introduce concepts such as Dependency Injection and IOC (Inversion of Control) in order to "fake out" data in order to isolate the specific method(s) we are testing for.

    In the end, because unit tests test the smallest chunk of code and are the most reliable type of test, we will have more of these kinds of tests than any other.


    Phase 5


    Phase 5 is a refactoring/building stage. Armed with the knowledge of unit and integration testing and experience in refactoring code to write these tests, we need to build up our test suite. This phase will focus on paying back the technical debt that has accumulated over time and begin structuring our code in a testable manner.

    This phase will begin to introduce design patterns such as Model-View-Present (MVP) for Windows Development or even Model-View-Controller (MVC) for web development. Begin introducing how to develop and refactor code in this design patterns. Writing/refactoring code in a design pattern enforces a separation of concerns between the user interface and the business logic. This will allow us to test end to end, functional requirements, effectively testing as much code as possible without doing a GUI test.


    Phase 6


    Now that we have refactored code in a much more testable manner, we need to introduce Functional Testing. The idea behind functional testing is that we test functional requirements from a business perspective. Having our code in the MVP design pattern will allow us to test functionality below the user interface. This will allow for faster, more reliable tests than GUI tests and it keeps our tests running even when the GUI is changed.

    The end goal is solid software. How does test automation get us there? It takes time, and there is some risk getting there, but if we take short, iterative steps, it can be done! Be sure that when developers are writing tests that a member of QA pairs with them (or at least reviews each test). They’ll ensure the developers write valuable tests. Over time you’ll find the developers learn what the QA team members need tested, and the QA team will start to learn what types of scenarios are easiest to automate. This will result in even faster and more effective test creation in the future!



    1. At minimum, create different projects for different types of tests. Create an integration test project, unit test project, and a GUI test project. If you have a large number of GUI tests, you may want to consider having that as a separate solution and have those broken down. One advantage of breaking tests up into multiple projects; you decide which tests can run when on a Continuous Integration server.

    2. Run unit and integration tests as part of the build on the CI server. This will guarantee developers are notified in a timely manner if they have broken code. The sooner broken code (and the test) is found, the sooner it can be fixed, and the cheaper it is to fix!

  • Wednesday, January 12, 2011

    5 Characteristics for an Effective Daily Stand Up

    One practice of Scrum is a daily stand up meeting.  Why?  It serves as a status update of how the team is doing and allows each team member to feel an ownership and be accountable of the process. 

    Characteristics of an Effective Stand Up

    1. Stand Up! - this keeps the meeting short and more engaging.  Harder to fall asleep when you're standing up!
    2. Consistent - same bat time, same bat channel, and be the top priority of every team member to attend.  Ideally, they occur in the mornings, right after everyone has arrived, to set the direction of the day.  If your team has a staggered work schedule, make it late enough in the day so people don't use the stand up to start their day.
    3. Quick - each person has a maximum of 60 seconds to answer the three golden questions:
      1. What did you do yesterday?
      2. What are you doing today?
      3. What roadblocks are you facing?
    4. Focused - the person facilitating the meeting (typically the Scrum Master), needs to keep team members focused and engaged on those three questions.
    5. "Meeting after the Meeting" - team members often need clarification from another team member(s), talk to them after the stand up, not during it, so as to not take up everyone else's time.


    • Use Skype for Remote team members - use Skype or some other voice communication tool.  I'm on a team with one remote person but the other team members are in the office.  The team stands up around a PC with a web cam, a desktop microphone, and desktop speakers, and Skype the remote member.
    • Make sure team members answer questions effectively.  "I did stuff yesterday and am doing more stuff today", doesn't count!  We have a ticketing system for each story.  The answers should give an adequate status of what the team member is working on.  For example, "I'm working on the Create functionality for creating a member and should be done with it tomorrow.  I have no blocks" is much more effective. 
    • Follow up the next day if something was expected to get done but did not and determine why not.
    • Foster an environment of supportive accountability.  Keep your team members accountable to what they say they are going to do but encourage team members to help each other when needed!

    Additional Resources
    Martin Fowler’s - It’s Not Just a Stand Up
    Daily Scrum