2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Как управляться с телефонными номерами
Существует миллион способов записать номер телефона. Скобочки, пробелы, тире, плюсики и дальше по списку.
Проблемы начинаются, когда нужно где-то и как-то хранить телефонный номер и у вас нет возможности валидировать формат номера при вводе.
В статье автор рассказывает о стандарте для хранения телефонных номеров, специальной библиотеке для работы с номерами, приёмах для нормализации номеров, а также о подвохах, которые вас ожидают.
#skills
Список матюков
Недавно была задача на фильтрацию всяких непотребств в продукте. Начали думать, где бы взять хороший, полный словарик, а если ещё будут английские слова, так вообще замечательно.
И мы узнали, что, оказывается, самые разнообразные матюки можно найти в Steam.
В комментах приложим файлики для изучения и общего развития на русском и английском языках. А также файлики со словами-исключениями, чтобы избегать ложного срабатывания.
Для особо пытливых другие языки можно найти в Windows в Steam, в папочке resource.
#edu
Книга "Релевантный поиск"
Недавно моему хорошему коллеге пришлось с нуля разботывать работу с elasticsearch. Статей для глубокого погружения не хватало и он взялся основательно за книгу.
И вот что он рассказал о книге:
Книга знакомит с понятиями релевантности, текстового анализа, ранжирования. Подробно рассказывает о разных хитрых особенностях.
Материал хорошо структурирован и имеет практический уклон. Поставленные проблемы решаются микрошажками, чтобы любая домохозяйка разобралась.
Отдельно рассказали как эксплейнить запросы и какие механизмы есть под капотом, которые оценивают релевантность в соответствии с введенным запросом.
Дабы закрепить материал, в конце показывают вымышленное приложение и как авторы собирали поиск, учитывая желания и клиентов, и бизнеса, и геолокации.
Для нашего нового проекта книга оказалось полезной, удалось пересмотреть анализаторы и выкинуть в помойку лишнее.
#skills #books
Dozer
Маководы наверняка сталкивались с проблемой, когда в меню баре скапливается очень много иконок, и не все они нужны и даже не все помещаются в экран.
Давно пользуюсь такой простой утилиткой, как Dozer. Очень удобно, очень нативно можно скрыть все, что вам мешает.
#tools
Оценка сроков проекта для тимлида
Как узнать у разработчика сроки решения задачи? Ну, никак. Он вам будет врать.
Если вы всё ещё хотите узнать сроки, то придется попотеть:
1. Спрашиваете сроки. Вам говорят некую величину R.
2. Если R <= 16 рабочих часов, то реальное время выполнения проекта составит примерно R умножить на π, то есть ~3,14R. Почему умножаем на Пи? Во-первых, это красиво. Во-вторых, тройного запаса обычно хватает.
3. Если R > 16 часов, то задача слишком большая и разработчик дал рандомный срок. В этом случае срок можно рассчитать как R×π + 2 недели. Почему умножаем на Пи? Потому что это красиво. Почему добавляем 2 недели? Потому что за 2 недели можно сделать что угодно...
И полученную цифру надо отсчитывать от момента начала работы над задачей, а не от сегодня. Как узнать, когда разработчик приступит к задаче? Ну, никак...
Ответ на пост Трудоемкость != сроки
#edu #teamwork
Пятничное развлекательное
Нестареющая классика. Так и живем. Лишние телодвижения ни к чему😃
#fun
Прекрасное из недавнего диалога:
— Наша архитектура — микросервисный монолит!
Короче, это когда архитекторы вложились и сделали изолированные пельмени, чтобы снизить зависимости, а потом пришли разработчики и сварили из них запеканку.
The ultimate docker compose cheat sheet
Хорошая статья, охватывающая основные аспекты docker compose. Автор начинает с базовых концепций, но будет полезна даже тем, кто хорошо знаком с компоузом.
Из интересного:
– параметр, позволяющий рестартить сервис, если он завалился
– как одному сервису дождаться запуска другого сервиса с использованием определенных условий. Бывает полезно, когда веб-сервис дожидается старта базы данных
– как задавать healthcheck сервисов с различными параметрами
– также автор разжёвывает тему volumes и networks
У нас был отдельный пост с практическими советами по докеру.
#skills #docker
Backup: подборка по базам
Экспертиза в базах данных – супер востребованный скилл среди разработчиков. У нас накопилось приличное количество постов, посвящённых базам данных. Собрали все в один пост, чтобы было удобно.
Практика
– Подробный гайд по работе с json в postgres
– Какой тип данных использовать для хранения строк в postgres
– Куда смотреть, если postgres начала тупить
– Базовые настройки Postgres
– Работа с NULL в Postgres
– Тестирование миграций alembic
– Сравниваем базы данных с помощью data-diff
Теория
– TOAST – проблемы откуда не ждали
– Индексы в PostgreSQL
– Буфферный кеш в PostgreSQL
– Этапы выполнения запросов в PostgreSQL
– ACID в PostgreSQL
–Понимаем EXPLAIN в PostgreSQL
– Миграции без даунтайма
– Храним данные по-разному, в зависимости от цели – создаем аналитическую базу
– Введение в Greenplum и пример реального использования
– Введение в Manticore и сравнение с Elastic
– Тернистый путь к ClickHouse
Эту подборку мы добавим в закреплённое сообщение и будем поддерживать в актуальном состоянии. Пробейте палец вверх, если считаете подобные тематические подборки полезными.
#backup
За что мы любим командную строку
В повседневной деятельности мы активно применяем командную строку. Иногда слышим вопросы о том, зачем это вообще нужно, вроде и без неё все хорошо? Этот вопрос вполне логичен, если не погружался в эту тему, не пытался решать реальные задачи.
На хабре мы написали лёгкую статью, где на примерах рассказали, за что мы любим командную строку. Профессиональный навык работы с командной строкой – один из шагов к 10х программисту.
Попробуйте ruff
Ранее мы рассказывали о целом наборе линтеров, которые постоянно применяем в своих проектах.
Недавно обратили внимание на достаточно молодой и интересный линтер для python – ruff. Он объединяет в себе правила многих других линтеров – по сути всех, которые используем.
Мы уже сделали для себя конфиг и испробовали его на одном из сервисов. Полёт нормальный, ощущения только положительные.
Из плюсов:
– ощутимая скорость. Линтеры у нас прогоняются с помощью pre-commit на каждом коммите, поэтому скорость имеет значение. Пару раз даже ловил себя на мысли, что не делаю лишний коммит, чтобы не ждать прогона линтеров. А ruff отрабатывает практически моментально
– в pre-commit не нужно держать целый зоопарк линтеров. Достаточно один раз сконфигурировать и подключить ruff
Так что категорически рекомендую попробовать. У них, кстати, есть playground для этих целей.
#python
Пятничное развлекательное
Мы уже говорили о Роберте Сапольски. Хочется порекомендовать ещё одну захватывающую лекцию. На этот раз о религии. Просто послушайте и делайте выводы сами.
А кто хочет лёгкого и интересного чтения обратите внимание на его книгу о жизни и работе в Африке – Записки примата. Необычайная жизнь ученого среди павианов. Путешествия по континенту, исследование влияния стресса на другие биологические показатели, быт местных племен.
#fun #books
Работа с памятью
На практике редко приходится работать с памятью напрямую, но под капотом компьютер шуршит шестерёнками — выделяет и освобождает память.
Познавательная статья с очень качественной визуализацией, посвящённая основам работы с памятью.
Автор рассказывает базовые концепции, как выделяется и как освобождается память, затрагивает проблему фрагментации, утечки памяти, и другие причины полнейших крахов, от которых мы не защищены.
#skills
Пятничное развлекательное
Наверно, почти все слышали о замечательной книге "Вы, конечно, шутите, мистер Фейнман!", но она точно заслуживает ещё одного упоминания.
Увлекательная автобиография известного физика, лауреата Нобелевской премии – Ричарда Фейнмана. Как думал, как работал этот выдающийся человек. Помимо этого в книге рассказывается множество интересных историй и смешных случаев из жизни.
Эта книга вдохновляет и мотивирует на новые свершения.
Если еще не читали – обязательно прочтите.
#fun #books
Оптимизатор join в PostgreSQL
Тема из разряда: вон оно как бывает в Postgres. Ну, или, может, об этом все знают, а я один такой тёмный.
Обычно вы можете джоины смело лепить в любом порядке, а умный оптимизатор всё оптимизирует и выполнит джоины, скорее всего, оптимальным путем.
Но бывают случаи, когда нужно сделать большое количество джоинов. Например, когда подбиваем какой-нибудь отчёт.
Оказывается, что если сделать больше 8 джоинов (параметр по умолчанию), то оптимизатор не будет строить планы выполнения запросов, а просто выполнит все джоины в том порядке, в каком они написаны.
Число, после которого оптимизатор сдаётся и ничего не делает, задается параметром join_collapse_limit. С ним можно поэкспериментировать с помощью SET join_collapse_limit и посмотреть, как будет меняться время работы EXPLAIN запроса.
В тему нюансов работы с Postgres у нас был пост, чем отличаются: char, varchar, и text и какие бывают нежданчики в json-полях.
#database
Говоря о поисковых движках, мы писали о том, как затаскивали Manticore Search на проект. Начиналось всё очень даже позитивно. Нам нужен был разухабистый поиск по понятным, но сложным правилам.
Закончилось всё не так позитивно. Через некоторое время мы словили критический для нас баг, о котором доблестно отчитались в баг репорте на GitHub.
По багу развернулся большой тред и через несколько месяцев даже отрапортовали, что проблема не воспроизводится. Ноооо мы решили дальше не рисковать и больше мантикорой не пользуемся.
А вывод из этой истории такой: экспериментировать технологиями хорошо, полезно и нужно. Но в продакшн стоит брать проверенные, «скучные» технологии.
#skills #database
Книга "Getting Real"
Долго откладывал эту книжку, а потом каааак прочел на одном дыхании.
Книга описывает философию и подходы к разработке и управлению проектами.
Основные идеи книги включают:
– Простота: Сосредоточьтесь на том, что действительно важно, и избегайте усложнения проекта ненужными функциями.
– Гибкость: Будьте готовы к изменениям и адаптации на ходу.
– Реализация идей: Начинайте с реализации основных функций и постоянно совершенствуйте продукт на основе обратной связи от пользователей.
– Минимализм: Создавайте минимально жизнеспособный продукт (MVP), чтобы быстрее получить обратную связь и внести необходимые улучшения.
Каждый из этих пунктов кажется банальным, но на практике они часто упускаются.
Особенно полезно будет для стартапов и небольших команд. Но ребятам из кровавого энтерпрайза тоже может оказаться интересным – узнать как оно бывает быстро и динамично.
#edu #books
Подкаст DevFM: Кто такой тимлид тимлидов (yandex / youtube / podster)
Второй подкаст посвящён нашему опыту росту разработчика от тимлида проекта до руководства разработкой десятка проектов, над которыми трудятся больше сотни человек.
Обсуждаем рабочий день, проблемы интераптов и санитайзинг рабочего времени. Удачные практики и инструменты по организации эффективной работы.
Что изменилось на новой должности? Нюансы потери детализации над проектом. Нужны ли KPI?
Непрошенный совет разработчикам, которые думают стать тимлидами.
Наш первый подкаст
#devfm #podcast #teamwork
Настраиваем терминал "под себя"
В нашем бесплатном курсе cli-for-dev на степике вышло новое занятие. Переменные окружения, конфиги, дикие алиасы. Практика с настоящим терминатором! Удобный Ctrl+R и тонны хоткеев, всё как вы любите.
У нас 950 учащихся, 180 дошли до пятого занятия и оставили 30 отзывов. Теперь доступно шестое занятие. Будем рады вашим отзывам на степике.
#devfm #skills
Зеркало 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.
Ну это просто прекраснейшая аналогия, теперь всем буду так объяснять
Читать полностью…
Backdoor длиною в два года
Для тех кто пропустил детективную новость – бекдор в пакете архиватора XZ Utils, который повсеместно используется в Linux. Уязвимость предоставляет возможность выполнить произвольный код по SSH, не оставляя следов в логах sshd.
Всё началось в октябре 2021, когда некто под ником JiaT75 начал активно участвовать в развитии XZ, делать пул реквесты. Разумеется, мейнтенером проекта он не был. Через некоторое время появилось ещё два персонажа Jigar Kumar и Dennis Ens, которые также начали контрибьютить в проект. Через какое-то время в переписках они начали аккуратно давить на мейнтейнера проекта, что как будто он не справляется с нагрузкой, не успевает вовремя ревьюить пулл реквесты и что хорошо бы сделать JiaT75 ещё одним мейнтейнером. Так оно и случилось, JiaT75 стал мейнтейнером проекта XZ, а через некоторое время внедрил в него бекдор.
Вот что значит играть вдолгую :) Причём после релиза библиотеки с бекдором злоумышленники с левых аккаунтов стали писать меинтейнерам программ и дистрибутивов, мол, обновляйтесь.
Вскрылось всё это случайно. Один ну очень внимательный разработчик заметил, что XZ стало поджирать больше cpu, чем обычно. Он начал разбираться и обнаружил вредоносный код.
Такая невероятная история. Обязательно почитайте. Страшно представить, сколько подобных бекдоров мы ещё не знаем…
Больше деталей на opennet, в том числе разбор логики бекдора. Интересные детали ещё в канале Авва.
#security
Redis меняет лицензию
Как-то мы пропустили новость момент, что redis очередной раз поменял лицензию (нужен VPN). Эта лицензия (RSALv2 и SSPLv1) делает редис, как говорит автор заметки, source available – звучит так себе. Основное ограничение – запрет на бесплатное использование redis для облачных сервисов, то есть борьба с SaaS от крупных компаний вроде Amazon.
Наверняка новая лицензия не затронет большинство пользователей. Но лицензия является проприетарной и ещё черт ногу сломит разобраться, насколько это повлияет конкретно на вас. Да и в целом такие шаги с нашей точки зрения дурно попахивают.
Поэтому есть повод посмотреть на достойные форки редиса, которые стали уже ничуть не хуже. Об одном из них писали ранее – KeyDB, второй достойный вариант – DragonflyDB.
#tools
Зачем разработчику нужен Linux вообще и терминал в частности
Эта статья существует! Вчерашний анонс из-за путешествий во времени вышел не вовремя. Так зачем вам терминал?
– легко поставить софт
– легко автоматизировать процессы
– легко вспомнить
– легко настроить под себя
легко…(злобный закадровый смешок)
Покажем, чем терминал важен для разработчиков и не только на разных примерах.
#devfm #skills
Управление данными в микросервисах
В микросервисной архитектуре у каждого сервиса обычно своя база данных. Для организации доступа одного сервиса к данным другого сервиса нужно либо каждый раз делать запрос к сервису, ответственному за данные, либо иметь копию нужных данных. И тут важен баланс.
Например, у нас есть сервис, который хранит и обслуживает актуальный справочник городов. А навигационный сервис предоставляет информацию о маршрутах общественного транспорта в выбранном городе. Как правильно организовать доступ навигационного сервиса к справочнику городов?
В статье автор рассказывает о способах управления данными в микросервисной архитектуре:
– Дублирование мастер-систем. Каждый сервис хранит и поддерживает данные независимо друг от друга
– API. Сервис, ответственный за данные, предоставляет доступ к данным по API другим сервисам
– DWH. Сервис, ответственный за данные, сливает их в единое хранилище, а другие сервисы имеют доступ к хранилищу
– Очереди. Сервис, ответственный за данные, публикует информацию обо всех изменениях в очередь. А другие сервисы, считывая данные из очереди, хранят на своей стороне и актуализируют.
По каждому способу автор рассказывает о достоинствах и недостатках. Подробнее останавливается на последнем, как на наиболее интересном, и рассказывает о нюансах реализации.
Способ через очереди мне особенно нравится тем, что позволяет делать сервисы более независимыми, хотя он, конечно, более трудозатратный.
#systemdesign
Backup: май
Архитектура проекта
1. Load balancing
2. Zero-Downtime Deployments with Docker Compose
3. Как проектировать микросервисы
4. Кеширование на бекенде
5. Асинхронное взаимодействие сервисов с применением Kafka
Копаем вглубь
1. Пагинируем по-всякому
2. Как работает ChatGPT
3. Попробуйте HTMX
4. Работа с памятью
Базы данных
1. О производительности Postgres
2. TOAST – проблемы откуда не ждали
Разное
1. Как мы стали делать офигенно длинные собрания, и почему это больше не вселенское зло
2. Роберт Сапольски — Биология религиозности
3. Вы, конечно, шутите, мистер Фейнман!
4. Сравниваем лампы и батарейки
Если пропустили, то подборка за апрель.
#backup
Сам читаю недавно, но уже хочется посоветовать живой и приятный канал Николая Хитрова о разработке на python.
Автор пишет много практических постов о разработке, например, пост о логировании или какие нюансики стоит знать, внедряя loguru. Периодически поток информации разбавляется юмором. А ещё узнал из этого канала об интересной такой утилите deptry.
TOAST – проблемы откуда не ждали
Для хранения длинных записей в Postgres используется механизм TOAST.
Колонки с длинными значениями не хранятся в самой таблице. Если значение больше 2 Кб, то данные разбиваются на чанки и отправляются в связные тост-таблицы, скрытые от пользователя. А в исходной таблице хранится специальный указатель на чанки в тост-таблице.
И нам этом можно было бы и закончить. Просто интересный факт, связанный с особенностью хранения данных.
Но есть нюансы. Отметим практически значимые.
– В тост-таблице не может быть больше, чем 2^32 значений, то есть можно просто упереться в верхнее значение
– TOAST не поддерживает UPDATE. То есть каждая операция обновления вашего большого JSON приводит к INSERT в тост-таблицу и её распуханию.
– Независимо сколько в вашей таблице колонок, тост-таблица всегда одна.
Но дело не только в количестве значений в тост-таблице. Сам механизм накладывает определенные издержки.
JSON в Postgres уже давно не в новинку и активно используется. И, как правило, обсуждения проблем TOAST крутятся именно вокруг JSON полей.
В первой части статьи на конкретных примерах показывают, как резко и, на первый взгляд, беспричинно может упасть производительность и увеличиться WAL из-за TOAST.
Во второй же рассказывают, как оптимизировали JSON, чтобы повысить его производительность и уменьшить влияние TOAST. Также дают пару советов: всегда использовать JSONB и никогда не хранить в нём ID.
А для желающих по хардкору погрузиться в кишочки ещё одна статья. Автор закатывает рукава и лезет вглубь TOAST, рассказывает алгоритм его работы и предлагает конкретный подход с бенчмарками для улучшения самого TOAST.
#skills #database
Асинхронное взаимодействие сервисов с применением Kafka
Практическая статья, демонстрирующая, как организовать асинхронное взаимодействие сервисов на Python с использованием Kafka. Автор коротенько даёт вводные, описывает архитектуру и переходит к делу.
У нас были посты для более глубокого погружения в Kafka. Например, тут в одной статье рассказывают самые основы, в другой разбирают неочевидные проблемы, возникающие на практике.
#python #procode