How store is injected into context and passed down from Provider

During the initial mount (ReactCompositeComponent.performInitialMount), React creates the context by merging the pre-existing context and the ChildContext, which is obtained from the component’s getChildContext method.

And in Provider.prototype.getChildContext method, the store is returned.

Define contextTypes to receive some properties of the context (otherwise all properties will be filtered out before the component receive the context)

static contextTypes = {
    store: PropTypes.object

Define getChildContext along with childContextTypes to pass down values through context

static childContextTypes = {
    store: PropTypes.object
 return {store:};

~/.bash_profile, ~/.bash_login, ~/.profile, ~/.bashrc and /etc/profile

When you log in to the system, bash will first execute the global setup file /etc/profile and then it will look for the personal setup file in the following order (will stop on the first finding)

  1. ~/.bash_profile (Derived from the Bourne Shell’s file name .profile)
  2. ~/.bash_login (Derived from the C Shell’s file name .login)
  3. ~/.profile

If all 3 files exist and need to be used, source the other files from ~/.bash_profile

~/.bashrc will be executed when you run a subshell by typing bash on the command line.

If ~/.bashrc needs to be executed when you log in to the system, source the file from ~/.bash_profile

When blame shows every line being changed and not committed state

00000000 (Not Committed Yet 2016-06-12 12:28:55 +0900 1) …
00000000 (Not Committed Yet 2016-06-12 12:28:55 +0900 2) …
00000000 (Not Committed Yet 2016-06-12 12:28:55 +0900 3) …
00000000 (Not Committed Yet 2016-06-12 12:28:55 +0900 4) …

This happened on Windows machine with Linux repo.

The problem is due to the different line breaks used in local machine and the server.

This can be solved by blaming on a file in the repo (since the file would have the same line breaks)

git blame HEAD file.txt

or using -w flag to ignore the line breaks.

git blame -w file.txt


SELinux (read as S.E.Linux)

The main purpose of using SELinux is to protect the system from “unpredictable” security breaches.
It provides a kernel-level security protection based on a white-list policy and can protect from things like application bugs and application misconfigurations.
(Buggy/misconfigured FTP/HTTP/other daemons may give the users more privileges than they should)

When troubleshooting SELinux related permission issues, “ls -Z” is the command to view the “label”, which defines the access privileges.