Ian Battersby
There is nothing worse when mixing business with pleasure or in this case - commercial priorities with open-source - than a battle between the heart and the mind; certainly that's the saddening feeling I have about Spark.
Always keen that our adopted environment shouldn't dictate tooling it was important that we could achieve a good level integration between with testing tools and Team Foundation Server; however as TFS 2010 moved to using web services and XAML build workflow it can look rather challenging.
Despite my love for all things DVCS, DAG, and Git it's no secret that there is one area of TFS 2010 that I am quite fond of - Visual Studio Lab Management. Utilising Microsoft Hyper-V technology it allows us to manage and use virtual machines in building, testing, and deploying applications.
If like me you don't want to have duplicate copies of your bin dependencies between your libraries/packages folder and \_bin\_deployableAssemblies you'll want to link them; unfortunately the default Microsoft.WebApplication.targets won't publish them - absurd I know!
Just thought I'd drop this quick note should you also find the settings on the Araxis website don't work with your .gitconfig, I went through many attempts but this simple version worked for me.
Many people have been asking to know more about Ripple, a tool from the Fubu-family that allows you to manage your NuGet dependencies both locally and hosted. Still quite a new tool (knocked up by Jeremy & Josh over a hot beverage I believe) it's early days but am already finding it invaluable in our solution management.
In the previous post in this management series we examined how we can improve the accuracy of our estimation, how it can be best tailored to service the needs of the business, and how we can automate it towards our goal of a self-managing team. Before we get ahead of ourselves we must return to our current position on the team evolutionary scale and examine other time-consuming elements of the business process; team-management guru Roy Osherove has a wonderful phrase for this – “bottleneck ninja”.
If doctors make the worst patients then I am convinced that developers make the worst estimators; only in the software industry would business process delegate such an important responsibility without first educating its staff.
How do I know this?
… because I’m absolutely terrible at it!
In the previous post in this series I stated we have a responsibility for imposing our experience on business process to ensure we “are given time to build our cathedrals” – good estimating is an essential first step.
So it seems this blogging thing is quite difficult after all, or at least so is finding the time I would argue is required to do it to a worthwhile and acceptable standard; or perhaps I'm missing a vital ingredient to the blogging recipe?
If you too find your team voting in favour of introducing StyleCop (the Microsoft born aesthetic compliance tool) it's possible you have found yourself in a whole world of pain, but there is help at hand.