Насколько я знаю, Мартину не нравится прозвище "дядюшка Боб". Это прозвище он получил от читателей, когда был редактором журнала C++ Report. Так что зря вы пишите, что он "втирается в доверие".
Впрочем, я согласен, что ваша версия кода генерации простых чисел проще и понятнее, чем у Мартина.
Если бы были информативны, я бы не расстраивался. Переводил тут цикл статьей по F#. Оригинальный сайт среди знатоков F# в России считается номером один. Сам цикл — один из самых важных и интересных на сайте, про аналог монад в F#. А монады — сама по себе интересная тема.
Когда завершил (там одиннадцать статей), для удобства читателей сделал пост со ссылками на все части, чтобы можно было читать подряд. Итог — много плюсов и один минус "Низкий технический уровень материала". Это про оригинал? Про мой перевод? Про конкретно этот пост, который для удобства? Какую полезную информацию я получил, чтобы писать лучше. Никакой. Я так и не понял, почему этот минус стоит. Кажется, что причина абсолютно случайна.
Другая статья, уже не перевод. Написал, как мы провели IT-мероприятие в Казани этим летом. Снова единственный минус "Не соответствует тематике Хабра". Почему? Хабр изначально был ресурсом про IT, но сейчас здесь о чём только не пишут. И это нормально, мы же обычные люди.
Ну, хорошо, пусть статья должна быть в тематике Хабра. На Хабре есть несколько подходящих хабов: мы писали open source, разрабатывали под Linux, у нас был некий аналог хакатона. Почему "не в тематике"? Да кто ж знает. Просто поставили такой минус, непонятно за что.
Чтобы не реагировать слишком живо я и выработал правило, про которое написал выше: если плюсов гораздо больше, чем минусов, всё ок.
Я пишу довольно много и местами не понимаю, за что мне прилетают минусы. Моя защита в том, чтобы относиться к минусам статистически. Если бы мои статьи всё время уходили бы в минус, это был бы звоночек для меня. А если у статей отношение плюсов к минусов 10:1 то всё нормально.
В конце концов, не будучи червонцем, я не обязан всем нравиться. Но плохому материалу я могу поставить минус. Хотя не помню, когда последний раз реально ставил.
Шикарное вступление. Опознал аллюзию на "Страх и ненависть в Лас-Вегасе". Автору респект!
И ещё, отдельно, вопрос. Вы пишите про "набившую оскомину механику бродилки по броску кубика" и про то, что её можно "модифицировать карточками предметов и случайных событий". Могут ли карточки сделать игру интересной даже для искушённых игроков. Возможна ли такая игра, чтобы пять человек играли в неё, скажем, двадцать минут?
Я сейчас придумываю разного рода активности для программистов, в том числе рассматриваю и настольные игры. В отличии от вас, я не играл в них в зрелом возрасте: не сложилось. Из статьи понял, что игра "Князья" похожа на то, что меня интересует. Можете посоветовать ещё что-то?
Как я понял, автор вслух проговаривает какие-то мысли, может быть, планы. В принципе, почему нет? Но если прямо надо с кем-то разговаривать, в интернете есть, вероятно, сотни разговорных клубов разного формата.
Я не очень понимаю, почему вдруг исследование самого хабра превратилось в ноунейм-топ. Хабр — крупнейший ИТ-ресурс в рунете, значит, это исследование, по определению, самое известное в стране.
Какой бы "нейм-топ" вы ни имели в виду, он, очевидно, менее значим.
Интересно взглянуть на проблему с другой стороны: как там обстоят дела у работодателей? Сколько из них накручивают такие показатели, как "интересные задачи", "дружный коллектив" и "адекватный менеджмент".
Поздравления всем призёрам, личные поздравления позитивам. Наглядное подтверждение, что технобренд действительно что-то значит, и что в него нужно вкладываться.
Беда автора, что у него не откалибрована сложность материала. Пишет, мол, простите за очевидные вещи, а потом начинает тарабарить. Я могу из общих соображений догадаться, что такое PAGELATCH, но я не знаю, что такое NUMA и как-то смутно представляю себе BUFFER POOL. При этом я долго работал с MS SQL и как раз поэтому не очень хорошо представляю себе, что там сейчас творится на низком уровне.
Хотелось бы в общих чертах понимать, как что устроено и почему это плохо. Да, в паре мест есть ссылки на другие материалы, но это означает, что для того, чтобы понять статью, нужно прочитать ещё пару других статей приличного размера.
Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
Не знаю. Ходят слухи, что команда C# хочет что-то подобное затащить, но пока это только слухи, и не очень понятно, в каком объёме будут затаскивать.
С другой стороны — проект на F# вполне может держать в одном солюшене вместе с проектами на C#, так что уже сейчас можно писать, скажем, чистую бизнес-логику на F#, а инфраструктуру — на C#. Многие именно так и делают.
Сначала не понял, а потом как понял!
Приятный сарказм, посмеялся от души.
Насколько я знаю, Мартину не нравится прозвище "дядюшка Боб". Это прозвище он получил от читателей, когда был редактором журнала C++ Report.
Так что зря вы пишите, что он "втирается в доверие".
Впрочем, я согласен, что ваша версия кода генерации простых чисел проще и понятнее, чем у Мартина.
Голосую за NixOS!
Большое спасибо! Полезная подборка, займусь исследованиями.
Если бы были информативны, я бы не расстраивался.
Переводил тут цикл статьей по F#. Оригинальный сайт среди знатоков F# в России считается номером один. Сам цикл — один из самых важных и интересных на сайте, про аналог монад в F#. А монады — сама по себе интересная тема.
Когда завершил (там одиннадцать статей), для удобства читателей сделал пост со ссылками на все части, чтобы можно было читать подряд. Итог — много плюсов и один минус "Низкий технический уровень материала". Это про оригинал? Про мой перевод? Про конкретно этот пост, который для удобства? Какую полезную информацию я получил, чтобы писать лучше. Никакой. Я так и не понял, почему этот минус стоит. Кажется, что причина абсолютно случайна.
Другая статья, уже не перевод. Написал, как мы провели IT-мероприятие в Казани этим летом. Снова единственный минус "Не соответствует тематике Хабра". Почему? Хабр изначально был ресурсом про IT, но сейчас здесь о чём только не пишут. И это нормально, мы же обычные люди.
Ну, хорошо, пусть статья должна быть в тематике Хабра. На Хабре есть несколько подходящих хабов: мы писали open source, разрабатывали под Linux, у нас был некий аналог хакатона. Почему "не в тематике"? Да кто ж знает. Просто поставили такой минус, непонятно за что.
Чтобы не реагировать слишком живо я и выработал правило, про которое написал выше: если плюсов гораздо больше, чем минусов, всё ок.
Плюсик в карму.
Я пишу довольно много и местами не понимаю, за что мне прилетают минусы. Моя защита в том, чтобы относиться к минусам статистически. Если бы мои статьи всё время уходили бы в минус, это был бы звоночек для меня. А если у статей отношение плюсов к минусов 10:1 то всё нормально.
В конце концов, не будучи червонцем, я не обязан всем нравиться. Но плохому материалу я могу поставить минус. Хотя не помню, когда последний раз реально ставил.
Шикарное вступление. Опознал аллюзию на "Страх и ненависть в Лас-Вегасе". Автору респект!
И ещё, отдельно, вопрос. Вы пишите про "набившую оскомину механику бродилки по броску кубика" и про то, что её можно "модифицировать карточками предметов и случайных событий". Могут ли карточки сделать игру интересной даже для искушённых игроков. Возможна ли такая игра, чтобы пять человек играли в неё, скажем, двадцать минут?
Я сейчас придумываю разного рода активности для программистов, в том числе рассматриваю и настольные игры. В отличии от вас, я не играл в них в зрелом возрасте: не сложилось. Из статьи понял, что игра "Князья" похожа на то, что меня интересует. Можете посоветовать ещё что-то?
Как я понял, автор вслух проговаривает какие-то мысли, может быть, планы. В принципе, почему нет?
Но если прямо надо с кем-то разговаривать, в интернете есть, вероятно, сотни разговорных клубов разного формата.
Я не очень понимаю, почему вдруг исследование самого хабра превратилось в ноунейм-топ.
Хабр — крупнейший ИТ-ресурс в рунете, значит, это исследование, по определению, самое известное в стране.
Какой бы "нейм-топ" вы ни имели в виду, он, очевидно, менее значим.
Интересно взглянуть на проблему с другой стороны: как там обстоят дела у работодателей? Сколько из них накручивают такие показатели, как "интересные задачи", "дружный коллектив" и "адекватный менеджмент".
Абсолютно согласен. Это и есть основная проблема.
Поздравления всем призёрам, личные поздравления позитивам. Наглядное подтверждение, что технобренд действительно что-то значит, и что в него нужно вкладываться.
Беда автора, что у него не откалибрована сложность материала. Пишет, мол, простите за очевидные вещи, а потом начинает тарабарить. Я могу из общих соображений догадаться, что такое PAGELATCH, но я не знаю, что такое NUMA и как-то смутно представляю себе BUFFER POOL. При этом я долго работал с MS SQL и как раз поэтому не очень хорошо представляю себе, что там сейчас творится на низком уровне.
Хотелось бы в общих чертах понимать, как что устроено и почему это плохо. Да, в паре мест есть ссылки на другие материалы, но это означает, что для того, чтобы понять статью, нужно прочитать ещё пару других статей приличного размера.
Тогда о какой очевидности речь?
У меня приблизительно такие же представления. За тем, может быть, исключением, что есть ещё чёрные лебеди, которые кардинально ломают планирование.
Вы не с тем человек спорите. Я то считаю, что 60-80% это вполне ок. Мне вот пишут, что это мало и надо 100%.
Так я, вроде, именно это и делаю. Завершим, — говорю, — от 60 до 80% запланированных задач. Чем не непредсказуемость?
Но ведь это не в наших возможностях. Об этом и был мой комментарий.
Мир непредсказуем. Как ты ни крутись, но 100% всё равно не попадёшь. И статистика это подтверждает, можете сами посмотреть, как в индустрии обстоят дела с предсказуемостью.
Ответ: никак. Если бы всё было в целом хорошо, никто бы и не парился. Проблема в том, что всё нехорошо, никогда не было хорошо и никакие методологии кардинально ситуацию не улучшили за последние лет пятьдесят.
Не соглашусь. Мы с коллегами вели учёт спринтов и каждый раз на ретро пытались найти причины задержек. Но причины почти всегда были разные. Только потом, прочитав Талеба, я понял, что истинная причина задержек совсем в другом: мир принципиально непредсказуем.
Если бы мы писали систему повторно, то тогда бы знали все подводные камни. Но обычно у нас или новая технология, или не очень известная предметная область, или так называемый "творческий бизнес", который придумывает ТЗ на ходу.
Некоторым подтверждением моих слов может служить статистика. Я постоянно ссылаюсь на CHAOS REPORT 2015. Он гуглится. Там есть разнообразная статистика по проектам, с Agile, без Agile, большим, средним, маленьким.
И вот там даже у маленьких проектов, которые ведутся по Agile (считается, что это более контролируемый процесс) процент проектов, уложившихся в сроки и бюджет — всего лишь порядка 50%. Это в целом по индустрии.
Если кто-то мне не верит, могу предложить самостоятельно вести учёт спринтов, скажем, полгода, но только честно. Если что-то не успели сделать, так и пишем в табличку. Можно считать очень точно, поскольку есть перечень задач на спринт. Через полгода смотрим. Предположу, что реальная исполняемость как раз и будет 60-80%.
Интересный парадокс. Сама идея спринтов не кажется такой уж плохой. Промежуточные цели — хороший способ контролировать продвижение. Чем раньше мы узнаём о проблемах, тем больше у нас возможностей с ними справиться. Звучит хорошо.
Но, знаете, когда я читал статью, то понял, что вы действительно правы. На практике, каждая сдача спринта это стресс. Мы постоянно что-то не успеваем и постоянно думаем, как нам с этим справиться, но у нас есть "большой дедлайн", поэтому всё это мы откладываем на потом.
Кажется, что где-то что-то глобально пошло не так. Идея была в том, чтобы проверять прогресс, но сейчас речь идёт, чтобы отчитываться о прогрессе. Ситуация, когда мы не сделали 60-80% задач, не должна считаться нонсенсом — это нормальная житейская история.
Не знаю, можно ли как то излечиться от этого "синдрома отчётности". Потому что, если нельзя, то идея итераций и в самом деле гибельная.
Не знаю. Ходят слухи, что команда C# хочет что-то подобное затащить, но пока это только слухи, и не очень понятно, в каком объёме будут затаскивать.
С другой стороны — проект на F# вполне может держать в одном солюшене вместе с проектами на C#, так что уже сейчас можно писать, скажем, чистую бизнес-логику на F#, а инфраструктуру — на C#. Многие именно так и делают.