Mimuss

Поставьте себя на место заказчика и смените область, к примеру, на создание автомобиля. Вы заказываете у мастера автомобиль ручной сборки. Он его собирает, проверяет заводится он или нет, и отдаём Вам в пользование. Вы садитесь в автомобиль, выезжаете на любимый автобан и даёте жару в 100 км/час. На 101 км/час у Вас отваливаются передние колёса. Приятная ситуация? А ведь мастер "просто собрал машину".

Если смотреть на бизнес по-взрослому, то всё просто:

• Есть Заказчик. У него стоит задача создать Продукт, с помощью которого он бы зарабатывал деньги (ну или другая цель, не суть).
  
• Есть Исполнитель (разработчик или команда разработчиков). Исполнитель обязуется за обусловленный Гонорар создать и поддерживать Продукт, который бы отвечал критериям качества Заказчика.
  
• Если Исполнитель делает Продукт не соответствующий критериям качества Заказчика, значит он не выполняет условия Договора.
  
• Если Заказчик не выплачивает Гонорар в должном объеме и вовремя, или требует чего-то не обусловленного в рамках Договора, значит он не выполняет условия Договора, а то и нарушает.
  
• И Исполнитель и Заказчик должны понимать, что они создают Продукт, и должным образом очертить в рамках Договора критерии к созданию/поддержке этого Продукта. Дабы однозначность этого вопроса была явная и юридическая.
  

Всё остальное - лирика.

Если Ваша команда (как Исполнитель) не обладает штатом тестировщиков, то соответствующие обязанности по обеспечению качества Продукта Вы должны осознанно брать на себя. Нет никаких "разработчик просто пишет код". Есть "разработчик создаёт Продукт". Команда разработки обязуется согласно Договору создать Продукт ожидаемого качества и всё. Как это качество обеспечивается - вопрос уже второстепенный и зависит от состава команды, существующих технических средств, да и самого Продукта как такового (много каверзных кейсов не поддаются вменяемой автоматизации). Соответственно, бюджет на обеспечение качество Продукта должен закладывать в любом случае, независимо от того есть ли тестировщик или нет.

«водка».mb_chars.upcase

Чтобы просматривать страницу в полном режиме в Google Chrome для MacOS, нужно использовать сочетание клавиш ⌘+Shift+F. Приятного использования

Параллельно программирование в основном касается рантайма, а не собственно языка.
Поэтому, можно брать всю ту же литературу, что и для параллельного программирование на Java (а такой литературы достаточно). Принципы там одни, да и библиотеки в основном пересекаются. Другой язык никак не помешает пользоваться общим рантаймом. Единственное отличие: на Scala аналогичный код в итоге может выглядеть намного красивее (если при написании мыслить по-скаловски).
Впоследствии стоит переходить к изучению документация к специфическим скалавским параллельным библиотекам/фреймворкам (Akka и др.). На более продвинутом уровне чтение исходников стандартной и сторонних библиотек будет давать гораздо более информации за более короткое время, а чтение книг (авторы которых просто пропустили через свою голову прочитанный код) покажется расточительным расходованием своего времени.

Рецепт изучения (один из возможных): Если начинать с самых азов, то подойдет соответствующая глава (про concurrency) из книги Брюса Эккеля. Там дается очень неплохое введение в тему, раскрываются соответствующие данной области проблемы и показываются основные пути их решения.
Далее следует выбрать более конкретное направление. В рамках темы параллельных вычислений существуют несколько различных подходов (смешивать их в одном проекте не только бессмысленно, но и опасно).
1. Классический подход, основанный на потоках и блокировках ресурсов.
1A. Разновидность (1), где вместо явных блокировок используются неблокирующие очереди.
2. Подход, основанный на повсеместном использовании Promise/Future.
3. Акторы (типизированные и нетипизированные (эти почему-то становятся более популярны)).
4. STM.
После выбора подхода к решению распараллеливания вычислений, следует выбрать конкретный инструмент (библиотеку) и углубится в изучение его официальной документации и любых примеров, найденных в Сети. На более продвинутом уровне можно будет перейти к чтению исходников и сторонняя литература больше не понадобится.

UPD: Все-таки существует специальная книга по Scala Concurrecy. Я ее не читал. Но судя по оглавлению, все основные темы там раскрываются.

У Оракла очень хорошая документация. Попробуйте начать отсюда:
https://docs.oracle.com/en/database/oracle/oracle-...

2 Day Developer's Guide
Database Development Guide

Здесь

Дополнительно:
1. Здесь можно посмотреть и спросить.
2. Здесь - теория.

Первый год сотрудник без опыта - это бесполезный источник трат. Фактически работодателю приходится заниматься благотворительностью, нанимая каких-то незнакомых людей, обучая и давая им деньги ни за что. Поэтому денег будут давать мало, ровно столько, чтобы сотрудник мог доехать до работы и не падал от голода. Это одна из причин, почему надо стараться искать стажировки ещё во время обучения, хотя бы летние.

На какую зарплату ориентироваться в Москве

Веб - программист, написание модулей, навыки git, linux, python

С такими знаниями - ни на какую (если под python вы подразумеваете только базовое знание языка)

Чтобы иметь шансы попасть на джуна, например на php-программиста (для стажера, кстати, требования будут аналогичны, только з/п меньше), на з/п от 40т.р. в Москве, нужно знать хотя бы на средне-базовом уровне:

- html/css
- верстка
- PHP
- ООП
- SQL
- git
- composer
- JS/jQuery
- Какой-нибудь из современных фреймворков: Yii2/Laravel/Symfony
- Портфолио

Кто-то может сказать что это завышенные требования - отнюдь, могут спросить (у меня спрашивали) еще:
- Свободное владение английским
- Linux на хорошем уровне
- Высшее техническое образование
- Слепую печать (да, даже такое)
- Другие БД

P.S. Все это из личного опыта - в прошлом году устраивался на джуна в Москве.
P.P.S. Входить в ИТ в 2018 году я бы посоветовал только тем, кто без кодинга/железа жить не может. Сфера специфическая, и з/п сильно демпингуются. Джунов много и их ставят в крайне невыгодные условия - много работать за копейки.

"так как склонен писать невнятный говнокод" - это у всех так когда учишься.
Главное не пытайся всё делать на Class Based Views потому что в некоторых местах они не подходят и получается код с излишне усложненным потоком выполнения.

покажите /var/log/nginx/error.log

1. Откуда вы взяли, что программа требует 1 гб памяти? Если из инструкции, то возможно программа на максимуме может потребовать до 1 гб памяти, а не требует этого при старте.
2. Swap.

Если 9.6 устанавливался менеджером пакетов, так пусть менеджер пакетов и обновляет. Не вижу проблемы в выполнении команд update и upgrade.

Определитесь, хотите вы устанавливать СУБД из пакета (да, файлы будут "разбросаны по файловой системе") или чтобы всё это компактно находилось внутри одного каталога, что позволяет без проблем манипулировать этим хозяйством руками.

В первом случае, как вам посоветовал Сергей Горностаев - просто подключайте репозиторий с устраивающей вас версией и апгрейдитесь. Во втором - устанавливайте из дистрибутива, указав при инсталляции подходящий вам каталог.