Programming
Feel The Func
A little side project I've been involved in, Feel The Func, releases today.
What is Feel The Func? It's the official podcast of FuncWorks.
FuncWorks is a project organized by Mike Neel, Cicelie Caulton, and myself. It is, to put it simply, a banner under which we're going to work on various side projects--the first one being a website for Cicelie's t-shirt designs (Cicelie, by the way, created the FuncWorks mascot to the right, the CodeStock logo, and the CodeStock t-shirts for both 2008 and 2009.)
The podcast is a chronicle of our weekly planning sessions--think Stack Overflow, but with a mix of marketing, design, and art talk as well as code. The first two episodes, which are up today, revolve around trying to define user personas for the site; later episodes will delve into the code a bit more--which should prove to be interesting, because Mike and I often approach both marketing and design from very different angles.
SharePoint Knights and the MVP Program
I don't know how many of you saw this (because it seemed to be mainly a SharePoint thing), but I thought it was interesting. I say that as someone not familiar with the MVP program, nor particularly outgoing or focused enough to be deep into the community, so it'd be interesting to get other people's reactions. I also say that as someone who didn't pay a great deal of attention to it, other than skimming the blog posts.
Joel Oleson posted a suggestion for a community-based group called SharePoint Knights, where membership was based solely on contribution to the community, tracked liked points). Nothing more than brainstorming had been done, but obviously it drew some pretty clear lines within the community.
It was followed by Luther's 10 Points to the MVP program, a critique of some of the problems with the program and the reason for creating a separate, community-focused organization alongside the MVP program. And finally, the response to both of these posts was so heated that the SharePoint Knights project has been put on hold.
I think he has a point about the politics often involved in community, especially when the public face is to pretend there aren't any politics and everyone's one big happy family. Perhaps Luther's theses were a bad choice for his critiques--here was a man who meant to reform an institution, and instead unintentionally created an enormous rift within it.
SharePoint Authentication Fun
While I have a backlog of blog posts I need to write, this one just hit me, and seems interesting (also, maybe I can get some additional insight).
The fact that SharePoint uses ASP.NET's forms-based authentication system is very nice. It means you can tap into almost any sort of authentication scheme you want, rather than being bound to Windows logins or Active Directory.
On the other hand, forms-based authentication doesn't play well with applications that aren't web browsers. (This is, incidentally, why SharePoint gives you the option to turn off client integration.) Pretty much any application that can download data from the web recognizes a 401 status code--but it can't tell the difference between a login page and the content you were expecting.
You might have encountered this if you've tried to open a Word document from a FBA-secured SharePoint site. If you're lucky, Word will use IE's authentication cookie and work seamlessly. If you're not lucky (and you usually aren't), you end up with the login page as a Word document. Which is, to say the least, not particularly helpful. (I think I read that this is being addressed in Office 2010, but I can't remember where, so it's possible I'm just making this up.)
Anyway, membership providers. They provide a great deal of flexibility. But they can also box you into a corner in terms of expectations, since most SharePoint-enabled applications assume you're using Windows/Active Directory logins.
As an example, we have the following situation on a SharePoint project I'm currently working on:
- Most users will access the site using forms-based authentication (because of other authentication requirements). However, they also have an Active Directory account that they can use to access the site through an alternate access mapping.
- Other users do not have an Active Directory account at all. They will have to access sites via FBA backed by a plain old ASP.NET SQL membership provider (or something similar).
- A key requirement of the project is that data be downloadable for offline use (via products like Geo-Replicator or Colligo Reader--it's not been decided which) for all users. Both of which require an AD login to sync data.
I'm not complaining, of course, because these aren't really pie-in-the-sky requirements that are conflicting. They are all necessary to the product being both useful and secure. But the balancing act is somewhat mind-boggling, because every choice requires some difficulty on the users' part.
So it's sort of a stalemate. We could in theory keep our options open on the offline use requirement, but it would require setting up a separate AD domain for external users (which is both a maintenance nightmare, and potentially impossible because of security requirements). Or, we can stick with FBA for our external users, which cuts out some of our options for offline-SharePoint products. (Although, interestingly enough, it doesn't negate all of them.)
I'm going with the latter, which feels like a hack in certain ways, but it meets all the requirements, satisfies them all as much as possible, and doesn't overly complicate things as part of the compromise.
Working From Home
In IT, and specifically software development, the fact that we can do much of our job from literally anywhere is one of our great luxuries.I've been working from home for 8 months. In fact, one of the reasons I took this job is that I'm working from home. I should point out that I am actually a full-time, salaried employee--this isn't contract work. Working from home is, I have to admit, really amazing. But every time I hear someone say, "wow, you get to work from home?" with a shocked or jealous tone, I cringe...
Flickr, Caching, and Overcomplication
I mentioned offhand in a previous post that I'd modified my photo section to use Flickr. A few days later, I realize this may have been a bad idea.
I've gotten a few tracebacks from this site where a search engine bot has hit the photos section and absolute broke this functionality. It's a big block of "Connection reset" messages sitting in my Inbox. And they do always seem to come in large numbers, so I don't think it's just randomly crapping out.
So tonight I coded up (what I think is) a fairly elegant caching solution. It will hold on to some number of Python objects (default is 1000) by key, and delete the least-recently used data as new items come in. And the main Photos page is caching each individual photoset, so that no additional calls need to be be made when you drill down to the Photoset level. The same thing happens on the Photoset page with individual Photos.
In testing, it hits me that Apache spawns a lot of different child processes (or maybe threads, I can't remember), and each process will necessarily have its own cache. (I count 9 child processes running right now.) So the odds of a search engine bot actually making heavy use of the caching is relatively small--unless they're just lucky and get the same child process each time, or stupid enough to request the same URL more than once. So for the amount of effort I spent, I surely could have just written a daily sync script to pull down all of my Flickr data to a database.
Of course, that would be too obvious a solution. (And, I gotta admit, writing a data sync script just doesn't feel as 1337 as doing caching.) Oh well. At least I have a caching module that I can use for this site or Chainsaw Buffet gets popular, or at least Slashdotted. (Do kids still use that term, "Slashdotted?")
... like that's ever going to happen. :)