<style>
div {
   width:100px;
   height:100px;
   background-color:blue !important;
}
</style>
<div style="background-color:red;"></div>

<style>
div {
   width:100px !important;
   height:100px;
   background-color:blue !important;
}
</style>
<div style="background-color:red;"></div>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>
$(function() {
//  $('div').width(200); // the width remains 100!
//  $('div').width('200px'); // the width remains 100!
//  $('div')[0].style.width='200px'; // the width remains 100!

//  $('div').width('200px !important'); //this is not a valid value for the width parameter! in IE it will even show an error
//  $('div').css('width','200px !important'); //this is not a valid value for the width parameter! in IE it will even show an error
//  $('div')[0].style.width='200px !important'; //this is not a valid value for the width parameter! in IE it will even show an error

var oldStyle=$('div').attr('style')||'';
$('div').attr('style',oldStyle+';width: 200px !important'); // this is the only thing I found to be working!

});
</script>

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