Программирование *

Расскажу про личный опыт оформления ИП в Грузии. Октябрь 2025

1. Подготовка документов.
Вам нужен только загранпаспорт

2. ...

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.

Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…

Меня зовут Иван Соснович, я тимлид фронтенд-разработки в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. В этой статье я покажу, как мы доработали FSD под себя, и дам ссылку на пример со структурой приложения. Надеюсь, будет полезно фронтенд-разработчикам.

Привет, Хабр!

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

Когда я только начинал Tunio, я хотел просто познакомиться с Kubernetes. В итоге получилось построить полноценную платформу для радио с AI-музыкой, новостями, прогнозами погоды, подкастами, гео-кластеризацией и TTS-ведущими - без команды, инвестиций и грантов. Эта статья - о том, как из pet-проекта вырос продакшн-сервис с реальными клиентами, и какие технические фэйлы и открытия случились по дороге.

Полистав различные ресурсы в Интернете и просмотрев множество видео по данной теме, я решил составить наиболее полную картину по данному, не побоюсь этого слова, революционному API, чтобы вы уже сегодня могли начать использовать его в своём проекте!

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

В этой статье мы разберём, почему для Ozon нужен браузерный парсинг, как использовать Playwright для успешного парсинга и как обернём решение в Telegram-бота, который по запросу пользователя парсит товары и отправляет CSV-файл.

Утечка оперативной памяти в Apple Calculator достигает 32 ГБ.

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

Случись такое в 2000-х, это бы привело к внесению срочных патчей и служебной проверке. Сегодня же это лишь очередной баг-репорт в очереди.

Мы урегулировали программные катастрофы такой степени, что утечка 32 ГБ в калькуляторе уже не удивляет. И дело не в ИИ. Кризис с качеством ПО начался за несколько лет до появления ChatGPT. ИИ лишь стал дополнительным инструментом в руках некомпетентных людей.

Команда AI for Devs подготовила перевод исследования о парадоксе безопасности локальных LLM. Если вы запускаете модели на своём сервере ради приватности, эту статью стоит прочитать. Эксперименты показывают: локальные модели вроде gpt-oss-20b куда легче обмануть, чем облачные аналоги. Они чаще вставляют вредоносный код, не замечая подвоха, и превращаются в идеальную цель для атак.

Команда Go for Devs подготовила перевод статьи о том, как memory maps (mmap) обеспечивают молниеносный доступ к файлам в Go. Автор показывает, что замена обычного чтения и записи на работу с памятью может ускорить программу в 25 раз — и объясняет, почему это почти магия, но с нюансами.

(!) Дата релиза этого обновления: 13 августа 2025. Это плановый, «прикладной» апдейт, который делает анализатор умнее, CLI — ощутимо быстрее, pub — точнее в разрешении зависимостей, а также приносит официальный MCP-сервер для интеграции Dart/Flutter с ИИ-ассистентами. Ниже — только существенное, с примерами и пошаговыми рекомендациями. (Dart)

База данных — это сердце системы. И в какой-то момент это сердце начинает давать сбои. Не от объема данных, а от их разнородности. Таблица users разрастается до 200 колонок. Одни нужны для логина каждую секунду, другие — для годового отчета раз в год. В итоге, чтобы прочитать два "горячих" поля, база тащит с диска целый блок с "холодными" данными. Это неэффективно.

В JDK 26 появилась долгожданная поддержка HTTP/3 в стандартном классе HttpClient. Хотя само API почти не изменилось, теперь можно явно указывать предпочтение использования HTTP/3 как на уровне клиента, так и на уровне запроса.

В новом переводе от команды Spring АйО подробно описывается, как работает выбор версии HTTP, что такое Http3DiscoveryMode, как принудительно использовать HTTP/3 и как HttpClient "обучается" на основе заголовков alt-svc.

По-моему, вайб-кодинг — полезная фича, но я знаю, что многие его недолюбливают и считают, что AI генерит чушь, а не нормальный код. Ну тут я могу сказать как в той рекламе с гепардом: «Ты просто не умеешь их готовить».

Я начал заниматься вайб-кодингом 2 года назад (привет первая версия GPT Engineer), то есть еще до того, как ввели сам термин (он появился только в этом году). За это время у меня накопился опыт, который я переложил в небольшие рекомендации, возможно они помогут начинающим вайб-кодерам.

Вообще вайб-кодинг, это, конечно, огромная тема. Думаю, сделать серию из нескольких статей: здесь начну с теории, а потом покаж�� практику, как я настраиваю окружение и вообще весь процесс.

Некоторое время назад компания Google DeepMind представила Gemini Diffusion — экспериментальную языковую модель, генерирующую текст методом диффузии. В отличие от традиционных моделей, написанных в стиле GPT и генерирующих слово за словом,  Gemini создаёт текст целыми блоками, пошагово уточняя случайный шум.

Я прочитал статью «Large Language Diffusion Models» — и с удивлением узнал, что дискретная диффузия языка представляет собой просто обобщение метода генерации пропущенного токена (MLM), практикуемого уже с 2018 года. Я сразу подумал: «А можно ли тонко настроить BERT-подобную модель так, чтобы приспособить её к генерации текста?» Из чистого любопытства решил наскоро набросать проверку концепции.

Примечание: уже после того, как написал эту статью, я наткнулся на исследование DiffusionBERT, где сделано практически то же самое, что и у меня, но проект гораздо тщательнее протестирован. Посмотрите этот пост, если тема вас заинтересовала.

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

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

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

Одно из правил - буквально слово в слово - я недавно встретил в одном популярном эссе о написании кода без ошибок (я расскажу об этом правиле позже). Мне стало любопытно, насколько применимы остальные правила со школьного плаката (короткий ответ – да), и есть ли у этого обоснование. Я немного зарылся в литературу, и вот что понял.

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

Готовится релиз. Сроки подходят. Мне скидывают странный баг: Наше приложение вдруг стало жаловаться на невозможность соединиться с соседним.

А почему не может? Защищённое соединение не устанавливается.

А почему не устанавливается? Файлы сертификатов для этого соединения не удаётся загрузить.

А почему файлы не грузятся? А потому что путь к файлам "отсутствует в конфигурации".

А если руками залезть и глазами посмотреть - присутствует. Чудеса! Эффект Шрёдингера!

95% корпоративных ИИ-пилотов проваливаются. IBM Watson Health - $62 млн впустую, Zillow - $880 млн убытков, McDonald’s - чат-бот, заказывающий 260 наггетсов. Почему? Потому что компании внедряют ИИ вслепую, без понимания своих процессов.

Но есть и другой путь. В этой статье я показыв��ю, как связка ДРАКОН + LLM превращает хаос в управляемую систему и становится фундаментом для агентских ИИ.

Вместо «чёрного ящика» - понятная визуальная карта, где каждый шаг прозрачен.
Вместо слепого доверия - гибридный процесс: человек и ИИ делят зоны ответственности.
Вместо провала - три уровня автоматизации, от 30% до 70%, с чёткими расчётами времени, рисков и ROI.

На примере сети СТО мы показываем:

как LLM на основе ДРАКОН-схемы проектирует агентов для записи клиентов, управления складом и поддержки механиков,

как сократить время на создание ТЗ с месяца до недели,

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

Это не теория. Это инженерный план:

Уровень 1: 5-7 часов экономии в неделю, риск провала - 5%,

Уровень 2: 15-20 часов, риск - 20%,

Уровень 3: 30-35 часов, риск - 35%.

И всё это - на открытых, доступных инструментах: Llama 3, Mistral, Qwen и языке ДРАКОН, который понимает и директор, и программист.

Потому что реальный ужас - не в том, что ИИ захочет нас уничтожить. А в том, что мы сами разрушим бизнес, не понимая, как работает то, чем управляем.

Статья для тех, кто устал от хайпа и хочет действовать - с пониманием, а не на авось.

Привет Хабр! Как-то так случилось, что кто-то очень хитрый, в одном НИИ, подключил обычный бытовой увлажнитель BALLU UHB-1000 к фитотрону(ака гроубоксу). Вот и встала задача добавить управление этим устройством.