Андруша пишет код

Для меня, как для фронтенд разработчика, очень просто воспринимать компании на рынке:
- Apple - делает отличные ноутбуки для моей работы. Но ужастные для домашнего использования
- Google - прекрасный ютуб, который мне помог своими видео в начале моей карьеры. Остальными сервисами не пользуюсь
- JetBrains - отличные IDE на любой вкус
и так далее.

Но в этом списке есть одна компания, которая одновременно несёт добро в этот мир, которое сделано максимально через задницу.
Это компания Microsoft. По какой-то непонятной причине сотрудники этой компании живут так, как будто завтра апокалипсис.

1. Давай глянем как MS покупает компании. Например: В 2020 году купила npmjs.com. Хорошая новость? Да, npm начал конкурировать с ярном и, сейчас, с pnpm. Одни плюсы. Но публичную деятельность npm решили вести максимально дибильно. После покупки все анонсы(blog.npmjs.org) падают в блог гитхаба. Пробовали ли вы что-то искать в блоге гитхаба? Это просто неиндексируемая помойка из всего что принадлежит MS. Пользоваться этим стало на порядок менее удобно. Аналогично произошло с Mono(опенсорс рантайм для дотнета).
2. Давай посмотрим как MS ведёт разработку своих языков: C#, F#, TypeScript. Знаете что у них общего? У них нет общей спецификации. И если у C# есть хотя бы дельты, благодаря которым можно жить, то у остальной двойки полная задница - ты не можешь просто реализовать компилятор этих языков. До войны JetBrains делилась какой ад им приходится проходить, чтобы понять что есть в тайпскипте: https://www.youtube.com/watch?v=qddYQL5-rZY. Спойлер: они читают все исходники, потому что других мест для получения информации нет.
3. MS и опенсорс = ❤. Ну, вроде и так. Начиная с .Net Core Майки очень много вещей вынесли на общее обозрение. Но в чём может быть тут косяк? Ну... К примеру, если ты запрещаешь использовать опенсорсный дебаггер к дотнету вне своих продуктов. https://github.com/dotnet/core/issues/505

https://dev.to/muhammadazfaraslam/highlight-on-the-new-features-of-next-js-14-config-2023-4lbe

Главное впечатление от прошедшей конфы некста на фото.

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

Синдерхорнус продолжает ультовать.
https://sindresorhus.com/blog/goodbye-nodejs-buffer

95% статьи я поддерживаю. Там описаны супер граммотные идеи. К примеру: в еслинте запрещаем использование нодового Buffer, чтобы потом постепенно переписать на стандарт. Но блин, его кардинальность "ломаем обратку в либах" - это нечто.

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

#tip

В TS variadic functions можно выражать через tuple

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

С энных версий (уже довольно давно) у нас есть типизация таплов и рекурсивные типы, не пишите портянки.

За последние 3 дня я столкнулся с двумя ситуациями:
- gulp.watch - штука которая смотрит за ФС, но, внезапно, криво размонтируется в тестах. Из-за чего в 3 из 4 случаев у меня тесты падают в случайном месте. Просто из-за кривого размонтирования. Никогда не чистите так за собой. https://github.com/XaveScor/gulp/blob/dad4fde180bdeeaa8da0de9c8cd3598af97ea67b/test/watch.mjs#L44
- Работа с сетью - аналогичная штука. Но тут ситуация серьёзнее. Из-за того что некоторые веб сервисы могут быть недоступны, то приходится навешивать retry. Из-за чего при падении теста код не доходит до освобождения ресурсов и на всё время прогонки тестов я получаю утечку. Из-за чего тесты опять же выпадают в ООМ или в другую ошибку.

Не будь макакой - думай и о плохом.

Не думай о хорошем

Прошла неделя с момента кривого ютуба(https://t.me/xavescor_code/44) и я начинаю подозревать, что мартышки повсюду. Потому что зачем планировать то как код будет работать в нештатной ситуации? Внезапно, код может упасть или ещё что-то подобное. К примеру, еикто в тестах не думает насколько удобно работать с упавшим тестом. А поэтому никто не чистит за собой ресурсы.

Если вы в тестах не пишите

const finalizers = [];
try {
 doSmth();
} finally {
 finalizers.forEach(f => f());
}

при работе с ресурсами, то у вас проблемы. Потому что иначе у вас ресурсы будут утекать. Есть, конечно, https://github.com/tc39/proposal-explicit-resource-management, но когда оно появится?

Никогда, НИКОГДА, НИ-КАГ-ДА не называйте переменные именами апих из глобального скоупа.

Сегодня я потратил часов 5 выясняя из стектрейса на 2 страницы(Не стебусь, реально 2) почему у меня в fetch нет метода catch.

Угадали? Верно, потому что fetch - это имя переменной, а не функция из globalThis. Вот зла не хватает, когда подобное видишь.

Назови человек переменную fetchFx, я бы не перелопачивал исходники jsdom и ещё 3 библитек, которые используются в тестах.

Поберегите психическое здоровье своих коллег из команды. Они знают где вы живёте.

Как воспользоваться?
- На странице гитхаба, которую хотите расшарить нажмите `y`(латинская) и у вас в урле будет урл с хешем коммита.
- Для IDE от JetBrains можно поставить крутой плагин https://plugins.jetbrains.com/plugin/8183-gitlink, который позволяет копировать ссылки на кучу сервисов(github, gitlab, bitbucket, etc) прямо из IDE
- Для VSCode сорян, не использую, но уверен, что есть аналог.

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

Анналы

Slack, github/gitlab/jira issues популяризировали идею того, что сообщения - это и есть документация к коду. Но почему-то люди с одной стороны поддерживают это, а с другой стороны наплевательски относятся к этому.

Как делать плохо: https://github.com/XaveScor/gulp/blob/master/index.js#L5
Как делать хорошо: https://github.com/XaveScor/gulp/blob/d90d9476e64e5c684f18e832529d7ac472b028a9/index.js#L5

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

Как воспользоваться?
- На странице гитхаба, которую хотите расшарить нажмите `y`(латинская) и у вас в урле будет урл с хешем коммита.
- Для IDE от JetBrains можно поставить крутой плагин https://plugins.jetbrains.com/plugin/8183-gitlink, который позволяет копировать ссылки на кучу сервисов(github, gitlab, bitbucket, etc) прямо из IDE

Да блин! Чувак 4 года ману копил и, как только я решил форкнуть галп для себя, стал пилить gulp@5. Ну что за невезуха?

Из новостей: галп возможно оживёт(нет)

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

Для воспроизведения достаточно открыть на одной и той же вкладке эдак 50 видео. К примеру, послушать музыку у плейлисте или же полистать шортсы.

Из полезного: думайте над утечками памяти через глобальные ресурсы. К примеру, setInterval полезно закрывать всегда.

Предположим, что вы сумели договориться и написали правило, которое запрещает писать тот или иной код. Но как это внедрить?

Есть пакет https://github.com/amanda-mitchell/suppress-eslint-errors, который расставит eslint-ignore в нужных местах. В итоге у вас будет и CI зелёный, и новый код будет уже правильным и красивым. А старый вы постепенно переработаете в процессе будущих задач.

Отношеньки pt2

https://t.me/xavescor_code/30
Учись работать в команде - не трать время на фигню

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

Решение простое: ESLint. Если вы установили какое-то правило - оно должно покрываться линтером. Правило сверху, к примеру, можно покрыть кодом, который изображён на скриншотах выше.
Из этого я пришёл к следующему правилу в отношеньках: если вы сумели согласиться на какую-либо практику, то она ОБЯЗАНА покрываться линтером. Да, есть мелкие исключения, но они мелкие. Остальные правила должны быть в линте.
Из этого следует второе правило: при ревью не принимаются притензии по кодстайлу, используемым апишкам и т.п. Потому что если это плохо, то подобный код должен запрещаться линтером.

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

Полезные ссылки:
https://eslint.org/docs/latest/rules/no-restricted-syntax - запрет написания плохого кода
https://eslint.org/docs/latest/rules/no-restricted-imports - запрет импортов
https://astexplorer.net - посмотреть в какой ast превращается ваш код для правил выше