From best to worse:
**Option 1 (C99 and newer)**
***#include ***
**Option 2**
***typedef enum { false, true } bool;***
**Option 3**
***typedef int bool;
enum { false, true };***
**Option 4**
***typedef int bool;
#define true 1
#define false 0
#Explanation***

Option 1 will work only if you use C99 (or newer) and it's the "standard way" to do it. Choose this if possible.
Options 2, 3 and 4 will have in practice the same identical behavior. #2 and #3 don't use #defines though, which in my opinion is better.
If you are undecided, go with #1!

**For Rails 3.2 or Rails 4+**
You should use **request.original_url** to get the current URL.
This method is documented at original_url method, but if you're curious, the implementation is:
***def original_url
base_url + original_fullpath
end***
**For Rails 3:**
You can write **"#{request.protocol}#{request.host_with_port}#{request.fullpath}"**, since **request.url** is now deprecated.
**For Rails 2:**
You can write **request.url** instead of **request.request_uri**. This combines the protocol (usually http://) with the host, and request_uri to give you the full address.

You can generate a random number with the **rand** method. The argument passed to the **rand** method should be an **integer** or a **range**, and returns a corresponding random number within the range:
***rand(9) # this generates a number between 0 to 8
rand(0 .. 9) # this generates a number between 0 to 9
rand(1 .. 50) # this generates a number between 1 to 50
#rand(m .. n) # m is the start of the number range, n is the end of number range***

It's a new feature of ECMAScript 5.
It's just a string you put in your JavaScript files (either at the top of your file or inside of a function) that looks like this:
***"use strict";***
Putting it in your code now shouldn't cause any problems with current browsers as it's just a string. It may cause problems with your code in the future if your code violates the pragma. For instance, if you currently have **foo = "bar"** without defining **foo** first, your code will start failing...which is a good thing in my opinion.

Angular version 2+ provides several ways to add classes conditionally:
**type one**
***[class.my_class] = "step === 'step1'"***

**type two**
***[ngClass]="{'my_class': step === 'step1'}"***
and multiple option:
***[ngClass]="{'my_class': step === 'step1', 'my_class2' : step === 'step2' }"***

**type three**
***[ngClass]="{1 : 'my_class1', 2 : 'my_class2', 3 : 'my_class4'}[step]"***

**type four**
***[ngClass]="step == 'step1' ? 'my_class1' : 'my_class2'"***

The correct syntax is the following:
******

**Promise**

A **Promise** handles a single event when an async operation completes or fails.

Note: There are **Promise** libraries out there that support cancellation, but ES6 **Promise** doesn't so far.

**Observable**

An **Observable** is like a **Stream** (in many languages) and allows to pass zero or more events where the callback is called for each event.

Often **Observable** is preferred over **Promise** because it provides the features of **Promise** and more. With **Observable** it doesn't matter if you want to handle 0, 1, or multiple events. You can utilize the same API in each case.

**Observable** also has the advantage over **Promise** to be **cancellable**. If the result of an HTTP request to a server or some other expensive async operation isn't needed anymore, the **Subscription** of an **Observable** allows to cancel the subscription, while a **Promise** will eventually call the success or failed callback even when you don't need the notification or the result it provides anymore.

While a **Promise** starts immediately, an **Observable** only starts if you subscribe to it. This is why Observables are called lazy.

Observable provides **operators** like **map**, **forEach**, **reduce**, ... similar to an array

There are also powerful operators like **retry()**, or **replay()**, ... that are often quite handy. A list of operators shipped with rxjs

Lazy execution allows to build up a chain of operators before the observable is executed by subscribing, to do a more declarative kind of programming.

Yes, that's it. In the **app.module.ts** file, I just added:
***import { FormsModule } from '@angular/forms';

[...]

@NgModule({
imports: [
[...]
FormsModule
],
[...]
})***

The last two are identical; "atomic" is the default behavior ( -- **atomic** was added as a keyword in recent versions of llvm/clang).
Assuming that you are @synthesizing the method implementations, atomic vs. non-atomic changes the generated code. If you are writing your own setter/getters, atomic/nonatomic/retain/assign/copy are merely advisory. (Note: @synthesize is now the default behavior in recent versions of LLVM. There is also no need to declare instance variables; they will be synthesized automatically, too, and will have an **_** prepended to their name to prevent accidental direct access).
With "atomic", the synthesized setter/getter will ensure that a whole value is always returned from the getter or set by the setter, regardless of setter activity on any other thread. That is, if thread A is in the middle of the getter while thread B calls the setter, an actual viable value -- an autoreleased object, most likely -- will be returned to the caller in A.
In **nonatomic**, no such guarantees are made. Thus, **nonatomic** is considerably faster than "atomic".
What "atomic" does not do is make any guarantees about thread safety. If thread A is calling the getter simultaneously with thread B and C calling the setter with different values, thread A may get any one of the three values returned -- the one prior to any setters being called or either of the values passed into the setters in B and C. Likewise, the object may end up with the value from B or C, no way to tell.
Ensuring data integrity -- one of the primary challenges of multi-threaded programming -- is achieved by other means.
Adding to this:
**atomicity** of a single property also cannot guarantee thread safety when multiple dependent properties are in play.
Consider:
***@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;***
In this case, thread A could be renaming the object by calling **setFirstName**: and then calling **setLastName**:. In the meantime, thread B may call **fullName** in between thread A's two calls and will receive the new first name coupled with the old last name.

To address this, you need a transactional model. I.e. some other kind of synchronization and/or exclusion that allows one to exclude access to **fullName** while the dependent properties are being updated.

Using the Standard C++ Library: **std::bitset**.
Or the **Boost** version: **boost::dynamic_bitset**.
There is no need to roll your own:
***#include
#include

int main()
{
std::bitset<5> x;

x[1] = 1;
x[2] = 0;
// Note x[0-4] valid

std::cout << x << std::endl;
}
***
***[Alpha:] > ./a.out
00010***
The Boost version allows a runtime sized bitset compared with a **standard library** compile-time sized bitset.

**append**: Appends object at the end.
***x = [1, 2, 3]
x.append([4, 5])
print (x)***
gives you: **[1, 2, 3, [4, 5]]**
**extend**: Extends list by appending elements from the iterable.
***x = [1, 2, 3]
x.extend([4, 5])
print (x)***
gives you: **[1, 2, 3, 4, 5]**

It may look cleaner using a key instead a cmp:
***newlist = sorted(list_to_be_sorted, key=lambda k: k['name']) ***
or as J.F.Sebastian and others suggested,
***from operator import itemgetter
newlist = sorted(list_to_be_sorted, key=itemgetter('name')) ***
For completeness (as pointed out in comments by fitzgeraldsteele), add **reverse=True** to sort descending
***newlist = sorted(l, key=itemgetter('name'), reverse=True)***