🛠 Pure CSS - модульный CSS-фреймворк с минимальными габаритами. Размер всей библиотеки составляет всего 3,8 Кб, но этот размер можно еще больше уменьшить, исключив ненужные части. Модули включают в себя базовый набор стилей, адаптивную сетку, компоненты форм, кнопки, таблицы и меню.

🌍 Сайт

Daily Coding #инструменты #CSS & Max

RE Покупка квартиры
Ссылка на проект

Поиск по теме:
#недвижимость

Гонзо обзоры HCI статей: Экономические обоснования интерфейсов

Существует достаточно большое число работ по Cost-justified usability, разборов метрик окупаемости инвестиций, но при этом достаточно маленькое число работ и проектов, которые проводятся экономистами, чтобы описать функционал интерфейса и его роль. Сегодня у нас в разборе работа "Market user interface design." In Proceedings of the 13th ACM Conference on Electronic Commerce (EC ’12), June 04 - 08, 2012, в общем-то работа на стыке дизайна рынков и дизайне пользовательского интерфейса

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

Поскольку люди несут когнитивные издержки при обработке информации [Miller 1956], изобилие информации или изобилие выбора в рыночных средах делает внимание дефицитным ресурсом. Тем не менее традиционные экономические модели предполагают, что агенты являются полностью рациональными, обладают неограниченным временем и неограниченными вычислительными ресурсами для обдумывания. Мы устраняем это несоответствие, явно учитывая поведенческие соображения при проектировании рыночных UI.

Подобно тому, как цветовая маркировка самолётов облегчает работу авиадиспетчера, наша цель — проектировать рыночные UI, которые делают принятие экономических решений проще, тем самым повышая общественное благосостояние. В этом смысле наш подход согласуется с идеей «архитектуры выбора» (choice architecture), предложенной Талером и коллегами [Thaler et al. 2010].
Рыночный UI лучше всего определяется двумя вопросами:
Какая информация отображается пользователю?
Сколько и какие именно варианты выбора ему предлагаются?

Цель — разработать вычислительный метод, который находит оптимальный рыночный UI, исходя из поведенческой модели пользователя. Использование поведенческих моделей может привести к иным рыночным UI по нескольким причинам

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

Каждый участник садился за компьютер и играл в серию коротких «раундов» (всего 6 раундов в одной игре). В начале у него было 30 токенов — это как месячный бюджет на быстрый интернет.
В каждом раунде на экране появлялось несколько кнопок (от 3 до 6). Каждая кнопка показывала:
Скорость интернета (например, 900 КБ/с, 300 КБ/с, 100 КБ/с или 0 КБ/с)
Ценность этого выбора в долларах (сколько вы заработаете, если выберете именно её)
Цену в токенах

В зависимости от того, насколько важная у вас сейчас «задача» (высокая, средняя или низкая важность), ценность одной и той же скорости сильно менялась. В важный момент (например, отправить отчёт начальнику) высокая скорость могла стоить очень дорого в долларовом эквиваленте, а в момент бесцельного скроллинга — почти ничего.
При этом время на принятие решения было жёстко ограничено — 7 или 12 секунд. Если не успеваешь выбрать — автоматически выбирается самый медленный вариант с большим штрафом. Это создавало реалистичное давление: нужно быстро думать, когда «трафик дорогой».
Участники играли десятки таких игр подряд, а экспериментаторы меняли правила: количество кнопок, меняются ли цены каждый раунд, адаптируется ли набор вариантов под текущую важность задачи и т.д.

Дизайнер UI решает:
сколько вариантов предлагать

Дизайнер UI решает:
сколько вариантов предлагать,
какие именно варианты предлагать.

Мы изучаем следующие четыре рычага дизайна рыночного UI:
Количество вариантов — сколько кнопок выбора доступно пользователям (3, 4, 5 или 6).
Фиксированные или динамические цены — В условии с фиксированными ценами каждый вариант всегда стоит фиксированное количество токенов (2 токена за 100 КБ/с). При динамических ценах в каждом раунде с вероятностью 1/3 выбирается один из 3 уровней цены, при этом цена за 100 КБ/с составляет 1, 2 или 3 токена (соответственно, 500 КБ/с стоит 5, 10 или 15 токенов).⁸
Фиксированные или адаптивные наборы выборов — В условии с фиксированным набором пользователи всегда имеют один и тот же набор вариантов в каждом раунде. В условии с адаптивными наборами состав предлагаемых вариантов может меняться в зависимости от категории задачи (например, в категории высокой важности доступно больше высокоскоростных вариантов, в низкой — больше низкоскоростных).
Оптимизация UI под рациональное или поведенческое поведение — Определяет метод, по которому формируется состав наборов выборов. В условии рациональной оптимизации наборы оптимизируются на основе MDP-модели при предположении полностью рационального поведения. В условии поведенческой оптимизации наборы оптимизируются с учётом поведенческой модели квантового отклик

По сути дизайнер решает две главные вещи:
Сколько вариантов показывать? (3, 4, 5 или 6 кнопок)
Какие именно варианты показывать? Например:
Показывать 0 / 100 / 300 / 900 КБ/с
Или 0 / 200 / 500 / 950 КБ/с
Или совсем другие комбинации

Хотя теоретически скорость интернета может быть любой (100, 237, 456 КБ/с и т.д. — бесконечное множество), дизайнер UI искусственно ограничивает выбор и предлагает только конечный «меню».
Исследователи сами выступали в роли дизайнеров UI и тестировали разные версии интерфейса:
Обычный (рациональный) дизайн — оптимизирован так, как будто пользователь идеально рационален.
Поведенческий дизайн — оптимизирован с учётом того, что люди часто ошибаются, боятся потерь и подвержены эффектам позиции.

Итак, привлекли 53 участников (27 мужчин, 26 женщин) из района Сиэтла с нетехническими профессиями. Все имели как минимум степень бакалавра. Авторы исключили участников, специализировавшихся на компьютерных науках, экономике, статистике, математике или физике.
Исследование было разделено на два отдельных эксперимента. В Эксперименте 1 участвовали 35 человек; мы тестировали рычаги дизайна «Количество вариантов» (внутрисубъектный фактор) и «Фиксированные или динамические цены» (межсубъектный фактор). Рандомизировали порядок, в котором пользователи играли в игры с 3, 4, 5 и 6 вариантами. Для каждого условия пользователь сначала играл четыре 12-секундные игры, затем четыре 7-секундные игры и, наконец, одну игру с эндогенным 240-секундным лимитом времени.

В Эксперименте 2 участвовали 18 человек; мы тестировали рычаги «Фиксированные или адаптивные наборы выборов» и «Рациональная или поведенческая оптимизация UI» (оба — внутрисубъектные факторы). Во всех играх было по четыре варианта и динамические цены.

Чем больше вариантов выбора предлагалось пользователям, тем лучше они справлялись - но только до определённого предела. Реализованная ценность (то есть реальные деньги, которые участники «зарабатывали» в игре) заметно росла при увеличении количества кнопок с 3 до 4 и далее до 5. Однако переход от 5 к 6 вариантам уже не давал статистически значимого прироста. Авторы предполагают, что на этом рубеже дополнительная нагрузка при выборе начинает уравновешивать пользу от большего выбора.
Ещё один победитель - адаптивные наборы выборов. Когда интерфейс динамически подстраивал предлагаемые скорости под текущую важность задачи (в важный момент показывал больше быстрых вариантов, в спокойный — больше экономичных), пользователи принимали заметно более выгодные решения. Реализованная ценность в этом случае была значительно выше, чем при фиксированном наборе кнопок.

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

Собственно, два варианта интерфейса, который видели участники эксперимента.
(a) Mockup — как это выглядело бы в реальном приложении на смартфоне

(b) Screenshot игры — то, что видели участники эксперимента
Справа — лабораторная версия игры, которую использовали в исследовании. Здесь всё максимально прозрачно для научных целей.

Участник должен быстро (за 5–12 секунд) выбрать скорость, которая даст максимальную ценность в текущей категории задачи, не потратив при этом весь бюджет на оставшиеся раунды.

Tim Burton: лонгрид про фильмографию режиссера

Посмотрите на атмосферный лонгрид который сделала Настя Давыдова.

В основе рассказа о Тиме Бертоне — сюжеты из его фильмов и иллюстрации героев. Посмотреть проект можно на .

Higgsfield выпустили плагин для Photoshop

Теперь можно:

– Превращать скетч в готовое изображение в реальном времени по мере рисования
– Разбирать любое изображение на редактируемые слои
– Менять стиль фотографии через пресеты или текстовый промпт

По сути, весь AI-пайплайн для работы с изображениями теперь находится внутри Photoshop.

higgsfield.ai/plugins/photoshop

Карпатый написал 4 инструкции для Claude Code. Репа набрала 40к звёзд за пару дней

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

Раньше работа с агентом выглядела так: «попросил в чате, получил код, скопировал».

Теперь рабочий цикл другой:

👉 SKILLS.md фиксирует повторяющиеся паттерны: как пишутся миграции, как оформляются ошибки, какие соглашения по логированию
👉 AGENTS.md лежит рядом с кодом и описывает архитектуру директории: что здесь живёт, что нельзя трогать
👉 MCP подключает агента к вики, БД, API-докам через стандартный протокол

За полгода узкое место сместилось с возможностей модели на навыки разработчика. Скиллов нужно освоить много: SPEC-разработка, контекст-инжиниринг, Plan Mode, AGENTS.md под каждую директорию, мультиагентные пайплайны. Собрать всё это в рабочую систему самому займёт примерно год экспериментов.

Команда Naition.ai научит этому за 12 недель на своем онлайн-буткемпе.
Преподают практики из Google, Yandex Cloud, Сбера. 15 живых вебинаров по 3 часа: теория, разбор кейса, практика на своём коде:
• настраиваешь ИИ-окружение под свой стек — RAG, MCP, агенты, контекст
• начинаешь быстрее делать фичи — от идеи до внедрения с ИИ на каждом этапе
• собираешь набор ИИ-агентов, которые берут на себя часть задач (бек, фронт, аналитика, DevOps)
• и много другое!

Записаться

Старт: 5 мая.
По промокоду WEUSEJS — скидка 20%.

Бонус для участников первых когорт: 3 месяца в закрытом клубе после обучения.

Записаться

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

Меня недавно позвали в папку IT On и я согласился почти не раздумывая, потому что давно искал что-то похожее.

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

Читаешь и чувствуешь что находишься внутри IT, а не наблюдаешь снаружи. Разница есть, проверено на себе.

Добавляй папку себе, советую!

Anti-corruption layer на фронте: зачем адаптеры между API и UI

Принято считать, что фронтенд просто берёт данные из API и рисует интерфейс.

На практике это быстрый путь к тому,
чтобы внешний контракт начал диктовать архитектуру UI.

В чём проблема

API почти никогда не совпадает с тем,
как думает интерфейс.

Бэкенд может отдавать:

👉 странные названия полей
👉 лишние вложенности
👉 nullable там, где UI ждёт значение
👉 статусы в формате, удобном серверу, а не экрану

Если тащить это напрямую в компоненты,
UI быстро заражается чужой моделью.

Что делает anti-corruption layer

Он ставит прослойку между API и приложением.

Не компонент получает сырой ответ,
а адаптер превращает его в нормальную фронтовую модель.

function mapUserDtoToUser(dto: UserDto): User {
  return {
    id: dto.user_id,
    name: dto.full_name ?? 'Unknown',
    isAdmin: dto.role === 'admin',
  }
}

Компоненту уже не нужно знать,
как именно бэкенд назвал поле.

Почему это важно

UI становится чище

Компоненты работают с понятной моделью,
а не с набором компромиссов из API.

Изменения API дешевле

Поменялся контракт —
меняем адаптер,
а не ищем user_id по всему проекту.

Меньше бизнес-логики в JSX

Все эти проверки:

user?.profile?.data?.attributes?.name

не должны жить в компоненте.

Компонент должен рендерить состояние,
а не расшифровывать ответ сервера.

Где адаптер особенно нужен

👉 API старое или нестабильное
👉 несколько источников данных
👉 разные форматы одной сущности
👉 сложные статусы и enum
👉 много nullable-полей

Чем грязнее внешний мир —
тем полезнее слой нормализации.

Где можно не усложнять

Если проект маленький,
API стабильное,
а модель почти совпадает с UI —
отдельный слой может быть лишним.

Не нужно строить enterprise там,
где достаточно одной функции рядом с запросом.

Главная мысль

Anti-corruption layer — это не архитектура ради архитектуры.

Это защита UI от чужих компромиссов.

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

⁣CSP, CORS и security headers — что фронтендер обязан понимать глубже

Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».

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

CORS — это не про «разрешить запрос»

CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».

Но по сути это механизм, который говорит:
кто имеет право читать ответ.

Важно понимать:

👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ

Именно поэтому:

👉 Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра
👉 credentials + wildcard — запрещённая комбинация

CORS — это про контроль доступа, а не про обход ошибок.

CSP — ваш последний рубеж

Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.

Пример:

Content-Security-Policy: default-src 'self'; script-src 'self'

Что это даёт:

👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак

Но есть нюанс.

Если CSP выглядит так:

script-src * 'unsafe-inline' 'unsafe-eval'

Это не защита. Это иллюзия.

Security headers, которые реально важны

👉 X-Content-Type-Options: nosniff
Браузер не пытается угадать тип файла. Меньше атак через подмену.

👉 X-Frame-Options / frame-ancestors
Защита от clickjacking.

👉 Strict-Transport-Security (HSTS)
Принудительный HTTPS. Без вариантов.

👉 Referrer-Policy
Контроль того, какие данные уходят при переходах.

Где фронтендер влияет напрямую

👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные

Можно иметь идеальный бэкенд и сломать всё на уровне UI.

Частая ошибка

«Мы включили CSP — значит всё ок».

Но:

👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля

В итоге защита есть только на бумаге.

Главная мысль

CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.

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

Кошмар вайбкодера

xCode Journal