Skip to main content

Posts

Showing posts from November, 2009

build for test != build for release

This might seem obvious to a lot of people - the people who actually do testing, but to everyone who doesn't or just waves a derogatory hand in the general direction it isn't... The differences manifests it's self in how the codebase is structured in your source control system. A codebase setup for test will have all the dependencies in the correct structure so when you pull the codebase, build the code and execute the tests you don't have to know what or how it's installed when the application is released - seems obvious right! I've just attempted to do this and low and behold a missing dependency, I don't know the application and I don't particularly want to right now but I'm going to have to spend sometime just to get the code to build - I suspect I need to install some application on the system before I can build let alone test - WRONG, WRONG, WRONG! Shite developers and there are a few, seem to think this job is about friction - friction pulling

When I'm a new team member

Jsut had a meeting about how to improve the build process for the team - the current structure of the code in the source control system means I can't just get the code out and build it - this to me is the sign of a failing project\team! I believe every project should be structured so that the following use cases are valid for any new developers coming onto a team, there's nothing more demoralising to new team members when you have to some kinda of voodoo to get a project to build; As a developer I want to install the IDE So that I can compile source code. As a developer I want to install the source control client So that I can extract code for compiling. As a developer I want to compile the code So that I can verify the code compiles sucessfully. As a developer I want to install a unit test framework So that I can execute unit tests for the code. As a developer I want to execute the unit tests for the code So that I can verify the tests execute successfully. Now

How to reduce url length in C#

I needed the other day to reduce the length of a URL - so I decided to use a URL reducing service like tinyurl.com And I thought I would share the C# .Net code - nothing new I'm sure and there are plenty of examples out there. public sealed class TinyUrlReducer : IReduceUrls { private readonly string _tinyUrl; private readonly string _proxyUrl; public TinyUrlReducer(string tinyUrl) : this(tinyUrl, null) { } public TinyUrlReducer(string tinyUrl, string proxyUrl) { _tinyUrl = tinyUrl; _proxyUrl = proxyUrl; } public string Reduce(string url) { if (string.IsNullOrEmpty(url)) throw new ArgumentException("Can reduce a null or empty url!", "url"); var reducedUrl = ""; try { Trace.WriteLine(string.Format("Reduce: Url - '{0}'.", url)); var requestUrl = string.Format("{0}?url={1}", _tinyUrl, url); va

Bad developers love 'The Daily WTF'

When 'The Daily WTF' started up back in 2003/2004 it was a great laugh looking at shocking code other developers wrote, but after a bit it became repetitive and boring and a sad indictment of the industry. Now on my contracting travels around the industry the people who continue to love and read this site definitely fall into the 'bad developer' bracket on the whole, why? Simple because they subconsciously believe this is the way the industry is and always will be and they find it comforting to their bad practices. Example: This guy tries to ridicule TDD and the ideas behind such practices without regard for his own ability - Oh look there on his blog list ' The Daily WTF '... Whether this story is true or not it highlights some of the issues for me - the WTF is not the air conditioning guy causing the system outage but the IT department building such a fragile system with no resilience that takes 36 hours to bring back online - if it took me that long to brin

When will it be finished...

Developing software is synonymous to writing to a book, not because it's a creative task - which I do believe it is, but because when you write a book you go through many drafts before getting to the final released version. Just because the writer completes the first draft doesn't mean the publisher thinks it's ready for publication etc... Software development is the same unless you (the developer) is prepared to think in an iterative approach you'll never be able to break free from classical development paradigms, you have to accept the first version is never going to be complete and you'll never reach the nirvana of finished, there always something that could be improved. Oh and just like books code has a shelf life and it's never as long as you think or want it to be, and just because the software no longer fulfills what's required doesn't mean it's wrong, it just means the world has moved on... An example is the talk Eric Evans gave at QCon earli