This is what I consider to be my list of ‘essential’ tools / skills for a serious .Net developer.
An Agile or Lean methodology
If your projects are not being delivered successfully Scrum will either enable you to start delivering software, or highlight the reasons why you aren’t.
The Scrum Guide which contains all the rules of Scrum is 13 pages long. There is no excuse for not having read it.
If you aren’t doing Scrum, or you aren’t doing it well… get some help.
Out of the box, it gives you so much. I find it incredible how many people have TFS but are only using it for Source Control.
Learn both Team Foundation Source Control and Git, and the strengths of each.
Work Item Tracking
Being able to successfully deliver value to the customer while triaging bugs requires efficient work item tracking processes and tools.
Why-oh-why isn’t everyone doing CI?
Check in your code, have a magic fairy build it, test it and tell you if you’ve broken anything – sounds too good to be true AND it only takes 60 seconds to setup!
‘Fail Fast’ is probably my favourite development catch-phrase: If you find out that the code you’ve just checked-in conflicts with some-one else’s code 2 minutes after you’ve checked it in, it’s easy to resolve the issue. If you only find out there is an issue a week later, it’s much harder.
Get your CI fairy to take the code she builds and then deploy it to a server for you.
If every time you finish a task you can send the user a link to the test server that you just deployed to and say ‘tell me what you think’. The customer will LOVE you… and you get feedback when it’s most helpful.
If you are using Azure, continuous deployment is just so damn easy.
Also, I am having a little love affair with a tool called Octopus Deploy http://www.octopusdeploy.com. Check it out!
As a .Net guy… you need to be familiar with Azure.
It’s remarkable how easy it has become to build and deploy web applications to the cloud. In 30 minutes I can create a source code repository on http://visualstudio.com, check in an MVC project and have it continuously deploying to an Azure website with both Release and Staging environments.
Check out Andrew Coates from Microsoft doing continuous deployment to Azure at FireBootCamp.
Azure is so much more than just websites… but as this is a ‘need to know’ list, I’ll force myself to not go on about how awesome Azure VMs and Web Roles are. If you take an interest in the cloud, Azure is a platform that will have you boring all your friends with tales of how cool it is.
Communication and interpersonal skills cannot be overemphasised. No matter how smart someone is, you don’t want them on your team if they can’t work as part of the team.
- You need to know how to take instructions
- You need to know how to provide feedback
- You need to know how and when to push back, and when to give in
- Sometimes, you just need to shut-up
Patterns, Practices and Principles.
This is the stuff I’m REALLY passionate about.
Building a complex application, that is still going to be maintainable after you have added features to it for several years requires some skills. My mission is to increase the understanding amongst .Net developers that the following are essential, not hard to learn, will improve your job satisfaction and your employers opinion of you when you continue to add value to his application well after other projects have ground to a halt.
This is not about swapping your SQL Database for an Oracle one!
There are many, many benefits to Dependency Injection: Here is the major one for me – you need dependency injection to ensure that your complex system is built in such a way that changes to one module does not cause flow on effects in other modules.
Typical on many projects: first 10 features get thrown together in a week, the next 10 features take 2 weeks, the next 10 take a month, and then every subsequent feature takes longer and longer because of the changes that need to be made throughout the project to implement the new features.
Dependency Injection is about ensuring you can continue to add features to your complex project.
Essential Reading: Dependency Injection in .Net by Mark Seeman
I’m not a code coverage guy. I don’t believe every single line of code needs a unit tests.
I believe the following
You NEED to be able to write great tests.
Your application should have unit tests over 100% of the code that requires unit tests.
This is a topic that I can (and do) talk about for hours, but in summary:
I write tests
- for fragile code, or code that is likely to break
for important code that you cannot afford to break
for code that is hard to read: Well written unit tests are the best form of documentation after well written code.
when writing the test provides me clarity about the code that I am about to write (slipped my TDD hat on there for a minute)
- When writing a unit test will save my boss money because it’s faster than the (damn) debugger
One of my favourite rants: It is often faster to write a unit test than to test the code you have just written any other way.
I see this a lot and it drives me crazy: I’m testing the credit card validation of my online store. I want to test the submitted card number against a regex before I submit it to the Bank.
Debugger Guy: I hit F5, wait for the whole solution to compile, the website to spin up and the debugger to attach. I then select several items to add to my cart, click next, enter my name, phone number and address, click next, enter the credit card number and click next, realise there is a typo in the Regex, click Stop, change one character and press F5 again ! aaaaaarrrrggghhh !
Unit Test Guy: Writes a 5 line unit test in half the time it takes Debugger guy to even reach the code, gets feedback in milliseconds, provides great documentation about what the regex is validating and ensures that changes to the code in the future do not invalidate the current requirements.
Essential reading: The Art of Unit Testing by Roy Osherove
My session on unit testing: Eat your vegetables! Baking Healthy Projects with Unit Testing and Dependency Injection
Common patterns like Repository and Unit of Work
Patterns are important.
They provide a way for developers to communicate about common problems and suggested solutions.
I hate to re-invent the wheel when smarter people have already come before me and done most of the heavy lifting.
Familiarity with common patterns (the good and the bad) is essential to any senior developer.
Clean Code & SOLID Principles
If software were disposable, I wouldn’t be writing this post.
If I could write software today, and then walk away and never have to look at it again I may not care about the day next year when I have to come back and make sense of it – but I do.
Because I have to maintain my code – I should very much care about making it easy to maintain. This is where the idea of ‘Clean Code’ and the SOLID Principles come in.
Essential reading: Clean Code by Robert Martin
Professional developers should be proud of the code they write.
I struggle to understand why most developers still don’t have a good understanding of the above topics. I strongly believe that these areas should be lived and breathed by every member of a development team.
Once again, you don’t have to always use them… but if you don’t have them in your tool-belt you’re selling yourself as a professional carpenter when you don’t even own a hammer.
I’ve deliberately left this until last.
Although most job descriptions are full of technologies, I believe that knowledge of the topics above are far more important.
Here is the current set of technologies that we use by default to build most of our web applications.
- Frameworks and Toolsets-> we like to keep across what’s out there, and being consultants doing new projects all the time we get to try out different things but our default stack at the moment is
- Twitter Bootstrap
- Telerik KendoUI
I deliver large, high performing web applications for enterprises. The processes, tools and technologies above are what I believe an enterprise web developer needs to know. Obviously other development disciplines require very different skills sets.
In many scenarios other tools, frameworks or methods may be more appropriate, but before you start learning all the alternatives you should know and understand the mainstream choice. Then you are qualified to have an opinion about whether something else is better.
I am running Windows 8 and Visual Studio on my Mac using Parallels.
The project I am currently working on is configured to use IIS Express, but I want to test it using a VM that contains IE8.
As it turns out this was quite simple to setup.
1. Download the VM from http://www.microsoft.com/en-au/download/details.aspx?id=11575 or http://www.modern.ie/en-gb/virtualization-tools
2. Open the VM using Parallels (File, New, Add Existing Virtual Machine).
3. Change the Windows 8 VM and the VM containing IE8 to both obtain their own IP addresses from the local WiFi router.
Virtual Machine | Configure | Hardware | Network. Change type to WiFi
4. Change the configuration of the web application to use the Windows 8 VMs IP Address
5. Edit the binding in your IIS host config file
(You can find it in %userprofile%\Documents\IISExpress\config\applicationhost.config )
Find the entry for your application and change it from from
<binding protocol=”http” bindingInformation=”*:63527:localhost” />
<binding protocol=”http” bindingInformation=”*:63527:10.0.0.20″ />
6. Disable windows firewall on the Windows 8 machine.
7. Run Visual Studio as Administrator and run the application. It will now be accessible from the IE8 Virtual Machine.
The default Agile TFS template ships with three states: New, Active and Closed.
A common question that I am asked is how to add an extra stage to the TFS taskboard.
While this is not trivial in TFS 2012, it’s really not that hard once you know how, and is being made easier in newer versions of TFS.
Figure: We will demonstrate adding a ‘Testing’ column.
Step 1: Ensure that you are an administrator of the Team Project you are updating
Step 2: Download the Team Foundation Server 2012 Power Tools
– In Visual Studio select Tools, and then Extensions and Updates
Figure: Select Online from the left menu, enter Team Foundation 2012 in the search field, click the Download button on Microsoft Visual Studio Team Foundation Server 2012 Power Tools
Step 3: Export the Task Work Item Type
To add a new column to the task board, we need to add that status to the work item type definition.
Figure: From the Tools menu select, Process Editor, then Work Item Types and then Open WIT from Server
Figure: Expand the correct Team Project and select the Task work item type.
Step 4: Add the Testing state to the Task WIT
Figure: Select the Workflow tab. Open the toolbox and drag a State component onto the design surface. Right click on the new State, select Properties and set the Name property to Testing
Figure: Select the Transition Link component from the toolbox. Now click on the Active state and drag your mouse to the Testing state.
Figure: A transition will have been added from Active to Testing.
Figure: Right click on the Transition and choose Open Details. Go to the Reasons tab and Edit the reason value. Suggested test: ‘Ready for Testing’. You can click on the chevrons to expand the transition to be able to more clearly see the assigned properties.
Additional actions and Fields can also be specified but that is beyond the scope of this post.
Figure: Repeat the process above to add transitions from Testing to Complete (with a reason of ‘Testing Complete’) and from Testing back to Active (with a reason of ‘Failed Testing’).
Figure: Save the template to a known location on your hard drive so that it can be imported in the next step. E.g. c:\Temp\TeamProjectName_Task.wit
Step 5: Import the saved WIT
Figure: From the Tools menu select Process Editor, then Work Item Types and then Import WIT.
Figure: Browse to the location of the saved file, select the Team Project you wish to import the WIT into and click OK.
Figure: When you edit a task, the Testing status is now available. It is not yet however added to the board.
Step 6: Export the Process Template Config
This is the part that I always forget to do. After you have edited the Work Item Type, you still need to update the process template to include the State on the Task Board.
Figure: Open a command prompt, change to the Visual Studio IDE Folder and execute the following command
witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin exportcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Step 7: Edit the Process Template Config
Figure: Edit the exported file. Find the section for TaskWorkItems and add the line highlighted above.
<State type=”InProgress” value=”Testing” />
Save the file.
Step 8: Import the Process Template Config
Figure: Execute the following command
witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:”DirectoryPath\CommonConfiguration.xml”
for our instance the command required was
witadmin importcommonprocessconfig /collection:http://ourserver:8080/tfs/CollectionName /p:ProjectSparrow /f:”c:\Temp\CommonConfiguration.xml”
Figure: View your task board and you will have your new column!
Peter Gfader knows how to ship software. In this interview we chat about Clean Code, testing and continuous improvement
Using a precision mocking framework (such as Moq or NSubstitute) encourages developers to write maintainable, loosely coupled code.
Mocking frameworks allow you to replace a section of the code you are about to test, with an alternative piece of code.
For example, this allows you to test a method that performs a calculation and saves to the database, without actually requiring a database.
There are two types of mocking framework.
The Monster Mocker (e.g. Microsoft Fakes or TypeMock)
This type of mocking framework is very powerful and allows replacing code that wasn’t designed to be replaced.
This is great for testing legacy code (tightly coupled code with lots of static dependencies) and SharePoint.
Figure: Bad Example – Our class is tightly coupled to our authentication provider, and as we add each test we are adding *more* dependencies on this provider. This makes our codebase less and less maintainable. If we ever want to change our authentication provider “OAuthWebSecurity”, it will need to be changed in the controller, and every test that calls it.
The Precision Mocker (e.g. Moq)
This mocking framework takes advantage of well written, loosely coupled code.
The mocking framework creates substitute items to inject into the code under test.
Figure: Good Example – The code is loosely coupled. The controller is dependent on an interface, which is injected into the controller via its constructor. The unit test can easily create a mock object and substitute it for the dependency. Examples of this type of framework are Moq and NSubstitute.
Unit testing and Dependency Injection are good for you, yet these essential ingredients are missing from many projects.
In this session I look at why many projects still don’t include unit tests, and provide some recipes for healthy projects that every coder should have in their recipe book