Кстати, любители enum которые игнорировали все предупреждения и только оправились от того что не могли перехать на esbuild - теперь снова будут страдать
И поделом, предупреждали же что enum это плохо

Любопытное - мой ноут, который фреймворк, не подключает большой внешний монитор по type-c до тех пор пока в него самого не воткнута зарядка.
Едва ли это может быть мне нужно хоть когда-то, но и причина такого поведения мне не ясна (у монитора собственное питание)

Последнее время стал патчить или форкать вместо ПР-ов в исходный репозиторий. Хотя это считается плохой практикой в сообществе. Посчитал статистику по своему github: на 37.8% моих PR не было никакой реакции мэйтенеров*. Статистика удручающая, хотя по ощущениям было что таких половина.

* От числа PR которые я делал в репозитории незнакомых мне людей

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

https://www.youtube.com/watch?v=eZDlJgJf55o

До того как я стал жить в Польше я понятия не имел как правильно делать интернациональные сайты.
Пока сам на эти грабли не наступил - не понимал как это важно.
Ниже я напишу простые советы, что учесть чтобы сделать нормальный сайт для путешественников и мигрантов
(Вдруг мои подписчики умнее меня и учатся не только на своих ошибках)

Самое главное правило - местоположение вашего пользователя ничего не говорит вам о его языке. Он может быть на этой территории временно, недавно, или вовсе не быть там (VPN). Есть более надежный способ - прочитать заголовок Accept-Language, используйте его для определения языка

Итак, чеклист
1. Проверьте что вы не определяйте язык вашего пользователя по IP (по goip базам, whois и тп) ❌

2. Проверьте что вы не определяете язык вашего пользователя по геолокации ❌

3. Убедитесь что вы определяете язык пользователя считывая заголовок Accept-Language ✅

4. Если у вас нет переводов на другие языки - проверьте что ничего не ломается при использовании Google Translate (а ломается оно часто, особенно если у вас реакт, про это напишу отдельный пост)

Так же стоит избегать следующих практик:

1. Забыть добавить возможность изменить язык вручную (если есть переводы) не покидая страничку.

2. В случае выбора отличного от дефолтов языка - редиректить на другой сайт (например при выборе en языка на example.xy перекидывать на example.com)

3. Ререндерить всю страницу после каждого взаимодействия (делает авто перевод страниц около бесполезным)

4. Использовать лейблы дропдаунов в качестве значений отправляемых формой

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

Если возможно использую базу как сервис, типа того же supabase.com.
А сегодня я узнал что они запилили бесплатный онлайн инструмент postgres.new, который позволяет таким хомячкам как я с легкостью задизайнить базу потягав прямоугольники и нажаловавшись AIшке.
Причем есть возможность эту базу потестить прямо в браузере благодаря pglite.dev (postgress на WASM)

Можете потыкать сами или посмотреть как это тыкают на Ютубе.

Одна деталь меня всегда занимает в 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} />

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

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

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

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

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

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

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

Typenoscript официально не поддерживает функции-конструкторы потому что... да прост впадлу им, на самом деле все (типизация 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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