Показалось интересным, что статью разобрали сверху до низу, но никто не оспорил пункт с оплатой Java разработчика. А ведь для бизнеса это самый важный фактор. Ни строчки кода, ни рпс, ни гигабайты так не продать инвестору, как стоимость разработки. Когда у вас стартап и не известно взлетит он или как всегда, очень не хочется вбухивать бюджет в разработку энтерпрайз уровня который с сильно не нулевой вероятностью ляжет на полку. Даже если его потом попытаться продать, то себестоимость может не обрадовать.
Есть очень большое сомнение, что "отрефакторить под себя" займёт нулевое время, особено при солидном объёме кодовой базы. Опять же, что значит под себя. Разработчики в конечном итоге делают всё не для себя, а для проекта в целом.
Тогда у Вас получается закостенелая структура, в которой появляются свои риски. Когда, например, выпадает разработчик за которым была закреплена зона ответственноти, выпадает и сама зона.
Неблагодарное дело спорить с корифеями, но, как мне кажется, столь категорично устанавливать сроки в разработке неправильно. Не будет там месяца. Месяц уйдёт на то, чтобы все успели переругаться на тему как правильно называть функции (утрированно). За это время говно-код комадна уже выпустит альфу. Вообще к чему это всё. На начальном этапе фокус на чистный код и архитектуру может сыграть дурную шутку и погубить проект. Пусть это будет болью, но заниматься рефакторингом лучше уже на готовом продукте.
У меня есть другой пример. Допустим, есть идея стартапа которая должна покорить мир в ближайшем будущем. Мы набираем команду разработчиков которые профессионально подходят к своему делу, пишут документацию с первого дня, рисуют схемы, делают код-ревью, разносят код на модули и библиотеки, покрытие тестами приближается к 100%. Надеюсь ни для кого не секрет, что это всё занимает чуть больше времени чем просто реализация через спагетти-код. В итоге может получится, что когда распрекрасно-чистый код дойдёт до продакшена, идея потеряет свою актуальность. Еще может стать, что кто-то чуть менее принципиальный уже давно в проде и захватил весь рынок. К чему это всё, к тому, что в реальной жизни самурайский принцип не подходит и цель важнее пути.
Что-то вам с платёжным провайдером надо делать. Ни с одной карты платёж не проходит, а ошибка выглядит как: "что-то пошло не так". Ну не так, так не так.
Нашёл свой. Даже оказалось, что к нему есть родной чехол и стилус. С аккумом пока не разобрался, но теперь заморучусть. Если получится с дампом - обязательно солью.
Ни в коем разе не сомневаюсь в Вашей компетентности. Но всё-таки надёжность, масштабируемость и возможность востановления это всё очень субъективно. Про производительность даже не говорю. Любое приложение на железке будет производительней (может так же, но точно не хуже) чем в облаке. А уменьшение сложности управления может сыграть злую шутку, когда кухарка решит, что можно начать оптимизировать базу просто выкручивая параметры.
Преимущества те же, что и размещение любого приложения в контейнере. Изолированность среды. Данные-то всё равно в контейнер пихать не стоит. А так бегает себе движок в контейнере со своими либами, надо обновить - старый новым образом заменил и готово (конечно + миграция и т.п. ). Опять же дебажить удобно. Образ на десктоп поднял и уверен, что все либы те же. Если вопрос в прозводительности, то контейнеры её точно не прибавят.
Раббит точно такая же единая точка отказа. Особенно если нужно решать проблемы с кворумами или зеркалами. Он точно так же может упереться в сетевой стек. Причём учтите, Раббит он не сам по себе, он работает в виртуалке эрланга. Хотя я сторонник использования раббит как шину для обмена сообщениями между сервисами хотя бы потому, что он на такой обмен заточен. Отправитель кинул сообщение, получатель или получатели тут же его поймали, без необходимости опрашивать базу о новых событиях. Плюс плюшки в виде контроля трафика и политик очередей и по мелочи.
Обычно любовь к бекапам появляется сразу после инцидента, а потом со временем сходит на нет. Не без участия руководства, которое видит в бекапах только дополнительную статью расходов.
Вроде как не было замечано проблем у банков с подсчётами балансов. Мне кажется блокчейн это всё-таки про то, когда стороны друг-другу не доверяют и нужно после каждой итерации сверять данные и консилиумом решать их достоверность. Лучший пример это когда спекулянты торгуют друг с другом долговыми расписками, а в конце года подбивают баланс.
Показалось интересным, что статью разобрали сверху до низу, но никто не оспорил пункт с оплатой Java разработчика. А ведь для бизнеса это самый важный фактор. Ни строчки кода, ни рпс, ни гигабайты так не продать инвестору, как стоимость разработки. Когда у вас стартап и не известно взлетит он или как всегда, очень не хочется вбухивать бюджет в разработку энтерпрайз уровня который с сильно не нулевой вероятностью ляжет на полку. Даже если его потом попытаться продать, то себестоимость может не обрадовать.
Есть очень большое сомнение, что "отрефакторить под себя" займёт нулевое время, особено при солидном объёме кодовой базы. Опять же, что значит под себя. Разработчики в конечном итоге делают всё не для себя, а для проекта в целом.
Тогда у Вас получается закостенелая структура, в которой появляются свои риски. Когда, например, выпадает разработчик за которым была закреплена зона ответственноти, выпадает и сама зона.
Неблагодарное дело спорить с корифеями, но, как мне кажется, столь категорично устанавливать сроки в разработке неправильно. Не будет там месяца. Месяц уйдёт на то, чтобы все успели переругаться на тему как правильно называть функции (утрированно). За это время говно-код комадна уже выпустит альфу. Вообще к чему это всё. На начальном этапе фокус на чистный код и архитектуру может сыграть дурную шутку и погубить проект. Пусть это будет болью, но заниматься рефакторингом лучше уже на готовом продукте.
У меня есть другой пример. Допустим, есть идея стартапа которая должна покорить мир в ближайшем будущем. Мы набираем команду разработчиков которые профессионально подходят к своему делу, пишут документацию с первого дня, рисуют схемы, делают код-ревью, разносят код на модули и библиотеки, покрытие тестами приближается к 100%. Надеюсь ни для кого не секрет, что это всё занимает чуть больше времени чем просто реализация через спагетти-код. В итоге может получится, что когда распрекрасно-чистый код дойдёт до продакшена, идея потеряет свою актуальность. Еще может стать, что кто-то чуть менее принципиальный уже давно в проде и захватил весь рынок. К чему это всё, к тому, что в реальной жизни самурайский принцип не подходит и цель важнее пути.
Вы меня извините, конечно, но заголовок статье вообще не соответствует. Возможности раббита не ограничиваются типами обменников.
Что-то вам с платёжным провайдером надо делать. Ни с одной карты платёж не проходит, а ошибка выглядит как: "что-то пошло не так". Ну не так, так не так.
Нашёл свой. Даже оказалось, что к нему есть родной чехол и стилус. С аккумом пока не разобрался, но теперь заморучусть. Если получится с дампом - обязательно солью.
Неожиданный обзор. Привет из прошлого. У меня самого точно такой лежит в подвале, аккумулятор сдох, а от сети он не поднимается.
Ни в коем разе не сомневаюсь в Вашей компетентности. Но всё-таки надёжность, масштабируемость и возможность востановления это всё очень субъективно. Про производительность даже не говорю. Любое приложение на железке будет производительней (может так же, но точно не хуже) чем в облаке. А уменьшение сложности управления может сыграть злую шутку, когда кухарка решит, что можно начать оптимизировать базу просто выкручивая параметры.
Как насчёт бюджета? DBaaS всё-таки ощютимее дороже.
Второй абзац только я не понял?
Преимущества те же, что и размещение любого приложения в контейнере. Изолированность среды. Данные-то всё равно в контейнер пихать не стоит. А так бегает себе движок в контейнере со своими либами, надо обновить - старый новым образом заменил и готово (конечно + миграция и т.п. ). Опять же дебажить удобно. Образ на десктоп поднял и уверен, что все либы те же. Если вопрос в прозводительности, то контейнеры её точно не прибавят.
Раббит точно такая же единая точка отказа. Особенно если нужно решать проблемы с кворумами или зеркалами. Он точно так же может упереться в сетевой стек. Причём учтите, Раббит он не сам по себе, он работает в виртуалке эрланга. Хотя я сторонник использования раббит как шину для обмена сообщениями между сервисами хотя бы потому, что он на такой обмен заточен. Отправитель кинул сообщение, получатель или получатели тут же его поймали, без необходимости опрашивать базу о новых событиях. Плюс плюшки в виде контроля трафика и политик очередей и по мелочи.
Могу ошибаться, но ссылки на репозитории как раз нет. У меня ссылка ведёт на http://algorithmlll.py/
Обычно любовь к бекапам появляется сразу после инцидента, а потом со временем сходит на нет. Не без участия руководства, которое видит в бекапах только дополнительную статью расходов.
Как вариант, да.
Мне кажется если хакер найдёт уязвимость в контракте, он уже сам себя наградит.
Не появились еще рейдерские захваты dApp-ов? Там делов-то отжать приватный ключ и банк твой.
Вроде как не было замечано проблем у банков с подсчётами балансов. Мне кажется блокчейн это всё-таки про то, когда стороны друг-другу не доверяют и нужно после каждой итерации сверять данные и консилиумом решать их достоверность. Лучший пример это когда спекулянты торгуют друг с другом долговыми расписками, а в конце года подбивают баланс.