Kurgan-Telecom Ru | Информационные технологии

Делюсь впечатлениями о недавно вышедшей книге «Не усложняй! Управление проектами по методу P3.express» за авторством @daIlenkov и @lera_ilenkova

Это небольшая (~250 страниц) книга по управлению проектами на основе минималистичной системы P3.express, написанная лёгким и доступным языком. Отлично подойдёт для новичков. В сети уже немало отзывов, которые можно свести примерно к этой формуле.

Я хочу взглянуть на неё чуть глубже. Это книга-матрёшка.

Первый уровень действительно такой, каким его описывают в большинстве отзывов, — хорошо написанная книга, которую можно смело рекомендовать новичкам. На самом деле это ценное качество, потому что в интернете довольно часто спрашивают, что почитать/посмотреть/поучить новичкам по теме управления проектами. Отсылать сразу к PMBOK — и непродуктивно, и негуманно. Что там ещё рекомендуют из года в год? «Дедлайн» Тома ДеМарко? На самом деле отличная книга, люблю её, но сам же признаю, что жанр бизнес-романа имеет свои недостатки и подходит не всем. А надеяться на качественный онбординг на новой работе/роли не приходится — у руководителей проектов это устроено гораздо грустнее, чем у каких-нибудь айтишников. К тому же на эту первую работу ещё надо как-то умудриться попасть, и довольно часто это оказывается переходом на новую роль внутри компании. Но это идеальный случай, а ведь частенько бывает так, что какой-либо проект поручают не выделенному руководителю проектов, а опытному специалисту или руководителю подразделения — в довесок к основным обязанностям. Если до этого они не сталкивались с дисциплиной проектного управления и не имеют внутри организации поддержки от проектного офиса (или чего-то подобного), то приходится устраивать забег по граблям. Книга поэтапно показывает будни менеджера проектов — что вообще он делает и что от него ожидается. Так что если у вас нет возможности заранее ознакомиться с должностной инструкцией, положением о проектном управлении, регламентами проектных работ (а это мало где есть или есть, но частенько не работает), вы сможете понять, что от вас требуется и каких ошибок стоит избегать.

Группа точек мониторинга орошения, распределённых в горной местности, днём нагревается на солнце, а ночью остывает — суточный перепад температур может достигать тридцати–сорока градусов. Обслуживающий персонал заметил, что с наступлением осени обратная передача данных с части узлов LoRa стала давать редкие потери пакетов, а после повторного включения питания работа восстанавливалась. Первой реакцией часто бывает переход на более дорогой термокомпенсированный кварцевый генератор (TCXO). Однако по мере того, как LoRa IP четвёртого поколения повысил толерантность к отклонению частоты, TCXO перестал быть ответом по умолчанию на все проблемы температурного дрейфа.

Представим обычную обработку заказа. Сервис заказов публикует событие order.created. Сервис склада получает его и резервирует товар в PostgreSQL. После успешной транзакции обработчик должен отправить RabbitMQ подтверждение (Ack), чтобы broker удалил сообщение из queue.

Но процесс может остановиться после записи в PostgreSQL и до отправки Ack. RabbitMQ не знает, успел ли сервис зарезервировать товар. Broker видит только неподтверждённое сообщение, поэтому доставляет его ещё раз. С точки зрения доставки это правильное поведение. С точки зрения бизнеса один заказ теперь может зарезервировать товар дважды.

Другой сбой возникает раньше: PostgreSQL временно недоступен, и обработчик не может начать работу. Если сразу вернуть сообщение в queue через отрицательное подтверждение Nack(requeue=true), RabbitMQ почти немедленно доставит его снова. Пока база не восстановилась, все попытки будут бесполезными. Нужны задержка и ограничение числа повторов. При этом отложенное сообщение может пропустить вперёд более новые события, поэтому отдельно придётся решить вопрос порядка.

Так одна операция превращается в несколько независимых участков: запись события, публикация, хранение в broker, обработка и подтверждение. Между соседними участками остаются моменты, когда одна сторона уже выполнила действие, а другая ещё не получила подтверждение.

В статье разберём эти моменты по всему пути сообщения. Затем построим практическую схему для RabbitMQ и Go: добавим ограниченные повторы через retry queues, время жизни сообщения (TTL) и dead letter exchange, сделаем обработчик идемпотентным и определим, куда отправлять сообщения, которые не удалось обработать автоматически. В конце сравним этот подход с Kafka, NATS JetStream и Amazon SQS.

Я проектирую системы на LLM, и после каждого громкого ИИ‑инцидента мне прилетает одна и та же ссылка с одним и тем же вопросом: «а у нас такое может случиться?» Чтобы отвечать не на глазок, я завёл привычку разбирать каждый такой инцидент до конкретной технической причины. За последние месяцы таких разборов набралось три, и они удивили меня не сходством, а различием. Дыры, в совершенно разных местах: у одного проекта не проверялись источники, у другого, данные на границах системы, у третьего, права автономного агента. А вот причина одна: системы вокруг LLM строили люди, которые умеют писать промпты, но не умеют проектировать архитектуру.

Судите сами. Deloitte Australia возвращает правительству деньги за отчёт, в котором ИИ выдумал источники. В Миннесоте полиция четырьмя машинами блокирует на парковке журналиста, потому что сеть ИИ‑камер несколько дней вела его как угонщика, из‑за опечатки, сделанной за две тысячи миль от него. А основатель инди‑SaaS просыпается и обнаруживает, что написанный моделью код ночью отменил все подписки его клиентов и оставил бизнесу $38 месячной выручки.

У меня от трёх до пяти созвонов в день, почти все в браузере: Meet, Яндекс Телемост, ktalk, реже всего Zoom. Детали встреч мне нужны в тексте, иначе договорённости расползаются. Писал я звонки через OBS с захватом экрана, и на самих звонках началось веселье: звук временами жёстко квакал, всё чуть-чуть подвисало. Причину до конца не выяснял, моё предположение - процессор зажирался захватом и перебивал сам разговор; ktalk и браузер тут ни при чём. А экран, как потом дошло, мне вообще был не нужен.

Дальше вторая серия. Расшифровку я гонял своими Python-скриптами: конвертация → транскрибация → диаризация (разметка, кто когда говорил). На встрече с пятью участниками диаризация расставляла голоса крайне плохо, половину фраз всё равно восстанавливал по памяти.

Пошёл искать вариант, чтобы запись не мешала звонку, результат был приличный и всё крутилось локально: не хотелось ни отдавать записи в облако, ни платить подписку за минуты. Нашёл платный Audio Hijack, он подкупил лёгкостью и простотой настройки. Потом узнал, что на M-чипе быстрее всего у меня отрабатывает mlx-whisper на MLX: веса large-v3-turbo с Hugging Face, инференс на GPU Mac. Это архитектура Whisper, но рантайм — пакет mlx-whisper и бинарь mlx_whisper, не pip install openai-whisper и не репозиторий openai/whisper. Так собрался стек: Hijack пишет один mp3, mlx_whisper делает VTT, pyannote раскладывает по SPEAKER_XX. На 56-минутном звонке транскрипция заняла около пяти минут. Платный только Hijack — разовая лицензия, без подписки (цену смотрите на сайте Rogue Amoeba). Скрипты выложил в mac-call-transcribe под MIT. Ниже сборка, замеры с двух реальных звонков и грабли; повторяется на любом Mac с M-чипом.

В первой части агент включал свет, смотрел логи и собирал режим «Кинотеатр». Во второй — помогает новичку: объяснить, что есть в доме, где сыро и опасно, почему ночью что-то само гаснет, и по запросу сделать template для класса или объекта.

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

Несмотря на самостоятельность этой публикации, она раскрывает некоторые вопросы, поднятые ранее в статье "Как пройти… к третьей нормальной форме?"

Векторные базы данных в serverless-модели обычно обещают простую вещь: не требуется развёртывание и настройка, а провайдер берёт на себя управление хранилищем, масштабирование и обеспечение доступности. turbopuffer - один из лучших примеров этого класса: быстрый движок векторного поиска, использующий object storage в качестве хранилища, которым пользуются Cursor, Notion, Linear и другие.

Такой подход действительно снижает операционную нагрузку на команду, но он не бесплатен. Поэтому возникает закономерный вопрос: какая часть этих преимуществ нужна небольшому, четко определенному сценарию, и во что обойдется та же нагрузка на двух недорогих VPS с Manticore Search - по цене и по производительности?

В этой статье мы подтверждаем это цифрами: сравниваем две системы в одинаковых условиях на одном и том же наборе данных.

История создания GSM-DTMF-MQTT шлюза как замены телеграм (и вообще любых интернет-сервисов) в проектах домашней и не очень автоматизации.

Как известно, гипотеза Пуанкаре на сегодня является единственной решённой задачей тысячелетия.

Её формулировка довольно проста:Всякое односвязное компактное трёхмерное многообразие без края гомеоморфно трёхмерной сфере.

В этой статье мы создадим простенькую компьютерную визуализацию основных пунктов  упрощённого доказательства.

В прошлых статьях про инженерную архитектуру ГИГАХРУЩА мы разбирали, как в одном браузерном файле на чистом TypeScript держится тороидальный клеточный мир 1024x1024, кастомный WebGL-рэйкастер, симуляция A-Life и объемный генератор MESH PASS.

Сегодня мы расскажем историю создания речевого ядра проекта — историю о том, как попытка уйти от хардкода привела нас к теории категорий, дистрибутивной семантике и ошеломляющим открытиям: оказывается, если взглянуть на художественные тексты через чистую линейную алгебру, математика сама начинает «понимать» смысл слов и строить сюжетные конструкции.

В этой статье мы покажем, как с помощью векторного анализа корпусов, классов эквивалентности и PCA-осей нам удалось заставить Марковское ядро генерировать живую, контекстную речь для тысяч НПС — без сторонних фреймворков ("dependencies": {}), с задержкой 0 миллисекунд и 100% детерминизмом по SeedRng.

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

В законе Амдала, вроде, все правильно, но что-то не так и не то. Подобные сомнения возникли почти сразу после знакомства с ним. Но, правда, кто я такой, чтобы давать оценку? Да и интересовали меня на тот момент другие проблемы, к которым данный закон имел, как мне представлялось, косвенное отношение.

Однако, «давно не было такого и вот опять» – свежая статья на Хабре про закон Амдала, да еще и с настоятельной рекомендацией его изучать[1]. Пришло, видимо, время мне на эту тему высказаться. Хотя бы в пику его «обязательности чтения», т.к. для тех, кто «проектирует параллельные системы», подобные советы представляются не только излишними, а даже вредными.  

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

Так давайте попробуем понять кто прав, а кто нет.  А поможет нам математика, которую можно не понимать, можно даже не любить, но не уважать нельзя.

У Яндекс Лавки нет публичного API. А мне захотелось написать ассистенту «закажи молоко и что-нибудь к ужину» — и чтобы заказ реально уехал курьеру.

Рассказываю, как я отреверсил приватный веб-API Лавки прямо из браузерного трафика и завернул его в MCP-сервер: поиск, корзина, оформление с подтверждением суммы. А главное — про грабли, которые ловил воспроизведением, а не «на глаз»: заголовок X-CSRF-Token, зашитый в HTML; гонки за общую корзину и HTTP 409; «Раскупили» и «только из Большой Лавки», которые оказались не тем, чем выглядели; пустой способ оплаты; и удалённый деплой с OAuth, чтобы заказывать с телефона.

Код открыт (MIT), ставится через uvx. Осторожно: неофициально, реверс приватного API, оформление тратит реальные деньги.

Оплатить зарубежную подписку из России сейчас можно десятком способов, и почти все они непрозрачные. Пишешь боту «сколько будет ChatGPT Plus за 20 долларов» — получаешь цену в рублях, но не понимаешь, откуда она взялась. У одного сервиса выходит 1900 рублей, у другого за то же самое 2700. Официальный курс доллара в тот день — 78,4 рубля, то есть честная цена подписки 1568 рублей. Куда девается остальное и почему у всех по-разному?

Я потратил пару недель на то, чтобы это выяснить: писал ботам и менеджерам, просил посчитать одни и те же подписки, записывал итог в рублях и сравнивал с курсом ЦБ на день замера. Оказалось, что за пёстрыми ценниками прячется одна и та же формула, и, поняв её, переплату можно предсказывать заранее.

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

Во вторник министр финансов США Скотт Бессент заявил в эфире Fox Business, что администрация изучает китайские ИИ-модели на предмет украденной интеллектуальной собственности и рассматривает санкции: по его словам, внутри китайских моделей находят "водяные знаки" американских. А через несколько часов глава Nvidia Дженсен Хуанг в интервью Axios заявил, что Америке нечего бояться китайского ИИ — бояться стоит кампании по его запрету.

HEIF, HEIC и AVIF на Android через ImageMagick: хроника внедрения в два этапа. Без лишней воды — только проблемы и их решения.

21 июля 2026 года Госдума приняла законопроект «О цифровых валютах и цифровых правах» сразу во втором и третьем чтениях.

Большая часть положений нового закона должна вступить в силу с 1 сентября 2026 года. Речь идёт о требованиях к участникам рынка, правилах допуска инвесторов, ограничениях по отдельным операциям и других элементах будущей системы регулирования.

Однако полностью переводить рынок на новые правила начнут позднее. Требование проводить операции с криптовалютой через участников, включённых в реестр Банка России, должно заработать с 1 июля 2027 года. До этой даты предусмотрен переходный период, необходимый для лицензирования посредников и подготовки нормативной базы.

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

Одним из главных игровых событий лета 2026 года стал выход ремейка Assassin's Creed Black Flag, состоявшийся 9 июля. Игра про пиратов стала одной из самых популярных в серии, и о ней до сих тепло вспоминают многие фанаты. Однако из-за политики компании Ubisoft новинка недоступна в России. 

О том, стоит ли вообще играть в ремейк «Черного флага» и как добавить Black Flag Resynced в свою библиотеку без лишних хлопот и переплат — расскажем прямо сейчас.

Привет, Хабр! Сегодня System Design интервью стало неотъемлемой и, пожалуй, самой трудной частью найма разработчиков. От кандидатов требуют за короткое время спроектировать условный YouTube, Google Drive или Telegram, способный выдерживать миллионные нагрузки, не падать при отказе дата-центров и отвечать пользователю за считанные миллисекунды. И здесь большинство разработчиков сталкивается с суровой реальностью. Сложность в том, что на собеседованиях дают задачи на проектирование масштабных распределенных систем, но реальным опытом их создания создания обладают немногие. Задача проектирования может быть решена несколькими способами и не имеет единственного правильного ответа: Одно и то же требование можно реализовать многими способами, и каждый будет иметь плюсы и минусы. Нужно уметь проектировать высоконагруженные системы, учитывая проблемы сети: задержки, сбои серверов, обеспечение согласованности данных и балансировку нагрузки. Также требуется разбираться во множестве технологий и понимать, когда и как их применять.

Поэтому на интервью кандидат часто совершает критические ошибки: не умеет собирать требования и путает функциональные рамки проекта с нефункциональными (SLA, RPS, масштабируемость). Не видит нюансов и узких мест, из-за чего архитектура рушится при первой же пиковой нагрузке. Пытается строить отказоустойчивость «на бумаге», не понимая, как выбранные базы данных или очереди сообщений будут вести себя в реальном облаке. Лучший способ разобраться в тонкостях проектирования распределенных систем и увереннее чувствовать себя на архитектурных секциях — это создать такую систему с нуля в виде пет-проекта. Этой публикацией я начинаю серию статей, целью которой является желание поделиться опытом создания такой системы с нуля. Начнем с проектирования архитектуры, далее шаг за шагом реализуем ее на языке Go, развернем в облаке и оценим производительность. Будем проектировать систему сокращения ссылок из классической книги по системному дизайну.