drugoi.dev | Никита Баев об AI разработке и менеджменте

GitHub Copilot X

Пока мы празднуем Наурыз, GitHub выпустили анонс GitHub Copilot X — развитие Copilot вместе с GPT-4 под капотом, поддержкой чата и голосовых запросов, интеграцией в Pull Request-ы и генерированием документации.

Сейчас Copilot автодополняет ваш код тоже вместе с AI, но Copilot X унесёт нас в будущее программирования, где AI становится вашей “уточкой” и вашим коллегой в парном программировании.

Фичи, которые меня впечатлили:

Генерация тестов внутри PR: AI анализирует код и даёт рекомендацию по обновлению или созданию тестов — https://githubnext.com/projects/copilot-for-pull-requests#gentest

Ревью PR: это просто невероятная оптимизация рабочего времени, особенно, когда работаешь с джуниор разработчиками — https://githubnext.com/projects/copilot-for-pull-requests#reviewing-pull-requests-with-ai

Записываемся в Waitlist и ждём — https://github.com/github-copilot/chat_waitlist_signup/join

У нас открыт CFP на следующий AlmatyJS Light.

А также мы ищем интересные помещения для проведения митапов с оборудованием (90+ человек, проектор/экран, звук), можете кидать предложения в комментариях или мне в личные сообщения.

https://t.me/almaty_js/90

⛵️ Элемент за вьюпортом!

Раньше, когда я часто занимался вёрсткой и делал адаптивные интерфейсы, то иногда я сталкивался с тем, что некоторые элементы выходили за пределы viewport и появлялись зоны горизонтального скролла.

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

Для таких случаев я пользовался следующим хаком, через кастомный CSS:

*,
*:after,
*:before {
  outline: 1px solid red;
}

На все элементы на странице вешаем красный outline в 1px и находим виновников поехавшей вёрстки.

Сегодня увидел более элегантное решение с использованием JavaScript:

document.querySelectorAll('*').forEach((el) => {
  if (el.offsetWidth > document.documentElement.offsetWidth) {
    console.log(el);
  }
});

Ищем всем элементы на странице, если offsetWidth элемента больше, чем offsetWidth нашего документа — выводим элемент в консоль, а уже после этого мы можем (как минимум, в Chrome) нажать правой кнопкой на элемент в консоли и выбрать Scroll into view, чтобы увидеть его на странице.

Останется только поправить проблему и заниматься вёрсткой дальше.

Удобный GitHub

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

Быстрый опрос моих друзей-разработчиков показал, что не многие знают, что есть расширение, которое в разы улучшает пользовательский опыт на GitHub — это Refined GitHub. Вы только посмотрите на список фич, которые там реализовали — https://github.com/refined-github/refined-github#highlights-

Безусловно, одно из самых полезных расширений и которое никак не нужно настраивать. В качестве полезного дополнения могу назвать ещё OctoLinker, благодаря которому можно переходить по импортам из ваших файлов в другие файлы — https://github.com/OctoLinker/OctoLinker.

Примерно половина моей карьеры прошла именно так

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В конце выходных почему-то сломался дефолтный 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

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

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

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

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

Прошла уже половина октября, но у вас ещё есть возможность поучаствовать в ежегодном мероприятии, которое устраивает 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 объявили CFP, а также сбор тем на lightning доклады (маленькие доклады по 10-15 минут).

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

https://t.me/almaty_js/25

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

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

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

Затем я пришёл к использованию в боевых проектов 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.

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

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

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

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

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

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

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

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

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

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

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