Tune IT

Анатомия письма: почему email-дизайн — это машина времени в 1999 год

2026-04-08T17:34:56Z

Вы когда-нибудь пробовали применить display: flex или grid в коде письма? Если да, то вы знаете чувство глубокого разочарования, когда Gmail, Outlook или Yahoo решают, что ваш современный красивый макет должен выглядеть как стена текста, набранная на печатной машинке.

Добро пожаловать в мир email-дизайна — уникальной дисциплины, где правила веб-разработки не работают, а стандарты де-факто застыли в эпохе Netscape Navigator. Здесь дизайнер и верстальщик вынуждены использовать табличную вёрстку, писать инлайновые стили и воевать с условными комментариями для Outlook. И тем не менее, именно здесь рождаются письма, которые читают, по которым кликают и которые приносят миллионы.

Эта статья — глубокое погружение в специфику создания адаптивных писем. Мы разберем, почему таблицы до сих пор правят бал, как сделать письмо красивым на iPhone и при этом не сломать его на древней версии Microsoft Outlook.

Часть 1. Великий парадокс: Почему email живет в прошлом?

В отличие от сайтов, которые вы открываете в одном-двух браузерах (Chrome, Safari), email-клиентов — сотни. Каждый из них использует свой движок для рендеринга HTML:

Gmail (веб и приложение) использует свой собственный, сильно урезанный HTML-парсер.
Outlook (десктоп) печально известен тем, что использует движок Microsoft Word (!) для отображения HTML.
Apple Mail — один из самых «продвинутых», поддерживает современные CSS.
Яндекс.Почта, Mail.ru — имеют свои особенности.

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

Часть 2. Табличная вёрстка: Скелет вашего письма

Забудьте про <div> с display: flex. В мире email главный строительный блок — это <table>.

2.1. Почему таблицы?

Предсказуемость: Таблицы были созданы для отображения структурированных данных. Их алгоритм рендеринга (как ячейки растягиваются и выравниваются) одинаков во всех клиентах.
Надёжность: Они устойчивы к «съеданию» тегов и стилей. Если какой-то CSS не сработает, таблица всё равно останется таблицей.
Вложенность: Вся вёрстка письма — это матрёшка из вложенных друг в друга таблиц.

2.2. Базовая структура «резинового» письма

Современное адаптивное письмо строится по следующему шаблону:

<center>
    <table role="presentation" width="100%" border="0" cellpadding="0" cellspacing="0">
        <tr>
            <td align="center">
                <!-- Основной контейнер письма (ширина 600px) -->
                <table role="presentation" width="600" border="0" cellpadding="0" cellspacing="0">
                    <!-- ШАПКА -->
                    <tr>
                        <td> ... </td>
                    </tr>
                    <!-- ГЕРОЙ (Баннер) -->
                    <tr>
                        <td> ... </td>
                    </tr>
                    <!-- ТЕЛО С КОЛОНКАМИ -->
                    <tr>
                        <td>
                            <table role="presentation" width="100%" border="0" cellpadding="0" cellspacing="0">
                                <tr>
                                    <td class="stack" width="280"> Левая колонка </td>
                                    <td class="stack" width="20"> Отступ </td>
                                    <td class="stack" width="280"> Правая колонка </td>
                                </tr>
                            </table>
                        </td>
                    </tr>
                    <!-- ФУТЕР -->
                    <tr>
                        <td> ... </td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>
</center>

Ключевые моменты:

role="presentation" — говорит скрин-ридерам, что это таблица для вёрстки, а не для данных.
width="100%" — делает внешнюю таблицу «резиновой».
align="center" — центрирует всё письмо.

Часть 3. Адаптивность: Как превратить две колонки в одну

На десктопе мы видим две колонки текста. На мобильном телефоне они должны встать друг под друга. Это достигается с помощью медиа-запросов и трюка с display: block !important.

3.1. Медиа-запросы

Мы задаём правило: если ширина экрана меньше 600px, то заставляем наши колонки (с классом .stack) стать блочными и растянуться на 100%.

@media only screen and (max-width: 600px) {
    .stack {
        display: block !important;
        width: 100% !important;
    }
}

В нашем примере выше, у колонок ширина 280px и отступа 20px. На мобильном они получат width: 100% и выстроятся вертикально, а отступ превратится в пустую строку.

3.2. Проблема кнопок

Кнопки в письмах — это главная головная боль. <button> работает плохо. Ссылка <a> с padding тоже часто ломается в Outlook.
Надёжный способ (Bulletproof Button):
Сделать кнопку через границы ячейки таблицы.

<table role="presentation" border="0" cellpadding="0" cellspacing="0">
    <tr>
        <td align="center" bgcolor="#007bff" style="border-radius: 4px;">
            <a href="https://example.com" style="display: inline-block; padding: 12px 24px; color: #fff; text-decoration: none; font-weight: bold;">Купить сейчас</a>
        </td>
    </tr>
</table>

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

Часть 4. Тонкая настройка: Инлайновые стили и условные комментарии

4.1. Инлайн — король

Никогда не полагайтесь на то, что стили, прописанные в <head> или внешнем CSS, сработают. Gmail, например, вырезает <style> при определённых условиях. Правило: все стили, касающиеся отступов, цветов, границ, шрифтов, должны быть прописаны в атрибуте style каждого тега.

<td style="padding: 20px; font-family: Arial, sans-serif; color: #333;">

4.2. Условные комментарии для Microsoft Outlook

Outlook (особенно 2007, 2010, 2013) — это темная лошадка. Чтобы задать стили только для Outlook, используют условные комментарии, которые никто, кроме Outlook, не видит.

<!--[if mso]>
    <style type="text/css">
        /* Стили, которые увидит только Outlook */
        .outlook-button { background: #000; }
    </style>
<![endif]-->

А для обратной ситуации (спрятать что-то от Outlook):

<!--[if !mso]><!-->
    <div style="display: none;">Это увидят все, кроме Outlook</div>
<!--<![endif]-->

Часть 5. Изображения: Смертельный номер

В email-дизайне изображения — это источник проблем. Многие почтовые клиенты по умолчанию блокируют загрузку картинок (пользователь должен нажать «Показать изображения»). Если ваше письмо — одна большая картинка, пользователь увидит пустоту.

Правила работы с изображениями:

Не кладите текст на картинки. Если картинка не загрузится, текст не увидят.
Всегда прописывайте ALT-текст. И делайте его полезным: не «логотип», а «Купите iPhone со скидкой 20%».
Используйте атрибуты ширины и высоты. Без них Outlook может отобразить картинку размером 1x1 пиксель.

<img src="..." alt="Описание" width="600" height="200" style="display: block; width: 100%; height: auto;">

Спрайты и адаптивность: Чтобы картинка сжималась на мобильном, дайте ей style="width: 100%; height: auto;".

Часть 6. Инструменты и тестирование

Спроектировать письмо «на глаз» невозможно. Вы обязательно что-то сломаете в Outlook или Gmail.

Современный подход к созданию писем:

Дизайн в Figma: Рисуйте макет, помня, что ширина письма редко превышает 600px (оптимально для чтения).

Фреймворк MJML: Это спасение. Вы пишете простой, понятный код на MJML, а компилятор превращает его в идеально работающую табличную вёрстку. Это стандарт индустрии.

Тестирование (важно!):

Litmus / Email on Acid: Платные сервисы, которые прогоняют ваше письмо через 90+ клиентов и показывают скриншоты.
PutsMail: Бесплатный инструмент для отправки тестовых писем.
Реальная отправка: Заведите себе аккаунты в Gmail, Яндекс.Почте, Outlook.com, Mail.ru и отправляйте письма себе.

Заключение: Это не баг, это фича

Дизайн для email-рассылок раздражает веб-разработчиков своей архаичностью. Но это осознанный выбор, продиктованный средой. Умение создать надёжное, красивое и конвертирующее письмо, которое работает даже в Outlook 2007, — это признак высокой квалификации.

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

Нативная поддержка gRPC в Spring

2026-04-07T16:08:06Z

Не так давно в релиз был выкачена первая мажорная версия библиотеки Spring gRPC - для встроенной поддержки gRPC-сервисов в приложении Spring Boot. Она развивается внутри экосистемы Spring, а значит версионирование и интеграция с Boot - это теперь не вызывает проблем. У меня появился интерес протестить это in action.

Начнем с того, что подключим необходимые зависимости в build.gradle.kts:

implementation("org.springframework.grpc:spring-grpc-spring-boot-starter")
implementation("com.google.protobuf:protobuf-java")

Допустим, у нас есть такой proto-файл:

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

Реализация сервиса на kotlin будет выглядить следующим образом:

@GrpcService 
class GreeterService : GreeterGrpc.GreeterImplBase() {

    override fun sayHello(
        request: HelloRequest,
        responseObserver: StreamObserver<HelloReply>
    ) {
        val reply = HelloReply.newBuilder()
            .setMessage("Hello, ${request.name}!")
            .build()

        responseObserver.onNext(reply)
        responseObserver.onCompleted()
    }
}
// можно использовать и аннотацию @Service, но на личный вкус @GrpcService выглядит нагляднее

Spring gRPC автоматически обнаружит все бины, которые реализуют BindableService (это интерфейс, от которого наследует ImplBase), и зарегистрирует их на gRPC-сервере.

Дело за малым - осталось всё собрать и протестировать. Делать я это буду с помощью cli тулзы grpcurl, которая как раз предназначена для протыкивания grpc сервисов.

Подводя итог, можно сказать, что Spring gRPC успешно решает главную задачу - делает интеграцию gRPC в Spring Boot максимально бесшовной и нативной. Как показал тест, весь процесс настройки сводится к подключению стартера и созданию класса с аннотацией @Service. Автоматическое обнаружение сервисов и привычная работа через DI позволяют сосредоточиться на бизнес-логике, не отвлекаясь на инфраструктурные сложности.

Кэширование пользовательских ролей из стороннего сервиса при Stateless-аутентификации (Spring)

2026-04-06T13:47:44Z

Представим не столь редкую ситуацию, когда у нас есть некоторый сервис на базе Spring, к которому шлет запросы клиентское приложение. Фронтэнд взаимодействует с Keycloak (или другим сервером аутентификации, не столь важно), определяет пользователя, делающего запросы, и при обращении к нашему сервису подкладывает в заголовок "Authorization" Bearer-токен в виде JWT, на основании которого в сервисе должны происходить идентификация пользователя и определение прав доступа.

Схема обычная и соответствует стандарту авторизации OAuth 2.0, однако проблемы возникают, если нам необходимо непосредственно в процессе авторизации выдать те или иные права, основываясь на данных из другого сервиса, либо в целом приходится использовать какие-либо данные извне. Несмотря на все преимущества stateless-аутентификации, среди которых масштабируемость и производительность, в данном случае она будет проблемой, потому что при данном подходе сервер не использует сессии и не хранит никакой информации о клиенте между запросами. Таким образом, информация из стороннего сервиса будет запрашиваться заново при каждом запросе, что может сильно ударить по производительности системы. Конечно подобные проблемы лучше решать еще на этапе проектирования архитектуры всей системы, но если ситуация уже возникла, то решение есть.

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

Шаг 1. Зависимости и конфигурация приложения

Добавить зависимости:

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-oauth2-resource-server'
    implementation 'org.springframework.boot:spring-boot-starter-cache'
    implementation 'com.github.ben-manes.caffeine:caffeine'
}

В главный класс надо добавить аннотацию @EnableCaching, которая включит кэширвание в Spring
Добавить в application.yml нужные настройки:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://your-keycloak.com/realms/test
  cache:
    cache-names: infoFromOtherService
    caffeine:
      spec: expireAfterWrite=60s,maximumSize=1000

Здесь под issuer-uri мы указываем адрес Keycloak для проверки валидности токена, который пришел с клиентского приложения. В разделе cache указываем название для кэша, где мы будем хранить информацию о пользователе, приходящую из стороннего сервиса. В spec мы указываем настройки caffeine, которые помогут не очищать кэш самостоятельно, а задать ему срок жизни (в данном случае 60 секунд), после которого данные будут запрашиваться снова. В maximumSize пишется максимальный размер кэша, чтобы он не мог занять слишком много места.

Шаг 2. Сервис, который запрашивает данные о пользователе из стороннего сервиса


import org.springframework.cache.annotation.Cacheable;
import org.springframework.stereotype.Service;

@Service
public class ExternalSourceService {

    // sync = true защищает от повторной отправки застрявших в очереди запросов при истечении кэша
    @Cacheable(value = "infoFromOtherService", key = "#username", sync = true)
    public List<String> getInfoFromExternalSource(String username) {
        // Вызов API
        return externalSourceClient.findExternalInfoByUsername(username); 
    }
}

Это самый обычный сервис, который делает необходимый запрос по указанному API. Не будем приводить его реализацию, поскольку это сильно зависит от конкретного случая, отметим только необходимость добавить аннотацию Cacheable, value которой совпадает с названием кэша из настроек. С помощью этой аннотации мы отмечаем, что результаты именно этого метода необходимо кэшировать.

Шаг 3. Конвертер, преобразующий JWT-токен

import org.springframework.stereotype.Component;
import org.springframework.beans.factory.annotation.Autowired;

@Component
@RequiredArgsConstructor
public class AuthenticationConverter implements Converter<Jwt, AbstractAuthenticationToken> {

    @Autowired
    private final ExternalSourceService externalSourceService;

    @Override
    public AbstractAuthenticationToken convert(Jwt jwt) {
        UUID userId = UUID.fromString(jwt.getSubject()); // UUID пользователя
        String username = jwt.getClaimAsString("preferred_username"); // имя пользователя
        Collection<GrantedAuthority> roles = extractKeycloakRoles(jwt); // получаем роли из Keycloak
        // получаем информацию о пользователе из стороннего источника (что кэшируется)
        String externalSourceUserInfo = externalSourceService.getInfoFromExternalSource(username);
        try {
            // пытаемся добавить роли пользователя из стороннего источника
            Collection<GrantedAuthority> rolesFromExternalSource = extractExternalRoles(externalSourceUserInfo);
            roles.addAll(rolesFromExternalSource);
        } catch (JsonProcessingException e) {
            log.error("Cannot parse user info ", e);
        }
        return new JwtAuthenticationToken(jwt, roles, username);
    }

    private Collection<GrantedAuthority> extractKeycloakRoles(Jwt jwt) {
        Map<String, Object> realmAccess = jwt.getClaim("realm_access");
        if (realmAccess == null || realmAccess.isEmpty()) return Collections.emptyList();
        Collection<String> roles = (Collection<String>) realmAccess.get("roles");
        return roles.stream()
                .map(role -> new SimpleGrantedAuthority("ROLE_" + role))
                .collect(Collectors.toList());
    }

    private Collection<GrantedAuthority> extractExternalRoles(String externalSourceUserInfo) throws JsonProcessingException {
        ObjectMapper objectMapper = new ObjectMapper();
        JsonNode rootNode = objectMapper.readTree(externalSourceUserInfo);
        // достаем нужный кусок JSON, но парсинг ответа от стороннего сервиса зависит от особенностей конкретной системы
        JsonNode globalRoles = rootNode.get("roles");
        return objectMapper.convertValue(globalRoles, new TypeReference<List<String>>() {
                }).stream().map(role -> new SimpleGrantedAuthority("ROLE_" + role))
                .collect(Collectors.toList());
    }

Шаг 4. Конфигурация Spring Security

import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.annotation.Configuration;

@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Autowired
    private AuthenticationConverter authenticationConverter;

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .csrf().disable()
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and().authorizeRequests()
                    .antMatchers("/api/v1/example/**").authenticated()
                    .anyRequest().hasAnyRole("EXTERNAL_SOURCE_ADMIN")
                .and().oauth2ResourceServer().jwt().jwtAuthenticationConverter(authenticationConverter);

    }
}

Здесь мы уже можем в правилах проверки прав использовать те роли, которые мы получили из стороннего сервиса (вместе с кейклоковскими). И главное, что получение этих ролей не будет отрабатывать при каждом запросе к нашему сервису, а будет происходить лишь по истечении кэша, настройки которого, с использованием Caffeine, можно регулировать в application.yml.

REST API: 5 паттернов формирования ответов, которые используют опытные разработчики

2026-04-01T10:44:07Z

Введение

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

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

Возвращать необработанные JPA-сущности из REST-контроллеров — это один из тех паттернов, который кажется безобидным в начале, но затем превращается в системную проблему в production. Он не просто нарушает принцип разделения ответственности — он создаёт три взаимосвязанных риска одновременно: утечку чувствительных данных, жёсткую связанность API со схемой БД и потерю контроля над публичным контрактом.

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

Проблема прямого возврата сущностей

Прежде чем переходить к решениям, важно понять, в чем именно состоит проблема.

Рассмотрим типичную JPA-сущность:

@Entity
@Table(name = "users")
public class User {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String firstName;
    private String lastName;
    private String email;

    // Никогда не должно покидать сервер
    private String passwordHash;

    // Внутренние поля, не нужные клиентам
    private String internalNotes;
    private String resetToken;
    private LocalDateTime resetTokenExpiry;

    // Технические поля аудита
    @CreatedDate
    private LocalDateTime createdAt;

    @LastModifiedDate
    private LocalDateTime updatedAt;

    @Version
    private Long version;
}

А теперь — типичный контроллер новичка:

@GetMapping("/users/{id}")
public User getUser(@PathVariable Long id) {
    return userRepository.findById(id).orElseThrow();
    // В ответе окажется: passwordHash, internalNotes,
    // resetToken, resetTokenExpiry, version...
}

Этот код порождает три серьёзные проблемы.

Проблема 1: Утечка чувствительных данных. Поле `passwordHash` попадёт в JSON-ответ. Даже если там не открытый пароль, а хеш — это уже вектор для атак. Поле `resetToken` тоже не должно быть видно никому, кроме системы сброса пароля. Можно добавить `@JsonIgnore` на отдельные поля, но это ненадёжно: забудете об одном поле при добавлении — и утечка неизбежна.

Проблема 2: Жёсткая связанность с базой данных. Ваш API-контракт теперь является точным отражением вашей схемы БД. Переименовали `firstName` в `first_name` для соответствия coding style? Поздравляем — вы сломали всех клиентов. Разделили таблицу `users` на `users` и `user_profiles`? Теперь нужно менять не только схему, но и весь публичный API.

Проблема 3: Отсутствие контроля над контрактом. API должен выражать бизнес-понятия, а не структуру хранилища. Клиент хочет получить `fullName` вместо `firstName` + `lastName`? С сырыми сущностями это невозможно без изменения схемы БД.

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

Паттерн 1: Record-классы для формирования ответа

Проблема

Традиционные DTO-классы на Java требуют написания конструкторов, геттеров, сеттеров, `equals`, `hashCode` и `toString`. Это десятки строк шаблонного кода на каждую форму ответа. Даже с Lombok это всё равно дополнительные аннотации и косвенность.

Решение

Java Records (доступны с Java 16) дают вам неизменяемый объект передачи данных в несколько строк — без Lombok, без шаблонного кода, без сюрпризов.

public record UserResponse(
    Long id,
    String firstName,
    String lastName,
    String email
) {}

Вот и всё. Java автоматически генерирует конструктор, геттеры, `equals`, `hashCode` и `toString`. Объект неизменяем по умолчанию — никаких сеттеров, никаких случайных мутаций.

Полный пример

// Сервисный слой
@Service
@RequiredArgsConstructor
public class UserService {

    private final UserRepository userRepository;

    public User findById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new EntityNotFoundException("User not found: " + id));
    }
}

// Контроллер
@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    @GetMapping("/{id}")
    public UserResponse getUser(@PathVariable Long id) {
        User user = userService.findById(id);
        return new UserResponse(
            user.getId(),
            user.getFirstName(),
            user.getLastName(),
            user.getEmail()
        );
    }
}

Важные детали

Вложенные Record-классы хорошо работают для составных ответов:

public record AddressResponse(
    String street,
    String city,
    String country
) {}

public record UserDetailResponse(
    Long id,
    String firstName,
    String lastName,
    String email,
    AddressResponse address,        // вложенный record
    List<String> roles              // коллекции тоже поддерживаются
) {}

Кастомная сериализация настраивается через стандартные Jackson-аннотации:

public record UserResponse(
    Long id,
    String firstName,
    String lastName,
    String email,

    @JsonFormat(pattern = "dd.MM.yyyy")
    LocalDate birthDate,

    @JsonProperty("isVerified")
    boolean verified
) {}

Почему опытные разработчики это ценят: Record-классы самодокументируемы — любой член команды, открыв файл, немедленно видит полный контракт эндпоинта. Не нужно читать маппер, искать аннотации `@JsonIgnore` или гадать, какие поля попадут в ответ.

Паттерн 2: MapStruct для конвертации без шаблонного кода

Проблема

Ручное маппирование — серьёзная проблема при масштабировании. Когда у вас десять сущностей, каждая с двадцатью полями, написание маппинга вручную превращается в рутину, которая к тому же молча ломается. Добавили новое обязательное поле в `UserResponse`, но забыли обновить маппер? Компилятор промолчит, тесты не поймают — и вы получите `null` в production.

Решение

MapStruct генерирует код конвертации на этапе компиляции через annotation processing. Вы объявляете только интерфейс — всё остальное делает библиотека.

<!-- pom.xml -->
<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct</artifactId>
    <version>1.5.5.Final</version>
</dependency>
<dependency>
    <groupId>org.mapstruct</groupId>
    <artifactId>mapstruct-processor</artifactId>
    <version>1.5.5.Final</version>
    <scope>provided</scope>
</dependency>

Полный пример

// Базовый маппер
@Mapper(componentModel = "spring")
public interface UserMapper {

    // Простое маппирование: поля с одинаковыми именами — автоматически
    UserResponse toResponse(User user);

    // Маппирование коллекций — бесплатно
    List<UserResponse> toResponseList(List<User> users);

    // Кастомное маппирование полей с разными именами
    @Mapping(source = "passwordHash", target = "hasPassword",
             qualifiedByName = "passwordToBoolean")
    UserAdminResponse toAdminResponse(User user);

    @Named("passwordToBoolean")
    default boolean mapPassword(String passwordHash) {
        return passwordHash != null && !passwordHash.isEmpty();
    }

    // Игнорирование поля в целевом объекте
    @Mapping(target = "sensitiveData", ignore = true)
    UserPublicResponse toPublicResponse(User user);

    // Вычисляемые поля
    @Mapping(target = "fullName",
             expression = "java(user.getFirstName() + \" \" + user.getLastName())")
    UserSummaryResponse toSummaryResponse(User user);
}

// Использование в контроллере
@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;
    private final UserMapper userMapper;

    @GetMapping("/{id}")
    public UserResponse getUser(@PathVariable Long id) {
        return userMapper.toResponse(userService.findById(id));
    }

    @GetMapping
    public List<UserResponse> getAllUsers() {
        return userMapper.toResponseList(userService.findAll());
    }
}

Важные детали

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

// Превратить предупреждение в ошибку компиляции — рекомендуется для production
@Mapper(
    componentModel = "spring",
    unmappedTargetPolicy = ReportingPolicy.ERROR  // жёсткий режим
)
public interface UserMapper { ... }

Маппинг между вложенными объектами работает автоматически, если зарегистрировать вспомогательные маппинги:

@Mapper(componentModel = "spring", uses = {AddressMapper.class})
public interface UserMapper {
    // Address внутри User будет смаппирован через AddressMapper автоматически
    UserDetailResponse toDetailResponse(User user);
}

Почему опытные разработчики это ценят: MapStruct — это отраслевой стандарт в крупных компаниях. Один интерфейс заменяет десятки строк ручного маппинга, при этом ошибки обнаруживаются на этапе компиляции, а не в production в три часа ночи.

Паттерн 3: Проекции Spring Data для эндпоинтов чтения

Проблема

Типичный сценарий: страница со списком пользователей отображает только имя и email. Но ваш репозиторий загружает из базы данных всю сущность — включая `bio`, `avatarUrl`, `preferences`, `notificationSettings` и ещё пятнадцать полей, которые на этой странице просто не нужны. Это избыточный SELECT, лишний трафик и бесполезная нагрузка на сериализатор.

Решение

Spring Data поддерживает проекции — интерфейсы, которые указывают репозиторию: «загрузи только эти поля». На уровне SQL это выражается в `SELECT id, first_name, email FROM users` вместо `SELECT * FROM users`.

Полный пример

// Объявление проекции — просто интерфейс
public interface UserSummary {
    Long getId();
    String getFirstName();
    String getEmail();
}

// Проекция для вложенных объектов
public interface UserWithAddress {
    Long getId();
    String getEmail();
    AddressSummary getAddress();  // вложенная проекция

    interface AddressSummary {
        String getCity();
        String getCountry();
    }
}

// Репозиторий
public interface UserRepository extends JpaRepository<User, Long> {

    // Возвращает только нужные поля
    List<UserSummary> findAllBy();

    // С фильтрацией
    List<UserSummary> findByActiveTrue();

    // Динамическая проекция — тип выбирается вызывающим кодом
    <T> List<T> findByDepartmentId(Long departmentId, Class<T> type);
}

// Контроллер
@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserRepository userRepository;

    @GetMapping
    public List<UserSummary> getUsers() {
        return userRepository.findAllBy();
        // SQL: SELECT u.id, u.first_name, u.email FROM users u
    }

    @GetMapping("/list")
    public List<UserListItem> getUserList() {
        // Динамическая проекция
        return userRepository.findByDepartmentId(1L, UserListItem.class);
    }
}

Важные детали

Существуют два типа проекций, и важно понимать разницу:

Closed projection — интерфейс, где геттеры точно соответствуют полям сущности. Hibernate оптимизирует SQL: `SELECT id, first_name, email FROM users`. Это обеспечивает максимальную производительность.

Open projection — интерфейс с аннотацией `@Value` и SpEL-выражениями. Hibernate вынужден загружать всю сущность в память, а потом вычислять поле. Производительность хуже, но гибкость выше.

// Closed — оптимальный SQL
public interface UserSummary {
    Long getId();
    String getEmail(); // точное соответствие полям сущности
}

// Open — полная загрузка сущности, потом вычисление

// Расширенная проекция с вычисляемым полем через SpEL
public interface UserSummaryOpen {
    Long getId();
    String getEmail();
    String getFirstName();
    String getLastName();

    // Вычисляемое поле — склеивается на уровне Java, не SQL
    @Value("#{target.firstName + ' ' + target.lastName}")
    String getFullName(); // Hibernate загружает ВСЕ поля
}

Почему опытные разработчики это ценят: Проекции — это одновременно паттерн безопасности и инструмент оптимизации. Одно объявление интерфейса устраняет и DTO-класс, и лишний трафик к базе данных.

Паттерн 4: Конвертные ответы для единообразных контрактов API

Проблема

Клиент вашего API делает десять запросов к десяти разным эндпоинтам. У каждого своя структура: один возвращает объект напрямую, другой оборачивает в `{ "data": ... }`, третий при ошибке отдаёт строку, четвёртый — объект с полем `error`. Frontend-разработчики пишут десять разных обработчиков. Новые члены команды не знают, что ожидать. Интеграция с партнёрами превращается в квест по документации.

Решение

Единый конверт ответа (Envelope Pattern) — универсальная обёртка, которая делает каждый эндпоинт предсказуемым.

//  Универсальный конверт ответа
public record ApiResponse<T>(
    boolean success,
    String message,
    T data,
    List<String> errors,
    Map<String, Object> meta
) {
    // Успешный ответ с данными
    public static <T> ApiResponse<T> ok(T data) {
        return new ApiResponse<>(true, "OK", data, null, null);
    }

    // Успешный ответ с данными и пагинацией
    public static <T> ApiResponse<T> ok(T data, Map<String, Object> meta) {
        return new ApiResponse<>(true, "OK", data, null, meta);
    }

    // Ответ об ошибке
    public static <T> ApiResponse<T> error(String message) {
        return new ApiResponse<>(false, message, null, null, null);
    }

    // Ответ с несколькими ошибками (например, ошибки валидации)
    public static <T> ApiResponse<T> validationError(List<String> errors) {
        return new ApiResponse<>(false, "Validation failed", null, errors, null);
    }
}

Полный пример с пагинацией и обработкой ошибок

// Контроллер
@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;
    private final UserMapper userMapper;

    // Обычный запрос
    @GetMapping("/{id}")
    public ResponseEntity<ApiResponse<UserResponse>> getUser(@PathVariable Long id) {
        UserResponse user = userMapper.toResponse(userService.findById(id));
        return ResponseEntity.ok(ApiResponse.ok(user));
    }

    // Запрос с пагинацией — мета-информация передаётся в конверте
    @GetMapping
    public ResponseEntity<ApiResponse<List<UserResponse>>> getUsers(
            @RequestParam(defaultValue = "0") int page,
            @RequestParam(defaultValue = "20") int size) {

        Page<User> usersPage = userService.findAll(PageRequest.of(page, size));

        Map<String, Object> meta = Map.of(
            "page", usersPage.getNumber(),
            "size", usersPage.getSize(),
            "totalElements", usersPage.getTotalElements(),
            "totalPages", usersPage.getTotalPages(),
            "last", usersPage.isLast()
        );

        return ResponseEntity.ok(
            ApiResponse.ok(userMapper.toResponseList(usersPage.getContent()), meta)
        );
    }
}

// Глобальный обработчик ошибок — ключевая часть паттерна
@RestControllerAdvice
public class GlobalExceptionHandler {

    @ExceptionHandler(EntityNotFoundException.class)
    @ResponseStatus(HttpStatus.NOT_FOUND)
    public ApiResponse<Void> handleNotFound(EntityNotFoundException ex) {
        return ApiResponse.error(ex.getMessage());
    }

    @ExceptionHandler(MethodArgumentNotValidException.class)
    @ResponseStatus(HttpStatus.BAD_REQUEST)
    public ApiResponse<Void> handleValidation(MethodArgumentNotValidException ex) {
        List<String> errors = ex.getBindingResult()
            .getFieldErrors()
            .stream()
            .map(fe -> fe.getField() + ": " + fe.getDefaultMessage())
            .collect(Collectors.toList());
        return ApiResponse.validationError(errors);
    }

    @ExceptionHandler(AccessDeniedException.class)
    @ResponseStatus(HttpStatus.FORBIDDEN)
    public ApiResponse<Void> handleAccessDenied(AccessDeniedException ex) {
        return ApiResponse.error("Access denied");
    }
}

Теперь клиент всегда получает предсказуемую структуру:

// Успех
{
  "success": true,
  "message": "OK",
  "data": { "id": 1, "firstName": "Иван", "email": "ivan@example.com" },
  "errors": null,
  "meta": null
}

// Ошибка валидации
{
  "success": false,
  "message": "Validation failed",
  "data": null,
  "errors": ["email: must be a valid email", "firstName: must not be blank"],
  "meta": null
}

// Пагинация
{
  "success": true,
  "message": "OK",
  "data": [...],
  "errors": null,
  "meta": { "page": 0, "size": 20, "totalElements": 150, "totalPages": 8 }
}

Важные детали

Некоторые команды выбирают более лёгкий вариант без `success`/`errors` и просто полагаются на HTTP-статусы. Это тоже валидный подход. Главное — единообразие: выбранный формат должен применяться ко всем эндпоинтам без исключений.

Почему опытные разработчики это ценят: Единообразие API — признак зрелой кодовой базы. Это разница между API, с которым внешние команды работают с удовольствием, и тем, интеграции с которым боятся.

Паттерн 5: @JsonView для ролевого формирования ответов

Проблема

Бизнес-требование: публичные пользователи должны видеть имя и email; менеджеры - также дату рождения и телефон; администраторы должны видеть всё, включая внутренние заметки и историю входов. Самое простое решение — создать три отдельных DTO: `UserPublicResponse`, `UserManagerResponse`, `UserAdminResponse`. Однако, при десяти ролях и двадцати сущностях это превращается в сотни DTO-классов, которые нужно синхронизировать при каждом изменении.

Решение

Jackson `@JsonView` позволяет управлять видимостью полей на уровне сериализации: одна сущность, несколько представлений, ноль дублирующихся классов.

Полный пример

// Определение иерархии представлений
public class UserViews {
    // Иерархия через наследование:
    // Admin видит всё, что видит Manager,
    // Manager видит всё, что видит Public
    public interface Public {}
    public interface Manager extends Public {}
    public interface Admin extends Manager {}
}

// Сущность с разметкой полей
@Entity
@Table(name = "users")
public class User {

    @Id
    @JsonView(UserViews.Public.class)
    private Long id;

    @JsonView(UserViews.Public.class)
    private String firstName;

    @JsonView(UserViews.Public.class)
    private String lastName;

    @JsonView(UserViews.Public.class)
    private String email;

    // Видно менеджерам и выше
    @JsonView(UserViews.Manager.class)
    private String phone;

    @JsonView(UserViews.Manager.class)
    private LocalDate birthDate;

    @JsonView(UserViews.Manager.class)
    private String department;

    // Только для администраторов
    @JsonView(UserViews.Admin.class)
    private String internalNotes;

    @JsonView(UserViews.Admin.class)
    private LocalDateTime lastLoginAt;

    @JsonView(UserViews.Admin.class)
    private String lastLoginIp;

    @JsonView(UserViews.Admin.class)
    private boolean accountLocked;

    // Поля без @JsonView не попадают ни в один ответ
    private String passwordHash;
    private String resetToken;
}

// Контроллер с тремя представлениями
@RestController
@RequestMapping("/api/v1/users")
@RequiredArgsConstructor
public class UserController {

    private final UserService userService;

    // Публичный профиль — для всех
    @GetMapping("/{id}/profile")
    @JsonView(UserViews.Public.class)
    public User getPublicProfile(@PathVariable Long id) {
        return userService.findById(id);
        // Ответ: id, firstName, lastName, email
    }

    // Расширенный профиль — для менеджеров
    @GetMapping("/{id}/details")
    @JsonView(UserViews.Manager.class)
    @PreAuthorize("hasAnyRole('MANAGER', 'ADMIN')")
    public User getUserDetails(@PathVariable Long id) {
        return userService.findById(id);
        // Ответ: id, firstName, lastName, email, phone, birthDate, department
    }

    // Полный профиль — только для администраторов
    @GetMapping("/admin/{id}")
    @JsonView(UserViews.Admin.class)
    @PreAuthorize("hasRole('ADMIN')")
    public User getAdminProfile(@PathVariable Long id) {
        return userService.findById(id);
        // Ответ: все поля, размеченные @JsonView(Admin.class) и выше
    }
}

Важные детали

Тестирование ролевой видимости — важная часть работы с `@JsonView`:

@Test
void publicProfileShouldNotExposePhone() throws Exception {
    mockMvc.perform(get("/api/v1/users/1/profile"))
        .andExpect(status().isOk())
        .andExpect(jsonPath("$.phone").doesNotExist())
        .andExpect(jsonPath("$.internalNotes").doesNotExist())
        .andExpect(jsonPath("$.email").exists());
}

Программное переключение представления — когда роль определяется динамически:

@GetMapping("/{id}")
public ResponseEntity<String> getUser(@PathVariable Long id) throws JsonProcessingException {
    User user = userService.findById(id);

    Class<?> view = SecurityUtils.isAdmin()
        ? UserViews.Admin.class
        : UserViews.Public.class;

    ObjectWriter writer = objectMapper.writerWithView(view);
    return ResponseEntity.ok(writer.writeValueAsString(user));
}

Ограничение паттерна: `@JsonView` применяется только к сериализации. Если вы возвращаете саму сущность, вы всё равно загружаете из базы все поля. Для оптимизации запросов к БД этот паттерн нужно комбинировать с проекциями (паттерн 3).

Почему опытные разработчики это ценят: Ролевое управление видимостью полей — требование безопасности в большинстве production-систем. `@JsonView` реализует его на уровне сериализации — самом надёжном месте, где невозможно случайно «забыть» применить фильтрацию.

Сравнение паттернов: когда что применять

| Паттерн | Лучше всего для | Компромисс |

| Record-классы | Любые DTO, быстрый старт | Ручное маппирование при простых случаях |

| MapStruct | Большие проекты, много сущностей | Требует настройки зависимости |

| Проекции | Эндпоинты списков и чтения | Ограниченная гибкость при сложных вычислениях |

| Envelope | Публичные API, интеграции с партнёрами | Небольшой оверхед структуры ответа |

| @JsonView | Ролевой доступ к полям | Не оптимизирует запрос к БД |

На практике паттерны комбинируются. Зрелый проект обычно использует их все одновременно:

// Все паттерны вместе
@GetMapping("/{id}")
@JsonView(UserViews.Public.class)           // Паттерн 5: ролевая фильтрация
public ApiResponse<UserResponse> getUser(@PathVariable Long id) {
    return ApiResponse.ok(                  // Паттерн 4: конверт ответа
        userMapper.toResponse(              // Паттерн 2: MapStruct
            userService.findById(id)
        )
    );
    // UserResponse — это Record (Паттерн 1)
}

Заключение

Возврат сырых сущностей из REST API — это не просто технический долг. Это ошибка проектирования с реальными последствиями: утечки данных в production, сломанные клиенты после рефакторинга схемы, бесконечные вопросы от frontend-команды «а что именно возвращает этот эндпоинт?».

Каждый из пяти паттернов решает конкретную задачу:

Record-классы — явный, самодокументируемый контракт ответа без шаблонного кода.

MapStruct — безопасное маппирование на этапе компиляции вместо молчаливых ошибок в runtime.

Проекции — производительность и безопасность на уровне SQL-запроса.

Envelope-обёртки — единообразие, которое внешние команды перестают замечать, потому что «оно просто работает».

@JsonView — ролевое управление видимостью без взрыва DTO-классов.

Начать можно с малого. Если сегодня ваши контроллеры возвращают сырые сущности — введите Record-классы. Это займёт немного времени и сразу закроет риск утечки полей. Затем добавьте MapStruct. Envelope-паттерн введите перед первой внешней интеграцией. Проекции — когда появятся жалобы на производительность списков. `@JsonView` — как только появятся разные роли пользователей.

Поломалась оснастка порты управляемых сетей в zVirt

2026-03-30T11:39:55Z

В какой то момент в zVirt поломалась возможность импортировать виртуальные машины из образов в формате OVA размещённых на дисках хоста с гипервизором. Но о том как это чинить, как-нибудь в другой раз, а может и в очередном обновлении починится.
Дело в том, неудачные попытки импорта имеют неприятные последствия. В интерфейсе настройки Управляемых сетей на вкладке Порты нас встречает сообщение вида.

«Порт с идентификатором c7808f18-b5ab-4045-a230-c4ce59a86139 не найден»

И это все, что мы можем наблюдать на этой вкладке, соответственно управлять портами из веб-интерфейса становиться не возможно.
Как показало небольшое исследование, данная проблема возникает вследствие неудачного импорта. Во время импорта создаётся новая ВМ , для неё создаётся порт в соответствующей логической сети SDN. Но после краха процедуры импорта, виртуальная машина из конфигурации zvirt удаляется, а вот в базе данных программно определяемых сетей zvirt остаётся, что и вызывает вышеуказанное сообщение.
Чтобы исправить ситуацию сначала нужно найти какому порту соответствует указанный в ошибке идентификатор. Все парамеры портов хранятся в базе данных OVN , которую можно посмотреть на менеджере виртуализации.
Искомый идентификатор задаётся в параметре ovirt_device_id в поле external_ids в свойствах порта. Для поиска нужного порта можно использовать команду

ovn-nbctl find logical_switch_port external_ids:ovirt_device_id=<ИД из ошибки>

ovn-nbctl find logical_switch_port external_ids:ovirt_device_id=c7808f18-b5ab-4045-a230-c4ce59a86139 
_uuid               : e7ff4956-2151-4190-aee4-4d5681691050
 addresses           : ["56:6f:7e:2b:00:a2"]
 dhcpv4_options      : []
 dhcpv6_options      : []
 dynamic_addresses   : []
 enabled             : true external_ids        : {ovirt_device_id="c7808f18-b5ab-4045-a230-c4ce59a86139", ovirt_device_owner=oVirt, ovirt_nic_name=nic1, ovirt_security_groups="", zvirt_mode=dynamic, zvirt_namespace=common}
 ha_chassis_group    : []
 mirror_rules        : []
 name                : "c9afb0db-de90-4a42-a26c-88e69eb4c183"
 options             : {}
 parent_name         : []
 port_security       : []
 tag                 : [] 
tag_request         : [] 
type                : ""
 up                  : false

В поле name указано имя порта.
На всякий случай можно проверить в базе данных менеджера нет ли ВМ использующей этот порт, по имени порта или MAC адресу. Я просто поискал в дампе базы данных извлечённой из резервной копии (о том как делать резервные копии мы подробно рассказываем тут) и увидел такую запись

grep  05ef7f198d82   out_engine 21703    00000000-0000-0000-0000-000000000000    SYSTEM    \N        \N        \N        2026-03-25 11:24:02.987+03    SDN_PORT_CREATE_SUCCESS    16301    0    Port nic1 (9223a5aa-8394-4caf-9a33-05ef7f198d82) for VM DC602-location1 created successfully    f    \N        \N        \N        \N    \N    \N        \N        oVirt    \N    \N    \N    f    \N    \N    \N    \N

Что усилило мои подозрения.
Теперь фантомный порт необходимо удалить из базы данных OVN. Перед удаление настоятельно рекомендуется выполнить резервное копирование конфигурации менеджера.
Удаление выполняется с помощью команды ovn-nbctl lsp-del <имя порта >

ovn-nbctl lsp-del c9afb0db-de90-4a42-a26c-88e69eb4c183

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

Невидимые пользователи: Проектируем цифровую среду, доступную каждому

2026-03-09T16:28:05Z

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

Доступность (Accessibility, часто сокращаемая как A11y — где 11 означает количество букв между 'A' и 'y') — это не просто моральный долг или соответствие юридическим нормам. Это фундаментальное качество продукта, определяющее, сможет ли им воспользоваться каждый пятый житель планеты.

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

Часть 1: WCAG 2.2 — Навигационная карта доступности

Web Content Accessibility Guidelines (WCAG) — это «золотой стандарт» доступности, разработанный Консорциумом Всемирной паутины (W3C). В октябре 2023 года была утверждена новая редакция — WCAG 2.2, которая пришла на смену версии 2.1.

1.1. Четыре принципа POUR

В основе WCAG лежат четыре фундаментальных принципа, известных по аббревиатуре POUR. Контент должен быть:

Воспринимаемым (Perceivable): Пользователи должны иметь возможность воспринимать информацию, даже если у них есть сенсорные ограничения. Информация не может быть невидимой для всех органов чувств сразу .
Управляемым (Operable): Интерфейс должен работать с разными устройствами ввода. Пользователь должен иметь возможность управлять интерфейсом (например, нажимать кнопки), даже если не может использовать мышь .
Понятным (Understandable): И информация, и управление интерфейсом должны быть ясными. Пользователь должен понимать, где он находится и что происходит на странице.
Надёжным (Robust): Контент должен быть совместим с различными пользовательскими агентами, включая ассистивные технологии (скрин-ридеры, брайлевские дисплеи) .

1.2. Что нового в WCAG 2.2?

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

Фокус не должен исчезать (Focus Appearance — уровень AA): Визуальный индикатор фокуса клавиатуры (обычно контур вокруг элемента) должен иметь достаточный контраст и размер, чтобы его было легко заметить.
Перетаскивание (Dragging — уровень AA): Действия, требующие перетаскивания объектов (drag & drop), должны иметь альтернативный простой способ выполнения (например, нажатие кнопок), так как многие пользователи с моторными нарушениями не могут удерживать кнопку мыши при перемещении.
Целевой размер (Target Size — уровень AA): Для интерактивных элементов (кнопок, ссылок) рекомендуется минимальный размер 24x24 пикселя, чтобы по ним было легко попасть людям с тремором рук или при использовании мобильных устройств. Исключения делается для ссылок внутри текстового абзаца.
Аутентификация (Accessible Authentication — уровень AA): Процессы входа в систему не должны требовать решения задач, основанных на запоминании пароля или распознавании объектов (капча), если для этого нет альтернативы. Это критически важно для людей с когнитивными нарушениями.

Понимание WCAG 2.2 становится обязательным не только для госсектора. С 28 июня 2025 года Европейский акт о доступности (EAA) распространяет требования уровня AA на частный бизнес в ЕС: интернет-магазины, банки, телеком-операторов и многих других .

Часть 2: Дизайн для всех — учет особенностей пользователей

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

2.1. Нарушения зрения (от слепоты до дальтонизма)

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

Практические советы:

Контрастность: Обеспечьте достаточный контраст между текстом и фоном. Для обычного текста на уровне AA требуется контраст 4.5:1, для крупного текста — 3:1 . Используйте инструменты проверки контраста (Color Contrast Analyser, WebAIM).
Визуальные сигналы: Не используйте цвет как единственный сигнал, дающий информацию о состоянии объекта. Статус системы должен быть визуально понятным даже в черно-белом исполнении. Простыми словами, дублируйте сигнал иконками, текстом или подчеркиванием .
Текстовые альтернативы: Все значимые изображения должны иметь атрибут alt с описанием содержания. Декоративные изображения должны быть скрыты от скрин-ридеров (пустой alt="") , .
Масштабируемость: Интерфейс должен корректно отображаться при увеличении экрана до 400% без потери функциональности.

2.2. Нарушения моторики

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

Что делать дизайнеру:

Управление с клавиатуры: Все функции, доступные мышью, должны быть доступны с клавиатуры. Это означает логичный порядок фокуса (обычно совпадающий с визуальным порядком на странице) и видимый индикатор фокуса .
Крупные кликабельные области: Как требует WCAG 2.2, кнопки и ссылки должны быть большими, чтобы в них было легко попасть .
Достаточно времени: Избегайте таймеров или давайте возможность их продлить/отключить. Людям с моторными нарушениями может потребоваться больше времени на заполнение формы.
Отказ от сложных жестов: Предоставляйте простую альтернативу сложным жестам (смахивание, мультитач).

2.3. Когнитивные особенности

Это одна из самых сложных и разнообразных групп. Она включает людей с нарушениями обучаемости (дислексия), памяти, внимания, а также пожилых людей.

Что делать на практике:

Простота и предсказуемость: Интерфейс должен быть последовательным. Навигация и кнопки должны находиться на привычных местах. Избегайте неожиданных переходов и всплывающих окон.
Понятный язык: Используйте короткие предложения, избегайте сложных терминов и жаргона. Расшифровывайте аббревиатуры . Пишите "Январь" вместо "Янв".
Четкая структура: Используйте заголовки, списки и иконки для визуального разделения информации . Пользователю должно быть легко сканировать страницу взглядом.
Упрощенная аутентификация: Дайте возможность войти по биометрии или с помощью ссылки на email вместо запоминания сложного пароля.

Часть 3: Техническая реализация и семантическая верстка

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

3.1. Почему семантика — это основа?

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

Например, можно сделать "кнопку" так:

<div class="btn" role="button" tabindex="0">Купить</div>

Но гораздо правильнее и проще так:

<button>Купить</button>

Элемент <button> «из коробки» имеет правильную роль, управление с клавиатуры (Tab, Enter/Пробел) и фокус .

Ключевые семантические теги:

<header>, <nav>, <main>, <footer>, <aside> — создают навигационные вехи (landmarks), по которым пользователи скрин-ридеров могут быстро перемещаться.
<h1> — <h6> — создают иерархию заголовков. Никогда не пропускайте уровни (не перескакивайте с <h2> на <h4>). <h1> должен быть на странице один.
<ul>, <ol>, <li> — для списков.
<table> с <th> — для таблиц с данными (указывайте заголовки столбцов/строк).
<a> — для ссылок. Текст ссылки должен быть понятен вне контекста (никогда не пишите "нажмите здесь") .

3.2. Доступные формы

Формы — частый источник проблем. Чтобы сделать их доступными:

Каждый <input>, <select> или <textarea> должен быть связан с подписью через связку id и <label for="id"> или быть вложенным в <label>.
Группируйте логически связанные поля (например, адрес) в <fieldset> и давайте группе имя через <legend>.
Четко обозначайте обязательные поля и формат ввода данных в подписях, а не только цветом.

3.3. Когда HTML не справляется: WAI-ARIA

Иногда мы создаем сложные интерфейсные компоненты (например, кастомный выпадающий список с автодополнением), для которых нет подходящего HTML-тега. В таких случаях на помощь приходит WAI-ARIA (Accessible Rich Internet Applications).

ARIA позволяет добавить к элементам атрибуты, которые сообщают скрин-ридеру дополнительную информацию:

Роль (role): Что это за элемент? (role="dialog", role="tablist", role="progressbar").
Состояние и свойства: В каком он состоянии? (aria-expanded="true/false", aria-checked="true", aria-hidden="true").

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

Подробнее о создании доступной среды благодаря HTML

Часть 4: Тестирование — Смотрим и слушаем мир чужими глазами

Автоматические инструменты (Lighthouse, axe) — отличный первый шаг, но они находят лишь около 30% проблем. Настоящее тестирование доступности — это ручной труд и эмпатия.

4.1. Тестирование клавиатурой

Самый простой и эффективный тест. Отключите мышь и попробуйте пользоваться сайтом только с клавиатуры.

Используйте клавишу Tab, чтобы перемещаться по интерактивным элементам.
Всегда ли видно, где находится фокус (синяя или пунктирная обводка)?
Логичен ли порядок перехода? Не прыгает ли фокус с главного меню сразу в подвал?
Можно ли открыть все выпадающие списки, выбрать пункт и закрыть их?
Можно ли активировать все кнопки пробелом или энтером?

4.2. Тестирование со скрин-ридерами

Скрин-ридеры (читалки экрана) преобразуют цифровой текст в синтезированную речь или шрифт Брайля. Это основной инструмент для незрячих пользователей. Тестирование с ними — обязательный этап.

Популярные комбинации скрин-ридеров:

Windows: NVDA (бесплатный, лучше всего работает с Firefox). Или JAWS (платный, самый популярный в корпоративном секторе) .
macOS: VoiceOver (встроен в систему, лучше всего работает с Safari).
Android: TalkBack (встроен).
iOS: VoiceOver (встроен).

Что проверять с помощью скрин-ридера:

Чтение содержимого: Пройдитесь по странице стрелками (режим виртуального курсора). Все ли элементы озвучиваются? Правильно ли озвучиваются изображения (через alt)?
Навигация по заголовкам (клавиша H): Можете ли вы составить "карту" страницы и перейти к нужному разделу только по заголовкам? Не пропущены ли уровни? .
Навигация по ссылкам (клавиша K): Понятно ли, куда ведут ссылки, при прослушивании их вне контекста?
Навигация по вехам (landmarks) (клавиша D): Можно ли быстро перейти к основному контенту (<main>), минуя шапку и навигацию?
Работа с формами (клавиши F, E, C, R, B): Озвучивается ли подпись поля, когда вы входите в него? Правильно ли читаются сообщения об ошибках?
Динамический контент: Оповещает ли скрин-ридер о появлении всплывающих окон или обновлении части страницы?

4.3. Инструменты для помощи в тестировании

Помимо ручного тестирования, полезно использовать:

Accessibility Insights for Web (браузерный плагин): Помогает проходить проверки пошагово.
Lighthouse (встроен в Chrome DevTools): Быстрая автоматическая проверка основных метрик.
Инструменты разработчика (браузера): Позволяют инспектировать дерево доступности (Accessibility Tree), чтобы увидеть, какую именно информацию браузер передает скрин-ридеру.

Заключение

Доступность — это не финальный штрих и не чек-лист для галочки. Это философия проектирования, которая ставит человека в центр вселенной продукта. Интегрируя знания о WCAG 2.2, создавая продуманный дизайн для разных групп пользователей, опираясь на семантическую верстку и проверяя свою работу с реальными инструментами (от клавиатуры до VoiceOver), мы перестаем делить мир на "обычных" и "особенных" пользователей. Мы просто создаем качественный, удобный и честный продукт для всех.

Как я сократил время итерации в 3 раза на проекте с микросервисами

2026-03-04T11:28:24Z

Рано или поздно любая задача по написанию кода сводится к одному и тому же циклу: собрал проект -> запустил -> прогнал тесты -> поймал проблему -> выдвинул гипотезу -> внёс правки -> и снова по кругу, каждый раз надеясь, что в этот раз «точно всё».

На моём проекте - 10+ микросервисов на kotlin/spring, docker, gradle - один такой круг занимал примерно 3 минуты: секунд 15–30 на сборку всего проекта, около 2 минут на запуск контейнеров и ещё секунд 30 на тестирование. Казалось бы, 3 минуты - мелочь. Но представьте, что за одну задачу вы проходите этот цикл 10 раз (а это вполне реалистично). Получается 30 минут чистого ожидания - просто сидишь и смотришь в монитор. Мне показалось, что с этим стоит что-то сделать.

Первая мысль была в духе «надо как-то ускорить сборку». Но потом я понял, что проблема не в скорости отдельных шагов, а в том, что на каждой итерации собиралось и запускалось всё. Все 10+ сервисов. Каждый раз. Хотя для проверки моей гипотезы обычно нужны один-два из них.

Вопрос переформулировался: как сделать так, чтобы на каждую итерацию собиралось и поднималось только то, что действительно нужно?

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

Всё в одной конфигурации

В idea можно создать docker сompose конфигурацию, которая за один запуск делает всё: собирает нужные модули и поднимает контейнеры. Вот как это выглядит:

Тут указываем путь до docker compose файла, а в Services вместо указания 10+ сервисов, перечисляем только те, которые нужны для текущей задачи, по желанию указываем флаги для docker compose up. В Before-launch добавляем gradle-таски clean assemble, но только для конкретных модулей - это позволит idea выполнить их перед тем как запустить docker compose up.

Экономим энергию и пару секунд хоткеем Shift+F10 и радуемся результату - idea сначала собрала два нужных модуля, потом подняла два контейнера. Всё. Не нужно помнить порядок команд, не нужно их прописывать вручную.

Вместо одной «универсальной» конфигурации, которая поднимает всё, я создаю отдельную под каждую задачу. Работаю над gateway и some - конфигурация gateway+some. Завтра нужен другой набор сервисов - создаю новую. Создание такой конфигурации занимает пару минут. Но эта пара минут окупается уже на второй итерации.

Давайте глянем на цифры: сборка теперь занимает в среднем 5 секунд, а запуск 15 секунд. Итого мне нужно 50 секунд на проверку гипотезы, вместо 180, а это разница в 3 раза и это ощущается - стало легче сохранять фокус и контекст во время ожидания.

Если у вас похожий стек - kotlin/spring, gradle, docker, несколько микросервисов - попробуйте. Возможно, самое дорогое время в вашем рабочем дне - это не написание кода, а ожидание, пока он соберётся.

HashMap в Java: 10 фактов, о которых вы, возможно, не знали

2026-03-04T09:04:06Z

HashMap – наверное, самая используемая коллекция в Java. Мы кладём в неё элементы, достаём, редко задумываясь, что происходит под капотом. И в целом это нормально: класс работает, документация есть, сообщество стабильно советует переопределять equals и hashCode. Но если копнуть чуть глубже, обнаруживается немало деталей, которые могут удивить даже опытного разработчика.

Я собрала десять таких моментов. Не про то, как устроен HashMap в целом, а про то, что обычно остаётся за скобками.

1. Почему порог деревизации – именно 8

С Java 8, когда в одной корзине становится больше восьми элементов, связанный список преобразуется в красно-чёрное дерево. Логика понятна: начиная с какого-то размера список работает слишком медленно. Но почему порог установлен именно на восьми?

Ответ лежит в теории вероятностей. Разработчики Oracle смоделировали ситуацию с хорошей хеш-функцией и стандартным нагрузочным фактором 0.75. Согласно распределению Пуассона, вероятность того, что в одну корзину попадёт восемь элементов, составляет примерно 0.00000006. Это шесть случаев на десять миллионов.

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

2. Сдвиг на 16 бит: зачем он нужен

В исходном коде HashMap есть такая строчка:

(h = key.hashCode()) ^ (h >>> 16)

На первый взгляд кажется лишней. Зачем перед вычислением индекса ещё что-то делать с хеш-кодом?

Дело в том, что размер внутреннего массива всегда является степенью двойки. Индекс корзины вычисляется не через взятие остатка, а через побитовое И: (n - 1) & hash. Это быстро, но есть ограничение: в вычислении участвуют только младшие биты хеш-кода. Старшие, по сути, игнорируются.

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

3. Массив создаётся не сразу

Когда вы пишете new HashMap<>(), внутренний массив ещё не существует. Он создаётся только при первой вставке элемента. До этого объект занимает минимум памяти – фактически только накладные расходы на сам экземпляр.

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

4. Начальная ёмкость считается не так, как вы думаете

Конструктор new HashMap<>(100) часто понимают неправильно. Кажется, что если передать 100, то можно положить 100 элементов без расширения. На самом деле 100 – это размер внутреннего массива. Порог срабатывает при превышении ёмкость * loadFactor, то есть при 75 элементах.

Чтобы без расширения поместилось ровно 100 элементов, раньше нужно было писать (int) Math.ceil(100 / 0.75). Выглядит как заклинание… К счастью, в Java 19 появился метод HashMap.newHashMap(100), который делает этот расчёт автоматически.

5. Итерация зависит от ёмкости, а не только от размера

В документации сказано: время итерации пропорционально ёмкости плюс размер. Это не просто формальность.

Если вы создали мапу с ёмкостью 10 000, но положили в неё два элемента, итератор всё равно обойдёт все 10 000 корзин, проверяя каждую на наличие данных. Пустые корзины не пропускаются. Поэтому если вы планируете часто перебирать элементы, не стоит завышать начальную ёмкость без необходимости.

6. putAll может работать медленнее ручного копирования

Неожиданный факт, но в некоторых версиях Java для больших мап метод putAll (и конструктор копирования) работает медленнее, чем обычный цикл по entrySet() с ручным добавлением.

Исследователи OpenJDK связывают это с тем, что JIT-компилятор не всегда может эффективно оптимизировать полиморфные вызовы на границах методов. В простом же цикле оптимизаций больше, и код выполняется быстрее – разница может достигать 20–30%. Ситуация варьируется от версии к версии, но о ней полезно знать, если вы работаете с действительно большими объёмами данных.

7. Ключ null всегда попадает в нулевую корзину

То, что HashMap допускает один ключ null, знают все. Но мало кто задумывается, куда именно он попадает.

В методе hash() есть явная проверка: для null возвращается 0. При вычислении индекса (n - 1) & 0 результат всегда будет 0. То есть все ключи null хранятся строго в нулевой корзине и всегда располагаются первыми в списке или дереве этой корзины.

8. Бесконечный цикл в Java 7 больше не актуален

В Java 7 и более ранних версиях в многопоточной среде при одновременном расширении HashMap мог возникнуть бесконечный цикл – программа просто зависала.

Причина была в способе переноса элементов: использовалась вставка в начало списка, что в конкурентной среде могло замкнуть список само на себя. В Java 8 отказались от этого подхода в пользу вставки в конец. Бесконечные циклы ушли в прошлое. Но это не делает HashMap потокобезопасной – проблемы с потерей данных и состояниями гонки остались.

9. computeIfAbsent и merge могут бросить исключение во время выполнения

Методы compute, computeIfAbsent и merge удобны тем, что позволяют атомарно выполнить сложную логику вставки. Но у них есть особенность: они могут изменять мапу во время работы переданной функции.

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

10. Даже списки в Java 8 ищут быстрее

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

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

Эти детали редко всплывают в повседневной работе. Но когда сталкиваешься с неожиданным поведением или пытаешься выжать из приложения максимум производительности, знание внутреннего устройства HashMap помогает быстрее понять, что идёт не так и как это исправить.
Исходный код HashMap открыт, и в нём можно найти ещё много интересного. Иногда полезно просто заглянуть – хотя бы ради любопытства.

Go вместе изучать Go. Часть 6 (Заключительная)

2026-03-01T15:09:42Z

Введение

Добро пожаловать в заключительную статью нашей серии о языке программирования Go.

В ней мы рассмотрим три возможности языка: работу с изображениями через пакет image, обобщения (дженерики) для написания универсального кода и конкурентность — одну из главных «визитных карточек» Go.

Работа с изображениями

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

package image

type Image interface {
    ColorModel() color.Model
    Bounds() Rectangle
    At(x, y int) color.Color
}

Этот интерфейс описывает три метода: ColorModel() возвращает цветовую модель изображения, Bounds() — его границы в виде прямоугольника, а At(x, y int) — цвет пикселя по заданным координатам.

Обратите внимание: возвращаемое значение Rectangle метода Bounds на самом деле является типом image.Rectangle, поскольку объявление находится внутри пакета image.

Типы color.Color и color.Model также являются интерфейсами, но для простоты мы будем использовать готовые реализации color.RGBA и color.RGBAModel из пакета image/color.

package main

import (
	"fmt"
	"image"
)

func main() {
	// Создаем 100x100 пикселей типа RGBA
	m := image.NewRGBA(image.Rect(0, 0, 100, 100)) 
	
    // Мы можем вызвать методы, потому что *image.RGBA 
    // неявно реализует интерфейс image.Image.
	fmt.Println(m.Bounds())
	fmt.Println(m.At(0, 0).RGBA())
}
// Вывод:
// (0,0)-(100,100)
// 0 0 0 0

В этом примере мы создаём RGBA-изображение размером 100×100 пикселей. Функция Bounds() возвращает прямоугольник от точки (0,0) до точки (100,100). Метод At(0, 0).RGBA() возвращает четыре нуля — это значения красного, зелёного, синего и альфа-каналов для пикселя в левом верхнем углу. Нули означают полностью прозрачный чёрный цвет.

Универсальность кода: Обобщения (Generics)

Обобщения, появившиеся в Go 1.18, позволяют писать функции и типы, которые могут работать с любым типом данных, сохраняя при этом типобезопасность.

Параметры типов

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

func Index[T comparable](s []T, x T) int

Это объявление означает, что s — это срез элементов любого типа T, который удовлетворяет встроенному ограничению comparable. Значение x имеет тот же тип.

Ограничение comparable позволяет использовать операторы == и != для значений данного типа. В примере ниже мы используем его для сравнения значения со всеми элементами среза до нахождения совпадения:

package main

import "fmt"

// Index возвращает индекс x в срезе s или -1, если элемент не найден.
func Index[T comparable](s []T, x T) int {
    for i, v := range s {
        if v == x {
            return i
        }
    }
    return -1
}

func main() {
    // Index работает со срезом целых чисел
    si := []int{10, 20, 15, -10}
    fmt.Println(Index(si, 15))

    // Index также работает со срезом строк
    ss := []string{"foo", "bar", "baz"}
    fmt.Println(Index(ss, "hello"))
}

// Вывод:
// 2
// -1

Функция Index универсальна: она работает и с числами, и со строками — с любым типом, поддерживающим сравнение. Компилятор сам определяет конкретный тип T на основе переданных аргументов.

Обобщённые типы

Помимо обобщённых функций, Go поддерживает обобщённые типы. Тип можно параметризовать параметром типа, что особенно полезно для реализации универсальных структур данных.

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

package main

import "fmt"

// List представляет односвязный список, хранящий значения любого типа.
type List[T any] struct {
    next *List[T]
    val  T
}

// Push добавляет новый элемент в начало списка и возвращает новую голову.
func (l *List[T]) Push(val T) *List[T] {
    return &List[T]{next: l, val: val}
}

// Len возвращает длину списка.
func (l *List[T]) Len() int {
    count := 0
    for current := l; current != nil; current = current.next {
        count++
    }
    return count
}

// ToSlice преобразует список в срез.
func (l *List[T]) ToSlice() []T {
    var result []T
    for current := l; current != nil; current = current.next {
        result = append(result, current.val)
    }
    return result
}

// Find ищет элемент в списке (работает только для comparable типов).
func Find[T comparable](l *List[T], val T) bool {
    for current := l; current != nil; current = current.next {
        if current.val == val {
            return true
        }
    }
    return false
}

func main() {
    // Создаём список целых чисел
    var head *List[int]
    head = head.Push(1)
    head = head.Push(2)
    head = head.Push(3)

    fmt.Println("Длина списка:", head.Len())
    fmt.Println("Элементы:", head.ToSlice())
    fmt.Println("Содержит 2?", Find(head, 2))
    fmt.Println("Содержит 5?", Find(head, 5))
}

// Вывод:
// Длина списка: 3
// Элементы: [3 2 1]
// Содержит 2? true
// Содержит 5? false

Обратите внимание: метод Push возвращает новую голову списка, поскольку мы добавляем элементы в начало. Функция Find объявлена отдельно с ограничением comparable, потому что не все типы поддерживают сравнение через ==.

Конкурентность

Горутины

Горутина — это легковесный поток, управляемый средой выполнения Go:

go f(x, y, z)

Эта команда запускает новую горутину, выполняющую f(x, y, z). Вычисление f, x, y и z происходит в текущей горутине, а выполнение f — в новой.

Горутины работают в одном адресном пространстве, поэтому доступ к общей памяти должен быть синхронизирован. Пакет sync предоставляет полезные примитивы, хотя в Go чаще используются другие механизмы — каналы.

package main

import (
    "fmt"
    "time"
)

func say(s string) {
    for i := 0; i < 5; i++ {
        time.Sleep(100 * time.Millisecond)
        fmt.Println(s)
    }
}

func main() {
    go say("world")
    say("hello")
}

В этом примере две горутины выполняются параллельно: одна печатает «world», другая — «hello». Порядок вывода может варьироваться от запуска к запуску, поскольку горутины работают конкурентно.

// Пример вывода (порядок может меняться):
// hello
// hello
// world
// world
// ...

Каналы

Каналы — это типизированные каналы связи, через которые можно отправлять и получать значения с помощью оператора <-:

Каналы (chan) служат для безопасного обмена данными между горутинами.

ch <- v    // Отправить v в канал ch.
v := <-ch  // Получить значение из ch и присвоить его v.

Данные «текут» в направлении стрелки. Как и карты (maps) и срезы, каналы нужно создавать перед использованием:

ch := make(chan int)

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

package main

import "fmt"

func sum(s []int, c chan int) {
    sum := 0
    for _, v := range s {
        sum += v
    }
    c <- sum // отправить сумму в канал c
}

func main() {
    s := []int{7, 2, 8, -9, 4, 0}

    c := make(chan int)
    go sum(s[:len(s)/2], c)
    go sum(s[len(s)/2:], c)
    x, y := <-c, <-c // получить из канала c

    fmt.Println(x, y, x+y)
}

// Вывод: -5 17 12

Здесь работа по суммированию распределяется между двумя горутинами. Каждая считает сумму своей половины среза и отправляет результат в канал. Главная горутина получает оба значения и складывает их.

Буферизованные каналы

Каналы могут быть буферизованными. Размер буфера указывается вторым аргументом make.

Буферизованные каналы позволяют отправить несколько значений, не блокируя отправителя, пока буфер не заполнится.

ch := make(chan int, 100)

Отправка в буферизованный канал блокируется только когда буфер заполнен. Получение блокируется, когда буфер пуст.

Вот что происходит при переполнении буфера:

package main

import "fmt"

func main() {
    ch := make(chan int, 2)
    ch <- 1
    ch <- 2
    // ch <- 3 // Эта строка вызовет deadlock!
    
    fmt.Println(<-ch)
    fmt.Println(<-ch)
}

Если раскомментировать строку ch <- 3, программа зависнет (deadlock), потому что буфер размером 2 уже заполнен, и отправка будет ждать, пока кто-то не прочитает из канала. Но читать некому — главная горутина заблокирована на отправке. Результат — взаимная блокировка:

fatal error: all goroutines are asleep - deadlock!

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

Завершение передачи данных (Range и Close)

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

v, ok := <-ch

Значение ok будет false, если канал закрыт и пуст.

Цикл for i := range c получает значения из канала до его закрытия.

Важно: закрывать канал должен только отправитель, никогда — получатель. Отправка в закрытый канал вызовет панику. При этом каналы не похожи на файлы — их обычно не нужно закрывать. Закрытие необходимо только когда получателю нужно знать, что значений больше не будет.

package main

import "fmt"

func fibonacci(n int, c chan int) {
    x, y := 0, 1
    for i := 0; i < n; i++ {
        c <- x
        x, y = y, x+y
    }
    close(c) // Сигнал об окончании
}

func main() {
    c := make(chan int, 10)
    go fibonacci(cap(c), c)

	// Цикл range автоматически завершится, когда fibonacci вызовет close(c).
    for i := range c {
        fmt.Println(i)
    }
}

// Вывод: 0 1 1 2 3 5 8 13 21 34

Управляемый выбор: select

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

package main

import "fmt"

func fibonacci(c, quit chan int) {
    x, y := 0, 1
    for {
        select {
        case c <- x:
            x, y = y, x+y
        case <-quit:
            fmt.Println("quit")
            return
        }
    }
}

func main() {
    c := make(chan int)
    quit := make(chan int)
    go func() {
        for i := 0; i < 10; i++ {
            fmt.Println(<-c)
        }
        quit <- 0
    }()
    fibonacci(c, quit)
}

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

Default в Select

Ветка default выполняется, если ни один другой case не готов. Это позволяет выполнять неблокирующие операции:

select {
case i := <-c:
    // Данные пришли
default:
    //Данные не пришли немедленно, продолжаем работу
}

Взаимное исключение: sync.Mutex

Каналы отлично подходят для коммуникации между горутинами. Но если нам нужно просто гарантировать, что только одна горутина имеет доступ к переменной в данный момент (общение через каналы в данном случае просто напросто избыточно)?

Для этого существует взаимное исключение (mutex). Стандартная библиотека Go предоставляет sync.Mutex с двумя методами: Lock и Unlock.

package main

import (
    "fmt"
    "sync"
    "time"
)

// SafeCounter безопасен для конкурентного использования.
type SafeCounter struct {
    mu sync.Mutex
    v  map[string]int
}

// Inc увеличивает счётчик для заданного ключа.
func (c *SafeCounter) Inc(key string) {
    c.mu.Lock()
    c.v[key]++
    c.mu.Unlock()
}

// Value возвращает текущее значение счётчика.
func (c *SafeCounter) Value(key string) int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.v[key]
}

func main() {
    c := SafeCounter{v: make(map[string]int)}
    for i := 0; i < 1000; i++ {
        go c.Inc("somekey")
    }

    time.Sleep(time.Second)
    fmt.Println(c.Value("somekey"))
}

// Вывод: 1000

Без мьютекса 1000 горутин, одновременно изменяющих карту, вызвали бы гонку данных (data race) и непредсказуемое поведение. Мьютекс гарантирует, что в каждый момент времени только одна горутина работает с картой.

Обратите внимание на использование defer c.mu.Unlock() в методе Value — это гарантирует разблокировку даже при ранних возвратах или панике.

Заключение

Из этой статьи мы научились работать с несколькими важными аспектами Go. Мы узнали, как использовать пакет image для создания и манипулирования изображениями через интерфейс Image. Освоили дженерики — мощный механизм для написания универсального, переиспользуемого кода с параметрами типов и ограничениями вроде comparable и any. Погрузились в мир конкурентности Go: изучили горутины как легковесные потоки, каналы как средство безопасной коммуникации, оператор select для работы с несколькими каналами одновременно и мьютексы для защиты общих данных.

Эта статья завершает нашу серию материалов о языке Go. Мы прошли путь от основ синтаксиса до продвинутых возможностей языка, и теперь у вас есть некоторая база для написания эффективных, безопасных и элегантных программ на Go.

Успехов в ваших проектах!

iOS разработка: Как обнулить счетчик уведомлений в приложении

2026-02-26T13:16:20Z

Хотя мобильная разработка и не является основным профилем нашей компании, порой среди требований к корпоративному порталу оказывается его доступность с мобильных устройств. В связи с этим иногда приходится браться за нетипичные для нас задачи в виде разработки iOS и Android приложений. Однако оставим задачу систематического изложения основ мобильной разработки на другой раз. В этой заметке кратко зафиксируем, как наиболее просто решить проблему с красным значком с количеством уведомлений у иконки iOS-приложения, который не пропадает при переходе в программу. Речь идет о подобном красном кружке:

Зачастую происходит так, что при открытии приложения счетчик непрочитанных уведомлений не исчезает, а остается неизменным. Особенно часто такое возникает в случае, если переход происходит не по клику на уведомление в "Центре уведомлений", а непосредственно через экранное меню айфона.

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

Отличие SceneDelegate от AppDelegate в том, что последний предназначен для глобальной конфигурации всего приложения в целом. Там же происходит и регистрация Push-уведомлений, инициализация Firebase или иных уведомлений. Сейчас же нам нужен SceneDelegate, поскольку именно он обрабатывает событие открытия "сцены" приложения, при переходе в которую мы хотим обнулять счетчик уведомлений. Метод, который нам нужен для обработки события - sceneDidBecomeActive(_:). Он вызывается, когда сцена стала активной и готова к взаимодействию с пользователем.

Кусок кода на языке Swift, чтобы достичь поставленной задачи:

import UIKit
import SwiftUI

class SceneDelegate: UIResponder, UIWindowSceneDelegate {
    var window: UIWindow?

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        guard let _ = (scene as? UIWindowScene) else {
            return
        }
    }

    func sceneDidBecomeActive(_ scene: UIScene) {
            if #available(iOS 17.0, *) {
                UNUserNotificationCenter.current().setBadgeCount(0) { error in
                    if let error = error { print("sceneDidBecomeActive ERROR: \(error)") }
                }
            } else {
                UIApplication.shared.applicationIconBadgeNumber = 0
            }
            UNUserNotificationCenter.current().removeAllDeliveredNotifications()
        }

}

Для управления уведомлениями в iOS используется класс UNUserNotificationCenter. Во фрагменте кода выше мы используем его методы для сброса счетчика уведомлений на иконке приложения в ноль (метод setBadgeCount), а также для удаления уведомлений, пришедших от нашего приложения, в ленте "Центра уведомлений" (метод removeAllDeliveredNotifications). Метод удаления через UIApplication.shared.applicationIconBadgeNumber является устаревшим (для версий до iOS 17)

Keycloak: Identity Broker и настройка realm-to-realm брокеринга

2026-02-12T07:37:16Z

Добрый день!

Сегодня я хочу поговорить о механизме Identity Brokering внутри Keycloak, а точнее о возможности использовать один realm как Identity Provider для другого. Звучит просто, но на практике нюансов хватает, поэтому давайте разберёмся по порядку.

Что такое Identity Brokering

Identity Broker - это посредник, который устанавливает доверительные отношения между сервис-провайдером (приложением, которому нужна аутентификация) и одним или несколькими Identity Provider-ами (источниками учётных данных). В контексте Keycloak это означает, что один realm может делегировать аутентификацию другому realm-у - как внутри одного инстанса Keycloak, так и между разными серверами.

Суть проблемы: представьте, что в вашей организации несколько подразделений, каждое со своим realm-ом в Keycloak. У отдела разработки свой realm dev-realm с разработчиками, у HR - свой hr-realm с кадровиками. И вот появляется корпоративный портал, которому нужно пускать и тех, и других. Заводить всех пользователей заново? Синхронизировать базы руками? Нет, спасибо. Вот тут-то и приходит на помощь Identity Brokering.

Keycloak в роли брокера перенаправляет пользователя на страницу логина того realm-а, где хранятся его учётные данные, получает обратно токен и на его основе создаёт (или находит) локального пользователя в своём realm-е.

Подготовка окружения

Для демонстрации нам потребуется один инстанс Keycloak.
Мы создадим два realm-а:

idp-realm - realm, выступающий в роли Identity Provider. Здесь живут пользователи.
sp-realm - realm, выступающий в роли Service Provider (потребитель). Сюда будут «приходить» пользователи через брокеринг.

Запускаем Keycloak через Docker Compose. Создаём файл docker-compose.yml:

services:
  keycloak:
    image: quay.io/keycloak/keycloak:25.0.0
    command: start-dev
    environment:
      KEYCLOAK_ADMIN: admin
      KEYCLOAK_ADMIN_PASSWORD: admin
    ports:
      - "8080:8080"

Поднимаем:

docker compose up -d

Теперь можно заходить в админку http://localhost:8080 и авторизоваться.

Настройка realm-провайдера (IDP realm)

Начнём с realm-а, который будет отдавать пользователей. Создаём новый realm с именем idp-realm. В админке нажимаем на выпадающий список realm-ов в левом верхнем углу -> Create realm. Указываем имя idp-realm и жмём Create.

Теперь, чтобы sp-realm мог аутентифицировать пользователей через idp-realm, в idp-realm необходимо создать клиент (Client), который будет представлять собой наш sp-realm.
Переходим в Clients -> Create client и заполняем:

Client ID:            sp-realm-broker
Client type:          OpenID Connect
Valid redirect URIs:  http://localhost:8080/realms/sp-realm/broker/idp-realm-oidc/endpoint/*

В поле Valid redirect URIs мы указываем callback-URL того realm-а, который будет потребителем. Формат URL-а: {keycloak-base}/realms/{consumer-realm}/broker/{identity-provider-alias}/endpoint/*. Алиас idp-realm-oidc - это имя, которое мы дадим Identity Provider-у в sp-realm на следующем этапе.

В настройках клиента включаем Client authentication (т.е. клиент будет конфиденциальным), после сохранения переходим на вкладку Credentials и копируем Client secret - он нам скоро понадобится.

Для проверки работы брокеринга создаём пользователя:
Переходим в Users -> Add user:

Username:   testuser
Email:      testuser@example.com
First Name: Test
Last Name:  User

После создания открываем вкладку Credentials -> Set password, задаём пароль и снимаем галку Temporary.

Настройка realm-потребителя (SP realm)

Теперь настроим realm, который будет принимать пользователей из idp-realm.
Аналогично создаём realm с именем sp-realm.

Вот тут начинается самое интересное. Переходим в sp-realm -> Identity providers -> Keycloak OpenID Connect.

На наше счастье, Keycloak умеет автоматически подтягивать конфигурацию через Discovery URL. Заполняем поля:

Alias:           idp-realm-oidc
Discovery URL:   http://localhost:8080/realms/idp-realm/.well-known/openid-configuration
Client ID:       sp-realm-broker
Client Secret:   <сИкрет, скопированный на предыдущем этапе>

После указания Discovery URL и нажатия кнопки обновления Keycloak автоматически заполнит все endpoint-ы и можно радоваться жизни.

Дополнительные настройки, на которые стоит обратить внимание:

Store tokens - если включить, Keycloak будет хранить токены, полученные от IDP. Полезно, если вам нужно обращаться к API от имени пользователя.
Trust emails - если в IDP realm-е email пользователя уже подтверждён, можно включить эту опцию, чтобы не требовать повторного подтверждения.
Sync mode - определяет, как обновлять данные пользователя при повторном логине. Import - только при первом входе, Force - каждый раз.

Чтобы проверить работу брокеринга, создадим простой клиент в sp-realm:

Client ID:           test-app
Client type:         OpenID Connect
Valid redirect URIs:  http://localhost:8080/realms/sp-realm/account/*

Можно также воспользоваться встроенным Account Console, который доступен по адресу http://localhost:8080/realms/sp-realm/account.

Проверяем работу

Открываем в браузере:

http://localhost:8080/realms/sp-realm/account

На странице логина sp-realm появится кнопка IDP realm Login (или то имя, которое вы указали в Display name). Нажимаем на неё - нас перенаправит на страницу логина idp-realm. Вводим креды нашего testuser, и после успешной аутентификации нас вернёт обратно в sp-realm.

При первом входе Keycloak предложит пользователю подтвердить свой профиль (если включена соответствующая опция) и создаст локальную запись в sp-realm.

Маппинг атрибутов и ролей

По умолчанию Keycloak прокидывает базовые атрибуты - username, email, first name, last name. Но что, если нам нужно прокинуть кастомные атрибуты или роли?

Маппинг атрибутов

Переходим в sp-realm -> Identity providers -> idp-realm-oidc -> вкладка Mappers -> Add mapper.

Допустим, в idp-realm у пользователя есть атрибут department. Создаём маппер:

Name:                    Department Mapper
Sync mode override:      Inherit
Mapper type:             Attribute Importer
Claim:                   department
User Attribute Name:     department

Теперь при каждом логине значение клейма department из токена IDP будет записываться в атрибут пользователя в sp-realm. Правда есть нюанс - чтобы кастомный атрибут попадал в токен IDP realm-а, нужно создать Client scope в idp-realm с соответствующим маппером типа User Attribute, и назначить этот scope клиенту sp-realm-broker.

Маппинг ролей

Для ролей создаём маппер типа Claim to Role:

Name:             Role Mapper - Manager
Sync mode:        Inherit
Mapper type:      Claim to Role
Claim:            realm_access.roles
Claim Value:      manager
Role:             manager  (предварительно создайте эту роль в sp-realm)

Теперь пользователи с ролью manager в idp-realm автоматически получат роль manager в sp-realm.

Первый логин и стратегии обнаружения пользователей

Когда пользователь впервые приходит через брокеринг, Keycloak должен решить: создать нового пользователя или привязать к существующему? За это отвечает настройка First login flow в конфигурации Identity Provider-а.

По умолчанию используется flow first broker login, который включает в себя:

Review Profile - пользователю предлагают проверить свои данные.
Create User If Unique - если пользователя с таким email/username нет, он создаётся автоматически.
Confirm Link Existing Account - если пользователь уже существует, предлагается привязка аккаунтов.

Для корпоративного использования часто имеет смысл кастомизировать этот flow. Например, если вы уверены, что email уникален и доверяете IDP, можно убрать шаг Review Profile и автоматически линковать аккаунты без подтверждения.

Для этого:

Переходим в Authentication -> дублируем flow first broker login.
В нашей копии удаляем или отключаем Review Profile.
Настраиваем Automatically set existing user вместо ручного подтверждения.
Справа сверху в выпадающем списке назначаем наш кастомный flow через Bind flow в настройках Identity Provider-а в поле First broker login flow.

На этом всё. Мы рассмотрели полный цикл настройки realm-to-realm Identity Brokering-а в Keycloak: от создания realm-ов и клиентов до маппинга атрибутов и кастомизации первого логина. Механизм мощный и гибкий - позволяет строить федеративную аутентификацию без дублирования пользовательских баз и без сторонних решений.

Если тема Keycloak вам интересна, рекомендую заглянуть в официальную документацию по Server Administration Guide - там описаны продвинутые сценарии, включая брокеринг через SAML и Social Login провайдеры.

Будущее программирования: четыре смелые идеи из 60-х, которые меняют наш цифровой мир сегодня

2026-02-06T13:45:15Z

В 60-е и 70-е годы прошлого века, когда компьютерная наука только зарождалась, в ней не было правил. Не было стандартов, догм или «единственно верных» подходов. Были только чистые листы и смелые умы, готовые пробовать всё, что приходило в голову. Именно в этом творческом хаосе родились концепции, которые до сих пор определяют траекторию развития программирования.

Когда незнание было преимуществом

Современному разработчику, окружённому фреймворками, паттернами и best practices, трудно представить то время. Не было React, не было Kotlin, не было даже объектно-ориентированного программирования в его нынешнем виде. И именно эта свобода от «как надо» породила самые революционные идеи.

Автор выступления «The Future of Programming» Виктор Брет выделяет четыре такие идеи, каждая из которых казалась фантастикой, но сегодня находит своё воплощение в самых передовых технологиях.

Рисовать, а не кодить: прямая манипуляция структурами данных

1963 год. Айван Сазерленд демонстрирует Sketchpad -- систему, где вы рисуете линии световым пером прямо на экране, а компьютер не просто сохраняет картинку, а понимает её как структуру данных. Вы задаёте две точки -- получаете отрезок. Меняете одну точку -- отрезок перерисовывается автоматически.

Тогда это было чудо. Сегодня -- обыденность. Системы автоматизированного проектирования (CAD) вроде AutoCAD, Figma, инструменты для создания интерфейсов позволяют нам работать не с кодом, а с визуальными объектами. Современный дизайнер или инженер абстрагирован от битов и байтов -- он манипулирует понятными сущностями: кнопками, формами, деталями механизмов.

Суть идеи: замена написания инструкций на прямое взаимодействие с данными.

Говорить «что», а не «как»: цели вместо процедур

Традиционное программирование -- это рецепт. Шаг 1, шаг 2, шаг 3... Но что если вместо алгоритма описывать только желаемый результат и ограничения?

В 60-е это была теория. Сегодня -- это искусственный интеллект и машинное обучение. Мы не пишем код для распознавания лиц -- мы показываем нейросети тысячи изображений и говорим: «научись находить лица». GitHub Copilot не исполняет наш алгоритм -- он, анализируя контекст, генерирует код, который решает поставленную задачу.

Программирование эволюционирует от написания инструкций к формулированию задач. Декларативный подход к написанию кода становится все более и более популярным, а prompt engineering становится новой грамотностью разработчика.

Видеть, а не читать: пространственное представление кода

Текст -- линейный и последовательный. Но многие системы -- нелинейны и многомерны. Почему бы не представлять программу не как список строк, а как схему, граф, диаграмму?

Smalltalk в 70-х предложил мир объектов, которые можно «видеть» и с которыми можно «разговаривать». Сегодня LabVIEW даёт инженерам инструмент, где программа собирается из графических блоков, как конструктор. No-code/low-code платформы позволяют создавать бизнес-логику через перетаскивание элементов.

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

Истинный параллелизм

Архитектура фон Неймана, основа всей современной вычислительной техники, по сути, очередь: одна инструкция за другой. Да, мы научились хитрить -- появились многопоточность, superscalar, GPU, распределённые системы… Но это всё ещё параллелизм, построенный на общей памяти и блокировках.

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

За горизонтом: квантовый скачок

К идеям Брета хочется добавить ещё один, принципиально новый рубеж -- квантовые вычисления. Здесь программист должен мыслить не битами (0 или 1), а кубитами, которые могут быть и 0, и 1 одновременно (суперпозиция). Нужно учитывать квантовую запутанность и вероятностную природу результатов.

Это программирование, где разработчик -- ещё и физик. Где отладка -- это искусство, потому что любое измерение меняет состояние системы. Такие компании, как Microsoft, уже создают топологические кубиты для стабильных квантовых систем. Пока это узкоспециализированные инструменты, но они открывают двери в мир, где решаются задачи, невозможные для классических компьютеров.

Самая опасная мысль

Ключевой посыл выступления Виктора Брета удивительно прост и глубок:

Самая опасная мысль для творческого человека -- думать, что ты знаешь, что делаешь.

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

Будущее программирования рождается не там, где следуют стандартам, а там, где их нарушают. Не там, где оптимизируют существующее, а там, где представляют радикально иное. Возможно, следующая революционная идея уже ждёт своего часа -- не в исследовательском центре гиганта технологий, а в голове того, кто ещё не научился «правильно» мыслить. Кто не боится задать наивный вопрос: «А почему бы не сделать иначе?».

Именно этому духу -- духу 60-х, духу творческого незнания -- нам стоит поучиться. Ведь все сегодняшние «стандарты» когда-то были самыми смелыми идеями на свете.

Как психология в дизайне управляет нашим выбором

2026-02-03T16:20:33Z

Мы часто думаем о дизайне как о красоте, стиле или удобстве. Но на более глубоком уровне эффективный дизайн — это тонкая и мощная форма психологического воздействия. Он не просто украшает интерфейс, он направляет наше внимание, формирует восприятие, упрощает сложное и, в конечном счете, подталкивает нас к определенным решениям — от нажатия на кнопку до совершения покупки.

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

Когнитивная психология — дизайн для мозга

Мозг — персонаж неглупый и со своими принципами. Он стремится к экономии энергии, поэтому использует когнитивные шаблоны для быстрой интерпретации входящей информации. Хороший дизайн говорит на языке этих шаблонов.

1. Законы гештальта.

Гештальт (форма на немецком языке) — это группа принципов визуального восприятия, разработанная немецкими психологами в 1920-х годах. Он основан на теории, что «организованное целое воспринимается как большее, чем сумма его частей». Наш мозг автоматически группирует элементы по определенным правилам, чтобы увидеть структуру.

Близость (Proximity): Расположенные близко друг к другу элементы воспринимаются как группа. В дизайне: Это основа компоновки форм. Поле ввода и его подпись должны быть ближе друг к другу, чем к следующему полю. Так вы группируете связанную информацию без лишних линий.
Схожесть (Similarity): Похожие элементы (по цвету, форме, размеру) воспринимаются как группа. В дизайне: Все кнопки «Купить» одного цвета, все ссылки подчеркнуты. Это создает визуальные паттерны и систему.
Замкнутость (Closure): Мозг «дорисовывает» недостающие части, чтобы завершить знакомую фигуру. В дизайне: Логотип WWF (панда из незавершенных линий), использование негативного пространства. Позволяет создавать простые, но запоминающиеся образы.
Общая зона (Common Region): Элементы в одной замкнутой области воспринимаются как группа. В дизайне: Карточки товаров, всплывающие окна (модальные окна), разделы с фоновой заливкой. Мощный инструмент для выделения блоков информации.

На практике: Законы гештальта нужно использовать осознанно. Они — главный инструмент для создания ясной визуальной иерархии без лишнего «визуального шума».

2. Теория цвета.

Цвет — это не эстетика, а коммуникация. Он вызывает мгновенные эмоциональные и физиологические реакции, обходящие сознательный анализ.

Психология и культурный код: Красный сигнализирует об опасности, срочности или страсти (отсюда кнопки «Удалить» и «Купить»). Зеленый ассоциируется с природой, безопасностью и разрешением («Подтвердить»). Синий внушает доверие и стабильность (почему его любят банки и соцсети). Но важно: Культурный контекст меняет значение (белый — цвет свадьбы на Западе и траура в некоторых азиатских культурах).
Функциональность и доступность: Контраст текста и фона критически важен для читаемости и соответствия стандартам доступности (WCAG). Цвет не должен быть единственным способом передачи информации (например, «обязательные поля отмечены красным» — нужно и символом *).

На практике: Выбирайте цветовую палитру, исходя из задачи бренда (доверие, возбуждение, спокойствие) и функциональных требований, а не личных предпочтений. Тестируйте контраст и учитывайте цветовую слепоту.

3. Ментальные модели: встреча ожиданий и реальности

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

Конфликт моделей: Когда дизайн продукта (концептуальная модель) противоречит ожиданиям пользователя (ментальной модели), возникает когнитивная нагрузка, разочарование и ошибки. Пример: нестандартная иконка «Сохранить», которую невозможно узнать.
Использование знакомых паттернов: Следование общепринятым UX-паттернам (навигация, формы, взаимодействия) — это уважение к ментальным моделям пользователя. Это снижает порог входа и делает интерфейс предсказуемым.

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

Поведенческая экономика — дизайн для иррационального «Я»

Нобелевский лауреат Даниэль Канеман доказал: человек — не рациональный «хомо экономикус». Нами управляют систематические ошибки мышления (когнитивные искажения). Дизайн, который их учитывает, становится невероятно убедительным.

Принципы «подталкивания» (Nudges) в дизайне

Nudge («подталкивание») — это мягкое изменение среды выбора, которое предсказуемо направляет человека к лучшему решению, не ограничивая его свободы.

Эффект владения (Endowment Effect) и Статус-кво: Мы переоцениваем то, что уже имеем, и предпочитаем оставлять всё как есть.
- В дизайне: Бесплатный пробный период. После того как пользователь «присвоил» сервис на 14 дней, ему психологически сложнее от него отказаться. Настройки по умолчанию (например, опция «зеленого» тарифа) часто остаются неизменными.
Социальное доказательство (Social Proof): Мы смотрим на действия других, чтобы определить собственное поведение.
- В дизайне: Отзывы, количество скачиваний, фразы «Купили 100 человек за последний час», «Ваши друзья используют эту функцию». Это снижает неопределенность и риски.
Дефицит и срочность (Scarcity & Urgency): Ограниченное количество или время повышает воспринимаемую ценность.
- В дизайне: «Осталось 2 билета по этой цене», «Акция закончится через 2 часа 15 минут», «Ваша корзина забудется через 10 минут». Таймеры создают ощущение FOMO (страх упустить выгоду).
Якорение (Anchoring): Первая полученная информация (якорь) сильно влияет на последующие оценки.
- В дизайне: Ценовая стратегия. Показав сначала высокую цену «$999», цена «$599» кажется выгодной. В формах подписки часто самый выгодный тариф (якорь) находится в центре.
Эффект простого воздействия (Mere Exposure Effect): Чем чаще мы сталкиваемся с чем-либо, тем больше это нам нравится.
- В дизайне: Последовательный, повторяющийся брендинг (цвета, шрифты, тональность) на всех точках касания с пользователем повышает узнаваемость и лояльность.

Синтез — Как это работает вместе в реальном интерфейсе?

Рассмотрим на примере страницы оформления заказа в интернет-магазине:

Когнитивная психология: Законы близости и общей зоны группируют поля доставки и оплаты в четкие блоки. Контрастный цвет для кнопки «Оформить заказ» выделяет её на фоне остальных элементов (схожесть). Стандартный процесс «Корзина > Оформление > Подтверждение» соответствует ментальной модели покупки.
Поведенческая экономика: На этапе корзины работает социальное доказательство («Люди, купившие это, также берут...»). На странице оплаты может быть применен дефицит («Бесплатная доставка действует еще 15 мин!»). Тариф «Премиум» служит якорем, делая тариф «Стандарт» более привлекательным. А опция «Сохранить данные карты для будущих покупок» уже включена по умолчанию, используя нашу любовь к статус-кво.

Этика: Великая сила — великая ответственность

Знание психологии — это обоюдоострый меч. Те же принципы, что помогают пользователю сделать здоровый выбор (подписаться на пенсионные отчисления по умолчанию — nudge), могут быть использованы для создания «темных паттернов».

Принуждение: Сложно найти кнопку «Отписаться от рассылки».
Трюк с подтверждением: Дорогой товар «случайно» добавляется в корзину.
Скрытые затраты: Окончательная цена показывается только в конце долгого процесса.

Принуждение: Сложно найти кнопку «Отписаться от рассылки».
Трюк с подтверждением: Дорогой товар «случайно» добавляется в корзину.
Скрытые затраты: Окончательная цена показывается только в конце долгого процесса.

Этичный дизайнер использует психологию для:

Упрощения, а не усложнения.
Просвещения, а не манипуляции.
Расширения возможностей, а не ограничения выбора.
Создания долгосрочного доверия, а не сиюминутной выгоды.

Заключение

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

Итоговый совет: Внедряйте эти принципы последовательно. Начните с гештальта для ясности, добавьте цвет для эмоций, проверьте ментальные модели через тесты, а затем осторожно применяйте «подталкивания» для достижения бизнес- и пользовательских целей. Всегда спрашивайте себя: «Кому это решение приносит пользу в долгосрочной перспективе?» Ответ должен быть: «В первую очередь, пользователю».

Go вместе изучать Go. Часть 5

2026-02-01T13:25:41Z

Введение

Интерфейсы — один из элегантных инструментов Go, который позволяет писать гибкий и масштабируемый код. В отличие от многих других языков программирования, Go использует имплицитную (неявную) реализацию интерфейсов, что делает их особенно удобными и гибкими.

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

Что такое интерфейсы?

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

Для начала давайте рассмотрим простой пример:

type I interface {
	M()
}

Здесь мы определили интерфейс I с одним методом M(). Любой тип, который имеет метод M() с такой же сигнатурой, будет реализовывать этот интерфейс — причём совершенно автоматически, без каких-либо явных деклараций.

Неявная реализация интерфейсов

Одна из самых уникальных черт Go — интерфейсы реализуются неявно. Нет никакого ключевого слова implements или других явных объявлений. Если тип имеет все методы, определённые в интерфейсе, он автоматически реализует этот интерфейс.

Давайте посмотрим на конкретный пример:

package main

import "fmt"

type I interface {
	M()
}

type T struct {
	S string
}

// Метод M() означает, что тип T реализует интерфейс I
// Но мы не должны явно заявлять об этом
func (t T) M() {
	fmt.Println(t.S)
}

func main() {
	var i I = T{"hello"}
	i.M()
}

Результат: 

hello

Что здесь происходит? Мы объявили переменную i с типом интерфейса I, а затем присвоили ей значение T{"hello"}. Это работает потому, что структура T имеет метод M(), который отвечает требованиям интерфейса I. Go автоматически определил, что тип T реализует интерфейс I, и позволил выполнить это присваивание.

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

Значения интерфейсов

Чтобы по-настоящему понять, как работают интерфейсы в Go, нужно понять, что происходит под капотом. Значение интерфейса можно представить себе как кортеж из двух элементов:

(значение, конкретный_тип)

Интерфейс хранит значение конкретного типа. Когда вы вызываете метод на значении интерфейса, Go вызывает соответствующий метод этого конкретного типа.

Рассмотрим практический пример:

package main

import (
	"fmt"
	"math"
)

type I interface {
	M()
}

type T struct {
	S string
}

func (t *T) M() {
	fmt.Println(t.S)
}

type F float64

func (f F) M() {
	fmt.Println(f)
}

func main() {
	var i I

	i = &T{"Hello"}
	describe(i)
	i.M()

	i = F(math.Pi)
	describe(i)
	i.M()
}

func describe(i I) {
	fmt.Printf("(%v, %T)\n", i, i)
}

Результат: 

(&{Hello}, *main.T)

Hello

(3.141592653589793, main.F)

3.141592653589793

Функция describe() показывает нам внутреннее состояние интерфейса: значение и его конкретный тип. Обратите внимание, что мы можем присвоить одной и той же переменной интерфейса значения разных типов. В первом случае это указатель на T, во втором — значение типа F. Go гибко обрабатывает оба случая.

Значения интерфейсов с nil-значениями

Интересный аспект Go: интерфейс может содержать nil-значение конкретного типа, но сам интерфейс при этом остаётся не nil. Методы в этом случае будут вызваны с nil-приёмником.

package main

import "fmt"

type I interface {
	M()
}

type T struct {
	S string
}

func (t *T) M() {
	if t == nil {
		fmt.Println("<nil>")
		return
	}
	fmt.Println(t.S)
}

func main() {
	var i I

	var t *T
	i = t
	describe(i)
	i.M()

	i = &T{"hello"}
	describe(i)
	i.M()
}

func describe(i I) {
	fmt.Printf("(%v, %T)\n", i, i)
}

Результат: 

(<nil>, *main.T)

<nil>

(&{hello}, *main.T)

hello

В Go это нормальная практика — методы часто пишут так, чтобы они корректно работали с nil-приёмниками. Это предохраняет от неожиданных паник.

Nil-интерфейсы

Совсем другое дело — интерфейс, который не содержит ни значения, ни конкретного типа. Это настоящий nil-интерфейс:

package main

import "fmt"

type I interface {
	M()
}

func main() {
	var i I
	describe(i)
	i.M()
}

func describe(i I) {
	fmt.Printf("(%v, %T)\n", i, i)
}

Результат: 

(<nil>, <nil>)

panic: runtime error: invalid memory address or nil pointer dereference

Когда вы вызываете метод на nil-интерфейсе, Go не знает, какой конкретный метод вызвать, потому что нет информации о типе. Результат — ошибка выполнения (panic). Всегда проверяйте интерфейсы на nil перед использованием!

Пустой интерфейс

Интерфейс, который не определяет ни одного метода, называется пустым интерфейсом:

interface{}

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

Классический пример — функция fmt.Print(), которая может принимать любое количество аргументов любых типов:

package main

import "fmt"

func main() {
	var i interface{}
	describe(i)

	i = 42
	describe(i)

	i = "hello"
	describe(i)
}

func describe(i interface{}) {
	fmt.Printf("(%v, %T)\n", i, i)
}

Результат: 

(<nil>, <nil>)

(42, int)

(hello, string)

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

Утверждения типов (Type Assertions)

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

Простая форма утверждения типа:

t := i.(T)

Это утверждает, что интерфейсное значение i содержит конкретный тип T, и присваивает базовое значение переменной t. Если i на самом деле не содержит T, программа перейдёт в состояние паники.

Более безопасный вариант — использовать двойное возвращаемое значение:

t, ok := i.(T)

Если i содержит T, то t получит базовое значение и ok будет true. Если нет, ok будет false, t получит нулевое значение типа T, и паника не произойдёт. Это похоже на чтение из map в Go.

Давайте посмотрим практический пример:

package main

import "fmt"

func main() {
	var i interface{} = "hello"

	// Опасный вариант
	s := i.(string)
	fmt.Println(s)

	// Безопасный вариант с проверкой
	s, ok := i.(string)
	fmt.Println(s, ok)

	// Проверяем тип, который не совпадает
	f, ok := i.(float64)
	fmt.Println(f, ok)

	// Это вызовет панику!
	f = i.(float64)
	fmt.Println(f)
}

Результат: 

hello

hello true

0 false

panic: interface conversion: interface {} is string, not float64

Совет: Всегда используйте безопасный вариант с двойным возвращаемым значением (t, ok := i.(T)), если вы не уверены в типе.

Переключение по типам (Type Switches)

Когда вам нужно проверить несколько типов одновременно, переключение по типам — это идеальный инструмент. Синтаксис выглядит почти как обычный switch, но вместо значений мы сравниваем типы:

switch v := i.(type) {
case T:
	// здесь v имеет тип T
case S:
	// здесь v имеет тип S
default:
	// нет совпадений; здесь v имеет тот же тип, что и i
}

Рассмотрим практический пример:

package main

import "fmt"

func do(i interface{}) {
	switch v := i.(type) {
	case int:
		fmt.Printf("Twice %v is %v\n", v, v*2)
	case string:
		fmt.Printf("%q is %v bytes long\n", v, len(v))
	default:
		fmt.Printf("I don't know about type %T!\n", v)
	}
}

func main() {
	do(21)
	do("hello")
	do(true)
}

Результат: 

Twice 21 is 42

"hello" is 5 bytes long

I don't know about type bool!

Type switch автоматически преобразует значение в корректный тип в каждом case. Это намного удобнее, чем писать цепочку утверждений типов.

Интерфейс Stringer

Одна из самых распространённых интерфейсов в стандартной библиотеке — это Stringer, определённый в пакете fmt:

type Stringer interface {
	String() string
}

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

Давайте создадим полезный пример:

package main

import "fmt"

type Person struct {
	Name string
	Age  int
}

func (p Person) String() string {
	return fmt.Sprintf("%v (%v years)", p.Name, p.Age)
}

func main() {
	a := Person{"Arthur Dent", 42}
	z := Person{"Zaphod Beeblebrox", 9001}
	fmt.Println(a, z)
}

Результат: 

Arthur Dent (42 years) Zaphod Beeblebrox (9001 years)

Без реализации String() вывод был бы просто {Arthur Dent 42} и {Zaphod Beeblebrox 9001}. Метод String() позволяет полностью контролировать, как выглядит ваш тип при печати.

Обработка ошибок с интерфейсами

В Go ошибки представлены встроенным интерфейсом:

type error interface {
	Error() string
}

Функции часто возвращают значение типа error. Нулевое значение error означает успех; ненулевое значение означает ошибку:

i, err := strconv.Atoi("42")
if err != nil {
	fmt.Printf("couldn't convert number: %v\n", err)
	return
}
fmt.Println("Converted integer:", i)

Давайте создадим собственный тип ошибки:

package main

import (
	"fmt"
	"time"
)

type MyError struct {
	When time.Time
	What string
}

func (e *MyError) Error() string {
	return fmt.Sprintf("at %v, %s", e.When, e.What)
}

func run() error {
	return &MyError{
		time.Now(),
		"it didn't work",
	}
}

func main() {
	if err := run(); err != nil {
		fmt.Println(err)
	}
}

Результат: 

at 2009-11-10 23:00:00 +0000 UTC m=+0.000000001, it didn't work

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

Интерфейс Reader

Пакет io определяет интерфейс io.Reader, который представляет один конец потока данных:

func (T) Read(b []byte) (n int, err error)

Метод Read заполняет заданный байтовый срез данными и возвращает количество заполненных байтов и значение ошибки. Он возвращает io.EOF когда поток заканчивается.

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

package main

import (
	"fmt"
	"io"
	"strings"
)

func main() {
	r := strings.NewReader("Hello, Reader!")

	b := make([]byte, 8)
	for {
		n, err := r.Read(b)
		fmt.Printf("n = %v err = %v b = %v\n", n, err, b)
		fmt.Printf("b[:n] = %q\n", b[:n])
		if err == io.EOF {
			break
		}
	}
}

Результат: 

n = 8 err = <nil> b = [72 101 108 108 111 44 32 82]

b[:n] = "Hello, R"

n = 6 err = <nil> b = [101 97 100 101 114 33 32 82]

b[:n] = "eader!"

n = 0 err = EOF b = [101 97 100 101 114 33 32 82]

b[:n] = ""

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

Бонус: Различие между значениями и указателями

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

package main

import (
	"fmt"
	"math"
)

type Abser interface {
	Abs() float64
}

func main() {
	var a Abser
	f := MyFloat(-math.Sqrt2)
	v := Vertex{3, 4}

	a = f       // MyFloat реализует Abser (метод на значении)
	a = &v      // *Vertex реализует Abser (метод на указателе)
	
	// ОШИБКА: v имеет тип Vertex (не *Vertex) и НЕ реализует Abser
	// Метод Abs определён только на *Vertex
	a = v       // Это вызовет ошибку компиляции!

	fmt.Println(a.Abs())
}

type MyFloat float64

func (f MyFloat) Abs() float64 {
	if f < 0 {
		return float64(-f)
	}
	return float64(f)
}

type Vertex struct {
	X, Y float64
}

// Заметьте: приёмник (receiver) — это указатель *Vertex
func (v *Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Результат: 

cannot use v (variable of struct type Vertex) as Abser value in assignment:

Vertex does not implement Abser (method Abs has pointer receiver)

Важное правило: Если метод определён на указателе *T, то интерфейс можно реализовать только через указатель. Если метод определён на значении T, то интерфейс можно реализовать как через значение, так и через указатель (потому что Go автоматически дереферирует указатели при необходимости).

Заключение

Интерфейсы в Go — это мощный инструмент для написания гибкого и модульного кода.

В этой статье мы научились:

Базовым понятиям интерфейсов: как определять и использовать набор методов без явных объявлений реализации

Неявной реализации интерфейсов в Go, которая автоматически определяет, реализует ли тип данные методы

Структуре интерфейсов: как они хранят значение и его конкретный тип внутри своей внутренней реализации

Доступу к базовым типам через утверждения типов и как безопасно работать с ними

Использованию пустого интерфейса для работы со значениями неизвестного типа

Практическому применению интерфейсов в стандартной библиотеке Go и как они помогают писать чистый, гибкий код

Критической разнице между методами на значениях и указателях, как она влияет на реализацию интерфейсов

Методам работы с ошибками, потоками данных, и настройке форматирования выводов через стандартные интерфейсы

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

Swagger: как починить неработающие разнородные multipart-запросы

2026-01-30T16:45:06Z

Swagger давно уже можно назвать своего рода стандартом среди инструментов для документирования и тестирования RESTful API. Вместо ручного написания curl’ов для проверки созданных эндпоинтов всегда удобнее воспользоваться веб-интерфейсом Swagger UI. Тем не менее в каждом решении бывают свои недоработки, баги и проблемы. Сегодня рассмотрим одну из проблем, с которой мы столкнулись при использовании Swagger в процессе разработки сервиса на базе фреймворка Spring. Проблема некритичная, но порой раздражающая и тормозящая рабочий процесс, и связана она с особенностью обработки сложных multipart запросов с разнородными компонентами в теле. Перед тем как продолжить, сразу обозначим, что нами используется актуальная спецификация OpenAPI 3.0 (в более ранних версиях Swagger с поддержкой multipart-запросов все, кажется, совсем плохо).

Итак, рассмотрим классический пример. Мы пишем Spring-приложение на Kotlin, написан простой контроллер для обработки входящих запросов, в котором есть эндпоинт, принимающий POST-запросы, содержащие в себе какой-либо файл и дополнительную метаинформацию о файле в формате JSON. Заголовок Content-Type у такого запроса будет multipart/form-data;, при этом запрос у нас сложный, гетерогенный, в котором разные части тела запроса представлены разными типами контента. Упрощенно контроллер будет выглядеть примерно так:

import org.springframework.http.HttpStatus
import org.springframework.http.MediaType
import org.springframework.http.ResponseEntity
import org.springframework.web.bind.annotation.*
import org.springframework.web.multipart.MultipartFile

@RestController
@RequestMapping("/files")
class FilesController(
    private val fileService: FileService,
) {

    @PostMapping(consumes = [MediaType.MULTIPART_FORM_DATA_VALUE])
    fun processFile(
        @RequestPart("info") metaInfo: FileInfoDto,
        @RequestPart("file") file: MultipartFile,
    ): ResponseEntity<ResultDto> {
        val executionResult = fileService.processNewFile(metaInfo, file.inputStream)
        return ResponseEntity.status(HttpStatus.CREATED).body(executionResult)
    }

}

Содержимое конкретных DTO и сервисов нас сейчас не интересует, просто представим, что все написано без ошибок и соответствует требованиям к системе. С точки зрения программного кода ошибок нет, сервис функционирует и успешно обрабатывает запросы. Но только если они посылаются не из Swagger UI. В веб-интерфейсе отправим примерно такой запрос, добавив произвольный файл

В ответ мы с большой долей вероятности получим нечто вроде:

org.springframework.web.HttpMediaTypeNotSupportedException: Content-Type 'application/octet-stream' is not supported

Это означает, что Spring "не понял", что за тип данных нам отправляется, посчитав пришедшее на сервер недифференцируемым потоком бинарных данных. Spring не может сопоставить части запроса с описанными нами RequestPart, понять, где мы послали JSON, а где файл, из-за чего все разваливается. Но проблема тут не на стороне приложения, а именно в отсутствии нужной конфигурации для Swagger. Мы это поймем, если в веб-интерфейсе посмотрим curl, который swagger сгенерировал для данного запроса:

curl -X 'POST' \
  'http://localhost:8080/o/api/files' \
  -H 'accept: */*' \
  -H 'Content-Type: multipart/form-data' \
  -F 'info={"authorId": 123, "description": "something was created"}' \
  -F 'file=@img.png;type=image/png'

На первый взгляд может показаться, что все в порядке, но проблема в том, что в строке с info после JSON'а нет куска ;type=application/json

На уровне своей архитектуры OpenAPI 3.0 умеет работать с такими запросами, но нужно немного потрудиться над конфигурацией, чтобы Swagger понял, какая часть запроса каким типом представлена. Файлы Swagger способен распознать и добавить им тип по умолчанию, с JSON строкой же такого не происходит, в схеме нет нужной инструкции, а по умолчанию все строки в multipart-запросах Swagger считает типом text/plain. Таким образом, если Spring понимает, что в RequestPart ожидается JSON и способен его распарсить, то Swagger по умолчанию нет, он до последнего будет считать JSON произвольной строкой и отказываться добавлять в curl нужный тип.

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

import org.springframework.http.HttpStatus
import org.springframework.http.MediaType
import org.springframework.http.ResponseEntity
import org.springframework.web.bind.annotation.*
import org.springframework.web.multipart.MultipartFile

import io.swagger.v3.oas.annotations.Operation
import io.swagger.v3.oas.annotations.tags.Tag
import io.swagger.v3.oas.annotations.media.Content
import io.swagger.v3.oas.annotations.media.Encoding

@RestController
@Tag(name="Контроллер с правильной конфигурацией swagger")
@RequestMapping("/files")
class FilesController(
    private val fileService: FileService,
) {

   @Operation(
        summary = "Демонстрационный эндпоинт",
        requestBody = io.swagger.v3.oas.annotations.parameters.RequestBody(
            content = [
                Content(
                    mediaType = MediaType.MULTIPART_FORM_DATA_VALUE,
                    encoding = [
                        Encoding(name = "info", contentType = "application/json")
                    ]
                )
            ]
        )
    )
    @PostMapping(consumes = [MediaType.MULTIPART_FORM_DATA_VALUE])
    fun processFile(
        @RequestPart("info") metaInfo: FileInfoDto,
        @RequestPart("file") file: MultipartFile,
    ): ResponseEntity<ResultDto> {
        val executionResult = fileService.processNewFile(metaInfo, file.inputStream)
        return ResponseEntity.status(HttpStatus.CREATED).body(executionResult)
    }

}

После перезапуска приложения все должно заработать, запрос, отправленный из Swagger, обработается успешно, а curl станет генерироваться корректно:

curl -X 'POST' \
  'http://localhost:8080/o/api/files' \
  -H 'accept: */*' \
  -H 'Content-Type: multipart/form-data' \
  -F 'info={
  "authorId": 123,
  "description": "something was created"
};type=application/json' \
  -F 'file=@img.png;type=image/png'

Стили менеджмента: классификация по PAEI

2026-01-21T10:14:43Z

Введение

В своей практике на работе, если вы захотите проявить инициативу, или просто будете достаточно ответственны, то обязательно встретитесь с необходимостью руководить другими людьми. Cегодня мы поговорим не об управляемых, а об управляющих. Какие бывают стили менеджмента, и как понять, кем вы сами являетесь как руководитель? Для этого используем классификацию PAEI.

Примечание: Эта статья является выдержкой из глав книги "Идеальный руководитель" Ицхака Адизеса. Большинство идеи и фраз заимствованы из книги или являются прямыми цитатами.

Что такое "менеджмент"? Задачи менеджмента

Кто мудр? Тот, кто учится у всех и каждого.
Кто силен? Тот, кто обуздал свои страсти.
Кто богат? Тот, кто доволен судьбой.
Кому это дано?
Никому.
Бенджамин Франклин

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

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

Несколько пунктов, которые характеризуют менеджмент как явление:

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

Код (PAEI)

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

"Около 40 лет назад я обнаружил, что для обеспечения результативности и эффективности организации ... необходимо выполнять четыре функции. Каждая из них необходима, а вместе они достаточны для хорошего управления. Слово 'необходимо' подразумевает, что если хотя бы одна из функций не выполняется, имеет место определенная модель неправильного менеджмента."

Первая функция, которую должен выполнять менеджмент в любой организации - это (P), или производство результатов, обеспечивающее результативность организации в краткосрочном аспекте. Почему люди обращаются к вашей компании? Для чего вы им нужны? Какие услуги им требуются?
Вторая функция, (А), или администрирование, нужна, чтобы следить за порядком в организационных процессах: компания должна делать правильные вещи в правильной последовательности с правильной интенсивностью.Задача администратора (А) — обеспечить эффективность в краткосрочном аспекте.
Далее нам понадобится провидец. Он определяет направление, которого должна придерживаться организация. Это функция предпринимателя (Е), который сочетает в себе творческий подход и готовность идти на риск. Если организация успешно справляется с выполнением этой функции, ее услуги и/или продукты будут пользоваться спросом у будущих клиентов.
И наконец, менеджмент должен обеспечить интеграцию (I), то есть создать такую атмосферу и систему ценностей, которые будут стимулировать людей действовать сообща и не дадут никому стать незаменимым, что обеспечит жизнеспособность и эффективность организации в долгосрочной перспективе.

ВХОД	ПРЕОБРАЗОВАНИЕ	ВЫХОД
Функции	Для превращения организации в …	Характеризующуюся	На временном горизонте
(P) Производить результаты	Функциональную	Результативностью	В краткосрочном аспекте
(A) Администрировать	Систематизированную	Эффективностью	В краткосрочном аспекте
(E) Быть предпринимателем	Готовую к упреждающим действиям	Результативностью	В долгосрочной перспективе
(I)Интегрировать	Единый организм	Эффективностью	В долгосрочной перспективе

(P): Что нужно сделать?
(A): Как это нужно сделать?
(E): Когда/зачем это нужно сделать?
(I): Кто это должен сделать?

Стили менеджмента

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

Производитель (Paei) - "Давайте посмотрим, что представляет собой стиль менеджера, который успешно выполняет (Р)-Функцию, обеспечивая создание продукта, необ-ходимого для удовлетворения потребностей клиентов, то есть производство желаемого результата, и удовлетворительно справляется с администриро-ванием, предпринимательством и интеграцией. Такого менеджера, обо-значенного кодом (Раеі), я называю производителем, или менеджером (Р)-типа."
Администратор (pAei) - Такой человек имеет природную склонность замечать детали, в особенности касающиеся внедрения. Он методичен и любит, чтобы рабочая среда была продумана ихорошо организована него линейный способ машения. Когда у вас возникает идея, связанная с бизнесом, особенно если это безумная идея или если вы опасаетесь, что она окажется безумной, - вы отправляетесь к подобному менеджеру, чтобы он охладил ваш энтузиазм. Он сумеет оценить суть дела. Он задаст вопросы, которые не приходили вам в голову. Он увидит все подводные камни, которые вы не учли. Дайте ему прочесть бизнес-план, и он порвет его в клочья. И вы будете ему благодарны! Предвидя проблемы, можно решить их, прежде чем они переросли в кризис, или отказаться от несостоятельного плана и таким образом снизить затраты и убытки в долгосрочной перспективе.
Генератор идей (paEi) - Менеджер такого типа — не совсем предприниматель. Чтобы стать предпринимателем, который создает организации и обеспечивает их развитие, нужно одновременно иметь развитые (Р)-навыки. Ориентации только на (E) недостаточно.
Того, кто по большей части нацелен на (E) и удовлетворительно, но не блестяще справляется с (Р)-функцией, я теперь называю Генератором идей. У этого менеджера масса предложений — одни удачные, другие не слишком. Он выдает их в изобилии, иногда это настоящий поток идей. Он подобен школьнику, который тянет руку, не дослушав вопрос учителя. Именно он больше всех говорит на собраниях. Какое бы решение ни было предложено, у него есть другой вариант.
Предприниматель (paEi) - Чтобы быть предпринимателем, менеджеру необходимо обладать двумя основными качествами. Прежде всего, он должен быть творческой лично-стью, способной намечать новые направления и изобретать стратегии, которые позволяют организации адаптироваться к постоянно меняющимся условиям окружающей обстановки. Чтобы определять стратегию реакции на изменения, он должен чувствовать сильные и слабые стороны своей организации и обладать воображением и смелостью [8].
И все же быть творческой личностью недостаточно. Встречаются чрезвычайно творческие люди, которых нельзя назвать предпринимателями.
Интегратор (paeI) - Востоящая интеграция, или интерация, направленная вверх, это способность объединять людей, имеющих более высокий статус, полномочия, должности и т.д. Горизонтальная интеграция — это способность создавать сплоченную группу из равных себе. Нисходящая интеграция, или интеграция, направленная вниз, позволяет стать лидером, сплачивая под-чиненных. Успешный горизонтальный интегратор может с трудом справляться с нисходящей интеграцией, имея склонность слишком надменно держаться с подчиненными. На самом деле редко кто бывает непревзойденным интегратором по всем трем направлениям. Интегратор тонко чувствует других людей, сопереживает им и способен к дедуктивному мышлению — он понимает, чем отличается сказанное от того, что человеку хочется сказать. У него самого есть ряд личностных про-блем, что позволяет ему откликаться на чаяния, проблемы и нужды других людей, ставя их выше собственных интересов.

Подведение итогов

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

Организация достигает этих целей, если успешно выполняются четыре
Функции: производство во имя удовлетворения ожидаемых потребностей клиентов, администрирование, предпринимательство и интеграция — или (PAEI). Иными словами, организация должна быть нацелена на результат (Р), быть гибкой и хорошо адаптироваться к изменениям (Е), причем такая гибкость должна контролироваться и давать предсказуемые результаты (А). И наконец, система должна быть самонастраивающейся (I) и не требовать корректирующих воздействий извне.

Следовательно, задача менеджмента — выполнять эти четыре функции, поскольку они не реализуются сами по себе. «Управлять» — значит выполнять все эти функции или любую из них, независимо от должности индивида или его места в иерархии — и даже независимо от того, числится ли он в штате. Наверное, теперь, когда мы определили, что такое «менеджмент», и знаем, что ищем, мы сумеем найти идеального менеджера?
Не тут-то было. Но зато теперь нам будет проще понять, почему идеальных менеджеров не бывает и не может быть."

Задача по динамическому программированию: «Карьерный путь в Tune-IT»

2026-01-14T15:06:26Z

Задача по динамическому программированию: «Карьерный путь в Tune-IT»

Условия задачи

В компании Tune-IT программист строит карьеру, зарабатывая славу, деньги и влияние в зависимости от выбранного пути. Слава, деньги и влияние дают A, B и C очков репутации и D, E, F очков выгорания соответственно. Программист хоть и мечтает получить как можно больше репутации, но если он выгорит, то больше не сможет писать чистый, легко-масштабируемый код, способный менять мир к лучшему. У каждого программиста есть свой предельный уровень выгорания H, после которого он начинает думать об увольнении. Также дана карта возможностей M x N, показывающая, где можно получить славу, деньги и влияние, а где – ничего. На карте возможности отмечены буквами “С”, “Д”, “В” и “Н“.

Задача

Необходимо найти такой карьерный путь (на карте возможностей), который обеспечит программисту в Tune-IT максимальную репутацию, и при этом не даст ему выгореть. Двигаться по карте возможностей можно на клетку вверх, вниз, вправо и влево начиная с верхней левой клетки. В качестве результата необходимо вывести максимальное число очков репутации. В случае, когда любой выбор карьерного пути приводит к выгоранию, выведите -1.

Входные данные

H – предельный уровень выгорания
M, N – размер матрицы возможностей
A, B и C – очки репутации, которые дает слава, деньги и влияние соответственно
D, E и F – очки выгорания, которые дает слава, деньги и влияние соответственно
availability – матрица возможностей M x N, заполненная буквами “С”, “Д”, “В” и “Н“

Выходные данные

Максимальное число очков репутации или -1, если любой выбор карьерного пути приводит к выгоранию

Примеры

Ввод:

1 1

1 2 3

Вывод:

Если без воды и кратко – нужно найти путь по сетке M×N с движениями в 4 направления, который максимизирует суммарную репутацию при ограничении на суммарный уровень выгорания (не превышать H). Каждая клетка даёт либо один из трёх типов вознаграждений (репутация + выгорание) либо ничего. Если все пути приводят к выгоранию (> H), ответ – -1.

Это задача оптимизации с ограничением ресурса (burnout) на графе-решётке. Подход динамического программирования на клетках с учётом расходуемого ресурса (выгорания) даёт решение за O(M·N·(H+1)). Однако можно сделать O(M·N) по состояниям, если воспользоваться тем, что значения вознаграждений и издержек фиксированы и не зависят от скорости: здесь разумное и простое решение – BFS/динамика в пространстве (i, j, b), где b – текущее выгорание (0..H). Это динамика на взвешенном графе с неотрицательными прибавками: для каждого состояния храним максимальную репутацию, достижимую при данном выгорании. Переходы увеличивают выгорание на D/E/F (или 0) и репутацию на A/B/C (или 0) при заходе в соседнюю клетку.

Ключевые шаги решения

Кодируем для каждой буквы репутацию и выгорание: С→(A,D), Д→(B,E), В→(C,F), Н→(0,0).
Состояние – (i,j,b) где b ∈ [0..H] – текущая клетка и накопленное выгорание. Храним best[i][j][b] = максимальная репутация при достижении этого состояния.
Инициализация: стартовое состояние – верхняя левая клетка (0,0). Если её burn > H, ответ −1 (нельзя даже стартовать). Иначе стартовое best[0][0][burn0] = reward0. При старте мы посещаем (0,0) и применяем её эффекты.
По очереди (BFS/deque) релаксируем переходы в 4 направления: для соседа nb = b + burn(neigh); если nb ≤ H, обновляем best[ni][nj][nb] = max(...).
Ответ – максимум best[i][j][b] по всем i,j,b. Если ни одно состояние недостижимо – выводим - 1.

Код алгоритма на kotlin:

import java.io.BufferedReader

import java.io.InputStreamReader

import java.util.ArrayDeque

import kotlin.math.max

data class S(val i:Int, val j:Int, val b:Int)
 

fun main(){

    val br = BufferedReader(InputStreamReader(System.`in`))

    val toks = ArrayDeque<String>()

    fun next(): String {

        while(toks.isEmpty()){

            val line = br.readLine() ?: return ""

            line.trim().split(Regex("\\s+")).filter{it.isNotEmpty()}.forEach{toks.addLast(it)}

        }

        return toks.removeFirst()

    }
 

    val H = next().toInt()

    val M = next().toInt(); val N = next().toInt()

    val A = next().toInt(); val B = next().toInt(); val C = next().toInt()

    val D = next().toInt(); val E = next().toInt(); val F = next().toInt()
 

    val g = Array(M){ CharArray(N) }

    for(i in 0 until M){

        var s = next()

        if(s.length < N){

            val sb = StringBuilder(s)

            while(sb.length < N) sb.append(next())

            s = sb.toString()

        }

        for(j in 0 until N) g[i][j] = s[j]

    }
 

    fun reward(c:Char) = when(c){ 'С','C'->A; 'Д'->B; 'В','V'->C; else->0 }

    fun burn(c:Char) = when(c){ 'С','C'->D; 'Д'->E; 'В','V'->F; else->0 }
 

    val NEG = Int.MIN_VALUE/4

    val best = Array(M){ Array(N){ IntArray(H+1){ NEG } } }

    val q = ArrayDeque<S>()
 

    val sb0 = burn(g[0][0])

    if(sb0 > H){ println(-1); return }

    best[0][0][sb0] = reward(g[0][0])

    q.add(S(0,0,sb0))
 

    val di = intArrayOf(-1,1,0,0); val dj = intArrayOf(0,0,-1,1)

    while(q.isNotEmpty()){

        val cur = q.removeFirst()

        val curV = best[cur.i][cur.j][cur.b]

        for(d in 0..3){

            val ni = cur.i + di[d]; val nj = cur.j + dj[d]

            if(ni !in 0 until M || nj !in 0 until N) continue

            val nb = cur.b + burn(g[ni][nj])

            if(nb > H) continue

            val nv = curV + reward(g[ni][nj])

            if(nv > best[ni][nj][nb]){

                best[ni][nj][nb] = nv

                q.add(S(ni,nj,nb))

            }

        }

    }
 

    var ans = NEG

    for(i in 0 until M) for(j in 0 until N) for(b in 0..H) ans = max(ans, best[i][j][b])

    println(if(ans <= NEG/2) -1 else ans)

}

Go вместе изучать Go. Часть 4

2026-01-07T21:09:43Z

Введение

Одной из особенностей в Go, которая часто озадачивает разработчиков из других языков программирования, — является отсутствие классов.

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

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

Что такое метод в Go?

Метод в Go — это функция со специальным аргументом-получателем (receiver). Получатель появляется в собственном списке аргументов между ключевым словом func и названием метода.

Вот простой пример:

package main

import (
	"fmt"
	"math"
)

type Vertex struct {
	X, Y float64
}

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
	v := Vertex{3, 4}
	fmt.Println(v.Abs())
}

// Вывод: 5

Здесь (v Vertex) — это получатель метода. Это означает, что метод Abs() принадлежит типу Vertex и может быть вызван на переменной этого типа через точку: v.Abs().

Почему это важно? Методы позволяют связать функциональность с конкретным типом данных, делая код более организованным и интуитивным. Вместо того чтобы вызывать Abs(v), мы вызываем v.Abs(), что лучше читается и отражает объектно-ориентированный стиль.

Методы — это просто функции с получателем

Важно понимать, что метод в Go — это не что иное, как обычная функция с дополнительным аргументом. Предыдущий пример можно переписать как функцию:

package main

import (
	"fmt"
	"math"
)

type Vertex struct {
	X, Y float64
}

func Abs(v Vertex) float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
	v := Vertex{3, 4}
	fmt.Println(Abs(v))
}

// Вывод: 5

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

Методы на пользовательских типах

Методы можно определять не только на структурах, но и на любых типах, определённых в том же пакете. Например, можно создать метод на базовом числовом типе:

package main

import (
	"fmt"
	"math"
)

type MyFloat float64

func (f MyFloat) Abs() float64 {
	if f < 0 {
		return float64(-f)
	}
	return float64(f)
}

func main() {
	f := MyFloat(-math.Sqrt2)
	fmt.Println(f.Abs())
}

// Вывод: 1.4142135623730951

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

Получатели-указатели

Мы подошли к важному аспекту методов в Go — различию между получателем-значением и получателем-указателем.

Получатель-значение означает, что метод работает с копией исходного значения:

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

Получатель-указатель означает, что метод работает с указателем на исходное значение и может его изменять:

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

Давайте рассмотрим полный пример, чтобы увидеть разницу:

package main

import (
	"fmt"
	"math"
)

type Vertex struct {
	X, Y float64
}

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

func main() {
	v := Vertex{3, 4}
	v.Scale(10)
	fmt.Println(v.Abs())
}

// Вывод: 50

Метод Abs() с получателем-значением просто вычисляет длину вектора. Метод Scale() с получателем-указателем изменяет координаты исходной структуры. Если бы мы использовали значение-получатель для Scale(), изменения затронули бы только копию, а исходная структура осталась бы неизменной.

Почему это важно? В Go, когда вы передаёте значение функции, она получает копию этого значения. Если структура большая, создание копии может быть неэффективно. Если вам нужно изменить исходное значение, вам необходим указатель.

Автоматическое разыменование указателей

Go предоставляет удобство — методы с получателем-указателем можно вызывать на значениях, и Go автоматически создаст указатель:

var v Vertex
v.Scale(5)  // Go автоматически интерпретирует это как (&v).Scale(5)

Аналогично, методы с получателем-значением можно вызывать на указателях:

var p *Vertex = &Vertex{3, 4}
p.Abs()  // Go автоматически интерпретирует это как (*p).Abs()

Вот полный пример, демонстрирующий обе ситуации:

package main

import (
	"fmt"
	"math"
)

type Vertex struct {
	X, Y float64
}

func (v Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

func main() {
	v := Vertex{3, 4}
	v.Scale(2)        // OK: v — значение, но метод имеет получателя-указатель
	
	p := &Vertex{4, 3}
	p.Scale(3)        // OK: p — указатель на метод с получателем-указателем
	
	fmt.Println(v.Abs())     // OK: вызов Abs на значении
	fmt.Println(p.Abs())     // OK: Go автоматически разыменует указатель
}

// Вывод:
// 5
// 5

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

Когда использовать какой получатель?

1. Когда нужна модификация

Если метод должен изменить получатель, необходимо использовать получателя-указатель:

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

2. Эффективность

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

type LargeStruct struct {
	Data [1000]float64
}

// Хорошо: получатель-указатель, избегаем копирования
func (ls *LargeStruct) Process() {
	// работаем со структурой
}

Консистентность

Важное правило: В общем случае все методы на выбранном типе должны иметь либо получателя-значение, либо получателя-указатель, но не смешивать оба. Это делает код предсказуемым и поддерживаемым.

Вот пример хорошей практики:

package main

import (
	"fmt"
	"math"
)

type Vertex struct {
	X, Y float64
}

func (v *Vertex) Scale(f float64) {
	v.X = v.X * f
	v.Y = v.Y * f
}

func (v *Vertex) Abs() float64 {
	return math.Sqrt(v.X*v.X + v.Y*v.Y)
}

func main() {
	v := &Vertex{3, 4}
	fmt.Printf("До масштабирования: %+v, длина: %v\n", v, v.Abs())
	v.Scale(5)
	fmt.Printf("После масштабирования: %+v, длина: %v\n", v, v.Abs())
}

// Вывод:
// До масштабирования: &{X:3 Y:4}, длина: 5
// После масштабирования: &{X:15 Y:20}, длина: 25

Обратите внимание, что оба метода используют получателя-указатель, что обеспечивает консистентность и позволяет методу Abs() эффективно работать с потенциально большими структурами.

Заключение: Чему мы научились?

Методы в Go — это мощный инструмент для организации кода и создания чистых, читаемых программ. Вот ключевые моменты, которые мы разобрали:

1. Методы — это функции с получателем. Go предоставляет синтаксический сахар для вызова функций как методов, что улучшает читаемость.

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

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

4. Консистентность важнее универсальности. Придерживайтесь одного стиля получателей для всех методов выбранного типа.

Методы позволяют писать объектно-ориентированный код, сохраняя при этом простоту и эффективность, за которые Go так ценится разработчиками по всему миру. Правильное использование методов и получателей сделает ваш код не только функциональным, но и удобным для других разработчиков, которые будут его поддерживать

Apache NiFi: заметки по ведению логов потоков данных

2025-12-29T14:16:23Z

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

В первую очередь, вспомним, какие вообще бывают логи. В целом их 4 типа, хотя почти всегда нужен только один (nifi-app.log)

nifi-app.log - сообщения от процессоров внутри потока, собственно главное средство для отладки потока и понимания того, что вообще происходит в потоке, что было передано, что получено, какие данные обработаны со стороны NiFi;
nifi-user.log - сообщения, связанные с событиями аутентификации и авторизации пользователей, аудит безопасности и проверка пользователей, открывающих веб-интерфейс NiFi;
nifi-bootstrap.log - сообщения о запуске и остановке JVM, диагностика проблем с запуском и самой работоспособностью NiFi;
nifi-request.log - фиксация всех HTTP-запросов к NiFi, аудит веб-трафика (начиная с версии 1.16);
nifi-deprecation.log - логирование сведений об использовании устаревших процессоров (начиная с версии 1.18), используется для информации о наличии компонентов (или их отсутствии), препятствующих обновлению NiFi до новой версии (скажем, 2.x)

Все эти логи хранятся вместе в одной директории (обычно в /opt/nifi/nifi-current/logs, если NiFi развернут в Docker-контейнере, но зависит от специфики установки). Выглядит все это множество файлов например так:

Непосредственно файлы nifi-app.log, nifi-user.log, nifi-bootstrap.log и nifi-request.log представляют собой самые актуальные логи. Файлы же со временной отметкой являются логами историческими и описывают, что происходило с системой ранее. При этом важно четко осознавать, в какой момент логи сохраняются в файле с временной отметкой (то есть переходят в разряд прошедших событий) и каким образом NiFi понимает, что пора писать новый nifi-app.log файл. Далее мы будем рассматривать логирование в контексте nifi-app логов, поскольку их содержимое самое иформативное и интересует нас больше всего. Способы настройки логирования, о которых мы будет говорить далее, абсолютно идентичны и для остальных типов логов.

Итак, настройка же параметров логирования осуществляется в файле /opt/nifi/nifi-current/conf/logback.xml. В данном файла нас наиболее интересует вот этот фрагмент:

<appender name="APP_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <!--
              For daily rollover, use 'app_%d.log'.
              For hourly rollover, use 'app_%d{yyyy-MM-dd_HH}.log'.
              To GZIP rolled files, replace '.log' with '.log.gz'.
              To ZIP rolled files, replace '.log' with '.log.zip'.
            -->
            <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app_%d.%i.log</fileNamePattern>
            <maxFileSize>100MB</maxFileSize>
            <!-- keep 20 log files worth of history -->
            <maxHistory>20</maxHistory>
        </rollingPolicy>
        <immediateFlush>true</immediateFlush>
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>%date %level [%thread] %logger{40} %msg%n</pattern>
        </encoder>
    </appender>

Значения внутри тегов здесь указаны не такие, как по умолчанию, но это не так важно. Как можно увидеть, в атрибут name записано "APP_FILE", а значит мы имеем дело с nifi-app.log, но с остальными типами все то же самое, конфигураторы для них расположены ниже в том же файле. При изменении любых настроек в этом файле не забудьте перезапустить NiFi для их применения.

Как мы видим, в файле уже есть комментарии, кратко поясняющие суть настройки логирования. Если в fileNamePattern указать 'app_%d.log', то новый отдельный файл с логами будет появляться каждый день. Если укажем 'app_%d{yyyy-MM-dd_HH}.log', то каждый час. Также доступно архивирование в zip и gzip. Но кроме этого есть еще две важные характеристики -- это максимальный размер одного файла (maxFileSize) и максимальное число файлов для хранения (maxHistory). Подчеркнем, что в парадигме NiFi число хранимых файлов с логами определяется не конкретными временными рамками, а параметром, задающим максимальное количество файлов. То есть мы храним логи не за "последние n дней", а строго в пределах максимально допустимого maxHistory. Переход к записи логов в новый файл начнется либо когда наступит новый день/час в зависимости от настроек, либо когда размер одного файла превысит maxFileSize. Обращу внимание, что в представленном выше фрагменте XML мы указали паттерн 'nifi-app_%d.%i.log', %i в нем означает индекс файла с логами. Это значит, что если в течение одного дня наберется больше 100МВ логов, то NiFi начнет писать логи уже в новый файл (на скриншотах выше можно заметить, например, файлы nifi-app_2025-12-09.0.log, nifi-app_2025-12-09.1.log и так далее).

Таким образом, основный посыл этой заметки в том, что при менеджменте логов в NiFi-трансферах надо обращать внимание на размер одного файла, на максимальное их количество, на частоту добавления нового файла с логами. Все эти параметры сильно зависят от специфики проекта, ресурсов сервера, пожеланий заказчика. Важно понимать, что если, например, у вас maxHistory равен 10, размер файла выставлен 50MB, а в один день данных внезапно пришло на 500МВ, то все предыдущие логи будут стерты и окажутся недоступны, что может быть проблемой, если необходимо проверить, что приходило в день предыдущий.

Обратим внимание, что в файле logback.xml также расположены уровни логирования для классов и пакетов Apache NiFi, где по желанию можно менять стандартные настройки, изменить WARN на INFO или на ERROR. Например:

<logger name="org.apache.nifi" level="INFO"/>
    <logger name="org.apache.nifi.processors" level="WARN"/>
    <logger name="org.apache.nifi.processors.standard.LogAttribute" level="INFO"/>
    <logger name="org.apache.nifi.processors.standard.LogMessage" level="INFO"/>
    <logger name="org.apache.nifi.controller.repository.StandardProcessSession" level="WARN" />

Поднимаясь же на уровень выше и переходя непосредственно к потоку обработки данных, то есть в веб-интерфейс NiFi, то для логирования мы используем самый обычный процессор LogAttribute, который для этого и предназначен. Здесь можно разве что отдельно выделить параметр Log prefix, который мы всегда заполняем, чтобы обозначить, что вообще логируется в данный момент (факт, что NiFi получил запрос, что обработал данные, что успешно отправил что-либо куда нужно и т.п.). Log Payload указывает на то, логировать ли тело FlowFile'а, или же сохранять в логах только атрибуты. Для атрибутов также хорошей практикой будет выбирать не все значения, а задавать лишь самые важные в свойстве Attributes to Log. Так получится сэкономить место на диске и в целом сохранить больше логов.

В конечном итоге информацию о прошедшем событии можно будет посмотреть в файле nifi-app.log (или в более поздних app файлах). Пример выше довольно простой, в нем мы предполагаем, что у нас NiFi получает запрос одного вида с параметрами ИД и тип, которые мы и хотим залогировать. Добавив процессор выше, мы обнаружим в логах нечто вроде указанного ниже, где префикс будет разделять нужную информацию с остальными логами:

------------[RECORD REQUEST RECEIVED]-------------
FlowFile Properties
Key: 'entryDate'
	Value: 'Thu Dec 18 15:19:17 UTC 2025'
Key: 'lineageStartDate'
	Value: 'Thu Dec 18 15:19:17 UTC 2025'
Key: 'fileSize'
	Value: '0'
FlowFile Attribute Map Content
Key: 'http.query.param.id'
	Value: '12375823'
Key: 'http.query.param.type'
	Value: 'Type1'
------------[RECORD REQUEST RECEIVED]-------------

Как проектировать интерфейс, если ты не дизайнер. Базовые правила хорошего дизайна.

2025-12-27T20:52:06Z

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

Главное правило: Простого достаточно

Первый и самый важный принцип дизайна, если вы не дизайнер — не навреди. Часто стремление сделать «красиво» приводит к перегруженным, непрактичным интерфейсам. Помните: лучший дизайн часто тот, который не замечают. Когда пользователь интуитивно понимает, как взаимодействовать с интерфейсом, не задумываясь о его «дизайне», — вы на правильном пути.

Эта философия находит свое выражение в минимализме, который стал не просто трендом, а практической необходимостью. Каждый лишний элемент — это когнитивная нагрузка, это вопрос, который пользователь должен решить: «Что это? Зачем это? Нужно ли мне это?»
Хотите, чтобы пользователь совершил нужное вам действие — не отвлекайте его.

Второе правило: не изобретайте велосипед.

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

Современные дизайн-системы — это готовые библиотеки компонентов, созданные и протестированные крупнейшими компаниями:

Material Design (Google) — философия материальных поверхностей, реалистичных теней и осмысленной анимации. Это целая экосистема с четкими правилами и компонентами для любой ситуации.
Human Interface Guidelines (Apple) — минималистичный, воздушный подход с акцентом на ясность и уважение к контенту. Особенно важен для iOS-приложений.
Fluent Design (Microsoft) — система, построенная вокруг концепции «света, глубины, движения, материала и масштаба».

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

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

Третье правило: цвета и иерархия

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

Правило трех цветов

Выберите:

Основной цвет (для ключевых действий, акцентов)
Нейтральный цвет (для фона, основного текста)
Цвет для состояния (успех, ошибка, предупреждение)

Этого достаточно для 90% интерфейсов.

Шрифтовая иерархия

Задайте себе три вопроса о каждом элементе интерфейса:

Это критически важно для выполнения основной задачи?
Это полезная дополнительная информация?
Это нужно вообще?

Располагайте элементы в соответствии с этим.
Заголовки — самые важные и самые большие. Далее стандартный основной текст и чуть меньше его — подсказки.

Общая иерархия

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

Наш мозг неосознанно соединяет рядом стоящие объекты и если нарушить правила композиции, то возникнет искажение (как на втором примере)

Совет: Используйте модульные размеры, чтобы не придумывать каждый отступ заново. Модульные размеры — это числа, кратные, например, 8px. Таким образом, расстояния между объектами будут 8, 16, 24, 32 и тд. Для упрощения часто используют только несколько самых важных: 8, 16, 32, 64, 80/96 и 128

Автолейаут для чайников

Для тех, кто создает интерфейсы, одна из самых революционных концепций последних лет — автоматическая верстка (autolayout в Figma, аналог flexbox в вебе). Если в нем разобраться, он сильно упростит работу с дизайном.

Практическое руководство по автолейауту

Начните с фрейма — в Figma это основа для автолейаута
Выберите направление — горизонтальное (ряд) или вертикальное (колонка)
Определите поведение при растягивании — должен ли элемент растягиваться или сохранять размер?
Настройте отступы (padding) — внутренние отступы от краев фрейма
Установите расстояние между элементами (gap)

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

Эмоциональный интеллект интерфейса

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

Микроинтеракции как проявление заботы

Небольшие анимации, изменения состояний, звуковая обратная связь — это элементы, которые превращают функциональный инструмент в приятный опыт. Кнопка, которая слегка «нажимается» при клике, поле ввода, которое подсвечивается при фокусе, плавная подгрузка контента — эти детали создают ощущение качества.

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

Язык, который говорит с пользователем

Текст в интерфейсе — это не просто информация, это голос вашего продукта. Сообщения об ошибках, подсказки, призывы к действию — всё это формирует отношение пользователя.
Вместо сухого «Ошибка 404» напишите «Кажется, мы потеряли эту страницу. Попробуйте начать с главной». Вместо «Отправить» на кнопке формы — «Сохранить изменения» или «Завершить настройку».

Однако, не стоит забывать, что любые тексты в интерфейсе должны соответствовать вашему Tone of Voice. О нем я писал в этой статье.

Заключение: Почему с дизайнером всё же лучше?

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

Что на самом деле делает дизайнер

Профессиональный дизайнер — это не просто человек, который «умеет в Figma». Это:

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

Хороший дизайн также сокращает время разработки — продуманная система компонентов позволяет разрабатывать новые функции в 2-3 раза быстрее. И снижает стоимость поддержки — интуитивный интерфейс уменьшает количество обращений в поддержку и ошибок пользователей.

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

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