The wonderful world of mrgeesbigcircus

We have a WinForms application at my company which is used to basically set up and configure a user's Web.Config file as part of the instalation process of our web software.

I'm currently going over it with a fine-toothed comb to make the interface and the flow of events a little nicer for the user.

One of the aspects of it I'm changing is to have a user-input SQL Server name and database name written back to the Web.Config file into a custom section of the configuration.

One problem - that doesn't work. Not through the built in/standard methods that .NET provides anyway.

The simple way of accessing section of the Web.Config should be as smooth as this:

CustomConfigSection myConfigSection = ConfigurationManager.GetSection("MyCustomSection") as CustomConfigSection;

This, whichever way you cut it, always returns null. There's a number of people on the web having the same issue, and the problem simply seems to be that a WinForms (or console for that matter) application does not like to deal with custom sections.

The quickest way I've found around this is to read out the Web.Config file as XML, make the changes to the required element, and save the file. It's a bit crude, but here's an example:

XmlDocument doc = new XmlDocument();
doc.Load("path/to/file.xml");
XmlNode myNode = doc.SelectSingleNode("//configuration/MyCustomSection");

myNode.Attributes["SomeAttribute"].Value = "SomeValue";

doc.Save("path/to/file.xml");

Hopefully this might help other people beating their heads against a wall trying to create custom this that and the other trying to get it working - and if anyone does actually have a solution, let me know.

Best - or even just good - development practices, are what we all aim for. Agile development, clean code, beautiful tests - it's like a movie scene, looking off into an imagined future of sound principles, efficiency and collaboration. With soft focus.

All is well and good if we can implement best practices - be that by being a freelancer, self employed, at a senior level or by being very influential. But what happens when you're none of these things, but you hanker for that movie scene when everything around you is going to pot?

If you're a developer or designer working for a company, chances are you're going to be working by the company's set of principles and practices - whether you like it or not. You might be able to exert some professional opinion, but, if things are set in stone, it's fair to say you're going to be banging your head against a wall.

So what to do? Here's some options:

1. Lead by example

If you're the only one wanting to put best practice development methods in place, then you go for it. Start putting in place the practices that you want to use in your own work, as and when you can. If you can prove that the methods you are using are helping to enhance the way you work, hopefully others will follow suit.

2. Get colleagues on board

Promote what you're doing to your peers - how them that the way you're working is helping, and offer to help them get up and running. If you're company infrastructure supports it, start a wiki or blog about your practices.

3. Pester management

If all else fails, become a memo pest. Email senior staff, managers, directors - whoever it is with enough oomph to make positive change. Give details of what changes could be made to developement practices, what benefits they would have, as well as their shortcomings and timescales for implementation.

It might seem like you're going to have to grin and bear it and take on board bad practices that a company might be using, but have faith - best practices are called best for a reason, and, with the right nudging, your commitment to making them commonplace isn't far away.

On my way into work this morning - which deviated from the usual cycle ride in favour of a lift in the car - I noticed some new car park signs just as we entered the Nottingham city centre boundary (they could have been there a while, but hey I'm a cyclist, what do I know?).

Ahem. Anyway, these electronic signs indicated the number of free spaces in a number of the main car parks within the city. Electronic signs like this did exist previously, but only when you were literally a turn away from a particular car park. Not very handy for planning a route to the nearest free space.

With the addition of these signs just as you're entering the city limits, it gives drivers the oppotunity to plan ahead and decide not only which car park would be least busy, but also which route to take to get there - rather than getting stuck in a jam only to find there aren't any spaces left.

It got me thinking about how this is an easy to implement - but oft overlooked - piece of user interface design. By making your users aware of potential hazards at an early point in their journey (based on data you are already aware of), it allows them to plan ahead, and not get irrate when they find their destination does not live up to expectation.

Take for example a recent Amazon "journey". We were buying a number of items, all neatly collected in our shopping basket, and proceeded to the checkout. Three or four steps - account login, shipping address, payment details etc. - and then we were told that one of our items could not be shipped to the chosen address. Heartache and confusion reigned as we tried to get back to change the address and resubmit the order.

In the end we angrily deleted the offending item altogether - but if we'd been informed at an earlier stage of the process, would it have been as much of a hassle? Probably not. We would have anticipated the problem well in advance, and prepared ourselves that we might not be able to get the item delivered.

Keeping users informed, and informing them early, reduces tears before bedtime and makes you look like a lovely human being. Well done you.

Just having a play around with some logo design for one's self. Not too sure where I'm going to use this - suppose I could get some business cards done and throw them at random passers by on the street.

Why has the term "developer" worked it's way into not only modern IT terminology, but social language in general, as meaning anything along the lines of software, web or database development?

Photos are developed. Why isn't someone who performs that task commonly known as a developer? Business Development Managers are known just as that, not Developer. It's such a common word, it seems strange to be recognised solely for this meaning. Hopefully I can be proved wrong.

So when did this occur? If I said to my Gran "I'm a Developer", I'm pretty sure she'll know what I'm referring to. If you search Google, developer will turn up developer.com, a site specialising in software and web development. The next search result is the Wikipedia entry for Software Developer. No photo developers to be found.

Analyst can mean a lot of things over a number of industries, including IT. So can Engineer. So what is it with Developer?

Maybe I'm just being daft.

On a side note, what did the word "orange" mean first - the fruit or the colour?

Web Typography seems to be the new web-darling at present, and why not? Allowing designers and developers to use a broad range of type, opening up new realms of web-expressiveness, bridging the gap between print and screen.

The advent of the @font-face CSS property and (seemingly) every single design blog covering web typography in their articles only strengthens the fact that this is the way the web is going.

But I worry. I worried when Flash came onto the scene. I worried when marketing executives got hold of the phrase "Web 2.0". I worried when Ajax was developed. And now I worry about web typography.

You see, the problem is with some people, is that they don't understand the word "subtle". Subtle means toning it down. Subtle means pare back the implementation. Subtle doesn't need 5 extra plugins for your browser, nor does it require you to wear sunglasses

The web is a beautiful and interesting place. Let's hope it doesn't start to look like a toddler started playing with the font settings.

I've just been having a tidy up of some bugs on my company's web software, and whilst fixing a simple issue it struck me as how much time it could save users when filling out forms.

The fix was for automatically selecting an item in a DropDownList if it was the only item, rather than automatically displaying a "Please choose from the list..." style default item and forcing the user to actively choose. A simple bit of code like this, for example...

if (DropDownList.Items.Count == 2)
{       
        DropDownList.SelectedIndex = 1;
}

...means that the default item is negated, and the first, and only, "proper" item (be that a data-bound item or whatever) is automatically selected.

If you've got even just a few DropDownLists on your form, having single items in a DropDownList automatically selected could cut out a heck of a lot of wasted time for your users.

As a developer, when you're creating a new (or expanding an existing) application, it can be incredibly easy to throw in everything including the kitchen sink to make it the bestest application ever conceived. Even with a rigid specification to follow, your own personal feature-creep can throw the whole project off course.

On of the key aspects of keeping grounded when developing is to lsiten to your customers. Whether your marketing directly to users in the outside world, or developing something internal that your colleagues will use, everyone that uses your software is a customer - and the feedback they will give you is gold.

They will not only tell you what's great about your application, they'll also tell you what really sucks. They'll tell you what features they'd like to see in future releases, and what features that are currently there might not actually be that useful.

So drop the ego, get ready for criticism and listen to the feedback that your users are giving you. Take on board what they tell you and it could save you wasting time developing a pointless feature that no-one will use, or not developing a killer feature that you hadn't even thought about.