При изначальном планировании спринта заказчик (product owner) набрасывает задачи, которые хочет увидеть по завершению спринта. Техлид распределяет их по ответственным в команде разработчикам (по компонентам, технологиям, компетенциям и пр.). Далее те люди на которых назначено проводят сами оценку задачи по исходным данным что есть и только когда такие оценки готовы собирается команда на обсуждение по сценарию похожему на покер, только без карточек. В процессе обсуждения задачи могут переназначаться, а трудоемкость корректироваться.
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
Изначально в planning poker карточках не дни, а story points. Почему выбраны именно дни и как аргументировать отказ от story points?
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.
Если уж делать трактовку оригинала, то я бы сказал что ключевая фраза здесь вот эта:
communication must be stateless in nature
То бишь, где они расположены неважно, сам процесс взаимодействия между сервером и клиентом должен быть stateless. Ваши референсы далее касаются хранения сессии, а не состояния объектов.
По вашим аргументам:
1) Действительно ничто, потому что REST это принципы, а не четкий протокол. Вы можете делать так, а можете не делать, руководствуясь, в т.ч. «здравым смыслом». В моем понимании stateless должен быть на всех этапах выполнения бизнес-процесса.
2) Мое мнение, эти принципы масштабируемы под разные уровни. Браузер <-> веб-сервер <-> БД, почему нет? На каждом из звеньев можно соблюдать эти принципы. Где именно хранит важно для соблюдения stateless.
Так что обсуждение, какое же именно состояние в REST допустимо, а какое нет, — тема для длинного вдумчивого обсуждения.
Да, как я упомянул выше, тема очень скользкая и немало копий сломано :) Будет интересно где-нибудь обсудить.
Во-первых, накладывает именно словом stateless. Причем и на сервер и на клиент, раз иного не упомянуто.
Во-вторых, при чему тут If-Not-Modified-Since и в целом HTTP? Транспорт может быть любой.
Ну и в-третьих, так и не увидел ответа на свой вопрос. Пока вижу кучу нападок на мое мнение, без контраргументов.
Когда вы говорите, что в REST нет состояния, что конкретно вы имеете в виду?
для меня видится ключевым отсутствие хранения состояния.
Я не утверждал, что состояния нет. Я лишь сказал, что мы его не храним на неразделяемых ресурсах. Или выражаясь другим языком, подсказанным f0rk, сессисонно (или per-request или по-запросно, как хотите).
В этом примере, мы создали/отредактировали объект «Client 1». Если нам этот объект опять понадобится мы запросим его с сервера и будем с ним работать, а не с тем объектом который мы создали. Если мы говорим о веб сервисах, то в них не описано (протоколом точно, в договоренностях не всегда) как нам поступить в этом случае — работать с созданным или запросить новый.
В этом мое понимание этого принципа. У вас есть контрпример или свое видение?
На «сервер» и «БД» нет, есть сервер и есть клиент (один из них «сервер», другой «БД»). И таки REST строится на клиент-серверной архитектуре, поэтому разделение есть.
Не вижу ничего неправильного в вопросе, можете поподробнее?
Состояние объекта разумеется. Если есть на сервере объект, то мы никогда не храним его состояние (изначальное или измененное) в «неразделяемых» условиях. Для примера можно взять объект «сессия». По REST подходу его нельзя хранить в in-memory на машине, а нужно передавать на «разделяемый» ресурс (БД, к примеру).
Если пойти дальше, то и взаимодействие с БД можно тоже сделать restful и вообще избавится от сессий, заменив их, к примеру, на токены.
Вообще тема скользкая, в моей логике тоже есть изъяны и всегда можно найти контрпример :) Я считаю REST подход может масштабироваться и переходить на разные уровни (необязательно речь про веб).
Спасибо за исследование и мнение.
Помимо того что REST это не стандарт, а принципы построения архитектуры, в отличие от веб-сервисов, для меня видится ключевым отсутствие хранения состояния. Именно это я и спрашиваю на собеседовании при приеме к нам на работу. Если есть понимание, что REST это строго отсутствие состояния, а веб-сервисы нет (или не всегда), то на вопрос ответили правильно (хинт для тех кто пойдет к нам трудоустраиваться :) )
В том то и затык. Предыдущий комментатор написал мол «на каждом втором очевидно, что они сами не представляют что надо спрашивать и порой про разработку устройств и программирование вообще вопросы не задаются».
А как Вы посоветуете собеседовать человека на совершенно новое для компании направление? Просто интересно, без сарказма.
Сейчас у нас похожая ситуация (только не из мира FPGA) — есть новое направление с языком, который никто в компании не знает. И как тут быть?
Да, если точно знаешь зачем и где его использовать, а также покрыв такой код необходимыми проверками. У вас такого не заметил.
То, что уже написано в большинстве своем уже поддерживать не придется. Сделано как автомат калашникова. Предельно просто и предельно обфускано. Ну и гарантированно надежно.
Ха-ха. Откуда такая уверенность, что не придется? Гарантировано чем? Где юнит тесты, где интеграционные тесты и тесты производительности?
но, в как выяснилось в будущем, они особой пользы не имеют так как код работает и так эффективно.
Знаете, есть такое понятие как стандарты кодирования. Где-то они негласные, где-то явно закреплены. Кусок с тройным вложенным свитчем нечитаемый и нерасширяемый от слова совсем. Ну и тот же вопрос про «эффективно» — где тесты?
А вы хотели с наскока влиться в разработку? Даже не знаю где у вас это получилось бы проще всего ;] Посмотрите на сорцы той же jQuery. Не думаю, что они покажутся вам проще.
От инструмента, которым я пользуюсь в разработке, я жду полной прозрачности и быстрого старта. И да, сорцы JQuery мне кажутся значительно проще в понимании.
В итоге — нет тестов, код плохо читается, б*г знает сколько в таком коде багов. Его еще надо очень долго дорабатывать.
Не обижайтесь, но на хабр я бы постеснялся выкладывать такой фреймворк.
eval в частности.
Свитч тройной вложенности, имена переменных однобуквенные, разный стиль кодирования в разных местах (как будто копипаста)… Могу конечно продолжить, но смысла не вижу. Такой код невозможно поддерживать и читать, а следовательно говорить об эффективности, легкости, скорости совсем не приходится (невозможно что-то доказать, поскольку нельзя проанализировать).
switch(state) {
case 4:
// wrap statuses
switch(this.status - 0) {
case 200:
switch(f +"") {
case "text":
// as is as
result = datas;
break;
case "dom":
// revert from [string] to [object html]
var pattern = /<body[^>]*>((.|[\n\r])*)<\/body>/im;
result = $.convertSTRToHTML(pattern.exec(datas)[0]);
break;
case "json":
// revert to object
result = JSON.parse(datas.replace(/\\'/g, "'"));
break;
}
break;
case 404:
result = "404: not found";
break;
}
break;
};
// create a Gray Box modal windows
modal: function(t,d,s,q,c) {
Дальше просто побоялся смотреть. Код написан очень плохо.
Извините, ничего личного, не удержался…
Класс, даже не знал. Пойду досматривать упущенные годы.
Мне казалось Масяню перестали рисовать году 2006… Хотя уже и не вспомню сейчас всех подробностей.
Спасибо! Как увидел Масяню, аж чуть не всплакнул…
По теме — автор абсолютно прав. Огромное количество людей сейчас учат технологии, а не алгоритмы и языки. Такой «тренд» во всех сферах.
Для нас так оказалось наиболее эффективно по времени и комфорту в коллективе.
Поделюсь своим опытом: пытались применить покер планирование в наших командах, но так и не прижилось. Все участники были скованны в общении и не понимали, зачем нужны карточки. Правила игры не принимались командой и было сложно их мотивировать им следовать. В результате отказались от этой практики в пользу обсуждения каждой задачи на совещании по планированию с конкретным исполнителем в присутствии команды.
То бишь, где они расположены неважно, сам процесс взаимодействия между сервером и клиентом должен быть stateless. Ваши референсы далее касаются хранения сессии, а не состояния объектов.
По вашим аргументам:
1) Действительно ничто, потому что REST это принципы, а не четкий протокол. Вы можете делать так, а можете не делать, руководствуясь, в т.ч. «здравым смыслом». В моем понимании stateless должен быть на всех этапах выполнения бизнес-процесса.
2) Мое мнение, эти принципы масштабируемы под разные уровни. Браузер <-> веб-сервер <-> БД, почему нет? На каждом из звеньев можно соблюдать эти принципы. Где именно хранит важно для соблюдения stateless.
Да, как я упомянул выше, тема очень скользкая и немало копий сломано :) Будет интересно где-нибудь обсудить.
Во-вторых, при чему тут If-Not-Modified-Since и в целом HTTP? Транспорт может быть любой.
Ну и в-третьих, так и не увидел ответа на свой вопрос. Пока вижу кучу нападок на мое мнение, без контраргументов.
Я не утверждал, что состояния нет. Я лишь сказал, что мы его не храним на неразделяемых ресурсах. Или выражаясь другим языком, подсказанным f0rk, сессисонно (или per-request или по-запросно, как хотите).
В этом примере, мы создали/отредактировали объект «Client 1». Если нам этот объект опять понадобится мы запросим его с сервера и будем с ним работать, а не с тем объектом который мы создали. Если мы говорим о веб сервисах, то в них не описано (протоколом точно, в договоренностях не всегда) как нам поступить в этом случае — работать с созданным или запросить новый.
В этом мое понимание этого принципа. У вас есть контрпример или свое видение?
Не вижу ничего неправильного в вопросе, можете поподробнее?
Если пойти дальше, то и взаимодействие с БД можно тоже сделать restful и вообще избавится от сессий, заменив их, к примеру, на токены.
Вообще тема скользкая, в моей логике тоже есть изъяны и всегда можно найти контрпример :) Я считаю REST подход может масштабироваться и переходить на разные уровни (необязательно речь про веб).
Помимо того что REST это не стандарт, а принципы построения архитектуры, в отличие от веб-сервисов, для меня видится ключевым отсутствие хранения состояния. Именно это я и спрашиваю на собеседовании при приеме к нам на работу. Если есть понимание, что REST это строго отсутствие состояния, а веб-сервисы нет (или не всегда), то на вопрос ответили правильно (хинт для тех кто пойдет к нам трудоустраиваться :) )
Желаю побольше времени на сон в будущем году и осуществления всех планов! С наступающим! :)
А как надо то?
Сейчас у нас похожая ситуация (только не из мира FPGA) — есть новое направление с языком, который никто в компании не знает. И как тут быть?
Да, если точно знаешь зачем и где его использовать, а также покрыв такой код необходимыми проверками. У вас такого не заметил.
Ха-ха. Откуда такая уверенность, что не придется? Гарантировано чем? Где юнит тесты, где интеграционные тесты и тесты производительности?
Знаете, есть такое понятие как стандарты кодирования. Где-то они негласные, где-то явно закреплены. Кусок с тройным вложенным свитчем нечитаемый и нерасширяемый от слова совсем. Ну и тот же вопрос про «эффективно» — где тесты?
От инструмента, которым я пользуюсь в разработке, я жду полной прозрачности и быстрого старта. И да, сорцы JQuery мне кажутся значительно проще в понимании.
В итоге — нет тестов, код плохо читается, б*г знает сколько в таком коде багов. Его еще надо очень долго дорабатывать.
Не обижайтесь, но на хабр я бы постеснялся выкладывать такой фреймворк.
Тем не менее, удачи!
Свитч тройной вложенности, имена переменных однобуквенные, разный стиль кодирования в разных местах (как будто копипаста)… Могу конечно продолжить, но смысла не вижу. Такой код невозможно поддерживать и читать, а следовательно говорить об эффективности, легкости, скорости совсем не приходится (невозможно что-то доказать, поскольку нельзя проанализировать).
Дальше просто побоялся смотреть. Код написан очень плохо.
Извините, ничего личного, не удержался…
Мне казалось Масяню перестали рисовать году 2006… Хотя уже и не вспомню сейчас всех подробностей.
По теме — автор абсолютно прав. Огромное количество людей сейчас учат технологии, а не алгоритмы и языки. Такой «тренд» во всех сферах.