Все потоки

Сооснователь b2b компании EXPF Виталий Черемисинов рассказал, как продал её IT-гиганту Авито, оставшись в ней бизнес-оунером, почему не нужно спешить делать модного AI-единорога, а лучше продавать экспертность в своём деле. 

Чтобы ускорить развитие собственного продукта для аналитики, в 2025 году компания Авито купила EXPF,  их платформы объединились. После продажи Виталий продолжает управлять объединённой платформой.

Сейчас ты находишься уже внутри Авито. Расскажи, чем занимаешься?

Я отвечаю за бизнес-составляющую: удерживаю имеющихся клиентов и привлекаю новых.

Чем занимался до создания своей компании?

Моя альма-матер — компания AIC, где я совмещал две роли: отвечал за e-commerce практику и был дата-директором. Основная моя роль была именно в развитии бизнеса. Навык работы с клиентом, упаковка экспертизы и продажа её как продукта, умение выстраивать взаимоотношения — самое ценное, что я оттуда вынес. Благодарен гендиректору Антону Виноградову, который многому меня научил, давал ценные советы.

Какие он давал советы?

Первое — гарантировать клиенту качество и спокойствие. Второе — это делиться успехом с окружающими.  Этим мы руководствуемся до сих пор 

Как ты решил открыть свою компанию? Какие были первые шаги? 

Я и мой друг Искандер консультировали компании. Когда начали накапливаться проекты, в какой-то момент встал вопрос: либо мы продолжаем консультировать, но уже как самостоятельная компания, либо отрезаем как минимум половину от накопившихся работ, потому что уже не помещается. Мы решили попробовать начать свой бизнес. Получится — супер, не получится — вернёмся в найм.

Весной 2026 года Starbucks в Южной Корее запустила промо Tank Day со скидками на большие термокружки (одно из значений слова tank по-английски — резервуар для жидкости). Идея выглядела безобидной ровно до запуска. Старт пришёлся на 18 мая. В этот день в Корее вспоминают восстание в Кванджу: продемократический протест, который военные подавили танками; в результате погибли сотни людей.

«День танка» прочитали как издёвку над национальной трагедией. Дальше по нарастающей: бойкот, публичные извинения руководства, увольнение главы Starbucks Korea, день закрытых кофеен по всей стране ради лекций сотрудникам по истории. Позже компания призналась, что придумывать кампанию помогал искусственный интеллект. Сути это не меняет. Название просто никто не сверил с календарём.

Привет, Хабр! Меня зовут Диана Фионина, я исследователь клиентского опыта и рынка в экосистеме ит-продуктов Лукоморье. В этой статье расскажу, почему клиентский опыт часто нельзя просто «перевести» с одного рынка на другой и что стоит делать вместо перевода. На реальных кейсах, от Starbucks в Японии и WeChat в Китае до службы поддержки в трёх странах СНГ, я разбираю, как культура влияет на восприятие сервиса и как превращать культурные наблюдения в проверяемые продуктовые гипотезы.

В инструкции приводится разбор процесса самостоятельной регистрации товарного знака в Роспатенте, в том числе:

1) определения объема правовой охраны товарного знака, подбор товаров и услуг, а также классов МКТУ;

2) особенности подготовки и подачи заявки по шагам через сервис «АРМ Регистратор» (самый надежный способ);

3) расчет и оплата пошлин за каждый этап регистрации;

4) общее описания процедуры: формальная экспертиза и экспертизы по существу;

5) ТОП-10 самых распространенных причин для отказа в регистрации.

Меня зовут Никита, я технический лидер команды, которая занимаемся управлением безопасностью контейнерных сред — и как отдельным продуктом для внешних клиентов, и как внутренним решением для команд, которые используют Managed Kubernetes под свои сервисы.

По работе я вижу примерно одни и те же ошибки у разных клиентов: уязвимые зависимости, зараженные образы, забытые в слоях секреты, дырки в CI/CD. В этой статье разберем четыре тонких места, которые я вижу чаще всего, с конкретными кейсами из практики. И в конце будет минимальный набор защиты, который быстро можно накатить у себя.

Несколько месяцев пилил pet-проект, который зашёл дальше, чем планировал: файловый ASGI-фреймворк, где дерево папок — это и есть таблица роутов. Сегодня вышла версия 1.0 — с адверсариальным security-аудитом (нашёл у себя pickle RCE и CSWSH), 2329 тестами и нативным async на PostgreSQL. Рассказываю, что внутри и что было больнее всего сделать правильно.

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

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

Сегодня речь пойдет о процессе, без которого производство невозможно представить, но потребитель зачастую даже не задумывается об этом. Мы поговорим о процессе планирования производства, а именно, о формировании детального плана-графика, и тех задачах, которые находятся в зоне ответственности специалистов по планированию. С какой целью? Чтобы понять, какой большой объем работы сосредотачивается зачастую на одном специалисте, и какие возможности существуют, чтобы ему помочь.

Цель статьи

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

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

В комментариях быстро появились знакомые возражения: для этого уже есть виртуальные рабочие столы; в Linux всё давно настраивается; достаточно правильно организовать окна; универсальный интерфейс всё равно никому не подойдёт.

С тех пор прошло 18 лет. Виртуальные рабочие столы стали нормой, появились облачные документы, браузерные профили и десятки инструментов для совместной работы. Но сама проблема, на мой взгляд, не исчезла, она просто переместилась.

Раньше на рабочем столе было слишком много окон. Теперь один рабочий проект размазан между слишком большим количеством приложений и сервисов.

Ежегодно Библиотека Конгресса отбирает 25 звукозаписей, имеющие «непреходящую ценность» для американской культуры, чтобы поместить их в Национальный реестр аудиозаписей, хранящий разнообразие звукового наследия США. В мае 2026 года среди этих записей оказалось музыкальное оформление популярной видеоигры Doom, вышедшей в 1993 году, получив таким образом высочайшее признание как культурной ценности. Немногим позже, 16 июня того же года, автор этого ныне официально незабвенного музыкального произведения, Роберт «Бобби» Принс, покинул нас в возрасте 81 года.

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

В начале июля я объявил весь код своего проекта легаси. Не модуль — всё: код, архитектуру, документацию. Месяц до этого проект — джоб‑маркетплейс для синих воротничков: мобильное приложение, web, AI‑ассистент — делала команда. Люди сильные, каждый уже работал с LLM‑агентами; не было другого — методологии работы с агентами. Агент пишет код быстрее человека — и энтропию порождает быстрее: все ветки в main, решения только в чате, документация врёт, персональные данные оседают в access‑логах. Каждый исполнитель локально прав, система в целом не работает. Код, который страшно трогать, появился у нас раньше, чем первый работающий флоу. Я остановил всё и начал заново — один.

Привет всем. Меня зовут Максим Талалаев и, как уже можно было, догадаться по тематике профиля, мы с очень маленькой, но гордой командой замахнулись на великое и делаем платформу временной (гибкой) занятости. Это модель уберизации, переложенная в подработки. Таксисты по таким работают, курьеры, складские работники и т.д. Даже президент сказал не так давно, что безработица низкая и платформенная занятость - это вам ого-го какая штука!

Нам год, и, наверное, уже можно рассказать о том, как мы запускались, и как я принимал решение о страте именно этого проекта, а не другого.

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

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

Но по факту все, конечно же, оказалось сложнее.

Чтобы это начало работать нормально, пришлось сделать отдельный навык - очередь задач, SQLite, CLI-проверки, правила для телеги, валидаторы, перенос бета в прод и отдельный компилятор на Python.

Так что расскажу все по порядку, возможно, кому то пригодится.

Тут будет по сути хронология работы с агентом, так что идем от начала до сегодняшнего дня.

Всем привет. Я много лет играю в Counter-Strike и тренируюсь, как большинство: захожу в Deathmatch «размяться», играю три катки, тильтую, выхожу. Сервисы статистики при этом исправно сообщают, что у меня просела точность и выросло время реакции. Спасибо, а делать-то что?

Весной я решил собрать себе тренера сам. Сразу пара слов для контекста: я самоучка, в команде никогда не работал, основной опыт — десктопные утилиты и автоматизация, из веба до этого были только админки под собственные инструменты. В CS тоже звёзд с неба не хватаю, Premier в районе трёх тысяч, на FACEIT вообще первый уровень. Так что история будет не про успешный успех, а про то, где я наступил на грабли и что из этого вынес.

Сам сайт делает вот что: подтягивает историю матчей, отдаёт агрегированную статистику LLM, а та разбирает сильные и слабые места и составляет недельный план тренировок, с конкретными картами, режимами и минутами. Отметил выполненное, сыграл новые матчи — план подстроился.

Проект мой, ссылка будет одна и в конце. Статья состоит из трёх частей: сколько это всё стоит в токенах, где модель выдумывает и как я это ловлю кодом, ну и подводные камни DeepSeek API и связки EF Core + SQLite.

Привет, Хабр! Меня зовут Виктория Мохирева, я консультант SAP MM. Моя прошлая статья была посвящена тому, как с помощью локального класса и глобального API мы с командой «приручили» большую языковую модель для работы с пересортицей. И, как это часто бывает, с прототипа все только началось.

12% всех зарегистрированных утечек данных в России начинались с атаки на топ-менеджмент (по данным PT EdTechLab). Так случилось, что собственники и ТОПы — это люди с уникальным, точнее уникально взрывоопасным, сочетанием максимального уровня привелегий и доверия внутри компании с, часто, относительно халатным отношением к кибергигиене. Бывает, что к этому добавляется еще наполняющая кибератаки фактурой публичность. Поделюсь пророчествами мыслями, к чему это может привести, и рекомендациями, что делать специалисту по ИБ, чтобы оптимизировать риски.

Три сценария, к которым нужно быть готовым

1. Целевой фишинг (он же "whaling" — охота на китов)

Атакующий изучает жертву заранее: интервью, стиль общения, распорядок дня. Потом приходит точное, убедительное, срочное письмо.

Классические сценарии: правдоподобные инструкции (иногда в формате дипфейков) от якобы директора перевести деньги или срочно открыть доступ.

Что делать? Учить людей распознавать манипуляции, проводить фишинг-тесты сообщений от босса (особенно для личных помощников, секретарей и финансистов), везде ставить многофакторку, настроить на почтовом домене компании защиту от подделки писем, чтобы мошенники не могли рассылать письма от вашего имени, для важных сообщений использовать более защищённые каналы связи, чем привычные мессенджеры, или, как минимум, использовать отдельный канал для подтверждения крупных транзакций.

2. Компрометация личных устройств

Руководители редко разделяют личное и рабочее. Один ноутбук и смартфон для всего: личная и корпоративная почта, мессенджеры, соцсети, банковское приложение компании.

Привет, Хаброжители! У нас отличные новости для всех, кто хочет освоить Go или систематизировать свои знания. Мы открыли предзаказ на новую книгу Станислава Чернышева «Основы Go». Чтобы вы могли оценить подачу материала и глубину погружения, мы делимся с вами эксклюзивным отрывком.

В начале 2026 года я запустил опрос в отделе: «Какими ИИ-инструментами вы пользуетесь?» Из 20 опрошенных только 3 человека пробовали ИИ-агентов в работе. Большинство технической команды — это хардкорные МЛ-щики, которые создают системы поиска патологий на медицинских снимках, а не просто дергают API ChatGPT с нужным промптом.

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

Представьте машину времени. Не ту, что переносит в прошлое или будущее, а ту, что ускоряет ваши собственные биологические часы прямо сейчас. Садитесь внутрь, проводите в ней год и выходите с телом, которое прошло через изменения, характерные для нескольких десятилетий жизни на Земле. Мышцы истончились. Кости стали хрупкими. Кроветворные стволовые клетки состарились на молекулярном уровне. Иммунитет работает непредсказуемо.

Такая машина существует и находится примерно в 400 км над вашей головой. Это Международная космическая станция.

← Восьмая часть

Описанный в предыдущих частях калькулятор уже работал. Реализация 2021 года запускалась на реальном оборудовании, обрабатывала нажатия клавиш, вычисляла результаты и отображала их. Арифметика была корректной в том смысле, что большинство результатов было точным до 12 значимых разрядов, а это больше, чем требуется обычному пользователю.

Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.

В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.

Когда в зависимости обнаруживают уязвимость, очевидное решение — поднять её минимально допустимую версию во всех библиотеках, которые ее используют. Тогда пакетный менеджер не подтянет уязвимую версию даже при новой установке. Сет Ларсон из Python Software Foundation предлагает не делать этого автоматически. По его мнению метаданные библиотеки должны описывать только совместимость, а контроль безопасности сборки оставаться на стороне приложения.

Колонка Сета вызвала спор в Python-сообществе: одни поддержали разделение ответственности между библиотекой и приложением, другие заметили, что безопасность тоже может входить в условия поддержки библиотеки. Мы в CodeScoring подготовили перевод колонки, разбор обеих позиций и наш взгляд на этот вопрос.

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

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

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