Посмотрим на свежую статью по сравнению брокеров сообщений — систем, реализующих шаблон издатель-подписчик (pub/sub, publisher-subscriber). Шаблон позволяет реализовать асинхронную обработку сообщений с множественными писателями и читателями. Например, загрузка видео на youtube требует его переконвертацию под множество размеров (144p, 240p и так далее). Такое поведение можно реализовать на брокере сообщений — вкинули пул заданий на преобразование, и эти задания будут обрабатывать те сервера, которые сейчас свободны. Полученную схему можно относительно легко масштабировать, добавляя новые узлы-обработчики или сервисы-загрузчики новых видео.

Статья A Fair Comparison of Message Queuing Systems сравнивает Kafka, RabbitMQ, RocketMQ, ActiveMQ и Pulsar. Статья является отличным примером правильного сравнительного анализа. Дан обширный ввод в предметную область. Обзор публикаций маловат, но это единственный недочёт. Далее выдвинуты обоснованные критерии сравнения, разделённые на блоки: особенности (язык, сообщество, протоколы, ...), качество обслуживания (надёжность, масштабируемость, ...), производительность (задержки и пропускная способность). Для каждого из критериев написан абзац текста с описанием и обоснованием важности. Ранее мы критиковали статью с хабра за невнятные критерии. Теперь у нас есть отличный пример правильной формулировки критериев сравнения. Следом идёт сжатое описание каждой из сравниваемых систем, по каждой сформулированы плюсы и минусы.

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

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

#sudo #edu #devfm

Пятничное развлекательное. По пятницам у нас культурный код и прочий отдых.

В фильме Джонни Мнемоник (1995) с молодым Киану Ривз люди используются как большие флешки. Целых 80 гигабайт на человека, фантастически много по тем временам. Тогда HDD, кажется, больше 2 Гб физически не существовало. Для масштаба - GTA 1 вышла в 1997 году и требовала 80 мегабайт места на диске. И 16 мегабайт оперативной памяти, уууу. Mortal kombat 3 требовал 19 мегабайт на жёстком диске в 1995 году.

Нельзя не вспомнить Пароль «Рыба-меч» (2001). Молодой Хью Джекман в сцене хакинга сайта Пентагона за 60 секунд чудесен. Вообще антураж вокруг разработчиков был куда более атмосферным. Сейчас любой может на hackertyper почувствовать себя хакером, попробуйте и вы. И не забудьте трижды alt, господа.

Завершает сегодняшнюю подборку хакерских фильмов Социальная сеть (2010), картина о становлении Цукерберга и Facebook. Сайт голосования за лучшую девушку является крутым примером простой, но очень интересной идеи для pet-проекта.

#fun #films

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

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

Код быстро становится "чужим". Вернувшись в старый проект, часто только по git blame можно понять, кто писал тот или иной фрагмент. А без readme совершенно невозможно вспомнить, как это всё великолепие запустить.

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

По мотивам беседы с Умпутуном в чате подкаста radio-T

#procode #devfm

Рассмотрим простой фрагмент кода. Сохраняем список всех файлов и каталогов для "empty_dir" в переменную, потом проверяем, есть ли там что-то. Если что-то есть, то выводим список содержимого. Вроде всё корректно, но статический анализатор pylint даст вам по рукам с ошибкой

Do not use len(SEQUENCE) to determine if a sequence is empty (len-as-condition)

Достаточно непонятно написано. На самом деле, от вас требуется конструкция

if files:

Без всяких len. Потому что bool от сущности с нулевой длиной будет False. Такие дела.

#python #codereview

В статье Анатомия GNU/Linux (хабр, 2020) просто и понятно описываются такие составляющие операционной системы, как
— загрузчик
— ядро
— начальный образ загрузки
— init
— командная оболочка
— графический сервер
— дисплейный менеджер
— окружение рабочего стола

И всякое разное другое. На картинке представлена схема взаимосвязи упомянутых в статье сущностей

#skills

Нормальный ли у меня код?

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

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

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

Быстрый по скорости и компактный по данным. Другими словами, код должен быть нормальной вычислительной и пространственной сложности. Тут помогают и интуитивные представления (что-то тормозит), и теория вычислительной сложности (О-нотация). Если вы сортируете записи за O(n^3) и требуете O(n^5) оперативной памяти, то вы делаете что-то не так.

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

Если, конечно, не горят сроки

#procode #devfm

Переснят звук для видео про forkbomb (16 минут).

Есть такой вид DoS-атаки — forkbomb. Запускается процесс, который бесконечно порождает сам себя, пожирая все ресурсы системы. На видео запускается forkbomb внутри docker-контейнера с разными ограничениями (оперативная память, PID-лимиты, cpu). Демонстрируется, что можно сделать в таком контейнере. Показывается применение команд:

— docker run / exec / stop / stats
— lscpu / nproc
— uptime
— free
— top / ps

Будьте осторожны. Неаккуратное обращение с forkbomb чревато ребутом.

#youtube #skills #devfm

Пятничное развлекательное. Сегодня буковки.

На хабре есть очень крутой автор — Milfgard. Он создал Мосигру и возродил популярность настольных игр в РФ. Занимался много чем, в том числе организацией детских футбольных школ. Сейчас он руководитель в туту.ру и много путешествует.

От души обожаю каждую его статью. Сохраняю их в закладки как "юмор - мотивационное". Milfgard в статьях
— ходит по магазинам,
— разбирает бобров,
— изучает уязвимости в прошивках австралийских животных,
— пишет про образование и системное отличие бессмертной Галадриэль и весьма смертного Арагорна,
— рассказывает про защиту детей от информации на примерах,
— из камер и палок собирает видеоаналитику для детских футбольных школ,
— рассказывает про историю Британской Ост-индской компании,
— про социнжинеринг,
— и кассовые разрывы в бизнесе.

В конце концов, он соавтор трёх книг по бизнесу, которые я очень люблю перечитывать.

А для настроения вам видео — мягкий тетрис. Немного нервирует, но очень расслабляет в результате

#fun #books

Ранее мы писали, что логгирование значительно лучше отладочной печати принтами.

Вверху сконфигурируем логгер. В fmt внесём структуру записи в лог, в datefmt — формат даты, в style — тип переменных в fmt, у нас выбран format-вид в фигурных скобках.

На 10 строке показан вариант ручной настройки уровня логгера, на 11 уровень берётся из переменной окружения LOGLEVEL, если переменная не существует — то уровень INFO.

В функции add_user мы с уровнем debug пишем какие-то несущественные сообщения, с уровнем info — важные этапы работы, в error пишем ошибки, например, в случае исключений.

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

#python #codereview

Bash отлично подходит для работы с сервером, он неплох для маленькой автоматизации и вообще must-have для изучения. Bash всегда под рукой и приветливо подмигивает тебе своим $. Он позволяет на кончиках пальцев творить великую магию, организуя простые команды в сложные конвейеры для достижения цели. Позже мы разберём фрагменты bash, полезные в хозяйстве.

Но упаси вас Линукс пытаться на bash писать что-то сложное. Как человек, разработавший большую систему (~3к строк) на bash, никому не могу советовать повторять столь неприятный опыт.

В статье Подводные камни Bash (2016, оригинал) вам подробнейшим образом расскажут, почему не надо туда лезть и оно тебя сожрёт.
#skills

Анализируем размер проекта

Среди метрик качества проекта теоретики выделяют число LOC == lines of code, измеряемое обычно в тысячах.

Для измерения размера проекта в строках кода есть интересный проект cloc, запускаемый в том числе в docker.

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

А теперь интересное. LOC является очень противоречивой метрикой для контроля. С одной стороны, чем меньше проект, тем лучше. С другой — сокращение размера кода может вредить его читаемости.
#skills #devfm

Рассмотрим такой код. С помощью requests для заданного логина идём на gitlab.com и проверяем, что вернёт страничка пользователя. Если 200, то пользователь есть и возвращаем True. Если не 200, то пользователя нет или что-то сломалось.

Как это безобразие протестировать? Наш ответ в 22:00 по МСК

#python #codereview

Все варианты верны в той или иной степень. Тестировать код со внешними зависимостями действительно неприятно. Можно зафиксировать конкретные имена, что будет довольно грязно. Можно решить вопрос с помощью dependency injection и передать в функцию объект-requests, который умеет опрашивать сервер или имитировать подобное поведение.

Мы же воспользуемся заглушкой (Mock). Это механизм динамической замены функций/классов.

Создаём класс RequestsMock. Всё что он делает — это сохраняет переданный ему status_code.

Делаем with patch, и в этом блоке указанная функция (requests.get) будет подменена на подменный класс. Параметр side_effect многогранен, в нашем случае мы подаём туда список из объектов, и при каждом вызове requests.get будет возвращён очередной экземпляр из этого списка.

Теперь вместо реальной работы с сетью мы используем полностью контролируемое окружение. Можем так json-ы сервера подменять, например.

#python #codereview

Английский — основа силы в программировании.

Как бы кому ни хотелось, но без английского невозможно быть в курсе современной тусовки. Топовые материалы, будь то книги, статьи или видео, выходят преимущественно на английском. Эти же материалы появляются на русском с большим запозданием. Изредка запоздание в год-полтора, для других материалов это 3-5 лет. Для многих материалов русскоязычная версия не появляется никогда.

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

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

ps: судя по крутым репозиториям с нейронными сетями на китайском есть вероятность, что когда-нибудь лидер может смениться. Но сомнительно.
#edu

Как я научился воспринимать английский на слух

Давным давно, в районе 2012 года на площадке Udacity был такой крутой курс Introduction to Computer Science с Dave Evans по построению своего web crawler, то есть такой основы для поискового движка на питоне. Там было 7 огромных глав, в каждой много небольших видео, текстовый материал, вопросы и фрагмент кода для реализации, а в конце — непростой экзамен в виде "запрограммируй по ТЗ". К сожалению, сейчас курс заменили на очень маленький и совершенно невнятный.

Нашёл на ютубе одно из видео курса. Самой ценной для меня частью курса было введение в computer science на английском от человека с хорошей дикцией, рисующего понятные иллюстрации. Почти весь этот материал я уже знал на русском — там было и про основы циклов, и про устройство компа, и про историю жёсткого диска, и про устройство поисковой машины. В процессе я избегал субтитров, чтобы слушать, а не читать.

Такой повтор материала оказался для меня той соломинкой, что переломила спину ослу. После этого курса я смог различать на слух английскую речь. Закрепил понимание английской речи я просмотром любимого сериала House M.D, мультфильмов Футурама и Южный парк.

С тех пор я просмотрел огромное количество материала на английском языке, чего и вам советую. Только вот японский акцент мне никак не даётся, совершенно не могу воспринимать некоторых их представителей.

ps: нашёл у автора страницу этого курса! Там есть ссылка на все PDF и youtube-плейлист. К сожалению, без опросов и интерактивного кодирования всё это не так круто. Да и материал устарел, 10 лет прошло.
#edu