Как-то в одной известной компании решили упразднить процесс под названием "код-ревью". Упразднили не на уровне компании, а на уровне отдела, но в итоге упразднили не процесс, а того самого менеджера (по офицальный версии причины были другие, но мы-то знаем). Процесс (код-ревью), как видно, полезный, если способен пережить одного менеджера, но видно, вопросы к нему имеются. Код-ревью представляет собой взаимодейсвие автора пулл реквеста и ревьюера, что-то типа игры с ненулевой суммой, где та самая сумма аккумулируется между участниками процесса.

Фикс критической ошибки (не архитектурной или по дизайну системы, а именно ошибки/баги) не добавляет профита ревьюеру. При удачной фиче похвала и бонус пойдут автору. То есть действия ревьюрера приносят ноль ему и что-то автору. Хотя ревьюер может не только помочь, но и навредить - заблочить пул реквест (и иногда действительно такое случается), бизнес невилирует отрицательные последствия - вмержат только в путь, когда бабло начнет течь мимо кассы. Не беря во внимание совесть ревьюера, получить максимальный профит можно на дейликах (ведь для этого утренние созвоны и нужны, так ведь?) - аккурат перед мержем пулл реквеста упомянуть о критической неисправности.

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

Наибольший кайф античных книг в их выдержке, актуальности. Книги точно проверены временем, актуальны (правда если знаешь в чем) и как ни странно, честны (книги хотели бы, чтобы их читали через сотню или тысячу лет). В программировании античные скрипты, наверно, написал Деннис Ритчи, сегодня же почитаем современников - Sean Parent (довольно известный чел в c++ тусовке) начал писать на расте (возможно, как начал так и закончил, но мы живем в моменте - поэтому предлагаю насладиться). Читать на расте сложнее, чем писать (это прям факт) - пишут его двое (автор и компилятор), а читают, ну читают на гитхабе. Далее в прозаическом сочинении свободной композиции, подразумевающем впечатления и соображения автора по конкретному поводу или предмету, рассмотрим компоненты новой библиотеки и попробуем насладиться примерами кода.

Раст хорош, все это знают. Инвестируешь время в язык программирования, кайфуешь, работаешь c рисками, задаешься вопросом - а может, раст еще круче? Почему бы, например, не изучить солидный проект на плюсах (5k звезд на гитхабе) - и мигрировать его. Вроде, все так делают, но может, суть в миграции идей, а не кода. Быть может, мы найдем ответы о выразительности языка, читаемости и скорости программы. Возможно, нам станет ясно - а друг ли наш компилятор, но скорее всего, мы насладимся эстетикой процесса проектирования приложения на растe.

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

Лет так много назад, если верить слухам того времени, питон был не зыбко популярен, flask был где-то в узких кругах, а за django продавцам нужно было замолвить слово. Все, конечно, понимали - за django будущее, и не только потому, что java всем поднадоела, но потому что было удобно и для бизнеса, и для кодинга. Что кривить, читая книгу zero2prod невольно вспоминаешь удовольствие от изучения django, удивления - "а что, так можно было", и пожалуй, глубину проработки деталей, которые обычный разработчик осилил бы самостоятельно, но обычно было лень.

Rust при всей своей скромности по скорости весьма удобен для day to day разработки, и книга (которая в тайтле) раскрывает детали этой парадоксальной особенности.

Как известно, html-разработчики скучают по многопоточке. Читая на днях шикарную книгу Mara Bos oб "атомиках и локах", наткнулся на упоминание одного интересного языка программирования: rust lang. Согласно интернетам, learning curve раста стремится к бесконечности, но для многопоточного программирования выбор кажется нормуль. Тут вопрос - можно и, главное, удобно ли юзать раст для бизнес-логики (ну то есть для продакшна).

Краткое содержание: макросы, компилятор-враг, компилятор-друг, unsafe и miri, многопоточка, options, iters, match.

Будем честны, фичи тестировались на учебном проекте, но как бывает со всеми пет прожектами (учебными проектами), переписывались они десятки раз.

Где-то в Европе. Цель игры: из пункта А попасть в пункт Б и затем вернуться в пункт А.

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

Иногда хочется решить задачу просто потому что решение легко проверить, прям сразу для множество вариантов. Взяли список из 25 элементов, отсортировали его, и применили искомую функцию 25 раз, профит. Плюс задачка напоминает обложку тетрадки по арифметике за пятый класс, там где табличка произведений, ну та где находим пятый столбец и седьмой ряд и на пересечений их будет произведение. Там же в табличке видно что 6x6 - это квадрат, а 9x4 это совсем не квадрат (скорее ближе к прямоугольнику) хотя площадь у них равная. Так вот, "литкод" хочет чтобы мы нашли n-ый элемент в данной табличке по возрастанию.

Коллеги со стороны бакэнда иногда любезно спрашивают: "а нафига вам тут реакт"? Будем честны и ответим, что без него можно написать довольно приличный код, отдать его на ревью коллеге-фулстеку и получить аппрув после 15 секунд (так быстро не потому, что коллега не беспокоится за качество кода, а просто код весьма компактен, cмотрите ниже). Если подумать чуть-чуть дольше (например, за время заварки чая, которое, как все знают, равно трем минутам), можно найти не менее шести ошибок, а может и больше. Любая ошибка, конечно, весьма субъективна, но я постараюсь объективно объяснить каждую из них.

В 2002 году Алекс А. Степанов проводит лекцию в адоби: STL and Its Design Principles - где упоминает кейворд concept (там прям целый слайд про концепты). В 2009 году в свет выходит книга Elements of programming (Stepanov, McJones) и где по-моему нет ни одного алгоритма без концептов. В 2011 новый стандарт языка с++11, где в отложенных (прям очень жаль) фичах фигурируют концепты. В 2014 мир видит творенье Страуструпа - Tour of C++, где глава 5.4 названа Concepts and Generic Programming, хотя язык не поддерживает кейворд concept. Годом ранее, в 2013, Андрю Саттон публикует бумагу Concepts Lite. В стандарте с++14 появляется новая фича digit separators, но нет концептов. В 2017 на реддите обсуждают c++17 и предлагают отдохнуть еще три года.

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

// index.jsx

<History>
  <Observer>
     <HeaderView />
     <MainView />
  </Observer>
</History>

Если вбить в яндекс 'aes 128 ecb mode', найдутся хорошие статьи ребят на "хабре": раз и два — толковые и одновременно слишком подробные.

Рассказ об алгоритме в картинках находится здесь (который также можно найти по ссылкам в одной из статей ребят выше).

Кратко об алгоритме: 1) создаем объект с 16-байтным state и массивом 16-байтных ключей; 2) пишем примитивы для объекта (они же трансформации); 3) запускаем n раз (где n — кол-во раундов). Все трансформации делаем симметричными — для зашифровки и расшифровки одновременно. Расшифровка в терминах алгоритма — это зашифровка наоборот.

Структура:

using byte_t = unsigned char;
struct aes128 {
  aes128(const std::string& text, const std::string& cipher, bool decrypt = false)
    : state({begin(text), end(text)}), keys({{begin(cipher), end(cipher)}}), decrypt(decrypt) {}
  aes128() = default;
  aes128(const aes128&) = default;

  std::vector<byte_t> state;
  std::vector<std::vector<byte_t>> keys;
  bool decrypt;
}