Абстракции, типы данных и прочие атрибуты языков высокого уровня нужны человеку, чтобы другой человек или он сам смогли потом понять и осознать то, что он сейчас пишет
Для исполнения программы они не нужны и даже вредны - программа, написанная в виде нечитаемой лапши имеет все шансы исполняться быстрее, если понимать как писать эффективную лапшу
Так что в этом аспекте профессор всё правильно говорит.
Интересно только, где и у кого ИИ научится правильную лапшу писать, очень мало есть людей, которые этим занимаются, в силу целого комплекса причин
Ваша методика перебора точек на отрезке просто не сходится к множеству всех точек. Между множеством "все делители числа N" и множеством "все делители любых чисел" (хотя и это не есть ещё множество всех точек на отрезке даже по мощности) есть принципиальная качественная разница, поэтому ваши индуктивные рассуждения некорректны
Ну вот и получается, что в команде, которую собрали временно и в которой люди плохо друг друга знают, ежедневное совещание нужно, чтобы во-первых руководитель тыкал отстающих мотивирующей палкой, а во-вторых чтобы направлять их друг к другу за помощью, когда они сами не понимают, что кто-то может им помочь. Это правда круто и хорошо. Вопрос только, какое отношение это имеет к стендапам скрама, который про самоорганизующиеся продуктовые команды, где по классике вообще нет руководителя и все заинтересованы в том, чтобы работа двигалась вперёд, а не вбок куда попало.
Вы руководитель же, да? Ну так вы просто проводите утреннюю планёрку, поздравляю. Какая вам от этого польза - любой руководитель понимает без подсказок
Вопрос, какая польза Васе от того, что вы его при всех спросите, почему он не сделал вчера то, что обещал. В лучшем случае это не его вина и он сделал всё, что мог, но не получилось. В худшем он заленился и накосячил, и сейчас это узнают все, включая тех, кто иначе об этом бы даже не догадывался.
Польза для Васи есть, если он действительно сильно переживает, что не получилось, но о чудо есть человек, который оказывается может помочь, но Вася об этом не знает
Вопрос, какова вероятность такого исхода в нормальной слаженно работающей команде, собранной не вчера. В такой команде если Вася с чем-то не справляется, но кто-то ему может помочь - Вася уже попросил этой помощи безо всякого стендапа
Проблема в том, что как правило никакая проактивность в вопросах самоуправления невозможна. Ну то есть наверное есть где-то команды, которые могут сказать "нам не подходит скрам, будем делать канбан" - и наступает канбан. Но лично я таких команд никогда не видел.
Отсюда и фраза про "выкидывание из скрам-рая" - обычно скрам не сам собой заводится в команде от понимания процессов, а приходит некто и говорит "вы теперь будете работать по скрам". Всей организации или как минимум всему IT-департаменту. И скрам-мастеров или инструкторов приводит. Со всеми вытекающими отсюда последствиями
А в книжках да, всё происходит так, как вы описали. И возможно в прекрасных ФААНГах далеко на горизонте ещё. Хотя тоже уже очень сильно сомневаюсь
Осталось понять, как команда должна понимать, зачем нужен стендап, если ей самой предлагается придумать, зачем он нужен. А если она вдруг скажет, что не нужен, то их изгонят из скрам-рая, и что бы ужасное ни произошло с их продуктом - сами будут виноваты
Вы, как это часто бывает, берете две экстремальные альтернативы и дальше говорите - выбирай, у тебя скрам будет или тебе плевать, что случится с продуктом.
Это манипуляция. Вполне возможен случай, когда мне совсем не плевать на продукт и одновременно совершенно нет желания придумывать, зачем мне каждое утро стоячая встреча на 5-10 минут, без которой я до этого вполне мог обходиться
Меня всегда удивляет в таких текстах (читаю их точно не первый и не второй раз) странный выверт, что сначала они утверждают, что стендапы нужны, а потом, когда возникает совершенно логичный вопрос "зачем", внезапно оказывается, что это сама команда должна решить
Если мы не знаем, зачем они нужны, откуда мы знаем, что они вообще нужны. Может быть, некоторым командам не нужны такие встречи. А может быть, таких некоторых команд 90%. Может быть, если бы их перестали навязывать как некое обязательное мероприятие и оставили самой команде решать, когда и какие встречи проводить, было бы лучше, а не хуже. Но тогда экспертам по скраму может быть нечего было бы делать
Так себе идея проверять свой уровень испанского по самоучителю для итальянцев. Испанский и итальянский крайне похожи. Я подозреваю, что носитель итальянского понимает испанский безо всякого обучения почти так же хорошо, как носитель русского понимает украинский, и лучше, чем носитель русского понимает чешский или польский
Напишет IBM свою особенную Джаву для своих мэйнфреймов - и там будет. А что эта Джава нигде больше не будет запускаться - так и этот Кобол тоже нигде больше не запустится, это IBM совершенно волновать не будет )
Это не Кобол даёт, это IBM даёт. Я очень мало знаю об этом всём, но всё что я знаю говорит о том, что когда они делали свои мэйнфреймы - ни о какой переносимости не думали принципиально. Там всё сделано самой IBM - и железо, и ОС, и компиляторы, и СУБД, вообще всё. Поэтому там граница между системным и прикладным софтом крайне призрачная. Вот это даёт производительность, а не магия языка Кобол
Так и в Java это будет работать точно так же, если вы захотите, чтобы это работало точно так же. Не хотят не потому, что так нельзя, а потому что повесишься в мегатоннах лапши, где всё связано со всем, разбираться потом.
Наверняка есть какие-то особенности, но они связаны со своеобразной архитектурой мэйнфреймов IBM, а не с тем, что Кобол такой великий язык
Интересно, как в вашем представлении супербыстро и эффективно все эти конструкции работают в языке Кобол. Кобол способен читать данные из БД (которые там лежат в виде набора байтов на жёстком диске) в 5 переменных в разных местах оперативной памяти одной командой без промежуточного байтового буфера?
Тогда на этом Коболе надо СУБД писать, им такой функции очень не хватает
Вирус ВИЧ в стадии отдельно плавающего вируса вполне себе полностью уничтожается существующими средствами лечения (ну, в подавляющем большинстве случаев) - не нужно ради этого в организм запускать бактерию из водоемов, которая скорее всего в организме человека и выжить-то неспособна
Проблема с ним в том, что он встраивается в геном зараженного человека и оттуда потихонечку постоянно реактивируется
Соответственно, в качестве лекарства от ВИЧ эта бактерия должна была бы постоянно присутствовать в крови человека, её нельзя ненадолго запустить и потом убить антибиотиками. То есть её нужно модифицировать так, чтобы она полноценно вошла в человеческий биом. Это непосильная для современной биологии задача
По поводу размера - она вероятно потому и может поедать вирусы, что она такая большая. Или можно наоборот сказать - она стала в процессе эволюции такой большой, чтобы иметь возможность поедать вирусы, это то же самое. И это с точки зрения нахождения её в организме человека отдельная проблема, такой огромный кусок иммунная система точно не пропустит и быстро начнёт убивать
5 миллионов RPS, то есть 432 миллиарда запросов в сутки, на 32.7 миллионов активных покупателей (официальная статистика компании) - это как-то ну прямо очень много. Либо вы выдаете пиковую нагрузку за типовую, либо у вас очень много паразитной нагрузки
Добросовестность - это черта характера, она либо есть либо нет. Встроить в процесс ревью вы можете только мотивацию на тщательный поиск дефектов. Это можно сделать разными способами, и любой из них не универсален, так что это довольно сложно. Но я вообще не вижу, какое отношение к этому имеет описанное в статье изменение
Кстати, у меня есть довольно хороший критерий непродуктивного ревью - когда в его ходе возникает очень много замечаний к коду не этого реквеста, а к коду, который находится в эпсилон-окрестности вокруг него. Это означает, что либо ревьюер в первый раз в жизни этот модуль видит вообще, либо что он вообще не понимает что и зачем тут написано и начал изучать всё вокруг чтобы понять
Почему вы думаете, что этот метод неэффективен для расселения в космосе
На внешних стенках МКС живут бактерии. Мало и хреново, но живут. То, что люди не могут - это проблема людей, а не эволюции
Абстракции, типы данных и прочие атрибуты языков высокого уровня нужны человеку, чтобы другой человек или он сам смогли потом понять и осознать то, что он сейчас пишет
Для исполнения программы они не нужны и даже вредны - программа, написанная в виде нечитаемой лапши имеет все шансы исполняться быстрее, если понимать как писать эффективную лапшу
Так что в этом аспекте профессор всё правильно говорит.
Интересно только, где и у кого ИИ научится правильную лапшу писать, очень мало есть людей, которые этим занимаются, в силу целого комплекса причин
Ваша методика перебора точек на отрезке просто не сходится к множеству всех точек. Между множеством "все делители числа N" и множеством "все делители любых чисел" (хотя и это не есть ещё множество всех точек на отрезке даже по мощности) есть принципиальная качественная разница, поэтому ваши индуктивные рассуждения некорректны
Ну вот и получается, что в команде, которую собрали временно и в которой люди плохо друг друга знают, ежедневное совещание нужно, чтобы во-первых руководитель тыкал отстающих мотивирующей палкой, а во-вторых чтобы направлять их друг к другу за помощью, когда они сами не понимают, что кто-то может им помочь. Это правда круто и хорошо. Вопрос только, какое отношение это имеет к стендапам скрама, который про самоорганизующиеся продуктовые команды, где по классике вообще нет руководителя и все заинтересованы в том, чтобы работа двигалась вперёд, а не вбок куда попало.
Вы руководитель же, да? Ну так вы просто проводите утреннюю планёрку, поздравляю. Какая вам от этого польза - любой руководитель понимает без подсказок
Вопрос, какая польза Васе от того, что вы его при всех спросите, почему он не сделал вчера то, что обещал. В лучшем случае это не его вина и он сделал всё, что мог, но не получилось. В худшем он заленился и накосячил, и сейчас это узнают все, включая тех, кто иначе об этом бы даже не догадывался.
Польза для Васи есть, если он действительно сильно переживает, что не получилось, но о чудо есть человек, который оказывается может помочь, но Вася об этом не знает
Вопрос, какова вероятность такого исхода в нормальной слаженно работающей команде, собранной не вчера. В такой команде если Вася с чем-то не справляется, но кто-то ему может помочь - Вася уже попросил этой помощи безо всякого стендапа
Проблема в том, что как правило никакая проактивность в вопросах самоуправления невозможна. Ну то есть наверное есть где-то команды, которые могут сказать "нам не подходит скрам, будем делать канбан" - и наступает канбан. Но лично я таких команд никогда не видел.
Отсюда и фраза про "выкидывание из скрам-рая" - обычно скрам не сам собой заводится в команде от понимания процессов, а приходит некто и говорит "вы теперь будете работать по скрам". Всей организации или как минимум всему IT-департаменту. И скрам-мастеров или инструкторов приводит. Со всеми вытекающими отсюда последствиями
А в книжках да, всё происходит так, как вы описали. И возможно в прекрасных ФААНГах далеко на горизонте ещё. Хотя тоже уже очень сильно сомневаюсь
Осталось понять, как команда должна понимать, зачем нужен стендап, если ей самой предлагается придумать, зачем он нужен. А если она вдруг скажет, что не нужен, то их изгонят из скрам-рая, и что бы ужасное ни произошло с их продуктом - сами будут виноваты
Вы, как это часто бывает, берете две экстремальные альтернативы и дальше говорите - выбирай, у тебя скрам будет или тебе плевать, что случится с продуктом.
Это манипуляция. Вполне возможен случай, когда мне совсем не плевать на продукт и одновременно совершенно нет желания придумывать, зачем мне каждое утро стоячая встреча на 5-10 минут, без которой я до этого вполне мог обходиться
Меня всегда удивляет в таких текстах (читаю их точно не первый и не второй раз) странный выверт, что сначала они утверждают, что стендапы нужны, а потом, когда возникает совершенно логичный вопрос "зачем", внезапно оказывается, что это сама команда должна решить
Если мы не знаем, зачем они нужны, откуда мы знаем, что они вообще нужны. Может быть, некоторым командам не нужны такие встречи. А может быть, таких некоторых команд 90%. Может быть, если бы их перестали навязывать как некое обязательное мероприятие и оставили самой команде решать, когда и какие встречи проводить, было бы лучше, а не хуже. Но тогда экспертам по скраму может быть нечего было бы делать
Я бывал во всех трёх провинциях, везде будут говорить с вами на castellano с удовольствием, понимая что альтернатива вообще английский )
Так себе идея проверять свой уровень испанского по самоучителю для итальянцев. Испанский и итальянский крайне похожи. Я подозреваю, что носитель итальянского понимает испанский безо всякого обучения почти так же хорошо, как носитель русского понимает украинский, и лучше, чем носитель русского понимает чешский или польский
Напишет IBM свою особенную Джаву для своих мэйнфреймов - и там будет. А что эта Джава нигде больше не будет запускаться - так и этот Кобол тоже нигде больше не запустится, это IBM совершенно волновать не будет )
Это не Кобол даёт, это IBM даёт. Я очень мало знаю об этом всём, но всё что я знаю говорит о том, что когда они делали свои мэйнфреймы - ни о какой переносимости не думали принципиально. Там всё сделано самой IBM - и железо, и ОС, и компиляторы, и СУБД, вообще всё. Поэтому там граница между системным и прикладным софтом крайне призрачная. Вот это даёт производительность, а не магия языка Кобол
Так и в Java это будет работать точно так же, если вы захотите, чтобы это работало точно так же. Не хотят не потому, что так нельзя, а потому что повесишься в мегатоннах лапши, где всё связано со всем, разбираться потом.
Наверняка есть какие-то особенности, но они связаны со своеобразной архитектурой мэйнфреймов IBM, а не с тем, что Кобол такой великий язык
Интересно, как в вашем представлении супербыстро и эффективно все эти конструкции работают в языке Кобол. Кобол способен читать данные из БД (которые там лежат в виде набора байтов на жёстком диске) в 5 переменных в разных местах оперативной памяти одной командой без промежуточного байтового буфера?
Тогда на этом Коболе надо СУБД писать, им такой функции очень не хватает
Перевод "по реквизитам" - это и есть Swift
Нет одной главной проблемы у ВИЧ. Как минимум есть три проблемы, без каждой из которых остальные две не были бы так страшны
Он поражает клетки иммунной системы
Он встраивается в геном зараженной клетки
Он очень сильно мутирует, много ошибок при копировании
Вирус ВИЧ в стадии отдельно плавающего вируса вполне себе полностью уничтожается существующими средствами лечения (ну, в подавляющем большинстве случаев) - не нужно ради этого в организм запускать бактерию из водоемов, которая скорее всего в организме человека и выжить-то неспособна
Проблема с ним в том, что он встраивается в геном зараженного человека и оттуда потихонечку постоянно реактивируется
Соответственно, в качестве лекарства от ВИЧ эта бактерия должна была бы постоянно присутствовать в крови человека, её нельзя ненадолго запустить и потом убить антибиотиками. То есть её нужно модифицировать так, чтобы она полноценно вошла в человеческий биом. Это непосильная для современной биологии задача
По поводу размера - она вероятно потому и может поедать вирусы, что она такая большая. Или можно наоборот сказать - она стала в процессе эволюции такой большой, чтобы иметь возможность поедать вирусы, это то же самое. И это с точки зрения нахождения её в организме человека отдельная проблема, такой огромный кусок иммунная система точно не пропустит и быстро начнёт убивать
5 миллионов RPS, то есть 432 миллиарда запросов в сутки, на 32.7 миллионов активных покупателей (официальная статистика компании) - это как-то ну прямо очень много. Либо вы выдаете пиковую нагрузку за типовую, либо у вас очень много паразитной нагрузки
Добросовестность - это черта характера, она либо есть либо нет. Встроить в процесс ревью вы можете только мотивацию на тщательный поиск дефектов. Это можно сделать разными способами, и любой из них не универсален, так что это довольно сложно. Но я вообще не вижу, какое отношение к этому имеет описанное в статье изменение
Кстати, у меня есть довольно хороший критерий непродуктивного ревью - когда в его ходе возникает очень много замечаний к коду не этого реквеста, а к коду, который находится в эпсилон-окрестности вокруг него. Это означает, что либо ревьюер в первый раз в жизни этот модуль видит вообще, либо что он вообще не понимает что и зачем тут написано и начал изучать всё вокруг чтобы понять