#анализ
Среда 7 июля в 19:00
Люблю критику, ибо она часто помогает понять, как улучшить нашу работу. Вечером в среду Филипп поделится фидбеком, который мы сможем вместе обсудить, присоединяйтесь😏
Первую часть проведем в формате интервью, вторую - в режиме общей дискуссии.
https://compractice.timepad.ru/event/169456
Среда 7 июля в 19:00
Люблю критику, ибо она часто помогает понять, как улучшить нашу работу. Вечером в среду Филипп поделится фидбеком, который мы сможем вместе обсудить, присоединяйтесь😏
Первую часть проведем в формате интервью, вторую - в режиме общей дискуссии.
https://compractice.timepad.ru/event/169456
compractice.timepad.ru
Почему системный аналитик в компании - это bad smell? И что мы можем с этим сделать? / События на TimePad.ru
Почему системный аналитик в компании — это bad smell? И что мы можем с этим сделать?
Уже через час обсудим с Филиппом проблемы при работе с аналитиками, подключайтесь
https://us02web.zoom.us/j/89499320249
https://us02web.zoom.us/j/89499320249
#анализ #манагерское
Почему системный аналитик в компании - это bad smell?
https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:
⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.
В сухом остатке получается, что привлечение системных аналитиков вполне оправдано, если нет возможности менять процессы в команде и нанимать профессиональных разработчиков. Самим же аналитикам лучше фокусироваться на функциях архитектора или продукта - интересно, что схожие мысли последнее время озвучивали на конференциях Дмитрий Безуглый и Сергей Нужненко.
По итогам хочу еще поисследовать тему с другими представителями индустрии. Кому-нибудь еще интересен такой формат? Дайте знать в комментах, плз.
Почему системный аналитик в компании - это bad smell?
https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:
⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.
В сухом остатке получается, что привлечение системных аналитиков вполне оправдано, если нет возможности менять процессы в команде и нанимать профессиональных разработчиков. Самим же аналитикам лучше фокусироваться на функциях архитектора или продукта - интересно, что схожие мысли последнее время озвучивали на конференциях Дмитрий Безуглый и Сергей Нужненко.
По итогам хочу еще поисследовать тему с другими представителями индустрии. Кому-нибудь еще интересен такой формат? Дайте знать в комментах, плз.
YouTube
Почему системный аналитик в компании - это bad smell? И что мы можем с этим сделать?
Мы много раз слышали о том, зачем проекту или команде нужен системный аналитик. Однако, представители других IT-профессий не всегда разделяют это мнение. Андрей Бураков вместе с Филиппом Дельгядо говорили о том, какие проблемы возникают при работе с системными…
#архитектура
Монументальная подборка материалов от архитектора для будущих архитекторов
https://t.me/bpmn2ru/668
Монументальная подборка материалов от архитектора для будущих архитекторов
https://t.me/bpmn2ru/668
Telegram
BPMN2.ru & Stormbpmn.com
Кто-то в комментариях хочет стать архитектором, вот вам материал. Как все прочитаете и посмотрите - шлите резюме:
DDD:
* Эрик Эванс. Предметно-ориентированное проектирование (DDD).
* Предметно-ориентированное проектирование. Паттерны, принципы и методы…
DDD:
* Эрик Эванс. Предметно-ориентированное проектирование (DDD).
* Предметно-ориентированное проектирование. Паттерны, принципы и методы…
#интеграция #очереди
Очереди и синхронность
Один из классических тезисов, который можно услышать на собесах, что синхронные взаимодействия - это когда используем веб-сервисы, а асинхронные - когда у нас очереди.
Причем мысль об организации асинхронности с помощью веб-сервисов почему-то заходит намного легче, чем синхронные взаимодействия поверх очередей. А ведь выглядит это куда проще (если только ты не разраб).
Здесь рассматривают реализацию с помощью кафки, в начале статьи общее описание идеи со схемками:
https://callistaenterprise.se/blogg/teknik/2018/10/26/synchronous-request-reply-over-kafka/
Может пора доклад запилить на тему?
Очереди и синхронность
Один из классических тезисов, который можно услышать на собесах, что синхронные взаимодействия - это когда используем веб-сервисы, а асинхронные - когда у нас очереди.
Причем мысль об организации асинхронности с помощью веб-сервисов почему-то заходит намного легче, чем синхронные взаимодействия поверх очередей. А ведь выглядит это куда проще (если только ты не разраб).
Здесь рассматривают реализацию с помощью кафки, в начале статьи общее описание идеи со схемками:
https://callistaenterprise.se/blogg/teknik/2018/10/26/synchronous-request-reply-over-kafka/
Может пора доклад запилить на тему?
#интеграция #очереди
Две статьи, чтобы сформировать общее понимание, что такое Kafka, и чем она отличается от других брокеров.
Совсем просто с картинками и выдрами:
https://habr.com/ru/post/563582/
Чуть глубже уже на техническом языке:
https://habr.com/ru/company/vivid_money/blog/534858
Две статьи, чтобы сформировать общее понимание, что такое Kafka, и чем она отличается от других брокеров.
Совсем просто с картинками и выдрами:
https://habr.com/ru/post/563582/
Чуть глубже уже на техническом языке:
https://habr.com/ru/company/vivid_money/blog/534858
Хабр
Как объяснить детям, что такое Apache Kafka за 15 минут с картинками и выдрами
Я учусь иллюстрировать сложные процессы с помощью комиксов. Нашла себе в копилку крутой кейс: как с помощью комиксов про милых выдр можно ребенку объяснить такую сложную штуку как Apache Kafka , и...
👍2👏1
#хантинг
Минутка хантинга на нашем канале.
Ищу в команду сильного бизнес аналитика, который хочет решать проблемы бизнеса. Мы FoodTech проект, который занимается быстрой доставкой продуктов для американского рынка. Это как Вкусвилл, Я.Лавка и Самокат, только на другой стороне океана.
Чем нужно будет заниматься:
⁃ Много общаться с владельцами продуктов и реальным бизнесом: бухгалтерия, закупки, логистика, курьерская служба и т.п.
⁃ Выявлять боли и потребности бизнеса. Не только, когда они сами приходят к нам, но и действовать на опережение
⁃ Автоматизировать существующие процессы и запускать новые сервисы
⁃ Предлагать бизнесу альтернативные способы решения задач, анализировать их сильные и слабые стороны
⁃ Формировать карту развития бизнесов-процессов
⁃ Проектировать метрики, по которым можно отслеживать эффективность процессов и находить в них узкие места
Наши пожелания:
⁃ Самое важное - это стремление находить и предлагать решения бизнес-задач, а не записывать под диктовку со слов бизнеса
⁃ Мы используем Camunda для автоматизации процессов, поэтому полезно знать BPMN, либо быть готовым подружиться с ним
Если интересно, пишите в личку @and_burakov, расскажу все, что интересно.
Минутка хантинга на нашем канале.
Ищу в команду сильного бизнес аналитика, который хочет решать проблемы бизнеса. Мы FoodTech проект, который занимается быстрой доставкой продуктов для американского рынка. Это как Вкусвилл, Я.Лавка и Самокат, только на другой стороне океана.
Чем нужно будет заниматься:
⁃ Много общаться с владельцами продуктов и реальным бизнесом: бухгалтерия, закупки, логистика, курьерская служба и т.п.
⁃ Выявлять боли и потребности бизнеса. Не только, когда они сами приходят к нам, но и действовать на опережение
⁃ Автоматизировать существующие процессы и запускать новые сервисы
⁃ Предлагать бизнесу альтернативные способы решения задач, анализировать их сильные и слабые стороны
⁃ Формировать карту развития бизнесов-процессов
⁃ Проектировать метрики, по которым можно отслеживать эффективность процессов и находить в них узкие места
Наши пожелания:
⁃ Самое важное - это стремление находить и предлагать решения бизнес-задач, а не записывать под диктовку со слов бизнеса
⁃ Мы используем Camunda для автоматизации процессов, поэтому полезно знать BPMN, либо быть готовым подружиться с ним
Если интересно, пишите в личку @and_burakov, расскажу все, что интересно.
#архитектура
Александр Поломодов из Тинькова начал публиковать вводный курс по архитектуре.
https://apolomodov.medium.com/essential-arch-course-intro-693682064cd6
На данные момент доступны 2/5 статей:
Александр Поломодов из Тинькова начал публиковать вводный курс по архитектуре.
https://apolomodov.medium.com/essential-arch-course-intro-693682064cd6
На данные момент доступны 2/5 статей:
• Лекция про архитектуру и архитектора • Лекция про код • Лекция про данные • Лекция про архитектурные стили и распределенные системы • Лекция про распределенный архитектурный процесс и роль архитектора в немMedium
Курс Essential Architecture #Intro
Этой осенью я подписался сделать несколько лекций для вводного курса по архитектуре внутри Tinkoff. Программа курса должна была быть очень…
#интеграция #REST #API
Завершил священный поход на тему REST. Что в итоге получилось:
https://t.me/another_sa/57 - небольшая заметка, с которой все началось
https://youtu.be/DB2SER51mcU - запись вебинара на тему
https://systems.education/what-is-rest - конспект на основе вебинара
Завершил священный поход на тему REST. Что в итоге получилось:
https://t.me/another_sa/57 - небольшая заметка, с которой все началось
https://youtu.be/DB2SER51mcU - запись вебинара на тему
https://systems.education/what-is-rest - конспект на основе вебинара
🔥2
#API #интеграция
OpenRPC
При работе с JSON-RPC API становится больно, когда нужно его как-то задокументировать. В сваггере это делать жутко неудобно, ибо приходится засовывать все методы API под один эндпоинт и использовать вложенные anyOf. Резко теряется информативность и польза от визуализации. Да и не всегда мы используем http как транспорт. Как альтернатива неплохо заходит JSON-Schema, но она позволяет определить только структуру сообщений, а не методы API.
В поисках счастья нашел OpenRPC - детище ребят из эфира, которые решили запилить аналог сваггера для JSON-RPC.
Что внутри:
⁃ https://spec.open-rpc.org - схема для описания JSON-RPC API, предельно похожа на сваггер, только проще. Если писать ручками, то перейти будет довольно просто.
⁃ https://playground.open-rpc.org - удобный редактор, который красиво визуализирует схем и позволяет вызывать реальные сервисы.
Выглядит симпатично, но есть нюанс. С инструментами для генерации схем из кода и наоборот все грустно. Судя по активности в гитхабе и размерам комьюнити, в обозримом будущем ситуация особо не изменится. Так что, единственный сценарий использования OpenRPC - разработка красивых доков ручками. Но кому-то и это может быть полезно.
OpenRPC
При работе с JSON-RPC API становится больно, когда нужно его как-то задокументировать. В сваггере это делать жутко неудобно, ибо приходится засовывать все методы API под один эндпоинт и использовать вложенные anyOf. Резко теряется информативность и польза от визуализации. Да и не всегда мы используем http как транспорт. Как альтернатива неплохо заходит JSON-Schema, но она позволяет определить только структуру сообщений, а не методы API.
В поисках счастья нашел OpenRPC - детище ребят из эфира, которые решили запилить аналог сваггера для JSON-RPC.
Что внутри:
⁃ https://spec.open-rpc.org - схема для описания JSON-RPC API, предельно похожа на сваггер, только проще. Если писать ручками, то перейти будет довольно просто.
⁃ https://playground.open-rpc.org - удобный редактор, который красиво визуализирует схем и позволяет вызывать реальные сервисы.
Выглядит симпатично, но есть нюанс. С инструментами для генерации схем из кода и наоборот все грустно. Судя по активности в гитхабе и размерам комьюнити, в обозримом будущем ситуация особо не изменится. Так что, единственный сценарий использования OpenRPC - разработка красивых доков ручками. Но кому-то и это может быть полезно.
👍1
#API #интеграция
JSON-RPC
Раз уж в комментах спрашивают, то пусть будет и здесь.
Статья для быстрого знакомства с JSON-RPC, плюс его сравнение с REST-like подходом:
https://habr.com/en/post/441854/
Официальное описание стандарта: https://www.jsonrpc.org
JSON-RPC
Раз уж в комментах спрашивают, то пусть будет и здесь.
Статья для быстрого знакомства с JSON-RPC, плюс его сравнение с REST-like подходом:
https://habr.com/en/post/441854/
Официальное описание стандарта: https://www.jsonrpc.org
Хабр
REST? Возьмите тупой JSON-RPC
В последнее время на Хабре разгорелось много споров по поводу того, как правильно готовить REST API. Вместо того, чтобы бушевать в комментариях, подумайте: а н...
👍2
#анализ
Наконец-то, кто-то написал, кем является бизнес-аналитик на самом деле, и чем он занимается:
“Таким образом аналитик в такой компании-подрядчике анализирует не бизнес, и даже не процессы, а запросы клиента на автоматизацию отдельных участков бизнеса”.
Кстати, это одна из причин, почему я стараюсь избегать разделения системных и бизнес аналитиков в работе.
https://beskov.medium.com/lies-statistics-and-ba-in-it-1bd10484a706
Наконец-то, кто-то написал, кем является бизнес-аналитик на самом деле, и чем он занимается:
“Таким образом аналитик в такой компании-подрядчике анализирует не бизнес, и даже не процессы, а запросы клиента на автоматизацию отдельных участков бизнеса”.
Кстати, это одна из причин, почему я стараюсь избегать разделения системных и бизнес аналитиков в работе.
https://beskov.medium.com/lies-statistics-and-ba-in-it-1bd10484a706
Medium
Ложь, статистика и бизнес-анализ (в ИТ)
Давайте посмотрим, кто такой бизнес-аналитик (сначала не в ИТ, потом в ИТ), чего от него ждут, чем он должен заниматься и что он делает на…
👍3
#анализ
Обычно рассказы о НФТ повествуют нам о 100500 видов требований, но редко отвечают на вопрос, как добыть конкретные значения. Да еще чтобы они были связаны с реальностью, а не спустились с потолка.
В докладе Сергей предлагает несколько практических способов расчета НФТ:
⁃ что можно добыть в гугле
⁃ как оценить требования к производительности системы
⁃ элементарная статистика, и чем она полезна при расчетах
Имхо, один из лучших докладов на эту тему
https://youtu.be/x0E0DrE5Fmo
Обычно рассказы о НФТ повествуют нам о 100500 видов требований, но редко отвечают на вопрос, как добыть конкретные значения. Да еще чтобы они были связаны с реальностью, а не спустились с потолка.
В докладе Сергей предлагает несколько практических способов расчета НФТ:
⁃ что можно добыть в гугле
⁃ как оценить требования к производительности системы
⁃ элементарная статистика, и чем она полезна при расчетах
Имхо, один из лучших докладов на эту тему
https://youtu.be/x0E0DrE5Fmo
YouTube
Математика в SLA для самых маленьких
Доклад Сергея Уханова на конференции Analyst Days-12. 21-22 мая 2021. Санкт-Петербург
www.analystdays.com
www.analystdays.com
#интеграция #API
Похождения стажера Васи, прошедшего все круги идемпотентности, продолжаются.
В новой серии он столкнулся со сложностями проектирования взаимодействия бэкенда и мобильного приложения:
⁃ версионирование апи и согласование релизов
⁃ разделение логики между бэкендом и мобильным фронтом
⁃ влияние качества связи на логику взаимодействий
⁃ передача чувствительных данных по открытым каналам
https://habr.com/ru/company/yandex/blog/583332/
Похождения стажера Васи, прошедшего все круги идемпотентности, продолжаются.
В новой серии он столкнулся со сложностями проектирования взаимодействия бэкенда и мобильного приложения:
⁃ версионирование апи и согласование релизов
⁃ разделение логики между бэкендом и мобильным фронтом
⁃ влияние качества связи на логику взаимодействий
⁃ передача чувствительных данных по открытым каналам
https://habr.com/ru/company/yandex/blog/583332/
Хабр
Стажёр Вася и его опыт разработки нового API
Легко ли разработать новый API? На что обратить внимание, чтобы не ошибиться при реализации, и к каким компромиссам стоит быть готовым? Привет, Хабр! Меня зовут Иван Ивашковский. Я руковожу группой...
#анализ #манагерское
Интересный подкаст о проблемах разработки. Редко можно услышать, как представители итшечки критикуют позицию своих собратьев в битве IT vs Бизнес
https://open.spotify.com/episode/6zJuQT6xCEYB7ggNYl1MGx?si=8_Q4fkzgT_C09v-4NVfpuA
Особенно откликнулась мысль о типичной позиции разработчика по отношению к бизнесу: “Я умный, а они все там идиоты, зачем с ними разговаривать?” Часто это сопровождается убежденностью в том, что “вот мы бы маркетинг-продукт-процессы сделали нормально, если б только захотели-могли”.
В этом году удалось пообщаться с четырьмя командами/компаниями, где решили создать выделенную роль системного аналитика. В трех из них мотивация была в духе: “Хотим как-то оградить разработчиков от того бреда, который несет бизнес, когда просит запилить очередную хрень”. Не буду гдадать, на сколько силный антагонизм между ит и бизнесом у этих ребят, но история вполне обыденная.
Думаю, это тот самый кейс, когда системные аналитики - это костыль, которым пытаются полечить проблемы процессов и коммуникаций в компании. Нечто подобное обсуждали с Филиппом в эфире Почему системный аналитик в компании - это bad smell?
Возможно, именно это пытались лечить скрамы и прочие аджайлы, вводя в единую команду разрабов, продуктов и бизнес-экспертов.
К чему все это? Аналитик, если ты связываешь бизнес и разработку, помогая им понять друг друга - далеко не всегда это повод для гордости.
*Не относится к заказной разработке.
Интересный подкаст о проблемах разработки. Редко можно услышать, как представители итшечки критикуют позицию своих собратьев в битве IT vs Бизнес
https://open.spotify.com/episode/6zJuQT6xCEYB7ggNYl1MGx?si=8_Q4fkzgT_C09v-4NVfpuA
Особенно откликнулась мысль о типичной позиции разработчика по отношению к бизнесу: “Я умный, а они все там идиоты, зачем с ними разговаривать?” Часто это сопровождается убежденностью в том, что “вот мы бы маркетинг-продукт-процессы сделали нормально, если б только захотели-могли”.
В этом году удалось пообщаться с четырьмя командами/компаниями, где решили создать выделенную роль системного аналитика. В трех из них мотивация была в духе: “Хотим как-то оградить разработчиков от того бреда, который несет бизнес, когда просит запилить очередную хрень”. Не буду гдадать, на сколько силный антагонизм между ит и бизнесом у этих ребят, но история вполне обыденная.
Думаю, это тот самый кейс, когда системные аналитики - это костыль, которым пытаются полечить проблемы процессов и коммуникаций в компании. Нечто подобное обсуждали с Филиппом в эфире Почему системный аналитик в компании - это bad smell?
Возможно, именно это пытались лечить скрамы и прочие аджайлы, вводя в единую команду разрабов, продуктов и бизнес-экспертов.
К чему все это? Аналитик, если ты связываешь бизнес и разработку, помогая им понять друг друга - далеко не всегда это повод для гордости.
*Не относится к заказной разработке.
#процессы #нотации
Я не очень большой фанат bpmn, поэтому не мог пропустить статью о границах его применимости.
https://bpmn2.ru/blog/5-nepravilnix-sposobov-ispolzovat-bpmn
Я не очень большой фанат bpmn, поэтому не мог пропустить статью о границах его применимости.
https://bpmn2.ru/blog/5-nepravilnix-sposobov-ispolzovat-bpmn
bpmn2.ru
6 неправильных способов использовать BPMN, альтернативы BPMN
Важно знать когда стоит использовать BPMN, а когда - что-то другое. В каких 6 ситуациях люди пытаются использовать BPMN, но получается плохо?
#процессы #нотации
После прошлого поста случилась небольшая дискуссия на тему: “Если не BPMN, то что?”
В статье автор поделился историей разработки формальной пользователе-центричной нотации на основе CJM. Практики процессного подхода вряд ли найдут здесь что-то новое, но как альтернативный взгляд выглядит интересно.
Пощупаю как-нибудь на реальной задаче
После прошлого поста случилась небольшая дискуссия на тему: “Если не BPMN, то что?”
В статье автор поделился историей разработки формальной пользователе-центричной нотации на основе CJM. Практики процессного подхода вряд ли найдут здесь что-то новое, но как альтернативный взгляд выглядит интересно.
Пощупаю как-нибудь на реальной задаче
Medium
Схематизация опыта с CJM и Service Blueprint. Практика гибридной нотации
Инструменты проектирования
#очереди #интеграция
Нашел в блоге мейла пару простых статей о том, зачем нужны все эти очереди, кафки и рэббиты. Хорошо зайдет для первого знакомства с темой.
Про очереди: https://mcs.mail.ru/blog/zachem-nuzhny-ocheredi-soobshcheniy-v-mikroservisnoy-arkhitekture
Про Rabbit и Kafka: https://mcs.mail.ru/blog/rabbitmq-ili-apache-kafka
Нашел в блоге мейла пару простых статей о том, зачем нужны все эти очереди, кафки и рэббиты. Хорошо зайдет для первого знакомства с темой.
Про очереди: https://mcs.mail.ru/blog/zachem-nuzhny-ocheredi-soobshcheniy-v-mikroservisnoy-arkhitekture
Про Rabbit и Kafka: https://mcs.mail.ru/blog/rabbitmq-ili-apache-kafka
Тут в среду что-то новогоднее архитектурное dddшное намечается. Даже шанс есть вживую попасть.
https://t.me/dddevotion/234
https://t.me/dddevotion/234
Telegram
DDDevotion
Всем привет! В среду (22 декабря 18-00) митап, он будет проходить онлайн https://youtu.be/ybYtgII151g
Обсудим в свободной дискуссии как развивать качество проектирования в компании.
Также в Москве мы хотим организовать небольшую сходку, человек на 25-30)…
Обсудим в свободной дискуссии как развивать качество проектирования в компании.
Также в Москве мы хотим организовать небольшую сходку, человек на 25-30)…
#интеграция
Попытка разработать простой алгоритм выбора между:
- REST API
- GraphQL
- gRPC
- JSON-RPC
На полноту критериев и фундаментальность не претендует, но почему бы и нет.
https://levelup.gitconnected.com/rest-and-the-future-of-apis-ef9cf4e1706b
Попытка разработать простой алгоритм выбора между:
- REST API
- GraphQL
- gRPC
- JSON-RPC
На полноту критериев и фундаментальность не претендует, но почему бы и нет.
https://levelup.gitconnected.com/rest-and-the-future-of-apis-ef9cf4e1706b
Medium
REST and the future of APIs
Whenever someone starts talking about web services and APIs, you will eventually land on a discussion about whether to use REST or some new…
👍8👎1
#манагерское
Мне тут поведали, что у Филиппа вышла статья о bad smell в процессах. Не буду ничего цитировать, имхо мастрид для лидов, манагеров и всех сочувствующих. Там же ссыль на видео доклада.
https://habr.com/ru/company/oleg-bunin/blog/598925/
Мне тут поведали, что у Филиппа вышла статья о bad smell в процессах. Не буду ничего цитировать, имхо мастрид для лидов, манагеров и всех сочувствующих. Там же ссыль на видео доклада.
https://habr.com/ru/company/oleg-bunin/blog/598925/
Хабр
Ваши процессы попахивают. Как это понять и что делать?
В этой статье я не буду рассказывать про успешные внедрения, лучшие практики и общеполезные методики. Я вообще не буду давать какие-либо советы. Наоборот, попытаюсь на основании своего опыта...
🔥10👍1