Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.
Я много времени уделяю работе с опенсорсом и искренне за него радею. Люблю опенсорс за ощущение общего дела: когда код не просто пишешь, а вместе с другими улучшаешь, обсуждаешь, докручиваешь и делаешь полезнее.
В крупной компании есть объективное ограничение: не каждый проект можно вынести за периметр. Даже хорошо изолированный от бизнес-логики код часто несет на себе груз внутренней инфраструктуры, договоренностей, данных и открыть его невозможно даже при большом желании.
И вот здесь появляется иннерсорс: подход, который берет лучшее из опенсорса — открытость, совместную работу, общий вклад — и переносит это внутрь компании. В итоге закрытые продукты тоже можно делать быстро, прозрачно и по-хорошему командно.
Я сфокусировался: через 22 методики стратегического анализа, 31 экспертное интервью, финмодель, 64 сценария и год работы в Executive Master in Management ВШЭ.
Получил:
— Прогнозную NPV +8,7 млн ₽ на горизонте 24 месяцев — Стратегию из трёх измерений (где играем, чем играем, через какой канал) — Защиту выпускной работы на 10/10
Работы пока нет.
Метод — да. Гарантий — нет. Уверенность — да.
Это статья о том, как корпоративный стратегический инструментарий (PESTEL, Porter, VRIN, финансовое моделирование) работает применительно к карьере. И почему уверенность в методе и неуверенность в результате прекрасно живут вместе.
Внутри: 22 методики, 5 промоделированных сценариев, разбор «проблемы периметра» для интровертов‑управленцев, и одна неудобная мысль про то, что в 2026 году поиск работы перестал быть операционной задачей.
Хотите увидеть, как живое Spring Boot‑приложение проходит путь от репозитория до кластера Kubernetes? В статье пройдем путь от создания простого HealthController до автоматического деплоя через CI/CD. Разберём Dockerfile без магии, манифесты Deployment с пробами, настройку ресурсов и изящный Graceful Shutdown. В финале вы получите живую связку «код — контейнер — кластер», готовую к продакшену.
Если бы у этого дела был спортивный аналог — это титульный бой, выигранный в поздних раундах при отставании по очкам. Соперник: матёрый профи с большим портфелем доменов и опытом в «сотнях разбирательств». Мы: одно небольшое издание. Победили терпением — и тем, что позволили ему нокаутировать самого себя. Вот как это было — и чему нас научило.
HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.
Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.
После статьи про Cursor и сжатие контекста я получил много комментариев. В коментах спорят: виноват компактинг? Или attention dilution? Или модель просто ослушалась? Или проблема вообще не в контексте, а в alignment?
Спор хороший, но он показывает фундаментальную проблему: у инженеров нет общей картины того, как LLM работают с контекстом. Мы видим симптомы (агент удалил базу, модель галлюцинирует, точность падает на длинной сессии), но не понимаем механизмы.
Запустил pinock.io — бесплатную ленту AI-генерации животных в стиле советских спичечных коробков. Под капотом FLUX.2-klein + кастомная LoRA + двухпроходный «sandwich»-пайплайн.
Получил детальный технический комментарий на r/StableDiffusion с тремя претензиями. Сел и прогнал ablation: 5 вариантов пайплайна × 5 категорий × 3 сида = 75 картинок.
Нашёл дыры в собственном пайплайне — в том числе кириллицу прямо в выходе LoRA (training-set leakage) и полный коллапс LoRA при scale=2.0. Текущий sandwich оказался патчем поверх плохо обученной LoRA, а не правильным решением.
В статье — все картинки, цифры, и почему оба «правильных» совета критика на текущей модели не сработали. Плюс план переобучения на 1500-датасете.
Вы наверняка видели такой код - for (String s : data) { result += s; } сотни раз.
Что с ним не так?
Ведь он выглядит безобидно, почти идиоматично. Но в продакшене под нагрузкой этот цикл способен генерировать сотни мегабайт мусора в секунду - даже если сам результат никому не нужен.
И казалось бы, проблема конкатенации строк в Java давно решена. Джунам говорят: используй StringBuilder и будет тебе щастье. А статьи десятилетней давности сравнивают + и append() в бенчмарках и ставят точку.
В сегодняшней статье я копнул немного глубже и оказалось, что реальность сложнее.
Вред не исчез - он принял новые, менее очевидные формы.
Сегодня мы расскажем об игре на основе AI‑модели, которая наделала много шуму в 90-х и начале нулевых. А все потому что ее персонажи были пугающе умными.
Долгое время думала, что использовать паттерны на фронте незачем и это больше тема для собесов
Но недавно все-таки удалось использовать паттерн фабрику для фронта и моему счастью не было предела, когда после 30-минутного рефакторинга разъехавшейся вёрстки через Claude, я попросила: "брат, слушай это ж паттерн фабрика, сделай BaseModal тонким, который просто решает, какой компонент отрисовать"
Технически, классический GoF Factory Method подразумевает наследование, а здесь у меня скорее Simple Factory — функция, выбирающая что создать. Но в обиходе все называют это "фабрикой", и я не буду усложнять.
Классический паттерн фабрика на Java:
// Интерфейс
interface Modal {
void open();
void close();
}
// Конкретные реализации
class Dialog implements Modal { ... }
class BottomSheet implements Modal { ... }
class FullscreenSheet implements Modal { ... }
// Фабрика — решает какой класс создать
class ModalFactory {
static Modal create(String type, boolean isMobile) {
if (!isMobile) return new Dialog();
return switch (type) {
case "bottom-sheet" -> new BottomSheet();
case "fullscreen" -> new FullscreenSheet();
default -> new Dialog();
};
}
}
// Использование
Modal modal = ModalFactory.create("bottom-sheet", isMobile);
modal.open();
Как это работает во Vue?
На фронте есть <component :is="..."/> - динамический компонент, который рендерит то, что ему передадут. Это и есть наш аналог ModalFactory.create(...).
<!-- BaseModal.vue — фабрика -->
<template>
<component
:is="modalComponent"
v-bind="$props"
@close="emit('close')"
>
<slot />
</component>
</template>
<script setup>
// Фабричный метод — выбирает компонент
const modalComponent = computed(() => {
// Desktop → всегда Dialog (центрированный)
if (!isMobile.value) return BaseDialog
// Mobile → зависит от mobileStyle
switch (props.mobileStyle) {
case 'fullscreen':
return BaseFullscreenSheet
case 'bottom-sheet':
return BaseBottomSheet
default:
return BaseDialog
}
})
</script>
Получился BaseModal, который сам почти ничего не делает.
Он не знает, как устроен dialog. Не знает, как анимируется bottom sheet. Не знает, как выглядит fullscreen-модалка.
Иногда перед разработчиком встает задача воссоздания некоторого окружения локально. В него часто входят различные компоненты инфраструктуры, такие как:
– PostgreSQL
– Kafka
– RabbitMQ
– Redis
И так далее. Менеджить целый зоопарк таких сервисов локально бывает не очень удобно. К счастью, у команды Spring Boot для вас есть небольшой помошник - Spring Boot Docker Compose.
Комментарий от Михаила Поливахи:
Друзья, хоть на дворе уже Spring Boot 4, мы знаем, что большинство из вас сидит на Spring Boot 3. И мы посчитали очень нужным рассказать о таком Spring Boot инструменте, который, на наш взгляд, делает локальную разработку со Spring Boot намного более приятной.
У дисковой подсистемы слишком хорошая репутация в тарифных таблицах и не самая однозначная в инженерных обсуждениях. В первом случае нам продают гигабайты в секунду, во втором часто говорят, что для веба диск почти не важен.
Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.
Сегодня в ТОП-5 — Пакет PyPI был взломан для распространения программы-похитителя информации, обнаружена критическая уязвимость в продуктах GitHub, вирус-вымогатель VECT 2.0 необратимо уничтожает файлы, новый бэкдор на Python использует туннельные сервисы для кражи учетных данных, новая уязвимость Copy Fail в Linux позволяет получить root-доступ.
1. Введение. Trino: ключевые задачи и главные преимущества
В современной архитектуре управления данными ETL‑процессы рассматриваются не как вспомогательный инструмент, а как базовый механизм интеграции, трансформации и подготовки данных, поступающих из множества гетерогенных источников. Ключевая цель этих процессов — избавиться от хаоса и разрозненности данных, которые почти всегда появляются в больших распределенных компаниях [1].
В рамках ETL‑конвейера выполняется автоматизированное извлечение данных из различных источников, их очистка, нормализация и приведение к единой модели, после чего подготовленные данные загружаются в централизованное аналитическое хранилище. Это даёт три главных преимущества: обеспечивает высокое качество и согласованность данных, структурирует информацию под нужды бизнес‑отчетности, а также отделяет аналитическую нагрузку от операционных систем, повышая таким образом производительность системы в целом.
ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.
Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.
Ryzen AI 9 HX 370 - это чип с NPU на 50 TOPS и Ollama его не видит - из-за своей архитектуры. Собственно, сама Ollama работает поверх llama.cpp, llama.cpp поддерживает GPU через CUDA, Metal, Vulkan и ROCm. А вот AMD GPU Ollama запускает - через ROCm и Vulkan. Но AMD NPU на базе архитектуры XDNA туда, к сожалению, не входит. Ryzen AI 300, Ryzen 8040, Ryzen 7040 - у всех этих чипов есть нейронный процессор, который при запуске Ollama простаивает.
И вот Lemonade Server появился именно для этого сегмента.
В наши задачи входит развитие интеграционной шины (ESB). Без надёжной интеграционной шины невозможно представить ни один межсистемный процесс.
В этом году мы реализовали проект по модернизации существующего решения ESB. В результате улучшили процессы управления интеграциями и сократили время на создание типовых интеграций в несколько раз.
О том, какую ценность это несет и как это работает, данная статья.
Иллюзия участия в AI-инструментах: как мы теряем пользователя внутри собственного продукта
Мы в Кэмпе уже более 6 лет работаем над AI-инструментами для образования и фиксируем устойчивый эффект: пользователь воспринимает результат генерации как «свой», даже если его реальное участие в процессе было минимальным.
При этом проблема не в том, что AI делает слишком много, а в том, что пользователь перестает понимать, что именно он сделал внутри процесса генерации самостоятельно. Это не поведенческая особенность аудитории, а продуктовая проблема, которая напрямую влияет на то, чему пользователь реально учится и как он закрепляет знания.
В этой статье мы разберем этот эффект как продуктовую проблему: откуда берется ощущение «я сделал сам», как оно связано с архитектурой AI-интерфейсов и как вернуть пользователя в процесс, а не просто ускорять результат.
Пару лет назад у меня возникла мысль, почему бы не написать полноценную клиентскую библиотеку ROS2 для языка Lua?.. Увы, результат оказался невостребованным, зато сама разработка позволила лучше понять, как устроен этот фреймворк, а также с интересом провести время, разгадывая логические головоломки.
Создатели ROS2 вынесли базовый функционал в C библиотеку rcl (ROS Client Libraries). В теории, достаточно создать обертку на каком-либо языке программирования и можно пользоваться. Между тем, сторонних клиентских библиотек не так уж много. На мой взгляд, можно выделить следующие причины:
Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как Project Manager стриминга кино viju.ru сама в этом варюсь каждый день — десятки тредов, уточнений, синхронизаций, но в какой-то момент ловишь себя на мысли: чем больше коммуникации, тем меньше реального движения задач.
Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.
В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.
Модель pay-as-you-go, которую предлагают в облаке, всегда была палкой о двух концах. С одной стороны, история вроде честнее некуда: платишь ровно за то, что заказал. Как в ресторане. Но, с другой, именно она практике нередко приводит к такому перерасходу, что поневоле начинаешь задумываться, а нужно ли нам вообще это облако?
На самом деле чудес не бывает, и я намеренно перевел pay-as-you-go как “платишь за то, что заказал”. Внимание: заказал, а не потребил. Потому что в этом и заключается первая проблема – нет, не облаков, – а тех, кто их использует. Компании регулярно выходят за рамки бюджетов, потому что платят за ресурсы, которыми де-факто не пользуются. Тут и забытые тестовые стенды, и старые проекты, которые продолжают генерировать счета, и простаивающие виртуальные машины с запасом по мощности, и чего только не. В результате до 30% облачного бюджета просто улетает впустую. А у некоторых и того больше.
Плюс – усложнение архитектуры как таковой. Если раньше одно приложение работало на одном сервере, то теперь они состоят из десятков разных микросервисов, и каждому нужна своя база, свой кэш, своя очередь. А ведь еще есть тестовое окружение, staging, CI/CD и много других английских слов. И за все надо платить. Да, по отдельности вроде копейки. Но когда таких сервисов 100 или 200, сумма выходит приличная. Добавим сюда накладные расходы и получим еще минимум 15-25% к счету. А хотелось бы эти деньги оставить у себя в кармане. О том, как это сделать, сегодня и поговорим.
