О какой равномерной загрузке может идти речь, если большинство задач в спринте занимают полспринта и больше? При таких условиях за два-три дня как раз и будет приходить вал задач. Да, это лучше, чем если бы задачи делались три месяца, а потом у тестировщиков неделя на валидацию, но проблема не решается — вместо огромного аврала раз в несколько месяцев регулярные авралы раз в две недели. В компании где я работаю это как-то обходится тем, что разработчики берут задачи из следующего спринта, в результате в начале каждого спринта длинные задачи уже наполовину выполнены и нагрузку на тестировщиков действительно получается размазать, но даже так случаются факапы. Плюс при этом сами спринты размазываются и становятся сложнее предсказуемыми (а ведь это одна из главных фишек скрама). Поэтому и интересно — может есть решение лучше?
Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.
Возможно тупой вопрос, но — не было мысли о том, что спектры перемещений дорожного полотна под воздействием проезжающих машин и теоретическая АЧХ собственных колебаний этого самого полотна так похожи, потому что именно с этими частотами ему проще всего колебаться? Как пример из электроники — если взять фильтр с какой-то АЧХ и подать на вход ему белый шум, то спектр выходного сигнала будет повторять эту самую АЧХ. Ни в коей мере не пытаюсь принизить проделанную работу, правда интересно.
Ну я в курсе про закон Амдала, и на десктопе у меня реальных 20 ядер (спасибо списанным процам и алиэкспрессу), но только это немного мимо, как уже отписали выше. Если при написании программы/сервиса/whatever была заложена масштабируемость, то при росте числа ядер/узлов доля времени "медленного" кода как минимум не будет расти, а как максимум будет падать. При этом время на разработку на плюсах будет в разы больше, чем на том же питоне, а человекочасы масштабировать гораздо сложнее. Более того, даже в чисто плюсовых проектах регулярный паттерн — два уровня кодовой базы, в нижнем все вылизывается под максимальную производительность (и там вдумчивая работа с памятью, минимизация syscalls и т.п.), а в верхнем пишется в стиле лишь бы побыстрее, и чтобы потом в этом легко разобраться было. При этом основное время выполняется как раз низкоуровневый код, а если это становится не так, то находится очердной "горячий" участок и выделяются очередные низкоуровневые примитивы. И вот этот высокоуровневый код на самом деле часто гораздо удобнее и проще было бы писать на чем-то более высокоуровневом, чем C++. Питон я только для примера привел, скорее как крайность.
Если задача — запускать в нужном порядке по определенным условиям число-молотилки или какие-нибудь IO (реализованные опять же на C) — то 2 порядка замедления питона погоды не сделают. Наглядный пример — Keras, который является очень удобной оберткой над в том числе Tensorflow, половина которого опять же на питоне (вторая половина как раз на C/C++), и в питоновском коде программы от силы 10% времени проводят. И тут хоть в 100 раз этот питон ускорить — ощутимого эффекта не будет. Зато продуктивность с этим самым питоном за счет высокоуровневых конструкций и быстрой обратной связи (не надо ждать компиляции, проще организовать автотесты) на порядок выше.
Если же я пишу сложную управляющую логику с очень разнообразными действиями, не сводящимися к «повторить вычисления A, B, C миллион раз», то лучше взять на вооружение всю мощь типизированного C++.
А может быть тогда имеет смысл взять что-то еще более высокоуровневое, чем C++? Что-то не требуещее компиляции по несколько минут (более-менее сложного кода), имеющее кучу удобных библиотек, позволяющее легко писать тесты? Не то, чтобы я был противником C++ — сам пишу на нем уже лет 15, но вот для своих личных экспериментов последние пару лет реально тянет писать например на связке Python + C.
"на сервере с Intel Xeon Gold сборка выполняется за 9 минут 12 секунд"
Вы его в один поток что ли собираете? Просто например даже на стареньком E5-2660v2 сборка в 20 потоков занимает чуть меньше двух минут.
Проект Ardour, вероятно, является более востребованным в профессиональной среде, чем предыдущие проекты из обзора.
Я бы сказал, что это единственный проект (из тех, что вы проверяли), который претендует на функциональность хоть как-то приближающуюся к таким продуктам, как cubase/nuendo.
Первый — laica, не помню точное название модели. Умеет измерять температуру по лбу, температуру просто поверхностей (например воды в ванне) и температуру в комнате. Температуру поверхностей измерял точно, температуру тела — очень и очень нестабильно. Заподозрил, что дело может быть в том, что температура поверхности лба имеет слишком большую зависимость от внешних факторов, и решил купить ушной. Bwell прям как на заглавной картинке к статье (собственно начал писать здесь комментарии как раз увидев его и слегка «пригорев»). Умеет измерять по лбу и через ухо, причем говорит, что измеряет через ухо только если реально его плотно в ухо засунуть. По лбу — выдает ересь еще большую, чем laica, в ухе — измеряет довольно точно, но только во взрослом. Засунуть его в детское ухо так, чтобы он понял, что он в ухе не получилось — слишком толстый зонд. Поскольку термометры эти — технически сложные устройства и возврату не подлежат, то после выкинутых денег на два ИК термометра желание экспериментировать пропало совсем.
Вот и повод для беспокойства. Не сама температура, а то, что она не сбивается и нет улучшения.
То, что температура реально высокая — стало понятно только после измерения ртутным термометром. ИК показывал 37.3-37.5 на тот момент. Если бы не перемерял ртутным — то даже не пытался бы сбивать.
Если 37.3 и ребёнку плохо — лучше дать НПВС, не дожидаясь 38.5
Если 37.3 и ребенку плохо — то это скорее всего не из-за температуры, а из-за интоксикации продуктами «жизнедеятельности» вируса, и НПВС тут особо не помогут.
Тут уже много мнений. В интеренете много гайдов «как убрать ртуть из градусника», а вот статистику по разбитым я не встретил пока…
Да, в том числе, что ИК часто дают погрешность. Причем по личному опыту — на несколько порядков чаще, чем разбиваются ртутные. Но нормальную статистику действительно найти тяжело.
Про связь ларингоспазма и температуры не слышал...
Врачи скорой рассказали, но да — это не истина в последней инстанции.
от 42 градусов… У детей плохая терморегуляция
Учитывая скорость, с которой может расти температура — если не начать сбивать при 38.5 и дождаться 40 — то пока жаропонижающее подействует можно и выше забраться.
И что сказала скорая? Какой диагноз?
Похоже на ОРВИ, но какая-то очень острая реакция организма, надо срочно ехать в инфекционку — мало ли что, пусть там разбираются. По факту (в больнице) оказалось ОРВИ.
При этом погрешность ИК термометра вы указываете в 2 градуса, что действительно очень много и это указывает на его неисправность… на этот случай могу предложить только иметь два ИК термометра разных марок.
Дома два разных ИК термометра разных марок. Оба для ребенка оказались бесполезны. Инструкцию читаю. Один из них мог измерять в том числе через ухо — и при таком режиме измерения были точными… на взрослых. А ребенку в ухо он просто не влезал, при этом не срабатывал датчик, что идет измерение через ухо, и термометр так же показывал чушь.
> Разбил первый градусник ещё будучи школьником. За жизнь сталкивался с разбитыми градусниками 4 раза. Что это доказывает?
Только то, что вы сталкивались с разбитыми градусниками гораздо чаще меня.
> Ваша ситуация с дочкой — температруа 37.3-37.7, девочке плохо — нужно дать жаропонижающее. Температура 39.5, но девочка бодра — сбивать температуру нет нужды.
До 38.5 она была бодра (ИК при этом показывал 37-37.5). Потом ей было уже явно хреново (причем дело под вечер), давали жаропонижающие, которые не помогали, и только когда температура в резвом темпе перевалила за 39 вызвали скорую. ИК термометром к тому моменту измеряли уже просто посмотреть насколько он врет. Теперь представьте ситуацию — верим ИК термометру, он показывает 37.5, вечер, ребенок сонливый. Ребенку год, сказать что ей очень хреново, а не просто спать хочется — не может. Считая, что все в пределах нормы спокойно укладываете спать, не зная, что температура реально 39.5 и растет. Какие шансы серьезных последствий думаю не надо объяснять?
> По одной только температуре не поставить диагноз.
Это да, но очень высокая температура сама по себе может привести к очень неприятным последствиям вплоть до смерти. Поэтому не сбивают только до 38.5, выше — сбивать нужно.
> Будем искать статистику? Я склонен больше доверять врачу, т.к. это его область деятельности.
Будем. Я никогда не склонен доверять мнению только одного человека.
> Чем опасна температура сама по себе, объясните?
Не врач, но знаю от нескольких врачей, что высокая (>39.5) температура у ребенка может вызвать судороги и ларингоспазм. При еще более высокой температуре может начаться расщепление белков. Скорее всего есть еще какие-то механизмы. Но я ни разу не слышал, чтобы врач говорил, что температура выше 39 — это нормальное состояние и ничего делать с температурой не надо.
> И какую проблему она описывает?
Вероятно, что организм решил поднять температуру, скорее всего в ответ на инфекцию. Если температура высокая — то скорее всего организму эта инфекция ну очень не понравилась, и лучше бы ему оказать _квалифицированную_ помощь — т.е. обратиться к врачу, и желательно побыстрее.
> Для детей есть пластиковые ножи, затупленные ножи.
Вы похоже не поняли аналогию. Настоящий острый нож — не детская игрушка, его нельзя давать маленькому ребенку поиграть. Ртутный термометр — точно так же не детская игрушка, и никаких проблем с откусываниями не будет, если не давать им играть, а измерение температуры контроллировать.
> Можете предложить безопасную и сравнимую по эффективности замену для ножей?
Я выше написал, почему не считаю ИК термометры (по крайней мере те два экземпляра, с которыми столкнулся сам) безопасной заменой ртутных. На мой взгляд они даже более опасны, поскольку могут дать ложное чувство спокойствия.
Т.е. данные постгреса лежали на томе RBD? И если не секрет — какой размер кластера и что за сетка между нодами?
Странно, но мне это как раз знакомо.
О какой равномерной загрузке может идти речь, если большинство задач в спринте занимают полспринта и больше? При таких условиях за два-три дня как раз и будет приходить вал задач. Да, это лучше, чем если бы задачи делались три месяца, а потом у тестировщиков неделя на валидацию, но проблема не решается — вместо огромного аврала раз в несколько месяцев регулярные авралы раз в две недели. В компании где я работаю это как-то обходится тем, что разработчики берут задачи из следующего спринта, в результате в начале каждого спринта длинные задачи уже наполовину выполнены и нагрузку на тестировщиков действительно получается размазать, но даже так случаются факапы. Плюс при этом сами спринты размазываются и становятся сложнее предсказуемыми (а ведь это одна из главных фишек скрама). Поэтому и интересно — может есть решение лучше?
Насчёт второго пункта и рекомендации использовать agile — а чем это собственно поможет? Допустим есть спринт две недели, есть куча задач, которые занимают скажем неделю и больше. Разработчики делают эти задачи, тестировщики в лучшем случае занимаются какими то exploratory задачами, в худшем просто курят бамбук. И за два дня до закрытия спринта и вваливается дохрена задач от разработчиков на валидацию — и привет аврал.
Вам повезло. Я вот был в проекте, где написание модульных тестов было запрещено. Прямым указом. Место работы я в итоге сменил...
Ну кстати шанс как раз есть — юнит тесты мало того что писать надо, но ещё и код делать тестируемым, а с анализатором нужно просто запустить его.
Только мне показалось, что цены у них немного охреневшие? 15 баксов за инстанс, который в том же digital ocean или linode стоит 5.
И, что интересно, в boost intrusive такая уже есть
Например тут можно посмотреть: https://www.ibm.com/developerworks/community/blogs/jfp/entry/A_Comparison_Of_C_Julia_Python_Numba_Cython_Scipy_and_BLAS_on_LU_Factorization
Или Numba, если нужны суровые числодробилки и не пугает необходимость ставить LLVM не ниже четвертой версии
Ну я в курсе про закон Амдала, и на десктопе у меня реальных 20 ядер (спасибо списанным процам и алиэкспрессу), но только это немного мимо, как уже отписали выше. Если при написании программы/сервиса/whatever была заложена масштабируемость, то при росте числа ядер/узлов доля времени "медленного" кода как минимум не будет расти, а как максимум будет падать. При этом время на разработку на плюсах будет в разы больше, чем на том же питоне, а человекочасы масштабировать гораздо сложнее. Более того, даже в чисто плюсовых проектах регулярный паттерн — два уровня кодовой базы, в нижнем все вылизывается под максимальную производительность (и там вдумчивая работа с памятью, минимизация syscalls и т.п.), а в верхнем пишется в стиле лишь бы побыстрее, и чтобы потом в этом легко разобраться было. При этом основное время выполняется как раз низкоуровневый код, а если это становится не так, то находится очердной "горячий" участок и выделяются очередные низкоуровневые примитивы. И вот этот высокоуровневый код на самом деле часто гораздо удобнее и проще было бы писать на чем-то более высокоуровневом, чем C++. Питон я только для примера привел, скорее как крайность.
Если задача — запускать в нужном порядке по определенным условиям число-молотилки или какие-нибудь IO (реализованные опять же на C) — то 2 порядка замедления питона погоды не сделают. Наглядный пример — Keras, который является очень удобной оберткой над в том числе Tensorflow, половина которого опять же на питоне (вторая половина как раз на C/C++), и в питоновском коде программы от силы 10% времени проводят. И тут хоть в 100 раз этот питон ускорить — ощутимого эффекта не будет. Зато продуктивность с этим самым питоном за счет высокоуровневых конструкций и быстрой обратной связи (не надо ждать компиляции, проще организовать автотесты) на порядок выше.
А может быть тогда имеет смысл взять что-то еще более высокоуровневое, чем C++? Что-то не требуещее компиляции по несколько минут (более-менее сложного кода), имеющее кучу удобных библиотек, позволяющее легко писать тесты? Не то, чтобы я был противником C++ — сам пишу на нем уже лет 15, но вот для своих личных экспериментов последние пару лет реально тянет писать например на связке Python + C.
"на сервере с Intel Xeon Gold сборка выполняется за 9 минут 12 секунд"
Вы его в один поток что ли собираете? Просто например даже на стареньком E5-2660v2 сборка в 20 потоков занимает чуть меньше двух минут.
Да, следующая часть и правда интересна
Я бы сказал, что это единственный проект (из тех, что вы проверяли), который претендует на функциональность хоть как-то приближающуюся к таким продуктам, как cubase/nuendo.
То, что температура реально высокая — стало понятно только после измерения ртутным термометром. ИК показывал 37.3-37.5 на тот момент. Если бы не перемерял ртутным — то даже не пытался бы сбивать.
Если 37.3 и ребенку плохо — то это скорее всего не из-за температуры, а из-за интоксикации продуктами «жизнедеятельности» вируса, и НПВС тут особо не помогут.
Да, в том числе, что ИК часто дают погрешность. Причем по личному опыту — на несколько порядков чаще, чем разбиваются ртутные. Но нормальную статистику действительно найти тяжело.
Врачи скорой рассказали, но да — это не истина в последней инстанции.
Учитывая скорость, с которой может расти температура — если не начать сбивать при 38.5 и дождаться 40 — то пока жаропонижающее подействует можно и выше забраться.
Похоже на ОРВИ, но какая-то очень острая реакция организма, надо срочно ехать в инфекционку — мало ли что, пусть там разбираются. По факту (в больнице) оказалось ОРВИ.
Дома два разных ИК термометра разных марок. Оба для ребенка оказались бесполезны. Инструкцию читаю. Один из них мог измерять в том числе через ухо — и при таком режиме измерения были точными… на взрослых. А ребенку в ухо он просто не влезал, при этом не срабатывал датчик, что идет измерение через ухо, и термометр так же показывал чушь.
Только то, что вы сталкивались с разбитыми градусниками гораздо чаще меня.
> Ваша ситуация с дочкой — температруа 37.3-37.7, девочке плохо — нужно дать жаропонижающее. Температура 39.5, но девочка бодра — сбивать температуру нет нужды.
До 38.5 она была бодра (ИК при этом показывал 37-37.5). Потом ей было уже явно хреново (причем дело под вечер), давали жаропонижающие, которые не помогали, и только когда температура в резвом темпе перевалила за 39 вызвали скорую. ИК термометром к тому моменту измеряли уже просто посмотреть насколько он врет. Теперь представьте ситуацию — верим ИК термометру, он показывает 37.5, вечер, ребенок сонливый. Ребенку год, сказать что ей очень хреново, а не просто спать хочется — не может. Считая, что все в пределах нормы спокойно укладываете спать, не зная, что температура реально 39.5 и растет. Какие шансы серьезных последствий думаю не надо объяснять?
> По одной только температуре не поставить диагноз.
Это да, но очень высокая температура сама по себе может привести к очень неприятным последствиям вплоть до смерти. Поэтому не сбивают только до 38.5, выше — сбивать нужно.
> Будем искать статистику? Я склонен больше доверять врачу, т.к. это его область деятельности.
Будем. Я никогда не склонен доверять мнению только одного человека.
> Чем опасна температура сама по себе, объясните?
Не врач, но знаю от нескольких врачей, что высокая (>39.5) температура у ребенка может вызвать судороги и ларингоспазм. При еще более высокой температуре может начаться расщепление белков. Скорее всего есть еще какие-то механизмы. Но я ни разу не слышал, чтобы врач говорил, что температура выше 39 — это нормальное состояние и ничего делать с температурой не надо.
> И какую проблему она описывает?
Вероятно, что организм решил поднять температуру, скорее всего в ответ на инфекцию. Если температура высокая — то скорее всего организму эта инфекция ну очень не понравилась, и лучше бы ему оказать _квалифицированную_ помощь — т.е. обратиться к врачу, и желательно побыстрее.
> Для детей есть пластиковые ножи, затупленные ножи.
Вы похоже не поняли аналогию. Настоящий острый нож — не детская игрушка, его нельзя давать маленькому ребенку поиграть. Ртутный термометр — точно так же не детская игрушка, и никаких проблем с откусываниями не будет, если не давать им играть, а измерение температуры контроллировать.
> Можете предложить безопасную и сравнимую по эффективности замену для ножей?
Я выше написал, почему не считаю ИК термометры (по крайней мере те два экземпляра, с которыми столкнулся сам) безопасной заменой ртутных. На мой взгляд они даже более опасны, поскольку могут дать ложное чувство спокойствия.