Роман rpiontik

Интригующее название — существенная часть успеха статьи. Именно оно заставляет читателя потратить свое драгоценное время на твой труд. Но нужно быть осторожным. Добившись доверия, можно “жестоко” поплатиться, не удовлетворив качеством чтива.

Почти год назад я представил свой pet-проект — IoT платформу ThingJS. Честно сказать, я не достиг всех целей, которые ставил перед собой публикуя ту статью. Но работа окупилась. Удалось получить нечто иное — полезную критику.

Я учел прошлый опыт. Теория без практики заходит плохо. В этот раз презентация будет построена на базе прикладного решения. Каждый сможет “потрогать” его и использовать в быту.

Статья направлена на диалог о необходимости архитектора в команде. Она будет интересна тем, кто задумывается о пути своего развития, когда “все дороги уже исхожены”. Когда имеющийся богатый опыт делает твою работу “неэффективной” с точки зрения коллег. Когда тебя уже почти ничего не удивляет и каждый следующий проект это дежа вю. Ты выгораешь.

Сижу я вчера спокойно, как водится никого особо не трогаю. Тут с двух разных контактов, почти одновременно присылают ссылку на небезызвестный твит про JSON из SQL. Одно из сообщений выглядело так:

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

Уверен, что заголовок вызвал здоровую реакцию — “ну опять началось…” Но позвольте завладеть вашим вниманием на 5-10 минут, и я постараюсь не обмануть ожидания.

Структура статьи будет такова: берется стереотипное утверждение и раскрывается “природа” возникновения этого стереотипа. Надеюсь, это позволит взглянуть на выбор парадигмы обмена данными в ваших проектах под новым углом.

Для того, чтобы была ясность в том, что такое RPC, предлагаю рассматривать стандарт JSON-RPC 2.0. C REST ясности нет. И не должно быть. Все, что нужно знать о REST — он неотличим от HTTP.

Последние два года я разрабатывал собственную IoT платформу и сегодня готов показать ее альфа версию.

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

Статья будет интересна людям, которым близка тема IoT и они уже что-то делали в этой сфере. Важным замечанием будет то, что платформа должна заинтересовать (внезапно) JavaScript разработчиков, т.к. именно этот язык выбран как основа платформы. Конечно, и С/С++ разработчикам тоже будет что почитать.

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

Я увлеченный человек. ИТ, несомненно, является основным увлечением. Но параллельно у меня появляются другие. Домашние животные, квартира, стройка. Везде я пытаюсь что-то заоверхедить. Одним из таких оверхедов стала разработка LED светильников для аквариума.

Казалось бы — что такого можно тут сотворить? Лампа лампой. Я тоже так думал. Но, как всегда, все гораздо сложнее, если мы этого захотим.

С момента моей регистрации на Хабре у меня было ощущение какой-то недосказанности в статьях. Т.е. вот есть автор, вот его статья = мнение… но чего-то нет. Чего-то нехватает… Спустя время я понял, что недостает критического взгляда. В целом, его можно найти в комментариях. Но у них есть существенный минус — альтернативное мнение теряется в общей массе, оказывается фрагментарным и приносит скорее больше “риски” для его автора чем пользы. Предлагаю рассмотреть эту проблему подробнее.

Сегодня я предлагаю затронуть вопрос ручного тестирования проектов на VueJS.

Независимо от уровня автоматизации процессов тестирования, практически всегда остается “живое общение” тестировщика с будущим релизом. Естественно, что оно должно быть комфортным и эффективным.

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

Это, пожалуй, будет самая короткая моя статья. Более того, сама идея очевидная.

Часто в WEB проектах возникают задачи доставки статики на прод вне релизов. Например, нужно выложить файлы для SPA с маркетинговой информацией: актуальные комиссии, свежий FAQ и т.п.

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

Однажды пришла идея использовать git для доставки маркетинговой статики на прод. Т.е. файлы все также генерируются в админке, затем они автоматом комитятся под пользователем, который их сгенерировал и пушатся в отдельную, маркетинговую репу.

А далее, работает привычная магия CI/CD git.

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

Давно я хотел написать эту статью. Все думал — с какой стороны зайти правильнее? Но, вдруг, недавно, на Хабре появилась подобная статья, которая вызвала бурю в стакане. Больше всего меня удивил тот факт, что статью начали вбивать в минуса, хотя она даже не декларировала что-то, а скорее поднимала вопрос об использовании кодов ответа web-сервера в REST. Дебаты разгорелись жаркие. А апофеозом стало то, что статья ушла в черновики… килобайты комментариев, мнений и т.д. просто исчезли. Многие стали кармо-жертвами, считай, ни за что :)

В общем, именно судьба той статьи побудила меня написать эту. И я очень надеюсь, что она будет полезна и прояснит многое.

Предупреждаю, все ниже написанное является реальным опытом, а не когнитивной эквилибристикой. И так, погнали.

Одна из проблем, которая возникает перед WEB-ресурсами имеющими персональные кабинеты — атака перебором. Да, простой перебор всех вариантов пароля для конкретной учетки. Тупо? Возможно, но такая атака может сильно нагрузить ресурс. К тому же, если контроля сложности пароля пользователя при регистрации нет, она может оказаться еще и успешной.

Чаще всего, вопрос решается относительно просто. Если пользователь ввел несколько раз неправильно пароль, его учетка блокируется на какое-то время. Альтернативное решение — выводить капчу. Сразу, или после нескольких неудачных попыток. Ну, и не забудем про 2F авторизацию, которая почти неуязвима. Казалось бы — профит! Но, не все так радужно…

Ключевой задачей высоконагруженных WEB-систем является способность обработать большое число запросов. Решить эту проблему можно по-разному. В этой статье я предлагаю рассмотреть необычный метод оптимизации запросов к backend через технологию content-range (range). А именно — сократить их количество без потери качества системы путем эффективного кеширования.

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

1. REST-интерфес;
2. WEBSocket broadcast subscription.

Метод REST зачастую используется для получения исторических данных, в то время, как по WEBSocket рассылается актуальная информация в режиме online. В некоторых случаях WEBSocket вообще не используется, а обновление происходит регулярными запросами через REST.

И вроде все довольны. Но, при более детальном рассмотрении, становится очевидными огромные накладные расходы на такую концепцию. Их основная масса ложится на REST. Для обеспечения функционирования REST-интерфейса мы должны создать backend отвечающий требованиям высоконагруженных систем. Естественно, тут можно выбирать различные варианты решения от PHP до нынче модного Golang.

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