SQL Server, performance, data, analytics
admin Bob Beauchemin‘s SQL Server 2005 Security Best Practices – Operational and Administrative Tasks whitepaper is up on the Technet website:
“This white paper covers some of the operational and administrative tasks
associated with SQL Server 2005 security and enumerates best practices and
operational and administrative tasks that will result in a more secure SQL
Server system. Each topic describes a feature and best practices.”
Over at Red Gate’s Simple-Talk blog, Robyn Page and ‘Phil Factor’ have a nice article on using a helper table of numbers to convert some common T-SQL iterative tasks to set-based operations:
Rob Farley is a bit of a demon with a table of numbers; I wonder if knows any more of these? Rob?
Ken Getz is no slouch when it comes to coding. The “Access Developers Handbook” series by Litwin/Getz/Gilbert was a classic. Few books covered the material so well or as comprehensively. I just pulled my Access 97 version down from the bookshelf. Ah, Access we had some good times! Right, that’s enough reminiscing!
It’s therefore reassuring to discover that developers of Ken’s stature occasionally make the same kinds of mistakes as the rest of us! As testament to the fact that the .NET framework is, in the words of Michael Palin as the chaplain in ‘Monty Python’s The Meaning of Life’, “…so very, very Huge! ..”, Ken posted this article.
Ken’s advice is worth heeding:
“A word to the wise: If you find yourself writing .NET code which seems like it
sure as heck ought to have been included in the Framework, take a few seconds
and try to convince yourself that it’s not.”
Do you test your applications for SQL injection vulnerabilities? I came across a nice round-up of possible attacks here: SQL Injection Cheat Sheet It has a nice reference section.
About a year and half ago, I was going to submit some of my photographs to a stock library based in Queensland, Australia, and on a whim I decided to try a very basic SQL injection to see how secure this site would be with my financial details. It didn’t pass! I contacted the owner/maintainer and told him about the problem. One year later, I checked back to see if it had been fixed. It had not. Needless to say, I don’t list any photos with them!
NDepend is a static code analysis tool that can provide you with some surprising insights into your code. Scott Hanselmann did a podcast and blogged about this tool recently, and when Scott waxes lyrical about something I sit up and take note. I played around with tool in its earlier incarnation some time ago, but didn’t fully ‘grok’ it, as I didn’t persevere over the 15 – 30 minutes ‘hump’ with the excellent tutorials (it’s only 5 – 10 minutes for Scott, apparently. Damn those Hanselmann clones!) It complements FxCop’s functionality and it can be similarly incorporated into your automated build process. Don’t take my word for it, go and download the free trial version and work through all 6 tutorials at least twice.
So what can NDepend be used for? Getting familiar with an existing, large codebase, gathering all kinds of metrics with a view to refactoring and improving existing code.
It can give you the 100ft view of a large and complex code base, but at the same time allows you to analyse and pinpoint a problem and then drill-down right to the code. If I remember correctly, I think Scott said it was Reflector on Steroids, but then so much more! It uses some pretty clever visualization techniques to convey code metric information.
I’m going to blog about NDepend2 in a bit more detail presently. In fact, I’m thinking it would make a great .NET User Group session…
Practical .NET2 and C#2 by Patrick Smacchia
Just read “//TODO: Uncomment Later” over at the newly renamed “DailyWTF” (it’s now called Worse Than Failure, and while I understand Alex’s motivation for the name change, I think the original was better…) . It got me thinking; as part of the build process, do you have a task that checks for any TODO comments? (You do use TODO comments, right?) In addition, check out the comments to that post: I love the wolves story, classic!
That post got me thinking, as part of the TODO comment checking task we should also check for commented out code lines. I deplore seeing commented out code that developers have left in the codebase; it’s a warning sign that something smells. That’s what Source Control is for! The only time leaving commented out code is acceptable is to indicate that it shouldn’t be done that way WITH an associated clear and explanatory comment.
When I program against the .NET Framework, I’m happy swapping between C# and VB.NET, although I must confess a preference for C#, having spent many years programming in C. It occurred to me that it would be slightly easier to check for commented out code (without using System.CodeDom) by checking for lines that contain “\\” and “;” or “{” or “}”. OK, it might match a few false positives. What are your thoughts on this?…
J.D. Meier has a nice post up on how to structure projects for Team Foundation Server here. He’s also asking for real world practices you use on your project as feedback to incorporate into the patterns and practices guidance.
I’ve recently been reading “The Wisdom of Crowds” by James Surowiecki. It’s a well written, easy to read, intriguing and thought provoking book. It doesn’t contain any heavy mathematics; in fact it contains no mathematics at all, so should be accessible to the widest audience. I would definitely recommended reading this book.
The ‘wisdom of crowds’ refers to collective intelligence, namely how it is possible for a crowd to pick a solution which is better than a corresponding one made by an expert: “when our imperfect judgments are aggregated in the right way, our collective intelligence is often excellent”.
The wide variety of complex problems upon which collective intelligence can be brought to bear, is broken into 3 problem groups: cognition, coordination and cooperation. Cognition problems are defined as those that have or will have a definite solution, such as “Where would be the best place to build this new road?”. Coordination problems require members of a group to determine how to coordinate their behavior with each other, such as buyers and sellers trading at a fair price. Cooperation problems involve getting self-interested, possibly distrustful people to work together, even when self-interest would seem to imply no benefit from taking part, such as paying taxes.
One of the key concepts discussed is the ‘Information Cascade’, a situation where people make a decision based more on the decisions being made around them rather on their own private information, the outcome of which is not always beneficial. I loved the story of one such example, plank-road fever (pg 51)!
[The human brain can be viewed as a crowd; perhaps that’s why when you become expert in a particular field, you can become better still by learning about other fields. Diverse perspectives are more likely to come up with something new, but I digress…]
I came across an example of an information cascade that centers on the humble screw in 1860s America, which was vaguely reminiscent of the ongoing changes we have seen in software development over the last 30 – 40 years. Back in the 1860s, when the machine-tool industry was a rough analogy to the technology industry in the 1990s, screws were individually hand-made by machinists. In the absence of national or industry standards, when a nut or bolt was damaged or lost, either a new one would have to be hand crafted or a replacement sent for from the original builder. This obviously severely limited the possibility of mass-production, and as James notes, it also enabled individual machinists to protect their way of life. As a customer, if you have a reliance on something that is custom made, then you are locked in to that supplier. Here’s the line that resonated with me in terms of the software development industry: “But if the screws became interchangeable, customers would need the craftsman less and would worry about the price more”.
William Sellers, a respected machinist of his era, believed that mass production was inevitable. Over a period of approximately 6 years he designed and promoted a standardized screw that was easier, faster and cheaper to produce than any other. Each new customer he secured meant it more likely that others would follow suite, based on the experience of the predecessors.
James sums up an information cascade as follows: “In a cascade, people’s decisions are not made independently, but are profoundly influenced – in some cases, even determined – by those around them.”
Several months ago, a colleague was editing a file in Visual Studio 2003 and said “…it would be great if you could select a block of text by columns…”. He was therefore a little surprised when I mentioned that you have been able to do this since around version 4 of what was then called Visual C++! If you hold down the ALT key whilst right-click dragging a selection you can select a rectangular block of text. (Ok, I know most people will already know this, but just in case…)