Айтишник обыкновенный 🐰

Мне одному смешно?)

#юморэзки

Timeout Backoff

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

Это позволяет снизить нагрузку на сервера при недоступности или прочих ошибках.

Так первый ретрай будет, например, через 5мин, следующий через 30мин, потом через час и тд

#словодня

#юморэзки

UDP - User Datagram Protocol

Протокол для передачи данных. Работает производительно, но имеет ряд проблем, включая то, что в меме)

#словодня и #юморэзки

#юморэзки

Solution concept

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

В таких случаях классно выручает solution concept. Это как аналитика, только написанная не по конкретным таскам(задачам), а непосредственно на всю большую доработку/разработку. Это как представление о том, что должно в итоге получиться, из чего состоит, что применяется и тд.

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

#словодня

Забавно, конечно, что душные экспертные посты собирают гораздо меньше отклика, чем мемы😂😂😂

Причем не только дело в реакциях, а еще в количестве подписчиков, в моменте после постов про XSD отписок стало больше😂😂😂

После этого начинаешь задумываться, может просто мемы постить в канал?😂😂😂

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

Немного не про айти, а про то, как важно делать регулярные маленькие шаги на пути к цели.

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

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

Так что вывод такой, мотивация временна, а цель вечна(ну почти, цели иногда нужно тоже переосмыслять и корректировать, но это уже другая история)

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

#быстростатья

BPMN — это нотация (или метод, хотя почти везде пишут «система») моделирования или описания бизнес-процессов. Бизнес-процесс представляет из себя логику (алгоритм) работы системы для достижения поставленной задачи.

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

В отдельных случаях с помощью BPMN прорабатывают сложные процессы: разработчик проектирует процесс, описывает все условия, пробрасывает потоки и т. д. Для этого есть специальные среды разработки, например, Tibco BPM и Camunda BPM.

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

#словодня

#юморэзки

SSE

Server-Sent Events - технология для отправки сообщений от сервера клиенту, строится поверх обычного HTTP. Очень похоже на работу вебсокетов за исключением того, что взаимодействие однонаправленное, сообщения шлет только сервер клиенту.

#словодня

Итак, подведу итог быстростатей по XSD.

Почему же XSD все-таки занимает отдельное место в моем сердце?

Потому что это функционально, много вариаций для создания документа вообще какого угодно формата и структуры. Если потратить время и разобраться в XSD, то это станет крутым инструментом для создания чего угодно, НО... К сожалению, как я писал выше, XML умирает, его высокая функциональность повышает порог вхождения, как следствие – «‎ааааа, слоооожна»‎.

Поэтому сейчас везде используется стильный модный молодежный – Иосиф Сталин Отец Народов(JSON)

Что интересного тут еще есть, поле inn имеет кастомный тип, который "базируется" на типе string, но имеет определенный паттерн, описанный с помощью регулярного выражения. Таким образом мы получили обязательное поле, которое будет валидно только в том случае, если его заполнить 12-ю или 10-ю цифрами.

Кстати, об обязательности, тут я устраивал викторины про minOccurs и maxOccurs. minOccurs отвечает за минимальное количество повторений элемента, а maxOccurs – за максимальное. По умолчанию значения этих атрибутов равно единице. А теперь на нашем примере, что это означает?
⏩Все поля без этих атрибутов являются обязательными;
⏩Все поля с minOccurs=0 являются необязательными;
⏩Поле contact является необязательным массивом.

Еще хочу обратить внимание на "индикаторы" sequence и all. Эти индикаторы отвечают за установку порядка. То есть при использовании sequence элементы четко закреплены за своими местами(имеют обязательную последовательность), соответственно их нельзя менять местами. При использовании индикатора all поля могут идти в любом порядке. Для наглядности в примере XML взгляните на элементы внутри user, они как объявлены в XSD, так и идут в примере. Далее взгляните на массив contactList, который используется с индикатором all, видно как поля type и value чередуются и это абсолютно корректно.

Помимо этих 2 индикаторов порядка еще есть choice, который тоже очень удобен и используется как оператор "исключающего ИЛИ". То есть в примере, если бы вместо all использовался choice, то в XML был бы либо элемент type, либо элемент value. choice очень удобно использовать, когда одна XSD используется для описания всех API микросервиса. Например:

<xs:choice>
  <xs:element name="GetClientDataByIdRequest" type="GetClientDataByIdRequestType" />
  <xs:element name="GetClientDataByIdResponse" type="GetClientDataByIdResponseType" />
  <xs:element name="SendNotificationRequest" type="SendNotificationRequestType" />
  <xs:element name="SendNotificationResponse" type="SendNotificationResponseType" />
  <xs:element name="CheckClientRequest" type="CheckClientRequestType" />
  <xs:element name="CheckClientResponse" type="CheckClientResponseType" />
</xs:choice>

Еще из интересного, в 2 местах схемы я использовал Enum'ы. Суть примерно та же, что и у элемента inn, поле также базируется на типе string, однако вместо паттерна, используется ограничение в виде возможных вариантов заполнения. Например, поле type элемента contact, может быть заполнено исключительно тремя значениями:
🟢EMAIL
🟢PHONE
🟢TELEGRAM

Конечно же, в XSD-схему можно добавлять описание для полей. Делается это так:

  <xs:annotation>
    <xs:documentation>Текст с описанием элемента</xs:documentation>
  </xs:annotation>

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

 <xs:element name="product">
    <xs:complexType>
        <xs:simpleContent>
            <xs:restriction base="xs:string">
                <xs:attribute name="coast" type="xs:boolean" use="required"/>
                <xs:attribute name="sale" type="xs:boolean"/>
                <xs:attribute name="size" type="xs:integer"/>
                <xs:attribute name="model" type="xs:string"/>
            </xs:restriction>
        </xs:simpleContent>
    </xs:complexType>
  </xs:element>

А вот так это будет выглядеть в XML-примере:

<product coast="12000" sale="false" size="24" model="Asus">Монитор</product>

Но я считаю, что использование атрибутов, хоть и круто расширяет возможности XML относительно формата JSON, зато по факту ухудшает читаемость(не всегда и везде, но ухудшает), а также заведомо запрещает формировать JSON на основе схемы.
PS, да-да не смотря на то, что XSD используется в первую очередь для описания структуры сообщения/запроса в формате XML, но на самом деле на его основе можно также формировать и JSON. Ты по сути указываешь программе структуру документа – XSD, а далее говоришь в какой формат эту структуру зарендерить – XML или JSON.

#быстростатья часть 2

Проснулся сегодня и почувствовал неистовое желание рассказать подробнее про XSD 😂

Так что, рассказываю.
Вот небольшой пример описания схемы:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:element name="user">
    <xs:complexType>
      <xs:complexContent>
        <xs:extension base="personType">
          <xs:sequence>
            <xs:element name="inn">
             <xs:simpleType>
              <xs:restriction base="xs:string">
               <xs:pattern value="\d{12}|\d{10}"/>
              </xs:restriction>
             </xs:simpleType>
            </xs:element>
            <xs:element name="contactList" type="contactListType" />
          </xs:sequence>
        </xs:extension>
      </xs:complexContent>
    </xs:complexType>
  </xs:element>

  <xs:complexType name="personType">
    <xs:sequence>
      <xs:element name="firstname" type="xs:string" />
      <xs:element name="secondname" type="xs:string" />
      <xs:element name="patronymic" type="xs:string" minOccurs="0" />
      <xs:element name="gender" minOccurs="0">
        <xs:simpleType final="restriction" >
          <xs:restriction base="xs:string">
              <xs:enumeration value="MALE" />
              <xs:enumeration value="FEMALE" />
          </xs:restriction>
        </xs:simpleType>
      </xs:element>
      <xs:element name="age" type="xs:integer" />
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="contactListType">
    <xs:sequence>
      <xs:element maxOccurs="unbounded" name="contact">
        <xs:complexType>
          <xs:all>
            <xs:element name="type">
              <xs:simpleType final="restriction" >
                <xs:restriction base="xs:string">
                    <xs:enumeration value="EMAIL" />
                    <xs:enumeration value="PHONE" />
                    <xs:enumeration value="TELEGRAM" />
                </xs:restriction>
              </xs:simpleType>
            </xs:element>
            <xs:element name="value" type="xs:string" />
          </xs:all>
        </xs:complexType>
      </xs:element>
    </xs:sequence>
  </xs:complexType>
</xs:schema>

Вот пример XML, который будет сформирован на основе примера схемы выше:

<user xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <firstname>Иван</firstname>
    <secondname>Иванов</secondname>
    <patronymic>Иванович</patronymic>
    <age>30</age>
    <inn>1234567890</inn>
    <contactList>
        <contact>
          <value>8(909)999-99-99</value>
          <type>PHONE</type>
        </contact>
        <contact>
          <type>TELEGRAM</type>
          <value>default_itshnik</value>
        </contact>
    </contactList>
</user>

В схеме я постарался по-максимуму задействовать функционал XSD для наглядности его возможностей(конечно же, не всех, только основных и часто используемых). Не смотря на то, что принято считать, что XML медленно, но верно умирает(соответственно и XSD тоже), в моем сердце они занимают отдельное место. Сейчас я расскажу, почему)

Но сначала давайте разберем схему, уверен, далеко не все владеют синтаксисом даже на моем(не столь высоком) уровне. Схема состоит из трех основных объектов: элемента user и двух типо personType и contactListType. user здесь корневой и основной элемент XSD, который расширяется типом personType. Сам user содержит в себе только 2 элемента inn и contactList, а расширение типом personType добавляет базовые поля личности: ФИО, пол, возраст.

#быстростатья часть 1

BABOK(a guide of the Business Analysis Body Of Knowledge) – пожалуй, самое известное руководство по бизнес анализу. Есть книга с первой версией, второй и третьей. Стоит огромных деняк…

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

Пс, спасибо GigaChat)

А ещё в нём много умных слов, так что читать его очень скучно. Сколько раз не пытался прочитать, постоянно заканчивал где-то близко к началу…

Возможно, у меня в канале есть ребята, которые осилили эту книгу, поделитесь в комментах, оно стоит того, возможно стоит выделить отдельные главы?

#словодня

API-first

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

#словодня

Монолит

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

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

#словодня

JSONB

Как JSON только бинарный – JavaScript Object Notation Binary. Формат, который используется для хранения JSON в БД PostgreSQL. При выполнении INSERT и UPDATE строка с JSON преобразуется в двоичную. При этом при SELECT’ах такого столбца можно увидеть изначальное значение(не двоичное).

#словодня