Last weekend I attended the excellent Code Camp Oz 2006 at Charles Sturt University in Wagga Wagga, New South Wales. What is a Code Camp? Well it's not deep training in .NET, and it's not a learning course for VB or C#. It is a no-cost, tightly-packed, two-day-long discussion of broad content for developers, split into about 50% upcoming technologies and 50% current topics. Topics covered in Code Camp Oz 2006 ranged from WPF (Windows Presentation Framework, formerly known as "Avalon") and WF (Windows Workflow Foundation), to the Compact Framework, SQL Server and Team System. The presenters were local...

As mentioned previously, I have been using IdeaBlade DevForce Express to generate a business object layer for a .NET 2.0 project. For this project, I needed a way I could determine the SQL Server that the DevForce business objects would connect to, without necessarily creating a business object and testing the connection properties. IdeaBlade DevForce creates a helper assembly with an embedded XML document called "IdeaBlade.ibconfig" containing the SQLOLEDB connection string for data access, and so I needed a way to: load the helper assembly read the XML document from the assembly's embedded resources find the connection string get the server...

This is a current picture of me - if you are going to Code Camp Oz in about a week's time and recognise me, please come up and say hello :-)

I was listening to Greg Low's podcast SQLDownUnder show 13 with Bill Graziano, and my ears pricked up when Greg made the comment that most of the consulting he does is on improving performance, and posed this as a question back to Bill as to why...actually, I became interested because Greg mentioned that developer knowledge could be to blame - that's me :-) The first part of Bill's answer, and the part that stood out, was: "...[I]t's easy to grow data at a rate that we never could before. Back in the 80's...it was just so much harder to generate data with...

SQL Server MVP and Oz Regional Director Greg Low posted a while back on "What Makes A Good Data Entry App" (I'm just catching up on some old, bookmarked, reading). He has a checklist of important considerations for designers, which is well worth following. I found out the hard way that Greg's remarks on font sizes are relevant - an application I'm designing used the default font and size which would be fine for me, but after demo'ing the application for a user I observed that for this particular user, my screens seemed unnecessarily compact and small. Changing the font size and...