1) На первом месте рынок. Если его нет — вы в заднице, а потому не суйтесь.
2) На втором месте продукт (при наличии рынка). Он должен соответствовать рынку.
3) Ну и в самом конце списка какие-то негры, которые делают то, что вы им приказываете, предварительно правильно выбрав рынок и к нему продукт.
От себя — объективно не вижу ценности команды. Если рынок и продукт выбраны правильно, то действительно нет проблем нанять кого угодно и спокойно заниматься децимацией тех из них, кто возжелал отклониться от линии на правильные продукт и рынок. При этом для оценки размера рынка или правильности продукта команда не нужна, для этого есть стандартные и не требующие особых профессионалов методики (анализы продаж конкурентов и всяческие опросы). Остальное — лишь наблюдение за отклонением продукта от требуемого рынком. Если отклоняется — неграм пинок. Ведь просто? Или я где-то ошибаюсь?
А вы не в курсе, чем не удовлетворил подход с разделением версий библиотек через разные класслоадеры? Ну и виртуальное изменение названия пакета на лету — почему нет?
Не ковырял, но в Eclipse аналогичную задачу решает OSGI. Какой там принцип? Может его использовать?
Собственно тема зависимостей в модульности самое главное, поэтому интересно понимать причины отказа от показанных решений.
Вы сейчас, по сути, отрабатываете методологию. Начальству, опять же по сути, плевать на ваши опыты до тех пор, пока строчка в затратах не сильно растёт. Вы сами «творите», опять же по сути, фактически для себя. В сумме получается условный стартап по проработке методологии обеспечения ИТ среднего предприятия. Стартап работает за деньги даже не подозревающего об этом инвестора.
У методологии потенциально есть место под солнцем. Но широкое её распространение, как и существенный рост для любого стартапа, совершенно не гарантировано. Скорее очень вероятно, что всё так и останется в рамках одной компании и вы лишь получите интересный опыт, но не более.
Но может и удастся упаковать и продать методологию другим средним предприятиям. Тогда бы возможно стал возможен вариант «неполной ставки» для тех, кому время важнее денег. Этим подход интересен. Но дьявол, как известно, в деталях. Поэтому может получиться плохо. А может и хорошо. Я со стороны разработчиков голосую за «хорошо», но понимаю, что всё это лишь очередной стартап с непонятными перспективами.
При беге и креплении на руке 4g часто хватает, но если чуть сильнее рукой взмахнёшь — выходит за диапазон. 4g это +-2g, то есть 1g сразу вычитается с одной стороны, а с другой запас 3g остаётся. У вас тоже видно на графике (если 10000=1g), что амплитуда взмахов руками выйдет за предел, если ещё вычесть 1g земного притяжения.
Собственно и по такому акселерометру можно получить некоторую информацию, но это лишь общий вид, то есть можно отличить бег от ходьбы или от взмахов палками, но не более. Для большего нужно получать скорости и перемещения по трём осям. Даже ходьбу от медленного бега можно не отличить. Вот поэтому я и говорю про необходимость расширить диапазон до 8g (будет +-4g) и повысить точность. Если ваши показания проинтегрировать, то через пару секунд вы по таким данным уже в космос полетите (положение будет «над землёй в 1-м метре»), а на самом деле всё так же бежите.
Я пытался по данным с часов бег измерять — даже сам бег и то сложно выделить. Поднимаюсь по лестнице — как будто бег получается, ну и тому подобное. Что бы отличить нужно считать положение, и считать достаточно точно. Если есть подъём на метр, значит это именно лестница, а не кривые показания — как-то так.
Акселерометр как раз работает плохо. Во первых — он ограничен по максимальному ускорению, поэтому при резких движениях кривая просто обрезается, что очевидно даёт никакую точность. Во вторых, погрешность измерений на малых ускорениях очень большая, поэтому состояние плывёт буквально за секунду, когда уже становится непонятно, какая сейчас реальная скорость, и тем более — где мы находимся (второй интеграл).
Хотя может вы встречались с приличными гироскопами? Максимальные ограничения — от 8g, точность — миллиметры/с^2 или лучше.
Когда-то давно я работал в отдельном магазине. Не сеть, но размер был неплохой. Они вполне нормально относились к обычному найму. Хотя денег, понятно, меньше чем у сетей. Правда приходилось совмещать всё, что относилось к компьютерам — кассы, юзеров, установку винды и прочую чистку мышек с реальной разработкой.
Теоретически им вряд ли было бы выгоднее нанимать админа и отдельно почасового разработчика. Админ бы не сильно меньше получал, но зато никаких гарантий от чужого разраба. А свой всё же был всегда под рукой, пока простаивал — з/п за админство начислялась (ну или оправдывалась в глазах директора).
Вообще если контора не очень большая (сотня-две человек), то тесные отношения с разработчиком полезны. Хотя разумеется, сначала нужно найти подходящего.
Ну а в больших конторах, или даже в средних, но которым нужно что-то приличное по размеру разрабатывать, стоимость потерь из-за отсутствия координации резко нарастает. Даже в сетях ERP на всю контору с учётом массы деталей очень даже требует координации. Если это покупной продукт, то координация по внедрению и настройке. Если кастом — тут вообще много задач, которые можно было бы сделать один раз, вместо десятков для каждого фрилансера.
В общем я за координацию. Может даже её можно вынести на почасовую оплату, типа один архитектор мониторит несколько заказчиков. Но всё равно без неё потери будут значительные.
Но с другой стороны — есть в бюджете строчка «расходы на ИТ» и ею начальство довольно — вот и нет нужды что-то координировать. Если у вас так, то это ни чем не обоснованный подход, кроме как экономией времени и нервов того, кто строчки в бюджете оценивает.
Автор описывал в прошлой статье (которую потом удалил) как работает по такой схеме Вкусвиль. Так вот там нет координации. Поэтому у них один проект работает, а другой в совершенно непонятном состоянии. То есть для бизнеса есть некая экономия по затратам, но так же очевидна просадка по качеству. И просадку без координации не устранить. Но координировать людей «свободных взглядов» (то есть работающих неполный день/неделю/месяц) сложнее, чем гарантированно пашущих по 40 часов в неделю. Отсюда вытекает необходимость получения гарантий от разработчиков. Но в ответ они, разумеется, потребуют гарантий от работодателя. Почасовая оплата = отсутствие гарантий. То есть в сумме во Вкусвиле не получится совместить ужа с ежом, ибо гарантии для одних не даются даром другими.
Но некоторое совмещение в виде «постоянной» и «переменной» частей команды было бы интересно, в том числе разработчикам, которые хотели бы иногда снизить нагрузку с 40ч. в неделю до произвольного меньшего значения. В идеале мог бы сформироваться качественный рынок предложения услуг по разработке, в том числе от индивидуалов. Сейчас же ситуация для индивидуалов, по сути, неконкурентоспособна по доходу в сравнении с постоянным наймом.
В общем — пусть Вкусвиль экспериментирует. У них задачи пока мелкие, поэтому обычный фриланс их тянет. Но вот подрастут (если сумеют, конечно), тогда объективно встанет задача координации усилий по разработке. Хотя может и не дорастут до такого размера, а потому ни на что на рынке не повлияют.
Хотя автор, похоже, по сути пиарит свою книжку про бирюзовое управление. Тогда вообще конструктивного диалога не выйдет — цели у него не соответствуют диалогу.
Тут дело не в методике дело, а в некомпетентности команды.
О да, в идеальном мире каждая команда тоже идеальна. Она умеет всё. Что такое атомное ядро и чем отличается химическая физика от физической химии — для правильной команды это детский лепет. Как нужно строить завод по обогащению урана? Да гавно вопрос — команда нагуглит и во всём разберётся. Потому что команда — ну просто супер, как раз из того мира, где розовые пони делают конфеты некоторым специфическим способом.
А теперь к реальности. Заевшихся от заказов команд в ней очень мало. Способных понять атомное ядро — ещё меньше (не нагуглить, а именно понять). Ну и фокус заевшихся и способных давно уже смещён в сторону «как мне нравится», а не «как на самом деле нужно заказчику». Поэтому если предложить им сделать атомную бомбу (вы вообще представляете весь необходимый объём работ?), то они упрутся в массу ограничений, о которых ранее даже понятия не имели, хотя и считали, что могут ну абсолютно всё. И вот эта супер-мега-айс-команда делает эпический фэйл. По скраму, разумеется. Ведь они же не какие-то там негры на галерах.
И разумеется, ребята всегда оправдаются (они же супер, не?). Обвинят во всём, понятно, заказчика. Свалят с проекта сразу, как только им скажут «ребята, у нас тут есть ограничения». Ну и распиарят свой «успешный опыт» примерно так — мы реально сделали бомбу! Но тупые заказчики, некомпетентные поставщики, и вообще всякая шваль под ногами… Ну вы поняли — виноваты все, кроме КОМАНДЫ.
Короче — ваш подход не для реального мира. Если вы входите в число заевшихся и лениво выбирающих себе заказ — ладно, вам простительно непонимание реальности (не до неё ведь). Если же нет, то уж сорри, но некомпетентны как раз вы. Других вариантов нет. Например, потому что вы не знаете, как сделать бомбу, даже если вам кажется, что вы всё знаете.
Ну а отдельные выполненные вами проекты, которыми все хвастаются как «успешными», всегда есть нечто несовершенное, весьма далёкое от идеала. Если кто-то знаком с таким явлением, то он не станет заявлять про ещё один проект (под названием «скрам») мол он успешнее всех успешных успехов, а потому всем нужно пилить только его, а кто не пилит — ну он просто некомпетентен.
Первые стори будут — «исследовать что такое 'всё'» и «что значит 'работает'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Оригинальный вариант интерпретации.
Аналогия — заказчик хочет атомную бомбу. Далее по вашему:
Первые стори будут — «исследовать что такое 'бомба'» и «что значит 'атомная'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Вы вчитайтесь в собственное понимание на показанном примере. Вчитались? Или пропустили текст и только ухмыляетесь? Вчитайтесь, очень полезно.
Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Об этом говорит заказчик. Он знает, что итерация равна неделе. Он хочет увидеть бомбу через неделю. Ну или что-то похожее на бомбу. И если мы ему покажем не бомбу, а, скажем, план завода по производству бомб, он нас спросит — а за что я вам плачу деньги? Где бомба? Потому что он знает, как контролировать сроки — время прошло, а понятного результата нет.
Вообще переводить на модные методики выжимания пота всё и вся — это маразм. Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов. И не важно, как они там себе всё обосновывают. Хоть деньгами, хоть причудами заказчика. Если инструмент не соответствует задаче — в топку такой инструмент. А если кто-то готов платить программистам за безумства — почему бы программистам не взять себе деньги и предоставить разумный по их мнению результат (хоть и безумный с точки зрения заказчика)? Почему вы все (фанаты модных потовыжималок) считаете, что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед? Но даже мозговеды не могут исправить пустоту, они только вид делают, что бы опять же денег срубить. А вы (фанаты моды) представляете себе мир с розовыми пони, которые ср*т исключительно шоколадом. И потому обвешиваете программистов задачами по исправлению пустых мозгов, параллельно с изучением атомного ядра и проектированием эффективного цикла производства ядерного оружия.
Маразм со стороны заказчиков поддерживается маразмом со стороны фанатов моды. В итоге получается маразм в квадрате. Но фанаты моды снова и снова поучают всех, мол вы не правильно наши модные штучки используете, а с заказчиком нужно дружить и стараться его удовлетворять. Да, даже если он хочет невозможного. Ведь он же вам денег даёт! Он святой, а вы обязаны его любить.
Но к счастью в мире есть более адекватные заказчики и фирмы по разработке софта. Поэтому лицам с пустыми головами оставляем задачу выживания в конкурентной среде за счёт повышенного расхода капитала.
Путано и бессистемно, но крайне безапелляционно, излагается точка зрения фаната «новых технологий».
Сначала научитесь простой модуляризации. И если научитесь — никаких проблем с выделением чего-то в отдельный сервис не возникнет. И так же не возникнет желание делать абсолютно всё в виде идиотских сервисов, содержащих в себе помимо логики ещё и веб-сервер, сервер очередей и т.д. и т.п. А так же запихивать это в эмулятор (ага, теперь уже вместе с JVM), накручивать на это миллион модных и бесполезных штучек, а потом хвастаться, что ваш недо-сервис запускается из одного exe файла, но не рассказывать, что весит он гигабайты и запускается часами. Потому что каждый такой сервис тянет свои сервера и прочее, а в сумме получаем те самые гигабайты и часы. Зато любителям писать каждый раз на новом языке — полная свобода.
Это обычный грипп. В том числе и по массовости заболевания.
За 4 месяца с начала «эпидемии» в очень оживлённом центре пересечения огромного количества людей — в Нью-Йорке — заразилось всего 20%. Всего переболеют процентов 25, может 30. И это в Нью-Йорке. А в остальной, гораздо более тихой Америке, переболеют процентов 10-15. Как и при любом сезонном гриппе.
Поэтому все страшилки на тему «от всех причин так не умирают» не учитывают простейший факт — зараза не охватывает 100% населения, как и любой сезонный грипп. Я уж не говорю про накрутку смертности на основе фиксации просто наличия заразы, а не выявления причины смерти. Ну а если я ещё возьмусь указывать на незнание математики некоторыми участниками, то меня моментально заминусуют до полного молчания.
В нашем случае поддержка нескольких версий от приложения требуется для возможности двигать версию приложения не меняя схему базы. Зачем двигать версию приложения? Для откатов. Почему не откатывать версию схемы? Потому что у новой схемы уже есть пользователи.
Я не исключаю логичности в ваших действиях, но всё же при смене версии приложения на мобильных устройствах вполне удавалось менять и схему данных. Откатывать же приложение назад не позволяет (по простому), например маркетплейс. Поэтому в итоге все пользователи когда-то обновляются и новая версия меняет схему БД до нужной именно ей. Проблемы возможны разве что с синхронизацией пользователей с разными схемами, но это довольно узкая тема, далеко не всем оно надо. Да и с сервером синхронизация разноверсионных клиентов относительно легко выполняется через диспетчерирующую прокладку.
Если же речь идёт о серверах в различных подразделениях, то обычно обкатывают новое на отдельных подразделениях (поэтапное внедрение, оно важно не только из-за софтовых косяков, но в первую очередь — из-за организационых), если там что-то идёт не так, тогда откатывают и версию БД и версию приложения. Скрипты для этого (в обе стороны) заранее готовят.
Поддержка каких-то промежуточных сочетаний «версия схемы»-«версия ПО» есть задача очень опасная из-за комбинаторного роста сложности. Не знаю, что такое openstack, но комбинаторику он не отменяет никак.
Ну и так, к слову — атомарный апгрейд, видимо, не атомарный, а разовый. Собственно свойство атомарности является обязательным для любого апгрейда вообще, поэтому акцентировать именно на атомарности — ни к чему.
До публикации нью-йоркского серологического исследования казалось, что появились шансы увидеть летальность порядка 0.2-0.3% (по предыдущим коряво задизайненным тестам, которые справедливо критиковались). Но теперь очевидно, что IFR будет выше 0.5% и, вполне возможно, выше 1%. Меньше 14% из 3,000 протестированных жителей Нью-Йорка имели антитела, а ведь почти 0.2% жителей уже умерли от/при COVID-19.
Автор откровенно подтасовывает цифры.
В статье по его же собственной ссылке сказано, что в городе Нью-Йорк (не путать со штатом Нью-Йорк) процент переболевших равен 21 с чем-то. Население там примерно 9 миллионов. Из этого имеем 1.89 миллиона переболевших. Заражённых (которых реально выявили, а не тех, кто бессимптомно гуляет) всего 150 тысяч. Смертность при наличии вируса в городе Нью-Йорк равна 11.5 тысяч. Сколько из них умерло именно от вируса — никто не знает. Но пусть даже все именно от вируса. Тогда делим 11.5+0.15 на 1890 и получаем не более 0.537%, в то время как автор пишет «будет выше 0.5% и, вполне возможно, выше 1%». Вот с чего он взял, что будет выше 1%? Ну просто захотел и написал для общей паники.
И про «коряво задизайненные тесты» — то же самое, берётся бульварная статейка и на основании проплаченных сомнений её автора делается вселенский вывод, мол ну автор статейки же сомневается, значит все тесты сделаны неправильно!
Я думаю, что с первых строк статьи становится ясно — автор фанат панических настроений, а потому обязан завышать значимость проблемы. Ну и завышает.
А между тем — 0.5% смертность (даже если все умерли именно от вируса), это обычный грипп. Вот этого одного факта достаточно, что бы уволить всех этих организаторов вселенского карантина. Но организаторы увольняться не спешат, а предпочитают создавать новостной фон, вселяющий панику и оправдывающий их халатные, а возможно и корыстные, действия.
Я работаю с java-программистом, который такой подход исповедует.
Вы подход-то не поняли, вот в чём проблема.
Статья на примерах для неких миддлов, то есть знакомых с базовыми принципами, терминологией и имеющим практический опыт людей, поясняет архитектурный принцип, который и на уровне сеньора многие не понимают. То есть недостаточно качественно подан материал. И вообще качественно его подать, это как книгу по высшей математике написать для школьников. Так обычно почти ни у кого не получается. Ну и у автора не получилось.
Автор довольно длинно, из-за желания всё разжевать миддлам (хотя он сам наверняка считает, что пишет для новичков, при этом сам весьма вероятно являясь не очень далёким от миддла разработчиком), наливает много воды, плюс использует лексикон не совсем из той оперы. Например просто глаз режет, когда он заявляет про «истины» которые по его мнению что-то там реализует. Нет на этом уровне никаких истин, есть только удачные или неудачные шаблоны, а новички же, купив рекламируемую книжку, будут считать это именно истиной, чем затуманят свой мозг и накапают на мозги другим разработчикам.
В общем я бы назвал подход «оптимальное использование сущностей». То есть не БД, как настаивает автор, а во первых — оптимальность, и во вторых — моделирование сущностей. И от такой постановки уже элементарно вытекает необходимость во многом отталкиваться от БД. Не от чего-то там наверченного непонятными генераторами, которые насочиняли непонятные лица, привыкшие использовать исключительно модные библиотеки и никогда не делать собственных велосипедов, а от понимания сути происходящего — нам нужна правильная модель и она должна использоваться оптимально, то есть эффективно лишь до той степени, пока эта программная эффективность не убивает эффективность процесса.
К сожалению, массовый рынок образовательных услуг, включая вот такие книжки, получает львиную долю прибыли от начинающих, слегка разбавленных миддлами. Поэтому рынок опускается до уровня молодёжи и выдаёт «священные писания» (вспомним всяких Фаулеров и прочих «святых») в которых сомневаться — страшный грех (ибо мало опыта у читателя, да и продажи ведь упадут!). Ну и далее находится бездна желающих получить гонорар за излияние своего (часто примитивного) видения вот в таком виде, который вроде бы должен объяснять глубины, но на самом деле из-за отсутствия опыта у читателя скорее уводит его от пути действительно истинного.
Поэтому ваш знакомый вами и воспринимается со словами типа «ужасно». Правда как уже отметили выше — это лишь ваше личное восприятие одного единственного случая, из чего вы делаете весьма далеко идущие (и неправильные) обобщения.
И кстати, по разным версиям БД. Вам зачем много версий? Отпускаем резвиться одну команду, которая куролесит свои изменения, внедряет их в отрыве от потребностей всей конторы, потом так же отпускаем другую команду, потом вообще все куролесят что захотят, но зато все героически отстаивают необходимость работы с БД разных версий. Примерно так у вас было? И я вам подскажу — потом каждый выберет свой язык программирования, любимую ОС, тучу вспомогательных инструментов, и всё это заставит изучать толпу тестировщиков, администраторов, технических писателей и прочая, и прочая, и прочая. Верной дорогой идёте, товарищи!
Вам потрепаться? Тогда я вас понимаю. Но если бы вам реально не нравилась нынешняя система, то вы бы все эти рассуждения давно бы прошли и поняли, почему они есть детская глупость.
Детская глупость, это когда ребёнок ничего не знает, но пыжится показать всем, что он очень умный. А когда ребёнка тыкают носом в его незнание, он обижается, плачет, ставит минусы и зовёт папика. Но без понимания своего незнания ребёнок не сможет учиться. Поэтому вам сначала нужно самому понять, что вы говорите ерунду.
Один маленький намёк — перечитайте три своих последних предложения. Они самым наглядным образом показывают не просто отсутствие знаний, но полное отсутствие желания интересоваться вопросом. Ребёнку с таким отношением к теме учиться категорически противопоказано — заплачет.
Посмотрите в лицо жене, матери, отцу. Это пример общества, в котором информацию трудно скрыть. Если вас смущает проблема масштабирования — вы не один такой, но это на самом деле ни разу не проблема. Просто о проблеме нужно думать конструктивно — как её устранить. Вы думали? Подозреваю — нет.
Ну и по данным, что бы два раз не вставать. Вы тоже не в курсе, что можно делать с данными (судя по другому вашему вопросу)? Я вас поздравляю — вы вошли в список потенциальных кандидатов в наше правительство. Там как раз все такие.
Но не буду вас более смущать. Данные нужны для принятия решений (хоть и секрет это для наших правителей). Так вот, если по немецким данным (которым, почему-то, больше веры) переболело 10% от всего населения, то для нашей страны имеем 14 миллионов. Логично? И если да, то от этих 14 миллионов мы должны иметь 1.4 миллиона трупов. Ведь именно цифрами в районе 10% нас пугают, правильно? Но здесь есть неувязочка — у нас за весь год от всех причин умирает заметно меньше. Поэтому такой всплеск был бы легко заметен не то что по убогим данным росстата, но просто по переполненности всех похоронных агентств в стране. Вы замечаете вокруг себя такую аномалию? А вот наше правительство как-то умудрилось её заметить. Я не знаю, что они там курят, но вот были бы в наличии точные данные, то можно было бы всю эту шпану поголовно отстранять от должности за несоответствие должностным обязанностям и, в следствии несоответствия, либо злого умысла, нанесение материального ущерба в особо крупных размерах (десятки процентов ВВП).
У вас (и ни у кого на свете) нет достоверных цифр по носителям и выздоровевшим. Поэтому «легко посчитать» относится скорее к фанатам самокарантина, а не к объективной реальности.
Но есть данные с большой погрешностью. В Германии 10% переболевших и 2% носителей, остальные — не болели и не болеют. У нас 5% переболевших. Сколько носителей и здоровых — никто не знает. Ну и все эти проценты указывают лишь на максимум плотности вероятности, а не на реальное значение, которое может отличаться от максимума плотности в разы.
При этом выявить достаточно точное распределение популяции на 3 группы элементарно — просто проведите вменяемое и массовое обследование (например — 1% от популяции). Просто отдать приказ. И всё. Но никто не хочет. С чего бы это?
Ответ двойной — приказывающие понятия не имеют, зачем это надо. А так же они понятия не имеют о том, как правильно проводить обследование. Но это часть ответа. Вторая часть — приказывающим просто не нужны реальные данные. Потому что цель другая.
Целенаправленные усилия СМИ именно на такой результат и заточены.
Ну а верующим всё равно не помочь — они будут прятаться в бункерах, надевать скафандры и обзывать всех неверующих конспирологами.
Лучше подумать о правильном обществе, где контролируемые обществом лаборатории проведут исчерпывающий анализ доступных данных, а если данные недоступны — общество предпримет усилия для их получения в максимально корректном виде. Это всё возможно. Это всё очень легко. Это всё безумно дёшево в сравнении с нынешним умопомрачением и разбазариванием триллионов баксов. Вот об этом нужно думать, а не о доказательстве верующим и их проповедникам очевидных истин. Фанатики непобедимы при помощи логики, а их поводыри в принципе не подвержены влиянию любых доводов, кроме личной выгоды. Не стоит тратить усилия на спор с ними.
Хотя нужно сказать, что автор несколько безалаберно показал в статье собранные им факты. Нужна логическая цепочка, отталкивающаяся от ссылок на официальные данные, а автор часто переходит на эмоции и теряет нить, возвращаясь позже к перечислению уже других фактов, забыв про начатую ранее цепочку. Судорожно мыслит, так сказать.
В целом модель ситуации простая — есть популяция, в ней есть переболевшие, болеющие и здоровые. СМИ пиарят исключительно умерших и «вновь заразившихся», то есть уводят от очень простой и наглядной картины с тремя группами — переболевшими, болеющими и здоровыми. Тесты выявляют носителей и поставляют данные для рекламы в СМИ, но какой-то систематической работы по разбиению популяции на указанные три группы почти не ведётся, а если ведётся — фрагментарно и нерепрезентативно. И как можно делать выводы о ситуации, когда нет самых примитивных данных для трёх групп? Всего три цифры. Доступно детям из детских садов. Но недоступно сотням влияющих на политику государств людям. Так может быть? Ну конечно — нет. Нас просто намеренно дурят. Хотя опять же — нас дурили всегда, так чему здесь удивляться?
Делать больше итераций — глобально ничего не мешает
Поэтому и нужно попробовать продвинуться подальше. Могут появится циклы, может начаться застой, может случится чудо и система станет вести себя непредсказуемо — интересно же понять, что будет.
В текущей модели есть фабрика, у которой есть какой-то капитал. Подразумевается, что он есть у владельца фабрики, конечно. Чем он отличается от буржуя в вашем смысле? Тем, что имеет возможность инвестировать в другие фабрики?
Фабрика имеет целью делать деньги, как и буржуй, но средства для этого выбраны такие, которые налагают ограничения на действия такого экономического субъекта. То есть фабрика не может купить конкурента, не может купить политика, хотя может быть стоит ей дать возможность купить СМИ. Разница в средстве производства. Для буржуя средство — деньги. Для фабрики — товары и их производство. Если совместить в одной сущности фабрику и буржуя, то надо как-то вводить возможность специализации, потому что модель поведения у них отличается. Хотя субъективность всё равно будет, поэтому можно и забить на различие. Но в реальности же не зря появились именно люди, делающие деньги из денег.
Прям компьютерную игру делать можно))
Да, стоит подумать на эту тему.
Когда-то давно была такая игра «Цивилизация». Так вот она примерно такой же принцип использовала. И получилось очень впечатляюще. Были всякие стратегии на тему строим город или ещё какую ерунду, но суть там точно такая же — есть модель и пользователь меняет её параметры, наращивая какие-то и уменьшая другие. Вот это всё отнюдь не умерло морально. Правда нужна красивая графика и тому подобное, но это всё уже понятно как делать.
А что если стимулировать качество? Некое государство, или что более вероятно — марсиане, выдают премию раз в несколько шагов за стратегию, постоянно преследующую цель повышения качества. Что будет в итоге?
Так же стоит подумать над размножением производителей. То есть в модели они умирают, но не рождаются. Почему? Нужно ввести некий коэффициент рождаемости и выводить на рынок «инкубаторские» стартапы со случайными параметрами. Раз в несколько шагов по одной штуке.
Но правильнее всего будет, если ввести в модель буржуев. Буржуй видит, что на рынке остался один победитель — буржуй вкладывается в него. Победитель в результате продаёт ещё больше, но часть капитала отдаёт обратно буржую. При этом победитель может перестать развиваться, поскольку все буржуи понесут деньги именно ему, поэтому кого считать победителем буржуй определяет с некоторой долей случайности — вводим коэффициент в рамках которого буржуй считает бизнесы успешными, а далее случайным образом вкладывается в одного из успешных. Здесь так же важно понимать — сколько у нас буржуев. Или же сколько раз может вложиться буржуй, если он в модели один. Видимо с этой стороны нужны ограничения по суммам на счёте буржуя. Ну и в целом приход-расход в экономике должен сходиться — если где-то чего-то присовокупилось, значит где-то чего-то обязательно убудет.
Модель спроса можно усовершенствовать так — вводим коэффициент ошибки, то есть покупатель определят качество товара с учётом этого коэффициента. Например — ошибка в пределах +-20% очень оживит действо.
Ну и далее нужно вводить продажные СМИ. СМИ — это тоже производитель. Но продаёт он товар только буржуям. Буржуй платит СМИ за стимулирование продаж тех предприятий, в которые он вложился. СМИ в результате с некоторой эффективностью (один коэффициент) смещают оценку качества целевых товаров на некоторое количество процентов (в рамках тех же +-20%). Выживают наиболее эффективно смещающие восприятие обществом качества товаров. Вложения в развитие производства СМИ приводит к увеличению процента в нужную сторону (опять же случайно, по модели вложений в обычное производство).
А далее уже вводится государство, в лице предприятий по навязыванию ограничений в интересах предложивших предприятиям-политикам наибольшую сумму буржуев. И вот тогда дивный новый мир засверкает всеми возможными красками. Особенно если государство сможет влиять абсолютно на все коэффициенты в модели. Иногда в минус для отдельного буржуя, но в среднем — в плюс. Буржуй с минусом вкладывается в политика-конкурента. Можно ещё модель субъективности в предпочтения буржуев заложить — не всегда давать деньги тому, кто помог с продажами, но иногда давать новичкам, что бы попробовать вырастить ещё лучшего фюрера.
Потом нужно организовать конкуренцию государств за деньги буржуев. Нищие государства не интересны буржуям, поэтому опять должен вырасти монополист в условном западном полушарии. Но среди политиков так же должны быть случайные отклонения, позволяющие иногда повышать конкурентоспособность государства и перераспределять доли в потоках денег от буржуев в свою пользу за счёт вложений «в долгую». Хотя таких в модели должно быть очень мало, ведь что это за политик, который не хочет много и прямо сейчас?
Ну и с параметрами модели типа кривой распределения дохода стоит поиграться. На сколько сильно будет влиять на ситуацию изменение коэффициента неравенства доходов на 10%? А на 100%?
Итераций нужно делать неограниченное количество. То есть до получения статики, либо обнаружения цикла. Что мешает долго итерировать? Запустить на ночь и пойти спать, как-то так.
В общем — занимательно, но реальность всё же моделирует всё гораздо точнее :)
1) На первом месте рынок. Если его нет — вы в заднице, а потому не суйтесь.
2) На втором месте продукт (при наличии рынка). Он должен соответствовать рынку.
3) Ну и в самом конце списка какие-то негры, которые делают то, что вы им приказываете, предварительно правильно выбрав рынок и к нему продукт.
От себя — объективно не вижу ценности команды. Если рынок и продукт выбраны правильно, то действительно нет проблем нанять кого угодно и спокойно заниматься децимацией тех из них, кто возжелал отклониться от линии на правильные продукт и рынок. При этом для оценки размера рынка или правильности продукта команда не нужна, для этого есть стандартные и не требующие особых профессионалов методики (анализы продаж конкурентов и всяческие опросы). Остальное — лишь наблюдение за отклонением продукта от требуемого рынком. Если отклоняется — неграм пинок. Ведь просто? Или я где-то ошибаюсь?
Не ковырял, но в Eclipse аналогичную задачу решает OSGI. Какой там принцип? Может его использовать?
Собственно тема зависимостей в модульности самое главное, поэтому интересно понимать причины отказа от показанных решений.
У методологии потенциально есть место под солнцем. Но широкое её распространение, как и существенный рост для любого стартапа, совершенно не гарантировано. Скорее очень вероятно, что всё так и останется в рамках одной компании и вы лишь получите интересный опыт, но не более.
Но может и удастся упаковать и продать методологию другим средним предприятиям. Тогда бы возможно стал возможен вариант «неполной ставки» для тех, кому время важнее денег. Этим подход интересен. Но дьявол, как известно, в деталях. Поэтому может получиться плохо. А может и хорошо. Я со стороны разработчиков голосую за «хорошо», но понимаю, что всё это лишь очередной стартап с непонятными перспективами.
При беге и креплении на руке 4g часто хватает, но если чуть сильнее рукой взмахнёшь — выходит за диапазон. 4g это +-2g, то есть 1g сразу вычитается с одной стороны, а с другой запас 3g остаётся. У вас тоже видно на графике (если 10000=1g), что амплитуда взмахов руками выйдет за предел, если ещё вычесть 1g земного притяжения.
Собственно и по такому акселерометру можно получить некоторую информацию, но это лишь общий вид, то есть можно отличить бег от ходьбы или от взмахов палками, но не более. Для большего нужно получать скорости и перемещения по трём осям. Даже ходьбу от медленного бега можно не отличить. Вот поэтому я и говорю про необходимость расширить диапазон до 8g (будет +-4g) и повысить точность. Если ваши показания проинтегрировать, то через пару секунд вы по таким данным уже в космос полетите (положение будет «над землёй в 1-м метре»), а на самом деле всё так же бежите.
Я пытался по данным с часов бег измерять — даже сам бег и то сложно выделить. Поднимаюсь по лестнице — как будто бег получается, ну и тому подобное. Что бы отличить нужно считать положение, и считать достаточно точно. Если есть подъём на метр, значит это именно лестница, а не кривые показания — как-то так.
Хотя может вы встречались с приличными гироскопами? Максимальные ограничения — от 8g, точность — миллиметры/с^2 или лучше.
Теоретически им вряд ли было бы выгоднее нанимать админа и отдельно почасового разработчика. Админ бы не сильно меньше получал, но зато никаких гарантий от чужого разраба. А свой всё же был всегда под рукой, пока простаивал — з/п за админство начислялась (ну или оправдывалась в глазах директора).
Вообще если контора не очень большая (сотня-две человек), то тесные отношения с разработчиком полезны. Хотя разумеется, сначала нужно найти подходящего.
Ну а в больших конторах, или даже в средних, но которым нужно что-то приличное по размеру разрабатывать, стоимость потерь из-за отсутствия координации резко нарастает. Даже в сетях ERP на всю контору с учётом массы деталей очень даже требует координации. Если это покупной продукт, то координация по внедрению и настройке. Если кастом — тут вообще много задач, которые можно было бы сделать один раз, вместо десятков для каждого фрилансера.
В общем я за координацию. Может даже её можно вынести на почасовую оплату, типа один архитектор мониторит несколько заказчиков. Но всё равно без неё потери будут значительные.
Но с другой стороны — есть в бюджете строчка «расходы на ИТ» и ею начальство довольно — вот и нет нужды что-то координировать. Если у вас так, то это ни чем не обоснованный подход, кроме как экономией времени и нервов того, кто строчки в бюджете оценивает.
Но некоторое совмещение в виде «постоянной» и «переменной» частей команды было бы интересно, в том числе разработчикам, которые хотели бы иногда снизить нагрузку с 40ч. в неделю до произвольного меньшего значения. В идеале мог бы сформироваться качественный рынок предложения услуг по разработке, в том числе от индивидуалов. Сейчас же ситуация для индивидуалов, по сути, неконкурентоспособна по доходу в сравнении с постоянным наймом.
В общем — пусть Вкусвиль экспериментирует. У них задачи пока мелкие, поэтому обычный фриланс их тянет. Но вот подрастут (если сумеют, конечно), тогда объективно встанет задача координации усилий по разработке. Хотя может и не дорастут до такого размера, а потому ни на что на рынке не повлияют.
Хотя автор, похоже, по сути пиарит свою книжку про бирюзовое управление. Тогда вообще конструктивного диалога не выйдет — цели у него не соответствуют диалогу.
О да, в идеальном мире каждая команда тоже идеальна. Она умеет всё. Что такое атомное ядро и чем отличается химическая физика от физической химии — для правильной команды это детский лепет. Как нужно строить завод по обогащению урана? Да гавно вопрос — команда нагуглит и во всём разберётся. Потому что команда — ну просто супер, как раз из того мира, где розовые пони делают конфеты некоторым специфическим способом.
А теперь к реальности. Заевшихся от заказов команд в ней очень мало. Способных понять атомное ядро — ещё меньше (не нагуглить, а именно понять). Ну и фокус заевшихся и способных давно уже смещён в сторону «как мне нравится», а не «как на самом деле нужно заказчику». Поэтому если предложить им сделать атомную бомбу (вы вообще представляете весь необходимый объём работ?), то они упрутся в массу ограничений, о которых ранее даже понятия не имели, хотя и считали, что могут ну абсолютно всё. И вот эта супер-мега-айс-команда делает эпический фэйл. По скраму, разумеется. Ведь они же не какие-то там негры на галерах.
И разумеется, ребята всегда оправдаются (они же супер, не?). Обвинят во всём, понятно, заказчика. Свалят с проекта сразу, как только им скажут «ребята, у нас тут есть ограничения». Ну и распиарят свой «успешный опыт» примерно так — мы реально сделали бомбу! Но тупые заказчики, некомпетентные поставщики, и вообще всякая шваль под ногами… Ну вы поняли — виноваты все, кроме КОМАНДЫ.
Короче — ваш подход не для реального мира. Если вы входите в число заевшихся и лениво выбирающих себе заказ — ладно, вам простительно непонимание реальности (не до неё ведь). Если же нет, то уж сорри, но некомпетентны как раз вы. Других вариантов нет. Например, потому что вы не знаете, как сделать бомбу, даже если вам кажется, что вы всё знаете.
Ну а отдельные выполненные вами проекты, которыми все хвастаются как «успешными», всегда есть нечто несовершенное, весьма далёкое от идеала. Если кто-то знаком с таким явлением, то он не станет заявлять про ещё один проект (под названием «скрам») мол он успешнее всех успешных успехов, а потому всем нужно пилить только его, а кто не пилит — ну он просто некомпетентен.
Оригинальный вариант интерпретации.
Аналогия — заказчик хочет атомную бомбу. Далее по вашему:
Первые стори будут — «исследовать что такое 'бомба'» и «что значит 'атомная'». По результатам исследования ставятся задачи на бизнес-анализ, архитектуру, дальнейшие исследования… Инкрементом бизнес-ценности в этом случае будет повышение компетенции команды в домене, создание проектной документации. Кто вам сказал, что инкрементом обязан быть сайт с кнопочкой?
Вы вчитайтесь в собственное понимание на показанном примере. Вчитались? Или пропустили текст и только ухмыляетесь? Вчитайтесь, очень полезно.
Об этом говорит заказчик. Он знает, что итерация равна неделе. Он хочет увидеть бомбу через неделю. Ну или что-то похожее на бомбу. И если мы ему покажем не бомбу, а, скажем, план завода по производству бомб, он нас спросит — а за что я вам плачу деньги? Где бомба? Потому что он знает, как контролировать сроки — время прошло, а понятного результата нет.
Вообще переводить на модные методики выжимания пота всё и вся — это маразм. Этот маразм исходит не от программистов, а от тех, кто принимает решения о загрузке программистов. И не важно, как они там себе всё обосновывают. Хоть деньгами, хоть причудами заказчика. Если инструмент не соответствует задаче — в топку такой инструмент. А если кто-то готов платить программистам за безумства — почему бы программистам не взять себе деньги и предоставить разумный по их мнению результат (хоть и безумный с точки зрения заказчика)? Почему вы все (фанаты модных потовыжималок) считаете, что программист обязан исправить пустоту в головах, сначала, своих работодателей, а потом ещё и в башке абсолютно тупого заказчика? Он программист или мозговед? Но даже мозговеды не могут исправить пустоту, они только вид делают, что бы опять же денег срубить. А вы (фанаты моды) представляете себе мир с розовыми пони, которые ср*т исключительно шоколадом. И потому обвешиваете программистов задачами по исправлению пустых мозгов, параллельно с изучением атомного ядра и проектированием эффективного цикла производства ядерного оружия.
Маразм со стороны заказчиков поддерживается маразмом со стороны фанатов моды. В итоге получается маразм в квадрате. Но фанаты моды снова и снова поучают всех, мол вы не правильно наши модные штучки используете, а с заказчиком нужно дружить и стараться его удовлетворять. Да, даже если он хочет невозможного. Ведь он же вам денег даёт! Он святой, а вы обязаны его любить.
Но к счастью в мире есть более адекватные заказчики и фирмы по разработке софта. Поэтому лицам с пустыми головами оставляем задачу выживания в конкурентной среде за счёт повышенного расхода капитала.
Вот и весь посыл статьи.
Путано и бессистемно, но крайне безапелляционно, излагается точка зрения фаната «новых технологий».
Сначала научитесь простой модуляризации. И если научитесь — никаких проблем с выделением чего-то в отдельный сервис не возникнет. И так же не возникнет желание делать абсолютно всё в виде идиотских сервисов, содержащих в себе помимо логики ещё и веб-сервер, сервер очередей и т.д. и т.п. А так же запихивать это в эмулятор (ага, теперь уже вместе с JVM), накручивать на это миллион модных и бесполезных штучек, а потом хвастаться, что ваш недо-сервис запускается из одного exe файла, но не рассказывать, что весит он гигабайты и запускается часами. Потому что каждый такой сервис тянет свои сервера и прочее, а в сумме получаем те самые гигабайты и часы. Зато любителям писать каждый раз на новом языке — полная свобода.
За 4 месяца с начала «эпидемии» в очень оживлённом центре пересечения огромного количества людей — в Нью-Йорке — заразилось всего 20%. Всего переболеют процентов 25, может 30. И это в Нью-Йорке. А в остальной, гораздо более тихой Америке, переболеют процентов 10-15. Как и при любом сезонном гриппе.
Поэтому все страшилки на тему «от всех причин так не умирают» не учитывают простейший факт — зараза не охватывает 100% населения, как и любой сезонный грипп. Я уж не говорю про накрутку смертности на основе фиксации просто наличия заразы, а не выявления причины смерти. Ну а если я ещё возьмусь указывать на незнание математики некоторыми участниками, то меня моментально заминусуют до полного молчания.
Ну вы что, я лишь прокомментировал :)
Я не исключаю логичности в ваших действиях, но всё же при смене версии приложения на мобильных устройствах вполне удавалось менять и схему данных. Откатывать же приложение назад не позволяет (по простому), например маркетплейс. Поэтому в итоге все пользователи когда-то обновляются и новая версия меняет схему БД до нужной именно ей. Проблемы возможны разве что с синхронизацией пользователей с разными схемами, но это довольно узкая тема, далеко не всем оно надо. Да и с сервером синхронизация разноверсионных клиентов относительно легко выполняется через диспетчерирующую прокладку.
Если же речь идёт о серверах в различных подразделениях, то обычно обкатывают новое на отдельных подразделениях (поэтапное внедрение, оно важно не только из-за софтовых косяков, но в первую очередь — из-за организационых), если там что-то идёт не так, тогда откатывают и версию БД и версию приложения. Скрипты для этого (в обе стороны) заранее готовят.
Поддержка каких-то промежуточных сочетаний «версия схемы»-«версия ПО» есть задача очень опасная из-за комбинаторного роста сложности. Не знаю, что такое openstack, но комбинаторику он не отменяет никак.
Ну и так, к слову — атомарный апгрейд, видимо, не атомарный, а разовый. Собственно свойство атомарности является обязательным для любого апгрейда вообще, поэтому акцентировать именно на атомарности — ни к чему.
Автор откровенно подтасовывает цифры.
В статье по его же собственной ссылке сказано, что в городе Нью-Йорк (не путать со штатом Нью-Йорк) процент переболевших равен 21 с чем-то. Население там примерно 9 миллионов. Из этого имеем 1.89 миллиона переболевших. Заражённых (которых реально выявили, а не тех, кто бессимптомно гуляет) всего 150 тысяч. Смертность при наличии вируса в городе Нью-Йорк равна 11.5 тысяч. Сколько из них умерло именно от вируса — никто не знает. Но пусть даже все именно от вируса. Тогда делим 11.5+0.15 на 1890 и получаем не более 0.537%, в то время как автор пишет «будет выше 0.5% и, вполне возможно, выше 1%». Вот с чего он взял, что будет выше 1%? Ну просто захотел и написал для общей паники.
И про «коряво задизайненные тесты» — то же самое, берётся бульварная статейка и на основании проплаченных сомнений её автора делается вселенский вывод, мол ну автор статейки же сомневается, значит все тесты сделаны неправильно!
Я думаю, что с первых строк статьи становится ясно — автор фанат панических настроений, а потому обязан завышать значимость проблемы. Ну и завышает.
А между тем — 0.5% смертность (даже если все умерли именно от вируса), это обычный грипп. Вот этого одного факта достаточно, что бы уволить всех этих организаторов вселенского карантина. Но организаторы увольняться не спешат, а предпочитают создавать новостной фон, вселяющий панику и оправдывающий их халатные, а возможно и корыстные, действия.
Вы подход-то не поняли, вот в чём проблема.
Статья на примерах для неких миддлов, то есть знакомых с базовыми принципами, терминологией и имеющим практический опыт людей, поясняет архитектурный принцип, который и на уровне сеньора многие не понимают. То есть недостаточно качественно подан материал. И вообще качественно его подать, это как книгу по высшей математике написать для школьников. Так обычно почти ни у кого не получается. Ну и у автора не получилось.
Автор довольно длинно, из-за желания всё разжевать миддлам (хотя он сам наверняка считает, что пишет для новичков, при этом сам весьма вероятно являясь не очень далёким от миддла разработчиком), наливает много воды, плюс использует лексикон не совсем из той оперы. Например просто глаз режет, когда он заявляет про «истины» которые по его мнению что-то там реализует. Нет на этом уровне никаких истин, есть только удачные или неудачные шаблоны, а новички же, купив рекламируемую книжку, будут считать это именно истиной, чем затуманят свой мозг и накапают на мозги другим разработчикам.
В общем я бы назвал подход «оптимальное использование сущностей». То есть не БД, как настаивает автор, а во первых — оптимальность, и во вторых — моделирование сущностей. И от такой постановки уже элементарно вытекает необходимость во многом отталкиваться от БД. Не от чего-то там наверченного непонятными генераторами, которые насочиняли непонятные лица, привыкшие использовать исключительно модные библиотеки и никогда не делать собственных велосипедов, а от понимания сути происходящего — нам нужна правильная модель и она должна использоваться оптимально, то есть эффективно лишь до той степени, пока эта программная эффективность не убивает эффективность процесса.
К сожалению, массовый рынок образовательных услуг, включая вот такие книжки, получает львиную долю прибыли от начинающих, слегка разбавленных миддлами. Поэтому рынок опускается до уровня молодёжи и выдаёт «священные писания» (вспомним всяких Фаулеров и прочих «святых») в которых сомневаться — страшный грех (ибо мало опыта у читателя, да и продажи ведь упадут!). Ну и далее находится бездна желающих получить гонорар за излияние своего (часто примитивного) видения вот в таком виде, который вроде бы должен объяснять глубины, но на самом деле из-за отсутствия опыта у читателя скорее уводит его от пути действительно истинного.
Поэтому ваш знакомый вами и воспринимается со словами типа «ужасно». Правда как уже отметили выше — это лишь ваше личное восприятие одного единственного случая, из чего вы делаете весьма далеко идущие (и неправильные) обобщения.
И кстати, по разным версиям БД. Вам зачем много версий? Отпускаем резвиться одну команду, которая куролесит свои изменения, внедряет их в отрыве от потребностей всей конторы, потом так же отпускаем другую команду, потом вообще все куролесят что захотят, но зато все героически отстаивают необходимость работы с БД разных версий. Примерно так у вас было? И я вам подскажу — потом каждый выберет свой язык программирования, любимую ОС, тучу вспомогательных инструментов, и всё это заставит изучать толпу тестировщиков, администраторов, технических писателей и прочая, и прочая, и прочая. Верной дорогой идёте, товарищи!
Детская глупость, это когда ребёнок ничего не знает, но пыжится показать всем, что он очень умный. А когда ребёнка тыкают носом в его незнание, он обижается, плачет, ставит минусы и зовёт папика. Но без понимания своего незнания ребёнок не сможет учиться. Поэтому вам сначала нужно самому понять, что вы говорите ерунду.
Один маленький намёк — перечитайте три своих последних предложения. Они самым наглядным образом показывают не просто отсутствие знаний, но полное отсутствие желания интересоваться вопросом. Ребёнку с таким отношением к теме учиться категорически противопоказано — заплачет.
Ну и по данным, что бы два раз не вставать. Вы тоже не в курсе, что можно делать с данными (судя по другому вашему вопросу)? Я вас поздравляю — вы вошли в список потенциальных кандидатов в наше правительство. Там как раз все такие.
Но не буду вас более смущать. Данные нужны для принятия решений (хоть и секрет это для наших правителей). Так вот, если по немецким данным (которым, почему-то, больше веры) переболело 10% от всего населения, то для нашей страны имеем 14 миллионов. Логично? И если да, то от этих 14 миллионов мы должны иметь 1.4 миллиона трупов. Ведь именно цифрами в районе 10% нас пугают, правильно? Но здесь есть неувязочка — у нас за весь год от всех причин умирает заметно меньше. Поэтому такой всплеск был бы легко заметен не то что по убогим данным росстата, но просто по переполненности всех похоронных агентств в стране. Вы замечаете вокруг себя такую аномалию? А вот наше правительство как-то умудрилось её заметить. Я не знаю, что они там курят, но вот были бы в наличии точные данные, то можно было бы всю эту шпану поголовно отстранять от должности за несоответствие должностным обязанностям и, в следствии несоответствия, либо злого умысла, нанесение материального ущерба в особо крупных размерах (десятки процентов ВВП).
Но есть данные с большой погрешностью. В Германии 10% переболевших и 2% носителей, остальные — не болели и не болеют. У нас 5% переболевших. Сколько носителей и здоровых — никто не знает. Ну и все эти проценты указывают лишь на максимум плотности вероятности, а не на реальное значение, которое может отличаться от максимума плотности в разы.
При этом выявить достаточно точное распределение популяции на 3 группы элементарно — просто проведите вменяемое и массовое обследование (например — 1% от популяции). Просто отдать приказ. И всё. Но никто не хочет. С чего бы это?
Ответ двойной — приказывающие понятия не имеют, зачем это надо. А так же они понятия не имеют о том, как правильно проводить обследование. Но это часть ответа. Вторая часть — приказывающим просто не нужны реальные данные. Потому что цель другая.
Да не мир сошёл, это его «сошли».
Целенаправленные усилия СМИ именно на такой результат и заточены.
Ну а верующим всё равно не помочь — они будут прятаться в бункерах, надевать скафандры и обзывать всех неверующих конспирологами.
Лучше подумать о правильном обществе, где контролируемые обществом лаборатории проведут исчерпывающий анализ доступных данных, а если данные недоступны — общество предпримет усилия для их получения в максимально корректном виде. Это всё возможно. Это всё очень легко. Это всё безумно дёшево в сравнении с нынешним умопомрачением и разбазариванием триллионов баксов. Вот об этом нужно думать, а не о доказательстве верующим и их проповедникам очевидных истин. Фанатики непобедимы при помощи логики, а их поводыри в принципе не подвержены влиянию любых доводов, кроме личной выгоды. Не стоит тратить усилия на спор с ними.
Хотя нужно сказать, что автор несколько безалаберно показал в статье собранные им факты. Нужна логическая цепочка, отталкивающаяся от ссылок на официальные данные, а автор часто переходит на эмоции и теряет нить, возвращаясь позже к перечислению уже других фактов, забыв про начатую ранее цепочку. Судорожно мыслит, так сказать.
В целом модель ситуации простая — есть популяция, в ней есть переболевшие, болеющие и здоровые. СМИ пиарят исключительно умерших и «вновь заразившихся», то есть уводят от очень простой и наглядной картины с тремя группами — переболевшими, болеющими и здоровыми. Тесты выявляют носителей и поставляют данные для рекламы в СМИ, но какой-то систематической работы по разбиению популяции на указанные три группы почти не ведётся, а если ведётся — фрагментарно и нерепрезентативно. И как можно делать выводы о ситуации, когда нет самых примитивных данных для трёх групп? Всего три цифры. Доступно детям из детских садов. Но недоступно сотням влияющих на политику государств людям. Так может быть? Ну конечно — нет. Нас просто намеренно дурят. Хотя опять же — нас дурили всегда, так чему здесь удивляться?
Поэтому и нужно попробовать продвинуться подальше. Могут появится циклы, может начаться застой, может случится чудо и система станет вести себя непредсказуемо — интересно же понять, что будет.
Фабрика имеет целью делать деньги, как и буржуй, но средства для этого выбраны такие, которые налагают ограничения на действия такого экономического субъекта. То есть фабрика не может купить конкурента, не может купить политика, хотя может быть стоит ей дать возможность купить СМИ. Разница в средстве производства. Для буржуя средство — деньги. Для фабрики — товары и их производство. Если совместить в одной сущности фабрику и буржуя, то надо как-то вводить возможность специализации, потому что модель поведения у них отличается. Хотя субъективность всё равно будет, поэтому можно и забить на различие. Но в реальности же не зря появились именно люди, делающие деньги из денег.
Да, стоит подумать на эту тему.
Когда-то давно была такая игра «Цивилизация». Так вот она примерно такой же принцип использовала. И получилось очень впечатляюще. Были всякие стратегии на тему строим город или ещё какую ерунду, но суть там точно такая же — есть модель и пользователь меняет её параметры, наращивая какие-то и уменьшая другие. Вот это всё отнюдь не умерло морально. Правда нужна красивая графика и тому подобное, но это всё уже понятно как делать.
Так же стоит подумать над размножением производителей. То есть в модели они умирают, но не рождаются. Почему? Нужно ввести некий коэффициент рождаемости и выводить на рынок «инкубаторские» стартапы со случайными параметрами. Раз в несколько шагов по одной штуке.
Но правильнее всего будет, если ввести в модель буржуев. Буржуй видит, что на рынке остался один победитель — буржуй вкладывается в него. Победитель в результате продаёт ещё больше, но часть капитала отдаёт обратно буржую. При этом победитель может перестать развиваться, поскольку все буржуи понесут деньги именно ему, поэтому кого считать победителем буржуй определяет с некоторой долей случайности — вводим коэффициент в рамках которого буржуй считает бизнесы успешными, а далее случайным образом вкладывается в одного из успешных. Здесь так же важно понимать — сколько у нас буржуев. Или же сколько раз может вложиться буржуй, если он в модели один. Видимо с этой стороны нужны ограничения по суммам на счёте буржуя. Ну и в целом приход-расход в экономике должен сходиться — если где-то чего-то присовокупилось, значит где-то чего-то обязательно убудет.
Модель спроса можно усовершенствовать так — вводим коэффициент ошибки, то есть покупатель определят качество товара с учётом этого коэффициента. Например — ошибка в пределах +-20% очень оживит действо.
Ну и далее нужно вводить продажные СМИ. СМИ — это тоже производитель. Но продаёт он товар только буржуям. Буржуй платит СМИ за стимулирование продаж тех предприятий, в которые он вложился. СМИ в результате с некоторой эффективностью (один коэффициент) смещают оценку качества целевых товаров на некоторое количество процентов (в рамках тех же +-20%). Выживают наиболее эффективно смещающие восприятие обществом качества товаров. Вложения в развитие производства СМИ приводит к увеличению процента в нужную сторону (опять же случайно, по модели вложений в обычное производство).
А далее уже вводится государство, в лице предприятий по навязыванию ограничений в интересах предложивших предприятиям-политикам наибольшую сумму буржуев. И вот тогда дивный новый мир засверкает всеми возможными красками. Особенно если государство сможет влиять абсолютно на все коэффициенты в модели. Иногда в минус для отдельного буржуя, но в среднем — в плюс. Буржуй с минусом вкладывается в политика-конкурента. Можно ещё модель субъективности в предпочтения буржуев заложить — не всегда давать деньги тому, кто помог с продажами, но иногда давать новичкам, что бы попробовать вырастить ещё лучшего фюрера.
Потом нужно организовать конкуренцию государств за деньги буржуев. Нищие государства не интересны буржуям, поэтому опять должен вырасти монополист в условном западном полушарии. Но среди политиков так же должны быть случайные отклонения, позволяющие иногда повышать конкурентоспособность государства и перераспределять доли в потоках денег от буржуев в свою пользу за счёт вложений «в долгую». Хотя таких в модели должно быть очень мало, ведь что это за политик, который не хочет много и прямо сейчас?
Ну и с параметрами модели типа кривой распределения дохода стоит поиграться. На сколько сильно будет влиять на ситуацию изменение коэффициента неравенства доходов на 10%? А на 100%?
Итераций нужно делать неограниченное количество. То есть до получения статики, либо обнаружения цикла. Что мешает долго итерировать? Запустить на ночь и пойти спать, как-то так.
В общем — занимательно, но реальность всё же моделирует всё гораздо точнее :)