nirvimel

• Дело вкуса.
  
• Дело привычки.
  

Все.

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

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

Еще вариант: все исходящие заворачиваются на свой же домен, откуда идет редирект (уже по назначению) через meta http-equiv="refresh", а лучше - через js, но только не через 30X код, так как 30X редиректы могут склеиваться.

1C Программист

Существует такая вкладка в Network в Developer Tools в браузере, там отображаются все сетевые запросы исходящие с активной страницы. Смотрите что запрашивается в момент перед погрузкой основного контента. Переписываете этот запрос на Python. Все!
Единственное, иногда для корректной работы AJAX могут потребоваться куки с основной страницы. Тогда делаете requests сессию запрашиваете основную страницу (сама она не понадобиться), после чего в той же открытой сессии выполняете нужный AJAX.

Каково оно учить JavaScript в 2016

есть один проект на шаред хостинге, там постоянно появляются шеллы.

В болоте лежит туша мамонта с прошлогодней охоты, но в ней (почему-то) постоянно заводятся черви.

Ну не могут шеллы заводится сами! НЕ МОГУТ!
Пока у вас в команде будет в порядке вещей такой подход к гигиене системной безопасности и разграничению доступа, когда шеллы на сайте заводятся сами, до тех пор вам не поможет ни один антивирус (ни платный, ни бесплатный).

1. В виртуальную машину ставите Windows XP SP3 (чистый корпоративный, а не какую-то говносборку).
(Не говорите, что это долго, если это надо сделать один раз, и пользоваться потом постоянно).
2. Делаете снепшот виртуалки с чистой свежеустановленной ОС.
3. Ставите своего торояна (пусть даже это - очень ценная и полезная программа, разницы нет).
4. Делаете снепшот виртуалки со свежеустановленным трояном.
5. Запускаете эту Вашу Прелесть. Работаете с ней ровно один сеанс.
6. Откатываете виртуальную машину к снепшоту (4) (или к снепшоту (2), когда захочется поиграть с другим трояном).
...
7. PROFIT.

Что касается собственно CPU, то тут (далее по ссылкам) подробнее.

Как считаете, такая схема достаточно надежна или есть более защищенные/удобные способы?

На этом погорели многие. Люди настолько привыкли окружать себя удобными вещами, что не понимают, что это их удобство иногда может оказаться просто несовместимо с безопасностью.
Разговор в реальном времени (не важно с каким шифрованием и через сколько туннелей) позволяет сопоставить двух абонентов друг с другом на основании только того, что они начинают и заканчивают разговор одновременно! Этой мелочи часто бывает достаточно, чтобы по логам (за много лет до того) выявить связь между двумя субъектами, которые находились в разных странах у разных операторов и пользовались разными технологиями связи (GSM/Skype/SIP). И это не решается применением никакого чудо-софта или никакими технологиями шифрования. Это фундаментальный неустранимый недостаток коммуникаций в реальном времени. Единственное решение - полностью отказаться от общения в реальном времени и вернуться к использованию старой доброй почты (электронной, конечно), с ней тоже связаны многие проблемы в плане безопасности, но они, по крайней мере, имеют техническое решение.

SQLite + одно из его расширений для шифрования.

Этим я даже сам пользовался много лет назад. Что с ним стало за эти годы - понятия не имею. Но сейчас у них на месяц просроченный сертификат на домен. Это должно говорить о многом.
Хотя поверхностный гуглинг не выявил каких-то претензий от его клиентов. В общем, разбирайтесь с ним сами, но не говорите, что я его рекомендовал.

Я такое делаю на юзерскриптах (GreaseMonkey). Кроме всегда доступного localStorage и куки, у GreaseMonkey есть еще и собственное API для хранения значений в базе (отдельная база для каждого юзерскрипта): GM_getValue/GM_setValue. Плюс в то, что после того, как очищаются все куки localStorage (против отслеживания со стороны скриптов на странице), базы моих юзерскриптов остается нетронутыми. Можно вести любую статику или хранить крупные объекты (картинки в бинарном виде, например), база на движке SQLite позволяет и это.

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

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

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