https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/

Тут тихой сапой мистер Интернет показал классику: ты можешь быть самым-самым крутым, но уборщица, нанятая за копейки, порушит всю инфраструктуру.
Из хорошего: ребята не скрываются и публично показывают в чём не правы.
Из идиотизма:
- О, у нас 3 ДЦ, но мы тестить на оффлайн будем только 2 из них. А один - ну и тестировать смысла нет. Всё равно всё ляжет.
- Они как-то смогли получить Tier III сертификацию на этот сервак
- Почти половина статьи является обсасыванием какие поставщики электичества идиоты, а не CF построили кривую архитектуру.

До потери Яндексом дата центра в Финляндии, Яша каждую неделю устраивали учения по отстреливанию одного ДЦ, при котором для пользователя должно измениться НИЧЕГО. Весь Яндекс должен иметь возможность жить на 3х датацентах из четырёх. И каждое учение было неплохим таким стрессом. Не особо помню, но вроде как они проводились все по вторникам(не уверен в корректности памяти) каждую неделю, поэтому можете не удивляться, что сервисы Яндекса в основном падали в эту дату. Можете проверить новости)
Но только где Яндекс и где Cloudflare?

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

https://blog.angular.io/announcing-angular-dev-1e1205fa3039

Пока реакт спит, враг качается.

Страшно, очень страшно мы не знаем что это такое

Самая страшная штука для джунских собесов - это попытка узнать "зачем та или иная щтука нужна". К примеру, "зачем нужен О(N)?"(Поклонники Демидовича, сорян, не про вас. Вам респект).
Я уверен что вы спокойно скажете сколько времени будет выполняться new Map().set(), Array.prototype.filter, Array.prototype.sort. И это правильно, потому что надо понимать как работает твоя платформа, чтобы писать простой и предсказуемый код.

Чуток отвечёмся: какого кода вы практически никогда не видите в своих редакторах? Что 99% времени свёрнуто и зачастую никто руками не пишет? Верно, импорты.
И как люди спрашивают на собесах "что происходит когда ты вводишь урл в браузере и нажимаешь Enter?", я так же спрошу: "Что происходит в программе, когда вы пишете import или require?"

Ответ: выполняется абсолютно весь код, включая все реэкспорты(даже те которые не нужны), который подключается в текущий модуль. И чем больше там кода, тем дольше будет происходить инициализация приложения.

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

Поэтому в PR'ах не стоит забивать на безобидный import {} from 'large_module'. Возможно, эта строка в случайном месте сломает вам весь CI лучшем случае, и продакшен в худшем.

https://eslint.org/blog/2023/10/deprecating-formatting-rules/

Ещё чуть-чуть и вопрос автоформатирования кода будет решён. Ну, я надеюсь на это.

https://groups.google.com/a/chromium.org/g/blink-dev/c/RG0oLYQ0f2I/m/xMSdsEAzBwAJ

Third-party куки уже почти-почти всё. В 2024 году будет веселье.

Насколько преждевременная оптимизация - плохая идея.

https://twitter.com/BrendanEich/status/1271954691421691905?s=20

Планировали похожесть на джаву, а в итоге потомки мучаются с null и undefined.

Пысы: это автор js.

А вот и новый ts5.3. Хоть это и проходняк. Особо вкусных вещей нет
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-3/

W3C и все-все-все

Давай я тебя ошарашу: стандарт стандарту рознь и то, что если что-то есть в стандарте, не значит что люди делали это с умом.

Возьму такую популярную вещь: стримы в ноде. Пакет 'node:streams'. Эта штука существует уже кучу лет и вроде как должна быть отработана временем и иметь решения всех проблем. И даже больше, у неё есть какой-то стандарт: https://streams.spec.whatwg.org. Вообще люди красавчики. Не только сделали удобный инструмент, но и сделали его полное описание, чтобы людям было проще жить. Или нет?

Простая задача: напишите функцию isReadableStream. А зачем её писать? Это же должно быть в стандартной библиотеке. Правда? Ага, щщщас. Дайте 2. Нет такой функции. Воспользуйтесь пакетом: https://www.npmjs.com/package/is-stream (Если ты сидишь на ESM, sindresorhus привет, ага). А на внутренности пакета лучше даже не смотреть

Продолжение в комментах(спасибо tg за удобство работы со скриншотами)

useless packages

Структурная типизация в js - это огромная удача для всего мира, так как мы можем использовать стандартные апи даже тогда когда их поддержки нет в рантайме в помощью полифиллов. Я считаю неплохой практикой поднимать у себя локальную копию https://polyfill.io, но много кто бандлит все полифилы к себе. Но есть проблема: если ты забандлил что-то, то иногда стоит удалять это из бандла, так как это уже не надо.

И вот тут начинаются проблемы: полифилы обычно не помечаются в npm как deprecated, из-за чего всякие outdated не будут вижжать, что надо выпилить пакет. Самый простой пример https://www.npmjs.com/package/object-assign. Эта штука уже давно существует у нас во ВСЕХ рантаймах, но 25 лямов скачиваний в неделю - это 25 лямов.

Я не видел решений, которые позволяют нам контролировать зависимости в этой части, так что решил сделать это сам:

npx cleanup-deps

@latest

Пакет, который покажет какие пакеты можно спокойно выпилить. Пример для моего текущего проекта на скриншоте в комментариях.

Из того что в планах сделать в ближайшее время:
- Оформить как нормальный опенсорс проект. Пока для MVP это делать лень
- Добавить как можно больше пакетов в https://github.com/XaveScor/cleanup-deps/blob/70e18fb0765206bac028beaa30664aea81b04971/src/deps.ts
- Добавить работу не только с нодой, но и с browserslist

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

К результатам о том кто мы такие подоспели результаты отпроса от jetBrains: https://www.jetbrains.com/lp/devecosystem-2023

А так же появился новая итерация State of JS:
https://survey.devographics.com/en-US/survey/state-of-js/2023

И если первое - это "о, наконец-то, задолбал этот фронт. Можно перекататься в <langName>" или просто подборка прикольных фактов о нашей жизни, то второе - способ за 10 минут понять что волнует индустрию, и возможно, записать пару вещей, которые стоит изучить на будущее.

search everywhere

Где-то в 2020 году моя жизнь в каком-то смысле разделилась на до и после. Как минимум в том как я стараюсь взаимодействовать с интерфейсами.

Всё началось с этой статьи https://blog.jetbrains.com/idea/2020/05/when-the-shift-hits-the-fan-search-everywhere/.
JetBrains сделали удобный способ искать. Тебе не нужно думать что тебе нужно искать: строку, символ, имя файла или даже настройки. Просто вводи текст и иснтрумент сам тебе подскажет всё что он найдёт.

Это оказалось настолько сверхудобно, что со временем невольно я начал переходить на search-first жизнь везде где мог дотянуться:
- Что-то надо на веб странице? cmd+F
- Что-то надо запустить на телефоне или кому-то позвонить? Открываю строку поиска и ввожу туда имя контакта или же название приложения
- Что-то надо запустить на ноутбуке? Открываю spotlight(Mac) или Пуск(Win) и ввожу имя программы
- Нужна справочная информация? Спрашиваю у колонки или же просто иду в duckduckgo. По стандартным запросам они отвечают вполне легко
- Телеграм? Поиск по контактам
- Нужно установить программу? Иду на brew.sh или winstall.app и ищу там

С появлением chatgpt стало всё вообще прекрасно. БЕСПЛАТНО ты можешь получить даже ответ на вопрос, на который ты не можешь задать нормально вопрос.

Да, тебе придётся запоминать названия инструментов, так как ты их вводишь в строку поиска для запуска. Но, внезапно, это плюс. Потому что поэтому ты попросту выкидываешь то что тебе не надо. Логика проста: не помнишь название инструмента, значит скорее всего тебе стоит от него избавляться.

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

Да прибудет с вами строка поиска

Стринги

Что может быть проще чем строка? Наверно только число или булеан. Наверно по этой причине люди любят строить апи на основе этого примитива. Потому что "проще === лучше" же?

Вот есть redux: вот у нас там экшены на строках, и когда их миллиард в приложении, то очень удобно(нет) делать так, чтобы они не пересекались. И мы даже решение, чтобы решить эту(в том числе) проблему придумаем: RTK. Хотя нет, лол. Не решает. Всё равно надо следить за строками.

Роутер? react-router супер! Все урлы - это строки. Поэтому смена урлов - это очень удобный процесс. Нужно всего лишь пройтись по всей кодовой базе и поменять все ссылки руками. Этож так удобно.

lodash.set? Вау, этож так удобно! Не нужно думать что у тебя в объекте. Просто установил путь, значение, а оно само там разрулит. Изменилась структура объекта и у тебя тайпчек не нашёл ошибок? Ну, зато писать код удобно

And more
And more
And more

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

Welcome to FAANG

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

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

Мы решаем литкод месяцами, изучаем новые технологии и всё только для того, чтобы потом при работе красить кнопки.

Так у меня всё время возникает вопрос к сообществу: почему враньё в резюме по поводу опыта осуждается? Люди врут в CV о своих достижениях, о технологиях, которые знают, завышают значимость своих задач. Но прохождение HR фильтра по критерию опыта - это прямо плохо. Только в этом врать нельзя. Но то, что полученный опыт в rs.school(не перестану их рекламировать) чаще всего будет ценнее 2хлетнего чувака, который ничего не делал и просто штаны просиживал, это опустим.

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

В волчарах нет ничего плохого. Просто вы вместо понимания технологий проверяли знание кейвордов.

Поэтому так и больно, ауф.

С новым кодом

Новый год прошёл, а значит время нести базу в этот грустный мир.
И вот база намбер ван: решение А является плохим, если существует решение Б, которое решает проблемы А лучше чем А. Причём желательно чтобы у Б проблем было или меньше, или они меньше мешались.
База намбер ту: редакс говно, как раз по причине намбер ван. Как минимум потому что существуют reatom.dev и effector.dev

Какие же вещи редакс делает плохо:
- Подписки. Напомню для тех кто не знает: редакс - это огромный обзёрвер, который с помощью метода subscribe уведомляет ВСЕХ подписчиков, что состояние внутри изменилось. И "всех" - это ключевое слово. Редакс спроектирован так, что на любой чих ты вызываешь все подписки. Ты не можешь подписаться на конкретную часть стейта. Да, есть всякие мемоизации и подобное. Но ты всё равно будешь вызывать разные внутренние проверки на "а изменилась ли та или иная ветка стейта". Реатом и эффектор лишены этого недостатка: все связи строятся при инициализации стейта, а не при его изменении.

- Экшены. Эту проблему можно описать одним словом: строка. Да, это может показаться не проблемой, так как мы можем использовать енамы, объекты, символы или любые другие инструменты языка, которые позволяют контролировать уникальность сущностей. Но зачем? Пока мы один костыль полируем другим, у конкурентов этой проблемы в принципе нет.

- mapped состояния. Типичный код выглядит как-то так:

const value = useValue() // подписка на стор
const modifiedValue = compute(value)

return <button onClick={() => dispatch('modify', modifiedValue + 1)} /> 

А теперь подумайте как бы вы сделали эту штуку с помощью редакса? Вы НИКАК НЕ МОЖЕТЕ поместить логику, связанную с modifiedValue рядом со стором. Да, вы можете вынести эту логику в какой-нибудь хук и вызывать его в каждом компоненте. Но(!) вы тут сразу бьёте по перфу, так как перевычисляете одну и ту же логику множество раз. У конкурентов же этой проблемы нет. А подобный код мы пишем каждую минуту.


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

#база

Уродливое, но родное

В прошлой заметке я попытался показать почему редакс, по-моему мнению, плох. Существуют даже конкуренты. И их много. И они неплохи на фоне редакса.
Конкуренты:
- jotai
- zustand
- mobx
- effector
- reatom

Эти все инструменты как минимум не хуже чем редакс. Некоторые из них даже становятся популярными и растут как ни в себя по скачиваниям, но от редакса люди не отказываются. Почему?

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

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

И это касается не только стейт менеджеров. Это касается всей индустрии. Никто не делает адаптеры со старых решений на новые. Возьмём, к примеру, библиотеки для запросов. axios и got - это сверхпопулярные библиотеки, чтобы сделать простую вещь - отправить запрос в сеть. С 18 версии в ноде появилась нативная поддержка fetch, которая позволяет сделать куда меньшие и более мощные библиотеки. Но что мы видим? Никто не делает какой-нибудь fetchios, который имеет тот же API, но fetch под капотом. Этим махом можно спокойно срезать половину размера. Но нафига козе баян? Мы лучше сделаем ky, который ни с кем выше не совместим.

Так и живём...

https://nodejs.org/api/esm.html#importmetadirname

Славься мир. Больше никаких

import { dirname } from 'path';
import { fileURLToPath } from 'url';

const __dirname = dirname(fileURLToPath(import.meta.url));

Ограничения - цэ добро

После https://news.1rj.ru/str/xavescor_code/77 я решил доказать это на практике, заменив xhr внутри axios на fetch. Это позволило бы и уменьшить размер аксиоса и позволить людям перейти на более простое, вебосовместимое решение.

Но я столкнулся с проблемами, о которых должен думать разраб библиотеки, но о которых не подумали разработчики аксиоса:
Целковый. Каждая новая перегрузка апи должна решать новый спектр задач. К примеру, у реатома хук useAtom может принимать как атом, так и функцию, которая возвращает значение. Эти перегрузки не взаимозаменяемы. AxiosHeaders же может принимать в себя кучу разных типов, которые потом очень хитро превращаются в строку при превращении в хедеры. И эта хитрость очень сильно мешает как во внутренней реализации, так и при написании адаптеров. Но если бы AxiosHeaders принимал только строки, то и реализация была бы проще, и клиентам было бы не особо сложнее.
Приведу другой пример: Куча либ позволяет принимать в себя как тип T, так и Array<T>, а внутри уже T приводится к [T]. Даже если специальная функция в npm: arraify. Но, заставив пользователя писать не foo(x), а foo([x]) мы бы сэкономили и на размере либы, и на упрощении контракта.
Вывод: все приведения типов должны быть снаружи библиотеки, а не внутри. Делайте апи максимально скудным. Это очень упрощает жизнь и в тестах, и в реальной жизни

Полушка. Обновляйте библиотеки и меняйте устаревшие решения на современные. Аксиос для тестирования в браузере использует karma + jasmine. А для того чтобы отслеживать запросы, они мокают xmr. Ну, это хорошее решение, пока у нас не появился второй примитив для отправки запросов. А сейчас нормальным решением является какой-нибудь playwright, который через вебдрайвер уже получает информацию о запросах от браузера, а не с помощью моков конкретной стуруктуры. В итоге из-за кривых тестов мне для проверки своей реализации нужно ещё переписать тесты

Четвертушка. РАЗНЫЕ ТЕСТЫ НА РАЗНЫЕ ОКРУЖЕНИЯ. axios - делаем запросы по-разному. Я не знаю что в голове у людей, которые пилят аксиос, но у них 2 набора тестов: для ноды и не для ноды. Причём это РАЗНЫЕ ТЕСТЫ. Они не пересекаются. И дело не в моках. Я проверял. Тесты реально разные и проверяют разную логику. Axios - библиотека, которая работает по-разному в разных окружениях. Велкоме.

Так и живём...

Ожидания == реальность

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

Так вот. FF мёртв, как минимум по ожиданиям разрабов. Потому что у меня нет обоснования как можно было допустить багу в такой базовой вещи как AbortController.
https://github.com/microsoft/playwright/issues/29101

Буду благодарен, если вы тоже проверите у себя эту багу, так как у меня сейчас только 1 ноут под рукой. Проверка отнимет от силы 2-3 минуты вашего времени.

https://9to5mac.com/2024/01/25/third-party-default-browsers-engines/

Раз в 10 лет ЕС кардинально меняет рынок браузеров. В 2012 ЕС убил десктопный IE, а в 2024 походу он пришёл за мобильным сафари. Тестеры поздравляю, вам чуток работы подъехало.

Недавно эпол частично прогнулась под ЕС в рамках сайдлоадинга https://www.macrumors.com/2024/01/25/ios-17-4-alternative-app-marketplaces-eu/ и люди опять оказались людьми:
"Почему государство указывает компаниям как вести свой бизнес? Если я захочу устанавливать приложения откуда-то снаружи, то я могу пойти на Android".
Это забавно, так как почему-то люди думают, что мир крутится вокруг них. Хотя это не так. В данном случае, почему-то никто не думает о разработчиках сервисов, которые для успеха должны иметь приложение и там, и сям. Без исключений. Но нет, второй стороны не существует, а мир крутится вокруг меня.

Эта же история напомнило мне что компании перестают быть плохими, когда достигают целей(Так как можно просто не видеть неудобную информацию). Пример прост: Амиго, Яндекс.Браузер и прочие. Де кась "эти продукты плохие, так как распространяюлись предустановками или же параллельными установками вместе с другим софтом". Возможно, открою Америку части людей: Google Chrome распространялся точно такими же методами. В 2012 году существовал сверхпопулярный продукт, которым пользовался практически каждый пользователь интернета - Abode Flash. И, не поверите, флеш устанавливал хром, если ты забывал снять галочку. Огромное количество миллионов инсталяций принесла эта "плохая" практика. И я даже не вспоминаю истории про гугл.тулбар, который устанавливался в IE вообще при любом чихе.

Эпол и Гугл вообще, кмк, стоит поставить на уровень естественных монополий, так как Android и iOS - это вещи, которые настолько сильно интегрированы в нашу жизнь, что без них жить уже невозможно. А вот пытаться их защищать, что против них делают что-то несправедливо - это уж точно.

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