As already stated ??!??! is essentially two trigraphs (??! and ??! again) mushed together that get replaced-translated to ||, i.e the logical OR, by the preprocessor.

The following table containing every trigraph should help disambiguate alternate trigraph combinations:
***
Trigraph Replaces

??( [
??) ]
??< {
??> }
??/ \
??' ^
??= #
??! |
??- ~
***

If you had a function that takes:
***
1 millisecond to complete if you have 2 elements.
2 milliseconds to complete if you have 4 elements.
3 milliseconds to complete if you have 8 elements.
4 milliseconds to complete if you have 16 elements.
...
n milliseconds to complete if you have 2^n elements.
***
Then it takes log2(n) time. The Big O notation, loosely speaking, means that the relationship only needs to be true for large n, and that constant factors and smaller terms can be ignored.

2 is the console standard error.

1 is the console standard output.

This is the standard Unix, and Windows also follows the POSIX.

E.g. when you run
***
perl test.pl 2>&1
***
the standard error is redirected to standard output, so you can see both outputs together:
***
perl test.pl > debug.log 2>&1
***
After execution, you can see all the output, including errors, in the debug.log.
***
perl test.pl 1>out.log 2>err.log
***
Then standard output goes to out.log, and standard error to err.log.

I suggest you to try to understand these.

Cloning an Object was always a concern in JS, but it was all about before ES6, I list different ways of copying an object in JavaScript below, imagine you have the Object below and would like to have a deep copy of that:
***
var obj = {a:1, b:2, c:3, d:4};
***
There are few ways to copy this object, without changing the origin:
***
ES5+, Using a simple function to do the copy for you:
function deepCopyObj(obj) {
if (null == obj || "object" != typeof obj) return obj;
if (obj instanceof Date) {
var copy = new Date();
copy.setTime(obj.getTime());
return copy;
}
if (obj instanceof Array) {
var copy = [];
for (var i = 0, len = obj.length; i < len; i++) {
copy[i] = deepCopyObj(obj[i]);
}
return copy;
}
if (obj instanceof Object) {
var copy = {};
for (var attr in obj) {
if (obj.hasOwnProperty(attr)) copy[attr] = deepCopyObj(obj[attr]);
}
return copy;
}
throw new Error("Unable to copy obj this object.");
}
***
ES5+, using JSON.parse and JSON.stringify.
***
var deepCopyObj = JSON.parse(JSON.stringify(obj));
***
AngularJs:
***
var deepCopyObj = angular.copy(obj);
***
jQuery:
***
var deepCopyObj = jQuery.extend(true, {}, obj);
***
UnderscoreJs & Loadash:
***
var deepCopyObj = _.cloneDeep(obj); //latest version UndescoreJs makes shallow copy
***

POST means "create new" as in "Here is the input for creating a user, create it for me".

PUT means "insert, replace if already exists" as in "Here is the data for user 5".

*px* - Pixels - point per scale corresponds to actual pixels on the screen.

*i *- Inches - based on the physical size of the screen.

*mm* - Millimeters - based on the physical size of the screen.

*pt* - Points - 1/72 of an inch based on the physical size of the screen.

*dp* - Density-independent Pixels - an abstract unit that is based on the physical density of the screen. These units are relative to a 160 dpi screen, so one dp is one pixel on a 160 dpi screen. The ratio of dp-to-pixel will change with the screen density, but not necessarily in direct proportion. Note: The compiler accepts both dip and dp, though dp is more consistent with sp.

*sp* - scalable pixels - this is like the dp unit, but it is also scaled by the user's font size preference. It is recommended that you use this unit when specifying font sizes, so they will be adjusted for both the screen density and user's preference.

Take the example of two screens that are the same size but one has a screen density of 160 dpi (dots per inch, i.e. pixels per inch) and the other is 240 dpi.
***
Lower resolution screen Higher resolution, same size
Physical Width 1.5 inches 1.5 inches
Dots Per Inch (“dpi”) 160 240
Pixels (=width*dpi) 240 360
Density (factor of baseline 160) 1.0 1.5

Density-independent pixels 240 240
(“dip” or “dp” or “dps”)

Scale-independent pixels
(“sip” or “sp”) Depends on user font size settings same
***

string is an alias for System.String. Assuming your code using String compiles to System.String (i.e. you haven't got a using directive for some other namespace with a different String type), they compile to the same code, so at execution time there is no difference whatsoever. This is just one of the aliases in C#. The complete list is:
***
object: System.Object
string: System.String
bool: System.Boolean
byte: System.Byte
sbyte: System.SByte
short: System.Int16
ushort: System.UInt16
int: System.Int32
uint: System.UInt32
long: System.Int64
ulong: System.UInt64
float: System.Single
double: System.Double
decimal: System.Decimal
char: System.Char
***
Apart from string and object, the aliases are all to value types. decimal is a value type, but not a primitive type in the CLR. The only primitive type which doesn't have an alias is System.IntPtr.

In the spec, the value type aliases are known as "simple types". Literals can be used for constant values of every simple type; no other value types have literal forms available. (Compare this with VB, which allows DateTime literals, and has an alias for it too.)

There is one circumstance in which you have to use the aliases: when explicitly specifying an enum's underlying type. For instance:
***
public enum Foo : UInt32 {} // Invalid
public enum Bar : uint {} // Valid
***
That's just a matter of the way the spec defines enum declarations - the part after the colon has to be the integral-type production, which is one token of sbyte, byte, short, ushort, int, uint, long, ulong, char... as opposed to a type production as used by variable declarations for example. It doesn't indicate any other difference.

Finally, when it comes to which to use: personally I use the aliases everywhere for the implementation, but the CLR type for any APIs. It really doesn't matter too much which you use in terms of implementation - consistency among your team is nice, but no-one else is going to care. On the other hand, it's genuinely important that if you refer to a type in an API, you do so in a language-neutral way. A method called ReadInt32 is unambiguous, whereas a method called ReadInt requires interpretation. The caller could be using a language that defines an int alias for Int16, for example. The .NET framework designers have followed this pattern, good examples being in the BitConverter, BinaryReader and Convert classes.

it's a time change in 1927 in Shanghai.

It was 23:54:07 in Shanghai, in the local standard time, but then after 5 minutes and 52 seconds, it turned to the next day at 00:00:00, and then local standard time changed back to 23:54:08. So, that's why the difference between the two times is 343 seconds, not 1 second, as you would have expected.

The time can also mess up in other places like the US. The US has Daylight Saving Time. When the Daylight Saving Time starts the time goes forward 1 hour. But after a while, the Daylight Saving Time ends, and it goes backward 1 hour back to the standard time zone. So sometimes when comparing times in the US the difference is about 3600 seconds not 1 second.

But there is something different about these two-time changes. The latter changes continuously and the former was just a change. It didn't change back or change again by the same amount.

It's better to use UTC unless if needed to use non-UTC time like in display.

When you use to pull, Git tries to automatically merge. It is context-sensitive, so Git will merge any pulled commits into the branch you are currently working on. pull automatically merges the commits without letting you review them first. If you don’t carefully manage your branches, you may run into frequent conflicts.

When you fetch, Git gathers any commits from the target branch that do not exist in your current branch and stores them in your local repository. However, it does not merge them with your current branch. This is particularly useful if you need to keep your repository up to date, but are working on something that might break if you update your files. To integrate the commits into your current branch, you must use merge afterward.

At times it is quite handy to get the auto increment primary key (id) of the row if it exists and 0 if it doesn't.

Here's how this can be done in a single query:
***
SELECT IFNULL(`id`, COUNT(*)) FROM WHERE ...
***

Use DISTINCT if you just want to remove duplicates. Use GROUPY BY if you want to apply aggregate operators (MAX, SUM, GROUP_CONCAT, ..., or a HAVING clause).

Use SCOPE_IDENTITY() to get the new ID value
***
INSERT INTO table (name) VALUES('bob');

SELECT SCOPE_IDENTITY()
***