Так-то по вашей аналогии с доп руками можно набирать тучу джунов, когда на проекте полный разброд и одна нянька (если повезет) - тогда получаем, что со временем на этих джунах уже и проект держится, и CI поднимается, и ТП выстроена, и мониторинги с алертами и т.п. Главное чтобы по той же вашей аналогии, эти джуны никуда не могли/не хотели уйти с этого проекта, тогда все будет тоже в шоколаде)
Красиво конечно, но сколько раз ни думал о возможности взаимодействия реального мира и цифрового мира блокчейнов, всегда возникала проблема в том, что всегда могут появиться обстоятельства во внешнем мире, которые приведут к манипулированию данными или например одна из сторон/систем просто перестанет быть участником по различным причинам и тогда блокчейн ничего даст и более того тот же контракт зависнет в неопределенном статусе - собственно это проблема номер два в вашем списке. Самая банальная ситуация, которую надо бы решить для начала: в цепочке поставщиков появляется фальсификатор данных или сговор нескольких участников, которые отправляют в блокчейн данные, которые от них ожидают, но в реальности что-то делается с товаром. В результате следущий в цепочке получает меньше/поврежденный/другой товар, но в блокчейне же посредник зафиксировал, что все было ок - и кто виноват? А если это именно потребитель решил вывести конкурента поставщика из дела, т.к. у него на примете есть знакомый поставщик и стоит цель в дикредитации? А что если это просто датчики сбойнули и посредник просто не мог получить реальные данные и тогда он добросовестный, а должен отвечать поставщик датчиков? И тут мы возвращаемся в наш реальный мир договоров и судов, в котором данные из блокчейна наверняка будут признаны ничтожными. Единственный вариант, который вижу - присутвие контролеров на каждом точке обмена от каждого участника для подтверждения с занесением и подтверждением данных в блокчейн, тогда это будет работать, т.к. будут отвественные. Правда тогда с выстраиванием всего этого процесса сам блокчейн фактически будет общей распределенной БД по поставкам и смартконтракты на нем будут только в роли фиксаторов событий, но никак не контролирующим и принимающим решения участником процесса, как это обычно преподносится.
В эпоху современных приложений, сжирающих любые ресурсы что у пользователя что на серверах, разработка под блокчейны, как и под микроконтроллеры и другие специфические железные темы, требует именно программирования с придумыванием способов решения бизнес задач в условиях крайне ограниченных ресурсов - это стоит воспринимать как хорошую практику для мозга и кому-то действительно именно это интересно. Так что блокчейн не плох - он просто не про "наляпать лишь бы что за пару сторипоинтов", хотя и такое вцелом возможно. А использовать или нет - дело каждого, и на всякий случай напомню, что блокчейн != крипта и стоит относиться к этому прежде всего как к технологии раз уж мы на ИТ-ресурсе.
@BoomburumА были ли идеи для минусов в карму добавить необходимость вводить причну? Например, стандартный список чекбоксов со стандартными причинами +другое с полем для коммента. И пользователю выводить сводку, чтобы он понимал за что его минусуют. Аналогично можно для плюсов ввести - для тех, кто хочет понимать что именно он делает хорошо это будет хорошим подспорьем в мотивации. Ну и если уж идти совсем упарываться - и на статьи и на комменты тоже подобное навесить) Но тут можно ухудшить UX и отпугнуть людей лишний раз оценивать
Первых двух ограничений в монге уже давно нет, аналог JOIN - $lookup, который также позволяет наложить доп условия на связывание и с доп обработкой.
Легкость в горизонтальном масштабировании есть в части увеличения нагрузки на чтение за счет простой репликации, но в части шардинга и увеличения нагрузки по записи и просто расширения объемов хранения имеет свои подводные камни и это должно быть продумано на этапе проектирования БД и написании кода, либо потом это будет не легко и не быстро.
И надо очень осторожно относиться к поддержке текстового поиска, в стандартной монге он есть, но только по морфологии, фултекста нет, подобрать похожее слово при наличии опечаток (fuzzy) тоже не получится, поиска по части слова нет и зачастую текстовый поиск сводится к регуляркам, что очень не быстро на больших объемах. Но все эти фичи имеются в облачном MongoDB Atlas Search
В общем опыт работы с монгой говорит о том, что сначала делается хоть как-то работающий прототип, он доживает до проявления болячек отсутствия проектирования и наработки компетенций по работе с монгой. После чего все старое выкидывается и проектируется структура БД и инфраструктура уже с учетом реальных потребностей проекта с использованием всех плюшек монги или понимания того, что монга не подходит/недостаточно и надо ставить что-то рядом под спец задачи.
И докучи отделять группу «просмотренные сегодня» и сводить в табличку с основными параметрами, чтобы выбрать из имеющегося в текущем магазине из того что есть на полках самое подходящее
В 4 пункте ошибка, у вас вызов Array.prototype.include происходит внутри цикла, а значит там будет O(N*(N-1)) ~ O(N^2). Улучшение ничем не лучше первого варианта с полным перебором, но при этом добавили кучу доступов к памяти
А где кофиг железа? 60Мб/с это примерно половина гигабитной сетки, т.е. как раз для репликафатор 2, так что получилось отличное тестирование сети, жаль что мы не узнаем о том, во что уперлась кафка.
Не знаю каким образом можно тестировать многопоточку на двухядерке и как на видео отработали тесты, но второй способ с park не работает.
Во-первых если его просто запустить, то он загоняет оба потока в park в среднем на 15 тысячах итераций на 8 ядерном камне.
Во-вторый есть критичные действия, которые не находятся в критичной секции, в результате очень легко первый поток сетит мессадж, он рапарковывает второй поток, и убегает в первую секцию, но останавливается перед parkedThread.set. Второй поток начинает движение во вторую секцию, доходит до распарковывания первого потока, но он не видит в parkedThread ничего и тут же убегает в первую ветку ифа, где уже оба потока доходят до парковки без проблем и лочатся навсегда.
И да для многопоточки все-таки нужно подтверждать корректность своих реализаций чем-нибудь наподобие jcstress
Я конечно изначально предполагал, что пересекаются именно в центре вращения. Однако пока идет дискуссия, то уже начинаю думать, что сейчас они точно не имеют общей точки, точнее когда-то давно — скорее всего это была и точка. но скорее всего они образуют нечто вроде сферы, состоящей из множества точек образованныйх пересечейниями вот таких «разъехавшихся плоскостей». Нарисовал примерно что понимаю под «разъехавшихся». Надеюсь понятно.
Опять же скорее всего это уже не правилньая сфера, а просто какая-то трехмерная поверхность.
Если я с правильно понял про вектора угловых скоростей (хотя до конца так и не понял что имелось ввиду), то в этом то и фишка, что сейчас уже нет явных закономерностей по общему распределнию векторов вращения. Они находятся в пространстве, а не на плоскости, даже толстой. А мы лишь на основании статистики смогли бы вычислить преобладание определенных градиентов от некторого мифического центра.
Плоскости — это лишь упрощение представления, и опять же если что-то вокруг чего-то вращается, то это вращение происходит на плоскости (для упрощения убираем отсюда всякие внешние явления заставляющие уходить из этой самой плоскости). Я сознательно упрощаю кучу всего, т.к. и сам не знаю всех тонкостей, как раз и прошу указывать на то что важно, но я упускаю из вида.
Пока же я не вижу ни одной проблемы в абстрагировании от рассмотрения всей кучи событий и сосредоточиться лишь на конкретной плоскости, а дальше просто экстраполировать рассуждения на все возможные плоскости, образующие весь объем нашего пространства.
Спасибо за комментарий, нужно будет разобраться в терминах, которые вы привели, может переосмыслю свое видение.
К первому замечанию скажу, что мы не знаем какие красные смещения в других точках за пределами хотя бы нашей Солнечной системы, не говоря о других галактиках, так что вопрос про отсутствие инвариантов крайне спорный. Тут необходимо предложить способ однозначно разрешаеющий его. Так что очень уместно считать, что данные варианты как минимум равносильны. Пока же я считаю, что относительное расстояние между любыми точками, разлетающихся с вращающегося диска увеличивается и это относится к любой точке данного диска, а значит мы можем себя ставить в люое место во Вселенной и наблюдать то же, что и сейчас.
Ко второму замечанию скажу, что вы как и многие другие не можете представить, что вращение может идти не в одной плоскости. Я предполагаю, что нет необходимости связывать себя рамками какой-то одной плоскости, да при размерах наблюдаемых спиральных галлактик видна именно конкретная плоскость, однако она же не нулевой толщины, а вполне себе имеет «толщину». Так вы же не будете отрицать, что если мы возьмем звезду из такой галактики, максимально удаленную усредненной плоскости вращения, то она так же вращается вокруг центра галактики. Получается ее плоскость вращения досточно сильно отличается от усредненной, и нам ничего не мешает представить, что на множестве галлактик происходит нечто подобное, но там разброс пошел такой, что такие «максимально выбивающиеся» галактики заполнили шар, а не диск, но при этом продолжают вращаться относительно центра. Первопричина наверняка в Большом взрыве, разбросавшем материю во все стороны.
Если что то я попытался описать вариант, когда все просто разлетается от мнимого центра при константной бесконечной Вселенной. У меня нет проблем с представлением расширения пространства и даже есть понимание, что даже в этом случае мы можем вычислить местонахождение того самого центра, прокомментируете?
Кстати при увеличении размеров шарика в два раза (по каждой оси) длина волны увеличится не в два раза, а пропорционально квадрату, т.е. в 4 раза, т.к. волна — дуга на сфере.
Ну и про скорость света ввернуто неизвестно почему, ни отсылок на вики ни на что-то еще
Так я нигде и не употреблял термин «вращение вокруг множества плоскостей» не надо это мне приписывать.
Я представляю себе это так — берем пространство Вселенной, берем плоскость содержащую, например, нашу галактику и пару далеких-далеких галактик. Которые условно можно представить как точки. Далее смотрим, что ученые говорят, мол крсное смещение и все друг от друга отдаляются, но никто не говорит каков реальный относительный вектор движения. Тогда делается предположение, что допускается не обязательно вектор направленный строго от нас, вплоть до боковое движение может намного превосходить движение от нас. Отсюда я предполгаю, что если представить на нашей плоскости врщающийся диск и галактики слетащие с него (как капли воды при раскручивании CD-диска), то относительное расстояние между ними всегда будет увеличиваться (чем дальше от центра тем с больше скоростью улетают) аналоигчно наблюдаемому.
Далее я считаю, что такое движение идет в пределах любой плоскости, а не конкретной, как в вашем примере с Млечным путем.
И чтобы подтвердить/опрвергнуть эту теорию предполагаю, что получив хоть какой-то вектор движения удаленных объектов и усреднив данные, можно было бы заметить конусообразность разлета, что указало бы либо на центр откуда все разлетается. Либо укажет на центр Вселенной, т.к. мне кажется, что при именно расширении вселенной будет плюс-минус такая же конусная картина разлета.
Насколько понимаю вся пробелма в четком определнии вектора движения, но это решается парой тройкой лет наблюдений и постройки пространственной модели.
Я не силен в ОТО, но разве нельзя добиться того же эффекта «разбегания» на вращающейся плоскости? Само собой имеется ввиду множество плоскостей по всем направлениям, заполняющих сферу вселенной, а не какая-то одна. Если представить достаточно большие расстояния, то разбегание так же будет пропорционально расстоянию между объектов (если шарик раскрутить с грузиками на конце, он так же будет растягиваться в плоскости врщения). В этому случае допустимо считать вселеную вполне себе постоянного бесконечного размера (самому конечно неочень верится в то что пишу, но все же). К тому же в таком случае можно достаточно «легко» подвердить/опревергнуть эту теорию, т.к. достатоно определить конусность разбегания и место предполагаемого центра. Кстати при расширении по идеи должен наблюдаться такой же эффект разбега по конусу от центар Вселенной.
Если проводились исследования на предмет проверки такой теории, то прошу поделиться ссылками.
Вот из-за того, что вы не понимаете как соотносятся версии ФН, ККТ и ФФД и получается такая путаница. Еще раз использование ФФД 1.05 не зависит от ФН и некорректно говорить «заменить его уже на 1.05 или 1.1». Корректно было бы: «заменить ФН на поддерживающий ФФД 1.05 и 1.1, а так же произвести обновление ККТ»
Хочу уточнить по поводу сказанного о ФФД 1.0, т.е. новые ФНы имеют спец команду для изменения режима работы как ФН 1.0 так и ФН 1.1? Если да, то хотелось бы увидеть какую-нибудь ссылку на спецификацию ФН или как это настраивается.
не могу удержаться, хоть и не пикабуха
Hidden text
Так-то по вашей аналогии с доп руками можно набирать тучу джунов, когда на проекте полный разброд и одна нянька (если повезет) - тогда получаем, что со временем на этих джунах уже и проект держится, и CI поднимается, и ТП выстроена, и мониторинги с алертами и т.п. Главное чтобы по той же вашей аналогии, эти джуны никуда не могли/не хотели уйти с этого проекта, тогда все будет тоже в шоколаде)
Красиво конечно, но сколько раз ни думал о возможности взаимодействия реального мира и цифрового мира блокчейнов, всегда возникала проблема в том, что всегда могут появиться обстоятельства во внешнем мире, которые приведут к манипулированию данными или например одна из сторон/систем просто перестанет быть участником по различным причинам и тогда блокчейн ничего даст и более того тот же контракт зависнет в неопределенном статусе - собственно это проблема номер два в вашем списке.
Самая банальная ситуация, которую надо бы решить для начала: в цепочке поставщиков появляется фальсификатор данных или сговор нескольких участников, которые отправляют в блокчейн данные, которые от них ожидают, но в реальности что-то делается с товаром. В результате следущий в цепочке получает меньше/поврежденный/другой товар, но в блокчейне же посредник зафиксировал, что все было ок - и кто виноват? А если это именно потребитель решил вывести конкурента поставщика из дела, т.к. у него на примете есть знакомый поставщик и стоит цель в дикредитации? А что если это просто датчики сбойнули и посредник просто не мог получить реальные данные и тогда он добросовестный, а должен отвечать поставщик датчиков? И тут мы возвращаемся в наш реальный мир договоров и судов, в котором данные из блокчейна наверняка будут признаны ничтожными.
Единственный вариант, который вижу - присутвие контролеров на каждом точке обмена от каждого участника для подтверждения с занесением и подтверждением данных в блокчейн, тогда это будет работать, т.к. будут отвественные. Правда тогда с выстраиванием всего этого процесса сам блокчейн фактически будет общей распределенной БД по поставкам и смартконтракты на нем будут только в роли фиксаторов событий, но никак не контролирующим и принимающим решения участником процесса, как это обычно преподносится.
В эпоху современных приложений, сжирающих любые ресурсы что у пользователя что на серверах, разработка под блокчейны, как и под микроконтроллеры и другие специфические железные темы, требует именно программирования с придумыванием способов решения бизнес задач в условиях крайне ограниченных ресурсов - это стоит воспринимать как хорошую практику для мозга и кому-то действительно именно это интересно. Так что блокчейн не плох - он просто не про "наляпать лишь бы что за пару сторипоинтов", хотя и такое вцелом возможно.
А использовать или нет - дело каждого, и на всякий случай напомню, что блокчейн != крипта и стоит относиться к этому прежде всего как к технологии раз уж мы на ИТ-ресурсе.
@BoomburumА были ли идеи для минусов в карму добавить необходимость вводить причну? Например, стандартный список чекбоксов со стандартными причинами +другое с полем для коммента. И пользователю выводить сводку, чтобы он понимал за что его минусуют. Аналогично можно для плюсов ввести - для тех, кто хочет понимать что именно он делает хорошо это будет хорошим подспорьем в мотивации.
Ну и если уж идти совсем упарываться - и на статьи и на комменты тоже подобное навесить) Но тут можно ухудшить UX и отпугнуть людей лишний раз оценивать
Первых двух ограничений в монге уже давно нет, аналог JOIN - $lookup, который также позволяет наложить доп условия на связывание и с доп обработкой.
Легкость в горизонтальном масштабировании есть в части увеличения нагрузки на чтение за счет простой репликации, но в части шардинга и увеличения нагрузки по записи и просто расширения объемов хранения имеет свои подводные камни и это должно быть продумано на этапе проектирования БД и написании кода, либо потом это будет не легко и не быстро.
И надо очень осторожно относиться к поддержке текстового поиска, в стандартной монге он есть, но только по морфологии, фултекста нет, подобрать похожее слово при наличии опечаток (fuzzy) тоже не получится, поиска по части слова нет и зачастую текстовый поиск сводится к регуляркам, что очень не быстро на больших объемах. Но все эти фичи имеются в облачном MongoDB Atlas Search
В общем опыт работы с монгой говорит о том, что сначала делается хоть как-то работающий прототип, он доживает до проявления болячек отсутствия проектирования и наработки компетенций по работе с монгой. После чего все старое выкидывается и проектируется структура БД и инфраструктура уже с учетом реальных потребностей проекта с использованием всех плюшек монги или понимания того, что монга не подходит/недостаточно и надо ставить что-то рядом под спец задачи.
Киберпреступник #1
Во-первых если его просто запустить, то он загоняет оба потока в park в среднем на 15 тысячах итераций на 8 ядерном камне.
Во-вторый есть критичные действия, которые не находятся в критичной секции, в результате очень легко первый поток сетит мессадж, он рапарковывает второй поток, и убегает в первую секцию, но останавливается перед parkedThread.set. Второй поток начинает движение во вторую секцию, доходит до распарковывания первого потока, но он не видит в parkedThread ничего и тут же убегает в первую ветку ифа, где уже оба потока доходят до парковки без проблем и лочатся навсегда.
И да для многопоточки все-таки нужно подтверждать корректность своих реализаций чем-нибудь наподобие jcstress
Опять же скорее всего это уже не правилньая сфера, а просто какая-то трехмерная поверхность.
Если я с правильно понял про вектора угловых скоростей (хотя до конца так и не понял что имелось ввиду), то в этом то и фишка, что сейчас уже нет явных закономерностей по общему распределнию векторов вращения. Они находятся в пространстве, а не на плоскости, даже толстой. А мы лишь на основании статистики смогли бы вычислить преобладание определенных градиентов от некторого мифического центра.
Пока же я не вижу ни одной проблемы в абстрагировании от рассмотрения всей кучи событий и сосредоточиться лишь на конкретной плоскости, а дальше просто экстраполировать рассуждения на все возможные плоскости, образующие весь объем нашего пространства.
К первому замечанию скажу, что мы не знаем какие красные смещения в других точках за пределами хотя бы нашей Солнечной системы, не говоря о других галактиках, так что вопрос про отсутствие инвариантов крайне спорный. Тут необходимо предложить способ однозначно разрешаеющий его. Так что очень уместно считать, что данные варианты как минимум равносильны. Пока же я считаю, что относительное расстояние между любыми точками, разлетающихся с вращающегося диска увеличивается и это относится к любой точке данного диска, а значит мы можем себя ставить в люое место во Вселенной и наблюдать то же, что и сейчас.
Ко второму замечанию скажу, что вы как и многие другие не можете представить, что вращение может идти не в одной плоскости. Я предполагаю, что нет необходимости связывать себя рамками какой-то одной плоскости, да при размерах наблюдаемых спиральных галлактик видна именно конкретная плоскость, однако она же не нулевой толщины, а вполне себе имеет «толщину». Так вы же не будете отрицать, что если мы возьмем звезду из такой галактики, максимально удаленную усредненной плоскости вращения, то она так же вращается вокруг центра галактики. Получается ее плоскость вращения досточно сильно отличается от усредненной, и нам ничего не мешает представить, что на множестве галлактик происходит нечто подобное, но там разброс пошел такой, что такие «максимально выбивающиеся» галактики заполнили шар, а не диск, но при этом продолжают вращаться относительно центра. Первопричина наверняка в Большом взрыве, разбросавшем материю во все стороны.
Кстати при увеличении размеров шарика в два раза (по каждой оси) длина волны увеличится не в два раза, а пропорционально квадрату, т.е. в 4 раза, т.к. волна — дуга на сфере.
Ну и про скорость света ввернуто неизвестно почему, ни отсылок на вики ни на что-то еще
Я представляю себе это так — берем пространство Вселенной, берем плоскость содержащую, например, нашу галактику и пару далеких-далеких галактик. Которые условно можно представить как точки. Далее смотрим, что ученые говорят, мол крсное смещение и все друг от друга отдаляются, но никто не говорит каков реальный относительный вектор движения. Тогда делается предположение, что допускается не обязательно вектор направленный строго от нас, вплоть до боковое движение может намного превосходить движение от нас. Отсюда я предполгаю, что если представить на нашей плоскости врщающийся диск и галактики слетащие с него (как капли воды при раскручивании CD-диска), то относительное расстояние между ними всегда будет увеличиваться (чем дальше от центра тем с больше скоростью улетают) аналоигчно наблюдаемому.
Далее я считаю, что такое движение идет в пределах любой плоскости, а не конкретной, как в вашем примере с Млечным путем.
И чтобы подтвердить/опрвергнуть эту теорию предполагаю, что получив хоть какой-то вектор движения удаленных объектов и усреднив данные, можно было бы заметить конусообразность разлета, что указало бы либо на центр откуда все разлетается. Либо укажет на центр Вселенной, т.к. мне кажется, что при именно расширении вселенной будет плюс-минус такая же конусная картина разлета.
Насколько понимаю вся пробелма в четком определнии вектора движения, но это решается парой тройкой лет наблюдений и постройки пространственной модели.
Если проводились исследования на предмет проверки такой теории, то прошу поделиться ссылками.
Хочу уточнить по поводу сказанного о ФФД 1.0, т.е. новые ФНы имеют спец команду для изменения режима работы как ФН 1.0 так и ФН 1.1? Если да, то хотелось бы увидеть какую-нибудь ссылку на спецификацию ФН или как это настраивается.