Monday, 13 September 2004

Just released on GotDotNet: MacawSharePointSkinner, a server HttpModule that allows you to modify the look and feel of SharePoint sites without having to change the core site layout. (found via Mark Harrison) You should also be able to use it to modify non-SharePoint ASP.NET web sites. It looks very promising for certain situations (probably not all - as my friend commented, why would you want to do customization work and then change your changes? Plus ASP.NET 2.0 will include skinning right in the package). Where SharePoint is involved, however, this could be useful since certain customizations can be quite a bit of redundant work.

From the MacawSharePointSkinner documentation:

MacawSharePointSkinner is a tool designed to enable non-intrusive modifications to the visual and functional design of SharePoint. The tool can be used for both Windows SharePoint Services 2.0 and for Microsoft Office SharePoint Portal Server 2003. Actually, it can be used for any web site utilizing the ASP.NET technology.

One of the major issues that we encounter in the implementation of SharePoint within organizations is that organizations want modifications to the visual and functional design that are almost impossible to implement without a major overhaul of the standard files and templates provided with SharePoint. SharePoint is constructed as a kind of standard product that is best used out of the box. Some design can be applied by specifying themes (for team sites) or by modifying CSS stylesheets (for the portal). The possibilities here are limited however, and changes to the actual HTML that is rendered results in changes to hundreds of the standard files.

When implementing customer requested visual modifications, one of the big problems that we encountered in making extensive modifications to the files and templates delivered with SharePoint was that the rendering of the same HTML is implemented differently by different pages. Some pages contain the actual HTML that is outputted and can be easily modified. Other pages contain server controls that do the rendering of the same HTML. These pages are almost impossible to modify. Another problem is that modifications must often be made to hundreds of pages.

The approach that MacawSharePointSkinner takes is that it lets SharePoint render the final HTML, and just before this HTML is sent to the browser MacawSharePointSkinner makes the needed modifications to this HTML. This is done in such a way that no modifications are needed to the internal files of SharePoint, so it is non-intrusive. Another advantage is that it will survive service packs (although the output HTML may change in a service pack!) and template modifications.

Interesting. Get it here. If anyone makes any screenshots of interesting implemetations of this, I would be interested in seeing them.



Add/Read: Comments [0]
SharePoint | Tech
Monday, 13 September 2004 21:35:10 (Pacific Standard Time, UTC-08:00)
#  Trackback

I'll gladly be taking the rest of the week off work, to spend some time with a friend visiting from Germany, Florian. He's the lead programmer on Admin Mod for Half Life, a server add-on for people who run Half Life and HL-Mod (anyone ever heard of CounterStrike?) game servers. I used to be the documentation and PR guy on the project back in the day, but a good guy names Dave has pretty much assumed the documentation role and does a great job with it, and PR is not exactly necessary anymore :-). So, I pretty much just hang out these days. We will be spending some time seeing the sites and cooking on the grill at least once, before heading up to Seattle to visit with Alfred, who originally wrote Admin Mod and now works at Valve Software, the company that created Half Life. He's been pretty busy lately. It will be the first time the three of us have met up in one place at the same time.

It's going to be a good week. :-)

Here are some great ideas people have given for things to do while Florian is here. I think we will pick and choose a few items from this list and a couple other ideas that were passed along:



Add/Read: Comments [1]
Personal Stories | Random Stuff
Monday, 13 September 2004 20:09:14 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Sunday, 12 September 2004

Pulling this out of the cave that is my blog comments:

I've completed a real-use test of the Nikon D70 with the Seagate ST1 hard drive. I'm not a hardware tester, but I decided I'd just load it up and push it a bit and see what happened.

I shot 1365 pictures at full jpeg resolution, continuous fire mode for long sessions. This required the hard drive to run continuously for several minutes at a time. The camera showed 451 images left to go (free space remaining) when I reached the point where all 1365 images had been recorded.

At that point my camera's battery died - Now, before anyone goes off on a rant, it's important to note that it was not fully charged to start with (I had charged the camera battery a month before and used it some since then), and that I intentionally shot groups of of 100-300 continuous-fire images at a time in this test, with auto-focus on and the reflex mirror down in normal operating mode. Also, the LCD display on the back of the camera was not disabled, as I used it to view some of the images between the continuous-fire sessions (like watching a slow frame rate movie - that night be a fun project some other time, heheh). In other words, I was running it in full-battery-killer mode, on a partially charged battery.

With the Seagate drive in the Nikon D70 (in continuous-shot mode, recording in fine resolution JPEG mode at the largest image size setting: 3008x2000 pixels), the camera does its standard thing, buffering the first 9 shots with rapid fire of about 2 frames per second, then slowing down its frame rate to allow the media to store the data (about a frame per second). Time required to spin up the drive and display an image on the camera's screen when I push PLAY on the camera from a dead stop is right at two seconds.

Disk space used on the ST1 drive by the 1365 images: 3.15 GB (3,388,802,794 bytes)

Time required to copy all 3.15GB of files to my laptop hard drive using a Sandisk USB2 CF I/II card reader (as measured using the nifty stopwatch feature on the Rio Carbon, of course): 10 minutes, 1 second.

This Seagate drive is nice, and my surviving Rio Carbon is awesome, too. It seems plenty fast enough for me. Unfortunately I don't have a Sandisk 2 Ultra or similar to compare it to, but I have seen others comment its close to that speed. Anyone have more specific experience there?

Off-topic Rio Carbon thought of the day: If you're not an Audible.com subscriber, your should become one and listen to "The Daily Show with Jon Stewart Presents America (The Audiobook): A Citizen's Guide to Democracy Inaction." Freakin' hilarious. I listened to the whole thing on my Carbon while commuting. I have also downloaded "Hitchiker's Guide to the Galaxy Unabridged" (as read by Adams himself) and "Getting Things Done," which is also great stuff.

Related Links:



Add/Read: Comments [13]
Photography | Tech
Sunday, 12 September 2004 22:38:39 (Pacific Standard Time, UTC-08:00)
#  Trackback

Want Gmail? Go here and follow the instructions.

Sorry, all taken - will update when I have more. :-)



Add/Read: Comments [5]
Random Stuff
Sunday, 12 September 2004 22:24:38 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Saturday, 11 September 2004

Wow, the hits just went through the /. roof. My article with pics on breaking down the Rio Carbon got posted on slashdot.org [link]. I have changed the pics in the article to make them smaller (clicking the smaller version now loads the larger image), as the bandwidth was challenging the NIC in the server. Good thing I didn't do what someone thought I did. I also made some changes to my fat-fingered apostrophes to settle down the grammar-police crowd. :)

My blogging software, dasBlog (a .net-based app running on Windows 2003 by the way, hehehe), has held up quite well under the /. traffic load. I'll put together stats and post them for other dasBlog users, once this all dies down. My service provider, Stormhosts, held up very well, too.

Number of unique *.slashdot.org web sessions on Saturday: 20,358

The graphs of bandwidth used are pretty interesting - note the trafffic before the spike is for all web sites on that shared web server - after that it's pretty much all mine:

Here are some numbers showing unique user sessions per hour - meaning it's how many actual visitors hit the site per hour. Saturday is usually pretty darn slow day, but not this time, and the number/size of of images on the page being loaded was a real challenge:

6am  57
7am  65
8am  54
9am  68
10am 74
11am 102
12pm 3321
1pm  5069
2pm  3360
3pm  2661
4pm  2196
5pm  1721
6pm  1477
7pm  1279
8pm  1239
9pm  1157
10pm 1063
11pm 702
Some more numbers...
                    11SEP04    Daily Avg
Sessions 26,030 1,792
Pageviews 52,522 4,280

Hits 639,524 8,754 
Bytes Transferred 13.49 GB 175.35 MB

Note that RSS was about four to five times my Saturday normal at 4,426 sessions (about twice a normal weekday count), but at a very light bandwidth requirement. Score one more for RSS. Quick, someone write a manifesto! ;-)

So anyhow, I would like to formally apologize to my service provider, Stormhosts. Well, not really apologize per se - more like shoot them a big HAHAHA! ;-) Good test for your systems I guess eh? Their systems held up very nicely, and when I emailed them just in case alert as soon as I knew what was about to happen**, they got right on IM with me. We watched the performance counters together. Great service from those guys, as always. Recommended.

** Mandatory educational content: Many sites over time have fallen victim to the Slashdot Effect, a term used to describe the very common and overwhelming onslaught of sudden traffic to a web site and the resulting failure of said server. It's typical for web servers to simply choke under the load. At some point, I don't remember when, slashdot started releasing new items to their subscriber base for a short while before they release it to their general public web site. This informal early warning system allows just enough time for their notably large number of subscribers to hammer your server, with just enough time left over for you to panic and send an email to your personal web site's unsuspecting service provider that reads something like “HOLY CRAP LOOK OUT!” The slashdot subscriber visits that precede the general onslaught generally include such friendly comments left on a blog as, “What a really cool/lame story. Oh, and by the way - you're about to get slashdotted.”



Add/Read: Comments [8]
Blogging | Random Stuff
Saturday, 11 September 2004 09:28:38 (Pacific Standard Time, UTC-08:00)
#  Trackback
 Friday, 10 September 2004

Interestingly, in an article by the Associated Press posted on the Security Pipeline web site, Microsoft is quoted as saying that their new biometric authentication products, which I posted about the other day, should not be used for securing important/sensitive data or networks:

"Curiously, Microsoft warns that the Fingerprint Reader shouldn't be trusted to secure access to corporate networks or to protect sensitive data, such as financial information.

"Basically, the company says it's about convenience, not security. That seems to rule out password-protected Web sites for credit cards, utilities, banking and others for which I might want to be spared having to remember and type a litany of passcodes."

Hmmm, well I guess I probably won't be ordering any of these to evaluate for work, then. :-) Maybe at home though. From the review, it appears they work well and that they passed the Silly Putty test, which is good. Despite Microsoft's advice regarding use of the equipment, I'll look forward to getting my hands on one of the devices to try it out for non-critical purposes.



Add/Read: Comments [3]
IT Security | Tech
Friday, 10 September 2004 20:31:15 (Pacific Standard Time, UTC-08:00)
#  Trackback