Игорь Камышев — разработчик веб‑приложений и техлид. Люблю чистый код и работающие продукты. Программирую на TypeScript, иногда на Dart или Scala.

Веду каналы в Телеграме: kamyshev.code об архитектуре ПО и софт‑скиллах, Глубокий JavaScript о тонкостях JS и несколько других.

Проекты

Самокат
2019

Мобильное приложение «Самокат» — это замена магазину у дома с моментальной доставкой продуктов (15‑30 минут).

Сделал карту с зонами доставки, интегрировал Mapbox. Сверстал экран для отображения электронных чеков от АТОЛ Онлайн. Спроектировал и реализовал систему диплинков для приложения. Переписал функциональность сторис с Preact (внутри веб‑вью) на ReactNative.

Стек: JS (ReactNative, TypeScript).

Stomweb
2019

Образовательная платформа Stomweb для врачей‑стоматологов: статьи, видеолекции, вебинары. Мы перезапустили сайт с новым дизайном.

Написал сервис для конвертации видео в M3U и последующего стриминга через HLS. Перевел легаси‑код админки на современную версию PHP, завернул её в Docker, добавил новые формы и исправил баги в старых. Верстал обновленный фронтенд.

Стек: JS (React, Node.js, TypeScript), PHP.

Просто спросить
2018‑2019

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

Спроектировал приложение, руководил разработкой при несдвигаемом дедлайне. Сделал синхронизацию данных приложения с Trello‑досками. Написал Telegram-бота для экспертов сервиса.

Стек: JS (React, Node.js, TypeScript).

Faster
2018

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

Организовал рефакторинг легаси‑кода и ускорил поиск по лекарствам в 10 раз. Реализовал масштабируемую архитектуру. Автоматизировал поиск изображений для товаров. Перевел фронтенд на TypeScript.

Стек: JS (React, TypeScript), PHP (Yii2).

CRM ФРМСП
2018

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

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

Стек: JS (Vue), PHP (Symfony).

QEEP‑Pro
2017‑2018

Платформа «QEEP‑Pro» объединяет в себе CRM, интернет‑магазин и мобильное приложение. Проект стартовал в 2011, к 2017 оброс значительным количеством легаси.

Поддерживал и развивал сайт и мобильное приложение. Разработал генератор интернет‑магазинов, сделал функциональность почтовых рассылок.

Стек: JS (React, ReactNative, Vue, TypeScript), PHP (Symfony).

Procraft
2017

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

Занимался модулем статистики. На бэкенде сделал интеграцию с Google Analytics и агрегации полученных данных, сверстал и имплементировал графики для сайта и мобильных приложений.

Стек: JS (React, ReactNative, TypeScript, Relay), Scala (Play, Slick, Sangria), GraphQL.

Опыт

Самокат
08.2019‑сейчас

Фронтенд разработчик, техлид

Сейчас работаю в Самокате — мы делаем моментальную доставку продуктов (10‑15 минут), без минимальной суммы заказа. Я занимаюсь внутренними продуктами компании: приложения для складских работников, сотрудников отдела кадров, службы технической поддержки и отдела закупок.

Нетология
04.2018‑сейчас

Методист и лектор

Работал над курсами, вебинарами и домашними заданиями в онлайн‑университете Нетология.

Разработал и год вёл занятия по работе с компонентами высшего порядка, Context API и Hook API в React. Участвовал в первом запуске продвинутого курса по JavaScript — читал лекции по использованию Service Workers и Web Workers, работе с Server Sent Events и Web Sockets. Курировал 7 потоков курса по базовому JS, вёл вебинары по функциональному программированию и асинхронности.

Breadhead
06.2018‑08.2019

Фулстек разработчик, техлид

Breadhead делает веб‑сервисы, связанные с образованием, e‑commerce и автоматизацией процессов. Я строил архитектуру новых приложений и оптимизировал легаси-код, контролировал качество кода. Писал сложные фронтенды и надежные бэкенды.

Руководил командой из 4 разработчиков. Валидировал запросы бизнеса, превращал их в задачи и распределял между разработчиками. Привел все приложения к единому стеку технологий. Ввел практику написания тестов и код‑ревью. Автоматизировал интеграцию и доставку, настроил CI/CD.

QEEP‑Pro
11.2016‑06.2018

Фулстек разработчик

QEEP‑Pro специализируется на создании CRM и ERP систем. Я писал внутренние продукты и работал над заказными проектами для Procraft, Фонда развития малого и среднего предпринимательства и локальных служб доставки. Привил практику непрерывной интеграции приложений, настроил CI. Руководил командой из 3 разработчиков.

Фриланс
01.2014‑11.2016

Веб‑разработчик

Верстал сайты, писал jQuery‑плагины, поднимал и дорабатывал CMS. Сделал свою систему управления контентом, запустил на ней 5 сайтов.

Статьи

Angulareact

У меня есть проблема. Приложение написано на Angular, а библиотека компонентов на React. Делать клон библиотеки слишком дорого. Значит, нужно использовать React‑компоненты в Angular-приложении с минимальными затратами. Разбираемся как это делать.

Инструкция: хостим сайты

Короткая практическая инструкция по хостингу любых сервисов. Единственное требование — завернуть приложение в Docker‑контейнер, взамен получаем автоматическую генерацию nginx-конфигов, HTTPS из коробки, надежность и простоту.

Инструкция: бэкап GitHub

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

Кейс: воркер‑треды

Node.js работает в одном потоке. Чаще всего это не создаёт проблем, потому что почти все операции в наших приложениях неблокирующие. Недавно я делал обработку натурального языка на JS и упёрся в однопоточность. Решение — воркер‑треды.

Как мы делаем CI/CD

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

Самый важный навык, который может освоить программист

Работа программиста — решать проблемы бизнеса, а код — это инструмент решения этих проблем. Но код стоит дорого. Его дорого писать, но еще дороже поддерживать. Каждая новая строка потенциально ведет к багам, требует рефакторинга в будущем. Перевод статьи о важности умения писать меньше кода.

Конфигурация NodeJS приложений

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

Конфигурация приложения – это все, что может меняться между развёртываниями (среда разработки, промежуточное и рабочее развёртывание). Это включает в себя:

  • идентификаторы подключения к ресурсам типа базы данных, кэш‑памяти и другим сторонним службам;
  • регистрационные данные для подключения к внешним сервисам, например, к Amazon S3 или Twitter;
  • значения зависимые от среды развёртывания такие, как каноническое имя хоста.

Простой путь

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

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

Правильный путь

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

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

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

Все это и больше

Итак, в большинстве приложений есть три варианта развёртывания:

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

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

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

@solid‑soda/config

В мире PHP есть отличное решение — Symfony Config Component. Эта библиотека умеет делать все что нужно для конфигурации приложений. Она вдохновила меня на создание @solid‑soda/config — абстракции над конфигурацией, которая предоставляет удобный и безопасный интерфейс для доступа к параметрам в Node.js.

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

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

Конфигурируйте!

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

Легкий фронтенд

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

Сайты должны быстро грузиться при любом интернете и хорошо работать на любом устройстве. Если сайт маленький, то добиться этого легко отказавшись от фреймворков и используя только HTML/CSS/JS.

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

Как

Обычно, когда берут генератор статики на React (Vue, etc), хотят получить удобный компонентный подход. Есть способ добиться аналогичного результата без такого большого оверхеда. Для повторного использования разметки лучше взять любой шаблонизатор (twig, pug) и делать в нем миксины. CSS же отлично изолируется БЭМ‑нотацией или CSS-модулями (да, и их можно использовать просто так).

Отказ от фреймворка не означает возвращение в прошлое. Можно все еще использовать современные возможности JS и CSS, и обрабатывать их Babel и PostCSS (а для разметки возьмите PostHTML).

Хитрый шаблонизатор, пост‑процессоры и транспайлеры нужно как-то удобно запускать, чтобы на выходе получать набор файлов понятных любому браузеру. Тут можно взять абсолютно любой бандлер, но лучше посмотреть на максимально простые в конфигурации — Parcel, Rollup.

Еще

  • Обратите внимание, сколько будет весить JS который вы написали. И сравните с весом любимого фреймворка. Для контроля размеры бандла используйте size‑limit.
  • Все это будет бесполезно, если не следить за интерфейсными изображениями на сайте. Посмотрите доклад Вадима Макеева.
  • Подумайте о полифилах. При таком стиле разработки сайта никто за вас не включит в бандл полифилы, потому следует четко понимать какие возможности в каких браузерах есть и следить за этим.

Построение таких сайтов изменяет мышление и будет полезно любому фронтенд разработчику. Попробуйте!

Как работать с денежными значениями в JavaScript

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

Процесс подготовки npm‑пакета

Я часто делаю npm‑пакеты. Это не моя основная работа, потому хочется тратить минимум времени и сил. После публикации пакет нужно поддерживать, хочется минимизировать и эти затраты. Статья о процессе и используемых инструментах.

Чистая архитектура

В процессе чтения книги Дядюшки Боба «Чистая архитектура» писал себе заметки. Для удобства собрал их в единый конспект. О ценностях программы, парадигмах в программировании, принципах SOLID и важности тестирования.

Не решайте воображаемые проблемы

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