Roman K

Здравствуйте.
Технологий взлома уйма.
В зависимости от того, какие привелегии получил "хакер" при вломе вашей БД - зависит очень много.
Если он получил доступ только на чтение, то захешированные в MD5 пароли ему мало чем помогут, т.к. MD5 не имеет алгоритма обратной расшифровки и хэширование спасёт тем, что взломщик получивший доступ на чтение паролей - самих паролей не получит (есть конечно словарь MD5 хешей, то это другая история).
Вообще для защиты любой БД есть несколько золотых правил:
0. Переименовать дефолтного админа и защитить его сложным паролем.
1. Для каждой БД должен создаваться свой владелец и несколько пользователей с разными наборами привелегий.
2. Ни у одного из пользователей, созданных в п.1 не должно быть прав на изменение таблиц в соседней БД.
Если есть необходимость обновлять соседние БД - делайте это триггером в соседней БД.
3. Каждый внешний веб-сервис должен ходить в БД только с тем набором прав, которых ему достаточно для работы. Т.е. не нужно везде прописывать root и надеяться на лучшее.
В этом случае, если взломщик получит привелегии этого пользователя, то сможет сделать только то, что разрешено этому пользователю. Тогда не выйдет "удалить все и сразу".
Например, для наполнения католога товаров в интернет-магазине может быть отдельный пользователь, с правами на SELECT, INSERT, UPDATE, DELETE в таблице SHOP_PRODUCTS, например. И ничего более.
А пользователи, приходящие в магазин за покупками могут делать SELECT, INSERT, UPDATE, DELETE только в таблицу CUSTOMER_CART. В коде веб-сервиса, естественно должна быть проверка, что покупатель редактирует СВОЮ корзину.
Для показа каталога товаров - отдельный пользователь, имеющий право только на SELECT из таблицы SHOP_PRODUCTS.
А продажу товара может делать отдельный пользователь, с правом только на UPDATE колонки AMOUNT в таблице SHOP_PRODUCTS. Пример:

GRANT SELECT ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';
GRANT UPDATE (AMOUNT) ON shopdb.SHOP_PRODUCTS TO 'trader_bot'@'shophost';

И т.п. По принципу "Разделяй и властвуй."
4. Писать запросы с использованием placeholder'ов (подстановку данных), что убережёт от SQL-инъекций.
Пример:

$DB->select('SELECT * FROM tbl WHERE a=? AND b=?', $a, $b);

5. Если и БД и приложение, используещее БД установлены на одном сервере - отключить удалённый доступ к БД и работать через сокеты.
6. Последний, но самый важный - БЕКАПЫ. При удалении всего и вся - нужно откуда-то восстановиться. Делайте бекапы и храните на отдельном сервере (не выставленном наружу).

Дискретная математика, Теория автоматов, Математическая логика, Теория вероятностей и математическая статистика, Теория алгоритмов, Моделирование, Защита компьютерной информации, Микропроцессорные системы, Сети ЭВМ, Операционные системы, Базы данных.

Мой круг же! https://moikrug.ru/

Такой вариант записи используют в JS, когда надо получить ключ или вызвать функцию с помощью переменной.
Это возможность самого языка, а не конструкция jquery.

var foo = {
  bar: 'bar value',
};

console.log(foo.bar);
// => bar value

console['log'](foo['bar']);
// => bar value

Разберем ваш пример. Такая запись:

var action = 'addClass';

$('.some-selector')[action]('some-class');

равносильна такой:
$('.some-selector').addClass('some-class');

То же самое для объекта:

var key = 'name';

var obj = {
  name: 'Tom',
  age: 24,
};

console.log(obj[key]);
// => Tom

console.log(obj.name);
// => Tom

console.log(obj[key] === obj.name);
// => true

key = 'age';

console.log(obj[key]);
// => 24

Так же есть случаи, когда к ключу можно обратиться только таким способом:

var obj = {
  'three words key': 'value',
};

console.log(obj['three words key']);

// => value

Естественно переделали, за 10 лет-то существования Python 3. Теперь идёт обратный процесс, с каждым днём всё меньше библиотек и фреймворков поддерживают 2.7.

Хрень какая-то.

def calculate_checksum(param):
    param.sort(reverse=True)

Встал вопрос - какой способ кэширования данных быстрее - MySQL с движком MEMORY, или же memcached?

Быстрее memcached, незначительно. Удобнее redis, значительно.

Это SPA на React с server side rendering. Приложение рендерится и получает данные на стороне сервера. При переключении поста, срабатывает роутер, рендерится нужный пост, а из интернета подтягиваются только картинки. Скорость node тут не причем. Такие SPA принято называть изоморфными.

Вам стоит внимательнее перечитать документацию Channels, под WSGI они не работают. Вам надо чем-нибудь, типа supervisord, запустить отдельно воркеры и отдельно ASGI-сервер Daphne. Nginx необходимо настроить на проброс запросов к Daphne. Кроме того, вам нужен какой-нибудь брокер очереди, например, Redis.

Paypal и Netflix используют Node.js. У обоих нагрузки очень даже приличные.
В плане масштабируемости думайте об архитектуре. Можно и на perl написать приложение, которое за секунду будет обслуживать миллион клиентов.
Node.js будет прекрасно работать в качестве движка для типичного веб-приложения вроде магазина, чата или CRM. Если у вас очень много компонентов, например тысячи, логичнее приложение разбить на модули и сделать вместо одного приложения несколько, которые можно запускать по-отдельности (здесь уместно упоминание микросервисной архитектуры). Разумеется запросы нужно распределять с помощью балансировщика.
Есть еще такая вот штука https://serverless.com/ - ее можно масштабировать практически до бесконечности. Были бы деньги.
Node.js будет плохо работать в области процессинга данных, например генерация картинок, потоковая обработка видео, нейронные сети и т.д. Здесь лидеры C, C++, Go, Rust, Java.
Можно даже создать гибридное приложение - большую часть выполнить на Node.js, а критичную по производительности на другом языке. Например генерация миллиона прайсов в сутки в старый xls или векторный pdf, упаковка в архив и рассылка - не самая лучшая идея для Node..JS. То же C++ здесь будет вне конкуренции.

Отвлекаюсь на все не могу себя заставить, нормально работать

Отключить все уведомления или выключить звук+вибро на телефоне.
Отключить все попапы в Windows, уведомления браузеров.
Отключить звук на компе.

Если помогает быстрая музыка — включить её (я фигачу под транс с di.fm).

Взять любой секундомер, поставить на нем таймер 10 минут. Уж 10 минут вы в состоянии выдержать?
После звонка таймера поставить новый на 15 минут. Это всего на 5 мин больше прошлого таймера.
После звонка таймера поставить новый на 25 минут. Это всего на 10 мин больше прошлого таймера.
Как вы поняли, это плавное привыкание к технике Помодоро=)

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

Прошло 50 минут. Теперь отдых. Выключить музыку, надо отдохнуть: ставите таймер на 10 минут, гуляете вокруг компа, смотрите в окно, делаете легкую зарядку, просто сидите с закрытыми глазами.

Телефон во время отдыха в руки не брать и почту /скайп (что там вы используйте) не проверять!! — Это ключевое. Отдых должен быть отдыхом. Умеете медитировать — медитируйте.

Ставите новый таймер на 50 минут. Один раз продержались, что, второй раз не сможете? Сможете.
После этого опять отдых, 10 минут.

После 3-4 циклов по 50работа/10отдых, делаете отдых 30/40/60 минут (как раз пообедать + проверить почту/телефон).

Потом новый комплект 3-4 цикла 50/10.
В конце дня можете проверить почту/телефон.

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

Также, если мотивация падает, говорим себе мантру: "Потерпи только сегодня, только один день. Пофиг, что там будет завтра, а вот сегодня надо потерпеть и сделать".

Для удобства на компе можно использовать любой тайм-трекер со встроенным Pomodoro, например Toggl (+могу еще насоветовать, знаю много трекеров)

UPD 1. Из другого ответа: "чтобы работать длинный промежуток времени, очень выручал https://www.forestapp.cc/"
Я протестировал приложение под Андроид и расширение для Хром и стал использовать: это отличное дополнение к методике, что тут описал, с автоматическим отключением всех внешних раздражителей. Рекомендую.

UPD 2. Классическая Помодорная схема — 4 цикла по 25работа/5отдых, потом отдых 20 мин.
Но она не подходит для работы "в потоке" — пока погружаешься в задачу, уже проходит 15 минут и остается всего 10 минут до отдыха на саму задачу, что мало.
Поэтому я использую циклы 50/10 для основных задач, +один цикл 50/10 в начале дня на планирование, почту и прочую мелочевку.

Да в общем-то никак: брю ставит пакеты глобально и ей в целом пофигу какие и где стоят питоны.
Что мешает в path прописать нужного змея?

А вообще уже давно придуманы такие ништяки как virtualenv, vagrant и прочие докеры, которые избавляют от подобных менингитов.

deprecated.

осуждение тут не при чем, просто эти методы объявлены устаревшими, соответственно
а) исчезнут в следующих версиях (языка, фреймворка, итд)
b) в них не исправляются ошибки.