Программирование *

Блог компании AvitoTechПрограммирование*Управление разработкой*Учебный процесс в IT

30 мая в 12:585.3K

Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?

В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.

Блог компании Cloud.ruПрограммирование*IT-инфраструктура*Облачные сервисы*

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

+21

veta_pf

30 мая в 11:274.9K

Как не только быстро развернуть бота в облаке без сложных настроек, но и сэкономить на его поддержке? Обсудим на предстоящем вебинаре 🖥️

Архитектор решений Cloud.ru Илья Смирнов расскажет:

как развернуть бота в облаке — варианты, а также плюсы и минусы каждого подхода;
в чем особенность развертывания бота;
какие нужны компоненты, чтобы построить бота в облаке.

А еще покажет демо по настройке вебхука для Telegram-бота, обработке событий и хранению данных в облаке.

📆 Когда: 5 июня в 11:00 мск

📍 Где: онлайн

Зарегистрироваться 👈

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

dronperminov

28 мая в 13:345.5K

Веб-разработка*JavaScript*Программирование*Говнокод

Я устал от форматирования JSON файлов

Я много и часто просматриваю JSON-файлы: от конфигураций сервисов до API ответов и логов. Каждый раз, открывая очередной файл, я форматирую содержимое, чтобы было удобнее читать (ведь JSON не только machine-readable, но и human-readable). И каждый раз я грущу, что все сервисы (онлайн, встроенные средства IDE и даже плагины) предоставляют лишь две крайности: форматировать всё или ничего (минифицировать в одну строку).

Но что, если я хочу отформатировать JSON лишь до определённого уровня? Что, если у меня есть огромный список словарей (возможно, даже глубоких), который при форматировании выглядит как-то так:

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {
            "day": 5,
            "month": 4,
            "year": 1983
        }
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {
            "day": 6,
            "month": 2,
            "year": 1945
        }
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {
            "day": 10,
            "month": 11,
            "year": 1978
        }
    }
]

Что, если я хочу оставить каждый словарь в более компактном (не совсем минифицированном) виде? Например, таком:

[
    {"id": 1, "name": "Alice", "birthday": {"day": 5, "month": 4, "year": 1983}},
    {"id": 2, "name": "Bob", "birthday": {"day": 6, "month": 2, "year": 1945}},
    {"id": 3, "name": "Eve", "birthday": {"day": 10, "month": 11, "year": 1978}}
]

Или я хочу, чтобы в каждом словаре развёрнуты были только внешние ключи?

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {"day": 5, "month": 4, "year": 1983}
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {"day": 6, "month": 2, "year": 1945}
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {"day": 10, "month": 11, "year": 1978}
    }
]

Да, многие текстовые редакторы вроде Sublime Text или VS Code дают возможность свернуть контент до определённого уровня. Но что, если я хочу оставить файл в этом промежуточном виде и просматривать его прямо в терминале, подключившись по ssh? Или я хочу посмотреть файл на гитхабе с телефона? Да, возможно, мои вкусы весьма специфичны, но в существующих реалиях я вынужден грустно довольствоваться лишь полностью развёрнутым вариантом (или делать это вручную). Встроенные средства форматирования JSON в JS или Python также не предоставляют простой возможности ограничить глубину (либо я так и не научился их готовить).

Поэтому я собрался с силами и написал свой форматтер с возможностью ограничить глубину. Помимо базового функционала вроде валидации, минификации и настройки количества отступов, в нём есть настройка максимальной глубины (по умолчанию она равна нулю, что соответствует привычному форматированию без ограничений).

Да, он вряд ли подойдёт, чтобы редактировать на лету гигантские JSON файлы. И он уж точно не пытается стать убийцей какого-либо из существующих онлайн сервисов. В первую очередь он призван решить мою проблему: сделать форматирование JSON чуточку более управляемым. А если и вы сталкивались с подобной проблемой, буду рад, если сервис поможет и вам!

Octagon77

23 мая в 17:406.6K

Программирование*Usability*Rust*

TUI Rust, это Хабр. Хабр, я нашёл тебе годноту.

По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.

А за ним занятный канал, Автор которого, помимо носительности качественного английского языка, вроде как является приверженцем следующих идей

не плоди сущности без необходимости
используй меньше чтобы сделать больше
велик C и Rust наследует ему
всё преходяще, кроме вечного

Рекомендуется к ознакомлению вкатунам и начинающим пользы ради, а остальными удовольствия для.

Конкретика: Uutils, Fish, Nushell, Ripgrep, Fd, Bat, Eza, Zoxide, Xh, Zellij, Gitui, du-dust, dua, starship, yazi, hyperfine, evil-helix, bacon, cargo-info, fselect, ncspot, rusty-man, delta, ripgrep-all, tokei, wiki-tui, just, mask, mprocs, presenterm, kondo, bob-nvim, rtx, espanso.

1forma

22 мая в 14:585.6K

Блог компании Первая ФормаПрограммирование*IT-инфраструктура*СофтIT-компании

«Первая Форма» заняла третье место в рейтинге no-code платформ CNews

Портал Cnews опубликовал рейтинг и обзор российских no-code платформ. No-code — это способ разработки ПО без написания кода и участия программиста. С помощью встроенного конструктора и шаблонов в таком решении можно реализовать работу с задачами, кастомизировать интерфейс и не только.

При составлении рейтинга эксперты учитывали следующие критерии:

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

BPM-система «Первая Форма» заняла в рейтинге третье место. Эксперты высоко оценили её возможности для автоматизации, интерфейс и множество инструментов для работы с данными. Решение позволяет:

просматривать и детализировать бизнес-процессы вплоть до полей в документах;
расширять библиотеку функций под потребности компании;
просматривать логи по сервисам для оперативного решения проблем;
конструировать экранные формы под любые задачи;
интегрировать любые внешние сервисы по API и не только.

Полный рейтинг доступен на сайте Cnews.

yooteam

22 мая в 14:364.9K

Блог компании ЮMoneyПрограммирование*Управление разработкой*React Native*

Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐

Олег и Денис, наши фронтенд-разработчики, рассказали, почему отказались от этого фреймворка, несмотря на то что потратили на погружение в него немало времени. Это был хороший эксперимент, который дал нам много полезных инсайтов. ✍️

Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.

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

Вот что мы поняли при разработке:

● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.

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

Результаты нашего эксперимента

Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:

✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.

✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.

Будет ли применимо для нас в будущем — время покажет. Возможно, для новых продуктов это рабочая схема, сейчас — экономически неоправданно.

Блог компании AvitoTechПрограммирование*Качество кода*Учебный процесс в IT

22 мая в 12:003.9K

Каковы задачи Абстрактной Фабрики?

Новая серия курса «Паттерны и практики написания кода» целиком посвящена разбору достаточно громоздкого паттерна — Абстрактной Фабрики. Вместе с бэкенд-инженером Юрой Афанасьевым на примерах разберем, что это такое и как она реализуется.

+22

Программирование*Анализ и проектирование систем*Проектирование и рефакторинг*

18 мая в 20:228.5K

Дели код на области (scope) - второй принцип. Полный список принципов здесь

Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.

Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:

эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно
история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.
техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.

Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.

Здесь нужно быть внимательным, потому что:

границы субъективны, зависят от понимания смысла, целей, отвественности компонента,
для бэка и фронта границы областей проходят по разному в рамках одной системы:
- для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;
- для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.

Важно общаться с коллегами при обсуждении задачи, получать обратную связь и добиваться общих критериев для границ.

Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:

Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.
Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.
Фасетный поиск должен возвращать значения для фасетов и результаты. Кажется, у модуля 2 функции. Может стоит сделать 2 модуля, или это будет 2 интерфейса внутри одного модуля? Решу, когда буду думать над логикой, там станет понятна связанность этих функций. Нужно будет обсудить с коллегами.

На фронте эта же задача выглядит по другому: это будет страница поиска, в ней фасетые фильтры, список товаров, страницы, сортировка. А еще где-то в шапке поле для ввода текста. Тут нет речи о Каталоге, потому что по смыслу это страница и какие-то элементы ввода. Это не страшно. Пусть структура UI компонент соответствует интуитивным ожиданиям фронт разработчиков. Важно, что бы ожидания были у всех одинаковые. Это в слое контроллеров.
В слое приложения лежит логика построения запроса по контракту. Вот здесь появляется Каталог, как поддомен, и модуль фасетного поиска. Позже тут будет модуль категорий и отдельного продукта. Слой контроллеров будет использовать их в разных UI компонентах.

Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.

Деление на слои и области выглядит как "решетка":

Весь код должен быть раскидан по ячейкам. Рано или поздно у вас появится общий для нескольких модулей код. Он хочет занять несколько ячеек по горизонтали. Скорее всего он выполняет общую служебную функцию внутри слоя. Здесь можно поступить по-разному: вынести в отдельный пакет, модуль с одним слоем, как договоритесь с коллегами.

Как физически организовать решетку и общие пакеты разберемся дальше.

vadimr

17 мая в 15:457.6K

Программирование*

О компиляторах.

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

Ядро Linux по этому определению может называться очень большим проектом. Под него специально затачивается gcc.

У IBM есть даже специальный язык PL/S, используемый специально для написания операционной системы. Компилятор PL/S не доступен вне IBM.

vadimr

17 мая в 12:148.8K

Программирование*

О языках программирования.

Язык программирования обычно становится конфеткой через 40-50 лет активного использования, когда из него устраняются все абстрактные идеи авторов и привносятся свойства, реально нужные программистам.

Исключением из этого правила является C++, который, несмотря на довольно почтенный возраст, до сих пор представляет собой полигон для игры ума авторов.

С другой стороны, стандарт Scheme принимают голосованием программистов по спорным вопросам.

Чем дольше живу, тем больше ценю Лисп и Фортран.

Dimon_no_ne_tot

17 мая в 09:056.3K

Криптография*Программирование*Алгоритмы*

Магические квадраты с произведением

О магических квадратах известно, наверное, всё. А возможны ли магические квадраты, в которых равны не суммы значений в строках, столбцах и на диагоналях, а их произведения? Оказывается – возможны. В дальнейшем буду называть такие квадраты «магическими квадратами с произведением» (сокращённо – МКП).

Интересно, что, как и «обычных» магических квадратов, возможно бесчисленное множество вариантов МКП. В общем случае для трёх чисел a, b и n МКП размером 3 × 3 имеют вид:

При этом a ≠ b, a ≠ 1, b ≠ 1, a ≠ b², b ≠ a²,

Интересно, что любой МКП размером 3 × 3 может быть основой для формирования бóльших МКП. Одно из возможных решений заключается в том, чтобы поместить такой квадрат в центр квадрата 5 × 5 и потом подобрать такие остальные числа, чтобы они соответствовали свойствам МКП. Это означает, что МКП являются также так называемыми «рамочными магическими квадратами» – магическими квадратами, которые сохраняют свое магическое свойство, если в них отбросить окаймляющие «полосы» в две клетки.

После комментариев @miksoft я удалю сей свой пост

vvmtutby

16 мая в 18:567.5K

Программирование*

Преимущества реализации цикла FOR в Modula-3

Цикл FOR в Modula-3 был значительно улучшен по сравнению с его аналогами в Pascal и Modula-2. Эти изменения сделали его более безопасным, гибким и удобным для разработки. Вот ключевые преимущества:

1. Гибкость диапазона и шага

В Modula-3 цикл FOR позволяет задавать произвольные начальное, конечное значения и шаг, а не только ±1, как в Pascal.
Пример:

FOR i := 10 TO 1 BY -2 DO
  ...  // обратный счёт с шагом -2
END;

Это упрощает итерации с нестандартными шагами, что особенно полезно в научных вычислениях или обработке данных.

2. Локальная область видимости переменной цикла

Переменная цикла объявляется непосредственно в конструкции FOR, ограничивая её область видимости телом цикла. Это предотвращает случайные конфликты имён и уменьшает риск ошибок.
Пример:

FOR i := 1 TO 10 DO
  ...  // переменная i существует только здесь
END;

3. Защита от модификации переменной цикла

Переменная цикла внутри тела цикла доступна только для чтения. Её нельзя изменить, что исключает случайные ошибки, характерные для Pascal и Modula-2.

FOR i := 1 TO 5 DO
  i := 10;  // Ошибка компиляции: присваивание запрещено
END;

4. Поддержка различных типов данных

Цикл FOR в Modula-3 работает не только с целыми числами, но и с другими типами, такими как:

Перечисляемые типы (ENUM).
Диапазонные типы (например, поддиапазоны [1..10]).
Даже символы (CHAR), если это имеет смысл.

Пример с перечислением:

TYPE Color = {Red, Green, Blue};
FOR c := FIRST(Color) TO LAST(Color) DO
  ...  // итерация по всем элементам перечисления
END;

5. Безопасность и контроль типов

Modula-3 строго проверяет границы цикла на этапе компиляции. Если начальное значение превышает конечное при положительном шаге (или наоборот), цикл не выполняется, что предотвращает бесконечные циклы или ошибки времени выполнения.

6. Улучшенная читаемость

Синтаксис FOR в Modula-3 более выразителен, особенно при работе с массивами или списками. Например:

FOR i := 0 TO LAST(a) DO
  a[i] := ...  // явный обход массива
END;

Это делает код понятнее, чем использование циклов WHILE.

Сравнение с другими языками

Pascal/Modula-2:
- Ограничен шагом ±1.
- Переменная цикла может быть модифицирована внутри тела.
- Неопределённое поведение после завершения цикла.
Ada:
Modula-3 позаимствовал многие принципы безопасности из Ada (например, защита переменной цикла), но сохранил простоту синтаксиса.

Итог

Цикл FOR в Modula-3 сочетает гибкость, безопасность и выразительность. Его реализация отражает общие принципы языка: строгий контроль типов, минимизацию ошибок и удобство для разработчика. Это делает Modula-3 предпочтительным выбором для задач, где важна надёжность и читаемость кода.

QTU100

16 мая в 11:214.9K

Программирование*Облачные вычисления*DevOps*Микросервисы*

3 ключевые метрики, которые спасут микросервисный проект

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

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

Количество рестартов.
Фейлы readiness/liveness проб.
Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

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

Конверсию платежей (например, от корзины к оплате).
Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

Время отклика API (p95, p99).
Частоту ошибок 5xx/4xx.
Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Блог компании AvitoTechПрограммирование*Качество кода*Учебный процесс в IT

15 мая в 13:217.1K

Порождающие паттерны: какие они и в чем их назначение?

В новой серии третьего сезона курса «Паттерны и практики написания кода» перейдём от теории к практике и погрузимся в мир прикладных паттернов. В предыдущем видео мы узнали, что паттерны делятся на три группы: сегодня вместе с бэкенд-инженером Юрой Афанасьевым начнём рассматривать первую из них — порождающие паттерны.

Блог компании Cloud.ruПрограммирование*IT-инфраструктура*DevOps*

+25

veta_pf

13 мая в 11:285.1K

5 книг, чтобы прокачать скиллы в SRE 📚

Со всеми, кто развивает инженерные практики, подборкой делится Антон Быстров — SRE-инженер Cloud․ru.

📖 SRE Table of Contents OT Google. Это своего рода «путеводитель» по принципам Site Reliability Engineering (SRE). Он объясняет, почему определенные методы и процессы должны использоваться в разработке и эксплуатации систем. Книги служат отличной базой для понимания философии и практических аспектов SRE, включая мониторинг, автоматизацию, управление инцидентами и многое другое.

📖 Проект «Феникс». Книга, которая рассказывает историю трансформации крупной компании через призму внедрения методов DevOps. Автор романа Брайан Дэрроу показывает, как команда разработчиков и операционных сотрудников объединяется для достижения общей цели — создания и запуска нового продукта. Хотя «Проект „Феникс“» — это прежде всего художественное произведение, оно содержит множество реальных примеров и идей, которые будут полезны как разработчикам, так и менеджерам, стремящимся внедрить современные подходы к управлению проектами и процессами.

📖 Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих — Бхаргава А. Алгоритмы играют ключевую роль в работе любой системы, и эта книга поможет вам глубже понять их принципы. Она проиллюстрирована и написана понятным языком, что делает её идеальной даже для начинающих.

📖 Запускаем Prometheus. Мониторинг инфраструктуры и приложений: Пивотто, Бразил. Одна из базовых книг по мониторингу. Она подробно описывает, как использовать Prometheus для сбора и анализа метрик, что является неотъемлемой частью работы SRE. Понимание экосистемы Prometheus значительно упростит вашу повседневную работу.

📖 Киф Моррис — Программирование инфраструктуры. Это руководство по подходу к инфраструктуре как к самостоятельному продукту. Оно охватывает как теорию, так и практику, помогая понять, как эффективно управлять инфраструктурой и обеспечивать ее надежность и масштабируемость.

Уже читали книги из списка? А какие готовы порекомендовать от себя? Делитесь в комментариях 👇

Программирование*Анализ и проектирование систем*Проектирование и рефакторинг*

12 мая в 15:385.6K

Дели код на слои - первый принцип. Полный список принципов здесь

Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.

Этого достаточно, ведь у меня даже нет задачи. Я начну думать о моделях, адаптерах, объекта‑значениях, когда приступлю обдумыванию бизнес логики и реализации.

Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.

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

Для бэка это код, который описывает бизнес правила, отвечает за валидность и целостность данных во время обработки запроса. Такой код может быть реализован по разному:

— как модель, которые хранят состояние пока запрос обрабатывается;

— сервис без состояния

— функция с валидации целостности

Контроллеры — это все, что касается ввода и вывода.

Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.

На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:

— шаблоны, стили, функции, которые готовят данные для отображения и обрабатывают ввод пользователя

— обработчики событий

— обработчики роутов, потому что роутинг — это интерфейс ввода данных.

— слушатели сокет соединений

На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:

— контроллеры gRPC, HTTP,

— слушатели очередей,

— конструкторы ответа, мапперы данных в нужный формат и т. п.

— описание протоколов.

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

Инфраструктура

— обязана работать с тем, что отдает слой приложения

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

Здесь лежат:

— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.

— конструкторы запросов к БД, очередям или другим сервисам

— мапперы данных слоя приложения в нужный формат и обратно

Конфигурация — соединяет компоненты из всех слоев в единый модуль, микросервис, приложение. Конфигурация отвечает за передачу настроек и параметров из переменных окружения в компоненты.

Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.

Слой приложения может отсутствовать. Тогда контроллеры и инфраструктура взаимодействуют напрямую. Чтобы сохранить порядок, нужно определить — кто главный. Главным лучше делать того, кто более стабилен.

На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.

На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.

Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.

Программирование*Анализ и проектирование систем*Проектирование и рефакторинг*

12 мая в 15:356.3K

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

Кто-то решит, что они вредные. Подумайте, прежде чем применять. Кому-то материал покажется очень простым, почти очевидным. Мой опыт показывает, что даже "бывалые" наводят бардак, хотя все всё понимают.

Принципы сформированы на основе практического применения информации из книг:

Эрик Эванс. Предметно-ориентированное проектирование. Структуризация сложных систем.
Вон Вернон. Реализация методов предметно-ориентированного проектирования - DDD.
https://www.infoq.com/minibooks/domain-driven-design-quickly/
Влад Хононов. Изучаем DDD – предметно-ориентированное проектирование.
Роберт Мартин. Чистая архитектура.

В оригиналах некоторые вещи трактуются объемно и широко.

Я про конкретику, практику и про код, поэтому сознательно упростил или выбросил часть информации. Она мешает и запутывает не только новичков, но и опытных разработчиков. Поэтому это не классический DDD или чистая архитектура. Скорее это смешение и личный опыт. Попытаюсь выдавать информацию без "воды".

Погнали:

SomeEditor

12 мая в 14:005.8K

Блог компании Yandex Cloud & Yandex InfrastructureСистемное администрирование*Программирование*IT-инфраструктура*Конференции

Опубликовали программу infra.conf'25 — конференции про работу с высоконагруженными системами и инфраструктурой

Итоговая программа ежегодной infra.conf'25 объединит доклады про платформенную разработку, применение больших языковых моделей, решения с открытым исходным кодом, обеспечение безопасности, инфраструктуру для машинного обучения и мобильной разработки.

Спикерами infra.conf'25 станут ведущие инженеры и разработчики Яндекса, Купера, MTS Web Services, Positive Technologies, AvitoTech, Sber AI и других компаний. Организаторы мероприятия — команда Yandex Infrastructure, которая создаёт и предоставляет внутреннюю инфраструктуру Яндекса.

Конференцию откроет главный доклад от Андрея Година, руководителя Yandex Infrastructure, и Александра Чубинского, руководителя Yandex Platform Engineering.
Также среди спикеров infra.conf'25:

Александр Николаичев и Николай Гриценко из Yandex Infrastructure — «Все дороги ведут в Internal Development Platform (IDP)».
Роза Морозенкова из Купера — «ML‑платформа: зачем она нужна вам, нам и ML‑инженерам».
Кирилл Сюзев из команды платформы для разработчиков SourceCraft — «Облачный CI/CD — 5-звёздочный отель для особо ~~опасных~~ любимых пользователей».
Валерий Евдокимов из ecom.tech (ex. Samokat.tech) — «Превозмогая opensource: опыт внедрения OpenTelemetry, Qryn и Coroot для выстраивания системы наблюдаемости».
Виталий Шишкин из Positive Technologies — «Tetragon: лучшие практики и нюансы разработки Tracing Policy».
Эдуард Оболенский из Yandex Infrastructure — «Опыт построения инфраструктуры вокруг мобильной разработки».

Также гости мероприятия смогут посетить воркшоп по Surface Mount Device‑пайке — это процесс пайки электронных компонентов поверхностного монтажа к печатным платам.

infra.conf'25 пройдёт 5 июня в Москве в Loft Hall #8. Также доклады можно посмотреть онлайн на сайте конференции. Для участия нужно зарегистрироваться на сайте и получить приглашение.

+10

sobolevn

12 мая в 10:596K

Веб-разработка*Python*Программирование*Rust*

Новый тайпчекер для Python от авторов ruff и uv, написанный на Rust

Вышло видео про новый тайпчекер и lsp: ty (старое название red-knot) от авторов ruff и uv. Пока по первым впечатлениям – бомба! Не смотря на версию 0.0.0a8 🌚

Из плюсов:

Быстрый
На расте
Куча новых фичей для типов
Полная спецификация
Интеграция с ruff и IDEшками

Из минусов:

Пока есть баги (но их поправят, конечно же)
Нет плагинов (и скорее всего никогда не будет)
Софт от молодой и маленькой компании
Как сделать поддержку ty и mypy вместе? А если использовались ty_extensions?

Обсуждение: а как вам проект? Успели попробовать?

+10

monolithed

11 мая в 11:0510K

Программирование*Интерфейсы*Интернет-маркетинг*Карьера в IT-индустрииУдалённая работа

Хочу поделиться удобным сервисом для создания резюме. Изначально мы делали его как часть внутреннего продукта, но «Резюмеха» быстра выросла в отдельный сервис и теперь живёт своей собственной жизнью.

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

Формат — максимально читабельный и компактный. Мы постарались учесть всё, что может понадобиться для создания чистого и современного резюме. И, конечно, вы можете заполнить резюме как на русском, так и на английском.

Пользуйтесь, с удовольствием!

+12

atomlib

9 мая в 16:279.3K

Программирование*Системное программирование*Windows*История ITБиографии гиков

Рэймонд Чен — ветеран компьютерной индустрии, который работает в Microsoft c 1992 года. Рэймонд участвовал в разработке OS/2, Windows 95, DirectX и оболочки Windows, а последние десятилетия отвечает за сохранение обратной совместимости системы. В своём блоге Old New Thing Чен регулярно делится забавными историями из разработки софта, но также показывает действительно полезные примеры.

На этот раз Чен показал, почему история буфера обмена не отражает быстрые изменения содержимого буфера. Рэймонд приводит следующий фрагмент кода от клиента. Этот код был написан для некой утилиты, вставляющей в историю буфера обмена объекты. В некотором роде историю прошлых изменений превращали в будущее — целью было предугадать, какие элементы пользователь хотел бы видеть в истории буфера обмена.

// В целях наглядности вся проверка ошибок опущена
#include <windows.h>

void SetClipboardText(HWND hwnd, PCWSTR text)
{
    OpenClipboard(hwnd);
    EmptyClipboard();
    auto size = sizeof(wchar_t) * (1 + wcslen(text));
    auto clipData = GlobalAlloc(GMEM_MOVEABLE, size);
    auto buffer = (LPWSTR)GlobalLock(clipData);
    strcpy_s(buffer, size, text);
    GlobalUnlock(clipData);
    SetClipboardData(CF_UNICODETEXT, clipData);
    CloseClipboard();
}

// Чтобы они были под рукой, разместим эти строки в истории буфера обмена
static constexpr PCWSTR messages[] = {
    L"314159", // номер бага, который мы хотим исправить
    L"e83c5163316f89bfbde7d9ab23ca2e25604af290", // коммит, к которому привязываем ошибку
    L"Widget polarity was set incorrectly.", // комментарий, который нужно добавить
};

int wmain([[maybe_unused]] int argc,
          [[maybe_unused]] wchar_t* argv[])
{
    auto tempWindow = CreateWindowExW(0, L"static", nullptr, WS_POPUPWINDOW,
            0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr);

    for (auto message : messages)
    {
        SetClipboardText(tempWindow, message);
    }
    DestroyWindow(tempWindow);
    return 0;
}

Код записывает в буфер обмена последовательно три строковые переменные. Однако при запуске утилиты в истории буфера обмена оказывалась лишь одна — последняя. Куда делись две остальные?

Дело в том, что служба истории буфера обмена работает асинхронно через механизм Clipboard Format Listener, существующий с эпохи Windows Vista. В этом механизме через функцию AddClipboardFormatListener приложение добавляет себя в качестве листенера. После этого никаких дополнительных опросов буфера обмена проводить не нужно — система сама оповестит приложение, если буфер изменился.

При получении уведомления служба истории буфера обновляет собственно историю буфера обмена. Но из-за асинхронности событие может происходить с задержкой. Как объясняет Чен, из-за асинхронной природы обновлений при получении WM_CLIPBOARDUPDATE от Clipboard Format Listener буфер может успеть обновиться ещё раз.

Как считает Рэймонд, это даже не баг, а фича. Так получается избегать приложений, которые быстро спамили бы в буфер обмена множество изменений. Если даже пользователь не успевает воспользоваться содержимым буфера, то сохранять это для истории смысла нет, указывает Чен.

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

Рэймонд обещает в следующий раз показать, как исправить код выше.

Программирование*Управление проектами*Управление продуктом*Читальный зал

7 мая в 12:186.2K

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

Дедлайн есть всегда. Если ты его не знаешь, тебе его не сказали или сказали, что его нет - он все равно есть. Он настигнет тебя в самый неподходящий момент. Он будет для тебя "сюрпризом".

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

Периодически уточняй дедлайн. Дедайн может измениться. Ты его не контролируешь. Это нормально. Он может измениться в силу внешних обстоятельств. Твоя задача - держать руку на пульсе и уточнять изменения в дедлайне. Не жди, что тебе скажут первым о изменениях - не скажут.

А у меня нет дедлайна. Думаешь тебе повезло? Нет. Это повод задуматься. Скорее всего у источника задачи нет стратегии, целей, долгосрочных планов, ожидания не соответствуют действительности. Он не понимает, что хочет. Задача - это идея, без понимания практического применения. Скорее всего ты в "болоте". Если компания "живая", дедлайн тебя настигнет. А может быть тебя хотят "слить" и это ловушка? Я видел такое, так бывает.

QTU100

7 мая в 11:115.8K

Программирование*Облачные вычисления*DevOps*Микросервисы*

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.
Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.
Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
}

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

Andrey2008

6 мая в 15:217.3K

Блог компании PVS-StudioИнформационная безопасность*Программирование*Управление разработкой*Законодательство в IT

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);
PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);
продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

Блог компании AvitoTechПрограммирование*Качество кода*Учебный процесс в IT

6 мая в 13:416.8K

Как правильно работать с паттернами кода?

Всем привет! Это третий сезон курса «Паттерны и практики написания кода». Первая серия вводная: в ней бэкенд-инженер Юра Афанасьев знакомит вас с историей паттернов и их функциями, а также рассказывает, как с ними правильно работать.