Переизобретение позднего связывания. Собственно тот случай когда свои шишки набивать нету необходимости - достоинства и недостатки позднего связывания, особенно как в данном случае "на стероидах" - давно набиты.
Hint: начать можно с простого - ошибка в написании имени метода выявляется только при запуске приложения. В то время как уже практически доказано что shift left подход (обнаруживать ошибки как можно раньше) - дает видимое увеличение качества и при ускорении time to market - зачем-то делается shift to right. Дальше можно поразвивать эту мысль, например в сторону что произойдет со статическим анализом что качества, что безопасности кода.
Мотивация понятна - предложенный путь дает небольшую экономию времени разработчика (но не времени до вывода на прод). За это кстати надо тоже сказать спасибо метрикам типа velocity которые внедряют псевдо-скрам-мастера, или еще хуже - утилизации (вообще коробит когда про людей говорим) вместо бизнес-ориентированных метрик того же Evidence Management Guide.
Так что чисто технически - действительно интересная работа, но прикладной смысл далеко не очевиден.
Частично справедливое замечание, но есть один нюанс.
Работа с клавиатуры действительно быстрее работы мышкой, если обладаешь навыком слепой печати. Я не любитель vim, но с Visual Studio работаю схожим способом - с клавиатуры. Даже исследования есть по этому поводу, там речь от разнице в двое между мышкой и клавиатурой по скорости.
Раз уж отсылаются к мастеру, то прям просится другая цитата оттуда:
“А сегодня я нашел два способа завязывать шнурки, один хорошо чтобы ходить, другой - что бы падать”
Старый код, конечно, попахивал, после рефакторинга - завонял. Раньше логика зависимая от строковой константы была хотя бы стыдливо спрятана в API, а теперь торчит наружу, поджидая неосторожного джуна или что еще хуже - клиента, чтобы тот выстрелил себе в ногу. И главное что статическим анализом кода такое уже не поймать, только дебаг, только хардкор, причем обязательно с заходом в функцию, чтобы понять чеж там происходит. “SOLID? Never heard about…”
В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
Сразу оговорюсь, как переводчик, статья описывает применение ПБ именно там где оно нужно, где эффект зависит от реальной командной работы - т.е. работ над сложными проектами (как оно понимается в теории сложности), ситуаций хаоса, создания нового знания (НИОКР). Ничего в статье не утверждает, что ПБ надо делать просто потому что это круто и всем срочно нужно. Статья исключительно о том, что если вам действительно нужна ПБ - то можно избежать, увы, распространенных ошибок. Так бывает когда “коачи” забывают простой принцип, хорошо сформулированный Лайзой Адкинс на W.A.T. (Women in Agile and Technology) в этом году: “Мы не коачи как в психологии, мы не работаем в интересах пациента. Мы здесь чтобы клиенты и компании получили эффективную и работающую команду”.
Само понятие ПБ может “триггерить” тех, кто столкнулся к кривой реализацией. Меня лично подвигла на поиск этого материала ситуация когда, в рамках оказания консультационных услуг, мне пришлось довольно жестко занимать сторону одного-единственного человека в команде, кто не боялся “резать правду-матку”, в то время как остальная команда, манипулируя словечками типа “ПБ”, “токсичность”, “софт-скиллз”, пыталась его натурально заткнуть. И так, к сожалению, тоже бывает. И я искренне понимаю почему что у этого человека, очень талантливого инженера теперь будет не очень реакция на идеи о ПБ.
Так что если кого задело - заранее прошу прощения. Ни разу имел в виду. Наоборот, надеюсь что эта статья даст аргументы для диалога с такими "коачами". Все-таки часто "вон че буржуи пишут" оказывается более весомым аргументом чем просто здравый смысл.
А почему она должна помочь? Идолопоклонничество еще в заповедях, которые товарищ Моисей принес, осуждалось, так что это было ой как задолго то титтеров, нашего десятилетия, нашего века, и даже нашей эпохи.
Вы привели достаточно длинную статью с пространными рассуждениями и без статистики, поэтому для внятной дальнейшей дискуссию пожалуйста процитируйте что именно из этой статьи навело вас на мысль что она подтверждает утверждение “это 14-16 летние вопят”. Мне бы не хотелось гадать и думаю что остальным читателям тоже. Спасибо.
Возможно зависит от того где, но по тому что я вижу - я бы скорее спросил в ответ - а разве 14-16-ти летние там вообще сидят? Насколько я могу судить - твиттер это социалка для тек кому сейчас 25-35 скорее, по крайней мере для европы и штатов. https://www.omnicoreagency.com/twitter-statistics/
Про РФ и твиттер честно скажу - понятия не имею, но работая с молодыми специалистами, и со школьниками - аналог американским миллениалам я скорее вижу в все-таки в нынешних 20-25 летних. Так что отставание если и есть, но не на 10 лет.
А я уже расслабился и принял как факт. Люди те же, но из-за быстрой связи и социальных сетей - мода распространяется намного быстрее, впрочем так же быстро и затухает. А так, нормальных людей хватает чтобы не впадать в отчаяние, а всем и каждому все равно ума не вложишь. :-)
А что толерантность - это реакция на последствия педагогических экспериментов 90-2000х которые вырастили поколение крайне ранимых и психически неустойчивых. Это тем более пройдет, поколение которым сейчас 15-20 внушает мне надежду, они наелись и социальных сетей, и толерантности и не верят ни в бога, ни в черта. Чем-то похожи на нас 30 лет назад.
Статья вызывает небольшой когнитивный диссонанс :-) С одной стороны явно есть опыт и определенные меткие наблюдения о природе людей, с другой - этот опыт почему-то не привел к тому чтобы научиться различать ущербные идеи и их ущербную реализацию, по другому давно метко сформулированный русским народом как “заставь дурака Богу молиться - он себе лоб расшибет”. Правда тогда бы и длинной статьи бы не было, можно было бы сократить до “дураки - плохо” и пойти слушать битву с дураками Макаревича. Хотя бы для того чтобы не впадать в состояние в котором “все вокруг такие дураки, один только сам-себе-я д’Артаньян”. Не надо, седые волосы на жопе и избыток устаревшего местами опыта не дает нам на этого особого права.
Тем более что ничего не ново, кто в области уже давно - может вспомнить “дурацкий” приход ПК на смену мейнфреймам, “дурацкое” увлечение толстыми клиентами на dBase подобных (забавно повторяющееся сейчас один-в-один с SPA), “дурацкие” попытки делать RAD, причем у каждого как дырка в жопе - уникальный и свой, пришедшие им на смену и не менее “дурацкие” внедрения RUP или CMMx, “дурацкие” сертификации по ISO9000. На все новое были и те, кто применял это бездумно, не всегда многочисленные, но всегда громкие, и те кто кричал - это все фигня.
В целом вы правильно зашли с теории сложных систем, но можно было продолжить в той же канве, бо совсем рядом там же мы найдем преимущества эмержетного поведения коллектива как сложной системы против единичности/штучности даже очень качественного мозга. Русский сегмент долгое время спасал относительный избыток оверквалифицированных кадров, когда таки можно было найти своего карманного гения на разумных условиях, но все хорошее кончается, манагерам придется перестать надеяться на “джина из бутылки” который пусть за дорого, но усе решит, а начать думать головой.
А им не обязательно попадать под автобус, люди еще просто меняют место работы, уходят в декрет и на больничный или просто возникает куда лучшее для них применение чем заставлять их копаться в остонадоевшей компоненте десятый год подряд.
Короче, неосторожные и нелояльные негодяи, совершенно плюющие на проблемы бедного владельца проекта, который по какой-то причине целиком и полностью проигнорировал в общем-то неплохо проработанный во многих методиках подход к обеспечению supportability - то бишь способности продукта к поддержке и дальнейшему развитию.
Но вообще еще много интересного сделать в разработке ПО. Например не озаботиться архитектурой, или забить на управление качеством, или не париться требованиями - и во всех случаях если проект не провалится - то возникает совершенно неожиданная (tm) и удивительная зависимость от пары человек которые чудом проект сделали вопреки всем усилиям заказчика и работодателя ни в коем случае проекта не допустить :-)
Увы, продолжает встречаться куда чаще чем должно бы.
Статья спорная, но взгляд очень интересный и почерпнуть из неё можно много полезного. Но, просто по опыту, 8 из 10 читателей "под кат" там где вы оговариваетесь про ЦПТ скорее всего даже не заглянут, а вот идею категорично выраженную в конце уже понесут гордо на флаге "я на хабре прочитал, там же все мега-профи сидят". :-) Совесть у вас в любом случае чиста, я тоже считаю что читать не умеет - сам себе злая буратина, но они ж потом так же будут страдать на каждом углу как их бедных обманули.
Про питон логика понятна. Я собственно чисто из интереса спросил. С моей колокольни читать код про статанализ - надо 99% знания статистики и только 1% знания языка. Да и скорости выполнения не то что бы были очень важны, чай не в реальном времени считаем. Зато на R все это пишется в 3 раза быстрее и в 3 раза короче. Ну и время развернуть - начать - 5 минут. Хотя операции типа нарезки сетов в одну строку могут напугать, что есть - то есть :-)
Насчет раскатывания - ну я ж тоже сразу предположил сленг, и поискал. При всем моем уважении - одно использование на первые три страницы выдачи. Опять-таки, дело хозяйское, но если избежать узкоспециального сленга - то статья станет только лучше. :-)
А по теме...
я описываю в статье, какие условия на самом деле требует t-test для корректной работы
Вы про кат с оговоркой про ЦПТ? Тогда, если честно, не совсем понятно в чем тут новость. Всю жизнь же проверяли данные например Шапиро-Вилксом и если данные достаточно близки к НР - то и t-тест или anova вполне себе применимы.
я привожу примеры, в каких случаях этот метод может привести к ошибкам, а когда его можно применять в статье.
И, как мне показалось, пример, особенно где про крупных клиентов - он скорее сигнал к тому что может быть критерии эксперимента или таргет-группу надо было по другому проектировать. По крайней мере прислали б мне студенты такой эксперимент в качестве работы по 6 сигма - именно перепланировать эксперимент я бы и отправил. :-) Ну если только у вас совсем нет возможности бить по конкретным группам в рамках тестирования гипотезы.
Про то, что статья получилась огромной
С точностью до наоборот. Маленькая она сильно :-) Ее можно сделать в 3 раза больше и она только выиграет.
А делилась, как мне кажется, легко. Рассуждения о презентации результатов тестирования - вполне себе статья сама по себе и отличная статья, кстати. Близкая к сердцу куда более широкой аудитории :-) Нюансы применения t-теста для не "сферических НР в вакууме", а в реальности (да хотя бы просто когда какая-то с...волочь взяла и округлила исходные данные до целых, при общем диапазоне в пару десятков единиц :-)) - еще статья. Борьба с выбросами - еще статья.
А вторую пишите обязательно, в потоке УГ из серии "как мы классно внедрили модную но никому не нужную фигню" - прям глоток свежего воздуха. :-)
Спасибо, вы то что я написал в первом комментарии продемонстрировали на практике. Ну или если автор действительно такое писал - было бы здорово чтобы он прямо подтвердил, тогда собственно вопросов и не останется.
Хм… два нюанса. Во-первых статья только выиграет если читателю не придется подменять одно слово другим. Все-таки выкатили как у вас в примере там нигде не используется, только раскатили. А это все-таки два сильно разных слова по значению. Но и во-вторых как минимум один раз там в статье раскатывают тест. Даже приняв ваше объяснение - я не вижу как именно следует трактовать эту фразу в контексте статанализа.
Почему питон, а не R, тоже самое на порядок проще там делается? Плюс очень приличные, но при этом простые в использовании пакеты для визуализации сразу есть. В областях где плотно зависят от статистики - R ща чуть ли не выбор по умолчанию.
Но вообще это вы в одной статье попытались рассказать сразу три главы учебника по какой-нибудь 6 сигма. :-) Есть подозрение что для человека, который не в теме, не очень понятно будет. А изобилие транслитерированных терминов типа “раскатать” (лично я не сразу понял что это не от русского глагола “катать”, а от английского cut). А если учесть достаточно смелое утверждение о применимости т-теста для данных не попадающих под нормальное распределение и пока более чем спорно выглядящий метод фильтрации outliers… Может быть стоит чуть подробнее и тут уж точно надо показывать и на каких выборках, и с какой целью принималось такое решение. Я вполне допускаю что существуют ситуации когда это решение было обоснованным, но как общее правило - очень, очень смелое утверждение.
Переизобретение позднего связывания. Собственно тот случай когда свои шишки набивать нету необходимости - достоинства и недостатки позднего связывания, особенно как в данном случае "на стероидах" - давно набиты.
Hint: начать можно с простого - ошибка в написании имени метода выявляется только при запуске приложения. В то время как уже практически доказано что shift left подход (обнаруживать ошибки как можно раньше) - дает видимое увеличение качества и при ускорении time to market - зачем-то делается shift to right. Дальше можно поразвивать эту мысль, например в сторону что произойдет со статическим анализом что качества, что безопасности кода.
Мотивация понятна - предложенный путь дает небольшую экономию времени разработчика (но не времени до вывода на прод). За это кстати надо тоже сказать спасибо метрикам типа velocity которые внедряют псевдо-скрам-мастера, или еще хуже - утилизации (вообще коробит когда про людей говорим) вместо бизнес-ориентированных метрик того же Evidence Management Guide.
Так что чисто технически - действительно интересная работа, но прикладной смысл далеко не очевиден.
Частично справедливое замечание, но есть один нюанс.
Работа с клавиатуры действительно быстрее работы мышкой, если обладаешь навыком слепой печати. Я не любитель vim, но с Visual Studio работаю схожим способом - с клавиатуры. Даже исследования есть по этому поводу, там речь от разнице в двое между мышкой и клавиатурой по скорости.
Раз уж отсылаются к мастеру, то прям просится другая цитата оттуда:
“А сегодня я нашел два способа завязывать шнурки, один хорошо чтобы ходить, другой - что бы падать”
Старый код, конечно, попахивал, после рефакторинга - завонял. Раньше логика зависимая от строковой константы была хотя бы стыдливо спрятана в API, а теперь торчит наружу, поджидая неосторожного джуна или что еще хуже - клиента, чтобы тот выстрелил себе в ногу. И главное что статическим анализом кода такое уже не поймать, только дебаг, только хардкор, причем обязательно с заходом в функцию, чтобы понять чеж там происходит. “SOLID? Never heard about…”
Больше, понимаешь, книжек, хороших и разных.
В чем смысл называть итерацию, построенную по принципам последовательной разработки - спринтом? Возможно куда проще будет и команде и заказчику - если работать по принципам предсказательного управления проектами (в простонародье - водопада) в рамках процесса, разработанного именно для этой модели. MSF там или RUP. Тем более что когда нет непредсказуемости в требованиях и условиях выполнения - эти модели дают результат быстрее и дешевле. Да и изобретать ничего не надо будет - тестовые сценарии скажем всегда были неотъемлимой частью варианта использования в RUP, а тест-дизайнер был вовлечен в процесс управления требованиями и изменениями.
Комментарий - золото!
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
Ну, если учесть насколько западная тусовка в гуманитарных науках повернута на левых идеях - это совершенно не удивительно.
Да и принципе кто помнит как делался нормальный НИОКР в СССР, глядя на Agile легко заметит, что там очень много "хорошо забытого старого". :-)
Сразу оговорюсь, как переводчик, статья описывает применение ПБ именно там где оно нужно, где эффект зависит от реальной командной работы - т.е. работ над сложными проектами (как оно понимается в теории сложности), ситуаций хаоса, создания нового знания (НИОКР). Ничего в статье не утверждает, что ПБ надо делать просто потому что это круто и всем срочно нужно. Статья исключительно о том, что если вам действительно нужна ПБ - то можно избежать, увы, распространенных ошибок. Так бывает когда “коачи” забывают простой принцип, хорошо сформулированный Лайзой Адкинс на W.A.T. (Women in Agile and Technology) в этом году: “Мы не коачи как в психологии, мы не работаем в интересах пациента. Мы здесь чтобы клиенты и компании получили эффективную и работающую команду”.
Само понятие ПБ может “триггерить” тех, кто столкнулся к кривой реализацией. Меня лично подвигла на поиск этого материала ситуация когда, в рамках оказания консультационных услуг, мне пришлось довольно жестко занимать сторону одного-единственного человека в команде, кто не боялся “резать правду-матку”, в то время как остальная команда, манипулируя словечками типа “ПБ”, “токсичность”, “софт-скиллз”, пыталась его натурально заткнуть. И так, к сожалению, тоже бывает. И я искренне понимаю почему что у этого человека, очень талантливого инженера теперь будет не очень реакция на идеи о ПБ.
Так что если кого задело - заранее прошу прощения. Ни разу имел в виду. Наоборот, надеюсь что эта статья даст аргументы для диалога с такими "коачами". Все-таки часто "вон че буржуи пишут" оказывается более весомым аргументом чем просто здравый смысл.
Фух, дописал. Cheers y'all!
Соглашусь, вы правы. И тут тоже "нет ничего нового под солнцем"
А почему она должна помочь? Идолопоклонничество еще в заповедях, которые товарищ Моисей принес, осуждалось, так что это было ой как задолго то титтеров, нашего десятилетия, нашего века, и даже нашей эпохи.
Вы привели достаточно длинную статью с пространными рассуждениями и без статистики, поэтому для внятной дальнейшей дискуссию пожалуйста процитируйте что именно из этой статьи навело вас на мысль что она подтверждает утверждение “это 14-16 летние вопят”. Мне бы не хотелось гадать и думаю что остальным читателям тоже. Спасибо.
Возможно зависит от того где, но по тому что я вижу - я бы скорее спросил в ответ - а разве 14-16-ти летние там вообще сидят? Насколько я могу судить - твиттер это социалка для тек кому сейчас 25-35 скорее, по крайней мере для европы и штатов. https://www.omnicoreagency.com/twitter-statistics/
Про РФ и твиттер честно скажу - понятия не имею, но работая с молодыми специалистами, и со школьниками - аналог американским миллениалам я скорее вижу в все-таки в нынешних 20-25 летних. Так что отставание если и есть, но не на 10 лет.
А я уже расслабился и принял как факт. Люди те же, но из-за быстрой связи и социальных сетей - мода распространяется намного быстрее, впрочем так же быстро и затухает. А так, нормальных людей хватает чтобы не впадать в отчаяние, а всем и каждому все равно ума не вложишь. :-)
А что толерантность - это реакция на последствия педагогических экспериментов 90-2000х которые вырастили поколение крайне ранимых и психически неустойчивых. Это тем более пройдет, поколение которым сейчас 15-20 внушает мне надежду, они наелись и социальных сетей, и толерантности и не верят ни в бога, ни в черта. Чем-то похожи на нас 30 лет назад.
Статья вызывает небольшой когнитивный диссонанс :-) С одной стороны явно есть опыт и определенные меткие наблюдения о природе людей, с другой - этот опыт почему-то не привел к тому чтобы научиться различать ущербные идеи и их ущербную реализацию, по другому давно метко сформулированный русским народом как “заставь дурака Богу молиться - он себе лоб расшибет”. Правда тогда бы и длинной статьи бы не было, можно было бы сократить до “дураки - плохо” и пойти слушать битву с дураками Макаревича. Хотя бы для того чтобы не впадать в состояние в котором “все вокруг такие дураки, один только сам-себе-я д’Артаньян”. Не надо, седые волосы на жопе и избыток устаревшего местами опыта не дает нам на этого особого права.
Тем более что ничего не ново, кто в области уже давно - может вспомнить “дурацкий” приход ПК на смену мейнфреймам, “дурацкое” увлечение толстыми клиентами на dBase подобных (забавно повторяющееся сейчас один-в-один с SPA), “дурацкие” попытки делать RAD, причем у каждого как дырка в жопе - уникальный и свой, пришедшие им на смену и не менее “дурацкие” внедрения RUP или CMMx, “дурацкие” сертификации по ISO9000. На все новое были и те, кто применял это бездумно, не всегда многочисленные, но всегда громкие, и те кто кричал - это все фигня.
В целом вы правильно зашли с теории сложных систем, но можно было продолжить в той же канве, бо совсем рядом там же мы найдем преимущества эмержетного поведения коллектива как сложной системы против единичности/штучности даже очень качественного мозга. Русский сегмент долгое время спасал относительный избыток оверквалифицированных кадров, когда таки можно было найти своего карманного гения на разумных условиях, но все хорошее кончается, манагерам придется перестать надеяться на “джина из бутылки” который пусть за дорого, но усе решит, а начать думать головой.
А им не обязательно попадать под автобус, люди еще просто меняют место работы, уходят в декрет и на больничный или просто возникает куда лучшее для них применение чем заставлять их копаться в остонадоевшей компоненте десятый год подряд.
Короче, неосторожные и нелояльные негодяи, совершенно плюющие на проблемы бедного владельца проекта, который по какой-то причине целиком и полностью проигнорировал в общем-то неплохо проработанный во многих методиках подход к обеспечению supportability - то бишь способности продукта к поддержке и дальнейшему развитию.
Но вообще еще много интересного сделать в разработке ПО. Например не озаботиться архитектурой, или забить на управление качеством, или не париться требованиями - и во всех случаях если проект не провалится - то возникает совершенно неожиданная (tm) и удивительная зависимость от пары человек которые чудом проект сделали вопреки всем усилиям заказчика и работодателя ни в коем случае проекта не допустить :-)
Увы, продолжает встречаться куда чаще чем должно бы.
Я ж не в порядке оспаривания.
Статья спорная, но взгляд очень интересный и почерпнуть из неё можно много полезного. Но, просто по опыту, 8 из 10 читателей "под кат" там где вы оговариваетесь про ЦПТ скорее всего даже не заглянут, а вот идею категорично выраженную в конце уже понесут гордо на флаге "я на хабре прочитал, там же все мега-профи сидят". :-) Совесть у вас в любом случае чиста, я тоже считаю что читать не умеет - сам себе злая буратина, но они ж потом так же будут страдать на каждом углу как их бедных обманули.
Про питон логика понятна. Я собственно чисто из интереса спросил. С моей колокольни читать код про статанализ - надо 99% знания статистики и только 1% знания языка. Да и скорости выполнения не то что бы были очень важны, чай не в реальном времени считаем. Зато на R все это пишется в 3 раза быстрее и в 3 раза короче. Ну и время развернуть - начать - 5 минут. Хотя операции типа нарезки сетов в одну строку могут напугать, что есть - то есть :-)
Насчет раскатывания - ну я ж тоже сразу предположил сленг, и поискал. При всем моем уважении - одно использование на первые три страницы выдачи. Опять-таки, дело хозяйское, но если избежать узкоспециального сленга - то статья станет только лучше. :-)
А по теме...
я описываю в статье, какие условия на самом деле требует t-test для корректной работы
Вы про кат с оговоркой про ЦПТ? Тогда, если честно, не совсем понятно в чем тут новость. Всю жизнь же проверяли данные например Шапиро-Вилксом и если данные достаточно близки к НР - то и t-тест или anova вполне себе применимы.
я привожу примеры, в каких случаях этот метод может привести к ошибкам, а когда его можно применять в статье.
И, как мне показалось, пример, особенно где про крупных клиентов - он скорее сигнал к тому что может быть критерии эксперимента или таргет-группу надо было по другому проектировать. По крайней мере прислали б мне студенты такой эксперимент в качестве работы по 6 сигма - именно перепланировать эксперимент я бы и отправил. :-) Ну если только у вас совсем нет возможности бить по конкретным группам в рамках тестирования гипотезы.
Про то, что статья получилась огромной
С точностью до наоборот. Маленькая она сильно :-) Ее можно сделать в 3 раза больше и она только выиграет.
А делилась, как мне кажется, легко. Рассуждения о презентации результатов тестирования - вполне себе статья сама по себе и отличная статья, кстати. Близкая к сердцу куда более широкой аудитории :-) Нюансы применения t-теста для не "сферических НР в вакууме", а в реальности (да хотя бы просто когда какая-то с...волочь взяла и округлила исходные данные до целых, при общем диапазоне в пару десятков единиц :-)) - еще статья. Борьба с выбросами - еще статья.
А вторую пишите обязательно, в потоке УГ из серии "как мы классно внедрили модную но никому не нужную фигню" - прям глоток свежего воздуха. :-)
Спасибо, вы то что я написал в первом комментарии продемонстрировали на практике. Ну или если автор действительно такое писал - было бы здорово чтобы он прямо подтвердил, тогда собственно вопросов и не останется.
Хм… два нюанса. Во-первых статья только выиграет если читателю не придется подменять одно слово другим. Все-таки выкатили как у вас в примере там нигде не используется, только раскатили. А это все-таки два сильно разных слова по значению. Но и во-вторых как минимум один раз там в статье раскатывают тест. Даже приняв ваше объяснение - я не вижу как именно следует трактовать эту фразу в контексте статанализа.
Просто интереса ради
Почему питон, а не R, тоже самое на порядок проще там делается? Плюс очень приличные, но при этом простые в использовании пакеты для визуализации сразу есть. В областях где плотно зависят от статистики - R ща чуть ли не выбор по умолчанию.
Но вообще это вы в одной статье попытались рассказать сразу три главы учебника по какой-нибудь 6 сигма. :-) Есть подозрение что для человека, который не в теме, не очень понятно будет. А изобилие транслитерированных терминов типа “раскатать” (лично я не сразу понял что это не от русского глагола “катать”, а от английского cut). А если учесть достаточно смелое утверждение о применимости т-теста для данных не попадающих под нормальное распределение и пока более чем спорно выглядящий метод фильтрации outliers… Может быть стоит чуть подробнее и тут уж точно надо показывать и на каких выборках, и с какой целью принималось такое решение. Я вполне допускаю что существуют ситуации когда это решение было обоснованным, но как общее правило - очень, очень смелое утверждение.