panel.slideUp(400/*the default value*/,function() { 
  setTimeout(function() { 
    header.each(function(){ 
      this.className+=''; 
    }); 
  },1); 
});

var strArray=Object.prototype.toString(new Array());
Array.isArray=function(obj) {
  return Object.prototype.toString(obj)==strArray;
}

DECLARE @Var1 INT
DECLARE @Var2 INT
SELECT @Var1=Column1,@Var2=Column2 FROM MyTable WHERE ID=1
UPDATE MyTable SET Column1=@Var1,Column2=@Var2 WHERE ID=2

UPDATE MyTable 
  SET Column1=Alias.Column1,Column2=Alias.Column2
FROM MyOtherTable AS Alias
WHERE ID=2
  AND Alias.ID=1

UPDATE MyTable 
  SET Column1=Alias.Column1,Column2=Alias.Column2
FROM MyTable AS Alias
WHERE ID=2
  AND Alias.ID=1

UPDATE MyTable 
  SET Column1=Alias.Column1,Column2=Alias.Column2
FROM (SELECT * FROM MyTable) AS Alias
WHERE ID=2
  AND Alias.ID=1

WITH Alias(Column1,Column2)
AS (
  SELECT Column1, Column2 FROM MyTable
)
UPDATE MyTable 
  SET Column1=Alias.Column1,Column2=Alias.Column2
FROM Alias
WHERE ID=2
  AND Alias.ID=1

var obj={
  property1:"value1",
  property2:2,
  property3: new Date()
};
obj["property 4"]="value 4";
obj.property5=new MyCustomObject();
obj[6]='value 6';
console.log(obj.property1);
console.log(obj['property2']);
console.log(obj["property3"]);
console.log(obj['property 4']);
console.log(obj.property5);
console.log(obj[6]);

obj[new Date()]=true;

obj[new MyObject()]=true;

if (x==1) { 
  doSomething() 
} else { 
  doSomethingElse(); 
}

switch(x) {
  case 1:
    doSomething();
    break;
  default:
    doSomethingElse();
    break;
}

if (x===1) { 
  doSomething() 
} else { 
  doSomethingElse(); 
}

public static class Common {

  public enum MyEnumeration {
    Item1,
    Item2
  }

}

ElementsFlags.Add("form", HtmlElementFlag.CanOverlap | HtmlElementFlag.Empty);

HtmlNode.ElementsFlags["form"]=HtmlElementFlag.CanOverlap;

• Do not punish mistakes, instead give more chances to experience and learning - this is paramount to any analytical process. The purpose is not to kill the host, but to help it adapt to the disease. Own your mistakes, analyse them, learn from them.
• Decentralize control - let professionals assume responsibility and handle their own jobs as they know best. Dictating every action from the top puts enormous pressure on few people that cannot possibly know everything and react with enough speed to the unpredictable
• Communication is paramount in managing complex and unexpected situations, while things like checklists can take care of simple and necessary things - this is the main idea of the book, enabling creativity and intuition by checking off the routine stuff
• A process can help by only changing behaviour - Gawande gives an example where soap was freely given to people, together with instructions on how and when to use it. It had significant beneficial effects on people, not because of the soap per sé, but because it changed behaviour. They were already buying and using soap, but the routine and discipline of soap use was the most important result
• Team huddles - like in some American sports, when a team is trying to achieve a result, they need to communicate well. One of the important checks for all the lists in the book was a discussion between all team members describing what they are about to do. Equally important is communicating during the task, but also at the end, where conclusions can be drawn and outcomes discussed
• Checklists can be bad - a good checklist is precise, to the point, easy to use. A long and verbose list can impede people from their task, rather than help them, while vague items in the lists cause more harm than good
• A very important part of using a checklist system is to clearly define pause points - they are the moments at which people take the list and check things from it. An undefined or vaguely defined pause point is just as bad as useless checklist items
• Checklists are of two flavours - READ-DO, like a food recipe, with clear actions that must be performed in order, and DO-CONFIRM, where people stop to see what was accomplished and what is left to do, like a shopping list
• A good checklist should optimally have between five and nine items - the number of items the human brain can easily remember. This is not a strong rule, but it does help
• Investigate failures - there is no other way to adapt
• A checklist gotcha is the translation - people might make an effort to make a checklist do wonders in a certain context, only to find that translating it to other cultures is very difficult and prone to errors. A checklist is itself subject to failure investigation and adaptation
• Lobbying and greed are hurting us - a particularly emotional bit of the book is a small rant in which the author describes how people would have jumped on a pill or an expensive surgical device that would have brought the same great results as checklists, only to observe that people are less interested in something easy to copy, distribute and that doesn't bring benefits to anyone except the patients. That was a painful lesson
• The star test pilot is dead - there was a time when crazy brave test pilots would risk their lives to test airplanes. The checklist method has removed the need for unnecessary risks and slowly removed the danger and complexity in the test pilot work, thus destroying the mythos. That also reduced the number of useless deaths significantly.
• The financial investors that behave most like airline captains are the most successful - they balance their own greed or need for excitement with carefully crafted checklists, enabling their "guts" with the certainty that small details were not missed or ignored for reasons of wishful thinking
• The Hudson river hero(es) - an interesting point was made when describing the Hudson river airplane crash. Even if the crew worked perfectly with each other, keeping their calm in the face of both engines suddenly stopping, calming and preparing the passengers, carefully checking things off their lists and completing each other's tasks, the media pulled hard to make only the pilot a hero. Surely he denied it every time and said that it was a crew effort because he was modest. Clearly he had everything under control. That did not happen and it also explains why the checklist is so effective and yet so few people actually employ it. We dream of something else
• We are not built for discipline - that is why discipline is something that enables itself. It takes a little discipline to become more disciplined. A checklist ensures a kind of formal discipline in cases previously analysed by yourself. It assumes control over the emotional need for risk and excitement.
• Optimize the system, not the parts - it is always the best choice to look at something as a whole and improve it as a whole. The author mentions an experiment of building a car from the best parts, taken from different companies. The result was a junk car that was not very good. The way the parts interact with one another is often more important than individual performance

• Refactoring versus Optimization - Optimizing the performance or improving some functionality should not be mixed up with the refactoring of code, which aims to improve readability of code while preserving the initial functionality. Mixing them up is pitting the two essential stages of development one against the other.
• Methods should use their data of their own object - one of the telltales of need to refactor is when methods from an object use data from another object. It smells like the method should be moved in the responsibility of that other object.
• When it is easy to refactor, choose a simple design - Of course the opposite is true, as well: when you know it will be hard to refactor a piece of code, try to design it first. If not, it is better to not add unnecessary complexity. This is in line with the KISS concept.
• Split your application into self encapsulated parts - One of the ways to simplify refactoring is to separate your application into bits that you can manage separately. If you didn't design your application like that, try to first split it, then refactor.
• Whenever you need to write a comment, consider extracting a method with a meaningful name - or renaming methods to be more expressive.
• Consider polymorphism when seeing a switch statement - Now that is an interesting topic in itself. Why would polymorphism help here? How could it be simpler to understand than a switch/case statement? The idea behind this is that if you have a switch somewhere, you might have it somewhere else as well. Instead of taking decisions inside each method, it is better to split that behaviour in separate classes, each describing the particular value that the switch would have operated on.
• Test before refactoring - this would have been drilled in your head already, but if not, the book will do that to you. In order to not add faults to the program with the refactoring, make sure you have tests for the existing functionality, tests that should pass after the refactoring process, as well.
• The Quantity pattern - Review the Quantity pattern in order to improve readability and encapsulate simple common actions performed on specific types of units.
• Split conditionals into methods - in other words try to simplify your conditional blocks to if conditionMethod() then ifMethod() else elseMethod(). It might seem a sure way to get to a fragmented code base, with small methods everywhere, but the idea is sound. A condition, after all, is an intention. Encapsulate it into a well named method and it will be very clear what the programmer intended. Maybe the same method will be used in other places as well, and then, using polymorphism, one can get rid of the conditional altogether.
• Use Null objects - an interesting concept that I haven't even considered before. It is easy to recognize the need for a Null object when there are a lot of checks for null. if x==null then something() else x.somethingElse() would be turned into a simple x.something() if instead of null, x would be an object that represents empty, but still has attached behavior. An interesting side effect of this is that often the Null object can be made an immutable singleton.
• Code inside Assertions always executes - This is a gotcha I found interesting. Imagine the following code: Assert.IsTrue(SomeCondition()) Even if the Assert object is designed to not execute anything in Release mode, only compiled in Debug, the method SomeCondition() will execute all the time. One option is to use an extra condition: Assert.IsTrue(Assert.On&&SomeCondition()) or, in C#, try to send an expression: Assert.IsTrue(()=>SomeCondition())
• Careful when replacing method parameters with parameter object in parallel processing scenarios - Which nowadays means always. Anyways, the idea is that old libraries designed for parallel processing used large value parameter lists. One might be inclined to Introduce Parameter Object, but that introduces a reference object that might lead to locking issues. Just another gotcha.
• Separate Modifier from Query - This is a useful convention to remember. A method should either get some information (query) or change some data (modifier), not both. It makes the intention clear.