Привет всем!

Ранее я писал о своём участии в конферецнии Пых.конф'25. На тот момент программа была ещё не сформирована, но время пришло - сейчас программа полностью готова!

Выглядит очень хорошо и мощно. А что самое прекрасное, это не "художественный пересказ документации", а доклады людей, которые реально двигают php индустрию и у нас, и в Мире.

Всю программу можно посмотреть тут 💙 - я там открываю зал "Readonly" со своим докладом про мьютексы и прочие примитивы синхронизации.

Да, кстати, у меня есть лишний билет, планирую его кому-то подарить, так что следите за новостями в канале!⭐️

Что отличает хорошего программиста от лучшего?
(не нажимай на фото, пока не прочтёшь пост)

Всем привет! В эфире нерегулярная рубрика #soft_friday, где я разгоняю мысли про софты.

Думаю, ни для кого не секрет, что оценка грейда - задача непростая. Что должен уметь условный сеньор? Делать git squash в терминале? Писать строго по SOLID? Контрибьютить по 100 задач в день? Возможно, для кого-то это действительно так, это можно хотя бы измерить. А как измерить условную "полезность" для бизнеса?

Есть кое-что, о чём многие разработчики не задумываются. В своей заметке "За что платят разработчику" я уже упоминал, что платят не за код, а за умение решать задачи бизнеса, чаще всего техническими средствами. Да, это часто код, но не всегда.

Умение задать правильный вопрос в нужное время, упростить решение, а иногда и вовсе отказаться от него, сэкономив бизнесу миллионы - вот настоящее "золотое" умение лучших разработчиков.

Кажется, что проще просто сделать фичу за пару часов, пусть ребята из бизнеса отстанут. Но в итоге:
1. это твоя работа,
2. работа коллег на код-ревью,
3. работа тестировщиков,
4. и так далее.

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

У меня было много случаев, когда один хороший вопрос срезал целый эпик.
Например, после релиза крупной фичи бизнес принёс новый запрос - прямо противоречащий логике системы. Сделать надо, важность доказана. Несколько раз собирались на мозговые штурмы, все решения были в духе "надо всё переписывать". Пока до меня не дошло, что можно сделать одно простое изменение за 10 минут - и всё. Вероятно, компания до сих пор живёт с этим решением, и всё работает как часы.

Чтобы видеть такие решения, нужно понимать бизнес и знать продукт, который ты разрабатываешь.

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

Что думаете по этому поводу?

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Что не так с CAP-теоремой?

CAP-теорема - это то, что рассказывают всем, кто впервые погружается в распределённые системы. Но если копнуть глубже, то становится ясно: эта модель больше вредит, чем помогает. Почему?

Казалось бы всё удобно. Можно всё классифицировать: CP, AP, CA. Но… проблема в том, что CA не работает.

🤩 Пара только CA (Consistency + Availability) невозможна в реальности. Partition tolerance (P) - это не опция, это обязательное требование к любой распределённой системе. Запрос поо сети всегда может закончится неудачей. Сеть моргнула, узел оторвало, проблема с маршрутизацией. То есть, получается, в реальной распределённой системе либо CP, либо AP.

🤩 Какие альтернативы?

📌 PACELC - если partition, выбираешь между A и C, а если нет partition, то между latency и consistency. Это более практичная инженерная модель. Она не требует, чтобы система всегда была готова к P. Это ближе к реальности: большинство времени нет разрывов сети, и вы можете позволить себе strong consistency без жертв доступности (хотя так почти никто и не делает).

📌 CAP давно критикует и Клеппман (это который книгу с кабанчиком написал) и предлагает "Delay-sensitivity model". То есть модель, разделяющая операции по тому, нужна ли им синхронизация по сети. Delay-sensitive (требуют ответа от других узлов) и Delay-independent (могут выполняться локально). Идея: система может быть построена из delay-independent компонентов, которые не страдают от сетевых разрывов. Это был в 2015 году.

📌 Тот же Клеппман в 2020 предлагает PIE model, описав её в своём кабанчике (Designing Data-Intensive Applications).

PIE =
* Partition tolerance (P)
* Immediacy (I) - насколько быстро можно получить данные
* Exactness (E) - насколько точно данные отражают реальное состояние
Эта модель акцентирует не на бинарных свойствах, а на времени получения и точности результата, что ближе к user experience.

Конечно есть и другие. Так что не так с CAP? CAP это теорема, а не инженерный инструмент. В доказательстве Гилберта и Линча (2002) partition — обязательное условие, иначе конфликта C и A не возникает. CAP = строгая формализация невозможности тройки C + A + P одновременно, и она не говорит ничего про “обычный” режим работы.

Какой подход вам ближе\понятнее? Кажется, что CAP совсем устарела.

Сейчас есть масса распределённых СУБД. Например, YDB - при partition приоритет у консистентности или Cassandra - Eventual consistency, но высокая доступность даже при падениях. И т.д.

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Всем привет.

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

Приятного просмотра 🍿

https://www.youtube.com/watch?v=ml4sH7inE8w

💙 Пых.конф’25 — главное PHP-событие года!

PHP сегодня в самом расцвете сил:

• 20 человек в ядре, финансируемых PHP Foundation.
• Релизы каждый год с десятками новых фичей.
• Async, типизация, атрибуты, выразительный синтаксис.
• Обслуживает миллиарды пользователей по всему миру.

Оставалась только одна проблема — русскоязычным инженерам не хватало пространства для обсуждения этим тем. Мы её решили.

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

• Асинхронность и протоколы для неблокирующего I/O.
• RAG в PHP-бэкендах и круглый стол «Кодим с ИИ».
• Архитектурные каноны: DDD, модульность, идемпотентность.
• Производительность: от памяти и массивов до воркеров и CI.
• Yii3, Doctrine, Swoole, WordPress и Битрикс — экосистема во всей красе.
• Не только PHP: YDB, Postgres, Docker, OpenAPI.
• Fail-митап и Открытый микрофон для всех, кто захочет высказаться.
• Игры и конкурсы на стендах партнёров — компаний, преданных PHP.

Мы сдедали то, чего сами ждали много лет. Не хватает только тебя.

Забрать билет | Ничего не пропустить | Собрать свою программу

Всем привет!

Недавно в одном из чатов по разработке увидел вопрос: "Как запомнить аббревиатуру ACID", если он используется только на собесах, а в работе - нет. Предлагались какие-то ассоциации, как в школе мы делали, когда заучивали бесполезные даты исторических событий, высоту гор или новые английские слова.
Подход, конечно, рабочий. Но я в корне не согласен, что в работе мы не применяем ACID. Применяем, каждый раз, когда взаимодействуем с руляционной СУБД. Про атомарность (A), консистентность (С) и изолированность (I), по идее должно быть всё понятно. Если нет, то вот видео, где я рассказываю что и как. А что на счёт долговечности (D - durability)? Как обеспечивается это свойство? Дайте это обсудим подробнее на примере PosrgreSql и операций create, update, delete.

✅ Как это реализовано в PostgreSQL
WAL (Write-Ahead Log) - ключ к durability. Прежде чем вернуть нам ответ, Postgres записывает в специальный журнал (WAL) информацию обо всех изменениях до того, как обновит настоящую таблицу или индексы. Клиенту возвращается успех только после гарантированной физической записи WAL на диск.
Буферы и фоновые процессы - физическая запись данных в таблицы и индексы происходит позже, в фоне (background writer, checkpointer). Это снижает задержки и нагрузку на диск, но WAL обеспечивает, что данные не потеряются.

✅ Где durability работает отлично
Классические одиночные серверы с нормальной нагрузкой - здесь durability работает как часы, все зафиксированные данные можно будет восстановить.
Нормальные потоки операций записи - задержки минимальны, WAL справляется быстро.

⚠️ Где есть ограничения и что важно учесть
Интенсивные потоки записи могут создавать очередь на запись WAL, повышая задержки коммитов - тут либо ждём, либо настраиваем параметры (`wal_sync_method`, commit_delay и другие) для оптимизации.
WAL - единственный источник для восстановления. По этому, если сервер сгорит вместе с диском, то всё, данные того.
Durability, по сути гарантия локального сервера. Если сервер упал, а репликаций или архивов нет, то уже восстановить данные из других мест не получится.
При горизонтальном масштабировании тоже могут быть сложности. PostgreSQL из коробки не умеет в шардирование.

✅ Как репликация усиливает durability
Streaming replication - почти мгновенно копирует WAL на запасной сервер. При падении основного данные на реплике доступны и актуальны.
Синхронная репликация - мастер ждёт подтверждения от реплики о записи WAL перед тем, как вернуть успех клиенту. Это значительно повышает надёжность. Но сказывается на перфомансе.
Архивирование WAL - долгосрочное хранение журналов транзакций в других местах позволяет восстановить сервер с любого нужного момента.

✅ Итог простыми словами
Durability - это уверенность, что записал - не потеряю. Ну, почти.
WAL берёт ответственность за сохранность данных при любых сбоях.
Физическая запись таблиц и индексов происходит асинхронно и в фоне для повышения производительности.
К сожалению, на 100% недостижим.
Репликация и архивирование делают систему более устойчивой.

Надеюсь, теперь ACID для вас не просто буквы, а понятные и обьясниемы процессы.

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Договариваться без предательства себя

Всем привет. Это нерегулярная рубрика #soft_friday. Хочу сегодня обсудить такую тем, как умение договорится не "наступая себе на горло". Мы часто хотим казаться хорошими, готовыми помочь, вовлечёнными. В итоге выбираем действовать себе в ущерб.
Договариваться - это не про "соглашаться на всё" или "прогибаться ради мира". Это про умение отстаивать своё и при этом находить решение, которое устроит обе стороны. Такой навык экономит нервы, время и сохраняет уважение - и к другим, и к себе.

Есть несколько простых шагов, как это сделать.
1️⃣ Определи границы
Заранее реши, что для тебя неприкосновенно. Это твои принципы и границы, за которые нельзя заходить, даже если на тебя давят.

2️⃣ Ищи общий язык, а не усреднённый вариант
Не обязательно «срезать углы», жертвуя важным. Иногда достаточно другой формулировки или альтернативного пути к одной цели.

3️⃣ Слушай за пределами слов
За любыми требованиями стоят страхи, ожидания или скрытые потребности. Поняв, что движет человеком, легче найти вариант, который устроит обоих.

4️⃣ Используй "да, если…"
Так ты сохраняешь готовность к диалогу и сразу обозначаешь свои условия. Это работает лучше, чем жёсткое "нет" или безоговорочное "да".

5️⃣ Можно быть гибким, но не мягким
Гибкость - это менять форму, не меняя сути. Уступки ради прогресса - да, отказ от ценностей - нет. Поменять позицию бывает сложно, так психологически заложено природой. Но проявляя гибкость вы показываете себя с лучшей стороны и делает вклад в доверие к себе. Позже этот счёт можно очень выгодно обналичить.

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

🆓 Кто хочет получить билет на Пых.конф'25 бесплатно? 💙

До Пых.конф'25 осталось чуть больше месяца. Единственная конференция в этом году, в которой основной фокус будет именно на php. Насколько я могу судить сейчас, получается масштабно, но, тем не менее, достаточно душевно.
На конфе можно не только послушать доклады, но и познакомится с ведущими экспертами в различных областях. Людьми, которые прямо сейчас делают php лучше и удобнее. Лично я всегда на конференции езжу для общения и новыми знакомствами.
Скоро финальное повешений цены, можно успеть купить билет по прежней. После повышения опять придётся жалеть, что не взял пораньше, ну 🤗

Спикерам билет не нужен, нас и так пускают. А лишний билет у меня потому что моя история на последнем пых.ап`е оказалась достаточно кринжовой чтобы получить бесплатный билет. Если честно, люблю рассказывать о факапах больше, чем об историях успеха 💀

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

Удачи!

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Всем привет. Начинаем неделю с полезного контента!

Сезон конференций в этом году для меня открыл Dump Spb (а я там открыл трек бекенда), я там рассказывал как доставлять продуктовые метрики так, чтобы они не терялись и почему это важно. А вчера, наконец-то, выложили видео докладов.
Вот тут можно посмотреть, а тут весь плейлист секции бекенда.

Приятного просмотра 🍿

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Вайбкодеры освоили opensource 🤗 или "с нейронками всё лучше" - https://github.com/abyesilyurt/vibesort/tree/main

Привет!
Конференции это отличное место для нетворкинга, но конференции явление не очень частное и не всегда в вашем городе. Я нашёл как решить эту проблему. Есть такое международное IT-сообщество - Coffee&Code. С тёплой душой и технологическим сердцем ✌️

Каждые выходные ребята проводят ***офлайн***-встречи для разработчиков и IT-специалистов — в формате душевной беседы за кофе. Без лекций и официоза, но с пользой и поддержкой.

👉Встречи на этих выходных в канале @coffeecode

Раньше ребята были только про мобайл, а теперь про всё IT:
Frontend, Backend, iOS, Android, DevOps, гейминг, дизайн, карьера, софт-скиллы — говорят на разных языках, у них не скучно.

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


Список городов и направлений:

🤖 Android
📱 Mobile
🍏 iOS
💬 и другие направления IT — внутри каждого города

Переходи по ссылке, выбирай город и приходи!

Всем привет. Сегодня пусть будет не про архитектуру. Точнее, и про архитектуру, но не ту.

Год назад мы с семьёй переехали в свою квартиру. Получился ещё тот квест, но это совсем другая история. Обустраиваемся тут, заканчиваем ремонт. Мне, как удалёнщику со стажем, важно сделать себе рабочее место и провести интернет хорошего качества. В принципе, первое, что появилось в доме, - это роутер. Причём это Huawei от Ростелекома. Не совсем отвратный, но и не топ. Причина появления именно такого роутера в том, что подключение происходит по оптике, а не витой паре. Мой прежний роутер такое не умел. В целом интернет работал, скорость была нормальная, всё в порядке. Так я думал, пока мы окончательно не перебрались домой. Не знаю, из чего у нас сделаны стены, но сигнал роутера нормального качества есть только в прихожей, где он и находится. Ну или в зоне прямой видимости. В других комнатах качество сигнала сильно деградирует.

Я скачал тулзу для измерения уровня сигнала и походил по комнатам. В спальне уровень сигнала 30%, на рабочем месте - всего 20%. При этом если смещаюсь на 30 сантиметров назад и встаю напротив двери, откуда роутер почти видно, сигнал уже 85%. То есть до рабочего места сигналу надо преодолеть 5 стен, и это его почти полностью гасит. В старой квартире ситуация была почти такой же (по препятствиям), но там сигнал и качество деградировали не так сильно (по субъективной оценке, я тогда не замерял).

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

⬇️
Все мои попытки исправить ситуацию не влезают в пост в телегу, по этому закинул лонгрид - https://teletype.in/@mifleo/my-network#hDCr 🤓

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Привет! Решил публиковать небольшие и несложные заметки из серии good to know, т.е. что было бы классно знать для разработки качественного системного дизайна.
#good_to_know

Кворум в распределённых системах: что это и зачем нужно

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

Синхронная репликация

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

Роль кворума

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

Как выбрать кворум

Обычно берут половину реплик плюс одну. Например:
📌 В кластере из 3 реплик - достаточно 2 подтверждений.
📌 В кластере из 5 реплик - нужно минимум 3 подтверждения.

Формула кворума

Для корректной работы системы должно выполняться условие: w + r > n

Где:
📌 w - минимальное количество реплик для записи.
📌 r - минимальное количество реплик для чтения.
📌 n - общее число реплик.

Это гарантирует, что чтение всегда возвращает актуальные данные, даже если часть реплик недоступна.

Типы кворума

📌 Кворум на запись (W) - минимум узлов, которые подтвердили запись.
📌 Кворум на чтение (R) - минимум узлов, которые должны вернуть данные.
📌 Кворум наличия/участников - минимальное число узлов, которые должны быть онлайн, чтобы система считала себя функционирующей.
📌 Кворум конфигурации - нужно согласие нескольких узлов, чтобы изменить конфигурацию (например, добавить или удалить узлы).

Допустим, в кластере из 3 реплики, если для записи нужно подтверждение от 2 реплик, а для чтения — тоже от 2, система будет работать корректно, даже если одна реплика временно недоступна.

Случайная карьера

Сегодня в своей нерегулярной рубрике #soft_friday хочу обсудить отношение к карьере. Думаю, все, кто читает меня здесь, в Телеграме, достаточно серьёзно относятся к своей карьере и к своей работе. И у меня к вам вопрос: строите ли вы карьерные планы на год, два, пять лет?

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

Я же отношусь к своей карьере как к проекту. У меня есть план, есть стратегия — где и кем я хочу быть через год, через пять, через десять. По этому плану я двигаюсь уже 5 лет, а на свободном рынке я не был ещё больше. Тут я имею в виду, что не выкладывал своё резюме в публичный доступ, не делал массовых рассылок на вакансии. Обычно это точечные отклики в конкретную компанию, на конкретную вакансию. Иногда, конечно, компании сами меня находят, но чаще всего приходится побороться, может быть даже провалить собеседование, вернуться и получить желаемое.

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

Построить свой карьерный план несложно. Важно ответить на вопросы: "Что я готов делать?", "Что я хочу делать?", "Что я не готов делать?". Понимая примерный портрет, можно построить векторы развития. Выбрав нужное направление, можно детализировать карту, в том числе и с датами, компаниями и чёткими пунктами. Всё как в system design: сперва абстракция, потом переходим к конкретике, опираясь на ФТ и НФТ.

А ещё важно иметь план «Б».

А у вас есть план на свою карьеру? Или готовы довериться случаю?

Ну, а если не понятно как двигаться и что делать - приходите, помогу.

За репост, подписку, лайки - отдельное спасибо ❤️

⸻

Давайте оставаться на связи ☄️

Всем привет. Первое сентября. Астрологи объявили неделю горящих костров рябин, месяц горящего сентября и вообще разбудите меня, когда сентябрь закончится. Ничего не забыл? 🍃🍃🍃

Для меня это время подвести итоги летнего планирования. 3 месяца назад я опубликовал пост о планах на лето.

✅️️ Курс по работе с командой от Стратоплан почти окончен Осталась последняя сессия. Есть много инсайдов. Не могу сказать, что вся информация для меня новая, но точно есть интересные мысли. И, конечно же, интересные знакомства.

✅️️ В планах было пройти

- стратегия
- проектный менеджмент
- мотивация
- технический продакт
- карьера

Все оказались информативными и интересными. Буду делиться инсайдами, полученными на этих занятиях тут в канале.

✅️️ пых.ап - про него написал тут. А вот и запись на канале Валентина. Митап получился очень душевным и клёвым.

✅️️ Провёл элективный курс для студентов университета Иннополис. Интересный опыт, есть куда расти и как можно улучшить материал и подачу. Через семестр вернусь туда с обновлениями.

✅️️ Лекции в Otus всё ещё веду. Но интенсивность снизил до минимума.

✅️️ На осеннем сезоне конференций подался на 3 конфы. Из них прошёл на 2. На Тимлидконф опять пролтетел. За то позвали выступить на Kazan Digital Week 2025.
В итоге в осеннем сезоне
- выступаю на Kazan Digital Week 2025
- выступах на пых.конф'25
- выступаю на HighLoad++ 2025

✅️️ На работе меняем стек с php на go. Не спрашивайте.

✅️️ Неожиданно для себя провел несколько карьерных консультаций и ментроских сессий.

Дальше планы на осень, но уже в другом посте.

Ещё хочу отдать кому-то билет на осеннюю Стачку. Мы собрали очень крутецкий php трек. Следите за апдейтами)

⸻

Давайте оставаться на связи ☄️

Привет!

Так, ну что. Оказывается, у меня есть ещё 2 проходки на одна на пых.конф и одна на Стачку на оба дня, где крутецкий трек по php (https://spb25.nastachku.ru/lp/proekt-1/doklady?track=3&sectionIds=168). Я хочу подарить их кому-нибудь из подписчиков. (не все 2 в одни руки, конечно, а по одной)
Так как рандом я не люблю, я придумал другой способ - небольшая форма-опрос https://forms.yandex.ru/u/68b82ba9e010db6291d3241e, я выберу среди заполнивших, чей ответ мне понравится больше всего, потом напишу в личку и договоримся.))

И, конечно, надо быть подписанным на мой канал)

Результаты подведу в воскресенье (07.09).

До встречи на конфе!

⸻

Давайте оставаться на связи ☄️