Ernst Kuschke

Microsoft is treating all SADeveloper members for some tenpin bowling, and I hope to see all you guys at the Durban-based event! We've decided that SADeveloper will challenge Microsoft, so if you're good, come help us ;-) This leads up to the Whiteboard session we'll be conducting the following day at the Hilton - the focus is on high level developer and architectural guidance for developers using or evaluating the .NET Framework and Visual Studio .NET. Don't miss this opportunity to ask questions directly to knowledgable people in the field!

[UPDATE] - The Durban dates follows:

Security seminar told us that, and we heard it all over at DevDays. By now everyone should know that you should *never* hardcode a connectionstring (or any string literal that should be secure) into an assembly. Patterns and Practices, Microsoft. Encrypt your connectionstring, and *then* put it somewhere. Somewhere like the appsettings section of your app.config file. How secure is this practice really?

Well, it's obvious that you should never hardcode any secret into a .NET assembly, since a quick spelunking with ILDASM on the assembly will reveal it to prying eyes. So we're told to encrypt and put it away in app.config. If anyone would get their claws on app.config, they would see something like this:

Microsoft's DevDays was a huge success in Durban yesterday, and overall throughout the country.

Although the opening keynote (Danny Naidoo) contained the ussual marketing mumbo-jumbo, it was all relevant and informative on the direction Microsoft is taking in the next few years. It also gave a quick overview into new technologies like InfoPath and SQL Reporting Services, technologies I think we'll definately use in our company in the very near future.

I attended the Smart Client Track. The session on secure data-access overlapped almost entirely with the material from the recent security seminar, and yet most delegates only heard of many concepts for the first time. It just made me realise once again how neglected security is in general, especially with development in our country. C'mon guys, this is important stuff!!

A nice end to my day was dinner with the Microsoft guys and their groupies last night :) I could talk to these guys for hours and hours - extremely interesting lives are led by some extremely interesting people in our little IT industry down here in SA!!!

I was born in Namibia (believe it!), and since my family has been quite spread around the globe; mostly Africa. An uncle (Namibia) has recently started a brilliant innitiative where he sends mail to a whole list of family members' email addresses, and responses are also sent to the whole list. This had the effect that we're all starting to get to know each other again - just today I found out that another uncle (also Namibia) has started importing motor cars. This is real interesting (entertaining!) reading material for any family member - my family is one of the most diverse ones you'll find. Ever.

I've lately been playing with the idea of setting up a Family Sharepoint Server. Do any of you do something similar? The internet has so many wonderful uses :-)

DevDays is around the corner. This year's event sounds promising, with a Web Track and a Smart Client Track, and I definately recommend every .NET developer to attend. Microsoft has been kind enough to enable SADeveloper to host an area at the event where delegates can interact with us. We will also hand out free goods to some lucky delegates, so make sure you register!

We need some more people to man the site at the Durban-based event, so please leave your name in the Comments section of this post if you're keen. Alternatively contact me here.

After realising that even though it looked damn fine, it was a bit hard to read my previous “new look” (thanks for pointing that out, Wolfgang!), I settled on this final “XP feel”.

I've been getting lots of hits from people googling for “Shavathon”, I presume they are looking for the photos taken at the event. Sorry guys, I have no idea what CANSA did with them, but I do have some news on the event! Apparently we did break the world record with around 25 000 heads shaved. Congratulations to everyone who took part!!!

Revamped the blog - like it?

It took me a while to wrap my brain around the idea of delegates and events when I started out with .NET. Today, every time I think about events, it takes a while for it to become clear again. This is how events and delegates work.

Typically you'd have a class raising an event, and that event will be acted upon by some application, or class. Let's call our class that raises an event EventRaiser, and one that consumes the event EventReceiver. In EventRaiser we have an event called RaisedEvent, and when that fires, we want EventReceiver to let the user know about it. In EventRaiser we would define an event like so:

public delegate void RaisedEventHandler(object sender, System.EventArgs e);

public event RaisedEventHandler RaisedEvent;

RaisedEvent is of type RaisedEventHandler, which means that an event is of type delegate. Why then have two delegates here? The event 'delegate' has one slight difference from a regular delegate: although it can be referenced throughout its scope (meaning, if it's public, other classes can reference it), it can only ever be called from within the class in which it is declared. There's a simple reason for this - imagine if it was publicly callable - you'd be able to raise EventRaiser's events from EventReceiver! You still need a public delegate though, so that this can point to the function in your EventReceiver to be called when the event fires.

This means that, when handling an event of a class, not only is EventReceiver aware of EventRaiser, but EventRaiser is also aware of (has a reference to) EventReceiver, via the event's delegate.

Something very few people know is that by prefixing your sprocs with "sp_" actually downgrades their performance!
SQL Server by default checks the master database first for any procedure starting with "sp_". When not found, SQL Server assumes the sproc's execution plan isn't cached, and acquires a short lock on the sproc to recompile it.

I mentioned this on the SADeveloper site, but thought it useful to whoever might be reading this blog too :)

First day on the new job was spent (mostly) in meetings with our main client, and then with the dev team. There a helluva lot for me to learn - these guys have a data access/business layer architecture pattern that I'm not 100% familiar with yet, and the business itself presents loads to learn... I can't believe the day's over already!!! It went extremely fast - yesterday this time (17:30pm) it was only 15:00pm ;)