Opening up the newspaper this morning, I came across two terrible rulings recently passed down by the Supreme Court.
The first has to do with MSRP. I'm guessing that the majority of American's who are not filthy rich often go bargain hunting for prices below MSRP in hopes of finding that killer deal. I'm guessing that if you're like me, you're willing to sacrifice some service at the point of sale for a better price. This is part of principle of what has driven online sales: for the retailer, they save by not needing to have sales people or point of sale service while for customers, they often get a chance to save a huge amount over retail outlets.
From USA Today (6/29/07):
The 5-4 decision overturned a 96-year-old law that prevented manufacturers from setting minmum retail prices. The majority wrote that lifting the pricing ban could benefit consumers if retailers offered better service or selection.
Wait, what? How about benefitting consumers by offering a better price? Why not leave it up to the retailers to choose which model they choose to bring in customers? If customers wanted service, they could choose the retailer that offered it. If they wanted to find a bargain, they could choose the retailer with the best markdowns. Instead, the court has decided that the consumer has no say in this...no freedom of choice when it comes to price shopping.
What I found was completely asinine was a statement by Richard Doherty:
Richard Doherty of technology market researcher The Envisioneering Group agrees, saying the price ruling could lead retailers to use more free products and better services as sales incentives. "It's sure to be to consumers' benefit this summer and Christmas."
Is this guy on crack? How about I just want to get a good deal on a HDTV...I don't want any "quote-unquote-FREE" stuff. I don't care for point of sales services; I do my research on the products I buy and I already know what I want when I go into the store; I want to get the best deal that I can...why not leave that decision up to the individual consumer?
To make matters worse, the article offers commentary from a multi-billionaire:
Bill Gates, of golf equipment maker Ping, says, "Not every consumer is a bargain shopper. Some consumers are looking for quality, innovation, personalization and customer service when they shop."
That's fine, Bill, if you have the money for all that jazz, but how about the rest of us who are just trying to put away some money for retirement, for our kids, for our families? We just want to get by with a good deal. How about this novel idea: let the consumers decide what they value - price or service.
As if this wasn't bad enough, the Supreme Court also ruled to strike down school diversity programs on a national level:
The dramatic 5-4 decision throws into legal doubt programs that factor in race, including magnet schools that use race to draw students from different neighborhoods.
Accorind to Chief Justice Roberts,
Classifying and assigning schoolchildren according to...race is an extreme approach.
Well then, what would you suggest Mr. Roberts? How do you overcome the economic hurdles that create defacto segregated schools? How can you deny that integration - even if it is forced - is to the benefit of our racial diversity and our social fabric?
The fact is, if school children were simply assigned to schools based on location and district, it would in fact create further segregation and slowly reverse some of the progress that has been made. I think it is true that we fear what we do not know or understand. We view those who are different from us as outsiders because we do not understand their cultures, their languages, their traditions, and their ways; what better way to overcome the defacto segragation that occurs by township (and economic boundaries) they to help ensure a minimum level of integration?
Such an upsetting way to start the day...
Some days, I just can't handle the aggrevation...
I thought it was generally known that binary build output does not belong in source control, so I was quite dismayed when I grabbed an update to our source tree today and found myself downloading a 2MB .msi file (the output of one of our installer projects).
After discussing this with the other developers on my team, it became apparent that what I thought was a common, well known practice regarding source control is in fact, not so well known.
After presenting my arguments with little avail, I started to scour the web to find evidence support my stance:
What Files Should Not Be Source Controlled?
Build outputs that include assembly dynamic-link libraries (DLLs), Interop assembly DLLs and executable files (EXEs). Note that you are advised to add assemblies that are not built as part of your system build process (such as third-party controls and libraries) to Source Control within the projects that reference them.
Generally, avoid storing build output in version control. Provided that your source code is versioned properly, you should be able to recreate any previous release through the build process.
Files that you cannot add to source control include the following:
...Build output files, for example, *.dll and *.exe files.
We do not include the *.xml outputs in source control for the same reason that we do not include *.htm outputs; you can't run a new build without checking out the files! In my view, whether an output is a *.dll or a *.htm or a *.xml is irrelevant; it's build output, so it shouldn't be source controlled. Just source control the inputs and you have everything you need to get the outputs.
It is very important to us to be able to run an automated build (no human intervention). To the extent that a future version does include a dialog that offers to check out files, I hope it will either not run at all if the files are not source-controlled, or it can be suppressed by project settings.
Best Practice: Checkin all the Canonical Stuff, and Nothing else.
Although you can store anything you want in a repository, that doesn't mean you should. The best practice here is to store everything which is necessary to do a build, and nothing else. I call this "the canonical stuff."
To put this another way, I recommend that you do not store any file which is automatically generated. Checkin your hand-edited source code. Don't checkin EXEs and DLLs. If you use a code generation tool, checkin the input file, not the generated code file. If you generate your product documentation in several different formats, checkin the original format, the one that you manually edit.
If you have two files, one of which is automatically generated from the other, then you just don't need to checkin both of them. You would in effect be managing two expressions of the same thing. If one of them gets out of sync with the other, then you have a problem.
So not only is it a pain in the ass to have to download large binary files for a one line code changes, it also means that simply compiling the code (with no changes in the actual code) may cause a version change...argh!
I think that such a practice of disallowing build output in the repository also forces the team members to ensure that their code is buildable anywhere...a great quality when it comes to codebases as it means that onboarding new members or transitioning development machines, the code is ready to go.
One of the most confounding things about working with the SharePoint web services is that the return values are all in XML strings (wrapped in an XmlNode).
To make working with the services even more puzzling, suppose you get a result like so:
<ContentType ID="0x010100347433A509750F4D88880291599D314D04" Name="My Content Type" Group="My Custom Content Types" Version="7" xmlns="http://schemas.microsoft.com/sharepoint/soap/"> <Folder TargetName="_cts/My Content Type" /> <Fields> <Field ... /> <Field ... /> <Field ... /> <Field ... /> </Fields> <XmlDocuments> <XmlDocument NamespaceURI="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms"> <FormTemplates xmlns="http://schemas.microsoft.com/sharepoint/v3/contenttype/forms"> <Display>DocumentLibraryForm</Display> <Edit>DocumentLibraryForm</Edit> <New>DocumentLibraryForm</New> </FormTemplates> </XmlDocument> </XmlDocuments> </ContentType>
You would expect to be able to retrieve all of the <Field /> elements by executing the following code:
XmlNodeList nodes = xmlResponse.SelectNodes("//Field");
But it's not quite so straight forward. You actually have to instantiate an XmlNamespaceManager with a bogus prefix:
NameTable table = new NameTable();
XmlNamespaceManager manager = new XmlNamespaceManager(table);
XmlNodeList nodes = xmlResponse.SelectNodes("//sp:Field", manager);
In this case, I used "sp" as my prefix. Notice that it's utilized in the XPath query as well.