Roman_Kh

Наладить правильную коммуникацию лучше всего с помощью Flux.

Конструкция # -*- coding: cp1251 -*- указывает кодировку самого файла с кодом программы. Поэтому все строки в тексте будут сохранены в кодировке 1251, и если вы выводите в консоль с кодировкой 1251, то все напечатается нормально. Однако если кодировка консоли будет 866 или Unicode, то вместо кириллицы вы получите кракозябры.

Проблема python'а заключается в том, что разные команды/функции почему-то по-разному кодируют/раскодируют строки.
Чтобы с этим справиться, лучше все строки кодировать в Unicode и выводить в Unicode консоль. И использовать только команды с понятным поведением, например, print. Иначе рано или поздно вы снова столкнетесь с кракозябрами.

Model selection или Gradient boosting.

На российские псевдобизнес псевдошколы не стоит тратить деньги.
А вот Stanford, Harvard, Sloan, Wharton, LBS, IE, HEC, SBS и им подобные будут полезны: принесут и необходимые знания, и знакомства, и статус. В некоторых бизнес-школах даже есть специальные программы для препринимателей.

Кэш - это инструмент для ускорения алгоритмов с высокой локальностью данных. Проще говоря, если в алгоритме в какой-то момент времени данные читаются из ячейки памяти N, значит в очень скором времени потребуется чтение из какой-то ячейки, расположенной очень близко к N.
Еще один немаловажный момент - это высокая стоимость кэш-памяти. А значит алгоритм должен использовать кэш весьма рационально.

Таким образом cache conscious алгоритмы:
- обращаются к данные в легко предсказуемой манере (например, строго последовательно)
- хранят данные компактным образом (т.е. минимально необходимый набор данных оптимального типа с правильным выравниванием).

Обычно когда говорят о cache conscious алгоритмах имеют в виду кэш процессора (и даже все уровни процессорных кэшей, каждый из которых больше, но и медленнее предыдущего). Хотя это также относится и к распределенным вычислениям, когда алгоритм должен учитывать, что обращение к данным расположенным на другом компьютере может быть очень долгим и дорогим.

Из своего компонента вы dispatch вообще не должны вызывать никогда.
В Resize вы должны вызывать action, который вызывает dispatch.
Когда store выполнит обновление, он должен отправлять сообщение, допустим, RESIZE
Совершенно независимо от этого Modal должен при создании (например, в componentDidMount) подписаться на получение сообщений RESIZE от store.
Получив сообщение, Modal должен отреагировать на него, например, вызвав render, изменив свое состояние через setState или через forceUpdate().

Вам нужен нечеткий поиск. Начальный экскурс в тему можно получить здесь и здесь.

Это сделано с помощью React и React Router, а потом собрано WebPack'ом

Можно реализовать оба метода. Я обычно предпочитаю выгружать большие блоки данных с сервера, тем самым уменьшая количество запросов, а значит и нагрузку на сервер.

Только в обоих случаях нужно использовать GET, поскольку POST предназначен для отправки данных от клиента на сервер.

Добавьте в компонент List функцию getId(), которая будет возвращать this.props.params.id
А в App можно добавить функцию, которая будет возвращать все id всех children'ов.
Ссылку на функцию можно передать в качестве параметра при создании компонента MenuList
<MenuList getId={this.getAllIds} />
А MenuList будет вызывать ее при отрисовке и разбирать, какие пункты сделать активными, а какие нет.

Как вариант, можно сделать store (см. Flux), который будет содержать данные об отображенных компонентах. И тогда все (App, MenuList, List) будут общаться только с этим store.

Купить у Amazon несколько IP-адресов, привязать их к вашему EC2-инстансу, а дальше все как обычно - поднимаете интерфейсы, настраиваете маршрутизацию, DNS и ваш веб-сервер (если нужно).

https://docs.python.org/3.1/library/struct.html

Это зависит от того, что считатть гигабайтом: 70 * 10^9 - это как раз примерно 66 * 2^30.