The Museum Of Modern Thinking

I recently had to extract some items from an IList and pass their Guid identifiers to a legacy SQL Server stored procedure that required a list of comma-separated values.

Rather than loop round the list, appending items to a string with a comma at the end, then stripping the last comma off, or adding the chosen property to a IList, converting it to an array and then String.Join-ing that array, I came up with the following:

string divisionsCSV = String.Join(",", ((List)divisions).ConvertAll(d => d.DivisionID.ToString("b")).ToArray());

(There’s a casting of divisions to an List<IDivisionView> because a) divisions is an IList and b) ConvertAll is on the concrete implementation of IList)

I'm using ConvertAll to, er, convert a single property of every item in the list, in this case the Guid identifier of the division to a string. Incientally, I'm keeping the Guid parentheses thanks to the "b" parameter of the ToString call. The ToArray call then stuffs it all into an array ready for the String.Join call.

Any thoughts, comments or improvements?

Not existential angst, but wondering where I need to position myself as a developer. I’ve missed out on some technologies, and I’m wondering how far down the rabbit hole I should go with some of them.

I’m still very much a web developer, so I certainly should be looking at ASP.Net MVC and jQuery, as well as upgrading my knowledge in the standard Web Forms, not forgetting the AJAX toolkit as well. Behind the scenes, looking at data storage layers such as LINQ to SQL and their enterprise patter, as well as applicable patterns such as the Repository Pattern and even the Active Record pattern.

That’s where things get, frankly, a bit dull and convoluted. I read a great post recently about how coding these days is how to link one library to another, or just whack some XML together to control a Spring.Net DI solution. I, like the author, can’t find the fun in that. Sure, it may get projects done quicker, and it’s standard, but it can also be a lot of overkill. That’s why I’d prefer a simple approach to projects, nice and lightweight, no navel-gazing about what might be required two years down the line, not coding an interface for every single class because “it’s the right thing to do” although it’ll never be used, adding tests to every single method (even private ones) because “it’s the right thing to do”, etc.

I’m a firm believer in Jeff Attwood’s mantra YAGNI – you ain’t gonna need it. If the customer hasn’t asked for it, and if there’s no chance it will be required within a year or so, don’t code it. Write your code in such a way that things can be replaced easily (and yes, I guess that does mean some interfaces, but surely not on every single bloody class), and keep it simple. I use as many syntactical shortcuts as I can, as I’m lazy, but that’s why they were added to the language.

Anyway, a bit off topic – I’m really writing this as a store for where I should be heading. I am a Microsoft chap, and I enjoy the products they put out and their technoology approaches. I find it amusing when I suggest a Microsoft solution (such as ASP.Net’s Forms Authentication) and am told by a colleague that he’ll write it themselves – how many people does Microsoft employ to work on stuff like this? How much R&D do they do? And one person thinks they can do it better? Heh, it’s another contradiction, I guess – I said I don’t like merely linking up one library with another, but I guess you could say that’s all I’m doing with the Forms Authentication, but hey, it’s sometimes a pain to get right and it’s fun wreslting with it BUT it provides a hell of a lot out of the box…

And don’t get me started on form validation – “oh, we don’t use the validation controls because they don’t work”. Yeah, ok, I’ve used them countless times and they seem just dandy.

Gah, back on topic. I really should be looking at what’s new in Windows Forms and the top best practices in that area as well, and look at Silverlight as well.

Hmmm, lots to cover – I’d better get started…

Just a quick heads-up, I’ve added a PayDate Calculator page from which you can download a futility that calculates the number of weeks in a month for budgeting purposes – go and try it!

PS: It’s called a futility because it’s a 68k application that requires a 22mb Microsoft .Net 2.0 Framework installed Still, not a reason to not try it

I realise this is a bit of a departure from my usual posts (i.e. I’m not ranting), but I’d thought I’d share a rather useful bit of ASP.Net code I’ve been using.

When a user is presented with a GridView of data they can delete, it’s usually a good idea to give them a “Are you sure?” confirmation dialog using Javascript, like so:

<asp:Button ID="uxDelete" runat="server" Text="Delete" OnClientClick="javascript: return confirm('Are you sure you want to delete this record?');" />

(The above is an ASP button, to be placed in a TemplateField in a GridView)

Now that will give a plain “Are you sure?” message, but it’s a bit vague – what if the GridView has twenty-five, fifty or one hundred records displayed? Will the user be sure they clicked the right delete button for the right product / entry / whatever?

By some clever use of the Eval statement, the dataitem you want to delete and some character escapes, it’s possible to put an identifiable piece of data in the Javascript confirm call:

<asp:Button ID="uxDelete" runat="server" Text="Delete" OnClientClick='<%# Eval("ProductCode", "javascript: return confirm(\"Are you sure you want to delete {0}?\");") %>' />

Now, when the user clicks delete on an item, the name of the item will appear in the confirm dialog, reinforcing their decision to delete.

Another reason I’ve blogged this is to have it somewhere where I can always get hold of it – I don’t remember stuff as well as I used to