While working on my current project I decided that I had a need to use the Specification Pattern . After finding a clean implementation by Jeff Perrin I set to work creating the specifications that I needed. I quickly realized that we were going to end up having a ton of specifications and sometimes they would only apply to very special cases. Other times they would be very broad cases and they needed to be even more composable than even the fluid interface implemented in Jeff’s implementation wasn’t going to be enough. It after all still required me to create a concrete implementation for each specification, no matter how minuscule it might be.

This is the part where I thought to my self that since i was really only creating implementations for a single method that I could just write a LambdaSpecification and be able to use this for all the special cases I had.

Below is the LambdaSpecification Code:


using System;
using System.Linq.Expressions;

namespace Specification
{
    public class LambdaSpecification<T> : Specification<T>
    {
        private Func<T,bool> _expression;

        public LambdaSpecification(Func<T,bool> expression)
        {
             if(expression ==null) throw new ArgumentNullException(”expression”);
              _expression = expression;
        }

        public override bool IsSatisfiedBy(T obj)
        {
            return _expression(obj);
        }
    }
}

And the Tests:


[Test]
public void LambdaSpecification_CanExecuteSimpleLambda()
{
    var p = new Person() {Name = “Eric”};
    var spec = new LambdaSpecification<Person>(x => x.Name == “Eric”);

        Assert.IsTrue(spec.IsSatisfiedBy(p));
}

[Test]
public void LambdaSpecification_CanExecuteComplexLambda()
{
    var p = new Person() {Name = “Eric”, Age = 28};
    var spec = new LambdaSpecification<Person>(x => x.Name == “Eric” &&
                                                                        new IsLegalDrinkingAgeSpecification().IsSatisfiedBy(x));

    Assert.IsTrue(spec.IsSatisfiedBy(p));
}

//Might Not be needed but I wanted to be sure
[Test]
public void LambdaSpecification_CanExecuteLambda_AndUseAndSpecification()
{
    var p = new Person() {Name = “Eric”, Age = 28};
    var spec = new LambdaSpecification<Person>(x => x.Name == “Eric” );

    Assert.IsTrue(spec.And(new IsLegalDrinkingAgeSpecification()).IsSatisfiedBy(p));
}

Comments are welcome and encouraged, especially if you see a reason why I shouldn’t be doing this. Or, if you have any ways to make this better, I would love to hear them. This is the first time I have ever used a lambda as a parameter in my own code and so far i am liking it.

Thanks to Jeff Perrin again for his post on creating a clean implementation of the specification pattern.

Just like its predecessor, SQL Server 2008 is taking its sweet time to actually ship.  However, unlike its predecessor, it won't just be a "worthwhile upgrade".  It will kick ass.

Here are the top 10 reasons why.

10.  Plug-in model for SSMS.   SSMS 2005 also had a plug-in model, but it was not published, so the few developers that braved that environment were flying blind.  Apparently for 2008, the plug-in model will be published and a thousand add-ins will bloom. 

9.  Inline variable assignment.  I often wondered why, as a language, SQL languishes behind the times.  I mean, it has barely any modern syntactic sugar.  Well, in this version, they are at least scratching the the tip of the iceberg. 

Instead of:

DECLARE @myVar int
SET @myVar = 5

you can do it in one line:

DECLARE @myVar int = 5

Sweet.

8.  C like math syntax.  SET @i += 5.  Enough said.  They finally let a C# developer on the SQL team. 

7.  Auditing.  It's a 10 dollar word for storing changes to your data for later review, debugging or in response to regulatory laws.  It's a thankless and a mundane task and no one is ever excited by the prospect of writing triggers to handle it.  SQL Server 2008 introduces automatic auditing, so we can now check one thing off our to do list.

6.  Compression.  You may think that this feature is a waste of time, but it's not what it sounds like.  The release will offer row-level and page-level compression.  The compression mostly takes place on the metadata.  For instance, page compression will store common data for affected rows in a single place. 

The metadata storage for variable length fields is going to be completely crazy: they are pushing things into bits (instead of bytes).  For instance, length of the varchar will be stored in 3 bits. 

Anyway, I don't really care about space savings - storage is cheap.  What I do care about is that the feature promised (key word here "promises") to reduce I/O and RAM utilization, while increasing CPU utilization.  Every single performance problem I ever dealt with had to do with I/O overloading.  Will see how this plays out.  I am skeptical until I see some real world production benchmarks.

5.  Filtered Indexes.  This is another feature that sounds great - will have to see how it plays out.  Anyway, it allows you to create an index while specifying what rows are not to be in the index.  For example, index all rows where Status != null.  Theoretically, it'll get rid of all the dead weight in the index, allowing for faster queries. 

4.  Resource governor.  All I can say is FINALLY.  Sybase has had it since version 12 (that's last millennium, people).  Basically it allows the DBA to specify how much resources (e.g. CPU/RAM) each user is entitled to.  At the very least, it'll prevent people, with sparse SQL knowledge from shooting off a query with a Cartesian product and bringing down the box.

Actually Sybase is still ahead of MS on this feature.  Its ASE server allows you to prioritize one user over another - a feature that I found immensely useful.

3.  Plan freezing.  This is a solution to my personal pet peeve. Sometimes SQL Server decides to change its plan on you (in response to data changes, etc...).  If you've achieved your optimal query plan, now you can stick with it.  Yeah, I know, hints are evil, but there are situations when you want to take a hammer to SQL Server - well, this is the chill pill.

2.  Processing of delimited strings.   This is awesome and I could have used this feature...well, always.  Currently, we pass in delimited strings in the following manner:

exec sp_MySproc 'murphy,35;galen,31;samuels,27;colton,42'

Then the stored proc needs to parse the string into a usable form - a mindless task.

In 2008, Microsoft introduced Table Value Parameters (TVP). 

CREATE TYPE PeepsType AS TABLE (Name varchar(20), Age int)
DECLARE @myPeeps PeepsType
INSERT @myPeeps SELECT 'murphy', 35
INSERT @myPeeps SELECT 'galen', 31
INSERT @myPeeps SELECT 'samuels', 27
INSERT @myPeeps SELECT 'colton', 42

exec sp_MySproc2 @myPeeps

And the sproc would look like this:

CREATE PROCEDURE sp_MySproc2(@myPeeps PeepsType READONLY) ...

The advantage here is that you can treat the Table Type as a regular table, use it in joins, etc.  Say goodbye to all those string parsing routines.

1. Intellisense in the SQL Server Management Studio (SSMS).  This has been previously possible in SQL Server 2000 and 2005 with use of 3rd party add-ins like SQL Prompt ($195).  But these tools are a horrible hack at best (e.g. they hook into the editor window and try to interpret what the application is doing). 

Built-in intellisense is huge - it means new people can easily learn the database schema as they go.

There are a ton of other great features - most of them small, but hugely useful.  There is a lot of polishing all over the place, like server resource monitoring right in SSMS, a la Vista. 

I'd love to finish this entry on a happy note, but I can't, because I just finished perusing Editions of SQL Server 2008 page.  In addition to the Standard, Enterprise, Developer and Express editions, there are now Workgroup, Web, Compact (which has nothing to do with SQL Server) and Express Advanced editions.  Here is the comparison matrix.  And you thought picking a version of Vista was complicated.

You have only $50 left and you can buy two DVDs or one SQL book, what do you do? I would buy the book but not every person has the same idea of a fun time. This is the reason why I present you with a bunch of links to articles which will give you very good info. some of this you won’t be able to find in a book anyway.

The curse and blessings of dynamic SQL. How you use dynamic SQL, when you should - and when you should not.

Arrays and Lists in SQL Server. Several methods on how to pass an array of values from a client to SQL Server, and performance data about the methods. Two versions are available, one for SQL 2005 and one for SQL 2000 and earlier.

Implementing Error Handling with Stored Procedures and Error Handling in SQL Server – a Background. Two articles on error handling in SQL Server.

The ultimate guide to the datetime datatypes
The purpose of this article is to explain how the datetime datatypes work in SQL Server, including common pitfalls and general recommendations.

Stored procedure recompiles and SET options
Using stored procedures is generally considered a good thing. One advantage of stored procedures is that they are precompiled. This means that at execution time, SQL Server will fetch the precompiled procedure plan from cache memory (if exists) and execute it. This is generally faster than optimizing and compiling the code for each execution. However, under some circumstances, a procedure needs to be recompiled during execution.

Do You Know How Between Works With Dates?
article explaining why it can be dangerous to use between with datetime data types

How Are Dates Stored Internally In SQL Server?
Article explaining how datetimes are actually stored internally

Three part deadlock troubleshooting post, a must read if you want to understand how to resolve deadlocks.
Deadlock Troubleshooting, Part 1
Deadlock Troubleshooting, Part 2
Deadlock Troubleshooting, Part 3

SQL Server 2005 Whitepapers List
A list of 29 different SQL Server 2005 Whitepapers

Keep a check on your IDENTITY columns in SQL ServerThis article shows you how to keep an eye on your IDENTITY columns and find out before they run out of values, and fail with an arithmetic overflow error.

Character replacements in T-SQL
Quite often SQL programmers are left with the dirty job of working with badly formatted strings mostly generated from external sources. Typical examples are badly structured date values, social security numbers with misplaced hyphens, badly formatted phone numbers etc. When the data set if small, in many cases, one can easily fix by a one time cleanup code snippet, but for larger sets one will need more generalized routines.

We’re very excited to announce our 2^nd Community Technology Preview (CTP) for Parallel Extensions to the .NET Framework 3.5.  We released the Dec07 CTP on 11/29/2007, and from that we have received a lot of feedback from the community and customers. While you have been using our bits, participating in our forums, sharing your insights and experiences, and following along on our blog, we have been hard at work preparing this CTP, incorporating your feedback into it.

Download the Parallel Extensions June 08 CTP

There are some large changes in there that should provide a lot of benefits.  First off, we have begun to add the third major API component, the Coordination Data Structures, to the technology package.  As we build PLINQ and the Task Parallel Library, we use a lot of components under the covers to handle synchronization, coordination, and scale to contain data reads and writes from multiple procs.  We see these as widely useful, so we’re sharing them here with you.

We incorporated a brand-new user-mode, work-stealing, run-time scheduler (those modifiers essentially mean that it’s light, fast, and flexible) to the system, completely over-hauling the infrastructure.  This is a very important piece of technology for making the most of the resources available on your machines.  This has been in research and incubation for a long time, and it will allow for improved performance and future-proof scalability (e.g. cache consciousness) as we stabilize and improve it.  Expect to hear us talk a lot more about this in the future.  There are still likely to be some growing pains in this release, so please pass along that feedback and expect this to improve.  Additionally, The Task Parallel Library is now built directly on top of this scheduler.  And to add to the excitement, PLINQ is in the first stages of building on top of the Task Parallel Library. 

There are a number of other changes that we have made, some notables include: new ordering implementation for PLINQ, change of Parallel.Do to Parallel.Invoke, continuations in Tasks.  A much more detailed list of updates is coming soon.

Subscribe to the feed or come back to this blog often as we release a flurry of posts regarding the new and exciting work surrounding this CTP.

It isn't as big of a deal at the moment, but it is always good to make sure everyone is aware of this and how dangerous it can be.  There is some very good information on it located on MSDN here.  The important part is to remember that anytime you take input from an external source (someone typing on a web page), they don't always have to put in what you expect.

The safest way to keep yourself safe from SQL Injection is to always use stored procedures to accept input from user-input variables.  It is really simple to do this, for example, this is how you don't want to code things:

var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity + "'";

This allows someone to use SQL Injection to gain access to your database.  For example, imagine if someone put in the following for the "ShipCity":

Redmond'; drop table OrdersTable-- This would delete the entire table!  If you have seen much on SQL Injection, they have figured out all kinds of ways to get information about your database or server, so don't think they can't find the names of tables, etc.

The correct way to do this would be using a stored procedure as follows:

SqlDataAdapter myCommand = new SqlDataAdapter("AuthorLogin", conn);
myCommand.SelectCommand.CommandType = CommandType.StoredProcedure;
SqlParameter parm = myCommand.SelectCommand.Parameters.Add("@au_id",
     SqlDbType.VarChar, 11);
parm.Value = Login.Text;

Then you will be protected.  Be sure to use parameterized stored procedures to keep the stored procedure from having the same problem as before.|

There are other hints and advice on the MSDN article that you can check out, but this is the major piece of advice to know.

There is also some additional information that you can find here.  You can find more information and a video at Explained – SQL Injection and another video about it here.  There are tons of links on the web so feel free to research this more to be sure you are safe from this problem.

Recently, a user group held a conference whose subject was Domain-Driven Design with nHibernate. Now, this is a really cool topic of discussion! So, I decided to attend the conference in order to improve my perspective and knowledge on the subject. Little did I know that the speaker was an introverted programmer who greatly lacked in public speaking skills. Many people, including myself, left early, as the presentation became unbearably tedious and awkward.

What follows is a list of tips which I feel to be important when it comes to giving a presentation. This is not an exhaustive list, so I hope you would add your own comments to elaborate on these ideas or to add to the list. [I am also looking to improve my communication and presentation skills, so these rules and principles also apply to me].

Tip #1: Introduce yourself properly

When I was a kid and people asked me what my name was, I used to reply “My name is Brian…don’t you know that?” You see, back then, I thought everybody knew my name: it’s a common name, it’s easy to remember and it’s simple to pronounce. However, in reality, this is not usually the case. Therefore, before beginning a presentation, introduce yourself to your audience. What is your name? What do you do for a living? Why do you want to talk to us about your subject? How can we contact you? Do you have a Web site or a blog?

Tip #2: Make eye contact

Bear in mind that the audience came to see YOU. Therefore, you should be mindful of the fact that we have decided to take time out of OUR day to see YOU, when we could be somewhere else (at home, a friend’s party, a late night dinner, etc.) That being said, PLEASE acknowledge this fact by at least looking at your audience. Don’t stare at the ceiling, the floor or the walls. Don’t stare at your PowerPoint slides either. I think it costs about two calories to move your eyes from one direction to another at variable intervals. In other words: it doesn’t hurt and it doesn’t take a lot of energy to do that. I know some developers are very introverted, and that is in their nature, but would you ask someone out on a date while staring at the wall or the ceiling instead of looking into his/her eyes? This takes practice, but the resulting impact on your audience is well worth the effort!

Tip #3: Talk with a smile

Do you know that the human being is the only living being in Earth that can smile to express different emotions? There are hundreds of muscles and nerves that are being contracted when you smile. Yet it doesn’t hurt. In fact, smiling at an audience changes the atmosphere and the ambience of the room to make it more natural, more humanized and more comfortable. Again, would you ask someone on a date without smiling? I don’t think so.

Tip #4: Move around a little

Just like a shark cannot stay alive without swimming around, so should you be moving and walking around a little on the platform. That platform is yours and you should feel free to walk on it so the whole audience can have a chance to feel your presence and to see you. Don’t stay near the computer just because you want to be there for clicking that button to go to the next slide. The computer is just a tool, not an altar.

Tip #5: Carefully prepare your presentation

Take the necessary time and resources to prepare your material: watch out for grammatical errors which can compromise your credibility, don’t go overboard with the information for a slide. Just like a good class design, your slide should be highly cohesive. What is your intent for a given timeframe? That answer should be reflected on your slide. I personally don’t care much for PowerPoint slides as a participant. What you’re telling me should be enough to understand your intent. I’ll look at your slide to complement your vision or your intent, not to get a second understanding of what you just said. Another thing you can do is to make your PowerPoint presentation available to everyone or by request. That way, the audience can focus on you in a more relaxing manner because they know that your presentation is there for them to look at anytime.

Tip #6: Anticipate obvious questions that could arise and prepare your answers

If your audience is at all interested in your subject, be sure that some people will ask you questions about it. For this, I like to imagine myself as part of the audience and see another projection of myself giving a talk. What kind of question could I ask the speaker right about now? Maybe something I said wasn’t clear or needed an example to better complete the picture. For some abstract or complex subjects, you can try answering some questions related to the 5Ws (Who? What? Where? When? Why? How?). You can also ask a friend what he thinks about your material. Prior feedback is always a good thing!

Tip #7: It’s okay to admit that you don’t know it all (However, do not use this as an excuse to come unprepared!)

This one is simple, but very hard to act on. If you are asked a question which you are unable to answer, just say these three little words: I don’t know. It doesn’t mean that you are completely ignorant. It just means that you don’t know. Even the greatest world leaders don’t have all the answers…no one does! Don’t sacrifice your credibility and your professionalism by risking an incorrect answer or solution. I remember someone once told me “Brian, it is better to remain silent and thought a fool, than to open your mouth and remove all doubt.”

Tip #8: Have a plan B in case something goes wrong

Over the years, I have come to realize that Murphy’s Law is true and no one is safe from it. Not even developers. The law states that whatever can go wrong will go wrong. Therefore, prepare a second plan (or more!) in case things don’t go as planned. For example, if you’re modifying code in front of your audience and your system crashes, you shouldn’t take time out of your presentation to fix the problem. You will lose your audience!!! Just scrap the code and use the duplicate that you have as a backup.

There are many (free) resources online about how to improve presentation skills. I strongly suggest you to visit Kathy Sierra’s blog on human usability. It’s really worth it!

Over five years ago I posted Tips for a Successful MSFT Presentation. Yesterday I watched the video of my Mix Presentation all the way through. It's always very painful to hear one's own voice but it's even worse to watch yourself. I never listen to my podcast and I avoid watching myself. It's like watching a person in parallel universe and it inspires self-loathing. However, if you are someone who values continuous improvement - and I am - you need to do the uncomfortable.

Here's my five-years-later Updated Tips for a Successful Technical Presentation.

1. Have a Reset Strategy (One-Click)

If you're going to give a talk, you'll probably have to give it more than once. If you have demonstrations of any kind, have a "one-click" way to reset them. This might be a batch file or Powershell script that drops a modified database and reattaches a fresh one, or copies template files over ones you modify during your demo.

Personally, I'm sold on Virtual Machines. I have seven VMs on a small, fast portable USB drive that will let me do roughly 12 different presentations at the drop of a hat. You never know when you'll be called upon to give a demo. With a Virtual Machine I can turn on "Undo Disks" after I've prepared the talk, and my reset strategy is to just turn off the VM and select "Delete Changes." A little up-front preparation means one less thing for you to panic about the day of the talk.

2. Know Your Affectations (Ssssssseriously)

I have a bit of a lisp, it seems. I also hold my shoulders a little higher than is natural which causes my neck to tighten up. I also pick a different word, without realizing it, and overuse it in every talk. This is similar to how Microsoft Employees overuse the word "so" (which is actually Northwestern Americans, not MSFTies) too much.

It's important to know YOUR affectations so you can change them. They may be weakening your talk. Don't try to remember them all, though. Just pick two or three and focus on replacing them with something less detracting. Don't overanalyze or beat yourself up, though. I've spoken hundreds of times over the last 15 years and I'm always taking two-steps forward and one step back. The point is to try, not to succeed absolutely.

3. Know When To Move and When To Not Move (Red light!)

One of the most powerful tips I ever received was this: "When you move, they look at you. When you stop, they look at the screen." Use this to your advantage. Don't pace randomly, idley or unconsciously. Don't rock back and forth on your heels. Also, empty your pockets if you tend to fiddle with lose change or your keys.

4. For the Love of All That Is Holy, FONT SIZE, People (See that?)

It just tears me up. It physically makes me ill. To give a presentation and utter the words "um, you probably won't be able to see this" does everyone in the room a disservice.  Do NOT use the moment of the presentation as your time to do the font resizing.

Lucida Console, 14 to 18pt, Bold.  Consider this my gift to you.  This is the most readable, mono-spaced font out there.  Courier of any flavor or Arial (or any other proportionally spaced font) is NOT appropriate for code demonstrations, period, full stop.  Prepare your machine AHEAD OF TIME.  Nothing disrespects an audience like making them wait while you ask "Can you see this 8 point font? No? Oh, let me change it while you wait."  Setup every program you could possibly use, including all Command Prompt shortcuts, before you begin your presentation.  That includes VS.NET, Notepad, XMLSpy, and any others, including any small utilities.

I've found that the most readable setup for Command Prompts is a Black Background and with the Foreground Text set to Kermit Green (ala "Green Screen."  Yes, I was suspicious and disbelieving also, but believe it or not, it really works.)  I set Command Prompts to Lucida Console, 14 to 18pt, Bold as well, with much success.

Also, set the font size to LARGEST in Internet Explorer and remember that there are accessibility features in IE that allow you to include your own Large Font CSS file for those web pages that force a small font via CSS.

Learn how to use ZoomIt and practice before-hand. It can be an incredibly powerful tool for calling out sections of the screen and making it so even the folks way in the back can see what's going on.

For simplicities' sake, I like to keep a separate user around call "BigFonty" (choose your own name).  He's an Administrator on the local machine and he exists ONLY for the purposes of demonstrations.  All the fonts are large for all programs, large icons, great colors, etc.  It's the easiest way to set all these settings once and always have them easily available.

5. Speak their Language (Know the Audience)

When I was in Malaysia for TechEd, I spent 3 full days exclusively with locals before the talk, I learned snippets of each of the languages, tried to understand their jokes and get an idea about what was important to people in Malaysia.  American analogies, much humor, and certain "U.S. specific" English colloquialisms just didn't make any sense to them.  When it came time to give the presentations, I better understood the Malaysian sense of timing, of tone and timbre, and I began each of my presentations by speaking in Bahasa Malaysia.  I changed aspects of my slides to remove inappropriate content and add specific details that would be important to them.

I've used this same technique in a half-dozen countries with success. While this is an extreme example, the parallels with any audience are clear.  If you're speaking to a room full of IT guys who work in the Automotive field, or the Banking industry, the fact that we are all programmers only gives you a small degree of shared experience.  Remember no matter the technical topic, try to get into the mind of the audience and ask yourself, why are they here and what can I tell them that will not be a waste of their time.  What would YOU want to hear (and HOW would you like to hear it) if you were sitting there?

6. Be Utterly Prepared (No excuses)

Short of an unexpected BSOD (and even then, be ready) you should be prepared for ANYTHING.  You should know EVERY inch of your demos and EXACTLY what can go wrong.  Nothing kills your credibility more than an error that you DON'T understand.  Errors and screw-ups happen ALL the time in Presentations.  They can even INCREASE your credibility if you recover gracefully and EXPLAIN what happened.  "Ah, this is a common mistake that I've made, and here's what you should watch for."  Be prepared with phrases that will turn the unfortunate incident around and provide them useful information.

7. CONTENT, CONTENT, CONTENT (Have some)

Every move, phrase, mistake, anecdote and slide should actually contain content.  It should be meaningful.  Your mistakes should teach them, your demos should teach them; even your shortcut keys, utilities and menu layout should teach them.  A presentation isn't an opportunity to read your slides.  I'll say that again. Don't READ your slides. I can read faster than you can talk.

Remember that most people can read silently to themselves 5 to 10 times faster that you can read to them out loud.  Your job as a presenter is to read in between the lines, and provide them structure.  Your slides should be treated as your outline – they are structure, scaffolding, nothing more.  If you jam your slides full of details and dozens of bullets, you might as well take your content at write an article.  It's difficult to listen to someone talk and read their slides at the same time – remember that when you design your content. YOU are the content, and your slides are your Table of Contents.

8. System Setup (Be unique, but don't be nuts)

When you a presenting, remember that you are looked upon as an authority.  Basically, you are innocent until proven guilty.  It's great to have a personality and to be unique, but don't let your personal choice of editors or crazy color scheme obscure the good information you're presenting.  I appreciate that you may like to use VI or emacs to view text files, but let's just say that sometimes Notepad has a calming effect on the audience. 

I give Microsoft talks, usually, so I tend towards Visual Studio, but 99% of my talks use a limited number of tools. Basically Visual Studio, Notepad, the Command Prompt and a Browser.

Remember that while you may prefer things a certain way while your face is a foot away from the screen, it's very likely the wrong setup when 500 people are more than 100 feet away.

I really like to get Toolbars and things out of the way. I use F11 (Fullscreen) in the Browser a lot, as well as Visual Studio's Shift-Alt-Enter shortcut to FullScreen. Turn off unneeded flair and toolbars. Also, turn on line-numbering so you can refer to lines if you're presenting code.

9. Speaking (Um…)

"Volume and Diction," my High School Drama teacher said to me.  Speak clearly, authoritatively, project your voice to the back of the room.  The best speakers don't even need microphones.  If you have a speaking affectation (I had a lisp growing up) or you tend to say, um, etc, or find yourself overusing a specific phrase ("a priori", "fantastic", "powerful", etc) take it upon yourself to NOTICE this mannerism and avoid it.

Practice multi-tasking.  It seems silly to say, but although we can all multitask to a certain degree, when we hit a real snag in a presentation, many of us tend to freeze.  Silence is deadly.  Remember, since all eyes are on you, complete silence and apparent introspection says "I don't know know what I'm doing."  When you need to get to a particular file, don't make the audience wait for you while you putter through explorer.  Have shortcuts ready (and explain when you use them).  Move fast and efficiently, but annotate your actions.  You should continue to "color-commentate" your actions like a sports announcer.  Don't allow "dead-air," unless it's silence for effect.

10. Advancing Slides (No lasers!)

I always used to hate slide-advancers, you know, those little remotes with forward and backward buttons. Then I tried one and I'm hooked. I use the Microsoft Presenter Mouse 8000 and totally recommend it. It isn't just a great Bluetooth mouse, but flip it over and it's a great Powerpoint slide advancer. 

Take a look at Al Gore's excellent presentation in "An Inconvenient Truth." It's seamless and flows. Now imagine him running over to his laptop to hit the spacebar each time he wanted to advance a slide. My presentations have gotten better as I've started incorporating this technique.

11. Care (deeply)

I really avoid presenting on topics that I don't care about. I avoid it like the Plague and I encourage you to do so as well. There's nothing more important that truly caring about your topic. If you care, it'll show. If you eschew all the other tips, at the very least care.