Выглядит так что основной причиной использовать микросервисы в данном случае послужило то, что на проект ресурсы были выделены "на сдачу": с разными "стекам" и пришлось как то "выкручиваться".
Те же задачи что упоминаются в сценарии в тексте статьи — могут быть с тем же успехом решены с помощью VR «для бедных»: телефон в пластиковой корбке на голове. Причем, некоторые даже «в браузере» (Three,Babylon,libgdx).
А когда, через несколько лет экраны «4К» (с высокой плотностью пикселей) станут в телефонах более распространены — дело пойдет еще веселее.
Просто с «реальными» задачами, где была бы в этом насущная необходимость и понятный ROI — туго пока. Все в поиске.
И поиск осложняется тем, что эти очки — сами по себе мало полезны — пользу они могут принести только как компонент какой-то информационной системы.
Например если бы эти очки стоили бы «копейки», то ими можно было бы оснащать, например, инженеров обслуживающих сложные технически объекты вроде, атомных и прочих эс, атомных ледоколов, всяких буровых установок, больших телекоммуникационных узлов: там как правило уже есть свои ИС с которыми это всё можно было бы интегрировать.
В купе с голосовыми командами и электронным ассистентом -это повысило бы производительность труда таких работников: любые нужные статусы перед глазами, включение-отключение по команде, диагностические карты/последовательности, история операций, заявки на замену — тысячи мелочей которые выливаются в человеко-часы. Выше производительность — меньше людей и меньше ФОТ. + Глубокое внедрение снизит требования к квалификации обслуживающих инженеров: машина(или более опытный супервайзер в канале) будет подсказывать что делать: снова снижение ФОТ.
Кстати, хотел спросить:
У вас в подписи TypeScript developer
Почему решили делать всё не на одном «языке» (и фронт и бэк на js/ts) и переиспользовать общую логику, а а решили собирать букет из разных технологий?
Альтернативный вариант — вместо Digital Ocean — посмотрите в сторону INFURA
+Для игры наверно не важно, а в остальном — ноды не всегда стабильно работают, поэтому про мониторинг и избыточность стоит помнить.
Это что-то «кармическое»)
«Технически» да — POW от POS от POA, в крупную клетку, отличается только тем кто именно может участвовать в формировании очередного блока.
Но тут вопрос больше психологии и экономики. Пока решения только такие: максимально-децентрализовано, но очень большие издержки, либо ближе к реальности и удобнее пользоваться, но не такие яркие заголовки в СМИ.
И предположу, что массовыми всё же станут более централизованные системы. (И судя по дрифту от POW к POS/POA авторы решений тоже это понимают).
Если, конечно, не найдется принципиально нового решения, которое сбалансировало бы интересы всех участников более «экономным» способом.
Точнее «не доверять друг другу»)
Не доверять друг-другу «по-другому» можно. Зависит от того сколько именно «недоверия» нам нужно и сколько его мы готовы оплатить.
Больше децентрализации — выше «налог» на недоверие)
Если представить себе «шкалу недоверия» на одном конце которой расположено «абсолютное недоверия» (те самые популярные лозунги «децентрализация»,«анонимность» и прочая анархия), а на другом — «централизация», и разместим на ней все существующие решения, то увидим, что у нас есть
Решения на основе POA(Proof-of-Work) — максимальное недоверие, большие комиссии, большая ресурсоемкость.Эфир, Биткоин и прочее такое.
Решения на основе POA (Proof-of-Authority) — доверие «арбитру». Система при которой есть «главные» узлы, которые проводят транзакции и все остальные желающие — наблюдатели. Полная централизация, низкие комиссии, высокая пропускная способность, Ripple, Visa и т.д.
И Proof-of-Stake — POS — где-то по средине шкалы.
Название «Экономия газа в смарт-контрактах Ethereum» наталкивает на мысль, что статья будет об экономии газа при работе контракта.
Ну а по сути вопроса:
О чем стоит помнить:
1)Экономить на газе можно создавая новые экземпляры контракта из уже загруженного байт-кода. И/или используя в контракте байткод библиотек уже загруженных в эфир. Но тут главное, чтобы не получилось как с Parity
2)Стараться не усложнять. За «грамотное ООП» придется платить.
3)Подумать о том чтобы больше вынести оффчейн. В конечном итоге, когда кто-то с вами вступает в отношения с использованием контракта — скорее всего без действий с вашей стороны всё-равно работать не будет, а значит и офчейн вполне может быть подходящим решением.
4)Чем больше для выполнения метода контракта потребуется газа — тем выше будет gas price. Дело в том что у каждого блока в блокчейне есть лимит газа и как следствие то количество операций которое может быть выполнено. А значит если для выполнения метода вам требуется 10% всего газа блока, то в условии высокой конкуренции (как с недавними криптокотиками, например) — чтобы получить такое количество газа — придется заплатить за него дороже чем участникам с менее прожорливыми транзакциями
Ну тут всё не так однозначно ведь:
В крупную клетку: проблема мобильных операторов в том что они несут огромные капитальные затраты на создание инфраструктуры, а «сливки» с нее снимают «другие».
Ну т.е. вот мы хотим чтобы был хороший быстрый 4G интернет на мобильнике за 200р/мес, чтобы мы могли потреблять тяжелый контент (видео и прочее вот это вот всё), используя инфраструктуру оператора, а основные деньги на нас при этом зарабатывает «производитель контента».
Что в такой ситуации делать? Как показывать рентабельность и где искать деньги на то чтобы развиваться дальше? Ведь технологии не дешевеют.
Вот и ищут «пути». Наш потребительский профиль успешно малому бизнесу продают соц-сети и поисковики, так что ОПСОСам туда сложно войти, но вот — нашли аналогичную нишу — с банками. Кредитный скоринг и вот это вот всё.
Но поиски, конечно же продолжаются.
В своем боте-турагенте с горящими турами/билетами тоже использовал распознавание речи (жизнь слишком коротка чтобы заставлять человека руками набивать «тур на море в конце февраля на 7-10 дней до 25 тысяч»), но в итоге остановился на сервисе от гугла, хотя и с ним были сложности: голосовые сообщения из телеграмма обрабатывались как надо, а вот из ВК — пришлось менять sampling rate.
«Альфа-Банк заменил старый монолитный интернет-банк для бизнеса на удобную систему микросервисов.»
«монолит/микросеврвисы» — это всё категории технической моды.
Не «монолит» причина слабого продукта.
Хорошая статья для начинающих, но хотелось бы обратить внимание будущих разработчиков смарт-контрактов на документацию Solidity.
В частности Security Considerations
Там приведена частая ошибка, которая встречается и здесь:
if (p.currentResult > 0) { // если большинство проголосовало “за”
require ( p.recipient.send(p.amount) ); // отправить эфир получателю
p.proposalPassed = true; // пометить, что предложение одобрено
если злоумышленник сможет внести своё «предложение» адресом получателя у которого будет «контракт» контролируемый им, с помощью соц. инженерии добиться принятия своего предложения, то в контракте-получателе платежа может быть код, который в момент получения денег снова вызовет executeProposal(uint _proposalNumber), который пришлет еще немного денег и снова вызовет сам себя и так до тех пор пока не выгребет весь банк либо не закончится gas на транзакцию. А т.к. транзакция откатится — можно будет вызвать метод снова и забрать то, что не забрал, т.к. p.proposalPassed = true; не вызовется
Так же стоит помнить, что глубина стека в EVM ограничена и злоумышленник может вызвать ваш метод таким образом, что вы не сможете пойти «глубже». Иногда это тоже может иметь значение.
А в остальном — всем удачных контрактов)
И помните про цену размещения мегабайта данных в блокчейне эфира
Выглядит так что основной причиной использовать микросервисы в данном случае послужило то, что на проект ресурсы были выделены "на сдачу": с разными "стекам" и пришлось как то "выкручиваться".
Те же задачи что упоминаются в сценарии в тексте статьи — могут быть с тем же успехом решены с помощью VR «для бедных»: телефон в пластиковой корбке на голове. Причем, некоторые даже «в браузере» (Three,Babylon,libgdx).
А когда, через несколько лет экраны «4К» (с высокой плотностью пикселей) станут в телефонах более распространены — дело пойдет еще веселее.
Просто с «реальными» задачами, где была бы в этом насущная необходимость и понятный ROI — туго пока. Все в поиске.
И поиск осложняется тем, что эти очки — сами по себе мало полезны — пользу они могут принести только как компонент какой-то информационной системы.
Например если бы эти очки стоили бы «копейки», то ими можно было бы оснащать, например, инженеров обслуживающих сложные технически объекты вроде, атомных и прочих эс, атомных ледоколов, всяких буровых установок, больших телекоммуникационных узлов: там как правило уже есть свои ИС с которыми это всё можно было бы интегрировать.
В купе с голосовыми командами и электронным ассистентом -это повысило бы производительность труда таких работников: любые нужные статусы перед глазами, включение-отключение по команде, диагностические карты/последовательности, история операций, заявки на замену — тысячи мелочей которые выливаются в человеко-часы. Выше производительность — меньше людей и меньше ФОТ. + Глубокое внедрение снизит требования к квалификации обслуживающих инженеров: машина(или более опытный супервайзер в канале) будет подсказывать что делать: снова снижение ФОТ.
У вас в подписи TypeScript developer
Почему решили делать всё не на одном «языке» (и фронт и бэк на js/ts) и переиспользовать общую логику, а а решили собирать букет из разных технологий?
+Для игры наверно не важно, а в остальном — ноды не всегда стабильно работают, поэтому про мониторинг и избыточность стоит помнить.
«Технически» да — POW от POS от POA, в крупную клетку, отличается только тем кто именно может участвовать в формировании очередного блока.
Но тут вопрос больше психологии и экономики. Пока решения только такие: максимально-децентрализовано, но очень большие издержки, либо ближе к реальности и удобнее пользоваться, но не такие яркие заголовки в СМИ.
И предположу, что массовыми всё же станут более централизованные системы. (И судя по дрифту от POW к POS/POA авторы решений тоже это понимают).
Если, конечно, не найдется принципиально нового решения, которое сбалансировало бы интересы всех участников более «экономным» способом.
Точнее «не доверять друг другу»)
Не доверять друг-другу «по-другому» можно. Зависит от того сколько именно «недоверия» нам нужно и сколько его мы готовы оплатить.
Больше децентрализации — выше «налог» на недоверие)
Если представить себе «шкалу недоверия» на одном конце которой расположено «абсолютное недоверия» (те самые популярные лозунги «децентрализация»,«анонимность» и прочая анархия), а на другом — «централизация», и разместим на ней все существующие решения, то увидим, что у нас есть
Решения на основе POA(Proof-of-Work) — максимальное недоверие, большие комиссии, большая ресурсоемкость.Эфир, Биткоин и прочее такое.
Решения на основе POA (Proof-of-Authority) — доверие «арбитру». Система при которой есть «главные» узлы, которые проводят транзакции и все остальные желающие — наблюдатели. Полная централизация, низкие комиссии, высокая пропускная способность, Ripple, Visa и т.д.
И Proof-of-Stake — POS — где-то по средине шкалы.
Ну а по сути вопроса:
О чем стоит помнить:
1)Экономить на газе можно создавая новые экземпляры контракта из уже загруженного байт-кода. И/или используя в контракте байткод библиотек уже загруженных в эфир. Но тут главное, чтобы не получилось как с Parity
2)Стараться не усложнять. За «грамотное ООП» придется платить.
3)Подумать о том чтобы больше вынести оффчейн. В конечном итоге, когда кто-то с вами вступает в отношения с использованием контракта — скорее всего без действий с вашей стороны всё-равно работать не будет, а значит и офчейн вполне может быть подходящим решением.
4)Чем больше для выполнения метода контракта потребуется газа — тем выше будет gas price. Дело в том что у каждого блока в блокчейне есть лимит газа и как следствие то количество операций которое может быть выполнено. А значит если для выполнения метода вам требуется 10% всего газа блока, то в условии высокой конкуренции (как с недавними криптокотиками, например) — чтобы получить такое количество газа — придется заплатить за него дороже чем участникам с менее прожорливыми транзакциями
В крупную клетку: проблема мобильных операторов в том что они несут огромные капитальные затраты на создание инфраструктуры, а «сливки» с нее снимают «другие».
Ну т.е. вот мы хотим чтобы был хороший быстрый 4G интернет на мобильнике за 200р/мес, чтобы мы могли потреблять тяжелый контент (видео и прочее вот это вот всё), используя инфраструктуру оператора, а основные деньги на нас при этом зарабатывает «производитель контента».
Что в такой ситуации делать? Как показывать рентабельность и где искать деньги на то чтобы развиваться дальше? Ведь технологии не дешевеют.
Вот и ищут «пути». Наш потребительский профиль успешно малому бизнесу продают соц-сети и поисковики, так что ОПСОСам туда сложно войти, но вот — нашли аналогичную нишу — с банками. Кредитный скоринг и вот это вот всё.
Но поиски, конечно же продолжаются.
t.me/departureBot
vk.me/departureBot
На подходе следующая версия. Менее многослованя
«монолит/микросеврвисы» — это всё категории технической моды.
Не «монолит» причина слабого продукта.
В частности Security Considerations
Там приведена частая ошибка, которая встречается и здесь:
если злоумышленник сможет внести своё «предложение» адресом получателя у которого будет «контракт» контролируемый им, с помощью соц. инженерии добиться принятия своего предложения, то в контракте-получателе платежа может быть код, который в момент получения денег снова вызовет executeProposal(uint _proposalNumber), который пришлет еще немного денег и снова вызовет сам себя и так до тех пор пока не выгребет весь банк либо не закончится gas на транзакцию. А т.к. транзакция откатится — можно будет вызвать метод снова и забрать то, что не забрал, т.к. p.proposalPassed = true; не вызовется
Так же стоит помнить, что глубина стека в EVM ограничена и злоумышленник может вызвать ваш метод таким образом, что вы не сможете пойти «глубже». Иногда это тоже может иметь значение.
А в остальном — всем удачных контрактов)
И помните про цену размещения мегабайта данных в блокчейне эфира