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.

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)

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.htmlWe 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

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

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

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

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

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.