Россия в 2025 году вошла в топ-10 по числу новых долларовых миллионеров. За прошлый год в стране появилось их 22 тысячи. Это больше, чем в Китае несмотря на десятикратную разницу в численности населения.
Хабр и ЭКОПСИ как раз выясняют это в своём ежегодном исследовании. Пройдите опрос за 6–9 минут и поделитесь мнением — расскажите о компаниях, которые считаете лучшими.
Ежегодно результаты показывают, как меняется рынок, а с ним и восприятие IT-брендов работодателей.
👍Поделиться мнением о лучших IT-работодателях страны
Цитата Цитата Мы тоже принимаем участие в исследовании, ведь нам важно видеть, как мы растем, отвечаем вызовам времени и что о нас думают соискатели.
Спасибо за ваше мнение!🙏
Статический анализатор — мощный, но не всегда простой инструмент.
Поэтому мы подготовили для вас курс "Статический анализатор PVS-Studio на практике"!
Что вас ждёт:
- Вы узнаете возможности анализатора, актуальные требования ГОСТ и как устроено лицензирование PVS-Studio.
- Познакомитесь с локальной работой с PVS-Studio в плагине для IDE.
- Поймёте, как встроить PVS-Studio в рабочий процесс разработки и минимизировать ручную работу.
- Узнаете про использование PVS-Studio в роли SAST-инструмента для автоматического поиска ошибок и потенциальных уязвимостей в исходном коде.
- Разберётесь с системой мониторинга компиляции и разметкой предупреждений по стандартам MISRA на практике.
P.s. курс абсолютно бесплатный
Подробнее о курсе по этой ссылке.
Три метрики которые я перестал считать
Работаю с продуктами давно. За это время накопил список метрик которые выглядят полезными но на практике не помогают принимать решения. Вот три из них.
DAU и MAU в отрыве от контекста. Цифра растёт - хорошо. Падает - плохо. Но сама по себе она ничего не говорит о том почему. Видел продукты с растущим DAU и ухудшающейся юнит-экономикой одновременно. Рост привлечения маскировал проблему с удержанием.
NPS. Красивая цифра для отчётов. Но детракторы часто просто уходят молча не заполняя опрос. Промоутеры заполняют охотно. В итоге метрика смещённая. Видел продукты с высоким NPS и растущим churn одновременно.
Completion rate онбординга. Люди проходят кликая далее не читая. Метрика зелёная, понимания продукта нет. Об этом уже писал, но продолжаю видеть это в проектах снова и снова.
Общая проблема у всех трёх: показывают что происходит, но не объясняют почему. А решения нужно принимать именно на основе почему.
Сейчас больше времени трачу на качественные данные: разговоры с пользователями, сессионные записи, открытые вопросы в опросах. Медленнее и субъективнее. Но решения на их основе чаще оказываются правильными.
Какие метрики вы перестали считать или считаете что переоцениваете?
Начал писать тесты для бота. Оказалось не так страшно как думал
Долго откладывал тесты для своих ботов. Казалось что это боль: нужно мокать API, имитировать апдейты, непонятно с чего начать.
Начал с малого. Вынес всю бизнес-логику в отдельные функции которые не знают ничего про Telegram. Просто принимают данные, возвращают результат.
python
# Не так async def handle_payment(message: types.Message): amount = int(message.text) if amount > 10000: await message.answer("Сумма слишком большая") # А так def validate_amount(amount: int) -> tuple[bool, str]: if amount > 10000: return False, "Сумма слишком большая" return True, "" async def handle_payment(message: types.Message): is_valid, error = validate_amount(int(message.text)) if not is_valid: await message.answer(error)
Теперь validate_amount тестируется обычным pytest без всяких моков. Вызываешь функцию, проверяешь результат.
Звучит очевидно. Но я долго писал всю логику прямо в хендлерах и потом удивлялся почему тестировать неудобно. Оказывается проблема была не в тестах, а в архитектуре.
Покрытие пока небольшое, но уже несколько раз тесты поймали регрессию которую я бы заметил только в продакшене.
Кто тестирует ботов, как организуете?
Вебинар: ИИ в бизнесе — работает или только обещает?
Привет, Хабр! Мы тут уже не раз писали про ИИ: где он помогает бизнесу, где пока не очень, как вообще влияет на IT-индустрию. Тема горячая, бюджеты растут, пилоты запускаются один за другим. Но есть интересный момент: больше 90% компаний пробуют внедрять ИИ, а до полноценного запуска проектов доходят всего 7–10% (исследования легко найти у ICT Moscow и не только).
Мы в OXYGEN уже накопили опыт внедрений GPU-инфраструктуры, работы с нейросетями и языковыми моделями. И хотим поделиться тем, что выяснили на практике, вместе с коллегами из Aston, которые занимаются непосредственно запуском ИИ-проектов.
Поэтому приглашаем на вебинар:
Тема: «ИИ в бизнесе — работает или только обещает?»
Дата: 28 июля, вторник
Время: 11:00 мск
Формат: онлайн
Регистрация по ссылке, бесплатная.
Не будем рассказывать, какой ИИ замечательный и как скоро он изменит вообще все. Вместо этого разберем прикладные вопросы:
почему многие ИИ-проекты останавливаются сразу после пилота;
как выбрать сценарий внедрения с учетом реальных задач и бюджета;
какая инфраструктура нужна для разных типов нагрузок;
как подобрать конфигурацию серверов с GPU и не переплатить;
какие инструменты могут приносить пользу уже с первых дней;
где чаще всего ошибаются команды;
как оценить бизнес-эффект;
и как честно определить ту точку, в которой стоит задать вопрос: а нужно ли вообще продолжать проект?
Коллеги из Aston покажут реальные кейсы: что внедряли у клиентов, с какими сложностями столкнулись и к каким результатам пришли. Упомянем и о случаях, когда ожидаемой бизнес-выгоды получить не удалось, — потому что такие примеры зачастую полезнее историй успеха.
Основной фокус — инфраструктура, практические сценарии и измеримый результат. Вебинар будет интересен в первую очередь IT-директорам и руководителям отделов. Если вы отвечаете за IT-инфраструктуру, цифровизацию или внедрение новых технологий и пытаетесь понять, как довести ИИ-пилот до промышленного решения, приходите. Если просто интересно, тоже приходите!
Кто будет рассказывать:
Александр Будкин, IT-директор OXYGEN
Отвечает за технологическую стратегию нашей компании. Специализируется на построении отказоустойчивой IT-инфраструктуры и внедрении новых технологических решений для бизнеса. Расскажет, какая инфраструктура нужна для ИИ-нагрузок, как выбирать серверы с GPU под задачи.
Руслан Мельников, директор по развитию Aston Development
Отвечает за рост бизнеса и развитие продуктовых направлений компании. Расскажет, как ИИ-инструменты меняют работу команд изнутри и какие результаты получают заказчики.
И напоследок о нас (об организаторах):
OXYGEN — дата-центр и интегратор облачных решений, входит в ТОП-5 провайдеров ЦОД в России. С 2011 года обеспечивает бизнесу отказоустойчивую инфраструктуру с гарантией 100% uptime. Специализируется на гибридных и приватных облаках, при этом в портфеле у нас более 40 облачных сервисов.
Aston — разработчик корпоративного программного обеспечения для крупных заказчиков. Aston помогает бизнесу расти через качественную разработку, поддержку и облачные технологии.
В общем, приходите — будет интересно: Регистрация на вебинар
Подборка книг по эффективной работе в команде
Эффективная работа в команде строится на «трех китах»: доверии, четких целях и умении конструктивно общаться. Именно продуктивное взаимодействие с коллегами позволяет быстрее и качественнее достигать общих результатов.
Собрали подборку книг, которые помогут отработать эти навыки на практике.
«Наука общения», Ванесса Ван Эдвардс
Практическое руководство о том, как начинать разговор, производить первое впечатление, считывать эмоции и невербальные сигналы, поддерживать интерес собеседника и увереннее чувствовать себя на встречах, переговорах и мероприятиях.
«Пять пороков команды», Патрик Ленсиони
Бизнес-роман о руководителе, которая помогает конфликтующей команде вернуть эффективность. На примере этой истории автор разбирает пять ключевых проблем. Вторая часть книги помогает диагностировать эти проблемы и работать с ними.
«Идеальный командный игрок», Патрик Ленсиони
Книга о трех качествах, которые помогают эффективно работать с другими. Автор объясняет, как оценить собственные сильные стороны, понять, какие качества стоит развивать, и выстраивать взаимодействие внутри команды.
«Правила команды. Искусство думать вместе», Максим Поташев, Павел Ершов
Авторы рассказывают о жизненном цикле команды, распределении ролей, разных стилях мышления, лидерстве и коллективном решении сложных задач. В книге есть тесты для определения своей роли и зон развития.
«Как создать настоящую команду», Дэвид Шервин, Мэри Шервин
Сборник практических алгоритмов и рабочих ритуалов, которые помогают команде договариваться об общих правилах и ценностях, принимать решения, давать обратную связь и справляться с конфликтами.
Считаем окупаемость WMS через бизнес-процессы: новый выпуск подкаста «Сначала процессы»
В управленческом отчёте маржа и операционные расходы выглядят предсказуемо. На складе часть убытков проходит по статьям, которые в эту отчётность не попадают.
Это шестой выпуск подкаста INTEKEY «Сначала процессы» и второй в тематической серии про окупаемость WMS. Предыдущий выпуск серии считал окупаемость через персонал: зарплаты, текучку, стоимость найма. Этот рассматривает только механику складской рутины, без учёта людей.
Сравнение «12 млн за WMS — дорого» строится относительно нуля. На практике склад уже платит эту сумму каждый день: транспортные компании получают деньги за повторные рейсы из-за ошибок, банки — проценты по кредитам на закупку товара, который физически есть на складе, но его не могут найти.
Брак комплектации 1,5–2% на первый взгляд означает высокую точность. Полная стоимость одной ошибки складывается из нескольких шагов: повторная поездка, приёмка возврата, пересборка заказа, время менеджера на разговор с клиентом, корректировочные документы в бухгалтерии. Для российского B2B это около 4 000 ₽ за случай. При 500 отгрузках в день и 2% брака — больше 200 ошибок в месяц, около 800 000 ₽.
Товар физически лежит на складе, но недоступен для продажи, пока не отражён в системе. Приёмка на 150–250 строк силами трёх человек занимает около 4 часов: разгрузка, подсчёт, разбор накладных, звонки поставщику при расхождениях. Всё это время товар не виден отделу продаж. WMS с ASN (предварительным уведомлением об отгрузке) делает товар доступным к продаже в момент сканирования на воротах и сокращает процесс до 1,5 часов — около 460 000 ₽ в месяц освобождённого ресурса.
Инвентаризация с остановкой склада повторяется четыре раза в год. Прямые расходы на одну такую операцию — около 250 000 ₽ (переработки, доплаты, простои), то есть миллион в год. Цикличный фоновый пересчёт через ТСД убирает необходимость останавливать склад: расхождения фиксируются по мере появления, а не раз в квартал.
Точность остатков около 91% на ручном складе создаёт разрыв между системой и реальностью: закупщик видит в ERP отсутствие товара и заказывает новую партию, хотя старая лежит в другом углу склада. При запасе 90 млн ₽ разрыв 8,5% замораживает около 7,5 млн ₽. При стоимости капитала для бизнеса около 25% годовых это около 160 000 ₽ в месяц дополнительных расходов.
🎧 Выбирайте удобную для вас платформу для прослушивания: https://intekey.mave.digital/
📖 Статья, на которой основан выпуск: https://intekey.ru/articles/skolko-stoit-wms-biznes-processy/
Первая версия генератора кода готова. Сделал я его через IIncrementalGenerator и она очень сильно не оптимизирована, но да ладно он мне все ровно нужен был только ради следующей статьи про диагностику dsl
Русскоговорящий хакер использовал Gemini для контроля ботнета из восьми компьютеров стоматологических клиник
Именно такими заголовками пестрили новостные ленты на этой неделе в западных СМИ. Давайте разберемся, что произошло и действительно ли данная новость достойна звания новости.
В понедельник, 20 июля, на известном новостном агрегаторе thehackernews.com вышла одноименная статья, основанная на исследовании японо-американской компании в сфере кибербезопасности Trend Micro. Как утверждают авторы статьи, исследователи обнаружили русскоязычного злоумышленника под псевдонимом bandcampro, который использовал Google Gemini CLI как полноценного помощника при проведении реальных атак. Анализ основан на более чем 200 логах сессий Gemini CLI за период с 19 марта по 21 апреля 2026 года.
Специалисты называют это одним из первых документированных случаев, когда LLM понимает существующую инфраструктуру атаки, самостоятельно пишет код, исправляет собственные ошибки и помогает администрировать действующий ботнет. По оценке Trend Micro, во время миграции инфраструктуры сам злоумышленник выполнил лишь около 11% действий, остальное сделал ИИ: во время подготовки инфраструктуры возникли ошибки (502 Bad Gateway, блокировка Cloudflare, проблемы с HTTP-заголовками), однако Gemini сам диагностировал проблемы, предлагал добавить нужные заголовки, определял необходимость User-Agent и корректировал запросы. По мнению исследователей, ИИ использовался уже не как генератор кода, а как инженер по эксплуатации инфраструктуры.
Ну и как вишенка на торте, все инструкции (ради чего и была, наверно, написана статья) были на русском языке.
Однако, если детально проанализировать текст исследования и написанной на его основе статьи, мы не увидим ничего нового. Обход, злоупотребление и эксплуатация цензуры ИИ уже существует достаточно давно и компании-разработчики пытаются активно защититься от данного вида атаки. В данном случае, несмотря на громкое имя, Google оказался существенно уязвим, раз в течении нескольких месяцев ее детище активно использовалось для описанных в статье действиях.
С моей точки зрения, само по себе исследование интересно не потому, что найден новый джейлбрейк, а потому что появился хорошо задокументированный кейс: опубликованы реальные логи злоумышленника, показано длительное использование ИИ-агента в живой атакующей инфраструктуре и количественно оценена доля работы, выполненной AI. Исследование помогает понять как думает злоумышленник, последовательность его шагов и, самое главное, цели. В принципе можно сказать, что из Gemini получился симбиоз Honeypot и SIEM, который записал подробные действия хакера.
п.с. Вопрос: насколько быстро удалось бы обнаружить активность bandcampro, если бы среди исследователей не оказалось специалистов, свободно читающих русскоязычные логи? ;)
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте
С момента написания прошлой статьи про мою самописную товароучетную систему для работы с маркировкой «Честный Знак», я добавил новых фич и поправил существующие ошибки. Основные изменения следующие:
В Остатках в карточке товара появилась кнопка «Списать», позволяя сделать быстрое списание с нулевой ценой и выбором причины: утеря, собственные нужды, производственные цели, безвозмездная передача, отзыв с рынка. Данные нужно подавать также вручную, но для учета полезно.
Добавлен вид документа в продаже: поле «Вид док-та» в шапке заказа (Прочее, УПД, Товарная накладная, Акт приёма-передачи, Кассовый чек).
Появилась кнопка «Скачать КМ в CSV» в корзине Продаж для скачивания КМ в формате «для ввода/вывода из оборота» для вставке в ЭДО при передаче УПД.
Дропдаун «Статус» теперь показывает статус ЧЗ для проданных товаров.
Появилась возможность выделить и произвести массовую проверку статуса ЧЗ для выделенных товаров (чекбоксы + кнопка) на вкладках Остатки, Продано, Вывод из оборота.
Появилась колонка «Статус в ЧЗ» в таблицах Остатки и Вывод из оборота
Сделано автоподтверждение отчёта о выбытии при статусе ЧЗ равном «Выбыл» (RETIRED/WITHDRAWN/WRITTEN_OFF)
Сделано сохранение активной вкладки при перезагрузке страницы
Введена новая логика быстрой продажи: в шапку заказа: номер заказа, склад списания, дата продажи, добавление нескольких товаров по КМ/артикулу/EAN-13 с ценой за позицию в корзину с одинаковым номером заказа, КМ для Маркетплейсов отображается в корзине и копируется кликом, сделан Live-поиск при вводе кода с полной информацией о товаре.
ПО я писал для своей товарной группы «Игры и игрушки», но оно должно подходить и для других товарных групп потребительских товаров.
Сразу напишу про API: авторизация по ЭЦП и получение общего статуса по КМ все еще ведется по 3 версии API Честного Знака, как и например работа с МОД, а что-то уже работает только по 4 версии API (например ввод-вывод из оборота).
Kubernetes к 2035 году: стандарт, невидимая инфраструктура или история?
Kubernetes уже выиграл войну оркестраторов. Но что происходит с технологией, когда она становится стандартом — она взрослеет или превращается в легаси, о котором все знают, но никто не хочет разбираться?
В новом выпуске «В SREду на кухне» вместе с Александром Невским, руководителем юнита k8s в Infrastructure Platform Авито, поговорили о том, куда Kubernetes движется дальше — и что это значит для инженеров, которые с ним работают сегодня.
Что на повестке
Становится ли Kubernetes проще или сложнее с каждым годом — и почему ответ неочевиден. Почему компании приходят к десяткам кластеров и как Fleet Management превращается в отдельную инженерную дисциплину. Заменит ли платформенная инженерия Kubernetes или просто спрячет его поглубже. Как LLM уже меняют работу DevOps и SRE — и кто вообще будет управлять инфраструктурой через десять лет.
Отдельно — прогноз на 2035 год. Без гарантий, но с аргументами.
Если вы работаете с Kubernetes и хотите понять, стоит ли копать глубже или достаточно уметь писать манифесты — этот выпуск про вас.
🔵 VK Видео
📺 YouTube
📌 RuTube
Ⓜ️ Mave
День открытых дверей онлайн-магистратуры МФТИ «Разработка ИТ-продукта»
Приглашаем на открытый эфир, который будет полезен тем, кто планирует поступать на программу «Разработка ИТ-продукта» в 2026 году и хочет заранее разобраться, как устроены обучение, практика и процесс поступления.
Расскажем, какие дисциплины входят в учебный план, как студенты совмещают магистратуру с работой, над какими проектами работают во время обучения и какие карьерные траектории могут выстроить после выпуска.
На эфире обсудим:
— Как устроена программа «Разработка ИТ-продукта» и кому она подойдет.
— Какие навыки получают студенты и как проходит работа над практическими задачами.
— Как обучение помогает расти в разработке, переходить к проектированию архитектуры и запускать собственные ИТ-продукты.
— Как устроен процесс поступления в 2026 году: какие документы потребуются и как подготовиться к вступительным испытаниям.
К встрече присоединится выпускник программы, который поделится опытом обучения и расскажет, как полученные знания помогли ему в работе.
👥 Специальный гость: Антон Устинов — академический руководитель программы, директор по технологиям и информационным технологиям (CTO/CIO) с более чем 15-летним опытом в разработке и проектировании архитектуры финтех- и EdTech-продуктов (Сбер, Exante, Click и SmartBank), кандидат экономических наук и сертифицированный архитектор Сбера.
📅 Дата: 29 июля (среда)
⏰ Время: 18:00 (Мск)
🔗 Регистрация:
ВКонтакте: https://vk.com/app6379730_-224205661#l=30&auto=1
Telegram: https://t.me/mipt_events_bot?start=dl-1784623748d866ee49855e
Ближайшие события
Монитор CAN из Отладочной Платы JZ-F407VET6 и TFT экрана.
Реализовав на этой отладочной плате функционал PCAN, можно получить мощный инструмент анализа CAN-шины на компьютере. Но иногда удобнее использовать автономный монитор расшифровывая пакеты в контроллере и выводя их на экран.
Экран подлючается по SPI, а на плате единственный порт выведенный на разъём SPI2. Также на разъёме платы P3 присуствует питание 3.3В, а кроме SCK и MOSI выведено еще 4 сигнала, задействуем их для CS, DC, RST экрана и на оставшийся сенсорную кнопку для отправки управляющей команды.
Проверяемое ЭБУ передаёт значения напряжения и тока АКБ, следовательно расшифровав их, можно вывести на экран значения в виде стрелочных приборов. Остальные параметры выводятся в окне статуса. В нижней части экрана выводятся принятые пакеты в шестнадцатиричном виде и общий счетчик пакетов.
В качестве основы проекта использовался pcan_pro_x, упомянутый в одной из публикаций Александра посвящённых этой плате, код инициализации и отрисовки экрана любезно предоставил Google Gemini.
Ссылки на матерьялы:
Обзор учебно-тренировочной платы JZ-F407VET6 (или электронная парта)
T-shaped снова в моде?
Подняли тут вопрос, о том что мы снова движемся от специализации в T-shaped специалистов. Компании планируют сокращать персонал и одновременно с тем надеятся на усиление текущих специалистов за счет ИИ. В некоторых случаях это потребует замены текущих команд или как минимум отдельных людей, на агентно-ориентированных.
В обиход входит слово tiny teams. По представлениям сбера (это их инициатива), это компактные команды в несколько человек с большой степенью автономности находящиеся внутри ai sdlc, где все процессы изменены, где все знания доступны агентам и так далее. В общем ai native организации, вместо (зачеркни ненужное) бирюзовых, agile и других слов.
Пару мыслей про это от меня и других ребят, с которыми мы кулуарно общались. Во-первых сама тенденция возврата к фулстек режиму, во многом определяется не тем что у нас появился ИИ, а тем что идет общий экономический спад и компании сжимаются. А в таких случаях обязанности перераспределяются среди оставшихся. И наоборот, когда все активно развивается, происходит дробление обязанностей так как людей становится все больше и процессы становятся все сложнее.
Сейчас же ИИ действительно позволяет увеличить производительность, что само по себе приводит к укрупнению зон ответственности, но это явление временное. Когда агенты станут такой же обыденностью как персональные компьютеры (представьте разницу между теми у кого они были и у кого их не было в 80 годы), то для увеличения производительности труда снова придется дробить ответственности и брать больше людей.
Во-вторых, есть серьезные опасения, что сильных спецов в принципе всегда было мало, а тут мы как будто бы хотим лучших их лучших. Откуда их брать? И насколько людей действительно хватит? Мы не можем бесконечно масштабироваться, ИИ очень быстро уперся в ограничения кожанных. А комфотная работа для многих превратилась в изматывающий марафон на скорости стометровки.
Через 5 лет мы будем оглядываться назад и говорить о том, как все было очевидно, вот это работает, а вот это бы не заработало никогда. Как говорится, знал бы прикуп жил бы в Омске
Как связать контейнеры Nginx и PHP в Docker Compose, чтобы Nginx мог проксировать запросы?
Допустим, вы пытаетесь развернуть связку из веб-сервера и PHP. Контейнеры поднимаются, но веб-сервер выдает ошибку сети и не может достучаться до PHP-бэкенда. Разберемся, что нужно прописать в конфиге Nginx, чтобы они увидели друг друга.
Чаще всего подобная проблема возникает из-за того, что контейнеры изолированы друг от друга на сетевом уровне, либо в конфигурационном файле веб-сервера некорректно указан адрес целевого хоста. В экосистеме Docker Compose встроенный DNS-сервер автоматически сопоставляет имена сервисов с их внутренними IP-адресами. Поэтому не нужно прописывать статические IP — достаточно правильно использовать имена, заданные в манифесте.
Для того чтобы контейнеры могли успешно взаимодействовать по сети внутри Docker Compose, их нужно поместить в единое сетевое пространство и правильно настроить проксирование.
Чтобы Nginx мог передавать запросы PHP-FPM, необходимо:
убедиться, что оба контейнера находятся в одной сети (
app_network),указать в конфигурации Nginx правильный адрес PHP-контейнера (в нашем примере это
php:9000, гдеphp— имя сервиса в docker-compose.yml).
Шаг 1: Проверка манифеста docker-compose.yml
Убедитесь, что для обоих сервисов явно выделена одна общая сеть. Пример корректной структуры:
version: '3.8' services: nginx: image: nginx:latest container_name: nginx ports: - "80:80" volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf - ./nginx/html:/var/www/html depends_on: - php networks: - app_network php: image: php:8.2-fpm container_name: php volumes: - ./php:/var/www/html networks: - app_network networks: app_network: driver: bridge
Шаг 2: Настройка конфигурации Nginx
В блоке location, отвечающем за обработку PHP-скриптов, в директиве fastcgi_pass вместо 127.0.0.1 или localhost необходимо подставить имя сервиса PHP из файла конфигурации:
server { listen 80; server_name localhost; root /var/www/html; index index.php index.html; location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_pass php:9000; # Связь с PHP-контейнером fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; } }
Директива depends_on в блоке Nginx гарантирует, что веб-сервер не начнет стартовать раньше, чем поднимется контейнер с PHP. Это предотвратит падение Nginx при первичном запуске окружения, если он не сможет сразу разрешить DNS-имя php.
Если вы хотите глубже разобраться в сетевых механизмах, управлении volumes и оркестрации контейнеров, читайте наш полный материал: Docker Compose и основы работы с контейнерами.
Поступить в магистратуру, чтобы запустить стартап: как это работает
В корпоративном бэклоге почти всегда есть задачи, до которых месяцами не доходят руки: проверить гипотезу, собрать прототип, автоматизировать процесс. Во время магистратуры одну из них можно взять как проект, системно проработать и защитить как выпускную работу.
28 июля проведем эфир «Запуск корпоративного стартапа во время обучения: как совместить работу и учебу с максимальной пользой».
На открытой встрече выпускники онлайн-магистратур Центра «Пуск» МФТИ и представители компаний расскажут, как развивали корпоративные стартапы во время обучения.
За три года наши студенты разработали и защитили более 50 проектов для Hoff, Сбера, билайна, НИИАС РЖД, НЛМК, Совкомбанка, МКБ, Zecurion, GreenData и других компаний.
В программе:
🔹 Какие корпоративные стартапы выпускники разрабатывали во время обучения и для каких компаний.
🔹 Какие задачи стояли перед командами и какие решения они предложили.
🔹 Как студенты совмещали основную работу, учебу и разработку реального продукта.
🔹 Как работа над корпоративным стартапом повлияла на карьеру и профессиональное развитие выпускников.
🔹 Как прийти в магистратуру с проектом своей компании или взять задачу от индустриального партнера и развивать во время обучения в магистратуре Центра «Пуск» МФТИ.
📅 28 июля (вторник)
🕖 19:00 (Мск)
💻 Онлайн
Участие бесплатное. Необходима регистрация.
ВКонтакте: https://vk.com/app6379730_-224205661#l=31&auto=1
Telegram: https://t.me/mipt_events_bot?start=dl-17846368420ebf8e1ae9f2
На Бирже заказов Инфостарта за неделю с 15 по 22 июля появились новые проекты для разработчиков, аналитиков и консультантов 1С. В подборке - настройка отчетов и обменов, работа с банковскими выписками, перенос данных, интеграции с CRM и диагностика ошибок в учетных системах.
На этой неделе заказчикам нужны специалисты для следующих задач:
Автоматическое определение договора при загрузке банковской выписки в 1С:Бухгалтерии 3.0.
Настройка отображения остатков Центральной базы при подборе товара в УТ 11.5 РИБ.
Поиск и исправление ошибки закрытия месяца в 1С:Бухгалтерии ПРОФ.
Настройка пересчета закупочной цены из валюты в рубли без потери сумм из-за округления.
Биржа заказов Инфостарта помогает компаниям находить специалистов под задачи по 1С, а исполнителям - выбирать проекты по своей специализации и загрузке. На площадке размещают разовые задачи, консультации, доработки, запросы на сопровождение и участие в проектных командах.
Для заказчиков доступны исполнители разного формата - от частных специалистов до проектных ИТ-команд. Можно напрямую обмениваться контактами, работать без комиссии площадки и при необходимости использовать безопасную сделку.
Как мы закрываем задачу: тесты, диптрак, аудит и ещё пара рубежей
Продолжение серии про работу с ИИ-агентом. В прошлый раз разбирали, где живёт задача. Теперь — что с ней происходит, прежде чем она станет done.
«Готово» у агента наступает подозрительно рано — примерно в ту секунду, когда дописана последняя строчка кода. Поэтому между «я закончил писать» и «задача закрыта» у нас стоит несколько рубежей. Часть из них — детерминированные хуки: их агент физически не обойдёт, они возвращают ошибку и не дают закрыть ход. Часть — процедуры-скиллы, которые агент обязан прогнать сам. По порядку.
1. Автоформат — молча и сразу. После каждого Edit/Write срабатывает хук: Pint для PHP, Prettier для JS/TS правят изменённый файл. Не блокирует, ничего не спрашивает. Форматирование просто снято с повестки — про пробелы и переносы мы не спорим никогда.
2. Приёмка «прогнал — работает» (скилл verify-task). Финал задачи — не «по идее работает», а таблица. Перечитываем Definition of Done, по каждому пункту: как проверено → PASS/FAIL. Внутри:
прогон тестов затронутой области (Pest/PHPUnit) — зелёные, а не «вроде есть»;
smoke живого сценария через
tinkerили artisan-команду;корнер-кейсы: пусто, граница, null, таймаут внешнего сервиса;
в diff нет ключей и
.env.
Любой FAIL — задача не закрыта. Без «ну это мелочь, потом починим».
3. Deptrac — границы слоёв (Stop-хук). На попытке закрыть ход прогоняется анализатор архитектуры. Уехала логика из сервиса в контроллер, модель полезла напрямую во внешний API — exit 2, ход не закрывается, пока не переложишь код в правильный слой. Тот же гейт стоит в CI, а легаси-долг зафиксирован baseline’ом, чтобы старые грехи не блокировали новую работу. Правило в конфиге кажется неверным? Правь конфиг явно и объясняй — обходить молча нельзя.
4. Секреты не текут (guard-secrets). Отдельный хук стережёт, чтобы содержимое .env, ключей и дампов не улетело в чат: cat/grep по секретному файлу блокируются, Read на него — тоже. Править такие файлы можно (Edit/scp), а вываливать в переписку — нет.
5. Рефлексия — иначе не закрыть (guard-discipline). Код менялся, а записи в task/history за сегодня нет? Снова exit 2. Хук требует короткий разбор: что ставили, как решал, решено да/нет/частично, что можно было лучше. Следующая сессия начнёт с этих заметок и не наступит на те же грабли.
6. Независимый аудит — по коду, а не по рассказу. После нетривиальной доработки запускается отдельный агент, который не видел, как ты решал. Ему дают diff и чек-лист: все ли call-сайты покрыты, нет ли регрессий, есть ли тесты, скрытые баги, не уехали ли слои, не утекли ли секреты. Вердикт — APPROVE или CHANGES NEEDED со списком «файл:строка — почему». Нашёл проблему — не чинит молча, возвращает автору. Без аудита мёрдж не предлагаем.
7. И только теперь — в done и на мёрдж. Задача переезжает в task/done до открытия MR, в той же ветке. Прямой push в main закрыт хуком — только через merge request. А прод-pull делает человек: guard-prod fail-closed не пускает агента мутировать боевой сервер, агент лишь готовит команды.
Тут важно, кто есть кто. Автоформат, Deptrac, защита секретов, рефлексия, запрет пуша в main и защита прода — это хуки. Они срабатывают автоматически на события (после правки файла, при попытке закрыть ход, перед bash-командой) и возвращают exit 2, если что-то не так. Их нельзя «забыть» или уговорить — они не читают промпт, они перехватывают действие. А приёмка и аудит — это скиллы, процедуры, которые агент запускает сам: тут уже нужна голова, а не только стенка. Стенки ловят механику, скиллы — смысл.
Звучит как гора бюрократии — но пять рубежей из семи срабатывают сами и молча. Человека дёргают только там, где цена ошибки настоящая: на аудите и на проде.
«Готово» — не когда агент дописал код, а когда код прошёл все рубежи.
Почему «я знаю слова, но не могу говорить» — это не всегда проблема словарного запаса
У языковых приложений есть измеримая ловушка: узнавание слова и самостоятельное производство слова выглядят как один навык, но требуют разных действий от памяти. В тесте можно выбрать правильный вариант из четырех. В разговоре нужно быстро достать слово, собрать фразу, произнести ее и продолжить после ошибки.
Из этого следуют несколько простых правил для практики:
Проверять нужно не только узнавание, но и свободное извлечение: показать ситуацию и попросить сказать фразу без списка вариантов.
Голосовые попытки должны быть короткими. Пять минут каждый день дают более честный сигнал, чем редкая длинная сессия.
Ошибку полезно разбирать после попытки. Если останавливать человека до того, как он договорил, тренируется избегание, а не речь.
Следующий шаг должен быть чуть сложнее предыдущего: знакомая фраза, небольшая вариация, затем новый контекст.
Я собираю KeelAI вокруг этой идеи: чтение, повторение слов и переход к спокойным голосовым ответам в Telegram. Сейчас особенно интересны менее популярные языки, где проблема не в отсутствии учебников, а в нехватке регулярной практики.
Текущая версия проекта доступна здесь: KeelAI.
Буду рад техническим замечаниям: какие метрики вы бы использовали, чтобы отличить «узнает в упражнении» от «может произнести в новом контексте»?