Едва ли это прямая заслуга языка:) По тезису Черча-Тьюринга все Тьюринг-полные языки эквиваленты, а значит выбор ЯП в большей степени зависит не от задачи, а от команды, которая будет с его помощью реализовывать продукт. Хоть на JS операционки пиши и запускай)
Прелесть Scala в том, что у него замечательная интероперабельность с Java и существенная академическая база , что позволяет использовать богатую экосистему Java и полноценно окунуться в мир ФП без обратной совместимости с Java, обремененной этим самым принципом обратной совместимости. Язык получился достаточно простой и гибкий, когда его понимаешь. И в этом всё и дело.
В силу того, что далеко не все преодолевают "порог входа", то те, кому это удалось, в принципе обладают явно и живым умом и любознательностью, потому заслуга того, что у них на выходе получается качественный код скорее их собственная, чем непосредственно языка. А так, почти любой проект можно писать на разных языках общего или специального назначения и выбор субъективен. А наделать багов на Scala умеючи совсем несложно как на любом другом языке.
Я бы переформулировал: Почему не все скульпторы лепят из глины или гипса? Почему некоторые берут мрамор, гранит?
В этом мире ничего невозможно точно предсказывать. Не нужно себя обманывать. ETA - это не предсказания. Это инструмент работы с рисками. У вас постановка вопроса неправильная.
P.S. То что вы описали, к слову, рядовая банальщина, которую предсказать чаще всего совсем несложно. Гораздо интереснее задача выстраивать работу в таких условиях и уметь со всем этим спокойно работать.
в 99% ЗАЧЕМ инженеру работать быстрее/медленнее объективно понятно по естественным причинам и не требует уточнений. Срочность - это объективная неотъемлемая характеристика множества явлений этого мира, которую невозможно не учитывать. Только ее надо понимать правильно - не как "быстрее", а как "наличие даты, после которой оно уже и не нужно". И работает оно как в сторону увеличения темпов работ, так и в сторону их замедления.
Поэтому срочность сама по себе никакого отношения к "потере удовольствия от работы", "выгоранию", "внутреннего уровня нормы" не имеет. А всё перечисленное возникает из-за неадекватного восприятия ситуации каждой из сторон, как в отношении способностей друг друга, так и в отношении ожидаемых трудозатрат. Но почему это происходит и что с этим делать - это уже другая история.
"Ложка дорога к обеду" - или "Задача решенная несвоевременно, решенной не является". "Хорошо, но медленно" ничем не отличимое от "Быстро, но плохо".
Все 3 пункта базируются на предположении, что абстрактный программист "мудр и светел", а абстрактный менеджер "темен и туп".
В целом, найти менеджера сложнее, чем программиста. Тупых программистов чисто статистически больше чем тупых менеджеров, просто в силу того, что их просто больше. Найти хорошего менеджера кратно сложнее чем хорошего программиста.
В среднем случае, "если разработчик работает хорошо, но медленно" то, либо он работает "не хорошо"(нужно поручить задачу другому), либо "не медленно"(объективно задача сложная сама по себе). Собственно, выбор из этик двух "или" и есть критерий "хорошего менеджера".
С оценками задач по времени постоянно воспроизводимый бардак, хотя есть очевидные намеки, что контроль по времени на этапе планирования и на этапе реализации - это принципиально разные вещи и делаться он должен принципиально разными способами.
Этап планирования. Когда задачи набираются в условный спринт, то мы решаем условную задачу "упаковки коробок в контейнер" и нам важно их все подобрать так, чтоб они были упакованы максимально плотно (в смысле заполнения). Поскольку естественным объемом спринта является его продолжительность, то предварительная оценка всех задач в часах (на деле - в человеко-часах) является естественной и практически полезной. Но это только первая часть. Оценка задачи в часах тут - это норм.
Этап реализации. Когда задачи передаются на реализацию и в Jira у вас расставлены все исполнители, то к предварительной оценке в часах нужно относиться уже очень условно. Во-первых, задача переходит на реальных исполнителей с конкретными способностями и обстоятельствами и это первая поправка. Во-вторых, реальная многозадачность, фрустрации, форс-мажоры, заболевания, праздники и т.д. - даже при идеальных процессах разработки, способны 4 часа работы превратить в 4 дня/недели ожидания результата. И это самое важное обстоятельство. Здесь уже важна только абсолютная дата, когда задача будет готова.
Поэтому, когда задача назначена на исполнителя имеет смысл вообще отказаться от оценки в часах(за 1 час, за 2 дня и т.д.) и все вопросы про ETA сводить исключительно к вопросу "Какого числа/К которому часу будет готова задача?". В этом случае вопрос о том сколько на неё было запланировано становится вторичным и служит не более чем ориентиром на ожидаемые сроки ее завершения.
Абсолютные сроки исполнителю психологически некомфортно каждый раз сдвигать вправо. В отличии от трекинга "часов на задачу", которые всегда можно поставить "на паузу" под предлогом "я болел/занимался другими важными задачами/был на митингах/ и т.д." и формально затягивать задачу будучи абсолютно правым, поскольку трудоемкость задачи хоть и оценена верно, но никак не включает в себя значимые обстоятельства конкретного исполнителя. Когда на вход подается предварительная оценка трудоемкости и и с исполнителя требуется конкретная дата, когда будет результат - его работа им самим организуется сильно иначе. Это не говоря о том, что контроль исполнения потока задач при такой постановке и для PM становится гораздо более удобным и наглядным.
Можно для наглядности привести обратный пример лексически близких, но семантически далеких слов — "зола" и "золото". (Если вы никогда не задумывались, то имя Золушка происходит именно от первого.)
Если немного задуматься, то фактическая связь между словами всё-таки есть, пусть даже, её природа скорее физико-поэтическая. Дело в том, что элементы тяжелее железа являются продуктом распада сверхновых или нейтронных звезд. И золото, в том числе - это, по сути, "зола звёзд":) Вполне себе хорошая связь слов)
генерировать случайные числа, и именно с такой вероятностью вам будут попадаться простые
тут надо подумать, но не уверен, что в общем случае оно верно. Распределения случайных величин бывают разные, да и сильно всё будет зависеть от самой выборки, из которой вы планируете выбирать числа (т.е. генерировать). По-разному может сложиться с частотой появления простых.
Возможно вы имели ввиду, что если перебирать некоторый непрерывный диапазон чисел начиная со случайного места, то с некоторой предсказуемой вероятностью вам на интервале будут попадаться простые числа.
Спорное утверждение, или не очень удачная формулировка. Если взять k-подряд идущих чисел "одинакового размера"(одной разрядности), то при небольших k независимо от размера числа, чисто ориентируясь на его значение никаких обоснованных вероятностных суждений о простоте каждого из чисел относительно друг друга сделать не получится. О числе простых чисел на интервале, да, какие-то суждения сделать можно.
Вселенная пытается нам что-то сказать? Конечно же нет.
А вот и фиг его знает! Не стоит спешить с выводами.
В замечательной книге Джона Дербишира можно найти следующее:
Нетривиальные нули дзета-функции Римана появились при исследовании распределения простых чисел. Собственные значения случайных эрмитовых матриц появились при исследовании поведения систем субатомных частиц, подчиняющихся законам квантовой механики. Скажите, пожалуйста, что вообще может быть общего между простыми числами и поведением субатомных частиц?
О связи простых чисел и квантовой механики тезисно можно посмотреть здесь.
Относительно узоров на спиралях в связи с простыми числами - ларчик иногда открывается весьма просто. Но в этой простоте всё равно скрываются жутко интересные и содержательные вещи.
При всей справедливости, ко всему сказанному не лишне будет ещё раз добавить фразу "в основном". Это связано, в основном, с тем, что большая часть трудовой занятости по найму содержит больше в себе процедурную составляющую ("делать от забора и до обеда как сказано"), нежели научно-исследовательскую или креативную ("создать то, чего вчера ещё не было"). Потому большинству крайне редко доводится столкнуться на личном опыте со вторым, что позволяет с чистой совестью и не кривя душой сказать "Я вот не могу припомнить, чтобы эти знания мне когда-нибудь оказались полезны". Всё верно, так и есть. Но есть нюанс - чтоб у первых была работа, кто-то должен создать основы для неё, а это удел вторых. И вот там, знания, подобные этим, не то что необходимы, а являются квалификацией и признаком профприходности для такого вида деятельности. Факт многочисленности первых, говорит о крайней эффективности вторых :)
У меня дети, по мере взросления, периодически спрашивают: "Зачем нужны уроки в школе, если всё есть в Интернете, а большая часть знаний никогда не пригодится" на что всегда отвечаю некогда подслушанным: "Да, большая часть школьных знаний вам никогда в жизни не пригодится. Но вот те нейронные связи, которые вы натренеруете их получая, гарантированно пригодтся вам далеко не раз." :)
Парадокс в том, что Layer Driven Architecture находится в противоречии с Domain Driven Architecture в смысле организации кода. С дной стороны, хочется чтоб отдельно и рядышком были тут components, тут services, тут templates и т.д. а с другой хотелось бы чтоб вот тут были User, Company, Client и т.д. и там внутри всё, что с ним связано.
Когда и первого и второго много (т.е. типичный проект средней сложности) возникает вопрос организации этого хозяйства и тут, на мой взгляд, плохи только крайности, а выходом является волевое решение в виде некоторого компромиса.
Например, как вариант, естественную иерархию domain сущностей внутри упорядочивать по плоской фиксированной layer driven структуре. Сложно сказать, какая форма порядка самая лучшая, но точно можно сказать, что если ничего такого не делать, то с точки зрения Evolutionary Driven Architecture о временем отсутствие какого-либо порядка со всей неизбежностью уткнет проект в п.24
Не удивлюсь, если в предыдущей итерации была история, когда этот же сервис переписывали с Java на Scala :)
Едва ли это прямая заслуга языка:) По тезису Черча-Тьюринга все Тьюринг-полные языки эквиваленты, а значит выбор ЯП в большей степени зависит не от задачи, а от команды, которая будет с его помощью реализовывать продукт. Хоть на JS операционки пиши и запускай)
Прелесть Scala в том, что у него замечательная интероперабельность с Java и существенная академическая база , что позволяет использовать богатую экосистему Java и полноценно окунуться в мир ФП без обратной совместимости с Java, обремененной этим самым принципом обратной совместимости. Язык получился достаточно простой и гибкий, когда его понимаешь. И в этом всё и дело.
В силу того, что далеко не все преодолевают "порог входа", то те, кому это удалось, в принципе обладают явно и живым умом и любознательностью, потому заслуга того, что у них на выходе получается качественный код скорее их собственная, чем непосредственно языка. А так, почти любой проект можно писать на разных языках общего или специального назначения и выбор субъективен. А наделать багов на Scala умеючи совсем несложно как на любом другом языке.
Я бы переформулировал: Почему не все скульпторы лепят из глины или гипса? Почему некоторые берут мрамор, гранит?
А потому что могут. И им этот материал нравится.
В этом мире ничего невозможно точно предсказывать. Не нужно себя обманывать. ETA - это не предсказания. Это инструмент работы с рисками. У вас постановка вопроса неправильная.
P.S. То что вы описали, к слову, рядовая банальщина, которую предсказать чаще всего совсем несложно. Гораздо интереснее задача выстраивать работу в таких условиях и уметь со всем этим спокойно работать.
Вы так про Наймана пишете, будто он вам лично напакостил))
в 99% ЗАЧЕМ инженеру работать быстрее/медленнее объективно понятно по естественным причинам и не требует уточнений. Срочность - это объективная неотъемлемая характеристика множества явлений этого мира, которую невозможно не учитывать. Только ее надо понимать правильно - не как "быстрее", а как "наличие даты, после которой оно уже и не нужно". И работает оно как в сторону увеличения темпов работ, так и в сторону их замедления.
Поэтому срочность сама по себе никакого отношения к "потере удовольствия от работы", "выгоранию", "внутреннего уровня нормы" не имеет. А всё перечисленное возникает из-за неадекватного восприятия ситуации каждой из сторон, как в отношении способностей друг друга, так и в отношении ожидаемых трудозатрат. Но почему это происходит и что с этим делать - это уже другая история.
"Ложка дорога к обеду" - или "Задача решенная несвоевременно, решенной не является". "Хорошо, но медленно" ничем не отличимое от "Быстро, но плохо".
Все 3 пункта базируются на предположении, что абстрактный программист "мудр и светел", а абстрактный менеджер "темен и туп".
В целом, найти менеджера сложнее, чем программиста. Тупых программистов чисто статистически больше чем тупых менеджеров, просто в силу того, что их просто больше.
Найти хорошего менеджера кратно сложнее чем хорошего программиста.
В среднем случае, "если разработчик работает хорошо, но медленно" то, либо он работает "не хорошо"(нужно поручить задачу другому), либо "не медленно"(объективно задача сложная сама по себе). Собственно, выбор из этик двух "или" и есть критерий "хорошего менеджера".
С оценками задач по времени постоянно воспроизводимый бардак, хотя есть очевидные намеки, что контроль по времени на этапе планирования и на этапе реализации - это принципиально разные вещи и делаться он должен принципиально разными способами.
Этап планирования. Когда задачи набираются в условный спринт, то мы решаем условную задачу "упаковки коробок в контейнер" и нам важно их все подобрать так, чтоб они были упакованы максимально плотно (в смысле заполнения). Поскольку естественным объемом спринта является его продолжительность, то предварительная оценка всех задач в часах (на деле - в человеко-часах) является естественной и практически полезной. Но это только первая часть. Оценка задачи в часах тут - это норм.
Этап реализации. Когда задачи передаются на реализацию и в Jira у вас расставлены все исполнители, то к предварительной оценке в часах нужно относиться уже очень условно. Во-первых, задача переходит на реальных исполнителей с конкретными способностями и обстоятельствами и это первая поправка. Во-вторых, реальная многозадачность, фрустрации, форс-мажоры, заболевания, праздники и т.д. - даже при идеальных процессах разработки, способны 4 часа работы превратить в 4 дня/недели ожидания результата. И это самое важное обстоятельство. Здесь уже важна только абсолютная дата, когда задача будет готова.
Поэтому, когда задача назначена на исполнителя имеет смысл вообще отказаться от оценки в часах(за 1 час, за 2 дня и т.д.) и все вопросы про ETA сводить исключительно к вопросу "Какого числа/К которому часу будет готова задача?". В этом случае вопрос о том сколько на неё было запланировано становится вторичным и служит не более чем ориентиром на ожидаемые сроки ее завершения.
Абсолютные сроки исполнителю психологически некомфортно каждый раз сдвигать вправо. В отличии от трекинга "часов на задачу", которые всегда можно поставить "на паузу" под предлогом "я болел/занимался другими важными задачами/был на митингах/ и т.д." и формально затягивать задачу будучи абсолютно правым, поскольку трудоемкость задачи хоть и оценена верно, но никак не включает в себя значимые обстоятельства конкретного исполнителя. Когда на вход подается предварительная оценка трудоемкости и и с исполнителя требуется конкретная дата, когда будет результат - его работа им самим организуется сильно иначе. Это не говоря о том, что контроль исполнения потока задач при такой постановке и для PM становится гораздо более удобным и наглядным.
Джон фон Нейман (с)
Если немного задуматься, то фактическая связь между словами всё-таки есть, пусть даже, её природа скорее физико-поэтическая. Дело в том, что элементы тяжелее железа являются продуктом распада сверхновых или нейтронных звезд. И золото, в том числе - это, по сути, "зола звёзд":) Вполне себе хорошая связь слов)
А сам ваш комментарий является замечательной иллюстрацией к известной цитате: "Знание некоторых принципов легко возмещает незнание многих фактов." :)
тут надо подумать, но не уверен, что в общем случае оно верно. Распределения случайных величин бывают разные, да и сильно всё будет зависеть от самой выборки, из которой вы планируете выбирать числа (т.е. генерировать). По-разному может сложиться с частотой появления простых.
Возможно вы имели ввиду, что если перебирать некоторый непрерывный диапазон чисел начиная со случайного места, то с некоторой предсказуемой вероятностью вам на интервале будут попадаться простые числа.
Точную то точную, но есть нюанс. Число Скьюза. т.е. смело утверждать, что там творится в области о-очень больших чисел никто не берётся.
Спорное утверждение, или не очень удачная формулировка. Если взять k-подряд идущих чисел "одинакового размера"(одной разрядности), то при небольших k независимо от размера числа, чисто ориентируясь на его значение никаких обоснованных вероятностных суждений о простоте каждого из чисел относительно друг друга сделать не получится.
О числе простых чисел на интервале, да, какие-то суждения сделать можно.
А вот и фиг его знает! Не стоит спешить с выводами.
В замечательной книге Джона Дербишира можно найти следующее:
О связи простых чисел и квантовой механики тезисно можно посмотреть здесь.
Относительно узоров на спиралях в связи с простыми числами - ларчик иногда открывается весьма просто. Но в этой простоте всё равно скрываются жутко интересные и содержательные вещи.
При всей справедливости, ко всему сказанному не лишне будет ещё раз добавить фразу "в основном". Это связано, в основном, с тем, что большая часть трудовой занятости по найму содержит больше в себе процедурную составляющую ("делать от забора и до обеда как сказано"), нежели научно-исследовательскую или креативную ("создать то, чего вчера ещё не было"). Потому большинству крайне редко доводится столкнуться на личном опыте со вторым, что позволяет с чистой совестью и не кривя душой сказать "Я вот не могу припомнить, чтобы эти знания мне когда-нибудь оказались полезны". Всё верно, так и есть. Но есть нюанс - чтоб у первых была работа, кто-то должен создать основы для неё, а это удел вторых. И вот там, знания, подобные этим, не то что необходимы, а являются квалификацией и признаком профприходности для такого вида деятельности. Факт многочисленности первых, говорит о крайней эффективности вторых :)
У меня дети, по мере взросления, периодически спрашивают: "Зачем нужны уроки в школе, если всё есть в Интернете, а большая часть знаний никогда не пригодится" на что всегда отвечаю некогда подслушанным: "Да, большая часть школьных знаний вам никогда в жизни не пригодится. Но вот те нейронные связи, которые вы натренеруете их получая, гарантированно пригодтся вам далеко не раз." :)
Пожалуй, вы правы.
Парадокс в том, что Layer Driven Architecture находится в противоречии с Domain Driven Architecture в смысле организации кода. С дной стороны, хочется чтоб отдельно и рядышком были тут components, тут services, тут templates и т.д. а с другой хотелось бы чтоб вот тут были User, Company, Client и т.д. и там внутри всё, что с ним связано.
Когда и первого и второго много (т.е. типичный проект средней сложности) возникает вопрос организации этого хозяйства и тут, на мой взгляд, плохи только крайности, а выходом является волевое решение в виде некоторого компромиса.
Например, как вариант, естественную иерархию domain сущностей внутри упорядочивать по плоской фиксированной layer driven структуре. Сложно сказать, какая форма порядка самая лучшая, но точно можно сказать, что если ничего такого не делать, то с точки зрения Evolutionary Driven Architecture о временем отсутствие какого-либо порядка со всей неизбежностью уткнет проект в п.24
Подобные рассуждения справедливы только в рамках элементарной геометрии.
Прямая - это частный случай геодезической линии просто применительно к Евклидову пространству.