Lazycoder

ASP.NET MVC re-factoring

b# - Controller is NOT the New Code-Behind: ""

Ben has a great example of how things can get out of control even in a framework designed to simplify your code. I agree with his point and one of the MVC developers responds in his comments. So it looks like the issue will get taken care of quickly, if it hasn't been already.

I wanted to point out one bit that I saw that maybe needs re-factoring. It was in the original code and the re-factored portion that Ben posted.

Now I'll speak from ignorance for a second since I haven't gotten to look at the MVC code since preview 2. (Just too busy, busy with a new job). It seems to me that these lines could pop up in a lot of places in your MVC application. It would be nice if we could mark certain methods as POST or GET only. Maybe when defining the route. There may be a way to do this already in the routing system.

ASPInsiders is the wrong way to gather feedback

A sneak peak at ASP.NET AJAX 4.0’s client-side templating | Encosia:

"For those of us who aren’t MVPs or ASPInsiders, it’s nice to have a chance to offer constructive feedback and generally not be left in the dark."

Last week I met up with a bunch of people for a geek dinner. A few of them were in town for the ASPInsiders sneak preview/briefing/whatever you call it. I mentioned that I wasn't an ASPInsider despite having worked with some form of ASP since it was a bunch of idc and htx files. A lot of them kindly offered to nominate me if I wanted to be an ASPInsider. I declined. My reasoning for pointing out that I'm not an ASPInsider isn't because I think I'm so special that I *deserve* to be included in that group. It's that if they missed me when sending out invites to the group, who else might they have missed. Probably a lot of people who could provide really great feedback to the team. Is the solution to invite more people and expand the group?

I don't think so. In fact, I think the group needs to go away. I say that not because I want my friends to miss out on a trip to Redmond to meet with the ASP.NET team. But because I feel the time for small, exclusive groups who have insider information and get to give feedback on code and features that haven't been released yet is in the past.(2) That's old school, dinosaur thinking in the software development world. In the case of the MVC team, which has been releasing code and announcing features at LIGHTNING SPEED(1), secrecy and NDA's really only last a month or two before the feature is released.

I know there are probably legal reasons for the NDA. The team/management is probably nervous about showing features that aren't fully baked to the general development audience, only to have them change before release. But I think with a little work and more transparency, those issues can be resolved. Ideally, source checkins would be fully transparent. We would have read-only access to the teams source repository. We could build the framework on our machines and maybe even contribute some code back. But even just a wiki/forum/test site where new features could be demoed and discussed openly would be a great start.

(1) Lightning speed for Microsoft in any case.
(2) As J. Ambrose Little pointed out in his comment below, Membership in the ASPInsiders group is not determined by Microsoft. So they can't be held responsible for defining who gets in and who doesn't. They are a group of individuals who volunteer their experience and expertise to the ASP.NET team. The debate over whether or not the general public should be able to see the same features they do is a separate debate which continues in the comments and elsewhere.

Interviewing software developers: You’re doing it wrong.

Recently my wife and I both updated our resumes and started interviewing around. I ended up taking a position at a new company. What struck me as interesting was how different our interviewing experiences were.

My wife is a PharmD, this is the Pharmacy equivalent of a Doctor of Medicine (M.D.). She has to be licensed for the state she is working in and has to earn continuing education credits to maintain her license. When she goes to an interview, the questions she is asked are primarily about past projects she has worked on or are trying to determine what her personality is like and how well she will fit into the position.

I'm a self-taught software developer with about 12 years of experience, no certification and no license to practice software development. My questions consist mainly of questions trying to determine if I'm lying on my resume or about some piece of historical computer trivia. ("How would you write a linked list?" "I'd use Google as my IDE because THAT problem has been SOLVED son.").

Granted there is a difference between a position where a lack of knowledge could KILL someone versus and position where a lack of knowledge causes a loop to run 100 milliseconds slower. But you can kind of see how most programming interviews are pretty insulting to the interviewee.1 I've often wondered if we could create a licensing body for software development. Some body that is corporation and technology agnostic. Something that is able to put a stamp of approval on a person and require that person to continually learn in order to maintain their license. Right now, we have certification mills that just teach a person enough to earn their Oracle, Java, or Microsoft certification. I know that lots of people are working both inside and outside of those corporations to ensure that the tests contain real-world material and not just bullet-point factoids, but that doesn't stop the certification mills from just giving out answers.

So as it stands, programming interviews are said to be less about the technical knowledge and more about determining how a person thinks. Which is kind of wrong in a way. You're not going to see how a person thinks by giving them a little programming quiz during the interview.

Certification and licensing should be about setting a base level of competency. You shouldn't have to ask someone what the difference between a div and a span element is during a phone screen if they are a licensed web developer. You shouldn't ask a C++ developer to find the memory leak in a given piece of code. What you really want to know are the intangibles. Are they a cowboy coder? Are they continuously trying to improve their skills or are they set in their ways? Will they speak up during a meeting if they see a bottleneck or problem coming or will they just ignore the problem? We, as a group of professionals, need to determine a structure and governing body that will allow us to not wonder if an applicant is lying on their resume, but instead focus on whether or not a person will be a good fit with the rest of the team.

1 - I'm not even going to mention any B.S. questions about your "biggest weakness" or trying to determine your enthusiasm level for working at the company. Those are just stupid, stupid, stupid. Did I mention I thought they were stupid?

Why defining best practices isn’t always a good idea

Recently my daughter was sick. I'll spare you a lot of the gory details, suffice to say vomiting was included. She couldn't keep anything, solid or liquid, down. So we took her into urgent care at our local Children's Hospital. As soon as the doctor came in the room, my daughter started to vomit again. The doctor examined her for a little while and asked us some questions then said that she would give her some IV fluids and some Zofran. Zofran is an anti-nausea drug. Between the two treatments, her vomiting stopped and she was able to keep down some apple juice. The doctor prescribed a small amount of Zofran for us to keep at home and use over the next few days if her vomiting came back.

The reason this incident inspired this blog post is because last Christmas, my daughter had the same symptoms and we took her into urgent care at that time. The main difference was, last Christmas I had different medical coverage and we went to a different hospital. At this hospital, the policy was that my daughter was too young to take Zofran. That meant all they could give her was IV fluids to help combat dehydration. So for the next 12 hours, my daughter vomited and suffered.

Now I'm sure the doctors who made the policy decision "No Zofran for children under age 5" had good reason for making that decision. Zofran has some side effects. They may have felt that the risks outweighed the benefit. However other doctors, with different experiences and background, decided that Zofran is alright for a 3 year old to take if it soothes suffering and allows the child to get some fluids in their system. Two sets of doctors. Two different sets of experience and background. Two different opinions. One had a less than optimal effect on my daughter, but no long term effects. The other had an immediate positive effect, but with more risk.

Defining best practices for your group is a poor substitute for putting trust in the professionals you hire.