Верить или не верить сугубо дело каждого, но на собственном опыте точно знаю что такие явления имеют место быть. Причём влияние может быть как в одну так и в другую сторону.
После окончания института я работал в конструкторском бюро и мои коллеги быстро заметили одну особенность, позволявшую быстрее решать одну из неприятных конструкторских задач - поиск "плавающих неисправностей". В моём близком присутствии все плавающие неисправности проявлялись постоянно. Сидит инженер и отлаживает схему (подбирает параметры настраиваемых компонентов, ищет плохие контакты ...) какой-то узел то работает, то не работает как задумано, причём независимо от воздействий на него. Стоит мне подойти и узел начинает стабильно не работать, что позволяет коллеге быстро найти неисправность делая замеры в разных контрольных точках.
Меня реально много раз звали чтобы рядом постоял.
А в отделе технического обслуживания компьютерной техники работала женщина, в присутствии которой плавающие неисправности переставали происходить. Сам был свидетелем того как зам. главного конструктора готовил какой-то срочный отчёт на ПК, а у него то и дело гас экран, нажатия кнопок не приводили к выводу символа на экран, текстовый редактор то и дело зависал ... Тогда ПК были редкость и просто пересесть было не вариант, он вызывал техподдержку, приходила эта женщина и пока она стояла рядом всё работало абсолютно нормально. Данный эпизод закончился тем что пока зам не дописал свой отчёт она просто сидела рядом. Впоследствии этот ПК забрали на ремонт и нашли какую-то неисправность в блоке питания. Но подобные инциденты с этой женщиной я сам наблюдал неоднократно.
Научного объяснения данному феномену я тоже дать не смогу, но факты вещь упрямая.
Я смотрел сначала первую часть, потом вторую, и считаю первую несомненным успехом, а вторую шедевром. Потом посмотрел третью часть и это уже явное стремление срубить бабла на раскрученной теме - ничего, что могло бы считаться развитием я не увидел. А четвёртая часть, так и вообще полная дискредитация всего предшествующего.
Естественно, но если нет идеи, то и реализовывать нечего.
Общественного консенсуса нет. Любая идея в таком случае найдет своих противников.
Тем не менее общество не находится в постоянной конфронтации и некий консенсус всегда имеет место быть. Площадка и в текущем виде осуществляет свою функцию - идеи проходят отбор и общей деградации не происходит.
Возможно мне и не удастся придумать более эффективной процедуры, но это не означает что рассуждать в эту сторону нельзя.
Если у Вас нет конструктивных идей по предложенной мною теме, то не стоит зря тратить наше время.
Это закроет дорогу тем, кому пришла в голову хорошая, полезная для всех идея, но нет ресурсов на создание прототипа, или создание этого прототипа без поддержки вообще нецелесообразно. Например, высказанные мною идеи бесполезно даже начинать как коммерческие продукты.
Именно поэтому первым пунктом я поставил требование отсутствия любых видов фильтрации идей.
Вы всё время уклоняетесь в стадии после той, ради которой я инициировал это обсуждение. Хотя раньше у Вас была хорошая статья, подходящая для этой темы - https://habr.com/ru/articles/27392/. Возможно Хабр Вас чем-то разочаровал и высказывания
Все это для Хабра не проблема...
..., а повседневная реальность.
Вас как-то успокаивают, но я бы хотел конструктивного обсуждения именно в заданных публикацией рамках. Если сформулировать хорошие правила для получения синергии на коллективных площадках высказывания идей, это может принести пользу не только там, где я сейчас пытаюсь получить поддержку своим идеям, но и на Хабре, да и на любых других площадках.
AGILE это методология реализации проектов в условиях сильного дефицита исходных требований и частой смены приоритетов. Как это можно сопоставить с деятельностью АСИ я пока не понимаю.
Те пункты, которые Вы перечислили, это общий принцип деятельности любых инвестиционных структур. Относящийся к поставленной мною проблеме элемент в Вашем посте это
На этой стадии отбор осуществляется максимально формально - на соответствие критериям.
Я сейчас размышляю над тем как должен быть устроен этот отбор и какие критерии, процедуры и этапы должны быть. Как должен формироваться экспертный совет или его адекватная замена. Причём главной задачей считаю необходимость работы данных механизмов на любых масштабах идей (не только стартапы 5-15 человек с годовым циклом разработки). Если есть мысли как может быть устроен такой отбор буду благодарен за их формулировку в любом виде.
Слово "коррупция" я похоже применил по инерции и не совсем к месту.
Задача площадки в первую очередь делать качественный отбор идей, распределение бюджета возникает позже, поэтому вопрос рынка и инвестиций ещё не актуален. Более точно подходит аффилированность - чтобы голосующие эксперты принимали решение объективно, а не с учётом кумовства.
И, пожалуй, самым главным моментом в этой теме является создание механизма по уточнению поданных идей и их многоступенчатому ранжированию для обеспечения максимально возможной объективности в выборе финалистов.
Площадка собирает идеи не только в сфере IT, поэтому механизмы должны основываться на очень простых понятиях, но трудность ещё заключается в том чтобы не упираться в субъективность отдельных экспертов, которые могут не увидеть существенную новизну и перспективность в коротких текстах.
Если брать раздел "5.1 A Purely Relational Implementation", то он реализован полностью. Правда я подходил к этому документу как к описанию метода и структура хранения, собственно машина формирования запросов, несколько видоизменены, но основной подход полностью соответствует "proposal-у". Видоизменения вызваны тем, что я планирую довести этот проект до состояния, когда можно сохранять в базе данных любые соответствующие спецификациям xml-документы с учётом эволюции описывающих их xsd-схем (и сами схемы тоже), строить на полном множестве всех документов любые запросы, соответствующие спецификации XPath 3.1 и связывать отдельные узлы документов с НСИ и JPA-сущностями любых бизнес-доменов.
В некоторой части соглашусь - писать велосипеды пустая трата времени, но я уверен, что данное решение будет оптимальным для описанного мною класса проблем. Тем более, что это не отдельно стоящий парсер, а инструмент, превращающий реляционную базу данных в эффективно работающее документоориентированное хранилище. Возможность выполнять любые иерархические запросы с той же производительностью, что и реляционные запросы к плоским таблицам, позволяет упростить решение очень многих бизнес-задач.
Я рассматриваю проблему на стороне подсистемы, осуществляющей хранение и обработку. Реализованное мною решение не нуждается в накоплении чего-либо в промежуточных форматах. Сохранение в базу данных - поточная процедура, работающая с той производительностью сохранения, которую может предоставить реляционная база данных. Хранение иерархических данных осуществляется в трёх таблицах (документы, узлы документов и связи между ними).
Вопрос создания xml-документа чаще всего лежит на стороне бизнес-потребности и универсальный инструмент хранения/обработки должен с максимально возможной производительностью работать независимо от размеров данных, которые в него загружают.
В принципе идея витает в воздухе, я уже подходил к ней со стороны экономических потребностей - в текущем её состоянии, когда мера стоимости превратилась в тыкву, единственный более-менее надёжный способ долгосрочного планирования может опираться только на достаточно надёжные предсказания основных экономических величин: спрос, котировки, уровень конкуренции, сезонные колебания .. И в экономике достаточно быстро работают обратные связи - если чей-то способ показывает более высокую эффективность, то его достаточно быстро начинают использовать все Если создать систему с чёткими и понятными правилами игры, в которой самым главным критерием является рейтинг экспертизы, дающей наиболее точные прогнозы, то такая система должна сама себя воспроизводить и расширяться. Правда наиболее высокие риски я здесь вижу именно в моменте перехода на децентрализацию, сразу децентрализованной такая система быть не может, а поскольку будет завязана на экономику, будет много желающих прибрать её к рукам.
По поводу аффилированности я лет пять назад писал для ФНС-а программу которая готовила им кандидатов для камеральных проверок, как раз на основе ЕГРЮЛ-а и ещё нескольких публичных источников данных. Впоследствии пытался сделать централизованный сервис для коммерческих структур который позволил бы им гораздо проще кооперироваться. Осталось довольно много наработок, готов принять посильное участие в проекте если наберётся достаточное количество единомышленников.
К сожалению бизнес-цели работают в противоположном направлении к построению надёжных, долговечных решений. Улучшать положение в индустрии можно только в том случае, если будет подходящая задача и серьёзные инвестиции. Например если дальнейший рост аппаратных возможностей упрётся в технологические пределы.
Верить или не верить сугубо дело каждого, но на собственном опыте точно знаю что такие явления имеют место быть. Причём влияние может быть как в одну так и в другую сторону.
После окончания института я работал в конструкторском бюро и мои коллеги быстро заметили одну особенность, позволявшую быстрее решать одну из неприятных конструкторских задач - поиск "плавающих неисправностей". В моём близком присутствии все плавающие неисправности проявлялись постоянно. Сидит инженер и отлаживает схему (подбирает параметры настраиваемых компонентов, ищет плохие контакты ...) какой-то узел то работает, то не работает как задумано, причём независимо от воздействий на него. Стоит мне подойти и узел начинает стабильно не работать, что позволяет коллеге быстро найти неисправность делая замеры в разных контрольных точках.
Меня реально много раз звали чтобы рядом постоял.
А в отделе технического обслуживания компьютерной техники работала женщина, в присутствии которой плавающие неисправности переставали происходить. Сам был свидетелем того как зам. главного конструктора готовил какой-то срочный отчёт на ПК, а у него то и дело гас экран, нажатия кнопок не приводили к выводу символа на экран, текстовый редактор то и дело зависал ... Тогда ПК были редкость и просто пересесть было не вариант, он вызывал техподдержку, приходила эта женщина и пока она стояла рядом всё работало абсолютно нормально. Данный эпизод закончился тем что пока зам не дописал свой отчёт она просто сидела рядом. Впоследствии этот ПК забрали на ремонт и нашли какую-то неисправность в блоке питания. Но подобные инциденты с этой женщиной я сам наблюдал неоднократно.
Научного объяснения данному феномену я тоже дать не смогу, но факты вещь упрямая.
Я смотрел сначала первую часть, потом вторую, и считаю первую несомненным успехом, а вторую шедевром. Потом посмотрел третью часть и это уже явное стремление срубить бабла на раскрученной теме - ничего, что могло бы считаться развитием я не увидел. А четвёртая часть, так и вообще полная дискредитация всего предшествующего.
Естественно, но если нет идеи, то и реализовывать нечего.
Тем не менее общество не находится в постоянной конфронтации и некий консенсус всегда имеет место быть. Площадка и в текущем виде осуществляет свою функцию - идеи проходят отбор и общей деградации не происходит.
Возможно мне и не удастся придумать более эффективной процедуры, но это не означает что рассуждать в эту сторону нельзя.
Если у Вас нет конструктивных идей по предложенной мною теме, то не стоит зря тратить наше время.
Посмотрите на https://cyberleninka.ru/article/n/issledovanie-svoystv-matritsy-gilberta-i-prichin-ee-plohoy-obuslovlennosti/viewer
Вот-вот, я пока продумываю что-то типа шахматных рейтингов, которые определяются путем коллективного сравнения похожих идей друг с другом.
Это закроет дорогу тем, кому пришла в голову хорошая, полезная для всех идея, но нет ресурсов на создание прототипа, или создание этого прототипа без поддержки вообще нецелесообразно. Например, высказанные мною идеи бесполезно даже начинать как коммерческие продукты.
Именно поэтому первым пунктом я поставил требование отсутствия любых видов фильтрации идей.
Вы всё время уклоняетесь в стадии после той, ради которой я инициировал это обсуждение. Хотя раньше у Вас была хорошая статья, подходящая для этой темы - https://habr.com/ru/articles/27392/. Возможно Хабр Вас чем-то разочаровал и высказывания
Вас как-то успокаивают, но я бы хотел конструктивного обсуждения именно в заданных публикацией рамках. Если сформулировать хорошие правила для получения синергии на коллективных площадках высказывания идей, это может принести пользу не только там, где я сейчас пытаюсь получить поддержку своим идеям, но и на Хабре, да и на любых других площадках.
AGILE это методология реализации проектов в условиях сильного дефицита исходных требований и частой смены приоритетов. Как это можно сопоставить с деятельностью АСИ я пока не понимаю.
Те пункты, которые Вы перечислили, это общий принцип деятельности любых инвестиционных структур. Относящийся к поставленной мною проблеме элемент в Вашем посте это
Я сейчас размышляю над тем как должен быть устроен этот отбор и какие критерии, процедуры и этапы должны быть. Как должен формироваться экспертный совет или его адекватная замена. Причём главной задачей считаю необходимость работы данных механизмов на любых масштабах идей (не только стартапы 5-15 человек с годовым циклом разработки). Если есть мысли как может быть устроен такой отбор буду благодарен за их формулировку в любом виде.
Слово "коррупция" я похоже применил по инерции и не совсем к месту.
Задача площадки в первую очередь делать качественный отбор идей, распределение бюджета возникает позже, поэтому вопрос рынка и инвестиций ещё не актуален.
Более точно подходит аффилированность - чтобы голосующие эксперты принимали решение объективно, а не с учётом кумовства.
И, пожалуй, самым главным моментом в этой теме является создание механизма по уточнению поданных идей и их многоступенчатому ранжированию для обеспечения максимально возможной объективности в выборе финалистов.
Площадка собирает идеи не только в сфере IT, поэтому механизмы должны основываться на очень простых понятиях, но трудность ещё заключается в том чтобы не упираться в субъективность отдельных экспертов, которые могут не увидеть существенную новизну и перспективность в коротких текстах.
Пока что ещё раздумываю над разными вариантами, пока ни один не тянет на рабочий :(
Мне кажется вас может заинтересовать https://habr.com/ru/post/711682/
Спасибо, в точку!
Было бы очень любопытно узнать в чём Вы видите смысл этой статьи?
Если брать раздел "5.1 A Purely Relational Implementation", то он реализован полностью. Правда я подходил к этому документу как к описанию метода и структура хранения, собственно машина формирования запросов, несколько видоизменены, но основной подход полностью соответствует "proposal-у". Видоизменения вызваны тем, что я планирую довести этот проект до состояния, когда можно сохранять в базе данных любые соответствующие спецификациям xml-документы с учётом эволюции описывающих их xsd-схем (и сами схемы тоже), строить на полном множестве всех документов любые запросы, соответствующие спецификации XPath 3.1 и связывать отдельные узлы документов с НСИ и JPA-сущностями любых бизнес-доменов.
Здесь - В 2006-м году корпорацией IBM был опубликован интересный документ.
В некоторой части соглашусь - писать велосипеды пустая трата времени, но я уверен, что данное решение будет оптимальным для описанного мною класса проблем. Тем более, что это не отдельно стоящий парсер, а инструмент, превращающий реляционную базу данных в эффективно работающее документоориентированное хранилище. Возможность выполнять любые иерархические запросы с той же производительностью, что и реляционные запросы к плоским таблицам, позволяет упростить решение очень многих бизнес-задач.
Я рассматриваю проблему на стороне подсистемы, осуществляющей хранение и обработку. Реализованное мною решение не нуждается в накоплении чего-либо в промежуточных форматах. Сохранение в базу данных - поточная процедура, работающая с той производительностью сохранения, которую может предоставить реляционная база данных. Хранение иерархических данных осуществляется в трёх таблицах (документы, узлы документов и связи между ними).
Вопрос создания xml-документа чаще всего лежит на стороне бизнес-потребности и универсальный инструмент хранения/обработки должен с максимально возможной производительностью работать независимо от размеров данных, которые в него загружают.
В принципе идея витает в воздухе, я уже подходил к ней со стороны экономических потребностей - в текущем её состоянии, когда мера стоимости превратилась в тыкву, единственный более-менее надёжный способ долгосрочного планирования может опираться только на достаточно надёжные предсказания основных экономических величин: спрос, котировки, уровень конкуренции, сезонные колебания ..
И в экономике достаточно быстро работают обратные связи - если чей-то способ показывает более высокую эффективность, то его достаточно быстро начинают использовать все
Если создать систему с чёткими и понятными правилами игры, в которой самым главным критерием является рейтинг экспертизы, дающей наиболее точные прогнозы, то такая система должна сама себя воспроизводить и расширяться.
Правда наиболее высокие риски я здесь вижу именно в моменте перехода на децентрализацию, сразу децентрализованной такая система быть не может, а поскольку будет завязана на экономику, будет много желающих прибрать её к рукам.
По поводу аффилированности я лет пять назад писал для ФНС-а программу которая готовила им кандидатов для камеральных проверок, как раз на основе ЕГРЮЛ-а и ещё нескольких публичных источников данных. Впоследствии пытался сделать централизованный сервис для коммерческих структур который позволил бы им гораздо проще кооперироваться. Осталось довольно много наработок, готов принять посильное участие в проекте если наберётся достаточное количество единомышленников.