понедельник, 11 февраля 2019 г.

Cross-services communication

Recently I was involved in short but efficient discussion on the topic, and decided to consolidate some thoughts here.

In very short there are 3 kinds of communication types between services:
  • Query
  • Command
  • Event
Additionally, there can be synchronous and asynchronous implementations.
 
Event is async by nature. Query can be either sync or async in general though it's more about sync interaction (heavy async Query should be refactored in Command in most cases). Command is ok for both.

Sync calls are usually done via RPC, i.e. via REST. Asyn calls are better via Topics or Queues (of course one can implement them through REST as well though it's usually over complicated).
 
Context for Command - many producers, one consumer (I mean anatomically, even if there are several instances of the same logical consumer); therefore guaranteed delivery and retry in case of consumer failure are required.
 
Context for Event - one producer, many consumers. Consumers can be online or offline at the moment of events firing, but nevertheless they are interested to receive events. Guaranteed delivery and messages order are also important.
 
Therefore,
Message Brokers fit Commands since they had been created exactly for these needs. In addition, there are plenty of libraries to achieve required metrics.
Kafka is very ok for Events since it's easy, straightforward, and provides configurable retention time; guaranteed delivery and correct order are available by design.

It is possible to implement Events via Message Brokers and Commands via Kafka though it seems to be not the common way.

So, finally

понедельник, 27 марта 2017 г.

Интеграция с Google reCaptcha

Капча - один из очень распространённых и часто используемых способов для защиты приложений от атак.
Существуют различные имплементации капчи, от сторонних вендоров до собственных вариантов. При этом предложение от Google'а - reCapthcha - выглядит весьма привлекательным. Аргументы "за":
  • достаточно известный вендор ))
  • хороший экспириенс как для пользователей (не очень сложно), так и для компании (достаточно безопасно)
  • есть WCAG-compliance 
  • простая интеграция в приложение буквально в несколько действий.
Именно об интеграции и пойдёт речь дальше.

четверг, 23 марта 2017 г.

Тренинги Software Engineering Institute

За последнее время я прошёл несколько тренингов от Software Engineering Institute по архитектуре программного обеспечения.
Сам SEI как научно-исследовательский центр занимается несколькими направлениями в области управления и разработки программного обеспечения, и software architecture является одним из них. В SEI разработали и активно продвигают такие практики как Quality Attribute Workshop, Architecture Tradeoff Analysis Method и пр. Кроме исследований и практических работ над реальными проектами, SEI предлагает курсы / тренинги, на нескольких из них мне и удалось позаниматься.

среда, 14 декабря 2016 г.

websequencediagrams


Где можно быстро нарисовать секвенс-диаграмму? Один из вариантов ответа - онлайн сервис https://www.websequencediagrams.com/

Ссылку на этот сервис я "подсмотрел" в тренинге Certified ethical hacker от James Conrad, заглянул на сайт, немного "поигрался". И пока доволен тем, что удалось сделать.

В общем, в чём суть-то? Прямо в браузере можно создавать sequence diagrams и сразу же видеть результат.
Доступен набор предустановленных вариантов (виджеты?), например, простой вызов, вызов с возвратом, альтернативные / опциональные блоки и т.п., к которым можно добавлять и заметки. Виджеты можно перетягивать на рабочее поле, корректировать лэйблы и описания и двигаться дальше.
Все подобные графические варианты описываются в собственном простом текстовом формате, который отображается в колонке слева от рабочего поля. В принципе, через короткое время уже можно просто "программировать" диаграмму, а изображение будет отрисовано по этому сценарию.
Результат работы можно сохранить у них в хранилище в своём аккаунте (кстати, кроме отдельного аккаунта на саммом сайте можно зайти под google аккаунтом), можно расшарить линк на диаграмму, распечатать её или экпортировать в виде картинки или pdf файла.
Также доступны различные стили, от строгого до близкого к рукописному. 

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

В общем, в настоящее время пользуюсь сам и вполне рекомендую!

пятница, 25 ноября 2016 г.

Quote of the day

Не надо ничего придумывать, практически всё уже придумано, нужно выбирать, но не надо считать, что выбирать просто. Выбирать очень сложно. По-моему, выбирать сложнее, чем придумывать, это нужно делать с большой осторожностью.
И когда вы сделали свой выбор, проблемы будут. Мой опыт показывает, проблемы будут. Но не бойтесь их, будьте уверены в своём решении и старайтесь с вашим решением все эти проблемы превозмочь.
Павел Филонов, цитата из выступления на HighLoad++

Источник: https://habrahabr.ru/company/oleg-bunin/blog/310418/ 101 способ приготовления RabbitMQ и немного о pipeline архитектуре

пятница, 18 декабря 2015 г.

Неуспешный стартап и полученный опыт

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

Чуть больше месяца назад закрыл "свой" стартап. Проект был небольшой, в команде всего 4 человека (бэкэнд, мобильное приложение, веб, администрирование окружения). Какой же опыт я извлёк из этого "способа, который не сработал"?

* Начинать стартап там, где уже есть рынок и конкуренты - вовсе не означает заведомый проигрыш. Это следует из дисциплины маркетинга и подтверждается жизненным опытом.
Ведь в противоположном случае на рынке было бы только по одному игроку в каждом сегменте, а это не так.
Новый игрок на рынке может занять более узкую нишу, отвоевать свою долю и т.д. - используя классические маркетинговые стратегии и любую их комбинацию.
Конечно, не стОит воспринимать совет буквально - задумка написать второй facebook или linkedin, пожалуй, окажется безрезультатной (хотя и такие попытки регулярно встречаются).
Но в любом случае, если идея не является абсолютно новой (что бывает крайне редко), то это не повод думать, будто ничего не выйдет. 

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

* Люди - участники стартапа - должны "гореть" идеей, желанием и стремлением. Именно это является в стартапе одним из важнейших конкурентных преимуществ. Именно это позволяет "догнать и перегнать".
Пожалуй, это вообще самая главная особенность стартапа и необходимое требование для его успеха.
В общем, стартап - это не 8-мичасовой рабочий день. И вообще, он не измеряется рабочими часами.

*  Ещё - д.б. классные разработчики. Не узкая специализация и фразы "а как же без макетов?", а работа один-за-всех / все-за-одного. И небольшая команда, люди в которой подходят друг к другу в плане совместимости.

* Стартап должен быть быстрым и активным.
Возможно, в определённых случаях этот пункт не подходит. Но мне кажется, что нужно стремиться к как можно более быстрой реализации продукта, чтобы сразу же получить фидбэк и понять, в правильном ли направлении мы движемся, товарищи. 
Если "идёт" - продолжать работу. Если "не идёт" - бросать сразу же. Потому что бросать через год - намного более жалко.
Долго раскачиваться, долго обсуждать какие-то будущие фичи, сразу закладываться на огромный трафик и поток запросов - значит, впустую тратить время и силы.
Да, если стартап "взлетит", сервис может "лечь" под нагрузкой. Да, приложение может оказаться неприспособленным для лёгкого внесения изменений. 
Но "вылизанное" с технической точки зрения приложение может просто быть никому не нужным.

И в заключение - процитирую слова одного из участников, сказанные им после закрытия проекта:
"Никого не хотел обижать, но был уверен, что к этому придем, с самого начала. Увы. :("
Эти слова "сделали мой день"...
Так что - заметка мне самому и совет другим - людей с подобными настроениями надо выявлять как можно раньше и держаться от них подальше, всем лучше будет.

вторник, 10 ноября 2015 г.

Unsupported major.minor version

Порой при запуске java класса/jar/приложения и т.д. можно "словить"
java.lang.UnsupportedClassVersionError: название класса :
 Unsupported major.minor version 51.0
Причина заключается в том, что класс был скомпилирован на версии jdk более новой, чем та, на которой этот класс теперь запускается. Например, скомпилирован на 1.7, а запускается на 1.6 и т.п.

Узнать текущую версию jdk можно консольной командой java -version

А вот как определить, какой версии class-файл? Узнать версию jdk, использованную при компиляции, можно по числу в описании ошибки (51, 50 и т.п.) или по самому class-файлу. Любой класс имеет определённую структуру (детали - в документации по его формату, например, https://docs.oracle.com/javase/specs/jvms/se6/html/ClassFile.doc.html#80959). В частности, начало выглядит примерно так:
CA FE BA BE 00 00 00 2E
Файл начинает с magic number CAFEBABE, а за ним следуют два short-а, составляющие minor и major части версии соответственно.
Поэтому можно открыть class-файл в hex-редакторе, найти значение и определить версию по следующей таблице: