Разработка

Большинство данных на фермах оседает в Excel-таблицах и тетрадках зоотехников. Вместе с командой Genome AI (акселератор Talent Hub ИТМО и Napoleon IT) разбираемся, как машинное обучение превращает генетический «шум» в прогнозы продуктивности. В статье — про гибридные модели (CatBoost + PyTorch), работу с SNP-маркерами, кривые лактации и то, зачем корове цифровой двойник. Без абстракций — только код на R, визуализации и архитектура пайплайна.

12 лет я отработал в ФНС России: начинал в районной инспекции и завершал карьеру в Управлении ФНС по субъекту. И довольно долго жил с ощущением, что «у нас налоги мягче», предпринимателю проще дышать, а где-то «там» всё устроено жестче и формальнее.

Но всё оказалось не так однозначно, как казалось изнутри системы. Теперь, находясь по другую сторону баррикад, я решил сравнить две налоговые системы: российскую ФНС и американскую IRS, и в итоге оказалось, что налоговое бремя, у нас в России, не такое уж низкое как преподносят в СМИ - оно просто иначе спрятано и иначе распределено. В России человек чаще всего видит только НДФЛ, но значительная часть нагрузки живёт «над зарплатой» - в страховых взносах работодателя, а затем догоняет нас в потреблении через НДС, который уже встроен в цену.

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

Так как тема очень большая, в этой статье я начну с фундамента - разберу архитектуру ФНС и IRS: как устроены уровни управления, где сосредоточены контроль и аналитика, а в следующей части сравню налоговую нагрузку двух стран на конкретных расчётах и покажу, где именно «прячется» налоговое бремя в России и США.

JVM в первую очередь процесс операционной системы. Но важно понимать, что требования к этому процессу на production отличатся от требований на workstation-е разработчика. 

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

В новом переводе от команды Spring АйО разберем, какие существуют базовые настройки кучи, GC и CPU помогают синхронизировать JVM с лимитами контейнера и не переплачивать за простаивающие ресурсы.

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

Пристегните ремни, коллеги‑разработчики и любители нейросетей. Если вы думали, что битва титанов между GPT-5.3 и Claude 4.6 Opus, вышедшими в один день, — это пик гонки, то спешу вас обрадовать. Это был только прогрев.

Сначала нам представили новый Опус и 5.3, следом Google выкатил обновленный Gemini, который научился переваривать библиотеки размером с Ленинку. Даже Илон Маск решил не стоять в стороне, выкатив в бету свой Grok 4.20. И вот, когда мы только‑только начали привыкать к новым мощностям, Anthropic делает ход конем и выпускает Claude 4.6 Sonnet.

Знаете, что самое дикое в этой ситуации? Рынок LLM превратился в место, где модели устаревают быстрее, чем вы успеваете обновить баланс в API. Раньше Sonnet считался средним братом — быстрым, недорогим, но все‑таки компромиссным. Но версия 4.6...

По сети уже гуляют восторженные треды на Reddit и посты в X, где пользователи всерьез обсуждают, не обрел ли новый Соннет сознание, настолько человечными и глубокими стали его ответы.

В этой статье мы не будем просто смотреть на скучные графики. Мы разберемся, как так вышло, что средняя модель внезапно начала наступать на пятки флагманам, почему разработчики массово мигрируют на нее с GPT и действительно ли у Anthropic получилось создать нейросеть с душой и чутьем в коде.

Приятного чтения!

История о том, как мы в Профи.ру перешли на монорепозиторий. 

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

Приветствуем вас, Хабр.

В течение минувшего года мы серьёзно прорабатывали тему инженерии данных (Data Engineering), поскольку остались очень довольны читательским интересом к вышедшей у нас книге «Основы инженерии данных: как создавать надёжные системы обработки данных» Джо Риса и Мэтта Хоусли (оригинал — издательство "O'Reilly"). В январе вышла её допечатка.

Кроме того, у нас уже переведена и ушла в редактуру более продвинутая книга, также от O'Reilly, написал которую Бартош Конечны (Bartosz Konieczny); она называется «Data Engineering Design Patterns: Recipes for Solving the Most Common Data Engineering Problems».

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

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

Начинаю серию «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С.

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

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

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

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

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

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