Вот так да! Любопытно будет посмотреть.

Backdoor длиною в два года

Для тех кто пропустил детективную новость – бекдор в пакете архиватора XZ Utils, который повсеместно используется в Linux. Уязвимость предоставляет возможность выполнить произвольный код по SSH, не оставляя следов в логах sshd.

Всё началось в октябре 2021, когда некто под ником JiaT75 начал активно участвовать в развитии XZ, делать пул реквесты. Разумеется, мейнтенером проекта он не был. Через некоторое время появилось ещё два персонажа Jigar Kumar и Dennis Ens, которые также начали контрибьютить в проект. Через какое-то время в переписках они начали аккуратно давить на мейнтейнера проекта, что как будто он не справляется с нагрузкой, не успевает вовремя ревьюить пулл реквесты и что хорошо бы сделать JiaT75 ещё одним мейнтейнером. Так оно и случилось, JiaT75 стал мейнтейнером проекта XZ, а через некоторое время внедрил в него бекдор.

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

Вскрылось всё это случайно. Один ну очень внимательный разработчик заметил, что XZ стало поджирать больше cpu, чем обычно. Он начал разбираться и обнаружил вредоносный код.

Такая невероятная история. Обязательно почитайте. Страшно представить, сколько подобных бекдоров мы ещё не знаем…

Больше деталей на opennet, в том числе разбор логики бекдора. Интересные детали ещё в канале Авва.

#security

The ultimate docker compose cheat sheet

Хорошая статья, охватывающая основные аспекты docker compose. Автор начинает с базовых концепций, но будет полезна даже тем, кто хорошо знаком с компоузом.

Из интересного:
– параметр, позволяющий рестартить сервис, если он завалился
– как одному сервису дождаться запуска другого сервиса с использованием определенных условий. Бывает полезно, когда веб-сервис дожидается старта базы данных
– как задавать healthcheck сервисов с различными параметрами
– также автор разжёвывает тему volumes и networks

У нас был отдельный пост с практическими советами по докеру.

#skills #docker

Ну это просто прекраснейшая аналогия, теперь всем буду так объяснять

Прекрасное из недавнего диалога:

— Наша архитектура — микросервисный монолит!

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

Зеркало Dockerhub

Сейчас пользователь из РФ при использовании докерхаба получает такое сообщение

403 Forbidden
Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria.

Это либо техническая ошибка, либо РФ добавят в список стран.

Самая простая инструкция по настройке прокси тут
https://huecker.io/

Нюанс в том, что прокси надо доверять. В противном случае вы можете получить совсем не тот образ, что планируете. Адекватно использовать крупную площадку вроде зеркала Гугла
https://mirror.gcr.io

#tools

Пятничное развлекательное

Нестареющая классика. Так и живем. Лишние телодвижения ни к чему😃

#fun

Настраиваем терминал "под себя"

В нашем бесплатном курсе cli-for-dev на степике вышло новое занятие. Переменные окружения, конфиги, дикие алиасы. Практика с настоящим терминатором! Удобный Ctrl+R и тонны хоткеев, всё как вы любите.

У нас 950 учащихся, 180 дошли до пятого занятия и оставили 30 отзывов. Теперь доступно шестое занятие. Будем рады вашим отзывам на степике.

#devfm #skills

Оценка сроков проекта для тимлида

Как узнать у разработчика сроки решения задачи? Ну, никак. Он вам будет врать.

Если вы всё ещё хотите узнать сроки, то придется попотеть:
1. Спрашиваете сроки. Вам говорят некую величину R.
2. Если R <= 16 рабочих часов, то реальное время выполнения проекта составит примерно R умножить на π, то есть ~3,14R. Почему умножаем на Пи? Во-первых, это красиво. Во-вторых, тройного запаса обычно хватает.
3. Если R > 16 часов, то задача слишком большая и разработчик дал рандомный срок. В этом случае срок можно рассчитать как R×π + 2 недели. Почему умножаем на Пи? Потому что это красиво. Почему добавляем 2 недели? Потому что за 2 недели можно сделать что угодно...

И полученную цифру надо отсчитывать от момента начала работы над задачей, а не от сегодня. Как узнать, когда разработчик приступит к задаче? Ну, никак...

Ответ на пост Трудоемкость != сроки

#edu #teamwork

Подкаст DevFM: Кто такой тимлид тимлидов (yandex / youtube / podster)

Второй подкаст посвящён нашему опыту росту разработчика от тимлида проекта до руководства разработкой десятка проектов, над которыми трудятся больше сотни человек.

Обсуждаем рабочий день, проблемы интераптов и санитайзинг рабочего времени. Удачные практики и инструменты по организации эффективной работы.

Что изменилось на новой должности? Нюансы потери детализации над проектом. Нужны ли KPI?

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

Наш первый подкаст

#devfm #podcast #teamwork

Dozer

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

Давно пользуюсь такой простой утилиткой, как Dozer. Очень удобно, очень нативно можно скрыть все, что вам мешает.

#tools

Книга "Getting Real"

Долго откладывал эту книжку, а потом каааак прочел на одном дыхании.

Книга описывает философию и подходы к разработке и управлению проектами.

Основные идеи книги включают:
– Простота: Сосредоточьтесь на том, что действительно важно, и избегайте усложнения проекта ненужными функциями.
– Гибкость: Будьте готовы к изменениям и адаптации на ходу.
– Реализация идей: Начинайте с реализации основных функций и постоянно совершенствуйте продукт на основе обратной связи от пользователей.
– Минимализм: Создавайте минимально жизнеспособный продукт (MVP), чтобы быстрее получить обратную связь и внести необходимые улучшения.

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

Особенно полезно будет для стартапов и небольших команд. Но ребятам из кровавого энтерпрайза тоже может оказаться интересным – узнать как оно бывает быстро и динамично.

#edu #books

Книга "Релевантный поиск"

Недавно моему хорошему коллеге пришлось с нуля разботывать работу с elasticsearch. Статей для глубокого погружения не хватало и он взялся основательно за книгу.

И вот что он рассказал о книге:
Книга знакомит с понятиями релевантности, текстового анализа, ранжирования. Подробно рассказывает о разных хитрых особенностях.

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

Отдельно рассказали как эксплейнить запросы и какие механизмы есть под капотом, которые оценивают релевантность в соответствии с введенным запросом.

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

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

#skills #books

Говоря о поисковых движках, мы писали о том, как затаскивали Manticore Search на проект. Начиналось всё очень даже позитивно. Нам нужен был разухабистый поиск по понятным, но сложным правилам.

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

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

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

#skills #database

Список матюков

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

И мы узнали, что, оказывается, самые разнообразные матюки можно найти в Steam.

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

Для особо пытливых другие языки можно найти в Windows в Steam, в папочке resource.

#edu

Оптимизатор join в PostgreSQL

Тема из разряда: вон оно как бывает в Postgres. Ну, или, может, об этом все знают, а я один такой тёмный.

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

Но бывают случаи, когда нужно сделать большое количество джоинов. Например, когда подбиваем какой-нибудь отчёт.

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

Число, после которого оптимизатор сдаётся и ничего не делает, задается параметром join_collapse_limit. С ним можно поэкспериментировать с помощью SET join_collapse_limit и посмотреть, как будет меняться время работы EXPLAIN запроса.

В тему нюансов работы с Postgres у нас был пост, чем отличаются: char, varchar, и text и какие бывают нежданчики в json-полях.

#database

Как управляться с телефонными номерами

Существует миллион способов записать номер телефона. Скобочки, пробелы, тире, плюсики и дальше по списку.

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

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

#skills

🚀 Автор @sberlogabig приглашает Вас в неформальный проект.

Минимальные требования – навыки Python или хорошие знания теории групп (в идеале GAP, SAGE). Загрузка несколько часов в неделю. Задача проекта – применить машинное обучение к теории групп. Целью проекта является статья в хорошем журнале, участники – соавторы.

Если Вам интересно участие – напишите @alexander_v_c (Александр Червов, к.ф.-м.н. мехмат МГУ, 25 лет math&DS, Kaggle, Scholar, Linkedin).

Чат для обсуждений
Вводный доклад
Пояснения по RL части

Краткая суть задачи - нахождение пути на графе от вершины А до вершины Б, но размер графа 10^20-10^50 – обычные методы не применимы. Решение пазла типа Кубика Рубика. Задача близка к прошедшему конкурсу Каггл Санта 2023. Математически – разложение элемента группы по образующим. Математические пакеты, которые частично могут решать эту задачу – GAP, SAGE.

Достигнутые результаты - уже сейчас мы можем за минуты делать то, что авторы работы DeepCube делали за 40 часов на многих GPU.

GraphQL

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

Автор в своей статье рассказывает, какие нежданчики можно встретить при использовании этой технологии.
Проблема накручивания авторизации и rate limits – в graphql это решается сложнее, чем в rest. Также описана security проблема, при которой парсинг самого обычного запроса может привести к OOM на сервере.

В конце статьи автор предлагает набор критериев, когда вам эта технология не нужна, а также рассказывает об альтернативах, которые он видит.

В общем статья любопытная. Сам я эту технологию в production не трогал. У меня сложилось впечатление, что GraphQL – классный, когда у тебя очень-очень много клиентов, вот тогда раскрывается весь его потенциал.

#skills

Книга "Думай медленно... Решай быстро" от лауреата Нобелевской премии по экономике – Даниэля Канемана

Недавно второй раз перечитал эту замечательную книгу и хочу её посоветовать всем, кто ещё не читал.

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

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

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

#books