Tune IT

Astro.js: современный фреймворк для контент-ориентированных сайтов

2026-05-06T09:50:23Z

Astro.js: современный фреймворк для контент-ориентированных сайтов

Что такое Astro и зачем он нужен

Astro — это фреймворк для сайтов и веб-приложений, который по умолчанию рендерит большую часть страницы в статический HTML на сервере, а JavaScript подключает только там, где он действительно нужен. Такой подход называется islands architecture: основная часть страницы остается «легкой», а интерактивность добавляется небольшими изолированными фрагментами.

Astro поддерживает несколько UI-фреймворков одновременно: React, Preact, Vue, Svelte, Solid и веб-компоненты. Это делает его удобным, когда нужно сочетать контентные страницы, маркетинговые лендинги, документацию и отдельные интерактивные блоки в одном проекте.

Ключевые преимущества

Производительность «из коробки»

Astro проектировался как server-first решение, поэтому большинство страниц может отдаваться без необходимости тащить на клиент целый фреймворк runtime. В документации прямо отмечено, что это снижает сложность по сравнению с другими UI-фреймворками, потому что на сервере нет необходимости управлять реактивностью, хуками, stale closures и похожими механизмами.

UI-агностичность

Astro имеет систему интеграций и renderer-ов, через которую подключаются UI-фреймворки, адаптеры для серверного рендеринга и дополнительные возможности вроде MDX или sitemap. Для обычного проекта подключение официальной интеграции делается в несколько строк.

React — для компонентов с богатым состоянием,
Preact — там, где нужен React-подобный синтаксис с минимальным весом,
Svelte — для компактных и производительных виджетов,
Vue — если команда привыкла к его экосистеме,
Lit — для веб-компонентов.

На практике это особенно ценно при миграции старых проектов: вы можете постепенно переписывать компоненты, не ломая всё сразу.

Гибкая модель интерактивности

Astro использует компонентный подход, но интерактивность включается точечно через hydration directives: client:load, client:idle, client:visible, client:media и client:only. Это позволяет запускать JavaScript только для конкретных элементов интерфейса и выбирать момент загрузки в зависимости от приоритета UI.

Content Collections

Начиная с версии 2.0, Astro предлагает типизированные коллекции контента — встроенную систему для работы с Markdown, MDX и другими форматами с полной поддержкой TypeScript.

Технические основы: как это работает

Этапы сборки

Когда вы запускаете astro build, происходит следующее:

Парсинг компонентов — Astro читает все .astro-файлы и компоненты UI-фреймворков.
Статическая генерация — выполняется JavaScript в frontmatter (часть между ---), которая может делать запросы к API, читать файлы и т.д.
Рендеринг в HTML — вся разметка превращается в чистый HTML.
Выделение «островов» — компоненты с клиентскими директивами (client:load, client:idle и т.д.) упаковываются отдельно.
Гидратация — при загрузке страницы браузер загружает только нужные острова, причём строго по заданной стратегии.

Клиентские директивы

Директивы определяют, когда браузер должен оживить компонент:

Директива	Поведение
`client:load`	Немедленно при загрузке страницы
`client:idle`	Когда браузер освободился (через `requestIdleCallback`)
`client:visible`	Когда компонент попадает в область видимости (Intersection Observer)
`client:media="(max-width: 768px)"`	При совпадении медиазапроса
`client:only="preact"`	Только на клиенте, без серверного рендеринга

Синтаксис `.astro`-файлов

.astro-файл делится на две части: frontmatter (серверный JavaScript) и шаблон (HTML-подобная разметка).

---
// Всё здесь выполняется ТОЛЬКО на сервере/в момент сборки.
// Этот код никогда не попадёт в браузер.

import Header from '../components/Header.astro';
import ProductCard from '../components/ProductCard.jsx'; // React-компонент
import { getCollection } from 'astro:content';

const products = await fetch('https://api.example.com/products')
  .then(res => res.json());

const { title = 'Каталог товаров' } = Astro.props;
---

<html lang="ru">
  <head>
    <meta charset="UTF-8" />
    <title>{title}</title>
  </head>
  <body>
    <!-- Статический Astro-компонент -->
    <Header />

    <main>
      <h1>{title}</h1>

      <ul class="product-grid">
        {products.map(product => (
          <!-- ProductCard — React-компонент -->
          <ProductCard client:visible name={product.name}/>
        ))}
      </ul>
    </main>
  </body>
</html>

<style>...</style>

Astro автоматически изолирует CSS-стили — каждый .astro-файл получает уникальный хэш-атрибут.

Layouts — переиспользуемые макеты

В Astro макеты — это просто компоненты со слотом <slot />:

---
// src/layouts/BaseLayout.astro
interface Props {
  title: string;
  description?: string;
}

const { title, description = 'Мой Astro-сайт' } = Astro.props;
---

<!doctype html>
<html lang="ru">
  <head>
    ...
  </head>
  <body>
    <nav class="site-nav"> ... </nav>

    <!-- Содержимое страницы подставляется сюда -->
    <slot />

    <footer>© 2024 Мой сайт</footer>
  </body>
</html>

Маршрутизация и работа с данными

Файловая маршрутизация

Astro использует файловую систему для маршрутизации — принцип, знакомый по Next.js:

src/pages/
├── index.astro          → /
├── about.astro          → /about
├── blog/
│   ├── index.astro      → /blog
│   └── [slug].astro     → /blog/любой-slug
└── api/
    └── products.ts      → /api/products  (API-эндпоинт)

Динамические маршруты и `getStaticPaths`

Для генерации динамических страниц используется функция getStaticPaths:

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';
import BlogLayout from '../../layouts/BlogLayout.astro';

// Эта функция говорит Astro: "вот все возможные URL, которые нужно сгенерировать"
export async function getStaticPaths() {
  const posts = await getCollection('blog'); // читаем коллекцию из src/content/blog/

  return posts.map(post => ({
    params: { slug: post.slug },
    props: { post },              // передаём данные в компонент
  }));
}

const { post } = Astro.props;
const { Content } = await post.render(); // превращаем Markdown в компонент
---

<BlogLayout title={post.data.title} description={post.data.description}>
  <article>
    <h1>{post.data.title}</h1>
    <time>{post.data.publishedAt.toLocaleDateString('ru-RU')}</time>
    <!-- Content — это готовый к рендерингу HTML из Markdown-файла -->
    <Content />
  </article>
</BlogLayout>

Content Collections с типизацией

Система коллекций позволяет описать схему frontmatter и получить полную автодополнение в редакторе:

// src/content/config.ts
import { defineCollection, z } from 'astro:content';

const blogCollection = defineCollection({
  type: 'content', // 'content' для Markdown, 'data' для JSON/YAML
  schema: z.object({
    title: z.string(),
    description: z.string(),
    publishedAt: z.date(),
    tags: z.array(z.string()).default([]),
    draft: z.boolean().default(false),
    // Если поля нет — TypeScript немедленно об этом сообщит
    coverImage: z.string().optional(),
  }),
});

export const collections = {
  blog: blogCollection,
};

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

API-эндпоинты

Astro позволяет создавать серверные API прямо внутри проекта:

// src/pages/api/newsletter.ts
import type { APIRoute } from 'astro';

export const POST: APIRoute = async ({ request }) => {
  const body = await request.json();
  const { email } = body;

  if (!email || !email.includes('@')) {
    return new Response(
      JSON.stringify({ error: 'Некорректный email' }),
      { status: 400, headers: { 'Content-Type': 'application/json' } }
    );
  }

  // Здесь можно вызвать любой сервис: Mailchimp, Resend, собственную БД...
  await subscribeToNewsletter(email);

  return new Response(
    JSON.stringify({ success: true }),
    { status: 200, headers: { 'Content-Type': 'application/json' } }
  );
};

Сравнение с другими фреймворками

Понять место Astro в экосистеме проще всего через сравнение с конкурентами. Но важно понимать: это не «Astro против Next.js», а «разные инструменты для разных задач».

Сводная таблица

Критерий	Astro	Next.js	SvelteKit	Nuxt
JS по умолчанию	✅ Нет	❌ Да	⚠️ Минимум	❌ Да
Смешение фреймворков	✅ Да	❌ Нет	❌ Нет	❌ Нет
SSR	✅ Да	✅ Да	✅ Да	✅ Да
Встроенный роутер	✅ Файловый	✅ Файловый	✅ Файловый	✅ Файловый
Лучший случай	Контент-сайты	Rich SPA	Svelte-приложения	Vue-приложения
Порог входа	Низкий	Средний	Средний	Средний

Интеграция с UI-фреймворками на практике: Preact

Preact — это компактная библиотека компонентов, совместимая с React-экосистемой через preact/compat. В официальных материалах Preact подчеркивается, что compatibility layer позволяет использовать React-компоненты как drop-in replacement в ряде случаев, а сам Preact отличается более близким к DOM поведением и меньшим runtime-overhead, в том числе без synthetic event system.

В Astro интеграция с Preact подключается официальным пакетом @astrojs/preact. Для обычного использования достаточно команды astro add preact; после этого Astro умеет рендерить Preact-компоненты и гидрировать их через client:* директивы.

Установка и конфигурация

# Добавляем интеграцию одной командой
npx astro add preact

# Или вручную через npm
npm install @astrojs/preact preact

После этого обновляем конфиг:

// astro.config.mjs
import { defineConfig } from 'astro/config';
import preact from '@astrojs/preact';

export default defineConfig({
  integrations: [
    preact({
      // compat: true — включает слой совместимости с React,
      // что позволяет использовать некоторые React-библиотеки с Preact
      compat: true,
    }),
  ],
});

Особенности и тонкости при работе с Preact в Astro

Атрибуты class vs className. В Astro-компонентах (.astro) всегда используется class. В Preact-компонентах (.jsx) тоже рекомендуется class, а не className — это одно из отличий Preact от React.

Серверный рендеринг Preact-компонентов. Даже без клиентской директивы Preact-компоненты рендерятся на сервере в HTML. Директива лишь добавляет гидратацию. Это значит, что поисковик увидит контент компонента, даже если JavaScript в браузере отключён.

client:only="preact" нужен в редких случаях — когда компонент использует браузерные API (localStorage, window) и не может быть отрендерен на сервере. В таком случае Astro пропускает серверный рендеринг полностью.

// Компонент, который читает из localStorage — не может работать на сервере
export default function ThemeToggle() {
  const [theme, setTheme] = useState(
    // localStorage доступен только в браузере
    () => localStorage.getItem('theme') ?? 'light'
  );

  // ...
}

<!-- Правильно: client:only пропускает SSR -->
<ThemeToggle client:only="preact" />

Итог

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

Введение в архитектуру ПО. Часть 1: Истинная ценность структуры и цена спешки

2026-05-01T13:23:55Z

Введение

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

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

Что на самом деле означает хорошая архитектура

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

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

Именно это и является единственным значимым критерием.

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

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

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

Синдром быстрого старта и иллюзия «разберёмся потом»

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

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

В разработке программного обеспечения происходит ровно то же самое.

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

Проблема в том, что это «потом» почти никогда не наступает. После первой задачи приходит вторая, за ней третья - давление не ослабевает, а технический долг неуклонно накапливается. До тех пор, пока рутинная задача вдруг не начинает занимать неделю вместо дня.

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

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

Технический долг: когда метафора становится реальностью

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

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

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

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

Признаки того, что технический долг вышел из-под контроля, как правило, очевидны:

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

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

Две составляющие любого программного продукта

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

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

Структура - это то, насколько легко систему можно изменить.

Само английское слово software содержит в себе это значение: soft - мягкий, податливый. Программное обеспечение изначально задумано как то, что легко поддаётся изменениям. Сложность добавления новой возможности должна определяться только масштабом самой этой возможности - но никак не состоянием кодовой базы.

Наглядный пример: система формирует отчёты в формате PDF. Бизнес просит добавить выгрузку в Excel. Если архитектура продумана - это задача на несколько дней. Если логика формирования отчёта жёстко связана с логикой генерации PDF - команда переписывает модуль несколько недель.

Что важнее - поведение или структура? Ответ неочевиден, но принципиален.

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

Связанность и согласованность: два понятия, которые стоит знать

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

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

Хорошо спроектированная система стремится к низкой связанности. Модули взаимодействуют друг с другом через чётко определённые интерфейсы и не «знают» о внутреннем устройстве соседних компонентов. Это позволяет изменять, тестировать и заменять отдельные части системы независимо друг от друга.

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

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

Матрица Эйзенхауэра: почему архитектура всегда проигрывает в приоритетах

Президент Дуайт Эйзенхауэр сформулировал это так: «У меня есть два вида дел - срочные и важные. Срочные, как правило, не самые важные, а важные - не самые срочные».

В разработке эта закономерность проявляется особенно отчётливо.

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

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

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

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

Как архитектура влияет на команду: человеческое измерение

Разговор об архитектуре нередко сводится к техническим и экономическим аргументам. Однако есть ещё одно измерение, которое упускают из виду - человеческое.

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

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

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

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

Как обосновывать важность архитектуры в диалоге с руководством

Разработчик - это не просто исполнитель, реализующий поставленные задачи. Это профессионал со своей зоной ответственности. И защита качества системы - неотъемлемая часть этой ответственности.

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

Несколько практических принципов:

Избегайте субъективных формулировок: «код стал некрасивым» или «это технически неправильно» не убеждают никого, кто не занимается разработкой.
Говорите на языке конкретных последствий: «Если мы выделим три дня на оптимизацию этого модуля сейчас, следующий этап займёт неделю, а не месяц».
Фиксируйте технический долг явно. Если ваша команда принимает осознанное решение сделать что-то упрощённо ради скорости - запишите это. Создайте задачу, опишите, что именно было сделано не так, как следовало бы, и почему. Это переводит технический долг из категории неосознанного накопления в категорию управляемого инструмента. Руководство видит, что команда отдаёт себе отчёт в принятых решениях, а не просто пишет «как получается».
Внедрите принцип постепенного улучшения: каждый раз, работая с определённым участком кода, оставляйте его в немного лучшем состоянии, чем он был до вашего вмешательства. Это не требует отдельного времени - это профессиональная привычка, которая со временем существенно меняет общее состояние системы.
Предлагайте компромиссы, а не ультиматумы. Вместо «нам нужна неделя на рефакторинг, иначе ничего не выйдет» попробуйте «давайте заложим в план двадцать процентов времени на улучшение структуры параллельно с основной работой». Это звучит управляемо и вызывает значительно меньше сопротивления.

Заключение

Если сформулировать главное из этого материала, получится следующее.

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

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

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

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

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

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

Спасибо, что прочитали материал до конца.

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

Следите за продолжением.

Анатомия письма: почему 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 так ценится разработчиками по всему миру. Правильное использование методов и получателей сделает ваш код не только функциональным, но и удобным для других разработчиков, которые будут его поддерживать

Tune IT

Astro.js: современный фреймворк для контент-ориентированных сайтов

Astro.js: современный фреймворк для контент-ориентированных сайтов

Что такое Astro и зачем он нужен

Ключевые преимущества

Производительность «из коробки»

UI-агностичность

Гибкая модель интерактивности

Content Collections

Технические основы: как это работает

Этапы сборки

Клиентские директивы

Синтаксис .astro-файлов

Layouts — переиспользуемые макеты

Маршрутизация и работа с данными

Файловая маршрутизация

Динамические маршруты и getStaticPaths

Content Collections с типизацией

API-эндпоинты

Сравнение с другими фреймворками

Сводная таблица

Интеграция с UI-фреймворками на практике: Preact

Установка и конфигурация

Особенности и тонкости при работе с Preact в Astro

Итог

Введение в архитектуру ПО. Часть 1: Истинная ценность структуры и цена спешки

Введение

Что на самом деле означает хорошая архитектура

Синдром быстрого старта и иллюзия «разберёмся потом»

Технический долг: когда метафора становится реальностью

Две составляющие любого программного продукта

Связанность и согласованность: два понятия, которые стоит знать

Матрица Эйзенхауэра: почему архитектура всегда проигрывает в приоритетах

Как архитектура влияет на команду: человеческое измерение

Как обосновывать важность архитектуры в диалоге с руководством

Заключение

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

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

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

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

Введение

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Введение

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

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

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

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

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

Горутины

Каналы

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

Синтаксис `.astro`-файлов

Динамические маршруты и `getStaticPaths`