Все боятся регулярок как огня, хотя это вполне простая штука, которую можно освоить за минут 30-40. Внезапно, в этом хорошо помогает универ, а конкретно курс теории формальных языков. Для примера можете глянуть вот эту статью. https://www.hse.ru/data/2013/02/24/1306622858/cc-1-automata.pdf Хотя в каждом из универов есть хороший набор прикладных материалов для изучения подобного(советую материалы ВМК МГУ, там всё ок, так как я там учился).

Главный вывод из статью такой: любая регулярка - это конечный автомат. А как мы записываем конечные автоматы? Верно в виде графов. И эта визуализация неплохо помогает работать с регулярками. И даже есть неплохой сервис, который делает это debuggex.com.
К примеру, есть нечитаемое выражение (/\*)|(\\\*)|(<=)|(>=), которое хрен знает что значит. Но если его нарисовать, то всё становится понятно.

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

TIL css неплохо так помогает при написании js кода.

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

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

Но, внезапно, эту штуку можно перенести на плечи css через
window.matchMedia(any media query).
В итоге код превратился в более приятную штуку(см. картинку 2).
Теперь все проверки переложены на css, который, по идее, должен работать лучше чем наш js код. Как минимум не забирать cpu в мейнтреде, когда это не требуется.

TIL в exports для тайпингов можно задавать версию ts. https://github.com/DefinitelyTyped/DefinitelyTyped/blob/bd28a854c712dd45cd6e224a1571d2395e91dcf3/types/react/package.json#L9
Возможно, для костылей при переходе между версиями ts'а пригодится

Недавно у нас в команде были споры по поводу кодстайла(да, в 2023 году). Нашёл хорошую статью по поводу этой проблемы https://typenoscript-eslint.io/linting/troubleshooting/formatting/

Сегодня у меня возникла микрозадачка: проверить как работает библиотека "qs" на некоторых корнеркейсах, чтобы иметь возможность выпилить её в пользу URLSearchParams.

Оказывается, в npm на странице любой библиотеки есть кнопочка "try on runkit". После чего можно играть с библиотекой как тебе хочется. Очень удобно

Так же посоветовали аналог https://www.val.town/

https://www.youtube.com/watch?v=4B2Nbxrz-Uw

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

Иногда нужно передать файл с одной машины на другую, но нет доступа по ssh, из-за чего scp нельзя использовать. Если не слишком параноики, то можно использовать https://transfer.sh. Очень удобная штука

А если же параноик, то никто не мешает зашифровать файл перед загрузкой на их сервис.

Последнее время часто люди спрашивают школу, через которую РЕАЛЬНО можно научиться фронту с нуля. Такое, внезапно, есть: rs.school.
Бесплатно, долго, через труд. Но я рекомендую, так как у людей нет цели выкачать из вас деньги. Всё на энтузиазме.

Так же если захочется поменторить, то там всегда требуются менторы. Рекомендую. Тоже хороший опыт. Только советую не брать много людей. 2-3 оптимально. Больше - будете просто умирать от нагрузки

Двухминутка ненависти

Если вашему проекту хотя бы год и ваша команда занималась только "фигак-фигак и в продакшен", то наиболее вероятно, что ваши зависимости находятся в печальном состоянии. Потому что кроме кода, который пишете вы, существует код, который пишут другие люди и который вы используете: от бабеля и еслинта, и до какой-нибудь ui библиотеки, которая улетает на клиент.

Сейчас почти во всех популярных менеджерах пакетах есть команда outdated:
npm yarn@classic yarn@3 pnpm

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

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

Решение простое: каждое утро лично ты выполняй у себя на проекте команду outdated и обновляй любую зависимость. Желательно красную или же deprecated, если у вас такие есть в проекте.
К примеру, за 2 месяца почти ежедневных вмешательств красная часть стала меньше раза в 2. Ещё 3-4 месяца и, надеюсь, что от красного можно будет избавиться совсем.

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

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

А ещё телега требует премиум, если хочешь длинное сообщение накатать. Больше 1024 символов? Ха. Плати

https://codingfantasy.com/games/css-grid-attack/play

Игра, в которой можно изучить как работают css-гриды. А так же там куча других игр, которые посвящены программированию

Логичным вопросом после https://news.1rj.ru/str/xavescor_code/14 будет: а зачем вообще это делать, если всё работает? Нода прекрасно держит обратную совместимость, npm репозиторий иммутабельный. Весь код будет работать в будущем спокойно.

Оно-то так. Но увы, перестанет работать программист. Сейчас поясню:
- Пример первый. egov.kz Электронное правительство Республики Казахстан. Angular@1. Это сверхактивно развивающийся проект, аудитория которого больше 5М пользователей. Но первый ангуляр приводит к тому, что внутреннюю кодовую базу попросту больно поддерживать. Нет ни библиотек, ни программистов на рынке, ни развития тулинга. Я общаюсь с ребятами оттуда и они чуток на стену от боли лезут.
- Пример второй. nextjs.org. Основной фреймворк для реакта. Это активно развивающийся проект с двумя неприятными нюансами. Первый - они спокойно ломают обратную совместимость в патчах(не минорах и тем более не мажорах). Но это фигня, кмк, так как с этим жить можно. Ну, почитаешь issues и найдёшь решение. Страшно другое. На сайте есть документация ТОЛЬКО для последней версии. Отстал на пару мажорных версий? Ну, удачи тебе. Будет весело.
- Пример третий. nestjs.com По сравнению с next - тут чуть получше, есть версионирование доки. Но есть 1 нюанс: перейдите по ссылке на migration guide https://github.com/nestjs/nest/releases/tag/v9.0.0. И тут начнётся веселуха, потому что вы попадёте на migration guide с v9 на v10, а не v8->v9. Справедливости ради, он всё же существует. Но они сломали ссылки.

Все эти 3 примера - это проекты с огроменным финансированием, которые не умеют в примитивные вещи. А если у гигантов не получается соблюдать базовый DX, то что говорить о мелюзге? Там вообще всё плохо будет. По этой причине лучше пытаться держать актуальным проект сейчас, а не пытаться через 5-10 лет обновить это устаревшее поделие. Возможно, его будет проще переписать с нуля.