2135
Канал от Python-разработчиков: — востребованные инструменты — system design — softskills — лучшие практики разработки — подготовка к собеседованиям Увеличим твою ценность на рынке IT Для связи @sa_bul
Наш бесплатный курс "Командная строка для разработчиков"
Мы много лет готовим python-разработчиков. Подготовку начинаем с базовых знаний Linux, где прививаем желание и умение работать в терминале. Вдохновляясь курсом "Поколения Python" на степике, сделали бесплатный курс Командная строка для разработчиков, посвящённый терминалу в Linux. Начинающим разработчикам поможем преодолеть неловкость перед текстовым терминалом, опытным разработчикам покажем неочевидные и полезные в работе фишки для увеличения продуктивности.
Уроки курса:
— Команды и работа с файловой системой из терминала
— Модифицируем файловую систему
— Управляем сотнями файлов и пишем первый скрипт
— Знакомимся с текстовыми редакторами nano, mcedit, gedit, vim
— Разбираемся с процессами, jobs, fg, bg, ps, grep и конвейером
— Настраиваем терминал "под себя"
— Разграничение прав доступа и работа с учётными записями
#devfm
Справляемся с рисками
Две совсем несложные статьи (раз, два), посвящённые риску и управлению рисками.
В первой даётся определение риска – это сочетание возможности получить выгоду и вероятности потерь. Мы принимаем риск не ради него самого, а ради целей, которые хотим достичь.
Для анализа риска автор разделяет его на два компонента:
– Вероятность: насколько возможно, что негативное событие произойдёт?
– Последствия: какие убытки или проблемы оно принесёт?
Для оценки риска предлагается использовать матрицы риска, которые делят вероятность и последствия на категории: низкие, средние, высокие. Таким образом можно наглядно увидеть, какие стечения обстоятельств действительно рисковые.
На самом деле важно понимать структуру риска и инструменты для его анализа. Вместо расплывчатого "это слишком рискованно" можно попробовать выдать что-то осмысленное: "Вероятность низкая, но последствия критические, значит, это требует дополнительной подготовки".
Вторая статья посвящена управлению рисками – действиям, направленным на снижение риска.
По сути мы возвращаемся к составляющим риска:
– Снижение вероятности. Мы пытаемся сделать так, чтобы рискованное событие с меньшей вероятностью происходило.
– Снижение последствий. Мы уменьшаем ущерб, если событие всё же произойдёт.
Автор приводит не айтишный пример, но, в целом, неплохо демонстрирующий суть.
Нужно переправиться через реку:
Для снижения вероятности падения в воду мы можем:
– Использовать командные техники переправы
– Искать более мелкий участок реки для перехода
Для снижения последствий попадания в воду мы можем:
– Запаковать вещи в водонепроницаемые мешки, чтобы предотвратить их повреждение
– Разместить спасателей ниже по течению, чтобы минимизировать риск травм или утопления
#teamwork
Работаем со связанными ветками в Git
Наткнулся на любопытную статью о работе с ветками в гите во время разработки фичи, и как это дело можно упростить. Но обо всём по порядку.
Автор предлагает делить работу над задачей на несколько логически связанных частей. Каждая часть оформляется в виде отдельной ветки и сопровождается merge request-ом. При этом каждая ветка бранчуется от предыдущей. Например, feature-xyz/part-2 от feature-xyz/part-1, а feature-xyz/part-3 от part-2. Получается такой стек из веток.
Такой подход позволяет упростить ревью – каждый MR охватывает минимальный объем изменений, и создать историю коммитов, которая позволит читать изменения кода по шагам, понимая логику их внесения.
И всё выглядит хорошо до тех пор, пока не нужно внести изменения в part-1 по результатам ревью, а потом влить эти изменения в ветки part-2 и part-3. Или когда в основной dev-ветке появятся изменения, нужно также их затащить во все свои маленькие веточки. Тут приходит на помощь rebase со всеми сопутствующими приседаниями.
Чтобы избежать приседаний, автор предлагает решение: использовать опцию --update-refs команды rebase. В этом случае при ребейзе самой последней вашей ветки git сам обновит все родительские ветки.
Что думаете за такой подход? Выглядит замороченно, плюс нужно иметь высокую культуру в команде, чтобы все следовали договорённостям. По ощущениям, если пилите что-то действительно сложное и большое, когда в проекте много участников и важно ориентироваться в изменениях – выглядит жизнеспособно.
#skills #teamwork
State of Developer Ecosystem Report 2024
С 2017 года JetBrains проводит опросы, на базе которых готовит отчёты о состоянии индустрии. В 2024 году опросили 23к разработчиков. В отчёте есть разное интересное, имеет смысл ознакомиться с ним целиком. Мы же с вами посмотрим на отдельные моменты, которые сами считаем самыми примечательными.
Наш разбор результатов 2024 года читайте в статье. Ниже часть выводов оттуда.
Интересен блок с планами про языки программирования. Основной язык Python у 35% разработчиков, ещё 6% планируют его использовать. Самые большие планы на внедрение у Go (10%) и Rust (11%). Интересно, реализуется ли это. На рынке РФ вроде Rust не очень востребован.
Не использует виртуализацию всего 25% респондентов. 50% живут с докером, дальше есть нюансы. Удивлён, что не 90%.
Проникновение искусственного интеллекта в разработку довольно сильное. 70% пробовали, а 50% постоянно используют ChatGPT. Можно позалипать на цифры постоянного использования у других игроков: 26% у GitHub Copilot, 7% Google Gemini, 5% JetBrains AI, 3% Anthropic, 1% Tabnine, 2% локальный AI, 3% Codeium, 1% Blackbox AI. 1% Llama, 1% Gemini, 1% Cursor. Есть куда расти. Про остальных игроков я не слышал.
Занятная статистика по профиту от ИИ. Теперь ИИ является не только чатботом, но и заменой поисковику, помощником кодера, автоматизатором рутинных задач. Интересно, а есть ли уже бот, который code review в MR проводит? Если кто такое видел или использовал, поделитесь впечатлениями.
В блоке Developers' Life интересная статистика про затраты времени на код и на коммуникацию (созвоны, чаты, почта). Вроде опрос разработчиков, но 5% ребят тратят на код меньше 20% времени.
Интересен вопрос "самая сложная часть вашей работы". 38% отмечают понимание потребностей пользователей, 34% коммуникацию с командой (и ещё 16% с другими разработчиками). Проблема 32% в разборе чужого кода, и у 16% проблема в отладке. Непосредственно в написании кода сложности только у 15%, и в первую очередь эту часть сможет взять на себя ИИ. Остальные сложности, вероятно, пока останутся. А вообще всё выше подводит нас к важности софт скиллов, и об этом мы стали чаще писать. При этом 50% разработчиков работают в команде всего лишь из 2-7 человек. Одиночек 8%.
А в 2022 году мы обсуждали Stack Overflow Developer Survey.
#trends
The implementation of Rewind in Braid
Игра Braid написана одним разработчиком. Доклад от автора, как он реализовал бесконечную перемотку времени назад, учитывая ограничение игровых консолей, где нет условно бесконечной оперативной памяти.
Предлагается занятный вариант реализации – давайте хранить весь мир и его состояние сериализовать. И дальше куча хаков для оптимизации: неизменяемые объекты хранить в единственном экземпляре, фоновые частицы (чисто визуал, условно листья на заднем фоне) перегенерировать в похожем виде на основе случайного числа и текущего времени. Состояние мира хранится в виде цепочек с опорными кадрами (похоже на кодирование видео). Тут я не совсем понял, он предлагает хранить состояние целиком, а не разницу кадров.
Потом обсуждается хранение звука при перемотке. Завершает доклад ещё одна хитрая оптимизация. В раунде с кольцом замедления его способ хранения "примерного" состояния фоновых частиц не работает. Пришлось отдельное решение делать. Приятного просмотра!
#youtube #systemdesign
Databases in 2024: A Year in Review
Да, ещё один пост о базах :)
Любопытная, лёгкая и иногда захватывающая статья, посвящённая ретроспективе в области баз данных за 24 год.
Начинает автор с забавного: как Redis поменял лицензию более строгую, а Elasticsearch, наоборот, откатился на более открытую лицензию. Причиной всему облачные провайдеры, типа AWS, которые берут продукты и начинают их поставлять как сервис, тем самым мешая зарабатывать деньги компании-разработчику базы.
От себя добавлю, что уже давно есть более интересные альтернативы редису, о которых мы писали: DragonFly и KeyDB.
Продолжая статью, автор переходит в категорию "захватывающее" – о борьбе Snowflake и Databricks. Эти взаимоотношения можно описать, как в той самой поговорке про жабу и гадюку. В результате такой конкуренции продукты улучшаются и нам, как потребителям, это, конечно, на руку.
В этом году особенно часто на моём радаре появлялась DuckDB, которая упоминается в статье. Интересная база данных для аналитических запросов. Легко поднимается, написано куча расширений для Postgres, в результате достаточно просто начать использовать.
В оставшейся части статьи автор рассказывает набор новостей и фактов о самых различных базах, которые, наверняка, многие пропустили. Их тоже интересно посмотреть.
#database
Пятничное развлекательное
Забавная статья, в которой собраны всякие разные интересности о самой используемой базе данных – SQLite.
Автор собрал аж 24 пункта! Мне запомнилось несколько:
▫️Поддерживается всего тремя людьми three people.
▫️Супер покрытие тестами. На каждую строку кода приходится более 600 строк тестов.
▫️Особенно интересно, что, несмотря на открытый код, многие тесты не в open source.
▫️Ребята очень и очень упорно работают над обратной совместимостью. Текущая SQLite 3 совместима с первым релизом третьей версии в 2004 году.
▫️Не используют гит, используют самописное решение Fossil.
▫️Смешная история с именами временных файлов – изначально SQLite использовала префикс sqlite_ для своих временных файлов. Однако пользователи, обнаруживая эти файлы на своих устройствах, начинали звонить разработчикам среди ночи, думая, что это ошибка или вирус. Чтобы избежать подобных ситуаций, команда решила изменить префикс на обратное написание — etilqs_. Оно никого не смущает
#fun
За последнее время к каналу присоединилось много новых подписчиков, поэтому небольшое приветствие.
Канал ведут два увлеченных своим делом специалиста. Пишем о своём опыте, о разработке, об инструментах, о командной работе и управлении людьми, об архитектуре — обо всём, с чем сталкиваемся на практике. Периодически создаём свои учебные материалы, заходите к нам на MrAnetto/videos">ютуб, хабр и anetto1502">пикабу. В закреплённом сообщении есть навигация с хэштегами по нескольким направлениям.
В серии постов про архитектурные схемы мы обсуждаем, как можно документировать архитектуру и зачем оно вообще нужно в команде.
Рассказываем, как фиксируем зоны ответственности разработчиков и зачем.
Делимся опытом ведения дел, как заводим задачи, как структурируем, как отслеживаем выполнение.
Наш подкаст: Как руководить коллективами разработки (кто такой тимлид тимлидов).
А ещё у нас есть бесплатный курс на степике Командная строка для разработчиков с основами Linux.
Золотой Соер 2024
Приходите послушать нас на стрим Соера с победителями конкурса на лучший технический контент.
Недавно делился ощущениями от конференции ArchDays.
Хочу рассказать ещё об одном замечательном докладе "Как мы в Tinkoff принимаем архитектурные решения" от Александра Поломодова.
Особенно мне откликнулись следующие темы:
Какие архитектуры и архитекторы бывают – Enterprice, Solution, Software. По каждому типу даются ответы на вопросы: кто это делает, на каком уровне абстракции, для чего, какие инструменты используются, в какой нотации.
Более детально рассматривается Software Architecture, в том числе о внедрении работы над архитектурой внутрь команд.
Как принимаются архитектурные решения
– RFC (Request for Comments) – документ с описанием проблемы, предложением и обоснованием. Он публично обсуждается, после чего фиксируется решение.
– ADR (Architectural Decision Records) – все решения документируются, включая компромиссы и условия, при которых решение может быть пересмотрено.
– Рабочие группы – временные группы из активных участников разрабатывают предложения и координируют обсуждения.
Если сталкиваетесь с архитектурными проблемами или задумываетесь о том, как организовать процессы принятия решений, этот доклад может стать отличным источником информации.
#systemdesign
Друзья, сегодня стартует конференция Highload++. Всем, кто присутствует — хорошо провести время.
А для всех желающих из главного зала будет онлайн трансляция. В 11:10 будет, кажется, интересный доклад: «Можем ли мы с базой, но без кэш-слоя в 2024 году?»
Закон Конвея
Как-то так получилось, что в последнее время вокруг меня несколько раз упоминали закон Конвея.
На волне этого вспомнил статью от Фаулера, в которой он рассказывает о важности закона Конвея в разработке. Согласно этому закону, что любая разрабатываемая система будет отражать организационные связи между командами, которые создают эту систему.
Фаулер предлагает три подхода к учёту закона Конвея:
🔹 Игнорирование — не учитывать закон, что обычно приводит к проблемам в архитектуре.
🔹 Принятие — проектировать систему так, чтобы архитектура соответствовала структуре взаимодействия команд.
🔹 Инверсный манёвр Конвея — перестроить организацию команды для достижения желаемой архитектуры (часто применяется в микросервисах).
В заключении подчеркивается, что важно учитывать закон Конвея не только при создании архитектуры, но и на протяжении всего жизненного цикла проекта, организуя эволюцию архитектуры и организационных структур вместе.
#edu #systemdesign
Стрим: разбираем Fastapi + Docker
Сняли почти часовое видео для начинающих, смотрите где удобно youtube / rutube / dzen / VK.
В нём собираем приложение по доке FastAPI (кстати, документацию читать полезно, а их дока крутая). В видео фокусируемся на обвязке — код на гитлабе, проект в докере, в процессе используем Postman и смотрим web console браузера.
Предыдущий стрим про разработку небольшого проекта python-students.
#devfm #youtube #python
#СоерКлуб
Бекап постов за последнее время
Собрали посты, которые получили больше всего лайков, репостов и те, что понравились нам самим.
Материалы, подготовленные нами:
▫️Багскрам – что это и для чего нужен
▫️Как мы начали улучшать процесс в команде после анализа багов
▫️Опыт ведения дел
▫️Фиксация зон ответственности разработки – как и зачем
▫️Для чего нужны архитектурные схемы
▫️И снова о необходимости архитектурных схем
▫️Наш небольшой подкаст на тему: Кто такой тимлид тимлидов
▫️Шуточный пост на тему оценки задач
Обзоры статей:
▪️Отличный гайд от гугла по API
▪️Боль от распухающей базы данных
▪️Всё ли так просто с ретраями?
▪️Оптимизация Postgres за счёт порядка колонок в таблице
▪️Как в гугл пишут дизайн доки
▪️The ultimate docker compose cheat sheet
▪️RESTful web API design
Так же мы советовали несколько отличных книг:
🔹Книга "Думай медленно... Решай быстро" от лауреата Нобелевской премии по экономике – Даниэля Канемана
🔹Книга "Релевантный поиск"
🔹Книга "Getting Real"
#backup
When to write strategy, and how much?
Отличная статья Will Larson. Она посвящена созданию стратегии в инженерной команде с акцентом на выборе подходящего момента для её написания, определении оптимального объёма и способе внедрения.
В самом начале автор рассуждает о моментах, когда работа над стратегией действительно оправдана, таких как конфликт между командами или важные кадровые изменения, и объясняет, что не всегда правильным решением является создание стратегии "здесь и сейчас". Автор предлагает рассматривать три стратегических состояния: глобально согласованное, частично согласованное внутри команд и несогласованное, указывая, что разработка стратегии наиболее актуальна для ситуаций, когда команда находится во втором или третьем состоянии. Кроме того, если ситуация в компании ухудшается, но состояние стратегий ещё приемлемо, это может стать стимулом к началу работы над ними.
Следующим рассматривается вопрос оптимального количества стратегий. Автор рекомендует ограничивать количество одновременно разрабатываемых стратегий одной или двумя, чтобы обеспечить их успешное внедрение и избежать перегрузки организации. При этом подчеркивается важность постепенного роста стратегий и гибкого видения конечного результата, которое поддерживает принятие мелких шагов. На примере Uber: в какой-то момент возникла проблема надёжности сервисов и скорости их разработки. Для её решения была создана стратегия, направленная на обеспечение безболезненного деплоя и функционирования сервисов. Реализация этой стратегии постепенно привела к решению более глобальной исходной проблемы.
Далее самое интересное. Для внедрения стратегии нужно учитывать масштаб внедрения (команда или вся организация) и стиль изложения стратерии: запретительный (proscriptive, пример: "блокировать MR, если код не прошёл линтеры") или разрешительный (permissive, пример: "давайте использовать линтеры, вот основные правила, в каждой команде можно кастомизировать под себя"). Чем больше масштаб внедрения, например, на уровне всей компании, тем больше разрешительных пунктов должно быть. Иначе вряд ли стратегию получится внедрить.
Немаловажный момент, на который обращает внимание автор – оценка эффективности стратегии, а также её влияние на принятие различных решений.
Статья любопытная, как и многие другие от этого автора :)
#edu #systemdesign
DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)
В часовом видеоподкасте мы обсудили роли в ИТ-проекте из ~25 человек, занятых разработкой крупного веб-сервиса со сложной бизнес областью. Бизнес аналитики, системные аналитики, тим лиды, разработчики – кто на ком стоял и чем все эти люди занимаются. Представлен достаточно высокоуровневый взгляд на команду, если вы в таком не участвовали – вам точно будет интересно. В конце обсуждаем, можно ли малой командой делать большие проекты и, наоборот, делать большой командой малые проекты.
Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork
Ответ на задачу — проектируем динамическую фильтрацию
В прошлом посте описана задача, которую мы предлагали на собеседовании для разработчиков. Задача была такая: спроектировать фильтрацию результатов поиска товаров с учётом ограничений.
В задачах на проектирование чего-либо интервьюера интересует не столько сам ответ, сколько ход ваших мыслей. Вы можете не дойти до правильного ответа, или дойти с подсказкой. Рассмотрим потенциальные решения задачи и покритикуем их:
💡 Давайте присылать все данные на фронт и фильтровать там.
🚫 1кк записей передавать нецелесообразно. Более того, даже хранить фильтры на фронте не выйдет, так как они динамические и определяются конкретной выборкой. В любом случае, фильтровать должен бекенд.
💡В postgres можно спроектировать схему для хранения фильтров в связке со списком товаров, к которым эти фильтры можно применять.
🚫 Здесь не стали приводить конкретики, но отметим, что при таком подходе будут проблемы с динамическим обновлением счетчиков. А ещё такое решение несёт сложную ментальную нагрузку на разработчика.
💡Можно взять Elasticsearch или Manticore Search и подобное реализовать там.
❓По задаче требуется остаться с PostgreSQL и не вводить доп сущностей. Если можно поднять эластик, решение нормальное и можно обсудить детали.
💡Сведём задачу фильтрации к фасетному поиску. Для этого каждую единицу товара мы характеризуем набором конкретных признаков.
✅ В базе данных нам нужно завести отдельную колонку, где для каждого товара явно хранить набор его признаков и их значений. Для агрегации, подсчета количества и быстрого поиска по выбранным фильтрам можно использовать мощный механизм полнотекстового поиска.
Пример реализации такого решения с использованием полнотекстового поиска в postgres приведен в статье Faceted search using PostgreSQL full text search.
#database #skills #резюме
Когда ИИ заменит разработчиков, то...
Татьяна aka IT DIVA пишет о негативных последствиях замены миддл-инженеров на ИИ. О таких планах заявил Цукерберг на интервью у Джо Рогана (новость, оригинал подкаста на ютубе на 02:07:32). Конкретно прогнозам Цукерберга я бы особо не верил, потому что его мета-вселенные провалились. Но указанная тенденция действительно существует.
Если кратко резюмировать прогнозируемые Татьяной последствия от замены миддлов на ИИ, то получим примерно следующее (рекомендую прочитать пост целиком):
1. Если убрать с рынка джунов и миддлов, то мы усложняем будущий найм сеньоров.
2. Текущая кодовая база и так сложная, а написанный ИИ код будет ещё сложнее. Плюс на большом проекте добиться от ИИ результата будет сложнее.
По первому вопросу полностью согласен. Компаниям в среднем не нужны джуны, потому что обычно не способны выдавать результат, они отвлекают более опытных товарищей и джуны являются скорее инвестицией в будущего сотрудника, чем рабочими руками. Если будет ИИ-джун или ИИ-миддл, то компании предпочтут его. Это ещё и сокращает накладные расходы на коммуникацию, потому что команды нет, есть один условный сениор и его ИИ-ассистент.
Но, вероятно, это можно решить с помощью образования. Институт должен готовить пригодных для работы сотрудников. И крупные компании активно вовлекаются в образовательную движуху. Теперь нужно будет готовить разработчика, который умеет эксплуатировать ИИ для написания кода. Порог входа в профессию вырастет. Но он и сейчас довольно большой. Для разработки нужно знать много технологий, и чем дальше, тем больше. Если классическое образование не справится, то на помощь придут разные книги, курсы (в том числе бесплатные) и другие источники знаний.
А по второму вопросу совсем не могу согласиться. Описывается модель, словно ИИ будет рулить кодовой базой и компанией в целом. Но это не так, если остаются senior developer и прочие квалифицированные кадры. ИИ на текущем этапе может генерировать код, но решение о его внедрении принимает человек. Если эта практика сохранится, то и источник кода не важен, писал ли его человек или ИИ. Важно, чтобы принимающий решение субьект пропускал только качественный код. Тогда и проблем не будет. Причём ИИ может выступать ещё и в качестве высокоуровнего линтера, то есть стать ещё одной ступенькой обеспечения качества результата.
#edu
Задача на собеседовании — проектируем динамическую фильтрацию
Проводили собеседование на разработчика. Задачу для технической части взяли из практики, то есть это прямо то, чем в будущем предстояло заниматься собеседуемому, разве что с упрощением предметной области для понятности. Задача такая:
При поиске товаров на любой торговой площадке есть разухабистые возможности фильтрации товаров. Ваша задача — спроектировать функционал фильтрации результата поиска товаров.
Если вам на собеседовании поставили задачу в такой размытой формулировке, не пытайтесь сразу приступать к её решению. В первую очередь уточните требования и ограничения.
После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров
— количество записей в результате поиска может доходить до 1кк
— к полученным в результате поиска товарам можно применять множественные фильтры, у каждого фильтра есть набор значений
— у разных категорий товаров разный набор фильтров
— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.
— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.
— данные хранятся в postgres. Отдельно подумайте, как можно решить задачу, если у вас не стоит ограничение на базу данных
Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 15:00 понедельника.
#devfm #systemdesign #резюме
Пятничное развлекательное – инди-игра Braid
Очень атмосферный платформер-головоломка из 2008 года с шикарнейшей музыкой. Основная механика базируется на бесконечной перемотке времени назад. Но в каждом мире появляется механика, добавляющая новое измерение сложности. Появляются объекты, на которые перемотка времени не работает. Потом время завязывается на перемещение героя (идёт вправо — время движется, идёт влево — время отматывается назад). Потом перемотка времени вызывает теневого главного героя, это не объяснить простыми словами. В завершение появляется кольцо замедления времени. Каждый из этапов — просто божественная гимнастика для ума.
В прошлом году вышло дополнение Braid, Anniversary Edition. Я пропустил, планирую наверстать. Обещали новую графику и музыку (блин, куда лучше-то? Изначально было идеально!), доп контент от разработчика, и даже новую локацию — но про новую локацию фактуры найти не смог, мб её и нет.
Для особо упоротых в игре есть звёзды, достать которые реально сложно. С ними открывается секретная концовка. Спойлерить не буду, смотрите сами. Но за историей главного героя скрывается довольно необычная метафора об открытиях в науке.
Мировой рекорд спидрана 22:56, а TAS 18:45 (Tool-assisted speedrun, когда кнопки жмёт бездушная машина). Но игра настолько красива, что её уж точно не хочется заканчивать быстрее.
#games
Вторая часть статьи посвящена рассмотрению архитектур баз данных, которые значительно изменились за последние десятилетия (о первой части). Основное внимание уделяется тому, как технологические изменения, такие как развитие облачных технологий, новые модели хранения и вычислений, а также аппаратные инновации формируют подходы к проектированию систем управления данными.
Колоночные системы
Колоночное хранение данных стало прорывом для аналитических задач. Вместо традиционного хранения строк данные хранятся по столбцам, что позволяет эффективно сжимать данные, ускорять обработку запросов и оптимизировать доступ только к необходимым атрибутам.
Облачные базы данных
Переход в облако открыл новые возможности для масштабируемости и оптимизации ресурсов. Облачные архитектуры разделяют хранение данных и вычисления, что позволяет динамически добавлять вычислительные ресурсы по мере необходимости и экономить на инфраструктуре. Этот подход сделал базы данных доступнее для компаний любого размера, предлагая готовые решения без необходимости управлять сложной инфраструктурой.
Облачные базы данных изменили подход к проектированию систем, обеспечив гибкость, экономию ресурсов и возможность адаптироваться к изменяющимся потребностям. В будущем системы, не адаптировавшиеся к облачным технологиям, рискуют потерять актуальность.
Data Lakes и Lakehouses
Архитектуры Data Lake предоставляют возможность хранить данные в их необработанном виде, позволяя использовать их для самых разнообразных аналитических задач. Однако отсутствие управления метаданными и структурированности часто превращает такие системы в хаотичные хранилища. Lakehouses добавляют к Data Lake возможности традиционных аналитических баз данных, такие как структурированность, управление данными и поддержка транзакций, что делает их более универсальными. Их успех связан с решением проблем Data Lake, таких как отсутствие контроля над данными и низкая эффективность аналитики.
NewSQL системы
NewSQL системы появились как ответ на ограничения традиционных реляционных баз данных в масштабируемости и производительности. Эти системы предлагают преимущества транзакционных баз данных, такие как ACID-свойства, но при этом поддерживают горизонтальное масштабирование и высокую производительность для OLTP-нагрузок.
Внедрение NewSQL идёт медленно из-за высокой стоимости миграции с существующих систем и ограничений первых поколений таких решений.
Аппаратные ускорители
Использование GPU и FPGA для ускорения выполнения аналитических запросов стало новым направлением в проектировании баз данных. Эти технологии позволяют значительно увеличить производительность при обработке больших объёмов информации.
Несмотря на потенциал, аппаратные ускорители остаются нишевыми решениями из-за высокой стоимости внедрения и ограниченного круга задач, где их преимущества могут быть реализованы.
Блокчейн базы данных
Блокчейн-базы предлагают неизменяемость данных и распределённое хранение, что делает их привлекательными для задач, где нужно построить доверенную среду, но нет доверия между участниками. Однако их производительность и сложность остаются серьёзными ограничениями. Высокая вычислительная сложность и отсутствие широких сценариев использования делают их больше маркетинговым инструментом, чем практическим решением.
#database
Наконец-то дочитал отличную статью What Goes Around Comes Around... And Around..., посвящённую изменениям в области баз данных за последние 20 лет.
Статья поделена на два раздела: Модели данных и языки запросов и Архитектура баз данных.
Модели данных и языки запросов
В этой части рассматривается развитие ключевых моделей данных, каждая из которых внесла свой вклад в формирование современных систем управления базами данных. Среди них выделяются MapReduce, Key-Value хранилища, документоориентированные базы, колоночные базы, текстовые поисковые движки, а также векторные и графовые базы данных. Как правило, эти подходы возникали как ответы на конкретные задачи: ускорение обработки больших данных, обеспечение гибкости хранения слабоструктурированной информации, улучшение аналитики и моделирование сложных взаимосвязей.
Например, системы MapReduce сыграли важную роль в обработке огромных объёмов данных в распределённых средах, а Key-Value хранилища предоставили разработчикам инструмент для быстрого доступа к данным с минимальными накладными расходами. Документоориентированные базы данных предложили удобный способ работы с данными в формате JSON. В свою очередь, текстовые поисковые системы оказались незаменимыми в задачах индексации больших массивов текстовой информации, а графовые базы данных предоставили мощные инструменты для анализа сложных связей, например, в социальных сетях или рекомендательных системах.
Однако, как подчёркивается в статье, большинство этих подходов остаются нишевыми решениями, которые применимы лишь в узких сценариях. Их популярность обусловлена тем, что они эффективно решают конкретные задачи, но часто не обладают достаточной универсальностью для использования в более широком контексте. Это ограничивает их применение и приводит к необходимости интеграции их идей в более гибкие и универсальные системы.
Основной вывод главы заключается в том, что современные системы управления базами данных стремятся перенимать лучшие аспекты представленных моделей, объединяя их возможности в многофункциональных решениях. Таким образом, развитие идёт в сторону унификации и создания систем, способных адаптироваться к самым разнообразным задачам.
Об архитектурах баз данных будет в следующем посте.
#database
Docker в каждый дом
Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:
1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.
2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.
3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.
4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.
5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.
6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.
7. Просто откатываться к старой версии. Версионирование докер-образов позволяет запустить новую версию, и, если что-то пошло не так, откатиться назад за десятки секунд.
8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.
В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.
Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.
#skills #sudo #devfm
Почему не нужно отвлекать программиста
Во время работы программист создаёт в голове воздушные замки и работает с ними. Это требует немалой концентрации, и любое внешнее прерывание приводит к необходимости снова загружать в свою оперативную память сложные абстракции. В отличие от компьютера, который почти мгновенно выгружает и загружает информацию, кожаному мешку обработка прерываний даётся достаточно тяжело.
В статье Как поймать «поток», и как сделать так, чтобы он не сорвался объясняется, что такое состояние потока и как постоянное прерывание этого самого потока замедляет работу. По оценке автора, погружение в состояние потока "стоит" 15 минут, то есть любое прерывание имеет вот такие дополнительные накладные расходы.
В статье Как я использую папки в Телеграм для удобства мы делились опытом, как можно настроить Телеграмм для асинхронного общения, что как раз направлено на сохранение потока.
#edu
Как я использую папки в Телеграм для удобства
Меня несколько раз спрашивали, как я живу с сотней активных чатов и десятком групповых. Сегодня необычное — о нашем опыте применения папок в ТГ для асинхронной коммуникации по работе. Как работать с огромным количеством чатов с длительным сроком жизни? Как удобно организовать чтение каналов, если у вас сотня каналов к прочтению?
#devfm #edu #tools
Автоматизируй автоматизируемое
Это пост для исключительно для маководов.
Уже очень давно пользуюсь такой замечательной программой — Raycast. Это супер-разухабистая штука, которая может упростить повседневную рабочую рутину, да и не только рабочую.
Начну с банального: слёзы текут, когда вижу как кто-то неуклюже ищет нужное ему окно. Ой, это браузер, ой, это почта, блин, это IDE, фух, вот же он — телеграмчик!
Первое, что у меня настроено в Raycast — это хоткеи абсолютно на все программы, которыми я постоянно пользуюсь: Option + M — почта, Option + T — телеграм, option + B — браузер, и т.д.
Штука рекомендуема к использованию абсолютно всем. Периодически буду делать посты, рассказывая, что ещё интересного с помощью неё делаю.
Также стоит обратить внимание на плагины для Raycast — они предоставляют какое-то нереальное количество возможностей. Переводчик, управление зумом, очистка текста в clipboard от спец символов, конвертер времени из юникс формата — всё через плагины.
#devfm #tools
Некоторое время назад прочитал у Николая Хитрова пост о том, как он затащил к себе на проект gitlint — инструмент для валидации commit messages.
Хм, подумал я, конечно, подобных штук для валидации коммитов вагон и маленькая тележка. Но вместе с этим мне вспомнился один из наших проектов, куда как будто эта штука хорошо зайдёт. Закинул в тимлида и вот возвращаюсь с результатом.
Ребята внедрили себе gitlint и уже несколько месяцев полноценно им пользуются. По отзывам разработчиков: кому-то понравилось, что теперь коммиты нужно писать более дисциплинированно, кто-то и так их качественно писал, поэтому и не заметил разницы. Кто-то, конечно, воняет до сих пор, но на них не отвлекаемся :)
Мне же приятно, что ченджлог и история коммитов теперь выглядит стройненько и единообразно.
За вдохновением по правилам написания коммитов загляните сюда.
Чтобы всем этим добром легче пользоваться, существуют всевозможные плагины для вашей IDE.
Вдогонку посмотрите еще на comimitizen.
Не на каждом проекте нужны такие штуки, но может именно на вашем пригодится.
#devfm #tools
Пятничное развлекательное
Проблема вагонетки – это известная этическая задача, иллюстрирующая сложность морального выбора. Задача звучит так: представьте, что вы управляете рычагом, который может изменить путь вагонетки/трамвая. По текущему пути вагонетка мчится на пятерых людей, и, если ничего не сделать, она их собьёт.
Однако у вас есть возможность переключить рычаг и направить вагонетку на другую колею, где находится только один человек. Выбор стоит между тем, чтобы ничего не делать и позволить вагонетке сбить пятерых, или вмешаться и направить её на одного, сознательно жертвуя им ради спасения пятерых.
Наткнулся недавно на замечательный ресурс – Absurd Trolley Problems, моделирующий проблему вагонетки.
Действительно любопытно потыкать, а также посмотреть, как отвечают на эти непростые вопросы другие люди.
#fun #edu
Вдохновившись выступлениями прошлых лет, побывал тут на ArchDays 2024.
Были доклады поверхностные – за всё хорошее, против всего плохого, были доклады, где люди просто плохо готовились к выступлению или рассказывали сырой материал.
Однако удалось послушать и два хороших выступления:
▫️Замечательный своей концептуальностью доклад Александра Поломодова про архитектуру Т-Банка, в процессе которого было множество полезных отсылок, которые он опубликовал у себя в канале, и куда можно уже врываться и изучать.
▫️И очень практический доклад Виталия Минко на тему архитектурных принципов. Как только доклад появится на ютубе, обязательно сделаю пост о нём. А пока от него же доклад с одной из прошлых конференций на тему Технического радара. В нём затрагиваются темы: что такое Технический радар, для чего он нужен, когда и как его внедрять в своей компании.
#systemdesign