Стандарт говорит об обратном, что по умолчанию табличная целостность не может нарушаться и constraint должен проверяться после всех запросов, которые могут на него повлиять и никаких исключений для вложенных запросов нет. В Q&A форуме легко найти мой вопрос, где я пишу то же самое, только цитатми из стандарта.
Курс хорош, но в нём явно не хватает возможности контакта с лектором (в AI классе такая возможность есть, можно отправить email с пожеланиями и еженедельно проходят office hours). В DB-классе предалгается задавать вопросы в Q&A форуме, но мне так по делу никто ничего и не ответил по поводу 7-го вопроса из экзамена.
Коммунизм не работает. Даже в статье написано не «Решения принимаются всей командой.», а «a system without a central authority» т.е. решает не команда, а каждый принимает решения для себя. Решения для команды принимаются командой. Решения, связанные с верхом принимаются сверху.
> Что вы понимаете под самоорганизующейся структурой?
Если просто: если каждый участник команды неявно следует какой-либо процедуре, за ним никто не следит, но её не нарушит, потому что понимает, что это будет не правильно. Например: каждый разработчик команды понимает, что чекинить код без review, настолько же неприлично, как мочиться в лифте, за это не убьют, но не поймут.
> Собирается команда, включая меня, тестера, девелопера и дизайнера и мы вместе решаем, как это будет сделано.
С оунером можно решить, что будет сделано, а дальше девелоперы между собой, тестеры между собой, дизайнеры между собой должны решить, как это сделать. Как дать понять человеку, что он должен подумать над задачей, которую он скорее всего не будет делать? Но если сказать «необходима твоя оценка», то он поймёт и задумается.
P.S. Над вопросом «что для меня аджайл» я отвечать не хочу, т.к. аджайл не является для меня основной конфессией.
То есть как? Назвать митинг «разговор о функциональности ...», приглашаются все, кто заинтересован или планирует когда-либо в будущем заинтересоваться?
По-моему, то что вы предлагаете — не является agile, т.к. структура не будет самоорганизующейся и кто-то должен будет всё продумывать заранее (кто, над чем работает), иначе всё развалится.
> А что, если тестирование очень сложное и долгое? А вы это не учтете? Или дизайнеру придется повозиться в 3 раза обычного времени, потому что IE6 надо поддержать, а он не знал?
Вы меня не слышите, я говорю следующее: не так важен результат оценки, как процесс оценки. От того, что все ошибутся в оценке в 10 раз, трагедии не будет. Но чтобы у менеджмента было меньше соблазна использовать оценки для неадекватных претензий, придумали «пойнты».
Разве planning poker может существовать в разнородной команде?
Если у вас тестер оценивал сложность задач дизайнеров, то удививительно, что вы это пунктом 0 в статью не добавили.
>Ну… как бы… Если он более приоритетный, то так и надо? Нет?
Нет, тут как с разделением процессорного времени, низкоприоритетные задачи должны тоже получать ресурсы, только меньше. Но нет смысла выделять 1 час в неделю задаче, которая рассчитана на месяц, но при этом короткие задачи за 1 час могут закрыться.
>Какое, простите, это имеет отношение к оценкам?
Оценка — активный процесс. Можно долго слушать о фиче (во время daily-scrum, презентаций и т.д.) и не представлять о чём она, но при оценке придётся хотя бы чуть-чуть задуматься. И я говорил не про разные команды (тестер, девелопер и дизайнер), я говорил про одну однородную команду разработчиков.
Как можно отказываться от planning poker?
1. Процесс оценки позволяет найти быстрое и эффективное решение, если оно есть к кого-то в голове (он запускается, если оценки сильно разнятся).
2. Если не проставлять оценки, то долгие приоритетные задачи (новый функционал) будут постоянно перекрывать быстрые, но менее приоритетные (улучшение старого функционала). Без оценок придётся делить пул задач на несколько очередей.
3. Без обсуждения задач, проект рискует развалиться на подпроекты, когда каждый пилит часть, которая ему больше нравится и не знает, что происходит у остальных.
Даже Рихтер, в примере в книжке clr via C#, использовал goto (глава не была с goto никак связана). Хотя, когда я посмотрел на этот код, было ощущение, что увидел привидение.
Где именно? Я пробовал выставлять предпочтительный язык, менял регион в персональных данных, заходил на google.co.uk, но он упорно ищет в рунете. У яндекса есть полезная фича — самому выбрать регион поиска, у гугла я подобного не вижу.
Интересно, на каком уровне абсолютный рекорд? Я помню, что когда начинали, то 500 казалось чем-то невероятным, а буквально через пару лет рекорд уже был больше 4000. Кто-нибудь пробивал отметку 10000?
Было бы интересней почитать о принципе работы этих дефибрилляторов. Через какой промежуток времени они срабатывают, какой принцип действия, нужно ли перезаряжать после срабатывания, бывают ли ложные срабатывания, есть ли возможности скачать новую прошивку на свой дефибриллятор, чтобы добавились новые функции и т.д.
Без чисел разговаривать можно очень долго, но например японцы собрали кучу данных, по которым можно составить картину, в каких объёмах растёт потребление www.stat.go.jp/english/data/chouki/index.htm. В каком не менее приятном виде можно потреблять столько энергии мне представить очень сложно.
> Про атомную энергию… я работал этой области и делжен сказать что ваш пример не удачен и подменяет предмет спора
Объясните. 2000 лет назад на земле жило 200 млн. человек, из потребностей в энергии у них были — орошение полей+нехитрые средства передвижения. Неужели сумма выработанной энергии современных АЭС не превосходит всю энергию, которую вырабатывали тогда люди+домашние животные+какие-нибудь нехитрые гидроприспособления связанные с рекой? Я почти уверен, что превосходит во много раз, просто потребности выросли соразмерно.
Про потребности человека есть ролик www.overstream.net/view.php?oid=m1eju3tya6n4.
А вечный двигатель уже давно реализован в виде атомной энергии (для людей 1000 лет назад это был бы вечный двигатель), но потребности растут, технология не справляется. Если человек знает, что существуют зубные протезы, кардиостимуляторы, то он будет работать чтобы их получить, а 2000 лет человеку нужно было только креститься потому что он не знал, что можно заниматься и другими приятными вещами.
foreach (var trash in inString.Split(new[] {«cake»}, StringSplitOptions.RemoveEmptyEntries))
{
return «I can't eat that :(»;
}
return «Yummy!!!»;
хотя тут foreach — по сути if
P.S. Забавный выбор первоисточника.
Если просто: если каждый участник команды неявно следует какой-либо процедуре, за ним никто не следит, но её не нарушит, потому что понимает, что это будет не правильно. Например: каждый разработчик команды понимает, что чекинить код без review, настолько же неприлично, как мочиться в лифте, за это не убьют, но не поймут.
> Собирается команда, включая меня, тестера, девелопера и дизайнера и мы вместе решаем, как это будет сделано.
С оунером можно решить, что будет сделано, а дальше девелоперы между собой, тестеры между собой, дизайнеры между собой должны решить, как это сделать. Как дать понять человеку, что он должен подумать над задачей, которую он скорее всего не будет делать? Но если сказать «необходима твоя оценка», то он поймёт и задумается.
P.S. Над вопросом «что для меня аджайл» я отвечать не хочу, т.к. аджайл не является для меня основной конфессией.
По-моему, то что вы предлагаете — не является agile, т.к. структура не будет самоорганизующейся и кто-то должен будет всё продумывать заранее (кто, над чем работает), иначе всё развалится.
Мы же об оценках говорим.
> А что, если тестирование очень сложное и долгое? А вы это не учтете? Или дизайнеру придется повозиться в 3 раза обычного времени, потому что IE6 надо поддержать, а он не знал?
Вы меня не слышите, я говорю следующее: не так важен результат оценки, как процесс оценки. От того, что все ошибутся в оценке в 10 раз, трагедии не будет. Но чтобы у менеджмента было меньше соблазна использовать оценки для неадекватных претензий, придумали «пойнты».
Если у вас тестер оценивал сложность задач дизайнеров, то удививительно, что вы это пунктом 0 в статью не добавили.
Нет, тут как с разделением процессорного времени, низкоприоритетные задачи должны тоже получать ресурсы, только меньше. Но нет смысла выделять 1 час в неделю задаче, которая рассчитана на месяц, но при этом короткие задачи за 1 час могут закрыться.
>Какое, простите, это имеет отношение к оценкам?
Оценка — активный процесс. Можно долго слушать о фиче (во время daily-scrum, презентаций и т.д.) и не представлять о чём она, но при оценке придётся хотя бы чуть-чуть задуматься. И я говорил не про разные команды (тестер, девелопер и дизайнер), я говорил про одну однородную команду разработчиков.
1. Процесс оценки позволяет найти быстрое и эффективное решение, если оно есть к кого-то в голове (он запускается, если оценки сильно разнятся).
2. Если не проставлять оценки, то долгие приоритетные задачи (новый функционал) будут постоянно перекрывать быстрые, но менее приоритетные (улучшение старого функционала). Без оценок придётся делить пул задач на несколько очередей.
3. Без обсуждения задач, проект рискует развалиться на подпроекты, когда каждый пилит часть, которая ему больше нравится и не знает, что происходит у остальных.
Это основной признак того, что в компании неправильно поставлены процессы. Без делигирования полномочий невозможен ни рост, ни развитие.
Объясните. 2000 лет назад на земле жило 200 млн. человек, из потребностей в энергии у них были — орошение полей+нехитрые средства передвижения. Неужели сумма выработанной энергии современных АЭС не превосходит всю энергию, которую вырабатывали тогда люди+домашние животные+какие-нибудь нехитрые гидроприспособления связанные с рекой? Я почти уверен, что превосходит во много раз, просто потребности выросли соразмерно.
А вечный двигатель уже давно реализован в виде атомной энергии (для людей 1000 лет назад это был бы вечный двигатель), но потребности растут, технология не справляется. Если человек знает, что существуют зубные протезы, кардиостимуляторы, то он будет работать чтобы их получить, а 2000 лет человеку нужно было только креститься потому что он не знал, что можно заниматься и другими приятными вещами.