IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
🔐 Разбираем модели контроля доступа
1️⃣ DAC (Discretionary Access Control)
🔹 Владелец ресурса сам назначает права (например, доступ к файлу).
🔹 Гибкость — плюс, но риск утечек из-за человеческого фактора.
🔹 Пример: классические UNIX-права (`chmod`).
2️⃣ MAC (Mandatory Access Control)
🔹 Доступ жёстко регулируется системой (госструктуры, военные).
🔹 Использует метки (например, «Секретно»), пользователи не могут менять правила.
🔹 Пример: SELinux, Windows Mandatory Integrity Control.
3️⃣ RBAC (Role-Based Access Control)
🔹 Права выдаются по ролям (админ, модератор, юзер).
🔹 Удобно для бизнес-приложений, но возможен избыточный доступ.
🔹 Пример: корпоративные системы (Active Directory).
4️⃣ ABAC (Attribute-Based Access Control)
🔹 Учитывает атрибуты (роль, время, местоположение, устройство).
🔹 Гибкий, но сложный в настройке и производительности.
🔹 Пример: политики AWS IAM.
5️⃣ FGA (Fine-Grained Authorization)
🔹 Детальный контроль (например, доступ к определённому полю в базе).
🔹 Идеально для микросервисов и API-ориентированных систем.
🔹 Пример: OpenFGA, Google Zanzibar.
💡 Вывод: Выбор зависит от требований — безопасность (MAC), простота (RBAC) или гибкость (ABAC/FGA).
Подробнее: https://www.permit.io/blog/mac-dac-rbac-and-fga-and-access-control
#Security #DevOps #AccessControl
2 · 590 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
✨ View Transitions API — одна строка CSS, и ваш сайт оживает
Помните, как раньше для плавных переходов между страницами нужен был SPA-фреймворк, React Router и куча анимационной логики? Теперь это делается нативно в браузере. Одной строкой.
View Transition API позволяет создавать кинематографичные переходы между страницами — и в SPA, и (что важнее) в обычных многостраничных сайтах. Браузер сам делает скриншоты старого и нового состояний и анимирует разницу через CSS Animations.
▪️ Для SPA — оборачиваете обновление DOM в document.startViewTransition():
document.startViewTransition(() => {
updateTheDOMSomehow();
});
▪️ Для MPA (многостраничник) — вообще без JS. Добавляете в CSS обеих страниц:
@view-transition {
navigation: auto;
}
И всё. Браузер сам подхватит навигацию и сделает плавный переход.
Что можно анимировать: превращение миниатюры в полную картинку, фиксированную навигацию между страницами, перестройку сетки при фильтрации. Работает в Chrome 126+ для MPA, в Chrome 111+ для SPA. Firefox и Safari пока догоняют.
Это один из тех случаев, когда веб-платформа забирает себе то, что раньше требовало библиотек. Как когда-то CSS Grid убил float-сетки — так и View Transitions убивает кастомные page-transition хаки.
🔗 Документация Chrome
#css #frontend #webapi
1 · 169 · Ссылка
нажмите — покажем
нажмите — покажем
🎨 CSS научился стилизовать поиск по странице. И это только начало.
В Chrome 144 появился псевдоэлемент ::search-text — теперь можно стилизовать подсветку результатов поиска по странице (Ctrl+F). Раньше жёлтые выделения были железобетонными — браузер решал за тебя. Теперь — два новых псевдоэлемента:
::search-text {
background: #e0f7fa;
color: #006064;
}
::search-text:current {
background: #ff6f00;
color: white;
}
::search-text стилизует все совпадения, а ::search-text:current — текущее активное. Это часть более широкого семейства Highlight Pseudo-Elements (::selection, ::target-text, ::spelling-error, ::grammar-error), которое CSS развивает последние два года.
Почему это важно? Потому что это философский сдвиг: браузеры отдают разработчикам контроль над вещами, которые раньше были хардкожены. ::target-text позволяет стилизовать фрагменты по scroll-to-text (#:~:text=), ::selection давно работает, а теперь и поиск стал кастомизируемым. Для дизайн-систем и dark-mode тем это спасение — жёлтый хайлайт на тёмном фоне наконец можно починить.
Бонус: Firefox Nightly получил @custom-media — возможность задавать переиспользуемые медиа-запросы как переменные. Адаптивная вёрстка станет ещё чище.
🔗 CSS-Tricks: Styling ::search-text
2 · 155 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
🏗 Модульный монолит vs микросервисы: что на самом деле важно
Один из самых популярных архитектурных постов последних месяцев на HN (148 апвоутов, 151 комментарий) — статья «Modularity is what truly matters». Автор разбирает вечный холивар монолит/микросервисы и приходит к выводу, который многие чувствуют, но боятся сказать вслух: деление на сервисы — вторично. Модульность — первична.
Ловушка, в которую попадают команды: решают «нам нужны микросервисы», нарезают систему на 15 сервисов, а потом обнаруживают, что 10 из них не могут работать друг без друга. Итог — распределённый монолит: все минусы обоих подходов и ни одного плюса. Сетевые вызовы вместо функций, eventual consistency вместо транзакций, и debug через три сервиса вместо одного стектрейса.
Правильная последовательность:
1️⃣ Разберитесь в домене. Найдите реальные границы — где данные и логика слабо связаны друг с другом.
2️⃣ Сделайте модули внутри монолита. Отдельные папки/пакеты с чёткими интерфейсами и минимумом зависимостей. High cohesion, loose coupling.
3️⃣ Только потом, если конкретный модуль нуждается в независимом масштабировании или деплое — выносите его в отдельный сервис. Осознанно, а не «потому что Netflix так делает».
Хороший тест: если два сервиса всегда деплоятся вместе, всегда падают вместе и не могут обработать запрос друг без друга — это не два сервиса. Это один сервис, которому зачем-то добавили сетевой вызов.
Модульный монолит — это не шаг назад. Это честная архитектура, которая масштабируется в микросервисы, когда это действительно нужно, а не когда так написано в блоге.
🔗 Статья
1 · 146 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
🧱 Masonry-раскладка: что это, зачем нужна и как скоро забудем про JS-костыли
Откройте Pinterest, Google Images или Unsplash. Видите, как карточки разной высоты плотно укладываются в колонки без пустых дыр — как кирпичики? Это и есть masonry-раскладка (от англ. masonry — кирпичная кладка).
Почему это было болью. CSS из коробки так не умел. Flexbox раскладывает элементы в ряды одинаковой высоты. Grid — по сетке с фиксированными ячейками. А masonry — это когда каждый элемент «прилипает» к нижнему краю предыдущего в своей колонке, независимо от высоты соседей. До сих пор это решалось костылями:
▸ column-count — ломает порядок элементов (они идут сверху вниз, а не слева направо)
▸ JS-библиотеки вроде Masonry.js — работают, но это лишний JS, пересчёт позиций на каждый ресайз, мерцание при загрузке
Что изменилось. CSS Grid Level 3 вводит display: grid-lanes — нативную masonry-раскладку без единой строчки JavaScript. Буквально:
.container {
display: grid-lanes;
grid-template-columns: repeat(3, 1fr);
gap: 16px;
}
Всё. Три колонки, элементы автоматически заполняют пустоты по высоте.
Когда можно использовать. Safari Technology Preview уже поддерживает финальный синтаксис. Firefox экспериментирует с 2020 года. Chrome и Edge обновляют реализации. Через @supports (display: grid-lanes) можно подключать прямо сейчас с фоллбэком на Masonry.js для старых браузеров.
Одна из тех фич, которую ждали 7 лет — и которая сделает тысячи строк JS ненужными.
🔗 Подробнее — WebKit Blog
6 · 198 · Ссылка
нажмите — покажем
нажмите — покажем
🚀 JavaScript фреймворки в 2026: куда движется фронтенд
Авторы This is Learning подвели итоги года и наметили тренды на 2026-й. Главная мысль: фокус сместился с производительности на стратегическое мышление. AI доминирует в обсуждениях, но как это влияет на сами фреймворки?
🤖 AI-First подход
Remix 3 (больше не на React!) полностью переосмысливает фулстек-разработку с учётом AI. Создатели делают ставку на уменьшение доменно-специфичного языка — чтобы AI мог генерировать универсальные решения, а не привязываться к специфике фреймворка.
Противоположный подход — React как "последний фреймворк", который AI знает лучше всего из-за огромной базы обучения. Но это ловушка: если мы застрянем на React 2018 года только потому, что AI его лучше знает — у нас проблемы.
🔄 Возврат к изоморфности
Islands и Server Components оказались неудобными для сложных интерактивных приложений. Слишком много границ между сервером и клиентом, слишком много путаницы.
Результат: Isomorphic-First архитектура возвращается. SolidStart, Tanstack Start, SvelteKit добавляют Out-of-Order streaming, Server Functions, Optimistic UI — всё лучшее от серверного рендеринга без архитектурных костылей.
Главный вывод: в 2026-м важнее видение, чем реализация. Фреймворки будут развиваться в сторону простоты для AI и удобства для разработчиков сложных приложений.
🔗 Полная статья
1 · 151 · Ссылка
нажмите — покажем
нажмите — покажем
🧮 TypeScript типы как язык программирования — погружение в Turing-complete систему типов
Знали ли вы, что TypeScript Turing-полный? Кто-то уже написал на типах Doom, кто-то реализовал арифметические операции. Но зачем? Чтобы лучше писать типы, думая о них как о программах.
🔧 Дженерики = функции
Типы с параметрами работают как функции — принимают входные типы, возвращают выходные:
// Функция
const identity = (value) => value;
// Тип-функция
type Identity<Type> = Type;
// Более сложный пример
type Crud<Resource extends { id: string | number }> = {
create: (resource: Omit<Resource, 'id'>) => Resource;
getOne: (id: Resource['id']) => Resource | undefined;
update: (id: Resource['id'], data: Partial<Omit<Resource, 'id'>>) => Resource;
}
⚡ Условные типы = if/else
Через extends и тернарный оператор получаем полноценные условия:
type IsNumber<Value> = Value extends number ? true : false;
type InferEventType<T extends Event> =
T extends CreateEvent ? "create" :
T extends UpdateEvent ? "update" :
T extends DeleteEvent ? "delete" : never;
📦 infer = переменные
Ключевое слово infer позволяет «вытаскивать» части типов:
type First<T> = T extends [infer Head, ...any[]] ? Head : never;
type Result = First<[string, number, boolean]>; // string
Зачем это нужно? Система типов становится мета-языком для описания структуры данных. Вместо дублирования кода вы описываете логику один раз в типах — и TypeScript автоматически выводит все остальное.
Следующий уровень после изучения базовых дженериков — начинать думать типами как алгоритмами.
🔗 Полная статья
4 · 155 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
"TypeScript умер. И это хорошо."
Пока все спорят о Bun vs Node, произошло кое-что интереснее: JavaScript ES2024+ стал настолько хорош, что TypeScript превратился в костыль. Новые фичи (decorators, pattern matching, pipe operator) плюс современные IDE с AI-автодополнением делают типизацию почти избыточной.
Смотрите: крупнейшие проекты потихоньку мигрируют обратно на чистый JS. DHH выкинул TS из Turbo, команда Svelte тоже отказалась. Даже создатель Deno Райан Даль признался, что сожалеет о встроенном TypeScript. Причина проста: overhead от сборки больше не оправдывает выгоды.
Но вот главное: новое поколение разработчиков, выросшее на JSDoc + современных линтерах, вообще не понимает, зачем нужна отдельная система типов. Когда VS Code с GitHub Copilot подсказывает типы лучше любого .d.ts файла, а рантайм-валидация через zod/joi покрывает реальные кейсы — зачем мучиться с tsc?
TypeScript сделал своё дело и может уходить.
6 · 215 · Так вот какие посты вызывают реакцию у аудитории😁
159 · Ссылка
нажмите — покажем
нажмите — покажем
Ладно, вот вам еще одно радикальное мнение. Микросервисы — самая дорогая ошибка IT за 10 лет
Netflix: 1000+ микросервисов, армия из 3000+ инженеров, миллиарды на инфраструктуру.
WhatsApp: монолит на Erlang, 50 разработчиков, 2 млрд пользователей, продали за $19 млрд.
Угадайте, кто эффективнее?
Пора признать неудобную правду: 95% проектов выбирают микросервисы не из-за технических требований, а из-за хайпа. Amazon сам говорит, что переход к монолиту сократил их расходы на 90%. Команда Shopify отказалась от микросервисов ради скорости разработки.
Вот что происходит в реальности: каждый новый сервис — это отдельный CI/CD, мониторинг, логи, безопасность, версионирование API. Дебаг распределённой системы превращается в ад. Одна фича теперь требует изменений в 5 репозиториях вместо одного коммита.
А теперь посмотрите на успешные стартапы 2023-2024: Linear, Notion, Figma — все начинали с монолитов и до сих пор ими остаются. Потому что скорость доставки фич важнее теоретической масштабируемости, которая понадобится не скоро.
Монолит-first — это не регресс, а зрелость. Микросервисы нужны 1% проектов, а используют их 80%.
Нужны ваши реакции!
2 · 208 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
🤔 Нужны ли ещё бэкенд-разработчики в 2026?
BaaS-платформы, serverless, ORM, которые пишут SQL за тебя, AI, который сетапит API быстрее, чем ты наливаешь кофе. Казалось бы — зачем нам бэкенд-разработчики?
Ответ прост: инструменты абстрагируют сложность, но не устраняют её. Когда стартап гордо заявляет «фронтенд напрямую ходит в Supabase, бэкенда нет» — это работает. До первого инцидента. Потому что убрали не бэкенд — убрали человека, который его понимает. Бэкенд-разработчик — это не тот, кто пишет CRUD-эндпоинты. Это тот, кто проектирует модели данных, которые переживут реальную нагрузку, думает о консистентности, отказоустойчивости и edge cases, и знает, куда смотреть, когда в 3 часа ночи всё ломается под нагрузкой.
Serverless не убил бэкендеров — он их трансформировал. Теперь вместо настройки серверов нужно разбираться в распределённых системах, event-driven архитектурах, observability и расходах, которые тихо взрываются за ночь. AI тоже не заменяет — он убирает скучную часть работы, ту, которую мы и так не любили. А вот понимание бизнес-ограничений, принятие решений в условиях неопределённости и дебаг эмерджентного поведения между сервисами — это по-прежнему задача человека. Бэкенд не исчезает. Он становится невидимым. И чем менее он заметен, тем ценнее люди, которые действительно его понимают.
196 · IT Капибара
Dependency hell в 2026: npm install займёт больше времени, чем разработка фичи
В прошлом году средний фронтенд-проект набрал 1,200+ зависимостей. Для сравнения — в операционной системе их меньше.
Хотите добавить кнопку? Установите UI-библиотеку. Она тянет 15 утилит для стилей, которые тянут парсеры, которые тянут валидаторы, которые тянут... Поздравляю, ваша кнопка весит 50MB в node_modules.
А потом начинается магия:
• Пакет A требует [email protected]
• Пакет B требует [email protected]
• Пакет C вообще переписал lodash и назвал его "lodash-pro"
• npm пытается это всё совместить и плачет
В итоге npm audit показывает 847 уязвимостей, половина зависимостей давно не поддерживается, а обновление одного пакета ломает половину проекта.
Что получается: left-pad не научил нас ничему. Мы всё ещё импортируем целую библиотеку ради одной функции и удивляемся, почему бандл раздулся до размеров небольшой ОС.
Может, пора вспомнить, что иногда 10 строк своего кода лучше, чем зависимость от "ultra-mega-helper-utils-v2"?
1 · 236 · IT Капибара
🤖 Неудобная правда: ИИ делает джунов бесполезными, а сеньоров — незаменимыми
Все говорят, что AI заменит программистов. Реальность жёстче: он заменит плохих программистов и усилит хороших.
Джун 2024 года: гуглит ошибки, копипастит со StackOverflow, тратит 2 часа на то, что Copilot делает за 30 секунд. Его единственное преимущество — дешевизна — больше не преимущество. Зачем платить человеку за работу, которую AI делает быстрее и без выходных?
Сеньор 2024 года: понимает почему код работает, видит архитектурные проблемы, задаёт правильные вопросы AI и критически оценивает ответы. Он не конкурирует с AI — он использует его как множитель своей экспертизы.
Парадокс: Чтобы эффективно использовать AI для кода, нужно уже уметь кодить. Джунам AI не помогает расти — он помогает им не расти, выдавая готовые ответы без понимания.
Раньше путь был: джун → мидл → сеньор. Теперь: джун → ???
Кто будет сеньорами через 10 лет, если джуны не проходят путь боли и ошибок? 🪦
1 · 233 · IT Капибара
Vibe Coding: программирование перестало быть про код
Раньше разработчик знал каждый символ своей кодовой базы, писал с нуля, гордился элегантными решениями. "Чистый код" был манифестом. Джуны зубрили синтаксис, сеньоры спорили об оптимизациях.
Сейчас происходит сдвиг. Andrej Karpathy назвал это вайбкодингом — ты описываешь намерение, AI пишет реализацию. Cursor, Copilot, Claude Code — уже не автокомплит, а полноценный со-разработчик.
Что изменилось философски:
🔹 От "как" к "что" — важнее понимать архитектуру и бизнес-логику, чем помнить API
🔹 От написания к ревью — читаешь и проверяешь больше, чем пишешь
🔹 От синтаксиса к семантике — правильный промпт важнее знания фреймворка
🔹 От владения к оркестрации — управляешь инструментами, а не молотком сам
Это не "деградация навыков". Когда-то программисты перекладывали данные в регистрах ассемблера - а писать на высокоуровневом языке считалось детской забавой. Когда-то управляли памятью вручную - потом появился garbage collector. Писали SQL руками — появились ORM. Каждый уровень абстракции освобождал для более важных задач.
Это просто следующий этап закономерного развития. Как мы сейчас не утруждаем себя ручным управлением памятью, так и ручное написание синтаксический конструкций, бизнес-логики и оптимизаций рендера страницы станет все больше выходить из моды. Инженер - это теперь тот, кто строит систему на уровне задач, которые она должна решать, а не как правильно реализовать отписку от таймера на Реакте.
Но разве это не всегда было настоящей сутью инженера?
225 · 🎭 ООП в JavaScript — карго-культ, который пора похоронить
Когда Java-разработчик приходит в JS, первое что он делает — тащит классы, наследование и паттерны из Gang of Four. И код превращается в это:
class UserRepository extends BaseRepository {
constructor(database) {
super(database);
this.model = UserModel;
}
async findById(id) {
return super.findById(id);
}
}
// 50 строк обёртки ради одного запроса в базу
А можно было так:
const findUser = (db) => (id) => db.query('users', { id });
// Всё. Одна строка. Тестируется за 5 секунд.
Почему это карго-культ:
1. Классы в JS — синтаксический сахар над прототипами. Вы не получаете настоящую инкапсуляцию (private появился вчера и работает костыльно)
2. Наследование — антипаттерн. Даже в Java давно говорят "composition over inheritance". В JS это критично вдвойне
3. this — мина замедленного действия. Половина багов в "классовом" коде — потеря контекста
Функции — first-class citizens в JS. Используй это. Композиция функций > иерархия классов.
2 · 321 · IT Капибара
🏦 COBOL: код, которому 66 лет, до сих пор управляет деньгами миллионов людей
Когда житель США проводит картой или бронирует авиабилет — за кулисами работает код, написанный до вашего рождения. Миллиарды строк COBOL из 1970-х тихо держат мировую экономику на плаву. COBOL создали в 1959 году по заказу Пентагона. Изначально это была временная заплатка — а потом Минобороны надавило на производителей компьютеров, и язык стал стандартом. «Временное решение» живёт уже 66 лет.
Язык проектировали так, чтобы код читался как английский текст: MOVE SALARY TO TOTAL-PAY. Идея была в том, что даже менеджер поймёт, что происходит. На практике получились программы на сотни тысяч строк, которые понимают только те, кто их писал.
Почему это проблема
Эксперты, которые писали этот код — уходят на пенсию. Университеты перестали преподавать COBOL десятилетия назад. Банки платят бешеные деньги за контракторов и еле держатся.
Во время ковида несколько штатов США столкнулись с коллапсом: системы пособий по безработице были на COBOL, а специалистов не хватало.
В некоторых банках сейчас работает такая цепочка: Java-код генерирует COBOL, который крутится внутри эмулятора, имитирующего старый IBM-мейнфрейм. Сотрудники банков до сих пор видят монохромные зелёные терминалы — прямо как в фильмах про хакеров из 90-х.
Java, которая сейчас заменяет COBOL в тех же банках, через 30 лет станет таким же легаси. Может быть, будущие разработчики будут запускать эмулятор современных систем, внутри которого Java генерирует COBOL, который крутится в эмуляторе IBM.
1 · 343 · IT Капибара
Фотография
нажмите — покажем
нажмите — покажем
Приглашаем в новый ИТ-хаб Группы «Т-Технологии» — место, где идеи превращаются в реальные продукты.
Встречаемся 26 марта: вас ждут выступления команды — поговорим о развитии саратовского ИТ-хаба, применении AI в разработке и роли системного аналитика в создании продуктов. А ещё — экскурсия по офису, чтобы увидеть всё изнутри.
После программы — время для общения: знакомьтесь, задавайте вопросы и обсуждайте идеи с теми, кто работает в ИТ каждый день.
Зовите коллег и регистрируйтесь прямо сейчас: количество мест ограничено!
Подробнее о программе и регистрация — https://l.tbank.ru/dod_saratov_26
1 · 318 · IT Капибара
Видео
IMG_3841.MP4 · 3.0 МБ · нажмите — покажем
IMG_3841.MP4 · 3.0 МБ · нажмите — покажем
Видео
IMG_3842.MP4 · 43.5 МБ · нажмите — покажем
IMG_3842.MP4 · 43.5 МБ · нажмите — покажем
Видео
IMG_3843.MP4 · 3.5 МБ · нажмите — покажем
IMG_3843.MP4 · 3.5 МБ · нажмите — покажем
Самый хайпующий проект в интернете прямо сейчас – Pretext
Инженер из Midjourney выложил в опенсорс алгоритм, который позволяет делать верстку без CSS. То есть он сам считает layout текста, без DOM и без браузерного reflow.
Звучит странно, потому что мы привыкли, что за это отвечает браузер. Но браузер делает это тяжело, через каскад стилей, зависимости между элементами и пересчеты при каждом изменении. Если текст часто меняется, вся система начинает тормозить. Pretext убирает этот слой и сводит задачу к прямой математике.
Собственно, это дает кратный выигрыш по скорости – до 500х.
Зачем это все нужно?
Сейчас появляется все больше интерфейсов, где текст и структура не заданы заранее, а формируются динамически. В частности – это история про агентов.
Когда агент собирает UI под задачу пользователя, интерфейс не фиксирован, он постоянно меняется, иногда буквально на каждом шаге. И каждый такой апдейт через браузерный reflow – это лишняя задержка и непредсказуемость.
С Pretext это занимает гораздо меньше времени + полностью контролируемо со стороны кода. Когда интерфейс генерирует не человек, а система, удобнее работать с прямыми алгоритмами, а не с тяжелым браузерным пайплайном.
Ну и, конечно, выглядит это очень красиво. За счет скорости обработки выдумать поверх Pretext можно что угодно (примеры прикладываем). И все же в первую очередь проект интересен именно тем, как изящно он ложится на новые сценарии.
github.com/chenglou/pretext
2 · 395 · IT Капибара
Ссылка
нажмите — покажем
нажмите — покажем
Дорогие подписчики!
Постов про то, что ИИ всех заменил и больше не надо понимать внутреннего устройство вашего любимого фреймворка - не будет!
Айти Капибара продолжает работу в штатном режиме и публикует интересные инженерные публикация. Админ убежден, что подобные знания будут только ценнее с течением времени, когда вокруг вас останутся только болванчики для промптинга Клода.
Поэтому сегодня на очереди материал о том, как работает тот самый механизм attention в любимых вами ГПТшках, который перевернул все и дал такой мощный буст языковым моделям.
https://t.me/tuzov_ai_lab/95
200 ·