Here's a list of FOSS tools and frameworks that you may find useful when developing .NET software. I've looked at, played with, or used all of these tools over the last few years.
Note that Visual Studio Team suite covers much the same functionality as some of the tools listed below and the there are a number of other commercial tools listed at the very end that may be worth considering.
Gemini - Effective Bug Tracking system (written with ASP.NET & NHibernate). License required for commercial use. Gemini Subversion Integration - Log Subversion commits against a Gemini issue Jira - Comprehensive bug tracking system (in Java)
Notepad++ - a great notepad replacement, includes syntax highlighting Castle Project - Inversion of Control (dependency injection) containers, MonoRail and more log4net - Logging framework Aspect# - Aspect oriented programming for .NET CopySourceAsHTML - copy VS2005 source as HTML. Great when blogging :-) Paint.NET - You're not still using MSPaint, are you?
Re-Sharper - VS2005 productivity enhancer. A must-have! CodeSmith - the de-facto standard in code generation. Mercury - Very expensive, but the best test tools you'll find going around by far. dotTrace - code profiling (performance & memory analysis) Ants Profiler - code profiling (performance & memory analysis)
If you've ever had to demo something and you use keyboard shortcuts it can be a pain to keep telling people what you were pressing. There's now a cool little utility to track those keyboard shortcuts and show them to the audience without having to tell them what you pressed.
It's been 2 years since I started with my current employer and while being a CTO has been fun, I've been feeling recently that it's time for a change. The higher I've been getting in management the less hands on I've been and recently I've not been able to spend much time at all on the Technology part of my role instead spending more and more in pure management.
As a result, I've decided to leave my current employer and change tacks (slightly) on my career. Today I 'm very happy to say that I've accepted an offer to join Readify as one of their senior consultants and will be starting with them shortly.
For those who don't know who Readify are, they are a specialist consulting firm focused on technical readiness around Microsoft technologies. In other words they help get companies and people prepared for the adoption of new technologies such as .NET 3.0, MOSS 2007 and so forth.
Readify has a large number of MVP's on board, run a "virtual office" where people who aren't on client sites are working from home, and have a great and genuine belief in the need to keep developing their staff. I know it sounds like an ad (sorry) but if you're interested have a look at the careers page of their web site.
I'm looking forward to the next step and seeing where things lead from here. It should be fun.
Static code analysis is the process of examining written code at design time and looking for problems. Typically this is done by tools such as FxCop, NDepend and SourceMonitor - tools that look for at coding rule violations, cyclomatic code complexity and a whole host of other code metrics.
Well, there's a few new tools that are not far away from making it big and getting a lot of attention.
CodeIt.Right combines FxCop style code analysis with automated refactoring. The concept being that you not only detect a problem (e.g. naming conventions and usage rule violations) but do something about it automatically to save the developer the hassle of making the change manually.
NStatic is still not yet available for download, but there's a 2 partpresentation about what it can do. Basically NStatic is used to track things such as redundant parameters, expressions that evaluate to constants, infinite loops and other metrics along those lines. It's looks really useful - I just wish I could get my hands on a copy :-)
Finally, Pex is a tool in the MS Research labs that uses static analysis to automatically create unit tests. For those of us who thing TDD is a good thing, then this will likely be a great tool and one that we come to rely on day in and day out.
I've been talking recently with Philip Beadle about the book DotNetNuke for Dummies that he co-authored and some of the effort involved in doing it. I was then wandering through the local bookshop shortly afterwards and saw 4 copies of it on the shelves and thought to myself "That's pretty cool".
But is it really worth it to write a book - and how much payback is there in doing it? Here's a somewhat sobering blog post by Scott Mitchell about the realities of authoring a tech book.
It's really worth reading; not as a deterrent but as a reality check. If you want to write a tech book - go for it, just be prepared for it to be a labour of love, not a path to early retirement.
OK, so it's not as good as the genius that is Firebug (which runs inside Firefox), but if you want to see what's happening in IE when testing your web app then you'd best head on over to the Microsoft web site and pull down the official Version 1.0 release of the IE Dev Toolbar.
The IE Blog also has a little more information on it, including a video of Steve Ballmer getting emotional again - not quite as bad as the Dancing Steve video but still pretty funny (rendered with Silverlight of course).
Now it appears that doctors have found a way to get the body to regenerate hair long after the original follicles went into early retirement. What's the catch? Well apart from the fact that it's all still in the lab, there's this small rider: "the hair would still be subject to the conditions that made it fall out in the first place."
I guess I'll stick with option 1 until they can sort the caveats out :-)
Well, so much for "going dark". I couldn't help myself :-)
Tonight one of my staff (Sharon) and I went to the inaugural combined Syxpac & Scrum Gathering where the Sydney agile community could get together. Andrew Hallam has already posted about it - talk about quick!
The gathering was in an open space format, which I've not personally experienced before. I've gotta say it's a really effective way to knock together an impromptu agenda and get people involved and as a result I've just added another item to my toolbox of meeting formats :-)
As a group we had 4 sessions over 2 hours covering a variety of topics (I think the final list was about 10). The Syxpac site should have a number of photos and discussions on it shortly for reference.
I sat in on the following discussions:
Value Stream Mapping
A good introduction by Jason Yip to the concepts for those who aren't so familiar with the topic. The use of a worked example from the group helped drive a few things home. Some of the things could be applicable to my current situation, but I think this'll be a file-it-in-the-back-of-my-head topic.
What's Different When Dealing With Agile Software Vendors
Lots of talk here about government in particular dealing with vendors delivering either bespoke software (ie custom developed) or customised solutions. So what's different? In a nutshell - Relationships.
Agile companies are more likely to engage, be open and communicate better than typical SI's
I really enjoyed this one - not because I learned anything, but because I could speak from experience and hopefully help others.
Scrum vs XP
Not so much a "which one is better" topic, but more a "what's the difference?" especially when XP has many of the same practices and Scrum. This was a good discussion, and there were a few key points that came out of it:
Scrum doesn't deal with engineering practices. XP Does.
XP is a little harder to manage backlogs with
Scrum is more about meeting sprint commitments and keeping things shippable. XP is more about completing individual features.
Scrum is probably less difficult for organisations to adopt (but still not easy)
The emphasis is different in each methodology. Scrum emphasises business interactions and self management, while XP emphasises development practices.
Is one better than the other? I don't think so - and when you consider that the agile practices all borrow from each other, there's not a lot of difference. Consider your situation and use the one most suitable.
When is it OK to Cut Corners on Quality?
Answer - never. :-) This was really a discussion on dealing with unmaintainable production code and the pragmatics of business considerations over code purity. I though this would be a quick one but it turned into a great discussion about business priorities, renegade salesmen, how to fund new development when a company is losing money, whether it's ever OK to start from scratch and so forth. A wide ranging conversation and lots of fun.
Thanks to Ben for running the night and for the Syxpac group for the invite. I can't wait for another one to happen.
No longer a release candidate, nHibernate 1.2 has now made it to production status, meaning it's fully supported and ready to roll. Read about it here & here.
Given what's happening in nHibernate these days I can be pretty sure that the AtomsFramework is now dead and buried. It was fun to do, but nHibernate is really moving forward these days and with the future including LINQ integration there's no way a one-man part time effort can keep up.
On Friday I toddled off to the nearest EB Games store and handed over some hard earned for a copy of Elite Beat Agents for the Nintendo DS.
This game has been getting first class reviews from various game sites and I've been curious as to how good it really is so I took a (small) risk and grabbed a copy. Needless to say, I'm very happy; and very addicted.
EBA is simple in concept - just hit numbers on the screen in time to the music - but it's executed so very, very well. Now I usually play games on the DS during the commute, but with this game I've played it across the weekend, took it to friends and got my wife to play (though I had to wait a while to get it back). It's great fun - even for a rhythmically challenged person such as myself.
If you've got a DS then go get a copy (or find someone to swap with) and have some genuine fun. I'm going to end this post now - the siren call of the Agents is getting loud again and I must answer. .. I cannot refuse...
Wow - this blog just racked up it's 10,000th visit! When I started it 2 years ago I never really thought I would get that many visits (or keep posting for this long either).
Thank you to everyone who visits regularly, whether by visiting the site or subscribing to the feed. I know it's a crowded web out there so its an honour to know you take the time to read my ramblings.
Guy Kawasaki has recently posted about using LinkedIn for vetting candidates and tied it to "The No A$$hole Rule" book. The result is a fairly interesting read, especially as I'm a boss.
How would I answer the list of items I wondered? Here's my self assessment, out in public, for the whole word to see. If you know me feel free to comment, though of course I'll probably abuse you and call you names :-)
Q1: Kisses-up and kicks-down: “How does the prospective boss respond to feedback from people higher in rank and lower in rank?” A1: Fairly well. I usually seek feedback from both my staff and boss. From the staff during reviews, from my boss at semi-regular intervals.
Q2: Can’t take it: “Does the prospective boss accept criticism or blame when the going gets tough?” A2: Yep, I'll put my hand up when I make a mistake. Here's a public example.
Q3: Short fuse: “In what situations have you seen the prospective boss lose his temper?” A3: Guilty on this one, though improving (slowly). I've lost my temper 3 times in the last 2 years, that I recall, and it's always been caused by a slow buildup of frustration that eventually erupts. I'm neither happy or proud about it.
Q4: Bad credit: “Which style best describes the prospective boss: gives out gratuitous credit, assigns credit where credit is due, or believes everyone should be their own champion?” A4: Credit where it's due.
Q5: Canker sore: “What do past collaborators say about working with the prospective boss?” A5: Nice things I hope - leave a comment. The fact that some people have followed me from previous organisations is probably a good sign.
Q6: Flamer: What kind of email sender is the prospective boss? A6: Flaming is rare - email is too easy to misinterpret so I try to keep things emotionless.
Q7: Downer: “What types of people find it difficult to work with the prospective boss? What type of people seem to work very well with the prospective boss?” A7: It's hard to work with me if you don't think for yourself or show little initiative. I like people to be results driven, good communicators, ego-less and open with others.
Q8: Card shark: “Does the prospective boss share information for everyone’s benefit?” A8: As much as I can. If things are in flux or sensitive in nature I'll withhold details, but once things settle and are clear I'll communicate what I can.
Q9: Army of one: “Would people pick the prospective boss for their team?” A9: I hope so - leave a comment.
Q10: Open architecture: “How would the prospective boss respond if a copy of the book appeared on her desk?” A10: I'll always accept freebies :-) Anyone got a copy they want to give me?
On March 20, I gave spoke at Google at the invitation of the bayXP group on the subject of "Planning and Tracking on Agile Projects." They did a nice job of recording the session and have posted it on YouTube. You can download it at: