Записи доклада пока нет, зато есть вот такая короткая выжимка :)

Полезные материалы про API: SOAP, RPC, REST

Недавно собирал для своих аналитиков небольшую лекцию про REST, SOAP и RPC. По мотивам лекции собрал список материалов, который советую для прочтения. Делюсь и с вами :)

1. Диаграма принятия решений об HTTP статусе в ответ на запрос: тут. Крутая очень шутка, которая маскимально подробно визуализирует логику выбора кода ответа HTTP. Красивое!
2. Отличная статья на хабре от AvitoTech про структуру HTTP запроса и ответа.
   Внутри есть ссылки на разное около сетевое.
3. Про SOAP от Школы Системного Анализа. Подробно, с кейсами и отвечами почему и зачем. Понравилось.
4. Про REST от школы системного анализа читать здесь. Достаточно прикладной материал, где есть куча всего, что почитать и потрогать вокруг RESTа.
5. Модель зрелости Ричардсона
6. Статья-сравнения разных архитектурных стилей интеграции (SOAP vs REST vs RPC vs GraphQL) на медиуме. В РФ работает только под ВПН

Сделай это прямо сейчас и это сэкономит тебе часы в будущем

Кликбейтный заголовок для того, чтобы вы прямо сейчас встали и включили логирование буфера обмена на Windows, если вы этого не делали ранее.

Нажатием на сочетание кнопок Win+V можно включить логирование содержимого вашего буфера обмена и это не раз спасет вас, когда в нем затеряется что-то важное. После того, как вы активируете эту функцию, вы сможете обратится к истории вашего буфера обмена на Win+V.

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

PS. Еще есть очень интересная особенность инфополя аналитиков. У нас есть много очень крутых ребят с огромным опытом. И при этом эти ребята делятся своим опытом в публичном поле и делают это чертовски круто :)

Хорошо, что такие материалы есть, я часто искренне поражаюсь тому, как многие вещи, которые я выявляю из своей работы — уже кто-то описал емко и полно. Это круто! Читаешь, и думаешь: почему же я раньше то не нашел такого материала?

Не круто только то, что твой контент с базовыми вещами не будет уникальным, потому что кто-то сделал это уже лучше тебя. Здесь просыпается синдром самозванца.
Иногда он может сковывать меня и говорить: «Сережа, не публикуй, это же уже есть». Внутри себя я сошелся на том, что в таких случаях я могу ~~паразитировать на них~~ продавать крутые статьи таких ребят и добавлять в них свои смыслы.
Зачем? Потому что не все знают о таких простых истинах, несмотря на то, что о них говорят в инфополе такие талантливые и опытные специалисты :) При этом в нашей сфере всегда есть, что добавить с призмы своего опыта и это ценно.

Кстати, так произошло и с постом выше, ведь есть крутая статья (и видео внутри) у Systems Education от Юрия Куприянова про стоп-слова в требованиях.

С уважением и восхищением отношусь к Юрию и его работам, это можно заметить по моему количеству цитирований его выступлений или статей.
Однажды я аж вычеркнул из своего контент-плана пост на тему красных флагов в текстах, потому что круче уже не скажу. А сейчас передумал и понял, что у меня есть, что к этому добавить, да и не страшно поделиться такой крутой статьей с вами :)

Не писать же мне еще одну статью про то, что такое REST под видом очень экспертного мнения профессионала, когда литературы и статей на этот счет уже пруд пруди, но все упорно делают вид, что такой контент реально полезный?)

systems.education

Стоп-слова как маркер проблем в требованиях

ЮРИЙ КУПРИЯНОВ

Про маркеры, по которым я замечаю неопытных аналитиков

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

Один из самых простых маркеров для меня: формулировки, который использует аналитик. Эти маркеры не единственное, что влияет на то, как я оцениваю действия аналитиков. Но, по крайней мере, при появлении этих маркеров в тексте — я начинаю сомневаться в уровне компетенций.

Представляю мой субъективный топ-5, который неявно триггерит меня при прочтении документов от других аналитиков. Возможно, он поможет посмотреть на свои постановки иначе)

1. Страдательный (пассивный) залог.

Гиперболизированный пример: запрос пользователя обрабатывается, сообщается результат пользователю.

Данные ниоткуда не появляются сами по себе и никуда просто так не исчезают. У любых изменений, как объекта, есть субъект, который эти изменения спровоцировал. И именно аналитик должен понимать, что или кто выступал в качестве субъекта изменений. Иначе получим «Хочу то, не знаю что».

2. Избыток сложных предложений ИЛИ однородных предложений в тексте.

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

3. Причастия. Изобилие причастий. Деепричастия.

Например: Проанализировав федеральный закон #123, обязывающий наших клиентов хранить данные, собранные от пользователей своих систем...

Причастия и деепричастия заменяют глаголы, усложняют конструкцию предложения и мешают чтению.
Фразу из примера можно переписать так:

Мы проанализировали федеральный закон #123, который обязывает наших клиентов хранить данные своих пользователей.

И текст сразу стал понятнее.

4. Субъективные и неизмеримые оценочные суждения.

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

За такими суждениями часто стоят догадки и неопределенность, так как у автора нет понимания целевых и измеримых значений.

5. Сложные логические конструкции.

В этот блок можно вынести все издевательства над логическими суждениями. Сюда можно отнести:
а. неоднозначный набор условий: пользователь должен указать свой email и ФИО или адрес)
б. неоднозначные условия с двойной трактовкой: пользователь должен заполнить поле ФИО и/или ИНН
в. двойные отрицания: нужно выбрать не неотправленные сообщения.

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

Про канал, его состояние и что происходит

Несмотря на долгую мою спячку в контенте, вижу, что есть поток новых подписчиков. Добро пожаловать, рад всех вас тут видеть ❤️

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

Кидать мемы и короткие посты про общеизвестные истины вида "Что такое REST API?" не хочу, потому что среди каналов есть те, кто делают это сильно чаще.

Как и писал в первом посте — концентрироваться здесь я буду на своем взгляде на мир, делиться мнением, успехами и неудачами.

Поэтому здесь вы можете видеть иногда репосты из других каналов, где кто-то уже так круто описал и рассказал о теме, что мне и остается только комментировать :)

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

Если у вас есть конкретные запросы разобрать ту или иную тему — о них можно написать:
1. мне в личку (@xvxshx);
2. в чат канала;
3. в комментарии.

Всем хороших выходных ?‍?

Telegram

Шуршание в кладовке аналитика

Чат с обсуждениями. Канал @analysts\_storeroom

GPT заменят аналитиков?

Вообще, мне казалось, что эти дискуссии утихли, пока мне лично не стали задавать вопросы об этом :)

Написал небольшую статью со своим ответом на волнующий многих вопрос

Telegraph

GPT заменят аналитиков?

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

Хардскиллы системных аналитиковНа хабре опубликован пост, в котором есть буквально БОЛЬШИНСТВО из того, что нужно знать в теории системного дизайна. Или, как принято говорить, основы "хардов системного аналитика". Прочитать можно по ссылке.

Сами по себе эти знания без практики вам вряд ли могут помочь, но как шпаргалка — вполне.

Впервые, если честно, вижу такой обширный материал, где все по полочкам, без воды. Рекомендую однозначно.

Хабр

System Design 101

О сложных системах простыми словами. В шпаргалке на высоком уровне рассматриваются такие вещи, как протоколы коммуникации, DevOps, CI/CD, архитектурные паттерны, базы данных, кэширование, микросервисы...