Ихрь постит в уютный бложик: заметки с тегом development

How to inline TailwindCSS styles to SSR NextJS

Wed, 04 Oct 2023 11:54:42 +0300

By default, NextJS may not include Tailwind styles in the SSR build, and with disabled JavaScript, your site may look ugly like pure HTML.

To fix this, you need to install the critters package.

npm install critters

And enable optimizeCss rule in next.config.js.

experimental: {
    optimizeCss: true,
},

Source: next.js#12868.

Change SSH port on Ubuntu 22 using Ansible

Wed, 29 Mar 2023 18:46:00 +0300

After updating Ubuntu 22.10 SSHd uses socket-based activation.
As a result, the sshd configuration port does not affect the listening port.
To change the port, we need to perform the following tasks:

- name: Create config folder
  file:
    path: /etc/systemd/system/ssh.socket.d
    state: directory
    recurse: true

- name: Create config file
  copy:
    dest: /etc/systemd/system/ssh.socket.d/listen.conf
    content: |
      [Socket]
      ListenStream={{ custom_ssh_port }}

- name: Reload systemd manager
  systemd:
    daemon_reload: yes

- name: restart ssh
  service:
    name: "ssh"
    state: restarted

- name: Update connection port
  set_fact:
    ansible_ssh_port: "{{ custom_ssh_port }}"

How to fix unknown fragments types in graphql-codegen?

Wed, 15 Feb 2023 23:05:44 +0300

I spent half of the day setting up graphql-codegen to generate the correct types for fragment queries.

At first, my code looked like this:

// file1
export const DIALOG_FIELDS = gql(`
  fragment DialogFields on Dialog {
    id
    name
  }
`);

// file2
export const GET_DIALOG = gql(`
  ${DIALOG_FIELDS}
  query GetDialog($dialogId: ID!) {
    dialog(id: $dialogId) {
      ...DialogFields
    }
  }
`);

const config: CodegenConfig = {
  schema: CONFIG.apiHost,
  documents: ['src/**/*.{tsx,ts,js,jsx}', '!src/gql/__generated__/*.ts'],
  generates: {
    './src/gql/__generated__/': {
      preset: 'client',
      plugins: [],
      overwrite: true,
      presetConfig: {
        gqlTagName: 'gql'
      }
    }
  },
};

So, with the basic config I did get an unknown type for both the query and the fragment:

I found a simple solution for this — we need to remove the string interpolation for the fragment literal from the query, because graphql-codegen automatically includes fragments.

export const GET_DIALOG = gql(`
  query GetDialog($dialogId: ID!) {
    dialog(id: $dialogId) {
      ...DialogFields
    }
  }
`);

As a result, I did get an not unknown type, but the type with no data from the fragment for the query fragment.

I lost the most time at this stage, eventually finding a solution in the small GitHub thread. We need to disable fragment masking feature.

const config: CodegenConfig = {
  schema: CONFIG.apiHost,
  documents: ['src/**/*.{tsx,ts,js,jsx}', '!src/gql/__generated__/*.ts'],
  generates: {
    './src/gql/__generated__/': {
      preset: 'client',
      plugins: [],
      overwrite: true,
      presetConfig: {
        gqlTagName: 'gql',
        fragmentMasking: false
      }
    }
  },
};

Finally the type contains all the information and it is complete!

Про дебаг в старых Safari

Wed, 01 Feb 2023 18:01:23 +0300

Знаете, что самое веселое в фронтенд-разработке после похорон IE?
Дебажить приложения под Safari старых версий — это просто нереально...

Как я делал с IE? Качал виртуалку с сайта MS с нужной версией IE и спокойно дебажил.

Как я делаю с Safari? Ищу образ виртуалки, их же официально никто не распространяет, а ушлые ребята распространяют образы только через Patreon, WTF?

На ноут я не могу поставить виртуалку со старой Mac OS, потому что у меня ARM процессор. На ПК я не могу поставить потому, что у меня там процессор AMD, а почему-то на новых AMD виртуалки как-то криво инструкции транслируют.

В итоге приходится искать макбуки на Intel, на них ставить виртуалку со старой ОС и там дебажить — во житуха!

Изначально писал в телеге — тык

Про Apple и поддержку старых фич

Mon, 14 Nov 2022 21:11:46 +0300

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

У меня в работе (да и не только в работе) очень много всего автоматизировано: переключения между проектами, автозаполнения форм, переводчики по месту, хитрые поиски и линки, генерилки паролей и временных почт, подключалки к серверам, всякие скрипты уровня «сходи туда, скачай то, заскриншоть, отправь в телеграм» и т. д.

Так вот после обновления Mac OS (напомню, лучшая ОС в мире) у меня отвалилась половина скриптов потому, что Apple удалила из стандартной сборки системы python 2 (которому сто лет в обед) и php (зачем он там был, я уже и не вспомню). Пришлось что-то переписать, что-то обновить, о чем-то забыть...

Вот Apple может взять и релизнуть сильно ломающие изменения, а некоторые мои знакомые в своих проектах не могут удалить одно мелкое поле, которым пользуются ну 2% пользователей. Более того, я завсегдатай срачей в тематических чатах про поддержку старых браузеров.

Кажется, всякое старье все-таки можно (и нужно) выпиливать, пользователи не тупые и умеют гуглить, пусть разбираются. Всем бы у Apple поучиться!

Больше постов в телеграме, там шитпостинг ложится лучше

Как я Алису научил открывать домофон

Fri, 02 Sep 2022 23:45:46 +0300

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

Это очень удобно, но телефон я не всегда ношу с собой по дому, да и когда готовлю, например, и требуется открыть дверь, то становится довольно неудобно — руки заняты.

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

Во-первых, я изначально заложил 95% на успех, так как домофон у меня через приложение может открываться с телефона.
Во-вторых, мне банально интересно было потыкаться в навыки Алисы и даже 5% неуспеха меня не смущали.
В-третьих, мне никак не хотелось идти вечером пятницы пить пиво.

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

Я, недолго думаю, постманом получил нужные токены, протыкал ручки — вроде работает. Быстренько накидал простой сервис на ноде, который на запрос по определенному эндопоинту с сикретом (куда же без сесурити) дергает эндпоинт провайдера, в случае неудачи пытается обновить токен и дернуть его еще раз.

Затем пошел на Диалоги, где сделал приватный диалог для Алисы, который перенаправил в ту же ручку. Внутри сервиса дописал пару проверок, чтобы во входящих интентах было «домофон», затем дергался эндпоинт провайдера, а в ответ Алисе уходило «Открываю».

Проверил — работает! Только расстроило, что в диалогах инпут длинный. То есть Алиса слушает это как «Алиса, скажи домофону, чтобы открылся» или около того — явно в команде должно звучать кодовое слово навыка.

Обошел это через создание шортката в сценариях для всех своих станций и... эврика! Теперь Алиса открывает домофон по фразе «Открой домофон». Пятница прошла довольно-таки неплохо!

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

Видео с демкой залил в телегу — тык.

How to run TS-node with ES modules and CommonJS?

Mon, 29 Aug 2022 20:26:01 +0300

If you’ve got ERR_REQUIRE_ESM, ERR_UNKNOWN_FILE_EXTENSION for TS files, ERR_MODULE_NOT_FOUND for TS files with ES modules and other errors related to «CJS to ESM migration problem» in your NodeJS project you can fix it by following these steps.

Update package.json to define modules system

"type": "module",

Update tsconfig.json to support ESM in TS-node

{
  "compilerOptions": {
    "target": "esnext",
    "emitDecoratorMetadata": true,
    "module": "esnext",
    "moduleResolution": "node",
    "types": ["node"],
    "resolveJsonModule": true,
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true
  }
}

Run your entry point script using node and ts-node as node loader

node --experimental-specifier-resolution=node --loader ts-node/esm src/index.ts

Enjoy!

Запустили сайт NИTИ

Tue, 07 Jun 2022 14:52:33 +0300

Мы с ребятами делаем в Рязани очень крутой движ — NИTИ, я относительно недавно, но все же. Это тусовки с электронной (и не только) музыкой, крутая площадка, диджейские подкасты, музыка и еще много всего крутого.

Пару дней назад у объединения была, так сказать, годовщина. В честь этого события мы анонсировали масштабный оупен-эйр и... барабанная дробь... сайт!

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

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

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

Работали по настоящему аджайлу, можно сказать, только спринты были по паре дней, утрирую, но как-то так.

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

Технологически весь сайт построен на NextJS, чтобы быстро работало и вообще на острие технологий.
К слову, на релизе этот самый Next съел всю оперативу на сервере и вместо картинок юзеры получали 502 ошибку, но теперь все статически экспортируется — рантайм не нужен!

На графике посещений очень ярко выражен момент, когда мы сайт в инстаграме и телеграме анонсировали, красота! А вот та просадочка в начале — это как раз 502 ошибки, хорошо, что поймали быстро.

Осталось заделать наикрутейший интернет-магазин, но пока это в бэклоге. Сейчас в топ-приоритетах — собрать сет на грядущий движ в ~~штанах~~ лесу!

Как хостить MySQL на маленьких VPS

Tue, 22 Mar 2022 17:20:29 +0300

Недавно я начал хостить бложик (apache + mysql + nginx + пара сервисов на nodejs) на самом дешевом дроплете от Digital Ocean (надо ж кредитные токены DO куда-то потратить).

Внезапно столкнулся с проблемой, что контейнер MySQL периодически умирает от OOM киллера, MySQL с небольшим количеством данных съедала ну очень много памяти в простое.

Платить больше я не хотел, а воспоминания, что когда-то MySQL крутилась у меня на прямо маленьких VPS никак не давала покоя.

Оказалось, что есть такая штука, как Performance Schema.

The MySQL Performance Schema is a feature for monitoring MySQL Server execution at a low level.
The Performance Schema provides a way to inspect internal execution of the server at runtime.

Дальше я не особо читал, конечно, погуглил чуть, решил поэкспериментировать.
Добавляем в конфиг в секцию [mysqld] строчку, чтобы отключить эту фичу (я просто примонтировал новый конфиг), перезагрузил сервис и бах — случилась магия и теперь MySQL кушает гораздо меньше ресурсов. А мониторить мне пока не к чему.

Как блог в DO переезжал

Thu, 17 Mar 2022 15:46:50 +0300

Недавно Mastercard и Visa работать перестали для международных покупок, значится. Понял я, что пришло время переезжать на Digital Ocean, так как у меня там был некоторый предоплаченный период.

С одной стороны я сразу пожалел, что не написал 7 лет назад какой-то плейбук, чтобы все развернуть. С другой — у меня почти все заводилось через `docker-compose up`.

Как раз подчистил ненужные сервисы, забэкапил все, перетащил через `scp` всякую рантайм-шляпу типа логов, терять же не хочется, запустил — все отлично работает, остался рад, ушел спать.

Ночью мне написали, что часть постов не грузится, я решил посмотреть, что произошло и... я не понял, что произошло, ведь я фронтендер! Да и до сих пор не понимаю. На графиках прикольно видно мои потуги что-то починить и как все ломалось.

В какой-то момент у меня начала падать база, что-то в ней побилось. Побилось, кажется, из-за того, что у одного из PHP-скриптов Эгеи не было прав, а потом уже и сам контейнер в базой не мог писать на диск, так как там прав тоже не хватало — на предыдущей VPS у меня чудесно uid’ы юзеров совпали, и все хорошо было.

В итоге потратил некоторое время на то, чтоб права поправить, обновил MySQL наконец-то, раз 5 переустановил Эгею из бэкапов — косячил в скрипте, некоторые UTF-8 символы криво переносились.

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

Какие выводы? Выводов нет. Надо только нормально все автоматизировать или хотя бы записывать, а не вспоминать что там было 3 года назад, и за правами сразу следить.

Второй выпуск подкаста смонтирован

Wed, 19 May 2021 11:07:00 +0300

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

Андрей Смолко — главный знаток спеки JS в Рязани рассказывает про то, как от проектирования кораблей он перешел к разработке веб-сервисов, учился в Европе и много чего интересного про синтетические данные.

Подкаст в аудио-формате и на других площадках — анкор.

Фидбэк, предложения, пожелания, залететь в следующий выпуск — форма.

0:00 — Приветствие
1:33 — Экскурс в историю
3:12 — Как поехать учиться в Европу
9:47 — Про магистерскую диссертацию, исследования и первые программы
14:37 — Как вернулся в Россию, в Рязань
17:00 — Про модели кораблей, электронную навигацию и работу в Санкт-Петербурге
21:10 — Первый продакшен код
22:55 — Как Андрей стал программистом и переехал в Рязань
28:30 — Как начал читать спеку JS
37:44 — Кто вдохновляет
42:55 — Бэкенд или фронтенд
46:09 — Компетенции и собеседования
55:12 — Про проект и синтетические данные
1:08:12 — Завершение

Как babel-плагин замедлил приложение в 2 раза

Thu, 04 Mar 2021 19:11:13 +0300

TL;DR: в @babel/plugin-transform-classses есть баг, который вызывает падение перформанса.

Вчера всплыла неожиданная проблема, которая изначально звучала как «часть приложения работает медленнее после оптимизаций сборки проекта». Перформанс панель показывала неутешительные результаты, причем, посмотрев на коллстек, найти даже минимальную зацепку я не смог.

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

С ними в проекте недавно была проведена работа по дедубликации лок-файла и дерева зависимостей, вместе с чем обновились некоторые библиотеки. Минус 7000 строк лока, разбор проблемы обещал быть веселым.

Проблему искал сначала мой коллега, затем я. Не знаю, сколько времени на это было потрачено, но причиной оказался один плагинчик — @babel/plugin-transform-classses. Откатил версию, зафиксировал ее, и все заработало.

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

Как оказалось, с 1 апреля 2020 года в репозитории есть репорт этой проблемы — babel#11356.

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

В нашем случае замедление было в среднем в 2+ раза. Некоторым повезло меньше, после обновления Angular можно поймать и более ощутимые просадки.

В очередной раз поймал себя на мысли, что в 2021 году babel уже не нужен. Пора начать выпиливать его из проектов!

Сейчас придумал теорию заговора, что babel так с адептами ООП борется просто.
Как там было? Если хочешь, чтобы перестали использовать deprecated метод, добавь в него sleep.

Пилотный выпуск подкаста в паблике

Sun, 28 Feb 2021 16:26:39 +0300

Зарелизил, так сказать, пилотный выпуск подкаста. Со звуком проблемы, но это пока, дальше — лучше!
Пока доступно на ютубе и анкоре, доставка на другие площадки — в процессе.

Фидбэк и предложения можно в комменты ниже, в комменты на ютуб или анонимно — в форму.

0:00 — Приветствие
2:12 — Стартапы и COVID-19 в Германии
5:42 — Социализация после переезда
10:42 — Велосипед и учеба на права в Берлине
13:55 — DevOps, инфраструктура и облака
15:51 — Основное направление работы
17:01 — Про Ruby
18:07 — Глобальная клаудификация
21:12 — Постоянное обучение и выгорание
25:21 — Инженерная тусовка и атмосфера
28:11 — Почему бы не начать свой стартап
30:36 — История сайта WebPurple
35:00 — Технический стек для своего стартапа
41:24 — Завершение

Обходим блокировку аналитики AD блокерами

Mon, 22 Feb 2021 13:14:12 +0300

AD-блокеры — несомненно крутая штука, тем не менее, они блокируют скрипты аналитики, которые не всегда являются злом.

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

Блокировщики работают в несколько этапов: блокируют подгрузку файла скрипта аналитики и блокируют запросы к серверам аналитики, к которым эти скрипты и обращаются.

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

Добавляем два локейшена в конфиг:

# сам скрипт аналитики
location /analytics-script.js {
  # очень важно, чтоб отрабатывал sub_filter, т.к. если сервер отдаст gzip, то замена не сработает
  proxy_set_header Accept-Encoding "";

  # заменяем в скрипте оригинальный адрес на наш, проксированный
  sub_filter 'https://cloudflareinsights.com/cdn-cgi/rum'  'https://домен/analytics-api';
  sub_filter_types *;
  sub_filter_once off;

  proxy_hide_header Content-Security-Policy;
  proxy_pass https://static.cloudflareinsights.com/beacon.min.js;
}

# проксируем вызовы к оригинальному api аналитики
location /analytics-api {
  proxy_pass https://cloudflareinsights.com/cdn-cgi/rum;
}

Подключаем аналитику не с домена Cloudflare, а со своего домена.

Таким образом мы загружаем и скрипт аналитики со своего домена, и аналитику он отправляет на наш домен, а внутри уже все проксируется в Cloudflare.

AD блокеры ничего не блокируют, мы получаем аналитику. Запросы куда-то еще уходят неявно.

Есть одна небольшая проблема — у всех запросов один IP, IP прокси, почему-то аналитика Cloudflare не учитвает заголовки и не имеет задокументированных способов переопределить IP юзера, как это сделано в Google аналитике.

Закинул в коммьюнити топик на эту тему, посмотрим, как решится.

Применяем команды iOS

Sun, 25 Oct 2020 19:05:43 +0300

Относительно недавно я перешел на iOS, и меня долго мучало, куда бы приладить команды, которые позволяют что-то автоматизировать. Чего я только в них прикрутить не пытался, в моих случаях все упиралось в то, что триггер телеграма с отправкой сообщений попросту не работает. Но это, конечно, совсем другая история!

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

Хотелось бы сказать, что я не написал ни строчки кода для внедрения этой фичи, но нет, пришлось дописать в бота один GET-эндпоинт, который достает из QS координаты, проверяет токен и делает все то же самое, что делал бот.

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

Ошибки state-менеджмента React-компонентов

Mon, 15 Jun 2020 19:01:52 +0300

При работе с React у многих разработчиков, у которых с ним менее года опыта (или более, но понимания некоторых аспектов нет) возникает проблема с пониманием состояния компонента.

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

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

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

Парочка самых распространенных, что я видел: Эффект, который слушает проп и обновляет в след за ним стейт без каких-либо преобразований. Что-то вроде такого:

const component = ({ prop }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    setSavedProp(prop);
  }, [prop]);
};

Больше логики никакой, никаких подводных камней. Мало того, что можно было бы прямо в useState прокидывать проп, так все гораздо проще — можно было бы использовать сам этот проп, вместо его сохранения в стейт! Вероятно, там когда-то был какой-то процессинг, может быть, какие-то условия, но больше этого нет, зато есть несколько ненужных обновлений компонента.

Эффект, который слушает изменения стейта, чтобы… вызвать коллбэк.

const component = ({ prop, onPropChange }) => {
  const [savedProp, setSavedProp] = useState(null);

  useEffect(() => {
    onPropChange(savedProp);
  }, [savedProp]);

  return (
    <Child prop={prop} onPropChange={setSavedProp} />
  )
};

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

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

Проблема FrontOps’а

Sun, 07 Jun 2020 18:59:53 +0300

TL;DR

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

Предыдущие два года на более, чем двух проектах я занимался такой деятельностью, которую обычно называют «FrontOps». Давайте разберемся, какие у фронтопса проблемы и как их решать.

Дисклеймер: По теме я не раз говорил на митапах Webpurple, но структурировать все в текст так и не вышло нормально. Пост — просто изливание кучи мыслей, не структурирован, хотя планировалось нечто большое на несколько иную тему, в черновиках лежал больше, чем полгода, но, как говорил Тим, надо признаться, что черновики не допишутся и публиковать как есть, вот публикую. Ниже все исключительно ИМХО.

Повествование я начну как обычно — с небольшого отступления в прошлое. Когда я начинал работать как разработчик, я никогда не был против задач не для разработчика (как сейчас считается): сервер настроить, сконфигурировать прокси, сборщик из пачки sh-скриптов подкрутить, еще что-то. Да, эти задачи я решал постольку-поскольку, не использовал всякие крутые штуки и инструменты, до поры до времени ни про вагрант, ни про ансибл не слышал, но задачи решал и мне в целом нравилось.

Что касается специализаций и развитий навыков, я приверженец T-shape подхода: в основном я фронтендер, но и в DevOps с бэкендом могу. Вот благодаря этому пересечению с девопсом я гордо могу назвать себя FrontOps’ом.

Появление FrontOps

Вторая часть слова — Ops. Когда говорят про Ops, вспоминается DevOps. Несколько обидно, что почему-то в DevOps не всегда включают FrontEnd, ~~шутка про формошлепов~~ на это есть свои причины, но начнем с того, что такое DevOps.

DevOps — методология взаимодействия специалистов по разработке (Dev) со специалистами по информационно-технологическому обслуживанию (Ops) и интеграцию их рабочих процессов друг в друга для обеспечения качества продукта.

Wikipeadia — DevOps

В диалогах я слышал что-то вроде: «Какие еще оперейшены во фронтоне?! Че там оперировать, статика же?», — наверно, поэтому как-то это все в отдельное направление и выделилось местами. Изначально, девопс — это больше про бэкенд и все, что около него, как-то так сложилось исторически, во всяком случая я чаще сталкивался с таким, что в рамках девопс-процессов о фронтенде никто особо не думал, и это как-то само должно было решаться. Ведь что нужно бэкенду? Кластер серверов, лоадбалансинг, умный деплоймент с нулевым даунтаймом, скейлинг и много всего сложного и интересного. А что на фронтенде обычно было? Отдать статику (часто через тот же бэкенд) и все, но сейчас времена другие.

В итоге, отпочковался фронтопс. Фронтопс — ничто иное, как перенос девопс-практик на фронтенд. Те же практики, те же решаемые задачи, просто с некоторой спецификой что ли. Девопс (и фронтопс, выходит, тоже) подразумевает работу по некоторому циклу из определенных шагов с использованием определенных техник и инструментов.

Проблема FrontEnd ~ Ops

Create... а дальше?

После того, как код написали, с ним еще много интересного происходит до того, как он начнет решать задачи пользователя и бизнеса, да и в процессе выполнения этих задач интересное не заканчивается. На бэкенде, разработчики в большинстве своем представляют, что с кодом происходит, после того, как он скомпилировался, так как по-другому там жить довольно сложно, надо все-таки понимать, кто там jar’ник запустил и какие и куда пакеты летают, бэкендерам даже надо понимать, что такое TCP, например (!!!).

В мире фронтенда ситуация несколько иная. На один мой комментарий в ревью «этот код не соберется вот по этой причине, вот линк, почитай, интересная штука» мне отвечали «я простой разработчик, это меня не касается» (утрирую, но примерно так было). WTF? В тот момент я понял, что что-то не так.

Откуда растут ноги этой проблемы? Из времен, когда разработка фронтенда заключалась в запуске сервера статики (и то не всегда) и изменения файликов, которые тут же отображаются в браузере, а деплой заключался в том, чтобы отдать файлики бэкендерам, а они там в jsp перегонят и сами разберутся, или загрузить файлики через FTP на другой сервер. Просто, круто, DX на высоте, код написал и все.

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

`git clone` — оп, код у меня;
`npm install` — ну, зависимости у меня, погнали;
`npm start` — ммм, *клик-клац-клик*, все, написал;
`git commit -a && git push` — отлично, таску в резолв.

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

Вроде бы задача понятна, но для многих разработчиков фронтенда она нерешаема по одной простой причине: они слишком отдалились от инструментов разработки и не успели подстроиться под их изменения, да и думать об этом часто не нужно, и «вообще пусть это девопсы делают, оперейшены все-таки». Но откуда девопс-инженерам знать о том, как код должен собираться вебпаком? А тем более о всяких узких местах, типа хранений шрифтов на том же домене, чтобы лишний dns-запрос не делался?

Много разработчиков на C++ вы знаете, которые не понимают, как линкуются библиотеки и не могут написать make-файл? А фронтендеров таких много, и это часто не проблема фронтендера, да и не проблема это, просто у нас много инструментов, которые легко устанавливаются и все делают сами.

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

Решаем проблемы

Фронтопс — это не только девопс + фронтенд, фронтопс — то, что нужно знать фронтенд разработчику, для того, чтобы быть действительно фронтенд разработчиком, ведь закомиченный код — далеко не результат работы. Нужно понимать, что с кодом происходит, куда он потом помещается и как доходит до пользователя.

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

Если вы не понимаете этого, изучите проект и инструменты, которые в нем используются, почитайте документацию к ним, спросите более опытных тиммейтов, сделайте собственный стартер или пет-проджект, накрутите там крутой CI/CD, оптимальную сборку.

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

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

Вебпак, бабел, бандлеры, таск-раннеры (Webpack, Babel, npm-scripts, Gulp) — изучите принцип работы сборщиков и компиляторов JavaScript, TypeScript, CSS, поймите разницу между Rollup и Webpack, изучите возможности npm-scripts и Gulp (хоть его и мало кто использует сейчас).
Форматтеры, линтеры, статические анализаторы (ESlint, Prettier, stylelint, SonarQube) — хватит спорить на ревью о том, где должна стоять запятая, хватит мутировать иммутабельные значения, автоматизируйте проверку этого.
Git и хуки (Husky, lint-staged, Learn Git) — изучите Git, для вас не должны быть проблемой ребейзы, которые заканчиваются конфликтами, используйте хуки для автоматического запуска проверок.
Тестирование (Jest, Mocha, Jasmine, Cypress) — изучите инструменты тестирования, способы их использования, виды тестов.
Дополнительные инструменты для проверок проекта (size-limit, Lighthouse CI) — проверяйте перформанс-метрики вашего проекта прямо на этапе непрерывных интеграций.
CDN, файлы, сервера и прокси (nginx, S3, CloudFront, Cloudinary) — изучите, как файлы могут храниться и раздаваться.
Мониторинг (Amplify, Sentry) — настройте мониторинги, отслеживайте, что происходит с кодом при использовании.
Деплой, сервера, докер (Ansible, Docker, SSH) — изучите подходы к деплою, варианты запуска приложений, научитесь работать с SSH и консолью — это действительно нужный навык.
CI/CD (GitLab CI) — изучите принципы и подходы к организации CI/CD, сделайте полезный пайплайн для своего проекта или оптимизируйте существующий.

UI library based on Chakra-UI bundling

Thu, 09 Apr 2020 18:49:15 +0300

Recently I tried to build some UI components library that based on Chakra-UI. At first my library didn’t contain react components and compiled using typescript and it worked perfectly. But after I added React components based on Chakra-UI and migrated build to webpack, I’ve got the next error from react hooks that were called inside Chakra-UI hooks such as useTheme:

Invalid hook call. Hooks can only be called inside of the body of a function component. This could happen for one of the following reasons:
1. You might have mismatching versions of React and the renderer (such as React DOM)
2. You might be breaking the Rules of Hooks
3. You might have more than one copy of React in the same app
See https://fb.me/react-invalid-hook-call for tips about how to debug and fix this problem.
By the way, Chakra-UI repository has this issue about this error - ((https://github.com/chakra-ui/chakra-ui/issues/495 #495)).

What is the reason for this error? useTheme hook and Chakra-UI library in whole use react library. As a result library imports react and react-dom. When webpack bundling your library that includes Chakra-UI, it includes react and react-dom to bundle of your library. In brief, you import react to your project, also you import your library with Chakra-UI that contains react too, as a result — you have at least two React copies. And in fact, it’s incorrect hook call.

How to fix it? Use only single react instance in your app. If you’re using webpack you can mark react and react-dom libraries as external libraries for your components library:

externals: {
  // mark "react" and react-dom as external packages that will import using commons
  react: 'commonjs react',
  'react-dom': 'commonjs react-dom'
},
output: {
  path: path.resolve('./'),
  libraryTarget: 'commonjs2', // set library target
  filename: '[name].js',
  library: '',
}

Now bundle of your library doesn’t contain react and react-dom. We marked libraries as external and have pure require calls but doesn’t have library in bundle:

/***/ "react":
/*!************************!*\
  !*** external "react" ***!
  \************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react");
/***/ }),

/***/ "react-dom":
/*!****************************!*\
  !*** external "react-dom" ***!
  \****************************/
/*! no static exports found */
/***/ (function(module, exports) {
  module.exports = require("react-dom");
/***/ })

This way also can help you if you’re using hooks and creating your own UI library without Chakra-UI.

NextJS, первый взгляд

Fri, 28 Feb 2020 18:45:08 +0300

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

На первый взгляд все оказалось очень круто, что интересно, почему-то даже некоторые интерактивные элементы начали работать быстрее, не разбирался пока, какая магия их ускорила, но не отметить не мог. Миграция тоже прошла гладко, подключение к проекту было самым крутым из всех инструментов: установить через yarn, удалить конфиг webpack’а, — именно последний пункт больше всего понравился.

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

Казалось бы, роутинг должен быть сильнее всего проработан в фреймворке такого типа, но то ли я не понял, как им правильно пользоваться, то ли оно как-то странно сделано. Ладно, со ссылками пришлось повозиться, ибо в одном случае href — тот url, на который непосредственно идет редирект, а в другом случае — slug страницы, который я определил в роутере, а непосредственно ссылку прокидывать нужно в проп as.

Но вот если пушить что-то в url с динамическим роутом, то получается что-то странное. Пушу не явный конечный url, а slug описанный в роутинге, нужна квери-стринга? Ок, квери можно прокинуть в отдельный объект, они даже до чилда долетят, но вот в url они не попадут, бери ручками и прокидывай.

Тут у меня прямо явный диссонанс:

Ожидание: сейчас я в метод пуш прокину объект квери и текущий адрес — хоба, квери обновлен, строка адреса хранит состояние, все счастливы.
Реальность: прокидываю реальный адрес, прокидываю шаблон адреса, прокидываю квери-объект, новый полный адрес вместе с квери, который сам леплю чем-то, — тоже все счастливы, конечно, но большей ценой.

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

Текущая локация на странице

Tue, 07 Jan 2020 18:35:37 +0300

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

Самый первый вариант, который я рассматривал — по cron’у дергать “Find my phone” и ориентироваться на эти координаты, однако, этот вариант не особо мне понравился, ибо, во-первых, надо раскручивать API, которое может неожиданно поменяться, во-вторых, в моменты между городами cron также отрабатывает, и потом на сайте красуется какое-то неожиданное местоположение, но основная причина — сложно и ничего непонятно.

Второй вариант — сделать простой сервис с get и post ручками, развернуть его где-то в Heroku и все. Сервис я такой сделал, положил его на GitHub. Из интересного, post-метод работает через Telegram-бота — я просто кликаю кнопку и… все, ну и в MongoDB ведется лог местоположений, интересно будет потом посмотреть.

Интерфейс бота

Сервис работает как часы (еще бы одна RW-сущность плохо работала), хостится на Heroku. Осталось только интегрировать его с сайтом, но тут интересно, что сайт-то полностью статический, делать запросы лишние не очень хочется, ибо на Heroku инстансы поднимаются дольше, чем пользователи задерживаются на моем сайте. Потому все вынес в compile time, оказалось, из GraphQL все довольно удобно доставать.

В gatsby-nodes.js добавляем хук, создаем ноду в GraphQL

const fetch = require('node-fetch');
const config = require('../config');

exports.sourceNodes = async ({
  actions: { createNode },
  createContentDigest
}) => {
  const result = await fetch(config.locationUrl);
  const locationData = await result.json();

  createNode({
    ...locationData,
    id: 'author-location',
    parent: null,
    children: [],
    internal: {
      type: 'AuthorLocation',
      contentDigest: createContentDigest(locationData)
    }
  });
};

В компоненте страницы достаем это и рендерим.

query RootPage {
    authorLocation {
      city
      country
    }
}

В целом механизм работы такой:

Отправляю боту местоположение.
Он проверяет, что оно новое, сохраняет в MongoDB.
Дергает webhook Netlify.
Netlify стартует пересборку сайта.
Gatsby делает запрос к сервису, получает новое местоположение.
Сборка.
Деплой.

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