afilippov

У вас приложение состоит из двух частей:
- это глупые (dumb) компоненты, по факту это почти все Ваши компоненты. Они просто рендерят props
- это так называемые контейнеры (или controller-view pattern), такие компоненты привязаны к redux (например) и у них есть логика.

react-router - это самое популярное (и на мой взгляд - лучшее) решение для роутинга. Не относитесь к этому как к вью. Просто удобней всего было сделать роуты как компоненты (но можно использовать и простые JS объекты). А сам роутер по определению должен рендерится, т.к. он и отображает нужный компонент в зависимости от url.

Вам следует создавать Docker-контейнер таким образом, чтобы в нём работал один ключевой процесс (у которого будет PID 0), завершение которого означает завершение работы контейнера. Код выхода этого процесса будет кодом выхода контейнера. Вы сможете увидеть его в выводе `docker ps --all`. Подробнее здесь: each-container-should-have-only-one-concern. Это не означает, что в контейнере должен быть всего один процесс, но должен быть один такой процесс, жизненный цикл которого неразрывно связан с жизненным циклом контейнера.

Логи этот процесс должен писать в STDOUT и STDERR - тогда Вы их сможете увидеть с помощью `docker logs ` и перенаправить куда надо с помощью драйвера логирования, настроенного в Докер-демоне. Подробнее здесь: View a container's logs

А зачем останавливать репликацию и прочие странные вещи для добавления колонки в postgresql?
Добавляете default null колонку. Транзакционно, мгновенно. Если колонка не должна быть null - то после добавления колонки меняете ей default, затем небольшими пачками обновляете имеющиеся строки, затем drop null.

Так делается для того, чтобы оставить за собой возможность впоследствии поменять реализацию не меняя интерфейс. Например, в будущем может потребоваться заменить реализацию ArrayList на LinkedList, если бы в качестве типа переменной был указан конкретный класс, то к тому времени код мог бы уже обрасти различными обращениями к, специфическим для конкретного класса, методами, выходящими за границы интерфейса List. В таком случае при замене реализации на LinkedList пришлось бы выискивать в коде и выкорчевывать оттуда все обращения к специфике ArrayList. На сколько это адски сложная задача знают все, кому приходилось работать над крупными проектами. Поэтому люди, знакомые с этой проблемой, предпочитают предупреждать подобные проблемы заранее, то есть во всех местах, где возможна смена реализации в будущем (то есть почти везде), стараются пользоваться исключительно интерфейсами, вместо того, чтобы опираться на конкретные реализации. В данном примере, если в качестве типа переменной был бы использован интерфейс List, то смена реализации ArrayList на LinkedList решалась бы заменой всего одной строки не зависимо от масштабов проекта.

Смотря чего вы хотите. Чтобы прокачаться дальше в computer science, можно Седжвика "Алгоритмы на Java". Если какой-то конкретики типа веб-приложений, нужны уже конкретные книги по технологиям, Spring и т.п. Можно пойти на JavaRush порешать там задачи (это не реклама джавараша, я просто у них занимался и знаю что задач там реально много, устанете решать). Можно пойти на Udacity учиться там андроиду.

Шилдт - хорошая книга, но это по сути пересказ спецификации.

Еще стандартная книга для джавистов Thinking in Java/Философия Java, ее обязательно стоит почитать.

На самом деле, тут некая неоднозначность. Вот тут описана проблема и возможные пути её решения. В двух словах: всё ограничено скоростью диска. Инсерт быстрый (50 тыщ операций в секунду), но транкзакции медленные (60 в секунду). Если вставить кучу инсертов в одну транкзакцию (через BEGIN...COMMIT) - будет быстро. Ещё можно выполнить PRAGMA synchronous=OFF, тогда sqlite не будет ждать подтверждения записи. Но в этом случае, при отключении питания, все несохранённые данные потеряются.

Почитай ещё это:
tech.vg.no/2011/04/04/speeding-up-sqlite-insert-op...
dba.stackexchange.com/questions/8028/whats-better-...
stackoverflow.com/questions/1271641/in-sql-is-upda...