ru
Feedback
DevFM

DevFM

Открыть в Telegram

О разработке: AI, технологии, инструменты, system design, процессы, команды Для связи @sa_bul

Больше
3 052
Подписчики
-424 часа
+47 дней
+13330 дней
Архив постов
DevFM
3 052
Посмотрите на альтернативу Kafka Мы очень любим Кафку и писали на эту тему несколько постов. Но не Кафкой единой. Всегда интересно посмотреть на альтернативы. И самая интересная сейчас — red panda. А для, тех кто заинтересовался подробностями — сложная статья с множеством бенчмарков и описанием интересных проблем. Обязательно загляните в заключение, там автор делает некоторые выводы и сравнивает Redpanda с Kafka. #skills

DevFM
3 052
Станьте спикером на IT-конференции YaTalks 2023 YaTalks — международная технологическая конференция Яндекса для IT-сообщества
Станьте спикером на IT-конференции YaTalks 2023 YaTalks — международная технологическая конференция Яндекса для IT-сообщества. Пройдёт 5 и 6 декабря офлайн в Москве и Белграде, а онлайн — по всему миру.  В первый день обсудим хардовые технологии и значимые тренды в IT: разработку, Machine Learning, базы данных, железо и безопасность. Второй день посвятим менеджменту, карьере, работе командами и послушаем вдохновляющие доклады о научных явлениях, которые изменят индустрию в будущем. 👀 Прямо сейчас мы ищем спикеров, которые хотят поделиться опытом с IT-комьюнити. Если вы работаете в области разработки и эксплуатации ML-приложений, баз данных, облачных технологий и других направлениях, мы ждём ваш доклад! 👉Расскажите, как строите методологии разработки, тестируете и отлаживаете программы. Поделитесь историями о ЦУП, беспилотных автомобилях, решениях для умного дома и других устройств. Ваш практический опыт, инсайты и истории успеха будут полезны другим участникам конференции. Подать доклад на конференцию можно до 13 октября. Мы рассмотрим заявку и вернёмся с ответом до 21 октября. Подать доклад Реклама. ООО "Яндекс". erid:2Vtzqv43BaK

DevFM
3 052
Как проектировать бизнес-логику приложения? Вопрос подписчика: с ростом сложности разработки возникает необходимость в проработке логики приложения и будущего интерфейса. Есть ли какие-то приложухи, приёмы, фреймворки, тулзы для помощи в создании абстракций будущего проекта? Слышал про UML-диаграммы, но хочется уточнить, что сейчас в сфере разработки действительно применимо, что нужно и что не нужно. ---------- При нашем участии создавались проекты от месяца до полутора лет и коллективами от 1 до 10 участвующих лиц. Были мы и рядовыми разработчиками, и тимлидами, и даже чисто создавали ТЗ для дальнейшей реализации сторонними силами. По нашему опыту проектной работы, функционал приложения удобно излагать в техническом задании (ТЗ). Подробное ТЗ в текстовом виде содержит набор требуемых фич и покрывает нюансы вроде разграничения ролей, планируемых интеграций и так далее. Само ТЗ можно компоновать по-разному. Довольно удачным является описание через раскрытие сценариев работы приложения. Оттолкнуться можно от user story – это краткое описание функциональности в стиле "возможность добавлять тег к задаче". В ТЗ такую фичу надо детализировать: кто именно может добавлять тег? Теги фиксированные или настраиваются? Настраиваются пользователем или админом приложения? На какие экраны надо выводить тег и где их можно редактировать? Ответы на эти вопросы складываются в кучу нюансов. Удобнее всего описывать ТЗ по экранам будущего приложения, а потом рядом прописать сценарии работы, в каком порядке эти экраны позволят выполнить те самые user story. При этом не надо из ТЗ пытаться делать огромный бюрократический документ. Размер, конечно, зависит от сложности системы, но вот наполнять ТЗ канцеляризмами совсем зло. Формальные подходы типа UML, на наш взгляд, в индустрии не взлетели. После ТЗ или одновременно с ним неплохо бы нарисовать макеты будущего приложения. Они упрощают восприятие ТЗ и позволяют согласовывать отдельные элементы с широким кругом заинтересованных лиц. Посмотреть картинку приложения куда проще, чем читать ТЗ. Нужные элементы, то есть условные формочки, выпадающие списки и кнопочки нужно накидать на будущие экраны. Сразу становится понятно, не перегружены ли экраны избыточной функциональностью. Рисовать макеты можно хоть от руки, хоть в paint. Конечно, есть более подходящие инструменты вроде figma, но глобально можно использовать что любой инструмент. Figma предоставляет разные библиотеки элементов и берёт на себя вопросы расшаривания макетов – макеты можно отдать дизайнеру, который в фигме же прорисует нормальный интерфейс, из которого потом верстальщик перенесёт всё в код. Дальше вопрос объёма приложения и опыта. Условно, если в paint макет я отрисую за 10 часов, а в figma за 1 час, казалось бы, paint совсем плох. Но! Для освоения figma я потрачу кучу времени, условные 4 часа. Тогда соотношение времени уже не 1 к 10, а 1 к 2. Плюс, сколько всего времени займут макеты? Обычно это относительно малая часть работы. По нашему опыту, для приложения со сроком разработки в год на ТЗ и макеты выделяется меньше 1 месяца, большая часть из которого тратится на выяснение фич и их согласование с заказчиком. #devfm #systemdesign

DevFM
3 052
Backup: август и сентябрь Мы записали подкаст! Совместное обсуждение разных тем всегда было для нас источником взаимного вдохновения. Мы решили попробовать новый для себя жанр и записали наш разговор: встречайте выпуск Ретроспектива силами команды разработки Остальное, как обычно, в текстовом виде. Я люблю питон, и вот почему он меня бесит Базы данных Посмотрите на keydb Временные интервалы в postgres Управляем людьми Как сделать из линейного сотрудника начальника Managing difficult software engineers Инструменты Утилита lazy-docker Любимые шрифты для разработки Если пропустили, то подборка за июнь и июль #backup

DevFM
3 052
Managing difficult software engineers Фокус статьи на управлении проблемными разработчиками. Это логично, потому что с беспроблемными разработчиками всё просто работает. Тем не менее, общие рекомендации для простого случая тоже есть. Формула такая: –Trust. Доверяйте компетенции сотрудника, давайте разумную автономию и адекватно относитесь к ошибкам – Growth. Давайте разработчику расти, выдавая ему крутые задачи, поощряйте успех и давайте обратную связь – Comfort. Обеспечьте комфорт, в том числе минимизируйте прерывания и обеспечьте процесс. Чем меньше у разработчика болит голова по вопросам вне проекта, тем более он может быть продуктивен в проекте Дальше рассматриваются типичные проблемные персонажи: Прокрастинатор, Одинокий волк, Демотиватор (как вам такой перевод? В оригинале negative Nancy), Обещатель, Всезнайка, Тихоня, Перфекционист, Ненадёжный, Конфликтный, Выгоревший. По каждому даны признаки и советы, как с таким жить. Советы для одинокого волка просто слёзы. Типа сделайте его командным игроком, ага. По остальным всё выглядит по делу. #edu

DevFM
3 052
Суперкомпьютерные дни в России Началась такая конференция. В этом году я не выступаю, а только слушаю. Сама конференция не такая крутая, как highload, поэтому публичной трансляции нет. Трансляция только после платной регистрации. В комментариях дам свои ссылки для ознакомления. Кстати, мы писали, зачем вообще имеет смысл ходить на конференции. Велкам на кофе-брейк, если кто-то тоже тут :)

DevFM
3 052
Пятничное развлекательное Посмотрите короткий ролик WAT — A lightning talk by Gary Bernhardt from CodeMash 2012. Товарищ обращает внимание на совершенно безумные конструкции в ruby и javascript и их нелогичность. Что будет, если выполнить a = a ? Что вернёт конструкция [] + []? Массив плюс массив в js. А массив плюс объект? А операция плюс коммутативна или нет? Если вам понравилось, то к просмотру предлагается 20-минутный доклад Brian Leroux - WTFJS на схожую тематику. #fun

DevFM
3 052
Подкаст DevFM: Ретроспектива силами команды разработки Мы тут собрались с духом и решили записать подкастик. Обсудили интересную и насущную тему – ретроспективы. У нас нет специального человека для ретро, да и сама идея этого мероприятия многим кажется сомнительной. Мы поделились опытом, как проводим ретро своими силами и почему считаем его важной штукой. #devfm #podcast #teamwork

DevFM
3 052
Я люблю питон, и вот почему он меня бесит Специалист выделяется тем, что для своего инструмента он понимает сильные и слабые стороны. Поэтому прошу: статья про кривые и косые вещи в питоне. Автор подсвечивает существующие проблемы генераторов: откладывают выполнение кода, дают мало контекста и затрудняют отладку. Динамические импорты дают свободу (как удобно прямо в функции что-то для отладки импортировать и потом убрать), так и определённые боли. А если импорт упадёт, а вы импортировали в рантайме? Это точно не то, что вы бы хотели. Интересно было прочитать про legacy с потоками и процессами. Выглядит забавно. Микс из разных стандартов именований прямо в модуле logging стандартной библиотеки забавен. Я всегда тыкаю в logging, когда хочу показать camelCase :) С async в python действительно непросто. Но у нас был достаточно хороший гайд на этот счёт, вливайтесь. Обратите внимание на блок про символьный ад. Меня всегда веселило, что 1 является числом, (1) тоже просто число, а 1, (с запятой) уже кортеж. Кстати, вы знали, что создание списка с помощью [] немного быстрее, чем создание с помощью list()? С указанными автором нюансами про декораторы никогда не сталкивался. А вы? А вот с необходимостью прервать с помощью break сразу два цикла сталкивался неоднократно. Приходится некрасиво костылить, к сожалению. Про наличие map/filter одновременно с comprehensions автор немного недоговаривает. В целом не существенно, но в статье List Comprehension vs Map этот вопрос рассматривается подробнее. Огромная боль, что нет аннотации исключений. Я как-то советовал новичкам для обработки исключений смотреть справку по функции и самому в docstring тщательно прописывать исключения. А потом я посмотрел справку на open. В описании есть только порождение IOError. А на самом деле функция open может выбрасывать угодно — IsADirectoryError, PermissionError, FileNotFoundError... И узнать это нельзя. Какие WTF в питоне больше всего забавляют вас? #python

DevFM
3 052
Как сделать из линейного сотрудника начальника В статье описывается интересный гайд по превращению опытного бекендера в тимлида. Начинается история с препятствий — чем будет плох разработчик, ставший руководителем. Он будет пытаться решить проблемы привычным ему образом, то есть тянуть все процессы на себя путём увеличения количества своей работы. Это плохо и бизнесу, и коллегам, и самому разработчику. Как сделать правильно? Автор предлагает очевидные, но хорошие шаги: — объяснить, что от него нужно на должности тимлида — договориться о конкретных задачах, сроках, не забыть выдать ресурсы — дождаться выполнения и помочь в процессе — провести ретроспективу. Кстати, это важный этап жизни любой команды, но здесь речь про ретро с самим тимлидом. Надо совместно понять, насколько цели достигнуты и что надо подкорректировать У автора совершенно выпадает вопрос определения или развития софтскиллов, требуемых тимлиду, чтобы адекватно вести команду. Вероятно, предполагается, что вы удачно взяли среди разработчиков некоторого неформального лидера, у которого уже есть склонность к руководству, и работаете с ним. Иначе гайд вам никак не поможет, разработчик-интроверт с достаточно малой вероятностью сможет стать крутым руководителем. #edu

DevFM
3 052
Любимые шрифты для разработки Помимо применения всяких линтеров, хочется, чтобы код визуально нравился. Я обычно использую шрифт FiraCode с лигатурами. Обычные символы ==, >=, ->, != и многие другие становятся очень красивенькими и более читаемыми. В репозитории собраны все подробности с картинками и пояснениями. #tools

DevFM
3 052
Пятничное развлекательное залипательное Залипательная штука. Каждый раз переходя по ссылочке, вы будете попадать на произвольный сайт из эпохи Web 1.0. Интересно, что натыкался на сайты, которые до сих пор поддерживаются и обновляются – обычно какие-то персональные страницы. Мне попадались самые разные шедевры, например, вот – о том, как сосуществовали люди и динозавры. Оттуда же можно узнать, почему динозавры не упоминаются в библии. Расскажите, что у вас? #fun

DevFM
3 052
Утилита lazy-docker Классная утилита lazy-docker, которая привносит UI в терминал. Позволяет быстро просматривать основные сущности, логи, конфиги, потребляемые ресурсы. Я не сторонник такого, но выглядит приятно, да ещё терминал не нужно покидать. #tools

DevFM
3 052
Временные интервалы в postgres Недавно столкнулись с задачей анализировать временные интервалы и подготавливать данные, находящиеся в Postgres, для построения графиков. В статье автор на реальных примерах демонстрирует интересные возможности postgres: – функция generate_series генерирует различные хитрые ряды – функция date_bin позволяет группировать временные метки по различным хитрым интервалам – функция width_bucket считает количество значений в динамических интервалах – на закуску unnest вместе с ORDINALITY Все описанные в статье примеры можно легко воспроизвести. Ещё из интересного, автор для своих примеров использует специальное расширение postgis для написания питоновского кода. Так, конечно, делать нельзя, но может оказаться полезным для проведения экспериментов или в демонстрационных целях. #skills #database

DevFM
3 052
Пятничное развлекательное При регистрации к паролю часто предъявляются разного уровня параноидальности требования. Нужны оба регистра букв, цифра, спецсимвол, завязка, кульминация и развязка... Залипательная игра на придумывание пароля с постоянно усложняющимися, мозгодробительными условиями. Пишите, на каком шаге остановились. #fun

DevFM
3 052
Посмотрите на keydb Мы уже упоминали keydb – интересную альтернативу redis, на которую можно бесшовно переехать. Хоть переезд и обещают бесшовным, но логичен вопрос – зачем? В статье ребята рассказывают о двух киллер-фичах, ради которых можно устроить переезд. Речь идёт о режимах active replica и multi-master. Они позволяют получить совместимый с Redis распределённый отказоустойчивый KeyDB, но при этом писать в любую ноду, читать из любой ноды. Это как раз то, чего в redis будет сложновато добиться. Пожалуй, самая интересная и ценная часть статьи – это проблемы, с которыми можно всё-таки столкнуться, используя keydb и тех случаях, когда keydb вам, вероятно, не подойдёт. Авторы столкнулись: – c неожиданным поведением некоторых команд – c out of memory, когда городили хитроумный кластер с множеством мастеров и реплик – с проблемой, когда всё ломала клиентская библиотека #skills #database

DevFM
3 052
Backup: июнь и июль Этим летом много говорили о проектировании, анонсировали наш курс по Linux, не забывали про Python и даже писали о тимлидстве. Архитектура проекта Управление данными в микросервисах Путь от монолита к микросервисам   Event storming для проектирования сервисов Retrying consumer in Kafka   Мониторинг — боль Linux Бесплатный курс "Командная строка для разработчиков" (готово 3 занятия, пополняется) Зачем разработчику нужен Linux вообще и терминал в частности Ковыряем атаку forkbomb на bash в docker Инструменты Как документировать архитектуру   Утилита gping — ping на стероидах Разное Tracing Python Попробуйте ruff   Гайд начинающего тимлида  Как находить время "на почитать" В пятничном развлекательном вы активно реагировали на посты Типы кабелей, 40 лет развития роботов, Что значит ЧБУ, Anki-карточки Если пропустили, то подборка за май и большая подборка по базам данных

DevFM
3 052
gping Периодически в офисе отваливается интернет. Чтобы оперативно об этом узнавать, в фоне всегда запущен терминал с классическим ping 8.8.8.8 Недавно узнал об интересной утилите gping. Это такой ping на стероидах. Из приятного: — в консоли строится временной график — можно пинговать сразу несколько хостов и наглядно видеть отличия — можно измерять время выполнения команд Кстати, помимо гуглового DNS 8.8.8.8 существует также красивый адрес DNS от Cloudflare 1.1.1.1. У них же есть DNS 1.0.0.1. Зачем им такой некрасивый адрес? Прикол в том, что по стандарту IP можно пропускать диапазон нулей. В результате ping 1.1 раскроется в 1.0.0.1 — попробуйте сами. #tools

DevFM
3 052
Пятничное развлекательное Залипательное и захватывающее видео о развитии роботов Boston Dynamics на протяжении 40 лет. Удивительно, как неспешно идёт прогресс в этой области. В противовес этому, прогресс в области искусственного интеллекта семимильными шагами идёт вперёд. Мы делились, какие прикладные задачи уже можно решать с помощью ChatGPT. Подробнее историю развития Boston Dynamics можно прочитать тут. Кстати, в 2013-2017 годах ими владели Google, а с 2020 года и по настоящее время ими владеет Hyundai. И у них всего 500 сотрудников. #fun

DevFM
3 052
Ковыряем атаку forkbomb на bash в docker Есть такой вид атаки на отказ в обслуживании (DoS, Denial of Service) — forkbomb. Запускается процесс, который бесконечно порождает сам себя, пожирая все ресурсы системы. Прав суперпользователя не требуется, любой пользователь может создавать процессы. Cкрипт атаки выглядит так. Функция порождает две версии себя, связанные конвейером. Правая функция уходит в фоновый режим с помощью знака амперсанд &. forkbomb() { forkbomb | forkbomb& } Скрипт можно переписать в непонятный однострочник, изменив название на символ двоеточия: :(){ :|:& }; : Такой набор символов эквивалентен скрипту выше. При этом он компактен, и его могут запихнуть вам в качестве шуточного ответа на вопрос. Спасибо ещё, что не патч Бармина. В видео также применяется десяток линуксовых команд, в том числе и разбираются флаги такой docker команды docker run --it --rm --cpus="0.5" --memory=4G --pids-limit=1000 --name=forkbomb ubuntu bash Хотите почувствовать себя капитаном тонущего корабля? Теперь ресурсы системы принадлежат не вам, а паразитному процессу forkbomb. Приятного просмотра! #devfm #youtube #skills