Иван Зубов posthedgehog

Есть такая очень старая и вросшая в *nix с корнями штука под названием «сигналы». Идея этих примитивов очень проста: реализовать программный аналог прерываний. Различные процессы могут посылать сигналы друг другу и самим себе, зная process id (pid) получателя. Процесс-получатель волен либо назначить функцию-обработчик сигнала, которая будет автоматически вызываться при его получении, либо игнорировать его с помощью специальной маски, либо же довериться поведению по умолчанию. So far so good.

Поведение по умолчанию при получении сигнала… А что означают эти успокаивающие слова? Уверен, не то, что вы ожидали. Вики говорит, что обработчики 28 стандартных сигналов (существуют и другие!) по умолчанию таковы: 2 игнорируются, 4 вызывают остановку процесса, 1 – его продолжение, 11 – его завершение, 10 – его завершение с созданием дампа памяти. Вот это уже интересно! Итак, дело обстоит следующим образом: даже если ваша программа никак не упоминает сигналы в исходном коде, на самом деле она их использует, причём весьма драматичным образом.

Пароли — древнейший способ аутентификации в информационных технологиях, повсеместно использующийся и сегодня. Увы, просто невозможно держать в памяти пароли для всех Интернет-ресурсов при условии, что все они будут разными и сложными! Тут на помощь человеку приходят менеджеры паролей, берущие эту задачу на себя: человек запоминает всего лишь один мастер-пароль, дающий доступ ко всем остальным.

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

Когда-то давно я мечтал стать специалистом по информационной безопасности и усердно ковырял разные веб-сайты на предмет уязвимостей. Моей самой большой победой стало нахождение уязвимости в платёжной системе QIWI, за которую добрые разработчики отсыпали мне 200 долларов. В итоге обнаруженная проблема была решена лишь спустя 3.5 года после жалобы, и после этого о ней стало можно поведать Вселенной. Забавный момент заключается в том, что я обнаружил эту уязвимость совершенно случайно, и на моём месте запросто мог быть ты.

Я считаю, что разработка ПО в значительной степени заключается в программировании на псевдокоде. Если ты представил псевдокод, то перевести его на Python, C, что угодно — не проблема. Основная сложность заключается вот в этой концептуальной деятельности, а не в кодировании. Нужно знать, как подходить к тем или иным вопросам. Модульность, абстракция. Гибкость, надёжность, простота. Шаблоны проектирования. Юнит-тестирование. Ю ноу.

Есть на свете курс «Структура и Интерпретация Компьютерных Программ» (далее СИКП), который позиционируется как введение в Computer Science и ранее использовался в MIT для обучения первокурсников. Два года назад я с удовольствием одолел курс лекций по нему и взялся за книгу.