Кажется, что senior — это просто "ещё немного опыта". Но нет. За десять лет в индустрии я видел десятки отличных мидлов, которые так и остались "чуть ниже потолка" — не потому что им не хватало знаний, а потому что им не хватало чего-то другого. Попробуем честно разобраться, что именно мешает переходу, и почему "умный код" не всегда делает тебя старшим.
Паттерн Command — широко известный и мощный инструмент построения гибких систем, позволяющий целиком вынести логику каждого метода в отдельный класс.
В статье показано как совмещение Command с Dependency Injection (DI) даёт дополнительные преимущества в архитектуре приложений.
Статья будет полезна разработчикам всех уровней, а также архитекторам приложений.
Технический вкус — это не то же самое, что технический навык. Вы можете быть технически подкованы, но иметь плохой технический вкус и наоборот. Как и любой вкус в принципе, технический вкус зачастую не зависит от наличия фактического навыка. Вы же можете отличить хорошую еду от плохой, не умея готовить? То же самое с ПО — вы вполне способны понять, нравится ли оно вам, не имея возможности его создать. И если технические навыки можно наработать через усердное изучение и повторение, то хороший вкус вырабатывается менее очевидным путём.
Статья о реализации сервиса на C++ с применением TDD, DDD и событийно-ориентированной архитектуры. Проект переносит идеи из книги «Паттерны разработки на Python: TDD, DDD и событийно-ориентированная архитектура» на C++.
Представьте ситуацию: ваше приложение работает в продакшене, как вдруг происходит критическая ошибка. Вы узнаете о ней только через несколько часов, когда пользователи начинают массово жаловаться. Идёте проверять консоль, а тут всего лишь трассировка стека, которая мало что говорит о проблеме. Из-за кого и когда возникла это ошибка? Чтобы предотвратить такие сценарии, необходима активная система уведомлений. В этом руководстве мы создадим пользовательский обработчик, который предоставит возможность создания системы уведомлений об ошибках, которая гарантирует, что вы всегда будете в курсе состояния вашей системы.
Всем привет! Сегодня хочу зажечь настоящий холивар — но с практическим уклоном. Речь пойдет о нашем большом рефакторинге, вернее, о почти полном переписывании ядра нашего API-гейтвея.
Немного контекста: У нас классический монолит на Java (Spring Boot), который неплохо служил нам лет 5. Но с ростом нагрузки до 100k+ RPS мы уперлись в лимиты:
Я сейчас работаю над автоматизированной системой A/B-экспериментирования заголовков и/или обложек статей и новостей на одной медиа-платформе в одиночку. В статье рассказываю вам, как эта система работает и показываю некоторые технические нюансы.
Всем очевидно: индустрия ИИ стремительно развивается. Но здесь появляется одно гигантское слоноподобное НО. В последнее десятилетие лидеры ИИ предпочли развиваться экстенсивно - то есть, например, ЛЛМ максимизируют объём моделей. Это в свою очередь тянет за собой целую цепочку гигантских затрат: от электростанций до передовых числодробилок. Из последнего - xAI готовится запустить вычислительную фабрику мощностью 1 ГВт с 500-ми тысячами видеоускорителей! Можно по разному относиться к хайпу вокруг ИИ, но очевидно одно - есть много желающих вкладываться по полной программе в эти технологии. И, возможно, впоследствии экстенсивный рост перейдёт в интенсивный, то есть количество перейдёт в качество. Проблема только в том, что на низком уровне - уровне железа - техника подходит к физическим пределам. И если не сменить парадигму и физическую основу, то поддерживать развитие индустрии никакими средствами кроме масштабирования не получится.
Enum’ы в PHP с нами уже давно, но вы задумывались, как они реально работают внутри? Давайте разберёмся, что там происходит под капотом.
Привет, Хабр! Сегодня мы разберем, как нейросети автоматизируют рутинные безнес‑процессы на реальном примере — классификации заявок в службу поддержки. Даже простые нейросети способны значительно разгрузить сотрудников и ускорить обработку данных.
Привет, Хабр!
Хочу поделиться своим путём в блокчейн. К 2023 году за плечами было уже 7 лет строгого режима веб-разработки, и она начала казаться рутиной. Хотелось нового. В идеале — области, где можно было бы применить свою любовь к математике. Выбор стоял между датой и блокчейном. Я выбрал второе — во многом потому, что несколько моих друзей уже погрузились в этот «тёмный лес» и своими проектами пробудили во мне интерес. Это решение привело меня к неожиданным открытиям, трем разным проектам, нескольким месяцам жизни на доширак и к пониманию, что блокчейн — это идеальный полигон для любого разработчика, увлеченного математикой.
Команда JavaScript for Devs подготовила перевод статьи о том, почему JavaScript-сообщество снова проигнорирует шанс исправить фундаментальные проблемы своей экосистемы после крупнейшей атаки на цепочку поставок. Автор предлагает здравый план — от стандартной библиотеки до новых практик управления зависимостями, — но считает, что индустрия снова ограничится символическими жестами.
Все уже прекрасно понимают, что Amplicode — неотъемлемая часть тулинга для разработки в OpenIDE, IntelliJ IDEA Community Edition и GigaIDE на Spring Boot. Но стоит установить Amplicode в IntelliJ IDEA Ultimate и ваша, казалось бы, идеальная IDE станет ещё мощнее и удобнее.
Команда Go for Devs подготовила перевод статьи, в которой автор шаг за шагом решает классическую задачу об обедающих философах на Go. Вы узнаете, почему наивный подход ведёт к взаимной блокировке, как нарушить симметрию, чтобы избежать deadlock’а, и почему даже «рабочее» решение может оставить одного философа голодать вечно.
C# — гибкий язык. На нём можно писать мобильные и десктопные приложения, игры, веб-сайты, сервисы и API. Можно писать на нём, как на Java, со всеми абстракциями и AbstractionFactoryClassProvider. Но, в отличие от Java, на нём также можно писать низкоуровневый и небезопасный код. И когда я говорю о низкоуровневом, то имею в виду отсутствие сборщика мусора и сырые указатели.
Низкоуровневый код обычно требуется для высокой производительности или взаимодействия с библиотеками C/операционной системой. Низкоуровневый код помогает повысить производительность благодаря тому, что с его помощью можно избавиться от проверок доступа к памяти в среде исполнения.
Для безопасности доступ к элементам массивов выполняется в C# с проверкой границ. Но из-за этого страдает производительность, если только, конечно, компилятор не сможет избавиться от операции проверки границ. Логика устранения проверок границ должна гарантировать, что проверка границ индекса массива уже выполнялась раньше или что во время компиляции индекс точно будет находиться в границах. Для примера возьмём простую функцию:
Prometheus — система мониторинга самых различных устройств и приложений, самостоятельно сканирующая целевые объекты. В нашем случае, целевой объект — тестовый стенд с устройствами различных архитектур под управлением ОС «Нейтрино».
Так как Prometheus широко распространен, то для сбора и предоставления данных о метриках в нужном формате существует большое множество различных экспортёров, но все они либо заточены под работу на конкретных устройствах, либо избыточны, и содержат массу зависимостей.
Нам же требовался достаточно простой текстовый экспортёр, который бы стабильно работал в условиях использования встраиваемых систем с различными архитектурами процессора, и учитывал бы особенности и ограничения ОС.
Так и появился данный проект, доступный в нашем публичном репозитории, реализованный на С++11.
Не пишешь код и не создаешь дизайн, но хочешь понимать, как все устроено? Подборка блогов веб-разработчиков, которые читаются как хорошая нефильтрованная практика.
Продолжаем изучать использование PVS-Studio на практике для бесплатных (и не только) проектов. В этой статье мы рассмотрим основной этап взаимодействия с инструментом — работу с отчётом! Подробно рассмотрим первый опыт разбора срабатываний, изучим интерфейс и посмотрим на ошибки в проекте osu!
Каждый год мы слышим о «революциях» в IT: то квантовый компьютер «сломает» криптографию, то новый фреймворк «убьёт» всех конкурентов, то искусственный интеллект уже «почти человек». Но где проходит граница между настоящим научным прорывом и маркетинговым шумом? В статье попробуем разобраться, как развивать здоровый скепсис, не впадая в цинизм, и чем нам, инженерам, он может помочь в работе.
Вы тоже наверняка замечали: стоит выйти какой-нибудь громкой новости, и через пару дней LinkedIn, Telegram и даже сосед в чате подъезда уже уверены, что «это будущее, которое всё изменит». А потом проходит год — и оказывается, что «будущее» тихо растворилось, а мы продолжаем писать код на старом добром Python или Java, подкручивать пайплайны и чинить CI, который снова упал.
Я не раз ловил себя на мысли: почему нас, технарей, так тянет верить в магию? Может, потому что мы слишком хотим верить в простые решения. Новая база данных обещает вечную масштабируемость? Конечно, ставим в прод. Новый инструмент гарантирует, что тесты сами себя напишут? Берём! А потом наступает утро понедельника, и ты один на один с ошибками сегментации и багами в проде.
Эта статья — попытка поговорить о технологическом скепсисе: о том, как отличать реальный прогресс от пустого хайпа. Я поделюсь мыслями, примерами из практики, кусками кода и даже немного философии.
Привет, Хабр!
Redis Streams давно перестали быть экзотикой для любителей CLI и стали нормальным способом гонять события между сервисами. Но у PHP есть своя специфика: один код — два способа конкурентности. Либо Amp с неблокирующим I/O и семафорами, либо Swoole с корутинами. В обоих случаях хочется одного и того же: устойчивые consumer-группы, ручной ack, автоматический claim зависших сообщений, backpressure, экспоненциальные ретраи и внятный дед-леттер.
