Игорь Камышев — разработчик веб‑приложений и техлид. Люблю чистый код и работающие продукты. Программирую на TypeScript, иногда на Dart или Scala.
Telegram GitHub Twitter Instagram LinkedIn
Веду канал в Телеграме kamyshev.code об архитектуре ПО и софт‑скиллах. Курирую список маст‑ридов для программистов.
2019‑2020
Внутреннее приложение «Смены» помогает сотрудникам Самоката планировать рабочее время. В нем курьеры отмечают, когда они готовы работать, а директора складов распределяют смены.
Я построил бэкенд приложения, интегрировал его с другими внутренними и внешними сервисами. Спроектировал API для мобильного приложения и веб‑интерфейса. Продумал и реализовал архитектуру фронтенд-приложения, верстал экраны, делал анимации. Проводил код-ревью и лоджик-ревью. Координировал релиз и внедрение.
Стек: JS (React, Node.js, TypeScript)
2019
Мобильное приложение «Самокат» — это замена магазину у дома с моментальной доставкой продуктов (15‑30 минут).
Сделал карту с зонами доставки, интегрировал Mapbox. Сверстал экран для отображения электронных чеков от АТОЛ Онлайн. Спроектировал и реализовал систему диплинков для приложения. Переписал функциональность сторис с Preact (внутри веб‑вью) на ReactNative.
Стек: JS (ReactNative, TypeScript).
2019
Образовательная платформа Stomweb для врачей‑стоматологов: статьи, видеолекции, вебинары. Мы перезапустили сайт с новым дизайном.
Написал сервис для конвертации видео в M3U и последующего стриминга через HLS. Перевёл легаси‑код админки на современную версию PHP, завернул её в Docker, добавил новые формы и исправил баги в старых. Верстал обновлённый фронтенд.
Стек: JS (React, Node.js, TypeScript), PHP.
2018‑2019
Сервис «Просто спросить» помогает людям, столкнувшимися с онкологическими заболеваниями. Служба бесплатно подскажет, как организовать качественное лечение.
Спроектировал приложение, руководил разработкой при несдвигаемом дедлайне. Сделал синхронизацию данных приложения с Trello‑досками. Написал Telegram-бота для экспертов сервиса.
Стек: JS (React, Node.js, TypeScript).
2018
Faster — аптечный маркетплейс, в котором можно забронировать лекарства в любой аптеке города.
Организовал рефакторинг легаси‑кода и ускорил поиск по лекарствам в 10 раз. Реализовал масштабируемую архитектуру. Автоматизировал поиск изображений для товаров. Перевёл фронтенд на TypeScript.
Стек: JS (React, TypeScript), PHP (Yii2).
2018
CRM Фонда развития малого и среднего предпринимательства позволяет работникам легко обрабатывать обращения, прослеживать их историю и отчитываться перед регулятором.
Полностью разработал приложение: реализовал возможность подписи обращений через ЭЦП из браузера, фильтрацию обращений по всем возможным полям, выгрузку отчётов для регулятора, интеграцию со старой системой для регистрации обращений.
Стек: JS (Vue), PHP (Symfony).
2017‑2018
Платформа «QEEP‑Pro» объединяет в себе CRM, интернет‑магазин и мобильное приложение. Проект стартовал в 2011, к 2017 оброс значительным количеством легаси.
Поддерживал и развивал сайт и мобильное приложение. Разработал генератор интернет‑магазинов, сделал функциональность почтовых рассылок.
Стек: JS (React, ReactNative, Vue, TypeScript), PHP (Symfony).
2017
Procraft — это CRM, с помощью которой самозанятые настраивают рекламу, создают лэндинги для продажи своих услуг и получают аналитику по клиентам.
Занимался модулем статистики. На бэкенде сделал интеграцию с Google Analytics и агрегации полученных данных, сверстал и имплементировал графики для сайта и мобильных приложений.
Стек: JS (React, ReactNative, TypeScript, Relay), Scala (Play, Slick, Sangria), GraphQL.
03.2020‑сейчас
Фронтенд разработчик
Сейчас работаю в метапоисковике авиабилетов Aviasales.
08.2019‑03.2020
Фронтенд разработчик, техлид
Самокат — сервис моментальной доставки продуктов (10‑15 минут), без минимальной суммы заказа. Я занимался внутренними продуктами компании: приложения для складских работников, сотрудников отдела кадров, службы технической поддержки и отдела закупок.
Я декомпозировал проекты от состояния «должно быть классно» до конкретных задач разработчикам. Программировал фронтенды на React, бэкенды на Node.js, поддерживал легаси‑приложение на Angular. Контролировал качество кода, проектировал интеграции с другими внутренними сервисами, координировал релизы. Руководил командой из 3 разработчиков.
04.2018‑01.2020
Методист и лектор
Работал над курсами, вебинарами и домашними заданиями в онлайн‑университете Нетология.
Разработал и год вёл несколько занятий для курса по React, проверял домашние задания. Читал лекции на первом запуске продвинутого курса по JavaScript. Курировал 7 потоков курса по базовому JS, вёл вебинары, корректировал содержание курса, помогал студентам и преподавателям.
06.2018‑08.2019
Фулстек разработчик, техлид
Breadhead делает веб‑сервисы, связанные с образованием, e‑commerce и автоматизацией процессов. Я строил архитектуру новых приложений и оптимизировал легаси-код, контролировал качество кода. Писал сложные фронтенды и надёжные бэкенды.
Руководил командой из 4 разработчиков. Валидировал запросы бизнеса, превращал их в задачи и распределял между разработчиками. Привёл все приложения к единому стеку технологий. Ввёл практику написания тестов и код‑ревью. Автоматизировал интеграцию и доставку, настроил CI/CD.
11.2016‑06.2018
Фулстек разработчик
QEEP‑Pro специализируется на создании CRM и ERP систем. Я писал внутренние продукты и работал над заказными проектами для Procraft, Фонда развития малого и среднего предпринимательства и локальных служб доставки. Привил практику непрерывной интеграции приложений, настроил CI. Руководил командой из 3 разработчиков.
01.2014‑11.2016
Веб‑разработчик
Верстал сайты, писал jQuery‑плагины, поднимал и дорабатывал CMS. Сделал свою систему управления контентом, запустил на ней 5 сайтов.
У меня есть проблема. Приложение написано на Angular, а библиотека компонентов на React. Делать клон библиотеки слишком дорого. Значит, нужно использовать React‑компоненты в Angular-приложении с минимальными затратами. Разбираемся как это делать.
19.09.2019 Читать на Habr
Короткая практическая инструкция по хостингу любых сервисов. Единственное требование — завернуть приложение в Docker‑контейнер, взамен получаем автоматическую генерацию nginx-конфигов, HTTPS из коробки, надёжность и простоту.
27.08.2019 Читать на Medium
Наш код стоит очень много денег. Мы тратим на его создание сотни тысяч долларов, но совершенно не заботимся о сохранности — храним на одном коммерческом сервисе. Простой способ делать автоматические бэкапы.
15.07.2019 Читать на Medium
Node.js работает в одном потоке. Чаще всего это не создаёт проблем, потому что почти все операции в наших приложениях неблокирующие. Недавно я делал обработку натурального языка на JS и упёрся в однопоточность. Решение — воркер‑треды.
10.07.2019 Читать на Medium
Год назад в Breadhead мы начали делать непрерывную интеграцию и доставку приложений. Рассказываю, зачем мы это делаем, какие технологии используем, сколько денег тратим, как повторить, что планируем улучшить.
02.07.2019 Читать на Medium
В манифесте Приложений двенадцати факторов говорится, что конфигурация должна быть отделена от кода. В первоисточнике сказано:
Конфигурация приложения – это все, что может меняться между развёртываниями (среда разработки, промежуточное и рабочее развёртывание). Это включает в себя:
Первое, что хочется сделать — просто хранить конфигурацию как константы внутри кода. Но этот путь сопряжён с некоторыми опасностями. В такой ситуации параметры просто обязаны попасть в систему контроля версий. То есть, как минимум вся команда разработки получит доступ к реальным ключам, паролям и токенам.
Есть простой способ определить, все ли в порядке с вашим способом конфигурирования приложения. Представьте, что весь репозиторий стал общедоступным, если вас это не пугает — все в порядке.
Правильный путь доставлять конфигурацию на боевые сервера — переменные окружения. Их легко передать в приложение, нет опасности случайно добавить секреты в репозиторий, одни плюсы.
Но работать с переменными окружения на локальном компьютере не удобно. Поэтому, для разработки часто используют .env файлы и специальные библиотеки, которые помогают подменить настоящее окружение на содержимое такого файла.
Остаётся ещё вопрос, как передавать конфигурацию при тестировании. Не хочется создавать кучу .env файлов на разные тестовые кейсы. Обычно, это обходят каким‑то образом изменяя окружение приложения во время выполнения тестов.
Итак, в большинстве приложений есть три варианта развёртывания:
.env файлы;Хочется иметь способ удобно работать с этими тремя (да и вообще любыми) случаями. Такой способ — создание некой абстракции над конфигурацией, конкретная реализация которой будет различаться в зависимости от окружения.
Важно добиться того, чтобы приложение не зависело от конкретной реализации (ключевые слова — инверсия зависимостей, внедрение зависимостей). Тогда все будет безопасно и удобно.
В мире PHP есть отличное решение — Symfony Config Component. Эта библиотека умеет делать все что нужно для конфигурации приложений. Она вдохновила меня на создание @solid‑soda/config — абстракции над конфигурацией, которая предоставляет удобный и безопасный интерфейс для доступа к параметрам в Node.js.
Библиотека включает в себя набор вариантов конфигурации (.env файлы, любые другие файлы, переменные окружения, константы внутри кода) и общий для них интерфейс. При необходимости можно легко добавить свою реализацию и использовать её как встроенную.
Конфигурация приложения — место где код встречается с реальным миром, необходимо позаботиться о безопасности значений. Поэтому библиотека явно требует выбрать стратегию работы с несуществующими значениями — либо передать значение по умолчанию, либо согласиться на выбрасывание исключения.
Конфигурация приложений — один из самых важных аспектов разработки. Это место, где постоянно происходят утечки секретных данных, тормозится процесс внедрения непрерывной доставки, случаются сложно отлавливаемые рантайм‑ошибки. Забота об этом — необходимость при разработке любого приложения.
11.05.2019
Современный веб пронизан фреймворками. Это не плохо! Проекты запускается быстро, а поддерживать их легко. Но иногда стоит избегать использования сторонних решений.
Сайты должны быстро грузиться при любом интернете и хорошо работать на любом устройстве. Если сайт маленький, то добиться этого легко отказавшись от фреймворков и используя только HTML/CSS/JS.
Довольно просто построить статический сайт быстро, не потерять в поддерживаемости и качестве кода.
Обычно, когда берут генератор статики на React (Vue, etc), хотят получить удобный компонентный подход. Есть способ добиться аналогичного результата без такого большого оверхеда. Для повторного использования разметки лучше взять любой шаблонизатор (twig, pug) и делать в нем миксины. CSS же отлично изолируется БЭМ‑нотацией или CSS-модулями (да, и их можно использовать просто так).
Отказ от фреймворка не означает возвращение в прошлое. Можно все ещё использовать современные возможности JS и CSS, и обрабатывать их Babel и PostCSS (а для разметки возьмите PostHTML).
Хитрый шаблонизатор, пост‑процессоры и транспайлеры нужно как-то удобно запускать, чтобы на выходе получать набор файлов понятных любому браузеру. Тут можно взять абсолютно любой бандлер, но лучше посмотреть на максимально простые в конфигурации — Parcel, Rollup.
Построение таких сайтов изменяет мышление и будет полезно любому фронтенд разработчику. Попробуйте!
25.03.2019
Деньги везде. Банковские приложения, интернет‑магазины, платформы для фондовых бирж, мы встречаемся с деньгами каждый день. И все чаще мы доверяем работу с деньгами технологиям. Перевод статьи о частых ошибках и принятых шаблонах при работе с денежными значениями.
23.01.2019 Читать на Medium
Я часто делаю npm‑пакеты. Это не моя основная работа, потому хочется тратить минимум времени и сил. После публикации пакет нужно поддерживать, хочется минимизировать и эти затраты. Статья о процессе и используемых инструментах.
18.01.2019 Читать на Medium
В процессе чтения книги Дядюшки Боба «Чистая архитектура» писал себе заметки. Для удобства собрал их в единый конспект. О ценностях программы, парадигмах в программировании, принципах SOLID и важности тестирования.
05.12.2018 Читать на Medium
Частая причина трудностей внесения изменений в программу — плохая архитектура. Программисты переусложняют код, потому что решают не реальные проблемы, а интересные им. Перевод статьи о воображаемых проблемах при проектировании ПО.
07.11.2018 Читать на Medium