Atlassian Developer Blog: Good Fences Make Aloof Neighbours:

“In an enterprise environment, where every contributor to the wiki is identifiable, and every change reversible, what value remains in restricting edit rights a priori?”

I stumbled on this on the atlassian site. My group is trying out Jira and the Confluence wiki. This article from an atlassian developer expresses some of the core oversights enterprise wikis face. Rights management, like any security measure, is a balancing act. How much does rights management cost you in terms of lost good and effort spent managing the management? How much benefit do you gain?

My default setting for behind-the-firewall social software is full rights with authentication, with security imposed as needed, and only the amount of security needed to protect from specific probably problems.

As I read Coding Horror: Is Your IDE Hot or Not?
I noticed the call for someone to create a hotornot site for IDE screenshots.
It didn’t seem like a bad idea, and I immediately thought of Ning, a social software platform that debuted a while ago.
They make it dead easy to create an actual application relevant to whatever social software use you are into.

I created this IDE Hot or Not ratings site in less than 10 minutes.
It’s not tweaked, it could use more care, but damn – 10 minutes and it is working. It’s got a few screenshots up there and a few ratings. I’d encourage you to submit yours and rate others for a lark.

And take some time to play with Ning. Next time you hear “Someone should whip up a website that lets us do x” you can finish it before they stop telling you how cool it would be. BTW – all the source code for your app is editable on Ning, but the standard stuff is truly code-free. It just works.

I’m thinking about configuration screens for stuff at work.
Some setttings affect things that happen on our server.
Other settings affect things that happen on the clientside.
There is a conflict between building things ahead of time and crafting them to be very userfriendly, and building things dynamically on the fly and letting them be very flexible.

If a setting is going to only affect things on our server we want to avoid having to do a new client release just to let the client change them. After all, the client program doesn’t need new code. These kinds of settings it would be good to build user controls for dynamically. That way the client doesn’t need to download anything new when we expose new settings.

If a setting is going to affect only the client side, then we have to deliver new components to the client to consume those settings. In that case, we want to deliver the new functionality along with the settings and it makes sense to construct the controls beforehand so they are as userfriendly as possible.

One way might be to deliver a document on loading up configuration screens where you list the major pages of configuration. Each listing would describe either a usercontrol to load or a list of options to construct a control around. For dynamically created settings controls you would create checkboxes for booleans, textboxes for mapping strings, combo boxes for enums, etc, then slap them all in a flow layout or something.

Even if the coolness of dynamically created controls for server side settings is doable, is it worth it? If we are creating a way to deliver updates to users in the background, shouldn’t we just use that?