Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.
А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.
Многие Java-разработчики боятся алгоритмических задач (и я один из тех, кто включается в каждую дискуссиую на тему надобности алго-собесов для бигтеха). Они кажутся чем-то из параллельной реальности: где-то там, в университетах, на LeetCode, в собеседованиях в FAANG и контестах.
Но реальность такова: если вы хотите расти — алгоритмы знать нужно или хотя бы желательно. И не только ради собесов. Они в действительности помогают мыслить как инженер: структурировать задачи, оценивать сложность, писать оптимальный код, ну и шаблонно мыслить :)
Я расскажу, как можно подойти к этому процессу системно и без боли — на основе личного опыта Java-разработчика и преподавателя.
Библиотека функций к Script-fu
Введение.
Прежде чем приступить к описанию реализации обобщённых функций, надо рассказать о основном алгоритме использующемся при выборе наиболее подходящего метода, при вызове обобщённой функции.
Наша система реализует множественное наследование, поэтому при вызове обобщённой функции надо реализовать какой то способ определяющий какой метод надо построить иерархию родителей, от которых наследуются классы объектов используемых в качестве аргументов обобщённой функции и на основе этих иерархий выбрать метод наилучшим образом подходящий для данного набора аргументов.
Команда Spring АйО провела небольшое исследование JEP 520. В Java 25 JFR (Java Flight Recorder) позволит точно отслеживать выполнение конкретных методов — без изменения исходников, без логирования и без сторонних Java-агентов.
Данная статья направлена на повышение уровня понимания принципов работы барьеров памяти, которые лежат в основе атомарных операций. Она не описывает историю и первопричины появления данного механизма, а служит объяснением основных подходов.
Идеей было донести простыми словами и примерами механизмов работы барьеров памяти, поэтому в данной статье нет углубления в синтаксис ассемблер команд или архитектур процессоров.
Привет, Хабр!
Сегодня мы рассмотрим без преувеличений один из самых недооценённых алгоритмов стандартной библиотеки — std::search. Разберёмся, как он устроен, где реально экономит процессорные тики, а где лучше заменить его на что-то иное.
Рустам Курамшин, эксперт Spring АйО, разобрал свежий отчёт Stack Overflow за 2025 год о результатах ежегодного опроса разработчиков за 2025 год, и это отличный повод взглянуть на экосистему Java через призму статистики и интересов сообщества.
Представьте: вы и коллега в разных уголках планеты, но курсоры ваши встречаются в документа онлайн редактора. Вы одновременно вставляете слова в одну и ту же позицию или удаляете фрагмент текста, который ваш коллега в этот момент редактирует. Казалось бы, результат должен превратиться в хаос, но всё складывается в единую, логичную версию текста — несмотря на расстояния, задержки и одновременные правки. При этом вы даже не ждете, пока ваши изменения согласуются с общим состоянием на сервере. Просто редактируете документ и можете быть уверены в том, что ваши изменения применятся.
На деле за этим волшебством часто скрываются CRDT — структуры данных, делающие возможной децентрализованную синхронизацию. Я сам столкнулся с этим, когда работал над онлайн-совместным редактором: CRDT и библиотека Yjs буквально спасли мой проект от хаоса и сделали синхронизацию прозрачной.
Меня зовут Никита Лыкосов, я занимаюсь фронтенд-разработкой в Doubletapp и предлагаю шаг за шагом разобраться, как устроена эта инженерная магия. Спойлер: это гораздо проще, чем кажется.
Читайте в статье:
• G-Counter — самый простой CRDT
• Какие правила CRDT выполняются на примере G-Counter и зачем это нужно?
• Массивы
• Yjs: как устроено совместное редактирование на практике
Привет, Хабр! Мы — Настя, Эвелина и Миша — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal и канал Scala Nishtyaki, добавляем дополнительные новости и собственные комментарии. Мотивацию мы черпаем из желания развиваться и делиться полученными знаниями.
Приветствуем любую обратную связь! (づ ◕‿◕ )づ
С необходимостью введения в язык Script‑fu Объектно‑ориентированного стиля программирования я столкнулся на поздних этапах реализации языка функциональной геометрии. Когда в коде появились «свичи/переключатели» и возможность исполнения кода в зависимости от типа входящих данных. Сам то этот «переключатель» написать не сложно, но в развивающемся проекте, постоянно возникают новые типы, изменяются, от каких то приходится отказываться, а ещё есть вариант создания модульных систем, когда в одном варианте существует один набор типов, а вдругом другой, ну а в третьем третий и т. д. И код этого «переключателя» постоянно приходится переписывать, или прибегать к различным «хакам», модифицирующим код в зависимости от того или иного варианта загрузки.
Когда вы в своём проекте сталкиваетесь с подобными конструкциями это явный признак того что вам необходимы языковые конструкции поддерживающие гибкое поведение кода. В объектно‑ориентированном программировании подобное поведение функций называется полиморфным, а сам принцип позволяющий создавать такие функции полиморфизмом.
Разбираемся, что собой представляет n8n — мощный open-source инструмент для no-code автоматизации, и создаём первый рабочий процесс: Telegram-бота, который находит заказы в Google Таблицах.
В 11-м классе я начал учить Visual Basic, чтобы зарабатывать деньги создавая приложения на заказ. Это язык был выбран как наиболее простой и дружелюбный для человека не знакомого с программированием. Через несколько месяцев изучения я понял, что готов, и рассказал идею своему другу, который неплохо знал C++. Выпив по кружке пива мы решили создать профиль на фриланс‑бирже и написать, что наша молодая динамичная корпорация готова выполнить проект любой сложности и на любом языке. Мы были молоды, заряжены, и просто рвались в алгоритмический бой! Название компании выбрали первое, что пришло в голову — «SuperSoft».
Выпив по второй кружке пива мы начали искать заказы. Фриланс‑биржа работала по принципу тендера, где каждый может указать условия на которых он готов вписаться в проект.
Через некоторое время мы заметили запрос на разработку CRM системы. Судя по скриншотам и описанию — вроде ничего сложного, за несколько месяцев можно справиться. У проекта уже были ставки от разных компаний с предложением цены, времени разработки и условий. В среднем предложения были по 10 000$ плюс‑минус пару тысяч.
У нас не было прокаченного аккаунта и отзывов клиентов, поэтому единственное что мы могли делать — демпинговать ценой. Мы написали, что наш высокопрофессиональный коллектив сделает этот проект в два раза быстрее конкурентов, а вместо 10 000$ разработает его за 5000$.
Мы разместили заказ и стали ждать. Через какое‑то время часть конкурентов увидела наше предложение и тоже снизила цены. Мы увидели несколько приложений с Индии по 5000$ и сроки разработки такие же как у нас. Мы приняли стратегические решения ещё снизить цены до 3000$ и добавить к своему предложению, что мы также протестируем приложение и сделаем дизайн.
Почему зрелый проект начинается не с кода, а с инфраструктуры? Рассказываю, как простая автоматизация, тесты и документация экономят время, нервы и спасают от хаоса, особенно если вы пишете код с помощью ИИ.
Если вы давно хотели разобраться с CI/CD, научиться запускать высоконагруженные API или наконец-то понять, как работают трансформеры в ML — вам сюда. В августе мы проведем 60 открытых уроков по ключевым темам разработки, архитектуры, безопасности, тестирования, анализа и управления.
Каждое занятие — это новые знания и практический разбор задач, возможность задать вопросы экспертам и оценить, нужно ли вам более серьёзное систематическое обучение. Выбирайте свою тему и записывайтесь.
Сразу расставлю все точки над «и»: LLM полезны. Вопрос не в том, могут ли LLM писать код, они на это способны. Вопрос в том, почему вайб-кодинг может оказаться вашей худшей карьерной инвестицией.
Я начал замечать перемены, когда темы бесед разработчиков полностью поменялись. Теперь они обсуждают лишь то, как заставить Claude написать код за них. Или конечную цель: как заставить ИИ делать всё без вмешательства человека.
До недавнего времени я по большей мере игнорировал этот ажиотаж. Я читал заголовки, время от времени просил Claude или ChatGPT помочь мне в отладке, но ничего больше. Пришла пора учиться вайб-кодингу!
Всем привет! Меня зовут Павел, я руководитель разработки в компании Банки.ру. Сегодня предлагаю погрузиться в достаточно классическую тему когнитивных искажений и их влияния на работу тимлида и принимаемые решения.
Уверен, что практически каждый хоть раз чувствовал некоторое разочарование и непонимание в поведении коллег, результатах проекта или принимаемых решениях. В эти моменты в голове часто крутятся вопросы:
– Почему часть важных изменений в команде не приживается и откатывается к началу, хотя, кажется, мы все вместе нашли консенсус?
– Да каким образом мы снова не попали в сроки проекта, хотя у нас прекрасная опытная команда.
– Какова причина нежелания команды переходить на актуальный стек? Или наоборот, почему члены команды упорно тащат в ключевой проект сырые фреймворки и необкатанные подходы?
– Снова по итогам проекта у нас переусложненная и запутанная архитектура. Что мы делаем не так?
Давайте разбираться!
За 20+ лет в разработке я прошёл путь от студента с книгой по C++ до техлида, но понял: управление людьми приносит меньше удовольствия, чем написание кода. Карьерный рост — это не всегда движение вверх по иерархии, иногда стоит выбрать то, что действительно нравится, а в IT можно хорошо зарабатывать просто программируя.
При работе любого приложения могут возникнуть ситуации, приводящие к аварийному завершению работы программы. Еще хуже, если такие ошибки приводят к появлению уязвимостей и возможностям их эксплуатации. Для предотвращения проблем, связанных с исключительными ситуациями при работе приложений, применяются специальные обработчики исключений.
В этой статье мы поговорим об обработке исключений в конфигурациях 1С. В частности, мы посмотрим, как можно перехватывать исключения правильно и не очень правильно. Все перечисленные рекомендации представлены на сайте данного вендора и являются обязательными, если не указано иное. Статья может быть полезна архитекторам и разработчикам приложений в 1С.
Всем привет! Меня зовут Николай, я DBA-разработчик SimbirSoft. Если вам приходилось иметь дело с табличной моделью данных SQL Server Analysis Services (SSAS), то вы наверняка знаете, что на сервере она работает только в режиме In-Memory и использует под свои процессы выделенную часть оперативной памяти. А когда памяти недостаточно для нормальной работы, то возникает системное сообщение о ее нехватке.
В этой статье я кратко рассмотрел причины и общие стратегии по решению данной проблемы, а также рассказал о своем опыте на примере табличной модели объемом около 100 ГБ на MS SQL Server 2019 Ent.
Привет, Хабр! Меня зовут Михаил Полукаров, я занимаюсь разработкой Desktop-версии корпоративного супераппа для совместной работы VK Teams.
Если вы тоже работали с большими проектами, где активно применяются объектно-ориентированные паттерны проектирования, то наверняка сталкивались с паттернами проектирования Factory Method или AbstractFactory. В процессе разработки я неоднократно ловил себя на мысли, что часто пишу однотипный код таких фабрик, и задумался о том, как можно было бы избежать таких самоповторений.
В этой статье я покажу, как сделать универсальную фабрику объектов, покрывающую большую часть потребностей, следующую принципам DRY (Don’t Repeat Yourself), а также как можно использовать некоторые «фишки» новых стандартов С++.
