Прикрутил тут я к Доктуристу тёмную тему. База была заложена еще во время редизайна, но сразу делать не стал, а то никогда бы не закончил.
Настройка трехпозиционная: всегда светлая / всегда тёмная / как в системе (то есть у браузера спрашивает, что показывать). Выглядит вроде ок, мне нравится, фидбэка от пользователей пока не получил.
Но тёмная тема немедленно начала провоцировать меня на тёмные мысли. Потому что что тут вообще скажешь? Прикрутил и прикрутил. Чего тут вообще интересного для айтишечного блога? Код, как у браузера спросить какие он цвета предпочитает? Как набор цветов в переменные фронта добавить и пользовательский выбор в localStorage положить?
Ответ-то на всё один: чат жопотэ, сделай мне тёмную тему для сайтика. Чат жопотэ, плашки слишком светлые, и форму редактора ты забыл покрасить гуталином. А, вот так да, хорошо. Запусти тесты. Гоу прод.
Как писал в апреле и упоминал потом на митапе, статейки про программирование должны как-то переродиться. Незачем больше это писать, потому что незачем это читать. Надо писать что-то другое, и это другое видимо сейчас бурлит и формируется где-то. Потому что нельзя же вообще ничего не писать.
P.S. Пока писал эту заметку, зашел в чатик по Ларавелу. А там несколько живых человеческих людей живо обсуждают как прикрутить A к B к C. Может не так уж всё и печально.
Обновление такой чудовищной критичности, что никаких деталей не раскрывают, чтобы заранее не взломали вообще всех.
Так что заготавливаем консольки, открываем докер-конфиги и вперёд, обновлять всё по кругу.
Но если уязвимости и обновления так и будут сыпаться, как из рога изобилия, придется когда-то уже действительно пускать на проды роботов и пусть они там сами. Иначе как это всё успевать-то?
На днях PR на 610 файлов был окончательно повержен и смерджен! На выходе получился полный редизайн Доктуриста. Наружной части (лендинга и блога) немного тоже, но в первую очередь — всего внутряка. Всех страниц, форм и диалогов самой crmки.
Это еще один пример как можно увлечься, решая задачи с нейросетью. Изначально идея была значительно скромнее. Дэшборд, он же рабочий стол, он же главная страница внутри системы — был сделан довольно простеньким. Вот так он выглядел:
Конечно, турагенты сообщили, что виджетами этого стола не пользуются совсем. Только ссылками, чтобы сразу прыгнуть в нужный раздел. А хотелось чтобы это был скорее быстрый доступ к важным разделам и информации. Чтобы некоторые вещи вообще можно было сделать, не уходя с дэшборда.
Вот этим мы с клод-дизайном и занялись. Переосмыслили содержимое дэшборда с целью сделать его удобным и используемым, а не просто местом для ссылок как рабочий стол в win95. И вышеприведенное «было» превратилось в новое «стало»:
Тут уже и показатели всякие, и главное лента с броньками более умная. Хочешь, смотри последние брони по дате, хочешь — требующие определённого внимания.
Сдерживать оформительские порывы Клода я не стал, поэтому в нагрузку получил сразу и новый стиль. Предыдущий стиль делался на теме color admin, которую я в 2018-м специально покупал. Тема, конечно, с тех пор несколько состарилась и подрастеряла актуальность.
Так или иначе, когда есть новое оформление — остальные страницы оставлять в старом не хочется. И так, страничка за страничкой, компонент за компонентом мы сначала с Claude Design, а затем с Claude Code привели весь сервис к новым стилям. А поскольку просто так перерисовывать скучно, то заодно переосмыслили, доработали и переделали компоненты на страничках.
Вот и получился PR на 610 файликов. Который я конечно умотался проверять и тестировать. И в целом тезисы моего доклада на эту тему сохраняются. Надо тестировать, структурировать, декомпозировать. А вот не смотреть на нейрокод по заветам Роберта Мартина пока еще не получается: я проверял каждый экранчик — смотрел изменения, тесты, фронт, и в каждом находил что что-то было сделано не совсем так, или не работало, или влекло проблемы какие-то новые.
Но в конечном итоге всё проверил, погонял руками и залил. Так что теперь у нас в Доктуристе не только новый, переосмысленный, современный дизайн, но и всякие юзабилити-мелочи, в том числе:
— Доктурист запоминает и сразу показывает набор операторов, с которыми часто работает агент, не нужно каждый раз искать по автодополнению.
— / или Ctrl+F немедленно включают поиск по всем данным (повторный Ctrl+F включает нативный поиск).
— Документы по брони можно сгенерировать и подписать прямо из всплывашки с рабочего стола, необязательно в бронь проваливаться.
— Улучшена работа календаря на мобильных устройствах (мобильный календарь просто сделан заново).
— Страница профиля наконец-то разделена на 5 секций по соответствующим тематикам настроек.
Результатом доволен, теперь обновления снова можно выкатывать чаще, не проверяя такие большие PRы. В целом редизайн занял где-то полтора месяца. Теперь на очереди интеграция сервиса онлайн-касс (уже готова) и тёмная тема (уже тоже). Работаем!
Вчера считал эстимейты на группу из ~40 тикетов. Все сделаны по отчету ИИ об анализе кода большого проекта на Drupal. Проекту около 10 лет, кодовая база развивалась все это время, 20 поддоменов, интеграции, апишки, синхронизация контента, в общем прикольный проект.
Отчет структурированный, нейросеть проверяла всех четырёх всадников попокалипсиса в проекте: Уязвимости, Баги, Тормоза и Грязный код. Изначально из переданного отчета получалось гораздо больше задач, но процентов на 30% я сразу won't fix навесил. Там и глюки нашлись, и непонимание контекста. Но 40 тикетов тем не менее осталось.
Среди них тоже в основном таски с минимальнейшим приоритетом, типа
в кастомном модуле не проставлена зависимость от чего-нибудь типа paragraphs;
где-то в коде наглый программист вызвал \Drupal::service() вместо инъекции зависимостей;
где-то deprecated-версии Друпала не убраны из поддерживаемых версий и тому подобное.
Нашлось и несколько более серьезных претензий:
парочка проблем N+1;
несколько XSS-уязвимостей (доступных только админам, но всё же);
несколько мест, где отсутствуют проверки на наличие ключа в массиве (спамит в лог предупрежденими);
и даже одна уязвимость типа timing oracle.
Да, грязненький код — признак грязненьких мыслей :) Да, хорошо бы всё это почистить. Но за вычетом 3–4 претензий, это получается больше ста часов работы суммарно, а выхлоп — немножко более чистый код, причёсанное legacy, немножко меньше техдолга и warning/debug-записей в логе. Хорошо конечно, когда заказчик не против провести такую генеральную уборку. И честь и хвала аккаунтам, которые могут убедить заказчика в необходимости такой уборки при примерно нулевой ценности для конечного пользователя.
А ощущения от таких отчетов по-прежнему странные. Вроде и находит что-то. Но суеты с этими отчетами пока куда больше, чем пользы.
Когда-то давно описывал довольно простой способ виртуализации проектов, над которыми работаю, чтобы было удобно переключаться и они друг другу не мешали. Прошло уже 7 лет и способ конечно эволюционировал. Когда-то использовать отдельные контейнеры, запускаемые по `docker run` было быстрее и удобнее и поэтому я докерфайлы и docker-compose-файлы не писал. Но прогресс конечно добрался до меня в этом вопросе и победил. Теперь я для локальной разработки тоже использую docker compose.
Инструментами со всякими пресетами типа lando или ddev я, тем не менее, стараюсь не пользоваться. В основном потому что когда с ними сталкивался, они нормально работали — до тех пор пока не надо было что-то в них поменять или сделать нестандартно. После чего начинался вынос мозга, иногда такой, что проще было самому пересобрать сразу.
Кроме того, если собирать «чистые» окружения, есть шанс лучше понять, как это всё работает, а если пользоваться lando, forge, ddev и прочими — наоборот.
Достаточно давно занимаюсь с сыном изучением C# через создание игр в Unity. До этого пробовали Scratch (слишком просто и немного скучно) и Lua с Роблоксом, тоже не зашло. Наверно, ввиду ограниченности применения.
В общем, взялись за игры в Unity и, посмотрев пару-тройку видеоуроков, решили что лучше по учебнику. Купил «Unity и C# Геймдев от идеи до реализации» Джереми Гибсона Бонда. Быстренько прочитал сам и стали заниматься.
Автор, как я понял, преподаёт геймдев в Калифорнийском универе, ну или что-то типа того, не вникал.
Книжку можно разделить на три части:
Некоторая теория и философствования на тему геймдизайна. С точки зрения занятий с детьми часть не очень полезная, но в целом почитать интересно. Вероятно тем кто хочет стать геймдизайнером — может быть полезно.
Теория по программированию на C#. Тут всё как обычно, разбор основных принципов программирования: hello world, переменные и типы данных, циклы, условия, классы и наследование. Учебные примеры, чтобы не заморачиваться, исполняются сразу в Unity.
Разработка игр. Добрая половина книги — после теории — посвящена настоящей разработке настоящих игр. Каждая глава описывает пошагово разработку отдельного прототипа игры с рабочим играбельным результатом в конце. По учебнику можно создать 7 разных игр, в том числе скролл-шутер, пасьянс, клоны Angry Birds и даже старой The Legend of Zelda.
Автор дает как концепции кодинга под Unity, так и использования Unity Editor для создания префабов. Причем, в основном автор создает объекты, пользуясь возможностями самого редактора, а не загружает модельки откуда-то еще.
Обычно основная проблема бумажной литературы о современных технологиях — ты еще не успел купить книжку, а данные в ней уже устарели. Но в данном случае примеры на удивление актуальны. Расхождения с текущей версией Unity есть конечно, в части текстовых лейблов на экране, в части работы с XML, но учитывая год издания (2021) их довольно мало: запускается сразу как в примерах почти всё.
Некоторый матан в книжке (кватернионы, кривые Безье и т.д.) детям объяснить сходу не получится. Но основную суть ухватить они вполне могут. В любом случае, по книжке лучше конечно заниматься с взрослым, который немного шарит.
Еще отмечу, что некоторые паттерны, применяемые автором, на взгляд программиста из другой отрасли могут показаться сомнительными. Но возможно это упрощение для учащихся. Ну или в настоящем геймдеве есть причины так делать — мало ли.
В целом книжку рекомендую всем кто хотел бы попробовать овладеть базой создания игрушек под Юнити, или обучить детей программированию. В отличие от отдельных видеороликов, книжка подходит к вопросу более системно, охватывает более широкий спектр тем и дает направления для дальнейшего изучения.
На первом приложенном видео — скролл-шутер, который мы написали по учебнику. На втором — результат упражнения по завершающей теоретическую часть главе. Это стая птиц, которая красиво летит за неким объектом, «роится», но при этом не сталкивается. Управлять ей нельзя, но можно регулировать параметры (скорость, количество птиц и т.д.) Это упражнение сын уже написал по книжке без меня.
В последнее время все чаще и больше в разработке использую генеративные нейросети в агентском режиме, для простоты будем называть это как все, вайб-кодингом. Ну а чего? Сейчас каждый утюг и его бабушка вайб-кодят и рассказывают о том, как это стало здорово. И в плане доступа к разработке тех, кто раньше разрабатывать не умел, это, кстати, действительно здорово.
Но кто и раньше умел разрабатывать сам, всё-таки смотрит на предмет немножко под другим углом. Поэтому решил немного растечься мыслями, поворчать, позанудствовать и поразмышлять не о том, как настроить Codex, MCP-сервер, или натравить Claude Code на KWork. А об эффектах, о неизбежных изменениях, которые внесли, вносят и будут вносить в нашу повседневную работу — в разработку программного обеспечения живыми человеческими людьми — нейросети.
Сначала коротко определим наше место в пространстве и времени относительно самого феномена нейросетей (здесь и далее — в разработке ПО). Обсуждать, нужны ли они, помогают ли они, следует ли их использовать — уже поздно. Этот вопрос больше не стоит. Если вдруг еще не начали, надо начать. Кот смотрит на часы и говорит — Пора!
Если вы живёте за городом, обязательно нужно вайб-кодить. Особенно зимой.
Я тут как-то завёл себе подписку на Claude Code, и он довольно здорово работает. Описал задание, выставил нужные разрешения, чтобы он без лишних вопросов работал, запустил. И всё, можно идти на улицу чистить снег. Если снега много, можно и сразу несколько заданий выставить.
Последнее время использую Клода в хвост и в гриву. Судя по регулярным сообщениям о превышении дневных и недельных лимитов — интенсивнее уже некуда.
Чтобы лимитов хватало чуточку побольше, пользуюсь таким простым методом.
Сначала завожу проекту файлик CLAUDE.md, в котором описываю полезную для иишечки информацию о проекте. Какие технологии, методики, тесты, как почистить кэш и где найти нужные контейнеры. Этот файл принимается нейросетью к сведению при старте каждой новой сессии. В принципе, можно и Клода попросить составить этот файл командой /init, но он понимает сходу о проекте не всё.
MD — это Markdown, удобный способ форматирования текста в обычных текстовых файлах. Удобный и роботам, и человекам.
Затем пишу отдельные md-файлы с задачами. Описываю цель задачи, детали, дополнительную инфу.
Затем перевожу Клода в режим планирования и говорю: прочитай файл с задачей и составь детальный план её реализации.
Читаю получившийся план, перещелкиваю в режим с авто-правками, запускаю и иду чистить снег.
Некоторые рекомендуют явно просить иичко записывать прогресс выполнения плана в отдельный файл, чтобы потом вернуться в случае сбоя. Но насколько я заметил, он под капотом и так всё в файлы пишет и проблем продолжить прерванную сессию не возникает.
Когда клод закончил и снег закончился, всё написанное нужно проверить вручную, отладить и закоммитить. Про эту часть напишу в следующий раз.
Как упомянул выше, дневные и недельные лимиты иссякают быстрее, чем хотелось бы. Чтобы немножко токенов сэкономить и чуть-чуть продлить беззаботный вайб-кодинг, рекомендую после пары-тройки выполненных задач посмотреть на лог сессий самому, или даже попросить агента порефлексировать. А именно: обновить по логам содержимое CLAUDE.md. Зачастую агент поначалу тупит и не сразу понимает, какой в точности командой правильно запустить тесты, или что не нужно лезть в контейнер, чтобы собрать фронт-энд.
Вот эти команды надо скорректировать, записать в CLAUDE.md тот вариант, с которым агенту удалось справиться с задачей. Чтобы он в каждой новой сессии не перебирал варианты заново.
Попользовался и консольным claude, и плагином в VS Code. Консольный поприкольнее, больше возможностей и команд всяких. К тому же его можно с отключенными проверками запустить — чтобы он не спрашивал, можно ли выполнить rm -Rf *, а сразу делал. Но и плагин тоже ничего. Работает и там, и там иишечка на совесть, месячная подписка, я считаю, окупилась в первые 3 часа использования.
В общем, хорошего вам снежного вайб-кодинга! Ну а летом достанем газонокосилку и займемся вайб-дебагом.
В Ларавеле из коробки (ну, почти из коробки) есть поддержка отправки сообщений на вебсокетах, что бывает довольно полезно. Например, когда мы из фронта просим сервер выполнить длительную операцию, и не можем, или не хотим ждать её окончания. А вот узнать, когда она закончится — наоборот, очень хотим. Для чего нам нужно получить от сервера обратную связь. В эру палеолита для этого каждый клиент опрашивал сервер раз в секунду до получения ответа (или до полного изумления сервера). Но теперь у нас есть вебсокеты, с ними проще. Можно передать с сервера результат отложенной операции, можно сделать уведомления о действиях других юзеров, или просто чатик сделать даже. Почитать про это можно в документации на Laravel Broadcasting. А далее мы рассмотрим нюансы первоначальной настройки Laravel Reverb для этого самого броадкастинга.
Вчера перед сном решил — а ну-ка сейчас за 20 минут добью большую фичу. Долго делал, чуть-чуть осталось. Сел, открыл, и правда — через 20 минут фича была готова. Но чёрт меня дернул запустить после этого все тесты. Пока фичу делал — смысла не было запускать весь пакет. А тут, в ночи, решил запустить.
И конечно как посыпались ошибки! Пару простых исправил, и оказалось, что все остальные — потому что сломался поиск. У меня в проекте используется Laravel Scout для быстрого поиска-автодополнения по нескольким типам моделей одновременно, чтобы было удобно искать что угодно. И вот он сломался сразу весь. Абсолютно все поиски возвращались пустыми.
Посмотрел на проде — всё еще работает. Стал разбираться, чего такого я мог сломать. Отключил несколько установленных библиотек — вдруг конфликт у трейта Searchable с чем-нибудь. Включил обратно ту, которую наоборот — стёр за ненадобностью. Не работает.
Откатил контроль версий на точку до начала разработки фичи. Не работает! Подозрительно как-то. Накатил обратно. Обновил зависимости. Не работает.
Поотлаживал классы Скаута — увидел, что почему-то драйвер поиска определяется как null (то есть никакой)! Полез смотреть, оказывается у меня внезапно в .env прописано SCOUT_DRIVER=null! Хотя я просто полагался на дефолтное значение из конфига scout.php (который не менялся), и в .env вообще драйвер не прописывал.
В общем, непонятно, кто такое сделал-то — то ли один из устанавливаемых пакетов в ходе vendor:publish проявил инициативу. То ли я зачем-то выставил, хотя никакой пользы от этого не припоминаю. То ли нейросеть, которую тем более об этом не просили.
В общем, пока нашёл ошибку и вернул нормальный драйвер, прошло уже конечно в разы больше 20 минут. Зато в конце увидел все тесты зелёными. На чем и ушел спать, вот только
Отправить письмо
На нашем сайте используются куки-файлы, потому что без них всё плохо работает. А с ними — хорошо. Нажмите на кнопку «Согласен», если согласны с условиями обработки куки и данных на сайте. Если не согласны, можете отключить куки в настройках браузера.
