Сейчас каждый 2ой проект замахивается на что-то «великое», «большое», «мы сделаем платформу, все будут там выполнять операции, а мы — только комиссию стричь и ни за что не отвечать», но кмк — блокчейн как технология, при её комодитизации, сможет стать основой для самоорганизации локальных сообществ, то что называется «комьют» и то чего сейчас нам так не хватает.
«инфраструктурных» как раз и означает — «закрытых».
«Инфраструктура» не сможет работать на POW. И скорее всего (по старой традиции) — всё сойдется к POA как к наиболее «эффективному» решению. А кто же будут эти «A»?) Вполне конкретный поименованный закрытый список серверов.
Например на базе ЦБ или дата-центров налоговой развернуть «условный» клон эфира в режиме POA.
Фискалы получат возможность видеть все потоки, банки снимут с себя пласт проблем с безопасностью и серверами, государство получит универсальную среду для автоматизации любых процессов. Хочешь — алкоголь регулируй, хочешь — шубы маркируй, хочешь к врачу записывай, хочешь — бездельников из ПФР разгоняй.
Но вот это как раз и означает — обмен сообщениями, подписанными ЭЦП), «Ничего нового» в таких сценариях технология не даёт.
Просто сейчас квалифицированные ЭЦП — дорого (а до недавнего времени на каждый чих нужна была своя), а тут как бы «бесплатно». Например через госуслуги.
Еще ребята из Parity рассказывали о своем аналогичном микрософтовому проекту — с биометрическими паспортами в/на блокчейне (эфир) + децентрализованная платежная система, когда по этим паспортам можно отовариваться в магазинах (получать прод.паёк), а потом благотворительная организация оплачивает магазинам «счета» (покупает их «тушонко-эфиры/тушонко-токены» за деньги).
В остальном — блокчейн это классно и здорово, но в «закрытых» системах — всё превращается во вполне «традиционный» обмен сообщениями подписанными ЭЦП. А с точки зрения корпоративного сектора — ближайшим аналогом будет некая «универсальная интеграционная шина».
Кмк Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
То что у вас "не получилось" с выделенной командой тестеров говорит скорее о слабости менеджмента, чем об ошибочности подхода. Особенно, когда у вас много проектов — сам боженька велел матричную структуру с отдельным ульем тестеров в котором будет накапливаться, прости Господи, экспертиза.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит. Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.
Оптимизировать и улучшать это всегда хорошо.
Но предположу, что корень ваших проблем в другом.
По моему такое происходит,, когда:
1)где-то топовый и/или линейный менеджер не на совсем месте: несколько раз "некрасиво" отреагировал на инициативу снизу и привет -больше инициатив и не будет.
2)не пахнет деньгами. Когда не пахнет деньгами, люди в ситуации когда стоит выбор между
а)быстро решить и сделать как лучше для дела и всем заработать
б)долго позерствовать и сделать "как я сказал, потому что я самый умный — нет! Я самый умный!", а не как будет "лучше"
Будут чаще вариант (б) с соответствующими результатами для бизнеса. Вроде и дерьмо, а вроде и "никто не виноват"
И если не мониторить поведение и не заниматься воспитанием, то как не "делись" — все вернётся на круги своя
Классно, но, ваши проблемы с esb от того, что все хотят быть "архитекторами", а думать и за "дисциплиной" следить некому.
И с этой точки зрения "а давайте микросервисы теперь!" — ровно тоже самое что "а давайте все перепишем!", но проблемы ваши не решит.
Вы точно так же "намесите" и с микросервисами и придёте ровно к тем же проблемам (правда это случится не сразу и скорее всего ура-реформаторы успеют покинуть проект с повышением)
Не совсем понял, в чем именно «трюк»?
Что delegatecall работает с данными в контексте вызывающего контракта а не вызываемого? (но это «нормальное» поведение)
Забавно, что в подобных историях детали не важны в том смысле, что это просто «кармическое»:
сэкономил в одном месте («а че так дорого? я на фрилансе за эти деньги 5х найму!») — заплатил в другом.
Аналогичную вещь реализовал на kotlin для departureBot.ru чтобы понимать запросы вроде "туры в Италию Испанию или Грецию в начале июня на 7-10 дней"
Не стал выкладывать т.к. парсер грамматик работает на выводе pymorphy (начальная форма + грамемы). Никто кст не знает живой аналогичной библиотеки с русским (и словарями) для jvm?
Маленький шаг для человека, огромный шаг для spring.
Сложность с rx -стилем в коде только в том, что без контроля очень легко получить "мама-смотри-какой-я-умный" лапшу в коде, причем даже на небольшом количестве строк.
И с этой точки зрения корутины котлина с синтаксическим сахаром кажутся весьма хорошим решением вместе с project reactor и spring
Все так. Но в книжках и на тренингах по "успешному успеху" обычно о таком не рассказывают (потому, что не "круто" и потому что реального опыта у тренеров и коучей часто исчезающе мало — у них просто нет истории провалов).
В сухом остатке, пожалуй, работающих стратегией остаётся только 2:
1) "проверять" модель, "пробовать" с минимальными кап вложениями +"Секси-идея" далеко не всегда по рентабельности обгонит точку по продажи шаурмы.
Если вероятность провала 0.9, то попробовав 5 раз — вероятность что все попытки буду провальными уже 0.6 ;)
2)участвовать в нескольких проектах параллельно своими связями/опытом.
Возможно, настоящая причина проблем в коллективе из статьи как раз в этом, а не в том, что каждый понимает одни и те же «лозунги» немного «по-своему».
Как это происходит:
1)Тимлид/ТехДир/Кто-то еще (Пусть будет Мистер М) делает ультимативным тоном спорное утверждение обильно посыпая его высокомерными ужимочками.
Обычно суть утверждения в следующем «Я Очень умный, надо делать так-то, а вы все Дебилы если со мной не согласны».
2) «Вы все» — слушают, но с такой оценкой себя они, конечно, не согласны — и начинается спор о том, чем «чьё кунг-фуDRY круче».
Последствия:
1)Когда оказывается, что М ошибся (так тоже бывает не редко) — признать это и принять решение которое было бы лучше для проекта ему мешает то заявление, в котором он назвал всех «идиотами»
2)«Вы все» — будут и дальше часть времени тратить не на то чтобы «дотащить проект», а на то чтобы найти где еще мистер М налажал
3)Эго МистераМ оплачено человеко-часами из бюджета проекта.
В чём мораль?
1)Не будьте «М». Вы не «самый умный в этой комнате».
2)Если вы нанимаете к себе в команду человека — постарайтесь убедиться что он не М.
//возврат денег при попытке отправить деньги на контракт
function () public payable {
revert();
}
Произойдет возврат только остатков газа. Приложенный к вызову эфир останется на счету контракта.
Этот fallback метод лучше совсем убрать. Тогда будет работать как задумано: эфир не получится отправить на баланс контракта прямым переводом.
Всё верно.Но как я уже писал — вопрос экономики. Если на кону джекпот под 100$млн — возможность манипуляции результатом «вызывает вопросы». Если же речь о «школьных завтраках» — то, конечно, заморачиваться никто и не будет.
В теории, если крупный Майнер имеет стойкий мотив в результатах лотереи, то когда такой результат зависит по известной (код контракта ведь публичные) формуле от хеша блока и/или времени его генерации, то Майнер помимо основной задачи, может искать такое решение которое даст такой хеш блока, который бы дал нужный результат в лотерее.
Вопрос лишь в экономике
1)Купить компанию с понятным продуктом, денежным потоком и дорогой местной разработкой
2)В короткие сроки перевести процесс разработки на свой overseas персонал, когда сокращение костов в 2 раза бонусом даёт еще и рост квалификации разработчиков. + общие юристы и бухгалтерия.
3)Распустить дорогих местных разработчиков, бухгалтеров, юристов.
4)…
5)PROFIT
Это гениально, черт возьми!
Удивлен, что это еще не стало повсеместным трендом среди крупных аутсорсеров
«Инфраструктура» не сможет работать на POW. И скорее всего (по старой традиции) — всё сойдется к POA как к наиболее «эффективному» решению. А кто же будут эти «A»?) Вполне конкретный поименованный закрытый список серверов.
Например на базе ЦБ или дата-центров налоговой развернуть «условный» клон эфира в режиме POA.
Фискалы получат возможность видеть все потоки, банки снимут с себя пласт проблем с безопасностью и серверами, государство получит универсальную среду для автоматизации любых процессов. Хочешь — алкоголь регулируй, хочешь — шубы маркируй, хочешь к врачу записывай, хочешь — бездельников из ПФР разгоняй.
Но вот это как раз и означает — обмен сообщениями, подписанными ЭЦП), «Ничего нового» в таких сценариях технология не даёт.
Просто сейчас квалифицированные ЭЦП — дорого (а до недавнего времени на каждый чих нужна была своя), а тут как бы «бесплатно». Например через госуслуги.
В остальном — блокчейн это классно и здорово, но в «закрытых» системах — всё превращается во вполне «традиционный» обмен сообщениями подписанными ЭЦП. А с точки зрения корпоративного сектора — ближайшим аналогом будет некая «универсальная интеграционная шина».
Кмк Рейты писателя скриптов пользовательских сценариев ниже рейта разработчика. Давая эту работу более дорогому специалисту вы только увеличите бюджет.
То что у вас "не получилось" с выделенной командой тестеров говорит скорее о слабости менеджмента, чем об ошибочности подхода. Особенно, когда у вас много проектов — сам боженька велел матричную структуру с отдельным ульем тестеров в котором будет накапливаться, прости Господи, экспертиза.
А когда менеджмент слаб — никакой божественный agile, к сожалению, проблем не решит. Как только эффект новизны пройдет нерешённые проблемы в коммуникации и доверии сделают своё дело.
Оптимизировать и улучшать это всегда хорошо.
Но предположу, что корень ваших проблем в другом.
По моему такое происходит,, когда:
1)где-то топовый и/или линейный менеджер не на совсем месте: несколько раз "некрасиво" отреагировал на инициативу снизу и привет -больше инициатив и не будет.
2)не пахнет деньгами. Когда не пахнет деньгами, люди в ситуации когда стоит выбор между
а)быстро решить и сделать как лучше для дела и всем заработать
б)долго позерствовать и сделать "как я сказал, потому что я самый умный — нет! Я самый умный!", а не как будет "лучше"
Будут чаще вариант (б) с соответствующими результатами для бизнеса. Вроде и дерьмо, а вроде и "никто не виноват"
И если не мониторить поведение и не заниматься воспитанием, то как не "делись" — все вернётся на круги своя
Классно, но, ваши проблемы с esb от того, что все хотят быть "архитекторами", а думать и за "дисциплиной" следить некому.
И с этой точки зрения "а давайте микросервисы теперь!" — ровно тоже самое что "а давайте все перепишем!", но проблемы ваши не решит.
Вы точно так же "намесите" и с микросервисами и придёте ровно к тем же проблемам (правда это случится не сразу и скорее всего ура-реформаторы успеют покинуть проект с повышением)
Что delegatecall работает с данными в контексте вызывающего контракта а не вызываемого? (но это «нормальное» поведение)
сэкономил в одном месте («а че так дорого? я на фрилансе за эти деньги 5х найму!») — заплатил в другом.
Аналогичную вещь реализовал на kotlin для departureBot.ru чтобы понимать запросы вроде "туры в Италию Испанию или Грецию в начале июня на 7-10 дней"
Не стал выкладывать т.к. парсер грамматик работает на выводе pymorphy (начальная форма + грамемы). Никто кст не знает живой аналогичной библиотеки с русским (и словарями) для jvm?
Маленький шаг для человека, огромный шаг для spring.
Сложность с rx -стилем в коде только в том, что без контроля очень легко получить "мама-смотри-какой-я-умный" лапшу в коде, причем даже на небольшом количестве строк.
И с этой точки зрения корутины котлина с синтаксическим сахаром кажутся весьма хорошим решением вместе с project reactor и spring
Все так. Но в книжках и на тренингах по "успешному успеху" обычно о таком не рассказывают (потому, что не "круто" и потому что реального опыта у тренеров и коучей часто исчезающе мало — у них просто нет истории провалов).
В сухом остатке, пожалуй, работающих стратегией остаётся только 2:
1) "проверять" модель, "пробовать" с минимальными кап вложениями +"Секси-идея" далеко не всегда по рентабельности обгонит точку по продажи шаурмы.
Если вероятность провала 0.9, то попробовав 5 раз — вероятность что все попытки буду провальными уже 0.6 ;)
2)участвовать в нескольких проектах параллельно своими связями/опытом.
github.com/alatushkin/not-so-smart-contracts/blob/master/rewrite-variable-example.sol
С такой позицией вас ждёт ещё ой как много сюрпризов и сложностей
Возможно, настоящая причина проблем в коллективе из статьи как раз в этом, а не в том, что каждый понимает одни и те же «лозунги» немного «по-своему».
Как это происходит:
1)Тимлид/ТехДир/Кто-то еще (Пусть будет Мистер М) делает ультимативным тоном спорное утверждение обильно посыпая его высокомерными ужимочками.
Обычно суть утверждения в следующем «Я Очень умный, надо делать так-то, а вы все Дебилы если со мной не согласны».
2) «Вы все» — слушают, но с такой оценкой себя они, конечно, не согласны — и начинается спор о том, чем «чьё
кунг-фуDRY круче».Последствия:
1)Когда оказывается, что М ошибся (так тоже бывает не редко) — признать это и принять решение которое было бы лучше для проекта ему мешает то заявление, в котором он назвал всех «идиотами»
2)«Вы все» — будут и дальше часть времени тратить не на то чтобы «дотащить проект», а на то чтобы найти где еще мистер М налажал
3)Эго МистераМ оплачено человеко-часами из бюджета проекта.
В чём мораль?
1)Не будьте «М». Вы не «самый умный в этой комнате».
2)Если вы нанимаете к себе в команду человека — постарайтесь убедиться что он не М.
Произойдет возврат только остатков газа. Приложенный к вызову эфир останется на счету контракта.
Этот fallback метод лучше совсем убрать. Тогда будет работать как задумано: эфир не получится отправить на баланс контракта прямым переводом.
Вопрос лишь в экономике
2)В короткие сроки перевести процесс разработки на свой overseas персонал, когда сокращение костов в 2 раза бонусом даёт еще и рост квалификации разработчиков. + общие юристы и бухгалтерия.
3)Распустить дорогих местных разработчиков, бухгалтеров, юристов.
4)…
5)PROFIT
Это гениально, черт возьми!
Удивлен, что это еще не стало повсеместным трендом среди крупных аутсорсеров