Friday, September 28, 2012

On SharePoint

You’d think embedding content in a SharePoint page, even their bastardized “wiki”, would be a relatively simple, refined feature… I mean it’s all about content management… they have picture libraries, right?!  Sure enough, the steps involve adding an image to a picture library, no problem there.  But then go to embed an image in the page and you get this beauty:

Seriously.. WTF?! Is this 1990 and MS-Access? Was this “feature” just introduced in SharePoint 2007? I gotta wonder because that dialog box is the kind of thing you build when your boss says “Can we have a feature where we can embed an image?” and you stub something in to verify it will work. Then you’re *supposed* to replace it with a more polished, and functional feature! I.e. options to select an image from an image library, or upload an image. (auto-creating a default image library) Something…. ANYTHING…  This is, as Chris Pebble is credited with the coining the phrase, “Protoduction”. (@CodingHorror)

So now all I need is the URL to the image I added in the image library… Now where do I find that… Click on my image in the library to view the item… name, preview, title…. No URL. Right-click on the preview and bring up properties: http://server/teams/IS/WikiImages/_w/Announcements_png.jpg ?? On the previous screen it is http://server/teams/IS/WikiImages/_t/Announcements_png.jpg. Ok, so just how many JPEGs does it need to render of my original PNG? 

Finally, clicking on the preview image itself brings up a browser window containing actual PNG file to get the actual URL… It would have never crossed my mind that a “copy URL” button or slapping it in text field might remotely have been useful especially when faced like idiotic dialog boxes asking me to type in the URL.

So now I finally have an image link in my wiki pointing to a PNG in an image library that has at least two mug-shot JPEGs taken of it. 

SharePoint: Content mismanagement at its finest.

On "clever".

Recently I came across some odd behaviour in a web system around date and time parsing. There was a validation step responsible for ensuring one date/time value was greater than the other. But it seemed to trip up in certain scenarios, such as around 08:00 in the morning. (Anyone used to working with Javascript probably knows exactly what the problem is already.:)

Fortunately I'd come across the cause of this bug a short time ago when enhancing a Javascript-based date parser.

Someone responsible for Javascript's parseInt() method thought it would be clever to try and determine what kind of numeric value was being passed in by inspecting the string and choosing an appropriate conversion rule. (I've read this may be a carry over from C, but regardless it is a stupid assumption that should never have been propagated.) If you pass in "0x..." it can be assumed you want to do a Hex conversion. Fair enough. But then they assumed that if you passed in a value with just a leading 0(zero) you'd want to do an Octal conversion.

I'm sorry, but this has to be one of the dumbest assumptions I've ever seen and surely has led to, and will continue to lead to countless bugs throughout the history of web applications. It's an absolutely stupid assumption because in either Octal or Decimal, 00-07 will result in: 0 - 7. The fun bit is that if you pass parseInt "08" or "09", you get back: wait for it, #null. Pass it "10" and the logic switches to assume you mean Decimal, so it passes you back 10.

So yes, according to parseInt, when you want to check a month number, your calendar must be:
January, Febuary, March, April, May, June, July, #null, #null, October, November, December.

So, if you're encountering unexplained bugs first thing in the morning, or with data for August or September be sure to inspect any and all parseInt calls.

parseInt("08", 10);

Someone owes an apology to the countless developers handed a #null for "08" and "09", and the possible *single* developer wondering where his 9 went after being led to believe parseInt defaulted to Octal.