Then I tried to create a Custom List. I had event receivers attached to custom lists (ListTemplateID=100 for those who care) and i got this:

Cannot insert the value NULL into column ‘Name’, table ‘[somesharepointcontentdatabase].dbo.EventReceivers’;
column does not allow nulls. INSERT fails.
The statement has been terminated.

Took me a good two hours of trying everything I could think of with my XML and code, only to be repeatedly thwarted by this database-level error! I tried commenting out different sections of my receivers and still got the error. When I commented the entire <Receivers> section, things ran fine, but not the <Receiver> items inside. What the hell is going on? Read on!

I’ll give an example of what I’m talking about here – the following comes from MSDN:

feature.xml:
<Feature
Scope=”Web”
Title=”Simple Updating Item Event Handler Registration”
Id=”A6B8687A-3200-4b01-AD76-09E8D163FB9A”
xmlns=”http://schemas.microsoft.com/sharepoint/”>
<ElementManifests>
<ElementManifest Location=”elements.xml”/>
</ElementManifests>
</Feature>

inside the feature.xml file (above) it references the following file:

elements.xml:

<Elements xmlns=”http://schemas.microsoft.com/sharepoint/”>
<Receivers
ListTemplateOwner=”ADDABAAA-1111-2222-3333-111111111111″
ListTemplateId=”104″>
<Receiver>
<Name>SimpleUpdateEvent</Name>
<Type>ItemUpdating</Type>
<SequenceNumber>10000</SequenceNumber>
<Assembly>SimpleUpdateEventHandler, Version=1.0.0.0, Culture=neutral, PublicKeyToken=10b23036c9b36d6d</Assembly>
<Class>MS.Samples.SimpleItemUpdateHandler</Class>
<Data></Data>
<Filter></Filter>
</Receiver>
</Receivers>
</Elements>

This works fine. Here’s something interesting though: any comments – <!– Like this –> - you have in the <Receivers> node will be literally interpreted as <Receiver> nodes! That means whenever it tries to attach event receivers to any list, it treats the comments as actual receivers! That’s right, for whatever reason, the code that ties event receivers to lists literally loops through every node (comments are still considered nodes!) and tries to use them instead of using any sort of XPath. How hard is it to use “//Elements/Receivers/Receiver” as your node collection XPath? I really hope whoever wrote that code got the ruler or something.

The solution: Remove comments from your Feature xml file(s).

I say this because God only knows where else this is happening, and the odds of you realizing that it is something that should just work, like comments, are probably not that high. Remember folks, sometimes the most obtuse problems have the most simple answers. Try not to over-think things.

A huge thank you must go out to Janne Mattila for being the first (and apparently only according to Google) documenting this. I wish I had looked sooner.

I’m bringing this up from an exceptionally small thing I noticed while at work today. As I have previously stated, I work with SharePoint. Much of the time I am branding it (though not in my current project!) and so I have a rather intimate and abusive relationship with the program. I find myself constantly finding weird styling quirks put into the environment that prove that SharePoint was built by a large group of people.

There are many instances within SharePoint – and I’m sure within WSS as well – where certain styles that should be consistent end up being done completely different ways. I wish I had a screen shot as an example, but you’ll have to use your imagination here. Picture two dropdown buttons. When you hover over them, they glow, and a menu appears. No picture the HTML for both dropdown buttons being completely different, with no shared styles or markup whatsoever.

This happens all over the place. Hell, there is markup all over the place that is either broken, non-standard (don’t get me started on WSS/SharePoint and it’s default markup) and over 6 thousand lines of styles if you add up all the sheets. 6 thousand! There is no need for that, and yet it exists because of – say it with me now – the lack of consistency.This lack of consistency then cascades down to people like me, who are stuck styling the damned things. Had there been a discussion between the differing groups, or the markup left to a third group so that they could all be structured the same way other peoples lives would then be made easier.

Another example I can bring up is with code. My code, my co-workers code, random interweb code, it happens everywhere. It is far more frequent when you work on rapid products, or many projects that build off of their predecessor. I can speak from experience that unless you code with the future in mind you will end up patching things… usually more than once.

In a perfect world you’d be able to properly scope your work out, develop your use cases, figure out your flow, and develop in a modular, expandable way. This of course requires a couple things: Time, patience, and knowledge. I can assure you that even if you think you have all three you don’t. The only time this can ever happen is when you are developing something for yourself and even then more often than not you’re just throwing something together for your own use, and those tend to be the worst for patch jobs… at least from my experience.

In the end all I can say is plan things out. Figure out a system and stick to it; even if it’s not the best it will at least not be the best everywhere. This makes it much easier to upgrade/fix later on. If you come up with 5 different solutions for 5 different things when they could all share common attributes, you are just making more work for yourself.

Save your time, your brain, and your fellow workers from the agony of added work brought about by inconsistency. Get a game plan, stick with it, and for the love of god: be consistent.

P.S. I managed to spell consistency wrong every time in this post while writing it.

P.P.S. Except for the one in the first postscript.

Update:

Success! I have a screen shot of the dropdown menus in question!
(Technically this update happened before the post went public, but whatever)

Fast forward to my current job. I can assure you that there are a plethora of examples that I could choose from for the point I will be making here, but one strikes me as perfect. You see when we developers started there things were volatile, unstructured, and pretty much a mess. My now fellow programmers and myself were hired in the wake of a collection of other developers leaving for one reason or another. We were also thrust into a project pretty much from the moment we sat in our chairs.

This was all fine and good, and we build what we thought we were supposed to build. Three days before we showed it to the client, we went through a run-through with the manager, only to find out that what we built was not what the client wanted. Well okay parts of it were, but for the most part it was off the mark. The result was months of us working grueling hours of overtime, wherein time became an abstract concept and my world knew nothing but code.

What the hell happened?

We didn’t have a process.

We built what we were told to build at the start, but things changed. The functional spec. was updated and we were never told. On the flip side, we also never went looking. Communication was sub-par at best, and the short of it is that there was enough blame for everyone.

We thought we had a process, but the debacle that we ran headlong into demonstrated that whatever process was in place either wasn’t working or was never initiated. The result was everything blowing up in our face. As it turns out, if you do not learn from this mistake, it will happen again and again. I could pull from more examples, but I’ll refrain… sort of.

I am on a new project, in fact I am the lead developer of said project. It’s my first time doing this and I’ll admit that it is a daunting task, but I set about doing my best. I was given a functional specification, which I thought odd because I’m pretty sure I’m the one that’s supposed to build that. I was told to add my section to it and that was that. I did so, to the best of my ability, with the information I had available to me.

It was okayed, and I started handing out tasks and the development cycle began.

Then I was told that the way things were supposed to work wouldn’t work that way anymore. This was after we had built stuff. This is generally a bad design move, because now any development that was already done now has to be reviewed and possibly scrapped. I updated the spec. again, and away we went. Then I realized that something wasn’t covered with the information I was given, so I asked a question. One question, I swear to God I only asked one but what was the end result? Another overhaul. Another attempt at the functional spec.

This has happened a couple times, and is not how the process should work. In a perfect world, the functional spec. is completely done before a line of code is written. The world is not perfect of course, and we have to make do with what we got, but damnit, I wasn’t about to go and take another stab at anything only to have it change on me again. So I went back to my college roots, and I made a decision:

I will make the process work again.

How can I do that though, when everything has apparently been thrown to the wind? It’s easier than I thought… well sort of. It still requires effort, but I’d rather expend the effort where I did fixing the process then rebuilding anything three times.

I sat down with my other main developer, and we went through everything. We went through every aspect of the functional spec, screen designs, and data sources, and figured out how it all works. We asked all the ‘hows’ and ‘what ifs’ as well as all of the ‘what the hells’ that subsequently came up. We went through every resource, created or not, and decided what was needed, what information had to be stored, etc.. We created use cases for the complex cases, and walked through more processes then I would care to count.

The end result? I spent ten hours (minimum) in a board room with a print-enabled white board and wrote everything down. I’m pretty sure we have at least 15 printouts of notes and questions and diagrams and use cases which helped clear up the utter ambiguity that surrounded the project. They get it now, and so do I. It’s no longer a matter of “how does this work?” but a matter of “what’s the next task?” Yes I have to update the functional spec. again, but at least now I know what to add, and where. The document is finally useful, and the project is understood. The process exists once again.

I’ve also taken it upon myself to write all of those tasks down in a shared location, so that whoever is on the project can take on new tasks as the run out of their assigned ones. That way no one has the excuse for not knowing what is next.

So yes we lost a day of development, but we have saved ourselves days of effort of unneeded rebuild time. Do it right the first time, and you’ll save time later.

On a side note, Sorry Mr. Miller turns out you were write all along about Analysis. My Bad.

Now granted, you can tell your website to stay on the cutting edge of IE rendering by using the “edge” keyword (see what I did there?) in your meta-tag . This will allow your website to be rendered at whatever the end users version of IE is. I like the idea of targeting a website to certain browsers, especially when you work in a web development position where part of the statement of work is a section dedicated to what browsers your work has to run in. This sort of idea makes my job as a website stylist that much easier. Unfortunately, I am opposed to the idea in the end.

The problem lays not in the fact that you can target browser version, it’s the fact that it’s gotten to this point. It’s a depressing thing to think about really; had Microsoft just done things right the first time (or at the very least come out with hot fixes to make the needed changes) we wouldn’t be in this mess to begin with. People are always complaining about IE, more so since browsers like Firefox have stepped into the ring. I’m aware that Firefox is not perfect, but that’s not what I’m arguing. Firefox, along with the other browsers, took far more time to correct CSS bugs than IE ever did. Only now with the eventual release of IE 8 are we looking at IE possibly coming up par.

I don’t work on the team, and I’m truly glad I don’t. These guys are basically the internet pariah group of the century. Everyone can hate IE with little to no effort due to its historic record of screwing up websites. I’m glad to see that they’re working so hard to get the browser up to speed on the compliance front, as well as trying to make it easier for everyone. Sadly, by making it easier for everyone they really hurt further progression in the field.

Allowing HTML writers to slap a version on their site and let it be that, you stifle the drive to improve their craft. You allow the user to literally say “good ’nuff” to their work, and since the Web isn’t going away anytime soon, I shudder to think of what will become of the next generation of web designers. It’s going to be the Geocities site builder circa 1997 all over again.

I guess it would at least look the same in every browser, so that’s something. In the end I’m against the idea from a progression standpoint, but I have to admit – if not begrudgingly – that at least this would stop sites from breaking every release. It’s gross, but it’d work.

P.S. This is the greatest summary of the issue, bar none.

Most people have no problem with following these rules, though I will say that my address will forever be 123 Fake St. unless something is getting shipped to me. The problem is not in the rules but in their explanation to us.

Sometimes websites are very clear about what they want by specifying it in clear, concise language: “Username must be between 5 and 11 characters and contain at least 1 number” or “Postal Code example: A1B 2C3“. This is a good practice because assuming your users are idiots will ironically result in a much lower screwup rate.

The point I’m getting to here is when you don’t state you’re rules, your users will default to basic behavior. Most people don’t know that usernames tend to have numbers in them now, and I’m sure even less know that because of your half-assed attempt at regex the postal code needs to be in capitals.

What does this mean? Well depending on how you set up the form users may be forced to fill it all out again. This is a pain in the ass to start, and when you throw in the fact that many websites do not include detailed error messages (error summaries people, error summaries) the users may -and in my case will- be forced to fill out the same form multiple times.

This is an example of CUE. Lazy programmers and lazy testing tend to be the main cause of form-based issues. I know this because I was a lazy programmer who submitted his stuff to a very thorough quality assurance person. He turned around and ripped my form apart. I learned quickly that by putting forth the additional effort into planning it all out and doing the job right, that two things would happen: the first thing is that I’d have less work coming back from the QA guys. The second was that I realized I was creating the same thing that annoyed me so often on the web. I’m a reformed man as a result.

What I’m trying to get at is that when you’re building something, no matter what it is, try and look at it from the end-users stand point. This can be a difficult task at time and believe me when I say that it takes some practice. You have to figure how users can screw things up that you find straight-forward and fix said things.

Once you know how they can screw them up, save yourself some time and tell them how not to screw them up. As long as you stop their input from decimating your server (sanitize your inputs, people) you can make your life easier by telling the user how to do things the right way.

That’s not lazy, that’s empowering.

Another step is to make sure that when they do screw up (which they will) make sure you tell them what they actually did wrong. DHTML and AJAX controls depending on your validation requirements, can be fantastic ways to validate on the fly… assuming you don’t make your error messages jarring (i.e. javascript popup messages are bad, don’t do them) or elusive (top of the page? I’m 15 inches down the form, I’m not going to see that) or cryptic “An error occurred.”

Once again, ask yourself what you would expect the user to see when they go through it. Do you really think big JavaScript popups are the best way to tell the user that their postal code can’t have spaces? Probably not, but I’m sure it made sense at the time.

I know I’m using submission forms heavily as my example here, but the idea is still the same. Once you’re done building your whateveritis, try it out yourself. Try drawing up some use-cases get some friends or colleagues to try it out. Pretend you’re a blathering idiot, and see how well you do then. Hell, find a blathering idiot and point him in your whatchimacallits direction. Do whatever you have to to get the sense of the users process. Find the problem areas with your thingimajigs before they become the bane of every end-users (which in turn will become the bane of your) life.

Don’t be lazy, and do it right the first time people.