Over the couple of weeks I've been migrating over my old blog posts into this spiffy, new site that the astute observer will immediately recognize as a WSS v3 blog template site - with some modifications.
I thought this would be a good fit since I could leverage my skills with the platform to do customizations and get a cool-looking blog up and running quickly.
Well, quick - yes; functioning as expected - not so much. Here are some annoyances that I discovered so far:
- RSS feeds for back-dated posts: This one totally surprised me because I just expected the RSS feed feature for WSS lists to work. The problem: Despite correctly back-dating the posts' published date field, when the RSS feeds are generated, they use the created date to populate the RSS "pubDate" field. Result: Irrespective of the filter or sort placed on the list, the posts show up in the order that they were entered and not according to their original pub date.
- Anonymous permissions for contact email lists: This took a bit of a Texas-two-step to fix. The problem: I set up a list to collect feedback from visitors, but wanted to guard against anonymous users viewing the entries. See below for my solution.
- Fixed-width blog post list view web part: I discovered this annoyance while putting together a new master page for the site - essentially, the part can be tamed to render results that respect the boundaries of the web part zone, but when the page is put into edit mode, it totally blows it apart to a full 655px.
Solution: Override the .ms-blogrss, .ms-CommentsWrapper and .ms-PostWrapper CSS classes that are found in the Core.css file within your current theme's CSS file or import a new CSS file with the overrides.
Defining "Secure" Anonymous Permissions for Lists
Your WSS site is set up for anonymous access, but you want to provide users with a list that they can add to, but cannot view any items afterwards (by say, navigating to the list's AllItems.aspx page, for example).
- Open up the anonymous acccess settings for the list:
- Enable options to allow anonymous users to add and view items:
- Go back to the main settings form for the list and select Advanced Settings from the General Settings menu:
- Change the item-level access settings for the list to allow users to only read and edit their own entries:
- Click OK and your list is now set up for anonymous additions, but secured viewing. Don't panic if you check the anonymous settings for the list and it looks like the following - it's apparently "normal". Ha.
536c2eb9-00e1-493d-87ca-79f8601d398f|0|.0
There's a well-worn expression about the changes in life that goes something like "as one door closes, another opens" - it implies that when something seemingly devastating or life-altering occurs, putting a fork in the road for you, it may be for the best, as it puts you on a path that you'd never have taken otherwise. And it can lead in directions you'd never expect.
This is the second version of a blog that I began in early 2004 not long after I joined a great little Microsoft web development company here in Toronto called imason. It's moved here now because I had a "fork stuck in the road" moment of my own this past week when I learned that I was to be "one of six" staff to be laid-off as part of a "corporate restructuring plan" that the company was undertaking.
It was a watershed moment, and for that reason I decided to make it the new moniker for my blog.
Now, I don't want to leave the impression that I'm embittered, far from it - I think I understood better than most the reasons why the company needed to restucture and certainly know the distinction between "business" and "personal". While I'm saddened to leave, I'm also rather excited about the opportunities that may lay ahead of me in the wake of this life-altering event.
So, this blog is as much about a clean break with the past as it is optimism for the future. I'm planning to write more about .NET, SharePoint, Better Practices for development, Agile/Lean software development and much more. While I had no restrictions on my writing in the past, I expect my horizons will be quite expansive in this new phase of my career and I'm anxious to begin testing out some concepts that may end up in a book or two - perhaps even a podcast or three.
So, what will I do next? Not sure, and I will write more on this as I formulate a good idea what I want to do and where I want to do it - I do know that I want to explore agile software development and best practices to a greater degree to leverage my passions and skills.
Stay tuned, as there is definitely much more to come.
12321764-65a7-4c1a-a25d-74d3820ddfa9|0|.0
Earlier this week I learned of a new
Microsoft Research labs project called “Pex” (short for Program EXploration) that posits an interesting approach to crafting unit tests - more specifically, how to automate the coverage of the unit tests you may write. For the uninitiated, “test coverage” is a moderately controversial topic in the Test-Driven-Development world that suggests unit tests should aim for 100% code coverage in order to be valuable as a regression validation tool.
At first, I was skeptical about Pex - I mean, after the
debacle with VSTS back in '05 where MSDN docs actually suggested auto-generating unit test stubs thereby negating the whole point of changing developer habits to write tests first, I thought Pex was another run at the windmill from it's description:
Pex is an intelligent assistant to the programmer. By automatically generating unit tests, it alllows to [sic] find bugs early. In addition, it suggests to the programmer how to fix the bugs.
As it turns out, this is a bit misleading; what Pex is actually all about is a new style of unit test composition: Parameterized unit tests. This is interesting!
So, what is a parameterized unit test?
Take your run-of-the-mill unit test (this is from the site):
Nothing special here - just validating a hashtable. Trouble is, we're baking-in some arbitrary values to validate our assertion. What if we need to check several different sets of values for a more complex object? We need to either: a) write more tests for each case, or b) invoke a bad practice and lump a lot of representative cases into a single test, or c) write a loop inside the test to go through several sets of values. In other words, tedium which needs to be maintained as the system grows.
Now, take a look at the same unit test written as a Pex parameterized test:
Already, we see the first significant difference: The test has parameters! And these arguments are then fed into the test, suggesting by design that this unit test is going to be more flexible than its predecessor. Pex doesn't stop here, though: It is capable of generating the inputs for the test. How?
Again, some interesting things are going on here: Pex actually monitors the execution of the test by using random inputs based on the arguments. Next, it uses a constraint solver to ensure that every set of inputs made actually exercise different code paths within the test and objects under test. Thus, we have significantly improved code coverage.
This is a really radical approach to computer-assisted unit testing - Visual Studio will in effect become an intelligent aide to developers who will still be on the hook for writing tests, but relieved from the tedium of providing supporting code to ensure higher code coverage.
Pex is still under development, so we probably won't see this until after Orcas is released - too bad! In the meantime, check out the site and have a look at the screencast which shows how this tool works within the VS2005 IDE - it's definitely raised my eyebrows.
efc243c2-2af2-4d10-85a8-5ffd603b725f|0|.0
Scott Hanselman's latest podcast is about a best-practice I and a few colleagues have been looking into here at imason: Continuous Integration. Part of the challenge with CI is that it's a little tricky to get all your bits and bobs straight, and more than once we've wondered why there wasn't a CC.NET in-a-box we could run and get started with straightaway.
Well, wonder no more: In the podcast, Scott interviews Jay Flowers, a rather sharp guy who figured out how to package up CC.NET and host of other great tools like NAnt and Subversion into an easy-to-install package called CI Factory. Not sure how it will stack up in reality, but Scott had a great analogy on how CI Factory may be as easy as “File->New Continous Integration“ - sure hope so!
I've already pulled down a copy and have started to play with it -- looking forward to seeing how it all works and how we could mod it up with some hooks and addons for installation on a SharePoint 2007 server, which is what we predominantly develop products for.
Check it out.
494c40d2-e874-4979-86d2-a661ed1a213b|0|.0