qRPC - конкретный фреймворк и протокол. А паттерн интеграции - RPC
Паттернов интеграции, видимо, всего 4: файлообмен; shared db, RPC, message.
А HTTP(s) - это конкретный протокол (на котором построено множество разных RPC). Использование HTTP не ограничивается передачей веб-странички браузеру и вообще не ограничивается "передачей данных в сети Интернет". Компоненты одной системы вполне себе могут быть интегрированы по какому-нибудь RPC и взаимодействовать по HTTP внутри своего интранета.
Push-каналы - асинхронная модель событийной передачи данных
При http-request в ответе возвращается верстка. Т.е. мы зависим от форматирования, от тегов, от стилей. Соответственно, если поставщик данных поменяет верстку, все поломается.
При использовании HTTP всегда в ответе передаётся веб-страница? Мой вам ответ на это:
267 Сомнительно, но окей
И еще: HTTP и push вы считаете отдельными типами интеграции. Они не укладываются в паттерн RPC/API?
С одной стороны, мне неудобно устраивать бесцеремонную критику статьи прямо в первых комментариях, но, @moneta_team , я не согласен. Пример с походом в магазин - это антипример работы с беклогом, работы в инкрементально-итеративном подходе.
Беклог - отсортированный список полезных вещей, которые нужно сделать. Каждый элемент беклога а) имеет ценность сам по себе б) достаточно маленького размера, чтобы успеть сделать за итерацию и в) состоит из одной фичи, а не набора; это сделано для концентрации команды и возможности "поставлять на прод чаще". Беклог сортируется не обязательно по принципу Must Have сверху. Сверху - "имеющее наибольшую ценность для клиента сейчас" по мнению Владельца продукта.
Так вот, вылазка в магазин - это ОДИН элемент беклога. А список продуктов - результат планирования спринта, когда вы сформулировали сабтаски. Набор покупок (сабтасков) можно определить перед началом спринта, взяв в задачу только важные вещи, которые успеем купить (хватит денег, сумеем вывезти, ...), а другие хотелки выделить в новый элемент беклога (поход в магазин).
Так что беклог на бытовом примере выглядит так:
Купить важные продукты (и внутри список от Must Have до Should Have, например)
Купить стол и кресло
Купить сладости и вкусности (и внутри список Could Have, например)
Починить тормоза у машины
Оплата ЖКУ
Допэлектрика у машины (парктроник, камера)
Вы рассматриваете лимит только на один ресурс - деньги, и "берете в работу" только те покупки, на которые хватит бюджета. Отлично, а как же время? Производительность команды? Ограничения по компетенциям команды? Если спринт у вас сегодня кончается в 13:00 и цель спринта - пообедать хоть чем-то?
Элементы 1, 2, 3 выполняются в одном магазине и есть соблазн их затащить в одну работу. Но идея беклога и инкрементально-итеративного подхода в том, что если вы сольёте в одну покупку и жизненно-важные крупы, и сладости, и мебель - у вас может не хватить ресурсов и лучше делать эти три нужные вещи поодиночке, хотя в сумме выйдет больше времени и денег. Есть ведь ограничения:
денег. Ну тут все понятно, вы их сразу увидите. Предположим даже, что денег много;
времени на выполнение: дорога туда-обратно, хождение по магазину, оплата, упаковка, поднять домой, сварить макароны;
места в машине: может быть, вместятся (пакеты с макаронами И пакеты со сладостями) ИЛИ (вместится мебель) и потребуется две поездки - это производительность;
компетенций (сил носить): приехав домой, обнаружите, что стол в одиночку донести на этаж не сможете, а уйти с пакетами варить макароны и оставить стол привязанным к багажнику (незавершенное производство) нельзя: украдут.
И вы не сделаете обед к 13:00, как планировали. Перепрыгните большую пропасть, но на 75%
Вам смешно, а пока я читал статью пришли ценные указания от жены: "калину посадим в метре от дорожки на уровне дальнего края малины". Не удержался и процитировал в ответ Стивенсона из комментария ниже. Готовлюсь ночевать на диване.
Я увидел newton в каком-то фильме и тут же понял, как будет выглядеть моё будущее: офис не обязателен для работы, где я - там и мой офис. В 2000 купил первый Palm и все так и случилось. А Ньютона, кадр которого меня вдохновилась, у меня так никогда и не было :(
PUT перезапишет данные объекта (если он есть) или создаст его (если не было), поэтому данные нужны все. А использовать ли PUT или PATCH - зависит от бизнес-ситуации. Если "нужен вот такой котик, был он или нет" - это PUT; "у существующего котика изменить то-то и это" - PATCH
Пролистав первую половину статьи, возрадовался - рассказано просто, правильно и главное - без всяких джисонов и хттп! Ан нет, появились потом.. По существу: классная статья, рассказано именно базовые вещи без воды и отвлечение. Автор - крутая! Дай пожму лапу
Холивар был бы, если бы мы утверждали "мой подход АА лучше", а я говорю про противоречие формулировок (не утверждая сейчас, что лучше - я могу топить как за ту, так и за эту сторону).
В новой формулировке "гибкие методологии управления проектами" мне тоже видится оксюморон: проекты - это одно, а продуктовый подход (для чего и придумали гибкие методологии) - это другое.
Я все же еще побрюзжу
qRPC - конкретный фреймворк и протокол. А паттерн интеграции - RPC
Паттернов интеграции, видимо, всего 4: файлообмен; shared db, RPC, message.
А HTTP(s) - это конкретный протокол (на котором построено множество разных RPC). Использование HTTP не ограничивается передачей веб-странички браузеру и вообще не ограничивается "передачей данных в сети Интернет". Компоненты одной системы вполне себе могут быть интегрированы по какому-нибудь RPC и взаимодействовать по HTTP внутри своего интранета.
паттерн Message?
При использовании HTTP всегда в ответе передаётся веб-страница? Мой вам ответ на это:
И еще: HTTP и push вы считаете отдельными типами интеграции. Они не укладываются в паттерн RPC/API?
Увы, не смог понять ваш ответ
С одной стороны, мне неудобно устраивать бесцеремонную критику статьи прямо в первых комментариях, но, @moneta_team , я не согласен. Пример с походом в магазин - это антипример работы с беклогом, работы в инкрементально-итеративном подходе.
Беклог - отсортированный список полезных вещей, которые нужно сделать. Каждый элемент беклога а) имеет ценность сам по себе б) достаточно маленького размера, чтобы успеть сделать за итерацию и в) состоит из одной фичи, а не набора; это сделано для концентрации команды и возможности "поставлять на прод чаще".
Беклог сортируется не обязательно по принципу Must Have сверху. Сверху - "имеющее наибольшую ценность для клиента сейчас" по мнению Владельца продукта.
Так вот, вылазка в магазин - это ОДИН элемент беклога. А список продуктов - результат планирования спринта, когда вы сформулировали сабтаски. Набор покупок (сабтасков) можно определить перед началом спринта, взяв в задачу только важные вещи, которые успеем купить (хватит денег, сумеем вывезти, ...), а другие хотелки выделить в новый элемент беклога (поход в магазин).
Так что беклог на бытовом примере выглядит так:
Купить важные продукты (и внутри список от Must Have до Should Have, например)
Купить стол и кресло
Купить сладости и вкусности (и внутри список Could Have, например)
Починить тормоза у машины
Оплата ЖКУ
Допэлектрика у машины (парктроник, камера)
Вы рассматриваете лимит только на один ресурс - деньги, и "берете в работу" только те покупки, на которые хватит бюджета. Отлично, а как же время? Производительность команды? Ограничения по компетенциям команды? Если спринт у вас сегодня кончается в 13:00 и цель спринта - пообедать хоть чем-то?
Элементы 1, 2, 3 выполняются в одном магазине и есть соблазн их затащить в одну работу. Но идея беклога и инкрементально-итеративного подхода в том, что если вы сольёте в одну покупку и жизненно-важные крупы, и сладости, и мебель - у вас может не хватить ресурсов и лучше делать эти три нужные вещи поодиночке, хотя в сумме выйдет больше времени и денег.
Есть ведь ограничения:
денег. Ну тут все понятно, вы их сразу увидите. Предположим даже, что денег много;
времени на выполнение: дорога туда-обратно, хождение по магазину, оплата, упаковка, поднять домой, сварить макароны;
места в машине: может быть, вместятся (пакеты с макаронами И пакеты со сладостями) ИЛИ (вместится мебель) и потребуется две поездки - это производительность;
компетенций (сил носить): приехав домой, обнаружите, что стол в одиночку донести на этаж не сможете, а уйти с пакетами варить макароны и оставить стол привязанным к багажнику (незавершенное производство) нельзя: украдут.
И вы не сделаете обед к 13:00, как планировали. Перепрыгните большую пропасть, но на 75%
Готов обсудить
Прочитал и поругал себя, зачем я полез на пикабу с утра. А стоп! Это на Хабре?!
Именно
Потому что через СП пытаемся решить проблему (якобы) невозможности планировать сроки
Вам смешно, а пока я читал статью пришли ценные указания от жены: "калину посадим в метре от дорожки на уровне дальнего края малины". Не удержался и процитировал в ответ Стивенсона из комментария ниже. Готовлюсь ночевать на диване.
Я увидел newton в каком-то фильме и тут же понял, как будет выглядеть моё будущее: офис не обязателен для работы, где я - там и мой офис. В 2000 купил первый Palm и все так и случилось. А Ньютона, кадр которого меня вдохновилась, у меня так никогда и не было :(
Когда комментарий полезнее статьи (и написан лучше)
... как системная аналитика вместо анализа ;)
Верно, не всё пользовательская история, что написано по шаблону "я, как А, хочу Б...".
"задача требует простого как таракан решения", дальше серьезно читать не смог
PUT перезапишет данные объекта (если он есть) или создаст его (если не было), поэтому данные нужны все.
А использовать ли PUT или PATCH - зависит от бизнес-ситуации. Если "нужен вот такой котик, был он или нет" - это PUT; "у существующего котика изменить то-то и это" - PATCH
Пролистав первую половину статьи, возрадовался - рассказано просто, правильно и главное - без всяких джисонов и хттп! Ан нет, появились потом..
По существу: классная статья, рассказано именно базовые вещи без воды и отвлечение. Автор - крутая! Дай пожму лапу
Можно этот комментарий сделать отдельным постом, чтобы я его в закладки смог положить? ;)
Холивар был бы, если бы мы утверждали "мой подход АА лучше", а я говорю про противоречие формулировок (не утверждая сейчас, что лучше - я могу топить как за ту, так и за эту сторону).
В новой формулировке "гибкие методологии управления проектами" мне тоже видится оксюморон: проекты - это одно, а продуктовый подход (для чего и придумали гибкие методологии) - это другое.
Прекрасное
Скажите, как сочетается утверждение "В DTB разделяют идеологию гибких методологий разработки" и описанная дальше поэтапная работа по "водопаду"?
Я имел в виду "хотя бы один или несколько" против "точно только один"
@Kwisatz, на такой комплексный комментарий хочется ответить просто "да!" :)