ILoggable

Second Life Tech talk @ Google

Saw this incredible video over at Zac Bowling's site. It's a tech talk by the creators of Second Life about their systems. Very high geek content, especially with the prospect of SL switching over to Mono.

I've been staying away from MMORPG's because I just don't need that kind of time-suck in my life, but once you add a compelling programming model on top of that, the temptation is just getting way too strong. So far I resist, but once they have mono integrated, I may have to poke around a bit.

Last time I got sucked into something like this was back in the early 90s, when I started playing around with LambdaMOO which was completely object oriented and user editable. The language I always thought was a variation on Scheme, but Wikipedia claims it a derivative of Algol. Either way, it was a lot of fun to program in and create the world around yourself. But it was addictive. My roommates all got sucked in and at some point you couldn't call our house because someone was always on LambdaMoo (yes, the day of modems... 2400bps modems).

The only thing that makes Second Life less dangerous is that it's build around a thriving economy. So, it's not only conceivable, but an actual reality that you can finance this habit by having the habit and sitting in there coding. I think i'm still going to stay far away for my own sanity.

posted by ether @ 1:32 PM 0 comments  

configSource attribute

I've been using the new <connectionStrings> tag for .NET 2.0 to store my DB config. I used to just have a custom <configSections> handler for it before. But hey, it's built in, let's use it. Now i'm putting NUnit in a bunch of projects so they all need to have app.config files. But i don't want them to each have a copy of the strings. Just means sooner or later things get screwed up. Not to mention that having the config file in the source control tree means that my local config gets checked in and i have to modify them on every machine to match environments. For <appSettings> and my own config handlers, I always had a file attribute to externalize them into a central configuration space. Except <connectionStrings> doesn't have file, only configSource. At first glimpse it looks like the same thing. Sure, it adds some cool stuff, like being able to reload on change, which file couldn't. But the price you pay is that the new file has to be in the same directory or a subdirectory. So much for using one config for multiple apps. I may be overlooking something, but I can't really find any good reference on the subject.

posted by ether @ 11:32 AM 0 comments