У yarn есть очень удобная команда yarn upgrade-interactive (и флаг --latest, если вы хотите обновиться до последних версий).

В npm из коробки нет такой удобной фичи, но зато есть отличный пакет npm-check, который покажет, какие пакеты можно обновить и на какие версии.

Обновляйте свои пакеты вовремя, но не забывайте читать changelog-и, чтобы случайно не сломать свой проект 👌🏻

Руслан @iamroose подсказал, что есть ещё более удобная альтернатива — npm-check-updates

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

# upgrade everything except nodemon
ncu \!nodemon
ncu -x nodemon
ncu --reject nodemon

Домен drugoi.codes оказался слишком дорогим для продления, а drugoi.dev вполне по деньгам 😬

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

🤖позволяет не тратить время на решение базовых вопросов и поиск сниппетов в своей кодовой базе, тем самым в разы ускоря разработку.

Пользуетесь ли вы Error Boundary в React?

Вы можете сказать, что ваш код не падает, но по опыту скажу, что бывало так, что у клиента было установлено какое-то расширение, которое крашило инпуты и благодаря Error Boundary крашилось не всё приложение, а какая-то небольшая его часть с возможностью перерендерить блок UI.

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

И как раз на глаза попалась хорошая статья, которая объясняет работу Error Boundary и то, как правильно их компоновать + рекомендует достаточно интересный пакет, который всё сделает за вас под капотом, пользуйтесь на здоровье

https://meticulous.ai/blog/react-error-boundaries-complete-guide/

Открыл старый проект для расширения под Chrome и на душе стало немного теплее.

Можно увидеть такие местами архаичные, для текущего времени, вещи, как:

bower — пакетный менеджер для фронтенда (как npm, только полностью для веба)
yeoman — генератор проектов (детям буду рассказывать, что это был Create React App)
gulp — таск-раннер, который заменил в своё время Grunt.
editorconfig — IDE конфиг для единообразия отступов и прочего в файлах проекта.

А вы застали золотые времена этих инструментов?

5 лет назад мы с @talgautb сделали примитивного бота для казахской латиницы (https://github.com/drugoi/telegram-bot-qazlatyn), чтобы можно было быстро перегнать текст/фразы из кириллица в латиницу.

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

Приняты ли у вас в команде какие-то правила по написанию коммитов?

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

Использовал этот подход в основном в своих собственных проектах и выглядело это примерно вот так:

Красиво? Да. Функционально? Ну, не очень.

Затем я пришёл к использованию в боевых проектов Conventional Commits (CC).

Это очень удобное соглашение, которое позволяет избавить ваш репозиторий от коммитов вида fix bug и, как отличный бонус, автоматическая генерация Changelog-а с правильной разметкой и релиз-менеджмент.

Но чтобы это всё работало правильно, нам необходимо либо найти разработчиков со 100% понимаем дела, либо включить линтинг коммитов.

Здесь нам на помощь приходит Commitlint, который с помощью простых pre-commit хуков позволяет валидировать содержимое сообщения коммита и либо пропускать его, либо выдавать ошибку. Он легко настраивается и позволяет очень быстро добавить в свой флоу разработки щепотку магии.

Единственная проблема, с которой я столкнулся — это валидация скоупов.

Скоуп в контексте CC — это место применения изменений, которые были сделаны в коммите. Например: feat(lang): add Kazakh language
В данном примере lang — это скоуп. Нет каких-то строгих правил по тому, что может являться скоупом, вы задаёте его в рамках своей бизнес-логики/фреймворка.
Но что, если наш разработчик напишет: feat(leng): add Kazakh language

С точки зрения commitlint — всё правильно, но с точки зрения Changelog-а и в целом управления скоупами — это что-то новое и в будущем вам будет сложнее искать связанные с одним скоупом коммиты.

Для решения этой проблемы в конфигурации commitlint придумали правило scope-enum которое позволяет перечислить список разрешённых скоупов в проекте. Его можно собрать самому, а можно воспользоваться python скриптом, который написал мой знакомый Галымжан @gazgolderkz — gist.

Скрипт нужно положить в папку с проектом и перед выполнением скрипта нужно выполнить сбор данных из git log с помощью команды — git log --pretty=format:%s | grep -E '^(\w+)\((\w+|\*)\)' > commits.log

В итоге будет создан csv файл, в котором отсортировано будут делать использованные вами скоупы. Осталось их почистить и добавить в конфигурацию commitlint.

Готово, вы — восхитительны, а ваш репозиторий чист и вкусно пахнет.

Сегодня нахожусь на Kolesa Conf.

Сейчас Андрей Минкин рассказывает про свой путь от разработчика до CTO и обратно.

Понравился слайд, на некоторых местах работы сталкивался с таким.

Мы в AlmatyJS объявили CFP, а также сбор тем на lightning доклады (маленькие доклады по 10-15 минут).

Если давно хотели попробовать себя в выступлениях — это отличный шанс!

https://t.me/almaty_js/25

Прошла уже половина октября, но у вас ещё есть возможность поучаствовать в ежегодном мероприятии, которое устраивает Digital Ocean и его партнёры — Hacktoberfest 2022.

По сути, это такой фестиваль поддержки OSS, где основная цель — помочь вам сделать свой первый PR в публичном репозитории. Регистрация по ссылке — https://hacktoberfest.com/

Конечно, заниматься поддержкой и развитием open source нужно круглый год, но благодаря Hacktoberfest сотни разработчиков делают свои первые PR в различные репозитории. Да, некоторые PR оставляют желать лучшего (удалили/добавили пробелы, например), но если вы, читая документацию, нашли ошибку и поправили её — это заслуживает уважения.

Мой список проектов, где можно помочь своим PR:
1. Если вы носитель казахского языка, то рекомендую обратить внимание на date-fns, я могу помочь вам с обновлением.
2. Документация react.js — good first issues

Ну и большой список репозиториев с лейблом hacktoberfest — Github Topics

Открыли продажи на #AlmatyJS

Финальная программа ещё в работе, но будет интересно и весело.

Билеты продаются на Sxodim — https://sxodim.com/almaty/event/mitap-dlya-razrabotchikov-almatyjs

Самая последняя информация в канале — https://t.me/almaty_js

В конце выходных почему-то сломался дефолтный DNS от Digital Ocean для казахстанских доменов из-за чего два моих бота, которые связанны с казахстанскими сайтами (KazNic и сайт Нацбанка) перестали достукиваться до них и падали в ошибку EAI_AGAIN, что говорит о том, что случился таймаут при запросе DNS записей домена.

Быстрым фиксом было проставление IP адресов в /etc/hosts, но это решение мне не нравилось.

Проведя несколько тестов я выяснил, что домены недоступны только с VPS-ок на Digital Ocean и решил, что можно попробовать сменить DNS-ы на самом сервере.

Если у вас стандартный дроплет от Digital Ocean, то это очень легко сделать: vi /etc/netplan/50-cloud-init.yaml

            nameservers:
                addresses:
                - 1.1.1.1
                - 1.0.0.1

Находим секцию с nameservers и меняем адреса на нужные (я выбрал DNS от Cloudflare).

Note: после ребута сервера эти настройки сбросятся, но кто ребутает свой сервер вообще?

После изменения NS записей выходим из vi и применяем параметры: sudo netplan apply

Готово, можно проверить работоспособность, например, через curl yourwebsite.kz

Ускорение сборки TypeScript проектов

Пару дней узнавал у знакомых, как они собирают свои TS проекты и выяснил, что у многих не включена опция incremental.

Если её включить, то TypeScript будет сохранять промежуточную информацию о компиляции в файлик .tsbuildinfo (можно поменять расположение/название файла через параметр `tsBuildInfoFile`) и тем самым уменьшать время компиляции.

Если, вдруг, вы не использовали эту настройку ранее, то поделитесь результатами до/после в комментариях.
Я, обычно, замеряю такие вещи вот так: time tsc

Держите в курсе

Очень важная часть разработки — это статусы в Jira, но куда более важная часть, как по мне, это личное общение “заказчиками” (QA, BA, PO, etc.) и друг с другом.

Если вы на утреннем DSM (daily standup meeting) пообещали какой-то апдейт и не успеваете — напишите об этом тому, кому обещали, чтобы он понимал текущую ситуацию. Не бойтесь уведомлять о задержках.

Лучше, чтобы все были в курсе, чем в неведении.

смотрите как умеет JSON Discovery

на надо ручками переписывать типы, за вас уже сделали

Айрат написал про интересную находку в JSON DIscovery.

Очень удобно, как по мне, не всегда бэкенд заранее может предоставить TS интерфейс для работы фронта.
Я обычно пользуюсь онлайн конвертером на сайте с полезными утилитами для конвертации — https://transform.tools/json-to-typescript

Пару месяцев назад у нас с Айратом разгорелась дискуссию на тему эффективности работы в офисе и на удалёнке.

С началом пандемии мы ушли из офисов в домашние офисы и я помню разговоры в офисе, в середине марта 2020 года, про то, что «эта удалёнка всего на пару недель», но лично для меня удалёнка продолжается до сих пор* и я испытываю почти максимальное удовольствие от неё.

Правда, как только пандемия немного отступила, то многие компании решили вернуть сотрудников в офисы. Это произошло и с моей командой в Альфе, мы вернулись на гибридный график до следующей вспышки заболеваний (т.е. примерно на месяц) и больше уже не возвращались.

Хочу поделиться мыслями про удалёнку и почему мне она нравится:

1 — Организация работы на удалёнке

Если вдруг вы не читали книгу Джейсона Фрайда и DHH «Remote. Офис не обязателен» (Remote: Office Not Required), то там есть очень важная мысль про то, что невозможно уйти на удалённую работу, если сам работодатель не создаёт условия для этой удалённой работы.

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

Когда нам настроили нормальный доступ без RDP производительность нашей команды выросла в разы и за время нахождения в локдауне (а это больше месяца) — мы запустили сразу несколько кредитных продуктов и провели хороший рефакторинг.

2 — Правильная организация рабочего времени

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

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

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

3 — Правильное рабочее место

Рабочее место и рабочий сетап (WFH setup) — это, наверное, одни из самых больших моих инвестиций в продуктивность и эффективность на удалёнке. Многие компании предоставляют бюджет для оснащения домашнего офиса и рекомендую использовать его по максимуму: хороший стол, кресло, эргономичная клавиатура и хорошее освещение. Моё рабочее место до недавнего времени выглядело вот так и я не знаю ни одного офиса в Алматы, который был бы подготовлен для работы таких больших людей, как я.

По моим наблюдениям, работа в офисе — это постоянная борьба с внешними раздражителями: решить куда пойти кушать с командой, сходить за кофе, сходить на перекур, стресс от дороги в/из офиса и т.д.

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