I've mentioned my concerns about LINQ before, and I think this article sums them up perfectly.
My argument is just that we have built in 'good' coding practises, separating things my layers and tiers of logical and physical form, only to come full-circle and now seem to be encouraged to put psuedo-SQL in-line with our code.
Haven't been around recently, for which I apologise.
However, an article on C|NET caught my eye this morning.
While the keyboard and mouse are the ubiqutous devices to perform the input side of computing, many people can't use these due to their disability such as motor problems or sight problems.
Web pages can be designed to allow users using their fingers, or their breath or tongue to interact with a site and get out what any normally-able person is able to. (But then again, I have seen sites that challenge even the able-bodied to get a decent experience from).
View some pictures of alternative input devices at C|Net here: http://beta.news.com.com/2300-1041_3-5886247-1.html
The story related to the pictures are here: http://beta.news.com.com/Devices+help+the+blind+cross+tech+divide/2100-1041_3-5888810.html
Where we should focus our efforts in terms of capturing input
As developers, we need to do nothing complex to accommodate this section of society. A sensible, consistent approach is all that is needed, with a mind to providing alternatives should a particular section of a page be complex.
Consider navigating around a single page. Most people use the PageUp/PageDown keys to scroll up and down a page, and this should be equally the case for disabled users. Therefore, your content should be flowing in a straight manner, and not flowing around objets - remember we are designing web pages, not publications in a DTP suite.
Selecting links and form elements can be made drastically easier by using three simple tags.
<a href="index.htm" title="Index Page" />
Placing a title on your links helps users navigate by the title of the link, rather than the position of the link in the page. It is important to realise that while your output ultimately defines how your input is received, your output may change significantly in downlevel and accessible browsers. Some browsers actively trawl pages for links with titles and provide them as an additional index for users to navigate to pages.
While we're on this, it is important to avoid using the "Click here" text within a link. This provides no information to anybody. If a title attribute has not been added, then the browser or the user will then think about what is inside the anchor tags. This is not always a successful strategy because the text inside the anchor is often unreleated, useless or for output only - such as an image.
<a href="index.htm" accesskey="1" />
Most sites have a consistent set of "top-level" links, which indicate the various sections of the site. The accesskey attribute allows a key to be added to a link or form element that allows for faster navigation around a site. Take this blogging site, the main links "Home", "Blogs", "Photos" and "Settings" could easily have access keys assigned to them. eg. 1,2,3,4. This will allow people to use the Ctrl or Alt key along with the access key to navigate and activate the link or form element immediately.
I will discuss forms even more at a later time, with an example.
<input type="text" tabindex="1">
We're used to the TAB key cycling through controls in Windows apps, and I'm sure we all know the TAB key can do similar things on a web page - but mostly with unpredictable results. Taking the time to add this tabindex attribute to a logical order is worth the effort to us all. Obviously, we test our sites to destruction, and I'm sure we all resort to using the TAB key to run through our form controls quickly. It is no different for the disabled. Without a mouse, web pages are often impossible to use. Remember, a mouse is actually quite a difficult device to use. It requires sight and motor dexterity - along with the ability to correlate the movement in a horizontal plane to that in a vertical plane.