tgindex

Павел Шерер

описание

О продуктах, логике и здравом смысле. https://sherer.pro По всем вопросам @mashavanassi По остальным вопросам @sherer_pro

← к каналу@shererpro
1 305
подписчиков
Охват к подписчикам
46,8%
ERR
Реакции к просмотрам
1,87%
229 на 20 постов
Пересылки к просмотрам
1,43%
175
Постов в день
0,0
всего 20

Где отзываются чаще

доля реакций к просмотрам
  • 9 июл.Решил я поставить эксперимент: запилить редизайн своего сайта полностью на Open AI Codex. Без дизайна, референсов и единой строчки самостоятельно написанного кода. Ну а где редизайн, там и с нуля написанная тема, современная и с кучей плюшек, которые я раньше закрывал сторонними плагинами. Задачка не особо простая, как мне тогда казалось. Сказать, что я охренел будет слишком мягко. Всего за 4 вечера шаблон был полностью готов, покрыт тестами и успешно развёрнут на локальном сервере (на прод залью чуть позже, пока вот вам скрины). Из интересного: я специально писал промпты на естественном языке, только иногда добавляя что-то специфическое, типа веб-сокетов в админке или детали по 2FA. Я не просил его о простых вещах, типа «подвинь вот этот блок» или «поменяй шрифт», только общие команды. Например вот такие: Внимательно изучи все страницы и объекты сайта с точки зрения UX и UI: - Главная страница - Страница блога - Запись блога - Страницы со списком питомцев - Отдельная страница питомца - 404 страница - Остальные страницы и разделы Тебе нужно проверить: - консистентность схожих элементов и блоков; - сетки, отступы, границы и тп; - качество цветовой схемы; - доступность: контраст, наличие элементов и атрибутов для скрин-ридеров; - удобство использования; - наличие, качество и плавность анимаций; - качество и оправданность выбранных дизайн-решений; - прочие аспекты UX и UI. После оценки составь план (в том числе, исходя из реальных интерфейсов в браузере), исправления всех недостатков, которые найдёшь. Задай все необходимые вопросы перед тем, как составлять финальный план. или такие: Нужно доработать механики таксономии «серия»: 1. На внешней части в секции .sherer-post-series.series показывать неопубликованные статьи серии с пометкой «coming soon». Они должны быть некликабельными, серыми. 2. Для каждой статьи в серии должно быть можно указать порядковый номер — именно по нему будут сортироваться записи в блоке .sherer-post-series.series. Если номер не установлен, то сортировки происходит по дате публикации. 3. Проставь автоматически всем записям во всех сериях порядковый, исходя из даты публикации (можно прямо в БД). или даже такие: Нужно добавить маленький плавающий баннер внизу страницы «Сайт использует куки» с кнопкой «Мне плевать». По клику на кнопку баннер скрывается и больше в этом экземпляре браузера не показывается (через cookies или local storage). Баннер должен быть совсем небольшой, чтобы не мешал чтению даже если пользователь его не скроет Да, без понимания, как оно вообще должно работать и без внятного образа результата — у вас, скорее всего, получится хуйня. Да, дизайн не сказать, что особо выразительный. Но тема получилась реально удобной и от её вида не текут кровавые слёзы. Кроме того, она делает сам сайт намного безопаснее — и без сторонних решений, расширяющих площадь атаки. А главное — это: - Быстро. Я бы сам такое писал месяц точно, если со всеми фичами. Но вероятнее, просто отдал бы на сторону. - Практически бесплатно. Я с лихвой уложился в «бесплатный» лимит кодекса, а раньше просто отдал бы 3-4 сотни дизайнеру с разрабом. - Удивительно, но это реально безопасно. Ни я, ни локальная модель, ни клод, ни тот же кодекс не смогли в итоговой версии найти ни одной уязвимости. В интересное время живём5,46%
  • 26 июн.Мой коллега и одновременно вундеркинд Гари недавно выложил довольно занимательную статью. Главная мысль в том, что фокус — это не «соберись блять». Это результат работы нейробиологии и архитектура среды: сон, питание, отсутствие лишних стимулов, нормальное рабочее место, понятные блоки работы и ритуалы входа/выхода. Настройка системы. Статья большая, но я в вас верю.5,14%
  • 22 июл.JTBD → Job Story → Иерархия целей → Opportunity Landscape → Personas → Механика → User Story → Проверка результата Новая статья в цикле про персон и JTBD. Теперь о том, почему даже приличная User Story может аккуратно описывать совершенно не ту задачу. Команды часто путают потребность с механикой: пользователю якобы нужен дашборд, уведомление, автоскейлер или очередная форма. Хотя на самом деле ему нужно, чтобы продукты не заканчивались, проект не падал, а важная информация не терялась. На сквозном примере разбираемся, как перейти от ситуации «я выпал из проекта и потерял контекст» к конкретной и проверяемой User Story — не влюбившись в решение раньше времени. Шарьте4,23%
  • 29 июл.Ну что, доживаем последние деньки в телеге, как считаете? Пока ещё всё работает, хочу вам сообщить о хорошей новости: я снова объявляю набор на менторство. Больше года прошло со времени последнего набора, у меня стали освобождаться слоты — посему велкам. Почему менторство, что это, какие условия и что что я могу дать — тут и ниже. Делитесь, наверняка кому-то окажется полезно. UPD: пишите @mashavanassi, она организует первую встречу3,09%
  • 28 июн.Голоса разделились поровну. А посему правом, данным мне мной же, выношу решение в сторону онлайн-встречи. В ближайший четверг, 02.07, в 20:00 МСК. Ссылку на Телемост скину ближе к дате. Обсуждать будем, как обычно, продукты, дизайн и управление: на этот раз с упором на исследования и прогнозирование в наступающий век AI. Будет полезно дизайнерам с аналитиками, исследователям и продактам. Шарьте всем причастным2,91%
  • 5 авг.Завтра общий сбор, проверьте календари2,85%
  • 9 июл.Ну и вот вам ещё парочка пропмтов, которые я использую с Codex регулярно. Каждый из них, разумеется, нужно допиливать под конкретную задачу и особенности проекта. В одно сообщение не влезло, ловите несколько: AGENTS.md # Задача Создай (или обнови) в корне репозитория файл AGENTS.md, который станет исчерпывающей шпаргалкой для дальнейшей автоматизации. Документ должен рождаться из самого кода: прежде чем писать, проанализируй структуру проекта, конфигурационные файлы и историю коммитов. ## Как работать Сначала собери контекст. Просмотри: * файлы, явно задающие правила (например package.json, composer.json, pyproject.toml, Makefile, docker‑compose.yml, .github/workflows); * настройки тестов и линтеров; * историю git, чтобы понять фактические соглашения именования и частоту используемых команд. Затем построй черновик, где каждый раздел отвечает на вопрос «как мне сэкономить время при следующем вызове». Проверь, что в финальной версии нет лишних подробностей (избыточных для автоматизации) и отсутствуют недостающие шаги, без которых агент начнёт задавать уточняющие вопросы. ## Что обязательно описать ### Навигация по коду Укажи точки входа (bin‑скрипты, запуск приложения, тестовый раннер) и пути, которые можно смело игнорировать (скомпилированные артефакты, временные каталоги). ### Повторяемые команды Приведи стандартные команды для запуска тестов, линтеров, миграций, сборки образов и развёртывания. Добавь примечания, когда нужны переменные окружения или специфические флаги. ### Соглашения о стиле Опиши реальные, а не декларируемые правила: табы или пробелы, максимальная длина строки, формат сообщений коммита. Если настроены автоформатеры (pre‑commit, black, prettier) — укажи их конфигурацию и команды. ### Ограничения и переменные среды Зафиксируй минимальные версии интерпретаторов, набор обязательных переменных окружения и значения по умолчанию, безопасные для локального запуска. ### Зависимости и менеджеры пакетов Перечисли используемые менеджеры (npm, pipenv, poetry, go modules) и типовые сценарии: установка, обновление, аудит. ### Система CI/CD Расскажи, какой pipeline собирает проект, какие проверки считаются обязательными, где находятся конфигурации workflow и как локально воспроизвести сборку. ### Расхождения и подводные камни Отметь известные проблемы (например, нестабильные версии зависимостей, необходимость ручного патча) и предложи безопасные обходы. ### Полезные ссылки Дай точечные ссылки на внешние руководства, если они экономят время (например, политика версионирования или дизайн‑система). ### Информацию о локализации (переводе) строк Если применимо, укажи механики локализации и место хранения переводов. ### Обязательно добавь о необходимости обновления AGENTS.md в случае, если в репозитории произошли какие-то изменения в перечисленных пунктах. ## Финальное действие Сформируй AGENTS.md, сохрани в корне репозитория, зафиксируй коммит с сообщением «docs: bootstrap AGENTS.md». В комментарии к коммиту коротко опиши, какие данные были автоматически обнаружены, а какие добавлены эвристически.2,07%
  • 4 июл.Неплохой выпуск моей любимой Подлодки про найм в эпоху AI: как процесс поменялся и продолжает меняться, какие специалисты становятся востребованны, а каким пора изучать работу кассового аппарата в Пятёрочке. Довольно сильно пересекается с темой нашей последней встречи. Рекомендую всем, кто нанимается или нанимает2,01%
  • 9 июл.ARCHITECTURE.md # Задача Создай (или обнови, если уже существует) файл `docs/ARCHITECTURE.md`. # Вводные `ARCHITECTURE.md` — это живой архитектурный документ, описывающий текущее фактическое состояние системы. Это не vision-документ и не roadmap. Он фиксирует реальную архитектуру, отражённую в коде и инфраструктуре. # Требования к содержанию `ARCHITECTURE.md` Документ обязан содержать следующие разделы: 1. System Overview – назначение системы – ключевая бизнес-цель – границы системы (что входит и что явно не входит) – основные внешние акторы и интеграции 2. Architectural Context – тип архитектуры (монолит, модульный монолит, микросервисы и т.д.) – среда исполнения (runtime, инфраструктура, deployment-модель) – основные технологические стеки 3. Subsystems and Responsibilities Для каждой подсистемы: – название – ответственность – публичные интерфейсы – зависимости – что она не должна делать 4. Interactions – логическая схема взаимодействия подсистем – направление зависимостей – синхронные / асинхронные взаимодействия – точки интеграции с внешними системами Описание должно быть логическим и архитектурным, без BPMN и без избыточной детализации бизнес-процессов. 5. Data Architecture – основные доменные сущности – границы владения данными – источники истины – политика кэширования (если есть) 6. Key Technical Decisions – принятые архитектурные решения – их причины – зафиксированные компромиссы – допущения 7. Constraints – технические ограничения – инфраструктурные ограничения – нормативные или внешние ограничения 8. Extension Points – предусмотренные точки расширения – места, где допустимо добавлять новые модули – зоны, требующие осторожности 9. Architectural Invariants Перечень принципов, которые запрещено нарушать. Это должны быть чёткие, проверяемые правила. # Правила описания – Документ описывает текущее состояние кода, а не желаемое будущее. – Если что-то не реализовано — не описывать это как существующее. – Не использовать расплывчатые формулировки («гибкая», «масштабируемая» без пояснения). – Не дублировать README. – Не описывать бизнес-функциональность вне архитектурного контекста. – Не фантазировать о механиках, которых нет в коде. # Консистентность Перед созданием/обновлением документа: – проанализируй текущую структуру репозитория – определи реальные модули и зависимости – зафиксируй их как есть Документ должен быть согласован с кодовой базой. # Обновление AGENTS.md Обнови файл `AGENTS.md`, добавив: 1. Правило, что `docs/ARCHITECTURE.md` является единственным источником истины по архитектуре системы. 2. Обязанность агента: – при любом изменении, затрагивающем архитектуру (структура модулей, зависимости, интеграции, инфраструктура, доменные границы), обновлять `ARCHITECTURE.md` в том же коммите. 3. Запрет на архитектурные изменения без обновления документа. 4. Если архитектурное изменение невозможно корректно отразить в `ARCHITECTURE.md`, агент обязан: – явно указать это в комментарии к изменению – объяснить причину – предложить способ корректного отражения # Запрет дублирования – Архитектурные описания запрещено дублировать в других документах. – Все архитектурные разделы в других файлах должны ссылаться на `docs/ARCHITECTURE.md`. # Дополнительно Если файл уже существует: – не переписывать его полностью без причины – сохранить структуру, если она логична – обновлять только несоответствующие или устаревшие разделы # Результат После выполнения: – `docs/ARCHITECTURE.md` отражает реальную архитектуру – `AGENTS.md` закрепляет дисциплину поддержки архитектурной документации1,85%
  • 9 июл.Общий анализ Внимательно проанализируй содержимое репозитория на предмет: - Наличия потенциальных уязвимостей и слабых мест в безопасности. - Качества общей архитектуры и программных решений. - Согласованности функций, компонентов, модулей, методов API и прочего. - Наличия избыточной и дублирующей функциональности и логики, методов API и прочего. - Идемпотентность операций (API, БД, кэш и прочее). - Оптимизации и быстродействия. - Cоответствие файлов окружения `.env.*`. - Полноты и качества документирования проекта, соответствия документации текущей версии кода. - Соответствия файлов ARCHITECTURE.md, README.md и AGENTS.md коду и архитектуре. - Консистентности документации проекта, наличия дубликатов в файлах документации. Старайся ничего не упустить. Создавай подробный план исправления. Проработка UX Внимательно изучи все страницы и объекты сайта с точки зрения UX и UI: - Главная страница - ... - 404 страница - Остальные страницы и разделы Тебе нужно проверить: - консистентность схожих элементов и блоков; - сетки, отступы, границы и тп; - качество цветовой схемы; - доступность: контраст, наличие элементов и атрибутов для скрин-ридеров; - удобство использования; - наличие, качество и плавность анимаций; - качество и оправданность выбранных дизайн-решений; - прочие аспекты UX и UI. После оценки составь план (в том числе, исходя из реальных интерфейсов в браузере), исправления всех недостатков, которые найдёшь. Задай все необходимые вопросы перед тем, как составлять финальный план.1,74%
  • 19 июн.Количество людей, которые утверждают, что закон Мура больше не работает, удваивается каждые 24 месяца (с). Скоро поговорим об исследованиях и прогнозировании. Как они поменялись (и ещё поменяются) с приходом AI.1,68%
  • 6 авг.Залетаем https://telemost.yandex.ru/j/5576120574 Темы: UX, системный дизайн, ai-аненты и всякое такое1,39%