Kent

So, the word, "So" (at the beginning of a sentence) was a point of discussion today (on Twitter), and I felt it deserved a broader audience. For those who care, there is a lovely article explaining everyone's favourite Microsoftism (that isn't really a Microsoftism).

The bits move on, and only the code keeps changing.

My complaints in the last post are no longer valid. As of the 4/16 release of the MVC framework, VB no longer has that weird behaviour. Now, all action methods must return an ActionResult, so they become functions in both VB and C#.

Of course, you already knew that because you're not behind on your reading, and you've already read ScottGu's post on this. I just read blogs for a living (partly), unfortunately the posts I want to read oftimes get pushed back because of it.

Don't ask why, but I decided to try to use the porridge that was "just right" in VB while trying to create a site using the new ASP.NET MVC framework. As I will no doubt forget the syntax to use in about 42 seconds, I'm including it here. Others may find it useful as well.

ActionLinks:

<%=Html.ActionLink(Of ViewEngines.CategoryController) _
    (Function(c As ViewEngines.CategoryController) c.Add(), _
    "Add Category")%>

Form definition:

<%  Using Html.Form(Of ViewEngines.CategoryController) _
    (Function(c As ViewEngines.CategoryController) c.Update(ViewData.CategoryID), _
    FormMethod.Post)%>

The Function(c as ViewEngines.CategoryController) c.blah syntax is the equivalent syntax to the shorter, more symbolrific C# syntax: c => c.Add().

That was still giving me an error. What I found (see below) was that the trick seems to be to change your methods into functions (instead of the Subs that I was using), and it would work:

    Public Function Update(ByVal id As Integer) As Object
        Dim c As New Category()
        c.LoadByKey(id)
        c.LoadFromPost()
        c.Save()
        RedirectToAction("List")
        Return Nothing
    End Function

Now someone can please tell me I'm wrong, and there is a simpler solution. Barring that, I think I might stick with using the "less correct" versions of the calls (or, more likely, using C# for all my MVC sites)

(Special thanks to Chuwanga on the asp.net forums for the original solution. I wouldn't have figured out that last step)

Or at least an effort.

I went down to the regional district office last week for one of their planning meetings. The masses had gathered to determine a vital matter for the three communities of the valley: Should there be a new gas station?

While the matter certainly wasn't anything of global proportions, it did bring one characteristic of the citizens here to light: Just how long have you been living here? One speaker after the other started their proposal with, "I've been here n years..." I imagine the message is supposed to add weight to their opinion.

You see and hear this all the time in dev circles as well: want ads ask for "Java developers with 30 years experience." Developers make blog posts and statements that begin with, "I've been using .NET since n" as though it really matters. I use myself as an example. I wrote my first .NET code a few months before it was shown at PDC, before it was even called NGWS (pronounced Nigwiss). However the set of .NET developers more skilled than myself is roughly equal to the set of .NET developers in the world. It's not how long you've been doing something, but the degree to which you're pushed yourself at really learning it. Don't get me wrong: I have pushed myself, but as my life is not measured in kloc, I don't consider my skill equivalent to someone who has to keep metal in motion.

So, how can you learn something so that it actually means something? Well, the first (and obvious) method is to actually use it, but to use it in a way that you're actually learning something. Stepping through samples from articles and Web casts is fine, but you need to break things, change values, make it fizz. Scott Hanselman's series on reading code is quite useful, especially if you try to "guess whodunnit" before-hand (predict how the code should work, what would happen if you changed it in some way, how you can use it in your own applications, etc.) Another great resource is Larry O'Brien's series on learning a language. Run through them every six months or you. You'll be surprised at how different your resulting code might be as new techniques and larnin' enters your brain and fingers.

While it may seem counter-intuitive, teaching is an amazing way of learning -- I learned more about programming^[1] by teaching it to others than I did by actually writing code. Different developers have different (sometimes way different) ideas about what is good code, and by discussing it with them, you grow (even if you were right in the first place). It also helps solidify your own arguments by forcing you to actually think them through and explain them in ways that others can understand. Plan a lunch workshop series at work, do a talk at your local User Group, or even sign up to help at the local continuing education facility.


(For those interested, they still haven't decided if they'll allow the new gas station.)
[1] Don't even get me started on what I learned administering and teaching Microsoft Mail for years

While these pages are in Flash, they can/should also be inspirational for those working in Silverlight. Probably even for WinForms and ASP.NET developers.

As the good Jon Galloway pointed out the other day, Silverlight developers should really think of what they are doing from the user perspective, not from the developer "oh, shiny!" perspective. Don't just create something that could be done in HTML with a little JavaScript. Doing this just creates a site that is less functional, less searchable and overall less worthwhile. (yes, I'm looking at you Download center beta)

There was a backlash against Flash when people added it to their sites without consideration. Hopefully Silverlight can avoid a similar backlash, but only if developers avoid making the same mistakes.