Как обычно статья о метаболике от человека без биологического образования, поэтому вы на все и смотрите так просто. А как человек ожидавший на экзамене по биохимии вопроса "молекула глюкозы попала мышцу, что было дальше...", я бы не был так категоричен.
Во первых наверное для вас будет открытием, что почти все метаболические пути проходят через циклы. И не просто так - это способ как быстро обеспечить клетку различными веществами, которые нужны "прямо сейчас", так и загонять различные вещества, которые "удалось добыть" по общему пути.
Для этого вещество преобразуется по циклу через несколько этапов в ... само себя, пришел пируват, стал цитратом - прошел несколько стадий и снова цитрат - и вот вам цикл Кребса. При этом большинство циклов в отличии от Кребса полезного "как бы" ничего не делают и вся хим. энергия затрачиваемая на преобразование уходит... в тепло. Чем быстрее цикл крутится и чем больше в этом цикле вещества, тем выше лабильность - прижали один переход и вот вам накопилось много вещества X - которое стоит до этого перехода.
Подобные циклы тратят очень много энергии как бы "в пустую", обеспечивая лабильность системы. Но так же вполне могут и дожимать энергобаланс в нужную сторону, когда вы съели или не смогли догнать лишнюю булочку.
Во вторых, ключевым местом получения энергии для эукариотов в режиме "все хорошо" является митохондрия. А с нашим содержанием глюкозы в крови у клетки всегда все хорошо. Это если упростить такой конденсатор, который с одной стороны заряжается от съеденного, а с другой разряжается с получением АТФ - универсального аккумулятор для клетки. Как понятно конденсатор может "подтекать" и этому может помочь всякая химия, как родного для клетки происхождения, так и внешнего.
От дешевого и дубового динитрофенола с вагоном побочек, до тонкой но очень дорогого FCCP с вагоном не сильно поменьше. И вот эти вещества позволяют утекать в тепло существенной части добытого заряда "конденсатора". Нашли бы такое безопасное и дешевое вещество - нужды бы в аземпике и калорик рестришне не было. Но пока ищут...
А вот исследования про падение средней температуры в популяции, указанные выше, лично меня бы натолкнули на определенный мысли, в какую сторону стоило бы копать.
В третьих ЖКТ... Как видно из перечисленного выше, ожидать, что ЖКТ это прям стопроцентная труба, которая работает постоянном в режиме - очень наивно, разве что вы робот - едите и в туалет всегда ходите строго по графику с одним цветом, консистенцией и весом. Во всех остальных случаях даже непродолжительный анализ того, что имеем на выходе... дает сомнения в постоянстве данного инструмента. А что на это влияет - гормоны, запас жира, психосоматика или фаза луны - вопрос. Но скорее всего все из перечисленного просто с очень разным весом.
В четвертых, коррелировать хитро измеренный по изотопному составу в костях метаболизм и простую калорийность продуктов, т.е. теплоту выделенную сжиганием съеденной булочки очень странно. А вот то что они так вот взяли и совпали..... меня бы как, человека проведшего не один год в экспериментальной лабе, крайне бы насторожило.
Но посыл про больше ходить и меньше жрать полностью поддерживаю) Хуже точно не будет - калорик рестришн еще никто не отменял.
У Вас две неоднородные цепи Маркова которые вы пытаетесь проверить на корреляцию между собой.
Вместо того, чтобы думать как прикрутить какой-нить коэффициент спирмана для оценки корреляции в идеале с O(n) - например ограничив глубину шагов используемых для корреляции, (исходя из описания "в лоб" явно будет O(n^2))
И постараться исходя из области реального применения впихнуть их в одну цепь с количеством состояний существенно меньше чем n^2, чтобы сложность опять же к квадрату не подскочила вы сразу играться в ML? Даже использование Витерби в вашем случае это заход с козырей .
Так что соглашусь с предыдущим оратором, выбор того, что почитать стоит начинать с его списка.
то, что владелец ЭЦП огребет первым - не вызывает сомнения, но и админ тоже не у дел не окажется. Он обеспечивает функционирование инфраструктуры, и так же несет ответственность за ее эксплуатацию. Сомневаюсь, что ему удастся объяснить, что бухгалтер знающий, что "нужно воткнуть флешку и нажать кнопку" сам, принял информированное решение об использовании такой схемы.
Или, что у него есть бумага от гендира в которой написано, что сделайте именно так, и не важно что в инструкции, которую мы подписали при получении токена в УЦ написано.
В любой непонятной ситуации, все включая гендира будут говорить - я только кнопки давить умею - все проектировал настраивал он, мимо инструкции делал тоже он. Захочет ли админ участвовать в этом цирке даже если, как вы говорите, по итогу у него проблем не будет - вопрос открытый.
А поэтому во всем, что связано с криптографией, правило одно: 63-ФЗ + инструкция ПО/железа, которое используем и ни шагу в сторону.
Помимо уже обозначенных выше вопросов безопасности и нарушений правил использования токенов, которые приведут к тому, что в любой непонятной ситуации крайними будете вы, не понятна причина по которой вы это делаете. У вас может быть более одной подписи в организации и в зависимости от назначения вам просто надо правильно ее оформить.
Если речь идет про отчетность, например, ФНС или ПФР - сертификат регистрируются либо ножками, либо через специальные приемные комплексы, например ИРУД для ФНС.
Сертификат лица не являющееся генеральным директором, регистрируются вместе с параметрами доверенности, в том числе для УП. Информацию об этом поставляет в ФНС ваш СОС, он же и проверит вашу доверенность.
Если речь идет про счет-фактуры, то ранее сертификаты, которыми можно подписывать СЧФ требовали бумажную доверенность и регистрацию через 13-ый ЭДО ФНС вашим оператором ЭДО. Сейчас он это же делает через АИС3.
Договора так же может подписывать любой сотрудник с бумажной доверенностью.
Понятно, что сертификат на каждого сотрудника это деньги, доверенность это время, но риски, которые вы берете даже физически передавая токен, имеющий право любых действий от имени организации стороннему лицу, кажутся несколько существеннее.
Если же по какой-то непонятной причине для вас это приемлемые риски, и проблема только техническая посмотрите в сторону облачной подписи. Не знаю сертифицировали ли ее уже для всех необходимых вам действий, но вполне уже могли
Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
При виде того, что могут "серьезного" поймать статистические анализаторы у обычного мидла должны волосы дыбом вставать.Не один и не два раза прогонял один известный тут анализатор на своем коде, который говорил все ок. Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей - прочитайте комментарий ниже - меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Как бы мы не хотели жить в идеальном мире идеального кода приходится опираться на экономическую целесообразность. В начале карьеры, а это было почти 15 лет назад, я работал в конторе, которая писала ПО для банков - вот там тестили и автоматически и вручную вдоль и поперек, и у нас и при приемке очередного релиза уже в банке. Тестирование шло настолько тщательно, что от выполнения релиза до выкатки проходило до месяца (привет непрерывной интеграции и доставке). А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее, и иммитация борьбы за качество кода там не прокатывала. P.S. И.... все равно иногда на проде косяки ловили
И сейчас много где так, потому что это требует существенных ресурсов, а их всегда не хватает, при этом результат, часто, весьма сомнителен. Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует. Если вы аппелируете к списку требований, то когда он был настолько полный, чтобы действительно описывать все случаи и комбинации, которые стоит протестировать. А если считаете покрытие по методам/строкам, то цифра вообще перестает что-то значить. Идея про тесты по потоку управления... может быть, когда нибудь. Поэтому все как всегда зависит от разработчика и того, как он понимает достаточность процесса тестирования/отладки. В чем тесты действительно помогают так это в регрессионке - потому что если отломать что-то двух летней давности, то незаметить это с ними довольно сложно.
В целом верно, только не пять, лет а скорее десять. За это время разработчик уже успевает пережить одну смену основного языка/платформы и ко всем инструментам начинает относится гораздо спокойнее. В виде - хотите, например, Clickhouse/Mongo/... ? - давайте почитаем, может вам поможет. Появилась год-два назад? - подождем еще пару лет, пока отладят, допялят и остальные на ней шишки набьют. Очень хотите? - ну ладно давайте настроим, но вот так это скажется на бюжете разработки и развертывания. Все еще хотите? - ладно ищите человека который будет за это отвечать, а я пока попробую сам по мануалам развернуть и настроить.
В разработке он уже не боится легаси, т.к. знает, что после 2-3 лет работы на проекте - даже его код, для него же самого уже легаси. И чтобы этого избежать нужно либо работать над проектами, которые и не предполагается запускать - сделали отчитались -> выкинули, либо быстро напили и скипнули пока не догнали - работу же менять каждые год-два надо.. Поэтому он не прячется за модное слово техдолг, и как только он накапливается переходит к режиму скипнуть, а настаивает на непрекрашающеся переработке проекта по частям с самого начала.
А в используемых инструментах сеньор уже во многом знает как делать не надо не смотря на то, что так в нескольких умных книжках написано, а где не знает - там уже одним местом чувствует.
А менять работу он не горит желанием, потому что он уже нашел место, где ему интересно, его ценят, и денег ему хватает - не много-много, больше всех, плюс опционы, и майбах не парковке, что кажется целью джунам, а именно достаточно. Именно эти ощущения вместе его на месте и держат.
Я думаю, что вы сильно переоцениваете сроки, за которые "10 лет назад команда человек 15" запилила бы додошечке то, что они себе там наклепали
Само собой, никто не говорит, что за 20 лет ничего путного не придумали. Тут скорее задача - отсеять мусор, а не тащить в работу все стильное, модное, современное, в надежде, что тут уж заживем, а пару месяцев спустя расхлебывать.
К тому же я представляю разговор лида с начальством - мы будем делать свою работу гораздо(зачеркнуто) немного лучше, но нам нужен бюджет X5, и это без учета роста средней заплаты и роста опыта тех людей, которые уже работают и в теме - там же сплошные джуны для них 2-3 года опыта - огромный прирост.
Тут вопрос что первично, и в 2000 и сейчас с разным успехом искали серебрянную пулю, чтобы разрабатывать "не разработчиками" потому что дорого - от специальных простых языков до визуального программирования. Сейчас в моде no-code, serverless и микросервисы - вся идея, которых давайте изолируем область разработки и косяк очередного горе-разработчика на всю систему не разрастется.А вся сложность ляжет на плечи системы, она же умная справится.
Начальство потирает руки и нанимается "джунов", с любыми лычками, которые что-то "за дешево" пилят. Только оказывается, что таких "разрабов" нужна прорва, чтобы что-то написать, а чтобы все это еще и заработало требуется еще одна прорва уже более-менее спецов, чтобы все эти куски склеить, синхронизировать и запустить. В итоге людей на ту работу которую раньше требовалось 10 человек теперь нужно 80. Их средний уровень не может не падать - куски уменьшаются, ситуация прогрессирует, в общем замкнутый круг. А дефицит сотрудников преращает даже горе-программистов в золотых, а их нужна прорва.
Как и всегда долго такое не продлится, и уже пошел откат по части "чудо-технологий", например микросервисов, о чем уже писали. А лет через 10 пойдет новая волна.
Самое веселое, что за примерами далеко ходить не надо - тут одна компания часто пишет. Видимо появившаяся после того как владельцы на пицце поднялись и решили куда-та деньни вложить(зачеркнуто) потратить.И гордо заявляют что у них во всем полный топчик. Смотрим описание работ - 2 EPR (сейчас затерли и указывают только много-много микросервисов и "проектов"...) + сайт + мобильное приложение - средняя нагрузка 3 заказа/с и нагрузочное тестирование, аж на 14 заказов/с. С такой задачей лет 10 назад комфортно справились бы команда человек 15, включая бизнес-аналитика и тестировщиков. У них сейчас 160.., т.е. без начальства, сопутсвующих не IT сотрудников и подснежников уж человек 80 то точно IT занимаются.
Что я хорошо усволил за 7 лет в двух генноинженерных лабах, так это то, что красивая картинка из презентации и экспериментальная реальность клеится друг к другу чуть больше чем никак, а про реальную клинику делите еще на 100.
А даже если и клеится, то основная проблема смещаяется с просто "сделать", в режим сделать "чуть-чуть" - только там где надо и только столько, сколько нужно. Как говорится, как отличить обычный табак от генномодифицированого - легко один будет выше тебя, а второй комнатной геранью. Речь конечно шла о зеленой фабрике персональных антител (не транзиентная экспрессия), но общую тендецию отражало.
И это еще реальная гипотеза, с точечной, аккуратной корректировкой конкретного метаболического процесса. А тут один стопор цитокинеза может наделать дел. Я работал со связью S-фазы с одним метаболическим эффектом, она конечно поважнее для клетки, чем деление цитоплазмы, но неприятных эффектов при ее остановке был вагон и маленькая тележка.
И это еще при условии, что кассета встанет куда надо, а то она сама пока выглядит очередной новомодной серебрянной пулей. Плюс доставлять во взрослый организм ее придется ретровирусом - не в электропоратор же запихивать. А это точность... и эффективность... Одно дело недостающий фермент добавить - он всем тканям пригодится и суммарный эффект будет, а здесь потребуется очень ткане-специфичный вирус.
Хотелось бы, чтобы все было так просто, но реальность от этого очень сильно далека.
P.S. Еще когда учился, нам говорили, что основная проблема срастания нейронов в появлении соединительной ткани - и как раз недопущение ее появления в месте разрыва - перспективная цель, не дайте ей появится и все само срастется. Даже какую-то химию тестировали, а уже больше 10 лет прошло.
Речь шла о Linux варианте, чтобы не приходилось две ветки делать. Да и код в таком случае для обеих ОС (Linux/Windows) унифицированный получается. А в Windows да, проблем с RSA к счастью нет.
Учитывая что альтернатива это OpenSSL, то наверняка будет удобнее. Но пока на 5.0 версию вроде нет сертификата, поэтому целиком перейти на нее не получится. Так что видимо пока придется работать с двумя системами сразу — ГОСТовые через сертифицированный CSP 3.9 или 4, а все остальные через OpenSSL.
Как обычно статья о метаболике от человека без биологического образования, поэтому вы на все и смотрите так просто. А как человек ожидавший на экзамене по биохимии вопроса "молекула глюкозы попала мышцу, что было дальше...", я бы не был так категоричен.
Во первых наверное для вас будет открытием, что почти все метаболические пути проходят через циклы. И не просто так - это способ как быстро обеспечить клетку различными веществами, которые нужны "прямо сейчас", так и загонять различные вещества, которые "удалось добыть" по общему пути.
Для этого вещество преобразуется по циклу через несколько этапов в ... само себя, пришел пируват, стал цитратом - прошел несколько стадий и снова цитрат - и вот вам цикл Кребса. При этом большинство циклов в отличии от Кребса полезного "как бы" ничего не делают и вся хим. энергия затрачиваемая на преобразование уходит... в тепло. Чем быстрее цикл крутится и чем больше в этом цикле вещества, тем выше лабильность - прижали один переход и вот вам накопилось много вещества X - которое стоит до этого перехода.
Подобные циклы тратят очень много энергии как бы "в пустую", обеспечивая лабильность системы. Но так же вполне могут и дожимать энергобаланс в нужную сторону, когда вы съели или не смогли догнать лишнюю булочку.
Во вторых, ключевым местом получения энергии для эукариотов в режиме "все хорошо" является митохондрия. А с нашим содержанием глюкозы в крови у клетки всегда все хорошо. Это если упростить такой конденсатор, который с одной стороны заряжается от съеденного, а с другой разряжается с получением АТФ - универсального аккумулятор для клетки. Как понятно конденсатор может "подтекать" и этому может помочь всякая химия, как родного для клетки происхождения, так и внешнего.
От дешевого и дубового динитрофенола с вагоном побочек, до тонкой но очень дорогого FCCP с вагоном не сильно поменьше. И вот эти вещества позволяют утекать в тепло существенной части добытого заряда "конденсатора". Нашли бы такое безопасное и дешевое вещество - нужды бы в аземпике и калорик рестришне не было. Но пока ищут...
А вот исследования про падение средней температуры в популяции, указанные выше, лично меня бы натолкнули на определенный мысли, в какую сторону стоило бы копать.
В третьих ЖКТ... Как видно из перечисленного выше, ожидать, что ЖКТ это прям стопроцентная труба, которая работает постоянном в режиме - очень наивно, разве что вы робот - едите и в туалет всегда ходите строго по графику с одним цветом, консистенцией и весом. Во всех остальных случаях даже непродолжительный анализ того, что имеем на выходе... дает сомнения в постоянстве данного инструмента. А что на это влияет - гормоны, запас жира, психосоматика или фаза луны - вопрос. Но скорее всего все из перечисленного просто с очень разным весом.
В четвертых, коррелировать хитро измеренный по изотопному составу в костях метаболизм и простую калорийность продуктов, т.е. теплоту выделенную сжиганием съеденной булочки очень странно. А вот то что они так вот взяли и совпали..... меня бы как, человека проведшего не один год в экспериментальной лабе, крайне бы насторожило.
Но посыл про больше ходить и меньше жрать полностью поддерживаю) Хуже точно не будет - калорик рестришн еще никто не отменял.
поправка O(nlogn) и O(n^2 logn) - там же еще сортировка для ранжирования будет
У Вас две неоднородные цепи Маркова которые вы пытаетесь проверить на корреляцию между собой.
Вместо того, чтобы думать как прикрутить какой-нить коэффициент спирмана для оценки корреляции в идеале с O(n) - например ограничив глубину шагов используемых для корреляции, (исходя из описания "в лоб" явно будет O(n^2))
И постараться исходя из области реального применения впихнуть их в одну цепь с количеством состояний существенно меньше чем n^2, чтобы сложность опять же к квадрату не подскочила вы сразу играться в ML? Даже использование Витерби в вашем случае это заход с козырей .
Так что соглашусь с предыдущим оратором, выбор того, что почитать стоит начинать с его списка.
Исходя из постановки задачи скорее стоит прочитать про цепи Маркова и алгоритм Витерби.
то, что владелец ЭЦП огребет первым - не вызывает сомнения, но и админ тоже не у дел не окажется. Он обеспечивает функционирование инфраструктуры, и так же несет ответственность за ее эксплуатацию. Сомневаюсь, что ему удастся объяснить, что бухгалтер знающий, что "нужно воткнуть флешку и нажать кнопку" сам, принял информированное решение об использовании такой схемы.
Или, что у него есть бумага от гендира в которой написано, что сделайте именно так, и не важно что в инструкции, которую мы подписали при получении токена в УЦ написано.
В любой непонятной ситуации, все включая гендира будут говорить - я только кнопки давить умею - все проектировал настраивал он, мимо инструкции делал тоже он. Захочет ли админ участвовать в этом цирке даже если, как вы говорите, по итогу у него проблем не будет - вопрос открытый.
А поэтому во всем, что связано с криптографией, правило одно: 63-ФЗ + инструкция ПО/железа, которое используем и ни шагу в сторону.
Помимо уже обозначенных выше вопросов безопасности и нарушений правил использования токенов, которые приведут к тому, что в любой непонятной ситуации крайними будете вы, не понятна причина по которой вы это делаете. У вас может быть более одной подписи в организации и в зависимости от назначения вам просто надо правильно ее оформить.
Если речь идет про отчетность, например, ФНС или ПФР - сертификат регистрируются либо ножками, либо через специальные приемные комплексы, например ИРУД для ФНС.
Сертификат лица не являющееся генеральным директором, регистрируются вместе с параметрами доверенности, в том числе для УП. Информацию об этом поставляет в ФНС ваш СОС, он же и проверит вашу доверенность.
Если речь идет про счет-фактуры, то ранее сертификаты, которыми можно подписывать СЧФ требовали бумажную доверенность и регистрацию через 13-ый ЭДО ФНС вашим оператором ЭДО. Сейчас он это же делает через АИС3.
Договора так же может подписывать любой сотрудник с бумажной доверенностью.
Понятно, что сертификат на каждого сотрудника это деньги, доверенность это время, но риски, которые вы берете даже физически передавая токен, имеющий право любых действий от имени организации стороннему лицу, кажутся несколько существеннее.
Если же по какой-то непонятной причине для вас это приемлемые риски, и проблема только техническая посмотрите в сторону облачной подписи. Не знаю сертифицировали ли ее уже для всех необходимых вам действий, но вполне уже могли
перестроятся, а заодно научатся не класть все яйца в одну корзину. Можно подумать риски не были очевидны в течении последних 8 лет.
Для улучшения качества кода уже давно придумали "ревью", и уже это требует дополнительных ресурсов.
При виде того, что могут "серьезного" поймать статистические анализаторы у обычного мидла должны волосы дыбом вставать.Не один и не два раза прогонял один известный тут анализатор на своем коде, который говорил все ок. Но это мой код, я отлично знаю в скольких местах там было сделано из говна и палок, только руки не доходили переписать, но статистически все ок.
Как раз анализаторы и покрытие тестами и кажутся серебряной пулей - прочитайте комментарий ниже - меня учили, что все входящие параметры и ответы обязательно надо проверять в коде.. и били по рукам, когда я этого не делал - а, оказывается, за разраба это должны делать... тесты.
Как бы мы не хотели жить в идеальном мире идеального кода приходится опираться на экономическую целесообразность. В начале карьеры, а это было почти 15 лет назад, я работал в конторе, которая писала ПО для банков - вот там тестили и автоматически и вручную вдоль и поперек, и у нас и при приемке очередного релиза уже в банке. Тестирование шло настолько тщательно, что от выполнения релиза до выкатки проходило до месяца (привет непрерывной интеграции и доставке). А все потому, что косяк там это не потеря игроком мега-сабли или не работающая кнопка в интернет магазине, а чуть-чуть посерьезнее, и иммитация борьбы за качество кода там не прокатывала.
P.S. И.... все равно иногда на проде косяки ловили
И сейчас много где так, потому что это требует существенных ресурсов, а их всегда не хватает, при этом результат, часто, весьма сомнителен.
Номинальная цифра покрытия тестами тешит лишь самолюбие и ничего не гарантирует. Если вы аппелируете к списку требований, то когда он был настолько полный, чтобы действительно описывать все случаи и комбинации, которые стоит протестировать. А если считаете покрытие по методам/строкам, то цифра вообще перестает что-то значить. Идея про тесты по потоку управления... может быть, когда нибудь. Поэтому все как всегда зависит от разработчика и того, как он понимает достаточность процесса тестирования/отладки.
В чем тесты действительно помогают так это в регрессионке - потому что если отломать что-то двух летней давности, то незаметить это с ними довольно сложно.
В целом верно, только не пять, лет а скорее десять.
За это время разработчик уже успевает пережить одну смену основного языка/платформы и ко всем инструментам начинает относится гораздо спокойнее. В виде - хотите, например, Clickhouse/Mongo/... ? - давайте почитаем, может вам поможет. Появилась год-два назад? - подождем еще пару лет, пока отладят, допялят и остальные на ней шишки набьют. Очень хотите? - ну ладно давайте настроим, но вот так это скажется на бюжете разработки и развертывания. Все еще хотите? - ладно ищите человека который будет за это отвечать, а я пока попробую сам по мануалам развернуть и настроить.
В разработке он уже не боится легаси, т.к. знает, что после 2-3 лет работы на проекте - даже его код, для него же самого уже легаси. И чтобы этого избежать нужно либо работать над проектами, которые и не предполагается запускать - сделали отчитались -> выкинули, либо быстро напили и
скипнули пока не догнали- работу же менять каждые год-два надо.. Поэтому он не прячется за модное слово техдолг, и как только он накапливается переходит к режиму скипнуть, а настаивает на непрекрашающеся переработке проекта по частям с самого начала.А в используемых инструментах сеньор уже во многом знает как делать не надо не смотря на то, что так в нескольких умных книжках написано, а где не знает - там уже одним местом чувствует.
А менять работу он не горит желанием, потому что он уже нашел место, где ему интересно, его ценят, и денег ему хватает - не много-много, больше всех, плюс опционы, и майбах не парковке, что кажется целью джунам, а именно достаточно. Именно эти ощущения вместе его на месте и держат.
Само собой, никто не говорит, что за 20 лет ничего путного не придумали. Тут скорее задача - отсеять мусор, а не тащить в работу все стильное, модное, современное, в надежде, что тут уж заживем, а пару месяцев спустя расхлебывать.
К тому же я представляю разговор лида с начальством - мы будем делать свою работу гораздо(зачеркнуто) немного лучше, но нам нужен бюджет X5, и это без учета роста средней заплаты и роста опыта тех людей, которые уже работают и в теме - там же сплошные джуны для них 2-3 года опыта - огромный прирост.
Тут вопрос что первично, и в 2000 и сейчас с разным успехом искали серебрянную пулю,
чтобы разрабатывать "не разработчиками" потому что дорого - от специальных простых языков до визуального программирования. Сейчас в моде no-code, serverless и микросервисы - вся идея, которых давайте изолируем область разработки и косяк очередного горе-разработчика на всю систему не разрастется.А вся сложность ляжет на плечи системы, она же умная справится.
Начальство потирает руки и нанимается "джунов", с любыми лычками, которые что-то "за дешево" пилят. Только оказывается, что таких "разрабов" нужна прорва, чтобы что-то написать, а чтобы все это еще и заработало требуется еще одна прорва уже более-менее спецов, чтобы все эти куски склеить, синхронизировать и запустить. В итоге людей на ту работу которую раньше требовалось 10 человек теперь нужно 80. Их средний уровень не может не падать - куски уменьшаются, ситуация прогрессирует, в общем замкнутый круг. А дефицит сотрудников преращает даже горе-программистов в золотых, а их нужна прорва.
Как и всегда долго такое не продлится, и уже пошел откат по части "чудо-технологий", например микросервисов, о чем уже писали. А лет через 10 пойдет новая волна.
Самое веселое, что за примерами далеко ходить не надо - тут одна компания часто пишет. Видимо появившаяся после того как владельцы на пицце поднялись и решили куда-та деньни вложить(зачеркнуто) потратить.И гордо заявляют что у них во всем полный топчик. Смотрим описание работ - 2 EPR (сейчас затерли и указывают только много-много микросервисов и "проектов"...) + сайт + мобильное приложение - средняя нагрузка 3 заказа/с и нагрузочное тестирование, аж на 14 заказов/с.
С такой задачей лет 10 назад комфортно справились бы команда человек 15, включая бизнес-аналитика и тестировщиков. У них сейчас 160.., т.е. без начальства, сопутсвующих не IT сотрудников и подснежников уж человек 80 то точно IT занимаются.
А потом удивляемся дефициту разрабов.
Что я хорошо усволил за 7 лет в двух генноинженерных лабах, так это то, что красивая картинка из презентации и экспериментальная реальность клеится друг к другу чуть больше чем никак, а про реальную клинику делите еще на 100.
А даже если и клеится, то основная проблема смещаяется с просто "сделать", в режим сделать "чуть-чуть" - только там где надо и только столько, сколько нужно. Как говорится, как отличить обычный табак от генномодифицированого - легко один будет выше тебя, а второй комнатной геранью. Речь конечно шла о зеленой фабрике персональных антител (не транзиентная экспрессия), но общую тендецию отражало.
И это еще реальная гипотеза, с точечной, аккуратной корректировкой конкретного метаболического процесса. А тут один стопор цитокинеза может наделать дел. Я работал со связью S-фазы с одним метаболическим эффектом, она конечно поважнее для клетки, чем деление цитоплазмы, но неприятных эффектов при ее остановке был вагон и маленькая тележка.
И это еще при условии, что кассета встанет куда надо, а то она сама пока выглядит очередной новомодной серебрянной пулей. Плюс доставлять во взрослый организм ее придется ретровирусом - не в электропоратор же запихивать. А это точность... и эффективность... Одно дело недостающий фермент добавить - он всем тканям пригодится и суммарный эффект будет, а здесь потребуется очень ткане-специфичный вирус.
Хотелось бы, чтобы все было так просто, но реальность от этого очень сильно далека.
P.S. Еще когда учился, нам говорили, что основная проблема срастания нейронов в появлении соединительной ткани - и как раз недопущение ее появления в месте разрыва - перспективная цель, не дайте ей появится и все само срастется. Даже какую-то химию тестировали, а уже больше 10 лет прошло.
Данный метод запускался в нескольких потоках
При 10 потоках вставало после суммарно 120к-160к циклов.
При 50 потоках иногда не доходило и до 30к.
4-ую версию попробуем.