| |
Articles from
June 2008
David Kean  mentions his thoughts on string handling and I have to say I completely disagree. He states that you should always return String.Empty instead of null. I hate this. An empty string and what equates to "no value," by definition, mean two different things. David, on the other hand, contends that the two should always be treated as the same. To be clear, I'm not saying the two should never be handled the same. On the contrary, I believe that's the norm... and rightfully so. With that, however, there are still cases where they need to be handled differently. Besides, the benefits you get from returning an empty string are immediately invalidated when considering consistency principles.
I'd even go as far as to say, returning empty strings promotes bad practices. Why? Because the developer then treats what is returned as a non-null value. While this isn't a problem, it typically goes further. The same developer will start assuming all methods that return strings act the same way. Let's not forget what they say about people who make assumptions... For this reason, I believe it's a good practice to always use String.IsNullOrEmpty() to validate string values, no matter what you think/know is returned.
I could list a number of what-if scenarios depicting why this is so important, but I won't. It should be pretty clear. Let's face it, we've all fallen victim to a null reference exception, which is essentially what happens when you assume a variable has a value. Clarify your assumptions with good exception handling.
Lastly, one other reason I like null over empty strings is because it uses less memory. Yes, this is very trivial, but it's true. The bottom line is that, whether you return null or empty string, you have to treat it as if it were null. For this reason alone, I believe it's cleaner to simply use null. Using empty strings is a hack, in my mind, unless it really means something different than "no value."
I know some people have asked in the past how to map latitude/longitude on Live Maps and I just ran into a scenario where I needed to do it. Well, it's as simple as typing in the desired lat/long, selecting Locations, and doing a search. Admittedly, it's not the most intuitive thing in the world, but I figured it out in a matter of seconds.
If you're looking to link directly to a lat/long position, you can also pass in the lat/long via querystring parameters. There are a number of different querystring parameters, and I'm not going to go thru them all here, but I will mention the two most important: cp and where1. The cp parameter is the lat/long position you want to center on. Using this alone will center on the lat/long at the default level, which isn't much help. For this reason, I'd recommend you also specify the where1 parameter, which performs a search for the lat/long. The key thing to remember here is that cp delimits the latitude and longitude by a tilde (~), whereas where1 uses a comma. Here's a sample URL: http://maps.live.com?cp=36.16773~-115.157181&where1=36.16783%2C-115.15707.
Working with the SharePoint object model can sometimes be a pain. Specifically, when you need to get a lot of information from multiple sources, it can become a very painful experience when you have to write pages of code to do something that takes entirely too long. I've heard of one case that took hours to accomplish in the object model, but querying the database directly brought that down to minutes. The question here is, what's supported. The typical dogma is that SharePoint databases are completely off limits. I have to admit this is something I wanted a bit more proof of. It reminds me of the unfounded rumors people sometimes spread without realizing it.
Adam Ruderman pointed me to SharePoint Database Access on MSDN that states, "Direct modification of the SharePoint database or its data is not recommended because it puts the environment in an unsupported state." I was hoping for something within the license, but this is good enough for me. Now, I know I can treat a SharePoint database as a read-only data source. Of course, I'd strongly recommend people avoid such a practice. I simply wanted to know for those odd-ball scenarios where the object model just doesn't cut it performance-wise.
If you're looking for something that covers supportability of changes to the database, you can also check out Support for changes to the databases that are used by Office server products and by Windows SharePoint Services, which talks about the supportability aspects we're actually concerned with.
Barry Collins, of PC Pro, is sharing numbers that showFirefox users migrating to Firefox 3 a lot faster than IE users to IE 7... well, at least for PC Pro users, anyway. Basically, it comes down to 55% of its users are on Firefox 3 after being released for 10 days, whereas IE users are sitting at 68% on IE 7, despite being released for over a year and a half. Nobody can argue the numbers and I'm sure we'd see something similar if we polled just about any group of sites. There's an important aspect that Barry is missing, however.
Firefox users are downloading the tool themselves and updates are done on individually from what amounts to nag-ware -- you are constantly asked to update until you do so. Don't get me wrong, I have no problem with this. I'm a firm believer in staying up-to-date. I'm really just pointing out the fact that IE doesn't have this same forceful update mantra. IE is typically updated via Windows Update. if you don't use it, you won't get updates. This is very important when looking at cases like this because most IT organizations manage their software updates, instead of relying on individuals to update their software. So, when an organization doesn't streamline the IE 7 push, of course it's not going to get out. I'd put money on the fact that 95% of the 31% users still on IE 6 are there because of their company, not their personal lack of updating the software.
This stuff kills me. People are so hard up to get ratings that they present partial truths in an attempt to promote a half-ass story. Of course, I'm no better by encouraging and linking to it 
It's been entirely too long. I've had a new project take over my life for the past few months. I'm trying to get back into things and catch up with the blogs I read, but it's sometimes hard. This is my first big SharePoint-based project and I have to say it's been "an experience." If you're a developer and you haven't heard about how much SharePoint has been taking over, you've probably been living/working in a cave. It's amazing. I've learned a lot, with respect to SharePoint, and I can sum it all up with this: SharePoint is the new VB. I don't say this from the drag-n-drop point of view that made VB so easy to use, but from the ease in which you can get something done. To put it another way, SharePoint is to hobbyist web "developers" what VB was to hobbyist client-side "developers." I say "developers" for a reason. I've been very clear about my thoughts on hobbyists, so I'm not going to get into that.
Perhaps the best way to put it is to liken SharePoint "development" to the creation of a Rube Goldberg device. And, if you want to throw in AJAX features and a standard user experience that looks/feels nothing like SharePoint... well, let's just say you have your work cut out for you. As if portal development wasn't odd enough with respect to deployment. All I can deduce is that SharePoint was built for tech savvy users (not even power users) and not developers... definitely not developers.
As most who know me already know, I've been a fan of DotNetNuke (DNN) for quite a while and even worked on the dev team for a few of the modules. I feel lucky to have gone thru that because DNN gave me a nice perspective to some key issues around portal development. It's also let me experience the difference between portals built for developers instead of for users. This is the key difference between SharePoint and DNN. I know there's been a lot of talk in the past about differences, but it all comes down to that. SharePoint has the polish necessary to make your portal much more user-friendly and feature-complete, but DNN has the dev backing to make it a breeze. I'm really hard-pressed to pick a favorite, that's for sure. I've been in talks with a few key people within the DNN and Microsoft teams to get more involved with DNN in an official capacity, but I think I'm going to back off of that. Between the two portals, I see SharePoint having the most promise for the future. DNN is fantastic and I'll continue to recommend it where it makes sense, but SharePoint is much more powerful. The big hole in SharePoint is the developer experience. I see this as a huge opportunity.
More and more, I hear about how we need to focus on specific technologies. I'm not the type to whole-heartedly dig in to a single technology from top-to-bottom, but I do see value in filling this gap. The training I continue to see around SharePoint is all about small-time hacks. We need an enterprise solution. Some true patterns and practices for enterprise SharePoint development. Given the Rube-Goldberg-ian nature of SharePoint, this may be hard, but someone has to do it. Of course, this is all going to depend on the project opportunities I have. For now, it's just a bag of thoughts I've thrown together, but I'm hoping I'll have a chance to sort them out and pull it all together in the future.
There's so much more I could say about SharePoint, DNN, and the other things I've mentioned here, but I've babbled on long enough.
The following consists of the English DVD updates released under the MSDN Premium (Team Suite) subscription level for June 2008.
Servers
- Disc 4407.01 / Part X14-89714
- BizTalk® Server 2006 R2
- BizTalk® Server 2006 R2 Accelerators
- BizTalk® Server 2006 R2 Adapters for Host Systems
- BizTalk® Server 2006 R2 Line of Business Adapters
- Connected Services Framework 3.0 Server with SP1
- Customer Care Framework 2005 .NET 2.0 Edition with SP1 (V2.6.1)
- Customer Care Framework 2008 (V3.0)
- Microsoft System Center Configuration Manager 2007
- Microsoft System Center Data Protection Manager 2007 System Recovery Tool
- Microsoft System Center Virtual Machine Manager 2007 (English)
- Microsoft System Center Data Protection Manager 2007 (x86 and x64) (English, French, German, Italian, Japanese, Korean, Simplified Chinese, Spanish, Traditional Chinese)
For more information, see the MSDN Subscriptions Index.
|
|
|
|