Приглашаю вас в небольшое приключение выходного дня, в котором никто никому ничего не будет доказывать. Мы просто будем реализовывать один и тот же несложный алгоритм, разыскивающий простые числа в некотором диапазоне, на нескольких языках программирования: C, C++, Scheme и Python - и смотреть, что этим кодом могут сделать современные оптимизирующие компиляторы. В процессе приключения мы увидим, что «динамический» не означает «совсем уж медленный», и посмотрим на приёмы программирования на Scheme, что, как мне кажется, можно сравнить с путешествием на экзотический остров.

Очень часто встречаю, что люди путают разные типы хэшей и думают, что NTLM и NTLMv1/v2 это одно и тоже, а NTLMv1/v2 и Net-NTLMv1/v2 разные типы. Данная статья заметка предназначена для того, что бы разобраться со всем этим.

Всем привет! Меня зовут Антон, я системный архитектор отдела разработки курьерских сервисов в Почтатехе. Мы разрабатываем сложные цифровые продукты Почты России. Помогаем ей стать удобнее, быстрее, качественнее и технологичнее для вас. 

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

Прежде, чем стать системным архитектором, я успел побывать разработчиком и тимлидом. И моя работа всегда была неразрывно связана с людьми, технологиями и процессами. В этой статье я хочу рассказать, как благодаря оптимизации процессов мы ускорили time-to-market для IT-систем нашего отдела.

Артем Мурадов — Senior Software Development Engineer в Amazon и автор курса «Алгоритмы: roadmap для работы и собеседований». Уже больше 14 лет он использует алгоритмы для решения рабочих задач и прохождения собеседований. С помощью алгоритмов он повышал производительность приложений, побеждал в спорах с коллегами и ускорял исследование ДНК. Даже попасть в Amazon ему помогло знание алгоритмов.

Мы пообщались с Артемом, чтобы узнать о его опыте. Он подробно рассказал, как изучал алгоритмы и как они помогали ему в работе.  

Альтернативный заголовок: "В любой непонятной ситуации возвращай Out of memory".

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

Error when parsing "example_proj.xml": 1:0 out of memory

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

Итак. Out of memory? На XML в 50 строчек? Сказать, что я был ошарашен - это не сказать ничего. "Но ведь раньше всё работало".

Я люблю критику. Если вы не заметили, я, как старый дед, всё поливаю грязью и всем недоволен.

Забавно, но в то же время я люблю, когда критикуют меня самого, потому что именно в такие моменты я что-то начинаю понимать, развиваюсь и становлюсь лучше. А в этой статье я решил совместить приятное с забавным и рассказать вам о своих самых идиотских решениях и самых эпичных провалах за свою карьеру программиста - такая вот само-критика. Возможно, кто-то узнает себя, а если нет, то я просто прошу вас: не делайте так же, как делал я.

Пока все кому не лень пишут статьи о том, как войти в айти, некоторые из нас нет-нет, да задумываются, а не выйти ли оттуда. Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни? А вдруг там, за дверью серверной или опенспейса R&D, всё по-другому? 

Язык Си - один из наиболее влиятельных языков программирования за всю историю. Он стал незаменимым инструментом разработки операционных систем, сместив с этого пьедестала языки ассемблера. Изучение Си обязательно для любого уважающего себя программиста. Этот язык любим за свою внешнюю простоту и ненавидим за беспощадность к ошибкам. Благодаря нему у нас есть ядро Linux и тысячи уязвимостей в нём же в придачу.

Попробуем понять, что же такое этот противоречивый язык Си - благословение или проклятие?

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

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

Чтобы понять безопасность, надо думать как безопасник, вести себя как безопасник, стать безопасником. Барух jbaruch Садогурский и Леонид Игольник в своих докладах много рассматривали DevOps с разных сторон — и очередь дошла до вопросов Security. На нашей конференции DevOops они поговорили об этом, и поскольку зрителям понравилось, теперь мы сделали текстовую версию доклада.

Как и в «предыдущих сериях», оформлено всё в формате приключений Васи с Омского мясокомбината. Теперь новый Chief Information Security Officer ставит Васе новые задачи, создает новые заботы и новые проблемы. Или, может быть, проблемы были и раньше, просто теперь они стали более заметны? Понимание мира, в котором живет CISO, поможет Васе и вам вместе с ним понять, какие проблемы безопасности стоят перед современной DevOps-организацией и как решить эти проблемы, не выкапывая новые колодцы и не создавая новые барьеры.

Под катом делимся и текстовой версией доклада, и видеозаписью. Экспертом на докладе выступил консультант по информационной безопасности Денис Якимов.

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

Большинство предложений разбивались о какие-то специфические особенности Хабра и ситуации, которые изначально не брались в расчёт. Иногда присутствовало здоровое зерно логики. Встречались и чрезмерно сложные фантазии. Мы читали каждый такой пост и комментарии к нему, мотали на ус, делали какие-то расчёты, но всё же не спешили вносить изменения. В функцию, которая может и не идеально, но всё же 15 лет проработала основой пользовательской регуляции.

Но сегодня мы анонсируем два изменения в механизме кармы.

Немалое количество простых кнопочных телефонов, присутствующих в российских магазинах, содержат нежелательные недокументированные функции. Они могут совершать автоматическую отправку СМС-сообщений или выходить в интернет для передачи факта покупки и использования телефона (передавая IMEI телефона и IMSI SIM-карт). Встречаются модели со встроенным трояном, отправляющим платные СМС-сообщения на короткие номера, текст которого загружается с сервера, также бывают устройства с настоящим бэкдором, пересылающим входящие СМС-сообщения на сервер злоумышленников.
Статья описывает детали вредоносных функций и способы их обнаружения.

Пару лет назад, в разговоре с кем-то промелькнула примерно такая фраза: "Мы используем In-Memory OLTP - это очень быстро, зачастую даже вместо временных таблиц создаём In-Memory и всем советуем". Спустя какое-то время, мне задали вопрос как можно держать одну таблицу в памяти, чтобы работать с ней максимально быстро. Выяснив подробности - небольшая таблица, данные должны храниться только за последние несколько минут, суммарно не больше 10000 записей "приемлемых" (не LOB) типов данных, потеря данных при перезагрузке/файловере не страшна и даже приветствуется. In-Memory OLTP, без тени сомнения ответил я.

Перед запуском в продакшн я излазил всю документацию, проводил свои тесты - просто огонь. Работает реально быстро, таблица SCHEMA_ONLY и IO не генерирует вообще (я же умный, смотрю sys.dm_io_virtual_file_statss до и после). С обращениями через natively compiled stored procedures - не просто быстро работает, летает. Одним словом мечта.

Правда, оказалось, что у моей мечты есть тёмная сторона.

Сегодня от имени команды Rust Core я рада объявить о Rust Foundation — новой независимой некоммерческой организации, управляющей языком программирования Rust и его экосистемой, которая исключительно ориентирована на поддержку всех сопроводителей — тех, кто создаёт проекты и управляет ими. Первое совещание Rust Foundation состоится завтра, 9 февраля, в 16:00 СТ (22:00 UTC+3). Совет директоров состоит из 5 директоров из компаний-учредителей: AWS, Huawei, Google, Microsoft и Mozilla, и 5 директоров из управления проектом. Двое из них — представители Core Team (Основной команды), трое — разных частей проекта: Reliability (Надёжности), Quality (Качества) и Collaboration (Взаимодействия).

Зрелый язык может использоваться немногими. Но он остаётся частью моей кодовой базы.

Как давнего пользователя (и активного сторонника) Scheme/Common Lisp/Racket, меня иногда спрашивают, почему я предпочитаю их. К счастью, я всегда возглавлял собственные инженерные организации, поэтому мне никогда не приходилось оправдывать это перед руководством. Но есть еще более важная аудитория - мои собственные коллеги-инженеры, которые никогда не имели удовольствия использовать эти языки. Хотя им не требуются оправдания, они все же спрашивают из интеллектуального любопытства, а иногда и из-за удивления, почему я не схожу с ума по поводу следующей крутой функции, которая будет в этом месяце добавлена в Python или Scala, или что бы там ни было в их вкусе.

Вновь улучшаем Ansible, и снова лезем в исходники.

(Хабр-Статья представляет собой авторский перевод доклада, представленного автором на Scheme Workshop 2020, проводившегося в рамках Международной Конференции по Функциональному Программированию, 28 августа 2020 года)

Эта статья -- своего рода "отчёт" по самому большому проекту, который я сделал в своей жизни по собственной инициативе. Я сделал полное, исчерпывающее решение всех задач из одной из самых извесных книг по программированию в мире "Структура и Интерпретация Компьютерных Программ" (Structure and Interpretation of Computer Programs -- SICP), за авторством Абельсона, Сассмана и Сассман.

В ходе выполнения проекте я собрал довольно много данных о том, как решалось это задание в частности, и сформулировал несколько эвристик, помогающих выполнять проекты вообще, а именно:

Четыре года назад мы, инженеры, закаленные в боях с аэродинамикой и прочностью, показали всему миру наше детище – махолет «Рарок». Это было здорово - пришлось оправдываться, разъяснять, рассказывать и даже просить денег на «Boomstarter» дабы продолжить развитие нашего дела. Убив на это уйму времени и сил, мы все же решили не останавливаться на достигнутом, а продолжить развитие любимой темы. Эта статья о том, чего удалось добиться за прошедшие три с половиной года и чего мы хотим.

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

Позвали Григория Петрова, DevRel’а Evrone.com (ex. Voximplant, Radmin, Digital October Center) и вдохновителя сообщества Moscow Python, рассказать, как писать хороший код самому и научить команду. А еще обсудили, как понять, какие механизмы нас тормозят, и как посмотреть на нейрофизиологию через призму прикладной разработки и руководства технической командой. Разговор оказался настолько интересным, что сделали статью по его следам.

Наш гость сам себя называет генералистом. Пишет на большинстве мейнстримовых языков разработки, кроме Haskell, и интересуется нейрофизиологией. В какой-то момент он посмотрел на свой предыдущий опыт работы и понял, что ему нравится писать документацию, объяснять сложные вещи простым языком и общаться с разработчиками, но не руководить. Поэтому позиция DevRel (Developer Relations) оказалась для него оптимальной.

На Хабре ввели новый WYSIWYG-редактор постов, а старый позже отключат. Идея в том, чтобы пользователям не требовалось иметь дела с HTML-тегами, и публиковать записи свободно мог любой не-айтишник. Но вот вопрос: не доставит ли это неудобств айтишникам?

Я ничего не имею против HTML-тегов. А вот возню с мышкой не люблю, предпочитая клавиатуру. И, попользовавшись новым редактором, ощутил, что мне стало неудобнее. В его текущем виде он не рассчитан на таких людей, как я.

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