Work & Beer Balance

после третьего вылета за 20 минут мой эксперимент с Cursor IDE закончился =)

Решил я тут попробовать Cursor IDE (кто не в курсе - это такой vscode, но с полностью закрытым кодом, и нашпигованый аишкой по самые помидорки)
Но на Linux (Gnome) у меня задвоились заголовки окна (как на картинке).

Написал баш скрипт который скачает иде, и пофиксит ее, вдруг пригодится

Uber когда то выглядел вот так. Посмотрите какой простой и чистый интерфейс, им может пользоваться бабушка, уставший после работы человек, и я полагаю даже алкогольное опьянение не станет большим препятствием что б нажать кнопку "домой".
Но, к сожалению, все это было бездарно просрано

Ремарка на тему:
А бывает наоборот? Чаще чем хотелось бы. Многое научное ПО, и часто open source ПО с GUI - не может себе позволить или не считает нужным исследовать UX, и просто фигачат все фичи как безумные в бесчисленное количество панелек.
А потом индусы снимают видео длинной в несколько часов чтобы объяснить как сделать hello world проект.

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

Но как быть, нельзя же выкинуть из приложения все фичи и оставить только одну!

Приведу пример - представьте себе что пользователь ищет дорогу к решению своей проблемы. Например, ему нужно прийти в город Б. Каждая фича видимая с главной - это еще одна дорога на перекрестке сразу в начале его путешествия.
В магазин, в туалет, к лавочке в тени, к колонке с водой. Это фичи. Вместо того чтобы идти в город Б - пользователю надо стоять искать нужную дорогу и думать о остальных вариантах (может зайти в магазин купить в дорогу воды?), он отвлекается и фрустриуется. Это плохой UX, (хороший если вы Японец)

Будет лучше если UX дизайнер походит с пользователями по дороге и отметит место где пользователи обычно хотят попить, а где отлить, и на протяжении пути сделают соответствующие ответвления - это уже будет простой выбор (да/нет), и если вы угадаете момент правильно - обрадует вашего пользователя и оставит положительные эмоции.

Рассмотрим остальные - Twitter (x.com) в своем UX сделал тот же трюк. Все соц сети что я видел до него (майспейс, ЖЖ, Фейсбук, ныне покойная google+) предлагали сходу сразу много фичей в виде менюшек и кнопочек на главной, и всеми силами протаскивали пользователя через флоу наполнения профиля (потому что им так надо было). Друзья, стена, новостная лента, приложения внутри приложения, группа, статусы вываливаются на голову нового пользователя. Регистрация в Твиттере произошла у меня как то между прочим, на ходу. Это ощущалось как то что я зашёл на курилку - люди о чем то говорят и тебе предлагают вставить свои пять копеек. Простая задача "Послушать чужое мнение и высказать свое" решена почти идеально, все остальное, вроде личных сообщений и профиля, управление подписками, запрятано по-глубже, и находится в случае надобности.

Ремарка для тех у кого настроение подушнить: не все ux решения там хороши, но принцип - спрятать все лишнее и решить идеально главное - на месте.

Я теперь хочу попробовать эту Open source колу

Питон наконец-то был пофикшен
https://github.com/mathialo/bython

Что объединяет Twitter, Notion, Telegram, Uber, React и Minecraft?

Все они стали очень популярными в своей сфере, и в каждом из них вижу одну общую черту - они тщательно маскируют свою сложность, пряча ее от юзера до момента когда он будет более лоялен и более уверен. Мастерство UX дизайнеров этих приложений заключается в том чтобы не показывать фичи до момента пока они не станут нужны, сосредоточив пользователя на какой-то очень простой базовой задаче.

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

Да, вторая половина успеха в том что бы фича находилось легко в тот момент когда она станет нужна, для чего надо очень хорошо понимать ситуации в которых это происходит.

Мне кажется наиболее ярким примером в этом списке является Minecraft - самая продаваемая и долгоживущая игра в мире.

В нем нет квестов, нет четкой сюжетной линий, нет никаких npc которые бы рассказали кто наш главный герой и что он должен делать. Нет даже тутора (не считая надпись "ударь дерево" в самом начале игры). Игрок просто занимается тем чем хочет, и он открывает те аспекты игры которые интересны именно ему, и играет в такую игру в которую ЕМУ нравится. А рядом люди играют в том же мире но совсем в другую игру. В этом весь секрет

Typescript официально не поддерживает функции-конструкторы потому что... да прост впадлу им, на самом деле все (типизация this, и конструкторов) у них для этого есть, просто это все приходится кастовать руками

interface ChangeSet {
  added: File[];
  removed: File[];
}

const ChangeSet = function (this: ChangeSet) {
  this.added = new Array<File>();
  this.removed = new Array<File>();
} as unknown as new () => ChangeSet;

const changeSet = new ChangeSet()

playground.ts

В JS в какой ситуации выполнение функции дойдет до return 'success' но функция никогда не вернет эту строчку
(ответ дам через 10 минут)

"обожаю" такие названия колбэков

Если вы когда-нибудь публиковали свой npm пакет то у вас наверняка была куча вопросов о том, что писать в main, exports, module, default поля в package.json

К счастью теперь есть либа @arethetypeswrong/cli которая призвана подсказать и проверить что все заполнено правильно

*Звук очищающихся серверов телеграмма от сомнительного контента в сохраненках*

Ну вот и чего ему не сиделось в эмиратах

Контекст: Дуров был арестован в Франции, ему грозит до 20 лет

Одна деталь меня всегда занимает в js - все что касается ошибок (Errors) и исключений (Exceptions) в нашем коде перевернуто сверх на голову.

Для контекста - что есть что:

Error - это когда ваша приложение сломалось полностью, пишем в логи трейс и умираем. Например - закончилась оперативная память.

Exception - это когда случилась неприятность, но мы можем с этим что-то сделать или вообще проигнорировать. Например - мы не нашли лог файл в который раньше писали.

в JavaScript нету нормального разделения на ошибки и исключения. у нас есть только объект Error, который мы используем часто для того чтобы выбросить исключение и как то его обработать.
Но как найти где она там будет обработана? А вы точно catch вашему промису добавили?

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

function someFn(data) {
   if (!someCheck(data)) return [Error('Can not do something because....'), null]
   // ...
   return  [null, something]
}

Таким образом я всегда могу быть уверен (благодоря тсу) что я эту ошибку отловил и учел в коде выше.
В ситуациях где я хочу чтобы приложение завершило работу - я делаю throw Error(...)

Ну и напоследок пример очень странного кода который часто вижу и никогда не понимал. Что это дает и как ловить эту ошибку кто-нибудь знает?

const onClick = useCallback(() => {
    ...
    throw Error(...)
}, [])

<div onClick={onClick} />