John Luif

This has been on my shitlist for some time and recently it came up again while taking a health assessment test to get cheaper insurance rates.  For those of you who do not know what BMI is, it is a measure of body fat based on height and weight.  If the above statement sounds stupid well it is.  By BMI standards all body builders are obese.  Considering that some body builders reach as low as 3% body fat (which is actually unhealthy) they would still be considered obese by BMI.

So you may say that using body builders as an example is a special case scenario.  There are so many special cases out there that is makes BMI a totally inaccurate number.  BMI is absolutely wrong and is a worthless measure that should not be used as a measure of anything.

For those of you who like DevExpress's stuff there is version 2.0 of CodeRush out there which is very exciting.  This also comes with a new version of DXCore which is great since I have been waiting on bug fixes.

Also, there is another CTP of eXpressApp.  I have not looked at this yet but it sounds very interesting.

Everyday I find something new that I love about CodeRush.  You can Optimize/Cleanup “usings” just by going to the top of the file where the usings are defined and press “Ctrl+`”.  Good stuff!

I just created a new home page for LuifIT.net using the RssToolKit to aggregate my wife’s and my blog to the home page.  Beyond just using the RssToolkit I also decided to use the new SiteMap and Themes available in .NET 2.0.  Below is my experience with the RssToolKit.

Scenario:

Aggregating multiple feeds to a single web page and providing an rss feed of the aggregated feeds.

Working with the Rss Toolkit:

It started out very well.  I ended up refactoring three times each because I found a better way to leverage the RssToolKit.  One very nice feature is the RssChannel supports the loading of multiple feeds; perfect for my scenario.  Since the RssChannel holds all it’s items in a List<T> it is sortable, so after loading multiple feeds it was easy to sort them according to date.

The RssDatasource is a great idea with a couple big limitations.  One, you can not set the Channel of the datasource in code.  So I went to change the code to allow the setting of the channel and noticed that it is using the GenericRssChannel which derives from the RssChannelBase. Long story short when the RssToolkit is used to generated types classes for your feed the gen’d channel derives from RssChannelBase not GenericRssChannel.  So if you gen using the toolkit the resulting code is incompatible with the RssDatasource.  It would nice to have an interface extracted out of the RssChannelBase class and have the RssDatasource use this for the Channel property.  Being able to gen typed classes is very nice and one addition that would be helpful gening these classes as partial.

RssChannelBase uses the XmlDocument to build the xml to render for the feed when using the RssHyperlink.  This is a fine idea if you do not need namespaces and prefixes but I did not find a way to include prefixes using the XmlDocument.  I changed the use of the XmlDocument to use an XmlTextWriter so it is possible to include prefixes.  This was only half the battle as the root “rss” element was created as empty.  I needed to have all the same namespaces as the original aggregated rss feeds.  I ended up saving off the original root rss node and checking to see if it was empty or not.  This allowed me to have prefixes and all the correct namespaces.

I see many easy refactorings that could be done to tighten up the code of the RssToolKit.  The decoupling of specific classes would of eventually fall out with some unit testing.  I looked at the Rss Framework on the code project for a few minutes and it looks pretty nice as well though it is built on .NET 1.1.  I think the RssToolKit has a lot of great potential and will eventually get there as time will permit.  Thanks for making the RssToolkit Dmitryr!

Today was the first ip meeting I ran using a commitment based approach as opposed to a velocity based approach.  With a commitment based approach each story in priority order from the backlog is decided upon by the team whether or not to commit to completing the story for the iteration.  The team decides when they have enough work for the iteration.

With a velocity approach the Dev Lead/Scrum Master/XP coach whatever you want to call it looks at the teams velocity and goes into backlog and takes top stories in priority order to add up to the teams velocity.  This story set is what the team is expected to complete in the next iteration.

What I noticed with a commitment based approach is the team is much more involved in iteration planning and they actually committed to more work than I would of given them based on their velocity.  I’m not completely convinced the team can complete all of it but I have been proven wrong before.  I also feel that the team will get a better since of commitment since they are the ones making the decisions.

Basic rule of thumb when leading an Agile team, when a decision will affect the team ask the team.