Обновить

Моя лента

Тип публикации
Порог рейтинга
Уровень сложности
Предупреждение
Войдите или зарегистрируйтесь, чтобы настроить фильтры
Статья

Иннерсорс: строим культуру открытого кода в большой компании

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели8.9K

Привет! Я Владимир Потехин, разработчик в Т-Банке в ИТ-хабе Нижнего Новгорода. Моя статья — первая в спецпроекте «20 в 20» к 20-летию Т-Банка. Двадцать специалистов из двадцати городов расскажут свои истории в серии статей, чтобы показать, как выглядит наша распределенная ИТ-карта. За эти годы Т-Банк сильно вырос, вместе с ним выросла и инженерная среда: команды работают в разных городах, но остаются частью одного большого процесса.

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

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

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

Читать далее
Статья

Карьерный переход топ‑менеджера как инвестиционный проект: кейс с цифрами

Уровень сложностиСредний
Время на прочтение22 мин
Охват и читатели8K

Карьерный консультант сказал «сфокусируйся».

Я сфокусировался: через 22 методики стратегического анализа, 31 экспертное интервью, финмодель, 64 сценария и год работы в Executive Master in Management ВШЭ.

Получил:

— Прогнозную NPV +8,7 млн ₽ на горизонте 24 месяцев
— Стратегию из трёх измерений (где играем, чем играем, через какой канал)
— Защиту выпускной работы на 10/10

Работы пока нет.

Метод — да. Гарантий — нет. Уверенность — да.

Это статья о том, как корпоративный стратегический инструментарий (PESTEL, Porter, VRIN, финансовое моделирование) работает применительно к карьере. И почему уверенность в методе и неуверенность в результате прекрасно живут вместе.

Внутри: 22 методики, 5 промоделированных сценариев, разбор «проблемы периметра» для интровертов‑управленцев, и одна неудобная мысль про то, что в 2026 году поиск работы перестал быть операционной задачей.

Читать далее
Статья

Как развернуть Spring Boot в Kubernetes за полчаса: туториал

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели9.8K

Хотите увидеть, как живое Spring Boot‑приложение проходит путь от репозитория до кластера Kubernetes? В статье пройдем путь от создания простого HealthController до автоматического деплоя через CI/CD. Разберём Dockerfile без магии, манифесты Deployment с пробами, настройку ресурсов и изящный Graceful Shutdown. В финале вы получите живую связку «код — контейнер — кластер», готовую к продакшену.

Читать далее
Статья

День, когда вы потеряли доменное имя

Время на прочтение7 мин
Охват и читатели8.2K

Если бы у этого дела был спортивный аналог — это титульный бой, выигранный в поздних раундах при отставании по очкам. Соперник: матёрый профи с большим портфелем доменов и опытом в «сотнях разбирательств». Мы: одно небольшое издание. Победили терпением — и тем, что позволили ему нокаутировать самого себя. Вот как это было — и чему нас научило.

Читать далее
Статья

Оптимизируем JDBC connection pool HikariCP. Основы и настройка

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели11K

HikariCP давно стал де-факто стандартом JDBC connection pooling в JVM-проектах. Но подключить его мало: важно правильно выбрать размер пула, таймауты, maxLifetime, keepaliveTime, leak detection и метрики.

Разбираем, как настроить HikariCP для Java, Kotlin, Scala и Spring Boot, какие ошибки чаще всего встречаются в проде и почему maximumPoolSize нельзя просто копировать из соседнего сервиса.

Читать далее
Статья

Больше контекста — хуже результат

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели14K

После статьи про Cursor и сжатие контекста я получил много комментариев. В коментах спорят: виноват компактинг? Или attention dilution? Или модель просто ослушалась? Или проблема вообще не в контексте, а в alignment?

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

Попробуем собрать эту картинку

Бооольше нейрослопа :)
Статья

75 картинок ablation: как Reddit-критика заставила меня переосмыслить FLUX-LoRA пайплайн

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели9.3K

Запустил 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-датасете.

Читать далее
Статья

Конкатенация строк в Java: почему советы 2008 года всё ещё работают — и почему этого уже недостаточно

Уровень сложностиСредний
Время на прочтение16 мин
Охват и читатели10K

Вы наверняка видели такой код - for (String s : data) { result += s; } сотни раз.

Что с ним не так?

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

И казалось бы, проблема конкатенации строк в Java давно решена. Джунам говорят: используй StringBuilder и будет тебе щастье. А статьи десятилетней давности сравнивают + и append() в бенчмарках и ставят точку.

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

Вред не исчез - он принял новые, менее очевидные формы.

Заглянуть
Статья

Странные ИИ‑существа из 00-х, которые научились размножаться сами

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели13K

Сегодня мы расскажем об игре на основе 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-модалка.

Он просто маршрутизирует:

BaseModal.vue  
  ├─ BaseDialog.vue    
  ├─ BaseBottomSheet.vue    
  └─ BaseFullscreenSheet.vue  

А каждая конкретная реализация живёт отдельно и отвечает только за себя.

Почему это лучше, чем один большой компонент?

Потому что большой универсальный компонент очень быстро превращается в кашу:

<!-- Каша в template -->
<div
    class="modal"
    :class="{
        'modal--open': open,
        'modal--mobile': isMobile,
        'modal--desktop': !isMobile,
        'modal--fullscreen': isMobile && mobileStyle === 'fullscreen',
        'modal--bottom-sheet': isMobile && mobileStyle === 'bottom-sheet',
    }"
>

А потом туда добавляются:

  • разные анимации

  • разные отступы и размеры

  • разное поведение закрытия

  • разные transition

  • разные layout-правила

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

С фабрикой проще:

  • BaseDialog отвечает за centered dialog

  • BaseBottomSheet отвечает за bottom sheet

  • BaseFullscreenSheet отвечает за fullscreen

  • BaseModal только выбирает, что показать

То есть вместо одного монолита появляется тонкий слой выбора и несколько изолированных компонентов.

И кстати, поделитесь: насколько паттерны актуальны сейчас? Или про них всё рассказали 20 лет назад и хватит говорить о них?

Теги:
+2
Комментарии3
Статья

Поддержка Docker Compose в Spring Boot 3.1

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели9K

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

– PostgreSQL

– Kafka

– RabbitMQ

– Redis

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

Комментарий от Михаила Поливахи:

Друзья, хоть на дворе уже Spring Boot 4, мы знаем, что большинство из вас сидит на Spring Boot 3. И мы посчитали очень нужным рассказать о таком Spring Boot инструменте, который, на наш взгляд, делает локальную разработку со Spring Boot намного более приятной.

Читать далее
Статья

Почему NVMe не всегда ускоряет сайт: смотрим на latency, p95/p99 и профиль нагрузки

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели7.4K

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

Я работаю контент-маркетологом в Scalehost и по работе регулярно разбираю темы, связанные с производительностью веб-проектов. Вопрос “нужен ли сайту NVMe или это просто маркетинговая галочка” возникает так часто, что мне захотелось собрать его в один технически внятный разбор.

Читать далее
Новость

ТОП-5 ИБ-событий недели по версии Jet CSIRT

Время на прочтение3 мин
Охват и читатели7.3K

Сегодня в ТОП-5 — Пакет PyPI был взломан для распространения программы-похитителя информации, обнаружена критическая уязвимость в продуктах GitHub, вирус-вымогатель VECT 2.0 необратимо уничтожает файлы, новый бэкдор на Python использует туннельные сервисы для кражи учетных данных, новая уязвимость Copy Fail в Linux позволяет получить root-доступ.

Читать далее

Ближайшие события

Статья

Использование Trino для построения ETL‑процессов

Уровень сложностиСредний
Время на прочтение35 мин
Охват и читатели8.1K

1. Введение. Trino: ключевые задачи и главные преимущества

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

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

ETL возник как вынужденная мера, так как во время его появления (1970–1990-е) не было ни высокоскоростных сетей, ни мощных распределенных движков аналитики, ни концепции Data Lake. Единственным надёжным способом построить аналитическую отчетность было физически извлекать данные из операционных систем и копировать их в отдельную специализированную базу. Именно поэтому ETL закрепился как основной архитектурный паттерн аналитических систем на долгие десятилетия.

Увы, такой подход породил и массу проблем: это дублирование данных, долгие пайплайны, сложные зависимости, задержки обновления и огромные затраты на поддержку. Традиционным ETL‑процессам становится всё труднее справляться с постоянно растущим объемом поступающих данных. Более того, большие сложности возникают при работе с уже накопленной информацией, ведь её требуется хранить на протяжении многих лет, а значит — сохранять возможность глубокого анализа по всей доступной истории.

Читать далее
Статья

Lemonade — локальный LLM-сервер при поддержке AMD. Зачем он нужен, если есть Ollama?

Уровень сложностиПростой
Время на прочтение3 мин
Охват и читатели15K

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 появился именно для этого сегмента.

Читать далее
Статья

Как мы модернизировали интеграционную шину и сократили время на управление интеграциями в несколько раз

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели6.6K

Всем привет!

Мы команда интеграции в Московской Бирже (MOEX).

В наши задачи входит развитие интеграционной шины (ESB).
Без надёжной интеграционной шины невозможно представить ни один межсистемный процесс.

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

О том, какую ценность это несет и как это работает, данная статья.

Читать далее
Статья

Кликнул пару раз — и уже автор: как AI-продукты убивают пользовательский вклад через интерфейс?

Время на прочтение5 мин
Охват и читатели7.1K

Иллюзия участия в AI-инструментах: как мы теряем пользователя внутри собственного продукта

Мы в Кэмпе уже более 6 лет работаем над AI-инструментами для образования и фиксируем устойчивый эффект: пользователь воспринимает результат генерации как «свой», даже если его реальное участие в процессе было минимальным.

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

В этой статье мы разберем этот эффект как продуктовую проблему: откуда берется ощущение «я сделал сам», как оно связано с архитектурой AI-интерфейсов и как вернуть пользователя в процесс, а не просто ускорять результат.

Читать далее
Статья

Создаем клиентскую библиотеку ROS2. «Hello ROS»

Время на прочтение10 мин
Охват и читатели8.2K

Пару лет назад у меня возникла мысль, почему бы не написать полноценную клиентскую библиотеку ROS2 для языка Lua?.. Увы, результат оказался невостребованным, зато сама разработка позволила лучше понять, как устроен этот фреймворк, а также с интересом провести время, разгадывая логические головоломки.

Создатели ROS2 вынесли базовый функционал в C библиотеку  rcl (ROS Client Libraries). В теории, достаточно создать обертку на каком-либо языке программирования и можно пользоваться. Между тем, сторонних клиентских библиотек не так уж много. На мой взгляд, можно выделить следующие причины:

Читать далее
Статья

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

Время на прочтение4 мин
Охват и читатели16K

Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как Project Manager стриминга кино viju.ru сама в этом варюсь каждый день — десятки тредов, уточнений, синхронизаций, но в какой-то момент ловишь себя на мысли: чем больше коммуникации, тем меньше реального движения задач. 

Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче.

В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.

Читать далее
Статья

База FinOps: Почему счет за облако каждый месяц растет и что с этим делать

Уровень сложностиПростой
Время на прочтение11 мин
Охват и читатели9.1K

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

На самом деле чудес не бывает, и я намеренно перевел pay-as-you-go как “платишь за то, что заказал”. Внимание: заказал, а не потребил. Потому что в этом и заключается первая проблема – нет, не облаков, – а тех, кто их использует. Компании регулярно выходят за рамки бюджетов, потому что платят за ресурсы, которыми де-факто не пользуются. Тут и забытые тестовые стенды, и старые проекты, которые продолжают генерировать счета, и простаивающие виртуальные машины с запасом по мощности, и чего только не. В результате до 30% облачного бюджета просто улетает впустую. А у некоторых и того больше. 

Плюс – усложнение архитектуры как таковой. Если раньше одно приложение работало на одном сервере, то теперь они состоят из десятков разных микросервисов, и каждому нужна своя база, свой кэш, своя очередь. А ведь еще есть тестовое окружение, staging, CI/CD и много других английских слов. И за все надо платить. Да, по отдельности вроде копейки. Но когда таких сервисов 100 или 200, сумма выходит приличная. Добавим сюда накладные расходы и получим еще минимум 15-25% к счету. А хотелось бы эти деньги оставить у себя в кармане. О том, как это сделать, сегодня и поговорим.

Читать далее