Многие баги, на первый взгляд, зарыты в коде. Но что, если код — это просто зеркало нашего мышления, а баг — результат когнитивной ошибки, которую мы даже не осознали? Эта статья — ретроспектива инженерных провалов, где причина — не баг в логике, а баг в голове. Разбираемся, почему мы думаем криво, как это ломает код, и можно ли «дебажить» собственное мышление.
Зачастую, в проектах ограничивается использование препроцессора по следующим причинам:
— Он не похож на весь остальной язык;
— Макросы могут возвращать неполные синтаксические конструкции, или вовсе различные, в зависимости от параметров.
Ввиду перечисленных особенностей, читать код с активным использованием препроцессора зачастую становится на порядок сложнее кода без него.
Со всеми его недостатками, инструмент есть в языке и достоин изучения.
В этой статье мы разберём, как использовать агентов в процессе разработки ПО и какие изменения это влечёт в повседневной работе разработчика. Чтобы показать, как может выглядеть подобный новый рабочий процесс на практике, мы создадим простое Angular-приложение, которое ищет статьи в Википедии и выводит результаты в виде списка, используя «режим агента» GitHub Copilot. Назовём его «Search wiki app».
Или как культура страха убивает продукт
Многие компании мечтают о сильной и самоорганизующейся команде.
О людях, которые берут на себя ответственность, двигают проект вперёд и решают проблемы без лишнего шума...
Пустые состояния (Empty States) — это незаметные, но критически важные элементы интерфейса. Что видит пользователь, когда список задач пуст, поиск не дал результатов или дашборд ещё не содержит данных? Пустой экран? Бесполезный спиннер? Или продуманное сообщение, которое помогает сориентироваться?
С появлением декларативного управления потоками (declarative control flow) в Angular обработка пустых состояний стала проще и элегантнее. Одна из ключевых возможностей — директива @empty, которая делает код чище, а интерфейс — дружелюбнее.
Давайте разберёмся, как это работает.
Привет, Хабр! Это Антон Дятлов, инженер по защите информации в Selectel. В современных базах данных JSON — де-факто стандарт для хранения полуструктурированных сведений. PostgreSQL предлагает два специализированных типа для работы с ним: json и jsonb. Первый хранит точную текстовую копию документа со всеми пробелами и порядком ключей. Второй применяет оптимизированный бинарный формат.
Рассказываем про jsquery — расширение, которое предоставляет полноценный язык для формулирования выборок. Появляется возможность писать декларативные, понятные и очень быстрые инструкции для работы с jsonb-полями.
Хотите ускорить запуск приложения и сэкономить память? Аннотация @Lazy в Spring поможет инициализировать бины только тогда, когда они действительно понадобятся. Команда Spring АйО поможет разбобраться, как применять @Lazy точечно и глобально, в чём плюсы и подводные камни ленивой инициализации, и как избежать неожиданных ошибок на проде.
Большие языковые модели (LLM) становятся неотъемлемой частью инструментов генерации, анализа и автоматизации программирования. Их возможности позволяют автоматизировать разработку, искать ошибки, генерировать тесты, осуществлять перевод между языками программирования. Однако одно из ключевых ограничений — контекстное окно, то есть максимально возможная длина входных данных. С ростом объема современных программ эффективность работы LLM с длинным кодом становится всё более актуальной задачей, особенно учитывая вычислительные и финансовые издержки обработки длинных последовательностей.
Минификация кода — процесс сокращения программного текста до минимального, необходимого для сохранения семантики. Для современных LLM это уже не только техническая задача (как раньше для web‑ресурсов), а способ оптимизации использования ресурсов, экономия токенов, увеличение объема анализируемого кода, ускорение анализа и генерации. В данной статье рассматривается современное состояние исследований по минификации в контексте LLM, формулируются гипотезы о её влиянии, а также обсуждаются перспективы для программной лингвистики.
С полгода назад я начал чаще использовать для программирования Python. Почему? Конечно, из-за ИИ. Лично для меня очевидно, что сегодня эта сфера связана с очень большими деньгами перспективами во всех направлениях. А какой язык является самым распространённым для ИИ? Да-да, как-раз этот проныра.
Я уже писал на Python, но только небольшие скрипты. К примеру, вот этот скрейпит метаданные всех видео с моего канала на YouTube. Собранные метаданные выводятся в виде файла JSON, который я использую для показа красивой статистики роликов на этой статичной странице. Как можно видеть здесь, этот скромный скрипт через GitHub Actions выполняется в соло-режиме каждый понедельник. Просто реализовать всё это на Python куда проще, чем с помощью того же Batch. И не только из-за более дружественного синтаксиса, но и потому, что его интерпретатор нативно интегрирован во все дистрибутивы Unix. Разве не круто?
Вы знаете из чего и как строятся программы? Странно что ни в одной из статей о программной архитектуре вы не найдете упоминаний о том из чего эти программы строятся.
Я попробую изложить свое понимание, понимание профессионала с более чем 20-ти летним опытом построения, рефакторинга программ. Возможно я в чем-то, а может и совсем, буду не прав и ошибаюсь, но тогда в комментариях, а может и в новых статьях мы увидим откровения знающих профессионалов, которые разобьют в пух и прах мои рассуждения, то есть в любом случае должно быть интересно. Но, мне кажется, кто-то должен рискнуть начать рассуждать на эту тему.
Dependency Injection (DI) один из столпов, на которых держится фреймворк Angular. Каждый разработчик, так или иначе, сталкивается с ним с первого дня: запрашивает сервисы в конструкторе, добавляет providedIn: 'root' и видит, как «магия» работает. Но именно в этом и кроется ловушка.
Для многих DI так и остается на уровне «магии» удобного механизма, который просто работает. Однако поверхностное понимание этого мощнейшего инструмента неизбежно приводит к архитектурным компромиссам: неочевидным утечкам памяти, сложностям в тестировании, созданию неявных связей между компонентами и, в конечном счете, к коду, который трудно поддерживать и масштабировать.
Эта статья не очередной пересказ официальной документации. Это глубокое погружение в архитектуру и философию Dependency Injection в Angular. Наша цель демистифицировать «магию» и превратить ее в предсказуемый, управляемый и мощный инженерный инструмент в вашем арсенале.
Мы пройдем путь от фундаментальных принципов инверсии контроля (IoC) до тонкостей иерархического инжектора. Мы разберем на атомы все стратегии предоставления зависимостей, научимся управлять их жизненным циклом и областью видимости. Мы изучим продвинутые паттерны с использованием InjectionToken и multi-провайдеров и поймем, как современная функция inject() меняет подход к композиции логики.
Всем привет.
Я — разработчица, которая пришла в IT не из классического CS-бэкграунда, а из гуманитарной сферы. Python покорил меня своей читаемостью, и вот уже третий год я работаю в продакшене, где сталкиваюсь с самым сложным противником — багами. Особенно теми, которые я сама случайно создаю.
Сегодня расскажу историю одного бага, который чуть не уложил наш сервис. А потом неожиданно превратился в полезную фичу.
Почему многие разработчики не мыслят словами, а сразу «видят» архитектуру, блок-схемы, паттерны и фрагменты кода? Что особенного в мозге программиста и как он превращает абстрактные задачи в работающие системы? В этой статье я разбираюсь в когнитивной архитектуре программистского мышления: от памяти и нейронных связей до привычки «думать в коде», приводя примеры, личные наблюдения и немного кода на Python, C++ и Haskell.
Сейчас джунам практически невозможно вкатиться в IT — об этом только ленивый не написал. Просто нет стартовых позиций, а на стажировки берут только студентов топовых вузов. Компании хотят «готовых бойцов», желательно с тремя годами опыта.
Это реальная проблема. И, как это обычно бывает, там, где есть боль, быстро появляются те, кто умеет на ней зарабатывать.
Так на рынке появился новый жанр — вкат в IT как услуга. Эти люди называют себя менторами, но по факту они учат не писать код, не работать в команде и даже не решать задачи. Они учат врать уверенно.
Привет, Хабр!
Сегодня мы рассмотрим, как заставить PostgreSQL самостоятельно крутить K-Means для сегментации клиентов, не вытаскивая данные наружу. Пройдемся по циклу: нормализуем фичи в materialized view, напишем функцию PL/PythonU, которая дергает scikit-learn, сохраняем cluster_id обратно в таблицу и закрываем гештальт отчётом «доход по кластеру» чистым SQL.
Команда Spring АйО не могла остаться в стороне и не прокомментировать одну из самых обсуждаемых новинок Kotlin, анонсированную на KotlinConf 2025 — Rich Errors.
Это вторая часть материала о финансовом стеке — теперь на уровне hard. В этой статье — не про SUM и диаграммы. Здесь речь пойдёт об ИТ-инструментах, которые помогают финансистам выйти за пределы ручной рутины, автоматизировать ключевые процессы и действительно влиять на бизнес.
Если вы уже уверенно работаете в Excel, пишете SQL-запросы и собираете отчёты — пора двигаться дальше. Power Query, витрины в SQL, архитектура BI, Python, API — всё, что позволит вам:
- ускориться в 3 раза,
- сократить рутину до минимума,
- стать архитектором аналитики, а не просто исполнителем.
Разберём, какие навыки нужны на продвинутом уровне, какие задачи они решают, как учиться эффективно — и как собрать из всего этого живую, работающую систему, встроенную в ваш рабочий процесс.
Сегодня чат‑боты и интеллектуальные ассистенты широко применяются в различных сферах: поддержка клиентов, корпоративные системы, поисковые сервисы и во многих других. Для их разработки часто используют архитектуру Retrieval‑Augmented Generation (RAG), которая объединяет генерацию ответа с поиском данных во внешних источниках. Такой подход помогает ботам и ассистентам давать более точные и актуальные ответы. Но на практике оказывается, что RAG сталкивается с проблемой повторяющихся запросов, из‑за которой система многократно выполняет одни и те же вычисления, повышая нагрузку и время отклика.
Всем привет! Меня зовут Вадим, я Data Scientist в компании Raft, и в этой статье мы разберемся, что такое векторный кэш и как его использовать. Давайте начнем!
Привет! На связи разработчик Максим и инженер по качеству Евгения из Т-Банка. Как-то мы задумались о переходе на TBD, чтобы избежать develop-ветки со всеми вытекающими.
Внедрение TBD оказалось более сложным процессом, чем мы думали сначала. Углубившись в тему, осознали, насколько важно учесть множество деталей, которые нужны для успешного перехода: в каких процессах необходимо настроить автоматизацию, доработать тесты, обновить документацию и сделать многое другое.
В этой статье мы поделимся опытом перехода на TBD: планом внедрения и вопросами, с которыми мы столкнулись.
Cтатья пригодится инженерам уровня middle и ниже и тимлидам. Для senior-инженеров статья не будет откровением, но надеемся, что станет местом для обсуждения нюансов внедрения или возможностью посмотреть на процесс с точки зрения QA.
Погнали!
В мире, где ваша деловая переписка зависит от чужих алгоритмов и сомнительной репутации общих IP-адресов, полный контроль — это не прихоть, а фундамент цифровой независимости. Нас годами убеждали, что управлять своей почтой — удел корпораций. Но это не так. Имея надежную платформу и правильные инструменты, вы можете стать хозяином своей коммуникации.
В этом руководстве мы пройдем весь путь: от развертывания сервера до отправки первого письма с настроенной и автономной почтовой системы. Никаких «черных ящиков» и компромиссов. Только вы, надежное «железо» и стопроцентный контроль.
