October 2004 - Posts
I can't believe this! I just got my Homing Beacon, the official Star Wars newsletter. I already knew the trailer for Revenge of the Sith would be released in november, but after reading the following, I'm quite pissed:
The eagerly awaited teaser trailer for Star Wars: Episode III Revenge of the Sith premieres worldwide next week on starwars.com Hyperspace. In the early afternoon of Thursday, November 4 (US time), the trailer will be available for high quality download only to members of starwars.com Hyperspace, in partnership with AOL.
November 8 the trailer will also be available for the world, but who cares? Everyone wants to watch the trailer 24h a day from the moment it's released!
Luckely we have eMule and I doubt the trailer won't be shared there from the moment it's released. Lucas goes way out of line with his drive for mo' money. Releasing every movie five times on VHS, then a few times more on DVD is already way too much, and wanting money for early access to the trailer is too much.
Oh ja, en Amstelveeners zijn saaier!
This post is especially for Izendooren! ;)
Michael Howard was curious about how many defects turned up in IIS6 and Apache2. So he made up this post in which he shows the following graphs:


All we can say is IIS6 looks pretty solid! But a lot of other people asked him, how the results were for IIS5 and Apache1.3 and how SSL comes into play... So he made another post here.
Michael Howard however is a Microsoft employee, but it's good to know these graphcs come from Secunia.
Ofcourse we have all read about the Provider Model (part 1, part 2), which Microsoft claims is their invention. Ryan Whitaker has made a post in which he explains you should not use it when you don't need it, although it looks very cool. Which it does, as it seems, as with everything Microsoft overhypes. As like Yukon and Whidbey.
Anyway, from experience I can say he's right! We did however need it, or a version of it. Our project had to support multiple databases, multiple mail servers and multiple geographical systems. As it was a product our company sells, clients aren't too happy about buying your product when it only supports SQL-Server, for example. The license isn't the problem, but when you got a few Oracle admins, it'll cost a lot to upgrade one to SQL-Server or get yourself a new admin ;-).
Anyway, it was fun while implementing it in the proof of concept, but I already knew the other developers would not like it. Most developers already have problems with simple GUI, Business Layer and Data Layer, the provider model introduced another three 'layers'. One class which defines everything and should be inherited, one class which (we'll call) reroutes every call to the (dynamically loaded) provider and one class for it's implementation. And don't forget the other implementations you write (mostly) afterwards when you're done with the first.
So that's three new 'layers' every developer has to go through. But more's to come.
I had one example to look at, DotNetNuke. If you look at the way they implemented it there, you'll see every call to the database has a separate method, as you most of the time would have. But DotNetNuke uses a lot, so a few hundred methods are defined in one class, as is the rerouting part and the implementation. Although it's not only really ugly, it's also practically unusable when working in a team of developers. Only begin to wonder what'll happen if every developer wants to add his/her method. Although we used the same method for the defining and rerouting, we used a different method for the implementation. One class the provider would call, and this class would call an internal method, in a class specifically for one piece of functionality. So if we'd have customers and products, the implementation class would reroute all calls to either customers.cs or products.cs. This introduces another, the forth class.
To get back to our project, we also had interfaces for every layer, except gui ofcourse, which made out of 3 layers, 2 interfaces, 4 classes for provider model a grand total of 9 classes to go through before we could get anything out of SQL-Server.
But hey, if the customer requested it, we could also get it from Oracle! ;-)
Just remember, use YAGNI before using the Provider Model!
I never heard of the term, but the following made me laugh my a$$ of!
"OK, Sam, why do you want to add it now?"
"Well, Ron, it will save time later."
Unless your universe is very different from mine, you can't save time.
After a zillion of posts on how great GMail is, who already has an account and more, more, more of the same, finally I'm blogging on GMail. Not on how great it is (although it is!!! ;)) but about a GMail Agent API for .NET!
You should really check out this website on what it can do, but in short, you can manage logging in into GMail and read your mailbox.
On the same website you can also find a tool written with the api to import addresses and a notifier.
They just released version 0.6 with proxy support, and it also compiles under Mono. And you know the rule, if it compiles, it works!
Old memories...
Paper, a 64Kb intro by Statix, partially build on my own computer. Statix crashed it so hard I lost most of all content on my harddrive, where I had a BBS running. Luckely I could restore it and most of the files.

And one of my favorites, Fashion by Logic Design. Logic Design was the Dutch part of TBL before they joined that group, The Black Lotus.

I'm kinda bored at work with no account to logon to the development network, so nothing to do but browse the internet.
Just browsed tweakers.net and found a tool called DOSBox, which emulates MS-DOS. But, does more! It emulates realmode/protected mode, XMS/EMS, VESA Graphics as well as a good old Gravis UltraSound (GUS).
Together with a nice list on pain.scene.org you can see that demos like Dope by Complex, Headache by Psychic Link, Second Reality by Future Cew, Solstice by Valhalla, Stars by NoooN and lots of other demos work within this emulator!
Too bad I have family coming over tonight, because I want to try these babies out!
Get DOSBox here.