Все потоки

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

А в конце месяца — тишина в кассе. Запросы на бесплатные консультации есть, а на серьезный продукт — нет.

Знакомо?

Это классическая ловушка «бесплатной скорой помощи».

Вы даете таблетку — быстрый совет, который снимает симптом здесь и сейчас. Клиент почувствовал облегчение и пошел дальше. Зачем ему покупать «курс лечения», если боль уже не так сильно давит?

Ваша щедрость стала вашим главным бизнес-врагом. Потому что вы продали результат заранее. Вы дали понять: «Вашу проблему можно решить одним комментарием или 15-секундным роликом». И это — правда. Но только для симптома, а не для причины.

⁉️ Где ошибка?

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

Как это исправить? Сменить фокус контента.

✔️ Вместо «ответа на вопрос» — «обнажение масштаба проблемы».

Было: «Вот 3 способа снять тревогу перед созвоном с клиентом».

Стало: «Почему «лайфхаки против тревоги» — это как аспирин при язве. Что на самом деле разрушает вашу уверенность в продажах (и как это чинится не за 5 минут, а за 21 день)».

✔️ Вместо «разбора кейса» — «диагностики тупика».

Было: «Смотрите, как я помог клиенту настроить таргет».

Стало: «Почему 90% экспертов не могут настроить таргет, который работает дольше недели. В чем подвох, который не видно снаружи (и именно поэтому вы раз за разом наступаете на те же грабли)».

Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте».

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

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

Эффективные рибосомы способны дать организму колоссальные преимущества. Перспективы фантастические. Об этом в конце статьи.

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

Зовут этого человека Роб Шервуд (Rob Sherwood). Радиолюбительскую лицензию он получил в 1961-м, в 14 лет. А спустя 27 лет стал оператором экстра-класса и обладателем позывного NC0B. 

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

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

Начинаю серию «Linux Base» из 11 частей — структурированная база для DevOps, DevSecOps и всех, кто работает с Linux.

Часть 1 — файловая система: разбираем структуру каталогов (/etc, /proc, /var и др.), навигацию, работу с файлами, просмотр содержимого и поиск через grep, awk, sed. В конце — 5 практических заданий для закрепления.

в конце также вас ждет Linux commands cheatsheet!

Разработчик рассказал о необычной задумке — он решил научить свою собаку создавать игры с помощью инструментов вайб-кодинга. Вот как это было.

За 30+ проектов я использовал RAG в 80% случаев, Fine-tuning — в 15%, комбинацию — в 5%. В статье — практическая матрица выбора: когда RAG достаточно, когда нужен fine-tuning, а когда гибрид. С примерами кода, реальными сценариями и разбором ошибок.2

Амбициозный, с собственными пет-проектами, участвующий в формах и профильных ивентах/конференциях — софты уже есть, на нашей стороне — харды.

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

Плюс, постепенно изучаем то, из чего состоит само приложение (что можно подключить память, что там можно выбирать различные инструменты для работы), отдельные моды в LangChain для разных задач, для вопросно-ответных систем, для систем, где агент выбирает сам инструменты, где система работает с реактом.

Обучение строится так:
— сначала хоть что-то запустить;
— потом понять, как это «хоть что-то» работает;
— потом усложнить и понять разницу;
— далее переходить к практическим задачкам.

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

Тут важно прописывать задачи.
В одной задаче мы подключаем память.
В другой — используем внешние инструменты, которые могут, например, по API дёргать данные по погоде/курсу валют/сводкам новостей/etc.

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

И после выполнения, например, 5 задач, джун уже может технически разбирать их по существу и понимать, а что и как можно улучшить?

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

Речь пойдет о следующей задаче из «Сборника задач по аналитической механике» (Е. С. Пятницкий, Н. М. Трухан, Ю. И. Ханукаев, Г. Н. Яковенко; под редакцией Е. С. Пятницкого. — 4-е изд. — Москва, МФТИ, 2018):

Атаки на отказ в обслуживании (Denial‑of‑service attack, DoS), к сожалению, стали обыденным явлением для публичных веб‑сервисов. Типов и разновидностей атак на отказ в обслуживании существует огромное количество, поэтому мы не будем даже пытаться провести классификацию. Скажем только, что для полноценной защиты от распределённых DoS‑атак (DDoS — Distributed DoS) необходима специализированная облачная система. В этой статье мы проведём обзор возможностей защиты от обычных DoS‑атак и простейших DDoS‑атак встроенными средствами веб‑сервера Angie.

2025 год стал переломным для open-source-сообщества. Согласно ежегодной статистике GitHub, количество публичных репозиториев перевалило за 395 миллионов, а аудитория платформы выросла до 180 миллионов разработчиков. Но главная интрига развернулась на пьедестале языков программирования: TypeScript впервые сместил Python и JavaScript, став самым быстрорастущим языком с годовым приростом в 1 миллион новых разработчиков.

Мы вступили в 2026 год, и тренд на «агентность» и «интеграцию с ИИ» перестал быть просто хайпом. Теперь это архитектурный стандарт. В этой статье я собрал проекты, которые буквально «взорвали» GitHub в конце 2025 и начале 2026 года. Это не просто игрушки, а реальные инструменты, меняющие ландшафт разработки.

«Ты будешь единственным тестировщиком на проекте», — услышал я на знакомстве с командой. Ничего страшного, с кем не бывало? «У нас не было постоянного тестировщика, нужно выстраивать все процессы с нуля», — добавил мой будущий тимлид. А вот это уже интереснее. 

Меня зовут Илья, я отвечаю за качество A/B‑платформы в Точка Банке. Сегодня я хочу рассказать, как тестировщику воспользоваться безграничной властью с пользой для всех (и немного для себя).

Всем привет, я Татьяна Миронова, руководитель направления доступности Госуслуг в компании РТЛабс. Сегодня хочу поделиться опытом нашего экс-специалиста по доступности Александры Галенко.

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

Дальнейший текст — рассказ от лица Саши.

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

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

С 2019 года в России активно развивается маркировка различных групп товаров на основе технологии, получившей название «Честный знак», которая разработана в рамках частно-государственного партнерства «Центром развития перспективных технологий» (ЦРПТ).

В рамках этой технологии движение товаров, подлежащих обязательной маркировке, отражаются в Государственной информационной системе маркировки товаров (ГИС МТ). Регистрация и авторизация в системе маркировки осуществляется с использованием сертификата электронной подписи. В связи с тем, что обязательная маркировка распространяется на все большее количество групп товаров, запрос на автоматизацию учета маркированного товара также растет.

Данная статья призвана расширить кругозор и компетенцию начинающих специалистов 1С в части работы с товарами с особенностью учета в рамках консалтинговой деятельности, в частности, автоматизации учета и работы с ГИС МТ в прикладных решениях вендора 1С.

Пониженные страховые взносы для аккредитованных IT-компаний - 7,6% вместо 30% - один из немногих реально работающих инструментов налоговой оптимизации для технологического бизнеса. Но именно эта льгота превратила IT-структуры внутри холдингов в главную мишень ФНС.

ФНС перешла от точечных проверок к системному анализу групп компаний. Налоговая активно выявляет IT-структуры внутри холдингов и стремится аннулировать льготы, квалифицируя схему как «дробление бизнеса» по ст. 54.1 НК РФ.

Главный аргумент инспекторов: IT-компания создана не для реальной самостоятельной деятельности, а исключительно для налоговой экономии группы.

Разбираем, на что смотрит налоговая, какие ошибки допускают налогоплательщики и как защитить бизнес на примерах из практики.

Почему ФНС атакует «корпоративные» IT-компании?

Логика налоговиков проста: если IT-компания обслуживает только предприятия своей «материнской» группы, не имеет внешней выручки, не владеет правами на ПО и не принимает самостоятельных решений - это не отдельный бизнес, а искусственно выделенное подразделение.

Цель ФНС доказать, что единый бизнес был разделён на части без деловой цели, кроме как получить льготу по взносам. В случае успеха: доначисление взносов по ставке 30% за весь период применения льготы + пени + штрафы 20–40% от суммы недоимки.

Важным ориентиром для бизнеса остаётся Письмо Минфина России № СД-4-2/3289@. В документе прямо сказано: само по себе выделение IT-функции в отдельное ООО «не может рассматриваться налоговыми органами как искажение фактов хозяйственной жизни... и квалифицироваться как применение схемы уклонения от налогообложения». То есть создать отдельную IT-компанию - не нарушение. Налоговая не вправе доначислить взносы только на том основании, что вы выделили IT-отдел в отдельную структуру.

Привет, Хабр! Меня зовут Екатерина Чумакова, я геммолог в LA VIVION. Это международный ювелирный бренд, который производит и продает украшения с бриллиантами. А геммолог — это специалист, который изучает драгоценные камни и может не только определить вид, но и происхождение, возраст, состав и многое другое.

Бриллианты — это, конечно, прежде всего красиво и дорого. Но мало кто задумывается, что стоит за этой красотой и роскошью. В своей первой статье я расскажу о том, какой путь проходит драгоценный камень, прежде чем оказаться на руке девушки (спойлер: не всегда, но часто этот путь длиннее экватора!), почему бриллианты такие дорогие и какие инженерные решения применяют технологи и ювелиры. 

В мире разработки программного обеспечения существует понятие, которое окружено множеством мифов, страхов и недопонимания. 

Это технический долг. 

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

Привет, Хабр! Я Анна Мелкомукова — инженер команды Spirit Compute в T-Банке. Наша команда отвечает за создание и полную поддержку Kubernetes-кластеров. 

Раньше трава была зеленее и небо голубее, а в Kubernetes крутились только легкие и беззаботные stateless-микросервисы. Поды появлялись и исчезали, как будто так будет всегда, но затем в архитектуре появился Stateful.

В статье я постараюсь ответить на вопрос «Как научить Kubernetes работать с приложениями, которым необходимо стабильное и надежное локальное хранилище».

World of Warcraft за два десятилетия оброс таким количеством дополнений, что сама история игры превратилась в череду эпох — со своими взлетами, провалами, экспериментами и возвращениями к корням. Каждое из них меняло не только механику и баланс, но и настроение всей вселенной: одни расширяли лор и задавали тон на годы вперед, другие — оставляли ощущение упущенного потенциала или неверного поворота в дизайне.

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