Random

So I haven't blogged lately mostly because I haven't done anything really cool lately to discuss.

That said here are some random things....

Some good sites.

StackOverflow is a site I love. I really don't ask or answer a lot of questions but I do read many. It is very informative. It is odd when you interview people and ask them where they go on the internet to look for help and very few people mention this site, until you ask them about it.

IWantMyMVC is another fun site. I really haven't used a lot from it but I like how they show good ways to solve problems in the asp.net MVC.

Another place I have been going on the web is here and here. I love my new windows phone 7.

Well that is it for now. More to come soon, I promise.

We Are Hiring

Take a look at the StackOverflow ad for more details. We're hiring 2 Senior developers and 2 Junior developers (and more: QA, BA, and a GUI developer). It's a fun environment with a strong technical team, so we're looking to keep the team strong. If you're around the Milwaukee area and are interested in more details, let me know.

Scrum Master

Monday July 18th and Tuesday July 19th I attended Srum Master Training.

Going in I was excited at the opportunity to learn more about Scrum and to become a better Scrum Master which is on of three roles in the Scrum process. I just recently took on this role part time. Although I have been doing scrum for for 5 years, I have always been part of the team role.

At the training I learned a lot. I enjoyed the mini games and group activities we did to help show how agile ideas can help improve managing change and unknowns. I also like how it broke down all the roles and responsibilities. I like the ideas of self organizing teams, and that the traditional conflict project manager face are separated by the scrum triangle.

Yesterday I finally took the scrum master certification exam, and passed with flying colors. I only got one question wrong. So yes it is official I am certifiable!

All in all it was a great time and now the next challenge is improving our process where I work.

Subversion Setup for c# Developers

At work we use TFS for everything and I hate it. I like Subversion and find it very easy to use.

I often hear that Subversion doesn't integrate well with visual studio, and that it is hard to setup and run. Well both these assumptions are wrong.

If you are running any of the windows OSes all you have to do is install SvnServer, configure it, install TortoiseSVN so you can work with svn projects from window explorer. Finally in the extension manager in visual studio and install AnkhSvn or get it here. This will give you svn support in visual studio. below will be step by step with pictures.

Svn Server install

After downloading the msi, you will be presented with some config sections. There are two that really matter. The first pictured below will ask if you want the console along with the repositories. The second pictured below will be configuration for the repositories themselves.

once installed open the console and create your first user and group. I have a group for each project. Lets add our first user. Right click on the Users folder and click Create User. Fill out the dialog with username and password.

Lets add our first group. Right click on the Groups folder and select Create Group. A dialog will display. Fill in the name and add users to it. Once done click ok.

Then add a repository by right clicking on Repositories and Create new repository. Give it a name and check the create default structure.

Then add security to the repo by right clicking on the new project and selecting All Tasks => Manage Security. Change everyone to No Access, and add the group you created earlier with Read / Write.

Thats it for SvnServer.

TortoiseSvn

Just install it and when in windows explorer you can right click on folders and there will be an added menu that allows you to do svn things, like checkout projects, update directories, commit changes and much more.

AnkhSvn

This is a plugin for visual studio 2010. To install it from visual studio go to extensions manager, click on online gallery => tools => source control and select AnkhSvn. It is free and it is awesome.

So after you create a new solution in visual studio, right click on the solution folder and select 'add solution to subversion'. Next fill in the repository url, and click ok. Thats it, it will now map your solution to your repository. Finally right click on the solution file and select, 'commit solution changes'. A dialog will open showing all modified files and gives you a chance to add a check in comment, do so and click ok. It will do it's thing and once done your project is now secure in your repository.

If you want to update your solution to the version in the repository just right click again on the solution file and select 'Update Solution to the Latest Version'. You can also select what version you want, revert local changes or anything else that is support by subversion.

BDD and Specflow

So recently I did a talk on BDD and showed off Specflow. Below are some of my notes from the talk, and I will try to find a place to host the code from the talk.

BDD

Technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally named in 2003 by Dan North[1] as a response to Test Driven Development, including Acceptance Test or Customer Test Driven Development practices.

BDD focuses on obtaining a clear understanding of desired software behaviour through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read. This allows the developers to focus on why the code should be created, rather than the technical details, and minimizes translation between the technical language in which the code is written and the domain language spoken by the business, users, stakeholders, project management, etc.

Some Jargon

Stakeholder

A Stakeholder is a person who gets some value out of the system. Typical stakeholders are representative of groups of users, for example a trader or an administrator.

Feature

A Feature is a piece of system functionality that delivers value to one or more stakeholders. Executable specifications work best when described from the perspective of stakeholders, not technical infrastructure, since doing so enables business users to understand them better and engage more in discussions about what makes a particular feature complete.

Features are normally vertical functional slices of the system, for example transaction processing. Horizontal infrastructural slices, for example authorization, are not good as features. They do not deliver value directly to any stakeholders. Stakeholders will not be able to engage properly in specifying the acceptance criteria for such functionality, pretty much defeating the point of specification by example.

User Story

A User story is a rough description of scope for future work, used as a planning tool. Stories are vertical slices of system functionality that are deliverable independently. Each story should specify the value it brings to one or more stakeholders, the stakeholders that care about the story and the scope of the intended work. A common format for the stories is:

As a ..., I want..., So that... or In order to..., as a ..., I want ...

Stories often impact several features — a payment story might have an impact on transaction processing, fraud control and back-office reporting. Stories are often relatively small chunks of work to support frequent delivery. A single feature might be delivered through a large number of stories.

Good stories are not broad in scope and should be able to kick off a meaningful discussion.

What is SpecFlow (specflow.org)

A Tool to bind business readable behavior specifications to the underlying implementation. ie creates "Acceptance" test stubs for your features/User Stories, to help know when done is done at least for development.

Feature File

A Feature file describes a feature or a part of a feature with representative examples of expected outcomes. Specflow uses these files to validate some system functionality against its specifications. Feature files are plain-text files, ideally stored in the same version control system as the related project.

Each feature should be illustrated with Key Examples (Scenarios). The examples show the expected outcomes in specific representative cases with very precise information. This makes it absolutely clear what the system is expected to do and helps to avoid any misunderstanding and ambiguity. It also makes it possible for Specflow, to check whether the system works according to the specification.

Scenario

A Scenario captures one key example for a feature in the feature file. It represents a way that the system delivers some value to a stakeholder. Scenarios are units of specifications for Specflow. Scenarios allow us to chop up feature functionality like Sushi, into chunks that can be separately consumed. Examples of good scenarios for credit card processing might be successful transaction authorization, transaction failure due to lack of funds, transaction failure due to wrong verification code and so on.

Steps

Steps are domain language phrases that we can combine to write scenarios. They can either refer to the context of a scenario, an action that the scenario describes or a way to validate the action.

What Makes a Good Feature File

The long term benefit of using Specflow comes from living documentation, a source of information on system functionality that is easily accessible to everyone and always current. To achieve that, a feature file should be:

• Easy to understand
• Consistent
• Easy to access

To serve as a target for development that prevents misunderstanding and ambiguities, scenarios in a feature file should be:

• Precise and testable
• Specifications, not scripts
• About business functionality not about software design.

Once a feature is implemented, the related file becomes a living document for the feature. To allow the software to evolve and provide functional regression checks, the scenarios should be:

• Self explanatory
• Focused
• In domain language

Most importantly these files should be written collaboratively... BAs, Stakeholders, QAs, and Devs

So once the feature file is written Specflow will create some stubbed tests of the scenarios. the development team's responsibility is to fill in the stubs, and then make these tests pass. This does not mean that the developer wont need to write unit tests, since the tests created by Specflow are more broad in scope.

So once all the Specflow tests pass the developers know they have met the needs of the Stakeholder and can confidently check in their code.

Walter Peterson

My Grandpa passed away last week and I wanted to write some things in memory of him.

The Joker.

My Grandpa had a great sense of humor. He was witty and always had a joke ready. The great thing though he wasn't funny to be the center of attention, he just wanted to make you laugh. My favorite joke of his was when he told me "he dropped out of school in the 5th grade." I was ready to hear something about tough times and need to work for the family, but as he continued, "well I had to because my dad was in the 6th grade and I didn't want to pass him up." It made me laugh and that joke got recycled through the entire family, my dad and uncles saying the same thing and I even used it once.

The Story Teller.

Some might think of my Grandpa as a quiet man. They wouldn't be wrong because he had a quiet cool to him. He could sit and listen to others, but he could also tell a great story once you got him going. I remember sitting and listening to him tell me about my Dad and Uncles when they were growing up, and some stories of his time serving as a MP in the Army Air Force. Or about when he met Grandma. He surely talked my girlfriend's ear off when we would go to visit, since he saved some of his best stories for her. Mostly were about me when I was little.

Grandpa I am going to miss you. I know you are back with Grandma and in a better place. Just know I love you and will never forget you.

jQuery UI and MVC

So I have been working on an ASP.Net MVC app in my spare time and have found at times that the UI is a little stale and clicky. What do I mean by clicky, well I mean the user has to do a lot of clicks to do certain tasks. All these clicks require full post back to the server. I like how I broke up the tasks into steps, but wanted a jazzier way to for the UI to work with the user, so low and behold I added some jQuery UI widgets and the whole process seems way smother and even a little quicker.

First let me talk about jQuery UI. It is a bunch of Widgets and UI interactions developed in jQuery. What is super cool is they have a theme editor so I could easily take the color scheme from my site and theme the widgets so they look like they belong on the web pages. The widgets included are Accordion, Auto Complete, Button, Date Picker Dialog, Progress Bar, Slider, and Tabs. The interactions are Dragable, Dropable, Resizeable, Selectable, and Sortable.

So far on my website I am using Tabs and Dialog. Now I want to state that in my Web Forms days I did work with AJAX.Net controls and although not difficult to use, no where near as easy as jQuery UI has been. To intergrate a dialog box on the page all I had to do is create a div tag and wire the jquery code to the tag. The Tabs was a little more work, however it was just create some simple HTML and wire that html to jQuery.

In my next post I will try to show code examples for both of these process. I was going to do it here, but was having trouble with my code syntax highlighter plugin and it was not looking good.

WiZdl Tool for Testing Services

This is a blog post I should have done months ago, but finally I am getting around to it.

Where I work we have many web services to support. Every new release it seems we are adding to the services or making changes to them. From the development standpoint we can create unit tests to test parts of the service, but when the QA folks need to do their testing it was a challenge. See we created an MVC app that just wrapped the services and the QA could use this app to do their testing. It worked ok until one day we started getting bugs opened. See a lot of the bugs were really with the test app and not the services. So now we have to support not only the services but a throw away test app.

I said to myself that this has to change. So I searched for a better way. What I found was the Wizdl tool. This is a great tool. It is not pretty or anything but it gets the job done. How it works is simple. You point it at the web service, and it dynamically creates an interface for it. you can then enter the needed data and it executes the service. On top of that it gives you some other nice things like, taking the response up into fields and displaying the data. It also shows the soap messages for the request and response. The tool also lets you save your data as an xml file so you can load it up later and do a regression test.

If you have to support web services check this tool out. It is free and works great.

Happy New Year!

Happy New Year to you all. Hopefully you will have a healthy and fruitful 2011.

This time of year really gives me time to reflect on the things I did in the last year and where I really want to grow my skills in the coming year. In the last year I really focused on MVC.Net for the most part. I also took some time to look into Entity Framework, Silverlight, StructureMap, NCommon, among some hardware concepts like the cloud.

In the coming year I am planning to look into Razor view engine, more jquery, and Nu Get, added functionality of MVC 3, BDD, and DDD. I am also going to learn more about Scrum. I have been doing Scrum in some form for the last 5 years and really think I need to understand it better to make it a more useful tool for working on projects.

Well that is where I plan to take my skills in the next year. Like all plans of course I may hit a crossroads and explore somewhere else.