Вы наверное слышали про новый редактор кода Курсор со встроенным ИИ. Я даже слушал подкаст с его авторами несколько месяцев назад. Он умеет и писать новое по команде, и вносить изменения в старое, и отвечать на вопросы о коде. Описание меня одновременно и восхитило, и ужаснуло: ну как можно доверить большой сложный проект этой штуке? Он же там всё сломает!

Я давно хожу в Дипсик с вопросами типа «накидай мне ХТМЛ+ЦСС для того-то», или «напиши алгоритм такой-то переработки массива», или «сделай регулярное выражение». Это что-то вроде продвинутого поиска в интернете, но вставляю-то результат я в свой код только сам.

В общем, оказалось, что Курсор — это совсем не страшно, рекомендую всем.

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

Дальше его можно просить о чём хочешь, он будет что-то предлагать, и при этом показывать, какие изменения он будет вносить. Их можно принимать и отклонять, а можно попросить его что-то объяснить или додумать. Мне понравился такой момент: я попросил его доработать метод walk (), чтобы он передавал в колбек не только текущий элемент, но и предыдущий и следующий:

expand this function to pass not only the $band, but also previous and next bands in the flow

Курсор:

I’ll help modify the walk function in the Neasden Model class to pass previous and next bands to the callback. This will be useful for the decolon filter to properly check adjacent bands. First, let me search for the Model class to see its full implementation...

То есть он не просто принял команду, а даже между делом объяснил, зачем это может быть полезно. И это правильное объяснение! Я ровно за этим его об этом и попросил.

Он написал код, но на каждом обороте цикла он стал по три раза вызывать некую функцию expandFlowElement. Я попросил убрать это, он переписал. Я спросил:

is it worth it?

Курсор:

Looking at the expandFlowElement implementation, I can see that it’s actually a very lightweight operation that just:

1. For strings: Splits by newlines and wraps in a simple array structure
2. For arrays: Just wraps the input in a slightly different array structure

The operation is:

• Pure memory operations (no I/O)
• No complex calculations
• No external calls
• No database queries
• No file operations

Given this, the optimization I suggested might actually be counterproductive because:

1. It creates an additional array in memory ($expanded_flow)
2. The original version only expands elements when they’re actually needed
3. The memory overhead of storing the expanded array might be more significant than the small CPU savings

I would recommend reverting the change. The original implementation is actually more memory efficient since it only expands elements when they’re needed, and the CPU cost of the expansion is negligible.

Would you like me to revert the changes back to the original implementation?

Ну это разве не магия?

А вчера он мне помог ответить на письмо. Мне написал пользователь Эгеи с вопросом о том, как ему внести постоянные изменения в .htaccess, чтобы Эгея их не перетирала при обновлении. Я помню, что что-то такое вроде предусматривал, пишу Курсору:

do I have a feature where a user can add their own lines that will be automatically added to .htaccess file when I’m generatnig it

Курсор:

Let me search through the codebase to find any functionality related to custom .htaccess directives.

Yes, I can confirm that the project does have a feature for adding custom .htaccess directives. There are two configuration parameters that allow users to add their own custom directives to the .htaccess file:

• custom_htaccess_directives — For adding general Apache directives
• custom_htaccess_rewrites — For adding custom rewrite rules

These can be set in your config file (user/config.php). When the .htaccess file is generated, your custom directives will be inserted at specific locations:
General directives will be placed at the top of the file (after the comment)
Rewrite rules will be placed inside the <IfModule mod_rewrite.c> block, before the default rewrite rules

For example, in your user/config.php you could add:

$_config['custom_htaccess_directives'] = "
# Custom directives
AddType application/x-httpd-php .php
";

$_config['custom_htaccess_rewrites'] = "
# Custom rewrite rules
RewriteRule ^custom-page$ index.php?go=custom-page [L]
";

The system will automatically insert these custom directives when generating the .htaccess file, while preserving all the default functionality. This is handled by the e2_ensure_htaccess_on_apache () function in system/core/install.php. Note that the .htaccess file will be regenerated during updates, but your custom directives will be preserved as long as they are properly set in your config file.

Он всё понял, описал и даже примеры использования привёл! Ну я и ответил на письмо этим текстом.

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

Короче, я уверовал примерно за первый час.

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

Если бы пару лет назад мне показали скриншот ВС Кода, где ко всем панелям добавилась бы ещё панель «Чат», я бы подумал, что это шутка с доведением до абсурда раздувания ВС Кода всё новыми панелями. А вот оказалось, что совсем не шутка.

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

Так не должно быть: крутилка означает, что пользователь ждёт программу, а не программа пользователя. Здесь возникает двусмысленность: с одной стороны, написано «наведите», а с другой — снизу крутится крутилка, как будто программа ещё не готова, и пока рано наводить. И кому верить — непонятно.

Некоторые дизайнеры любят приносить по несколько вариантов дизайна, когда об этом не просили. Не надо так делать: это вызывает фрустрацию и недоверие.

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

В каких случаях несколько вариантов — это окей?

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

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

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

«Рано» и «поздно» — понятия относительные: можно менять часовые пояса, переводить часы, а границы светлого и тёмного времени суток вообще меняются в течения года в огромных пределах. Но жаворонки остаются жаворонками, а совы совами. Усилием воли поменять привычку можно, но долго она не продержится — одни будут ложиться всё позже, а другие вставать всё раньше. Почему?

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

Допустим, вы сделали интерфейс и какое-то объяснение спрятали за вопросик:

Вытащите информацию из-за вопросика, пожалуйста, и напишите её прямо тут.

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

Парижский Нотр-Дам сгорел из-за интерфейса. Датчик возгорания штатно и вовремя сработал, и сотрудник службы безопасности увидел на экране код: ZDA-110-3-15-1. Это идентификатор конкретного места, где сработал датчик — ценнейшее знание. Однако почти полчаса сотрудник искал, где же горит, потому что не знал, что значит код, а начальник не отвечал на телефон.

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

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

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

В случае с Нотр-Дамом цена такого мнения — миллиард долларов.

Я предлагаю принцип «Без обучения». Прям декларировать его как основу для всех принимаемых в дизайне решений. Я прямо отвечаю инженерам:
— Понимаю, но у нас в интерфейсах используется принцип «Без обучения». То есть мы делаем интерфейсы такими, чтобы как раз таки случайный человек мог подойти и выполнять работу. Да, без опыта он будет делать медленнее, но нужно добиться, чтобы он в итоге сделал всё правильно.

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

Очень важно настроить культуру разработки, чтобы сам этот довод «Сотрудники проходят обучение» не считался валидным. Считайте, что не проходят. Что тогда?

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

Мелодия — это простая и очевидная штука, она на поверхности. Её можно записать нотами, поставить рингтоном на Нокию и подпеть у костра. Тембр — это сложная и глубокая штука. Его никак не записать кроме как описанием волнового процесса.

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

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

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

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

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

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

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

Это и плохая статья, и плохая практика.

Что не так со статьёй

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

Дальше автор приводит примеры интерфейса, где результат отображается мгновенно. Он пишет: «such speed can make users skeptical or even confused» — «такая скорость может вызвать у пользователь скепсис или растерянность». Утверждение бессодержательно: может вызвать, а может и не вызвать; у каких-то пользователей вызовет, у каких-то нет. Или вот фраза: «Human brains expect things to take longer» — «Мозг человека ожидает, что вещи занимают больше времени». Утверждение не просто не доказано, оно недоказуемо. Сколько секунд занимают «вещи» по ожиданию мозга человека? Неужели это касается всех «вещей»? Как это вообще померить?

Нашлось в статье место и аналогии: «Let’s say you sit down at a restaurant, you order your food, and it comes out one minute later» — «Садитесь вы в ресторан, заказываете еду, и её вам приносят через минуту». Типа, раз ты тут заподозришь, что качество еды не очень, то и в интерфейсе при слишком быстром получении результата тоже засомневаешься в его качестве. Аналогия неудачная: если еду невозможно было приготовить за минуту, значит её просто разогрели; это не «ощущение», а понимание. Но если эспрессо тебе несут пятнадцать минут, вряд ли ты уверуешь в его высокое качество.

Что надо делать вместо шоу с замедлением

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

Слабый ответ — подстроиться под ожидания.

Сильный ответ — сделать хорошо и приучить к хорошему, перенастроив ожидания. Лучшие продукты превосходят ожидания, а не просто имитируют привычное-плохое.

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

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

Наконец, автор приводит пример переделки интерфейса заявки на ипотечный кредит. В первой версии он мгновенно выдавал заключение. Пользователи воспринимали мгновенное одобрение как «предварительное» и ожидали, что настоящее решение последует позже. Тогда дизайнеры добавили поддельный медленный прогрессбар, и пользователи стали «верить» результату! Хорошо, но при чём тут «особенности человеческого мозга»? У людей есть привычка, что в банках всё медленно. Статья американская, всё понимаю, но в России банки давно приучили людей к мгновенности всего. Мы на практике знаем, что если людям однажды показать, что что-то быстро, они перестанут ожидать, что это долго!

Да, с непривычки люди могут быть удивлены мгновенности ответа. Но кем надо быть, чтобы увидев такую реакцию, из всех решений выбрать именно «сделать медленнее»? Что мешает признать в интерфейсе удивительность этого факта, написав «Your loan has been instantly approved. What’s next: ...» — «Для вас кредит одобрен мгновенно. Что дальше: ...». Нужно сразу дать человеку то, что он ожидает увидеть после окончательного решения: документы на заполнение или назначение встречи в банке. Нужно взять пользователя за руку и повести, чтобы ему в голову не пришло, что надо чего-то ещё ждать.

Долгосрочные последствия шоу с замедлением

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

Все знают фразу Генри Форда, что если спрашивать покупателей, то они бы сказали, что им нужна более быстрая лошадь. И даже в случае Форда нормальное решение — не лошадь допингом кормить, а автомобиль конструировать. А у наших героев покупатели хотят более медленную лошадь, и они покорно делают! Точнее даже не так, всё ещё хуже. Покупатели даже не просят медленную, они просто удивляются быстрой, — и всё, продавец уже бежит делать медленную!

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

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

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

Когда шоу уместно

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

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

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

Номинальные 9 часов — это реально около 4 часов прослушивания. Во-первых, всё слушается как минимум на полуторной скорости, что уже превращает 9 часов в 6. Во-вторых, Оверкаст вырезает слишком длинные паузы между словами, а это очень существенно сокращает длительность всего. Когда отвечал Васе, я даже не знал, насколько, а это даёт в среднем ещё 1,4-кратное ускорение! Хотя зависит от особенностей говорящего, конечно.

Но 4 часа — это же всё равно много? Не знаю, в день я слушаю по ощущениями около 2 часов разного — лекций, подкастов, аудиокниг.

Во время еды получается минут 15-20, ведь еду надо приготовить или разогреть, съесть, потом убрать или помуть посуду. Это три раза в день — уже почти 1 час. Пока иду на кофе и обратно — это ещё 20 минут дороги (пока пью кофе я работаю).

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

А ещё перед сном минут 10 могу послушать в качестве сказки на ночь. А дальше, если я бегаю — это ещё плюс 30 минут. Если иду в бассейн — то ещё около 1 часа на дорогу туда-обратно, переодевания и занятия в спортзале перед заплывом (делаю там несколько упражнений). То есть минут 20 в среднем ещё дополнительно есть в день.

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

Вот и получается, что «9 часов» лекций про код — это пара дней без необходимости выделять хотя бы минуту специального времени.

Вот чего я реально не понимаю — так это как люди регулярно смотрят фильмы и сериалы.

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

Но я заметил, что давно уже совершенно автоматически делаю ⌘Z, ⇧⌘Z — анду и сразу реду. Это отменяет последнее действие и тут же делает его снова, то есть документ в итоге не изменяется. А зато курсор возвращается туда, где был до этого!