2009
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Прекрасная статья ARCHITECTS, ANTI-PATTERNS, AND ORGANIZATIONAL FUCKERY, написанная по мотивам треда в твиттере. Название говорит само за себя.
Очень рекомендую к прочтению.
Свою позицию я выражу двумя цитатами из этой же статьи: «It treats architecture is a job to be done, not a role to be occupied.» и «Don’t become that sad architect. Be an engineer. Own your own code in production. This is the way.»
#systemdesign
Когда cron уже не хватает
Иногда классического cron не хватает, и есть замечательная альтернатива – fcron.
Для моей задачи нужны были хитрые условия запуска с определенной частотой и определенным количеством раз, которые fcron позволяет конфигурировать.
Но у него в целом более разухабистый функционал, чем у классического cron: с зависимостью задач друг от друга, выполнением задач по условиям, с более гибкой настройкой расписания.
#tools
llama.ttf is a font file which is also a large language model and an inference engine for that model.Для рабочего взаимодействия мы обычно использовали слак. Но настал тот день, когда слак добрался до нас – до злых рюсских (цитата по BadComedian) и заблокировал всё и сразу.
Но пост не об этом. Пост о том, насколько важен качественный и удобный канал общения.
Одно время одна из команд по определенным причинам вела рабочее общение в телеграмме. Но потом было принято волевое решение перевести ребят в слак. Скооооолько было стенаний, что слак неудобный. И вообще доколе?! – спрашивали они.
И вот теперь случилось обратное, мы временно вернулись в тг, пока присматриваем альтернативу. И скоооолько сейчас стенаний, что невозможно пользоваться телеграммом. Доколе?! – спрашивают они.
Самое важное, пожалуй, это наличие тредов, когда ты можешь очень изолированно в общем потоке обсудить конкретную проблему, не теряется контекст, нет параллельных сообщений на другие темы. И наличие грамотных уведомлений. Ты получаешь уведомление, если конкретно тебя тегнули (или весь канал), либо если кто-то пишет в треде, где тебя тегали или ты писал сообщения.
По сути, ты получаешь только то, что реально к тебе относится. Также есть специальное место, где всё это можно удобно посмотреть.
Пользуясь случаем, расскажите, что вы применяете на работе?
Я смотрю в сторону mattermost. Кто знает насколько там быстро упираешься в необходимость платить? Слышал также про zulip, на вид как слак.
#tools #devfm
GraphQL
GraphQL предлагает заманчивую концепцию. По сути, это язык для запросов данных, который позволяет клиентам получать только нужные им поля без лишней информации. Он использует одну точку доступа для всех запросов и чётко определяет структуру данных, что делает обмен информацией между клиентом и сервером более быстрым и удобным.
Автор в своей статье рассказывает, какие нежданчики можно встретить при использовании этой технологии.
Проблема накручивания авторизации и rate limits – в graphql это решается сложнее, чем в rest. Также описана security проблема, при которой парсинг самого обычного запроса может привести к OOM на сервере.
В конце статьи автор предлагает набор критериев, когда вам эта технология не нужна, а также рассказывает об альтернативах, которые он видит.
В общем статья любопытная. Сам я эту технологию в production не трогал. У меня сложилось впечатление, что GraphQL – классный, когда у тебя очень-очень много клиентов, вот тогда раскрывается весь его потенциал.
#skills
Как управляться с телефонными номерами
Существует миллион способов записать номер телефона. Скобочки, пробелы, тире, плюсики и дальше по списку.
Проблемы начинаются, когда нужно где-то и как-то хранить телефонный номер и у вас нет возможности валидировать формат номера при вводе.
В статье автор рассказывает о стандарте для хранения телефонных номеров, специальной библиотеке для работы с номерами, приёмах для нормализации номеров, а также о подвохах, которые вас ожидают.
#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
Идеальный скрипт на bash 2
Bash всё также ужасен и также распространён. Сняли продолжение хорошо зашедшего видео.
Когда в bash использовать [], а когда [[]]?
Как лучше писать в if, привычные < и > или непривычные -lt, -gt?
Кавычки вокруг переменных в bash — можно ли опускать? Ответы в 11-минутном видео. Текстовая расшифровка видео тут.
#youtube #skills #devfm
Пятничное развлекательное
Абсолютно замечательный сайт, где можно посмотреть внешний вид разных известных приложений десятилетие назад.
Можно, например, глянуть:
– Youtube из 2012
– Skype из 2011
– Airbnb из 2010
#fun
Советы руководителю от руководителя
Эта статья прекрасна своей простотой и очевидностью, но она затрагивает очень важные аспекты.
Автор касается многих тем, особенно мне откликнулись эти:
– ты, как руководитель, не должен быть незаменим, думай о bus factor.
– старайся давать своим сотрудникам чуть больше, чем даёт кампания. Мне кажется, это очень важно. По этой части я, например, некоторым своим ребятам покупал copilot, пробивал билеты на highload++, или отстаивал необходимость повышения зп. Очень приятно создавать комфортные условия для классных ребят.
– поддерживай связь с людьми, с которыми по какой-то причине перестаешь работать. Приведу цитату автора: "С работы ты можешь унести только две вещи: опыт и связи. Цени эти вещи."
#edu #teamwork
Книга "Думай медленно... Решай быстро" от лауреата Нобелевской премии по экономике – Даниэля Канемана
Недавно второй раз перечитал эту замечательную книгу и хочу её посоветовать всем, кто ещё не читал.
Главная идея книги вращается вокруг двух систем мышления, которые автор называет Система 1 и Система 2. Система 1 работает быстро и интуитивно, часто полагаясь на автоматические реакции и ассоциации. Система 2, напротив, медленная и аналитическая, требующая больше усилий и времени для обработки информации. Канеман показывает, как эти системы взаимодействуют и как часто наша интуиция может нас подводить из-за различных когнитивных искажений.
Что особенно ценно в этой книге, так это её практическая применимость. Автор приводит множество примеров из реальной жизни и результаты психологических экспериментов, которые иллюстрируют, как мы принимаем решения в разных ситуациях — от повседневных задач до сложных финансовых выборов. Он объясняет, почему мы склонны к ошибкам в оценке рисков и вероятностей и как наши эмоции могут влиять на рациональные решения.
Книга поможет лучше понять механизм своего мышления, повысить осознанность в принятии решений и избежать распространённых ошибок. Также позволит вам лучше понять себя и других, а также научиться принимать более взвешенные и обоснованные решения в различных сферах жизни.
#books
🚀 Автор @sberlogabig приглашает Вас в неформальный проект.
Минимальные требования – навыки Python или хорошие знания теории групп (в идеале GAP, SAGE). Загрузка несколько часов в неделю. Задача проекта – применить машинное обучение к теории групп. Целью проекта является статья в хорошем журнале, участники – соавторы.
Если Вам интересно участие – напишите @alexander_v_c (Александр Червов, к.ф.-м.н. мехмат МГУ, 25 лет math&DS, Kaggle, Scholar, Linkedin).
Чат для обсуждений
Вводный доклад
Пояснения по RL части
Краткая суть задачи - нахождение пути на графе от вершины А до вершины Б, но размер графа 10^20-10^50 – обычные методы не применимы. Решение пазла типа Кубика Рубика. Задача близка к прошедшему конкурсу Каггл Санта 2023. Математически – разложение элемента группы по образующим. Математические пакеты, которые частично могут решать эту задачу – GAP, SAGE.
Достигнутые результаты - уже сейчас мы можем за минуты делать то, что авторы работы DeepCube делали за 40 часов на многих GPU.
Оптимизатор 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