Developer blog banter #3 Response–Community coding

This is my response to https://davidburela.wordpress.com/2012/04/17/developer-blog-banter-3-show-tell/
Share a single interesting thing you’ve worked with recently. A tool, framework or technology for example.

The coolest thing that I’ve used recently has got to be the combination of https://GitHub.com + Markpad
I had used GitHub frequently in the past as a consumer of data. To download OSS applications to use, or .Net frameworks to include in my projects.

However, recently a tweet caught my attention.

People need to stop putting code in zip files on their blog and use a scm hosting provider like github or something.

— David Fowler (@davidfowl) April 8, 2012

I realised that my usual workflow when writing a blog post was:

• write the code examples in the post
• create a working sample application
• zip it all up
• host the the .zip file somewhere for readers to download.

After that the code always went stale and I never updated it. David Fowler got me thinking “He is correct. I really should make it easier for others to pull down my source code. And at the same time make it easier to update for when I use the same code in user group presentations”

I created my first few repositories https://github.com/DavidBurela and uploaded the source code for a Windows Phone 7 application and source code samples from presentations I gave. GitHub makes it really easy to get started and they have a heap of resources to get started.

With my repositories created and ready to share with the world, there was just one thing missing… a proper README file. When someone navigates to your repository, GitHub looks within the repository for a README file, if it finds one it renders and shows it. Its a great way to give people an introduction to what your repository is for. An example can be seen in my WP7 repository https://github.com/DavidBurela/Windows8DeveloperCampPhoneApplication

The README file is written in a format called MarkDown (as opposed to mark up languages). It can be difficult to write the README files without seeing rendered in real time. This is where MarkPad comes in. It is a MarkDown editor with real time previews.

These 2 products have made my life that much easier to share code with the community. It can be difficult configuring your system with Git for the first time. I have included some links below to help you get started. (But it has been rumoured that GitHub are creating GitHub For Windows, similar to their GitHub for mac client. Which should make things much easier in the future)

Links to get started with Git & GitHub

• Setting up Git (ESSENTIAL READ) http://help.github.com/win-set-up-git/
• The simple guide to using Git http://rogerdudler.github.com/git-guide/
• A guided tour of Git http://gitimmersion.com/
• Scott Hanselman’s guide to contributing to a GitHub repository http://www.hanselman.com/blog/GetInvolvedInOpenSourceTodayHowToContributeAPatchToAGitHubHostedOpenSourceProjectLikeCode52.aspx

By David Burela

Developer Blog Banter #3: Show & Tell

After a long hiatus, it is time to continue with the Developer Blog Banters (DBB). Each banter focuses on a single topic allowing passionate developers to blog on a common topic. The goal being to get more developers blogging and cross posting within the community.
Previous banters asked developers to “What their current technology stacks look like” and “How do you test applications”. More information about the blog banter can be found at https://davidburela.wordpress.com/developer-blog-banter/

The guys over at Code52 this week ask you to share a single interesting thing you’ve worked with recently. A tool, framework or technology for example.

http://code52.org/show-and-tell.html
We want to hear about what you have been working with in your spare time. We want to hear about the cool stuff we haven’t had a chance to use. We want to get jealous about hearing how you’ve used it and what you’ve learned about it.

We’re looking for people to write short articles on stuff they’ve used recently or something they’ve built recently to share with the big wide world.

We want to hear:

• what did you find that is awesome?
• what is awesome about it?
• how did you use it?
• what did you learn from using it?
• is there some code that people can have a play with?

As usual, post a trackback to this post and I’ll update the list of responses, allowing everyone to easily view posts participants. This also lets the Code52 guys see a consolidated list of responses that are currently online. You may even get your post featured on the Code52 blog! http://code52.org/blog.html

Participants

1. Tugberk Ugurlu – Generic Repository Pattern series
2. David Burela – Community coding (GitHub + MarkPad)
3. Gareth Bradley – My open source application
4. Duncan Bayne – Automating provision of virtual machines for use as build agents

By David Burela

Developer Blog Banter #3: Project post-mortem

It is nearing the end of the year and many of you would be near the end of your projects. I thought this would be a good time to look back and reflect on one of the projects you completed this year. The best way for us to learn is to reflect on what we have done, and analyse what we could have done better. This leads us to the Developer Blog Banter topic for this round.

We start on new projects with good intentions, but how often do we reflect on what we have done to see if we got to where we had planned?
Take your current or recent project one and discuss it. What were your intentions at the beginning of the project (to do it “right” this time, 80% code coverage, get it out by a deadline, learn a new technology, etc.). What compromises did you end up having to take. And what would you change if you could do it all over again.

As usual, comment on this post when you join the Developer Blog Banter and I’ll add your response below

Participants

1. David Tchepak – Lessons learned from an Agile project

By David Burela

Developer Blog Banter #2 response

This is my response to the 2^nd Developer Blog Banter. The question asked is

How do you organise your tests. Do you separate your unit tests, integration tests and UI tests into separate projects? Do you do anything specific to keep track of your tests? What naming conventions do you use? Do you run them before a check in or is that what the build server is for?

Structure

Most of my testing efforts focus on unit testing. I structure it so that I have a unit test project per code project. For example

DavidSolution
/BusinessLogic
/BusinessLogicTests
/MoreCode
/MoreCodeTests
/…

If it is a really small application with only a logic project and a host, then I will usually roll the tests into a single unit test project.

Naming conventions old

My naming conventions of my unit tests have change from project to project. On my last project I used to put all unit tests for a class into a single test class and do name each test something similar to this TheBusinessLogicCreatePersonMethodShouldReturnANewPerson()

However I found the names too long to quickly see what broke. Having them all the tests in a single TestClass combined with the tests being sorted alphabetically in the test results it would make it really hard to see what area of my code had broken.

Naming conventions new

I was talking to Damian Maclennen who showed me an example of how he is setting up his BDD tests. I took his approach of using extension methods and bastardised it into my new naming convention.

In my unit test project, I have a namespace for each logic class I am testing. E.g. Person
DavidProject.BusinessLogicTests.Person

Inside of that namespace I have a TestClass for each method I am testing on that class. I name the test class with the method name and ‘Should’ appened to the end, e.g.
CreatePersonShould

Finally I have all of my tests for that method inside that class. This brings it out so my tests look like

namespace DavidProject.BusinessLogicTests.Person
{
    [TestClass]
    public class CreatePersonShould
    {
        [TestMethod]
        public void NotCrashWhenPassedNull()
        {
        ....
        }
    }
}

When I run my tests in Resharper, I will then see all of the tests nested nicely by class name, and then all of the tests for that method.

When do I run them?

Whenever I change a big chunk of code. I don’t practice TDD, I usually create tests and code together as I write (or slightly after I have finished writing the code).

I haven’t set it up to run them on the build server on my current project, that is something I’ll get running this week.

Other forms of testing

I don’t do automated UI tests as I feel the effort required to script them isn’t worth the pay off as they are very brittle.

By David Burela

Developer Blog Banter #2: How do you test your applications?

Last time we discussed how you organise your technology stack. This month’s discussion point is around testing your applications.

How do you organise your tests. Do you separate your unit tests, integration tests and UI tests into separate projects? Do you do anything specific to keep track of your tests? What naming conventions do you use? Do you run them before a check in or is that what the build server is for?
If you are not testing, then how would you like to test your apps if given the opportunity?

I apologise, it has been a while since the last Developer Blog Banter. I was too busy getting my applications ready for the launch of Windows Phone 7.

As usual, comment on this post when you join the Developer Blog Banter and I’ll add your response below

Participants

1. David Burela – testing applicaitons
2. Liam Mclennan – testing, huh! what is it good for?
3. Tarn Barford – How do you test your applications?
4. Eric Ridgeway – I can haz tests?
5. Peter Gfader – How do you test your applications?

By David Burela

Developer Blog Banter #1: What is your preferred technology stack

Here is the first edition of the Developer Blog Banter. The DBB is a regular article where passionate developers in the community blog on a common topic.
More details and a list of all editions of the DBB is available on the main page https://davidburela.wordpress.com/developer-blog-banter/

This weeks topic is was inspired by a recent blog post by Paul Stovell.
When starting a new software project, what is your default choices for your technology stack. What common libraries and toolkits do you find yourself reusing again and again.
You can answer the question either from the perspective of “your perfect personal project”, or what your standard choice is for what your day job requires.

Some suggestions to help you get started

• What UI technologies are you using, web? ASP.Net vanilla, ASP.Net MVC, WPF, Silverlight, Ruby, etc.
• What would you use to persist / retrieve data. nHibernate, Entity Framework, perhaps you’re using MongoDB as your store.
• What testing tools / frameworks do you use.
• Are there any other supporting frameworks you would use in your stack, like Log4Net.

If you need some inspiration or ideas on how to format your response, look at the current list of participants.

Participants

1. David Burela What does your current tech stack look like
2. Paul Stovell The ultimate Lib folder
3. Liam McLennan My technology stack
4. Duncan Bayne What is your preferred technology stack?
5. Michael Minutillo My (magic unicorns) technology stack
6. Simone Chiaretta My ASP.NET MVC stack and why I chose it
7. Damian Maclennan What’s your current stack?
8. Eric Ridgeway My technology stack
9. Ko Chang What is your preferred technology stack
10. Paul Batum My technology stack
11. Composite code My software stack

By David Burela