Есть предположение, что например архитектуры городов существуют, а архитектуры предприятий не очень, из-за того, что разнообразие городов не очень разнообразное. Вот тут жители живут, вот здесь отдыхают, вот здесь работают, вот здесь дороги, вот здесь трубы, провода, и т.д. А предприятия существенно разнообразнее. Коммерческие, некоммерческие, государственные, производственные, научные, и т.д.
И предприятия меняются быстрее, чем города. Помогла бы Kodak, Nokia или Sun его архитектура предприятия? Была бы эта архитектура актуальной?
В целом по agile в бизнесе.
Да, вот такой вот он agile. Нужно меняться быстро, и с управляемым качеством.
И интерфейс, и прочее оцениваются не через метрики, обычно применяемые к интерфейсам, а через бизнес-метрики. Сколько активных клиентов было, сколько стало. Сколько платежек в месяц генерировалось, сколько стало. Сколько затрачивается времени на одну платежку. и прочее.
Если розовая кнопочка, увеличивает какой-либо бизнес показатель, ее сделают розовой, даже если это противоречит всем канонам дизайна.
И так во всем.
Монолит/микросервис? Не важно. Важно, как быстро ты можешь адаптироваться под новые условия с контролируемым качеством. Если сможешь в монолите, вперед, развивай монолит. Всем клиентам пофиг монолит/микросервис.
UI-автотесты хрупки, но когда у вас ui оптимизируют под разные устройства, например больше 3. И оптимизируя под одно устройство, легко сломать под другое в неочевидном месте. То жить с этим можно только с UI автотестами.
Тут выше упоминался банк.
Представьте, что вы банк. Какой стратегический план вы ожидаете для банка?
Что в нем должно быть такого, чего нет у других?
Уже известно, что клиенты хотят пользоваться сервисами банка через мобилки.
Клиенты хотят сервисы банка 24/7.
Клиенты хотят безопасности и простоты.
Как эти постулаты из стратегического плана помогут в разработке и внедрении конкретного кредита или депозита? Или приложения?
Мир меняется стремительнее, чем некоторое время назад. Стратегический план предполагает планирование на срок более 3 лет. Сейчас за 3 года меняется все насколько сильно, что все что ты напланировал 3 года назад, сегодня уже просто вызывает смех.
Если я вас не убедил.
Попытайтесль нагуглить стратегический план того же Гугла, или приснопамятного Амазона, Алиэкспресса, и т.д.
Если убедил, то возникает вопрос, а как развиваться, в условиях неопределенности. И вот тут ответ. Развивайтесь итеративно (agile style), следуя вашим ценностями (только ценности остаются долгосрочными).
Software vs Hardware (в самом широком смысле и Software, и Hardware)
В чем их главное отличие?
Software (soft) — нечто мягкое, виртуальное, неосязаемое. Внести изменения в Software, и получить обратную связь можно очень быстро.
Поменять что-то в Hardware — существенно дольше, и обычно дороже.
На этом строится разница в подходах развития. В Software просто реализуем и смотрим результат. В Hardware предварительно оцениваем, и пытаемся понять косвенно, идея стоящая или нет.
Сухой итог. Да, 9-этажку нельзя построить мелкими итерациями — построили первый этаж, заселились, начали строить 2-й, заселились и т.д.
А вот какое-нибудь приложение выпускать в production мелкими итерациями — запросто.
автомобили стали идти в массы, когда началась массовая урбанизация, и люди захотели передвигаться самостоятельно и быстро, но при этом не париться с уходом за лошадьми, вышел из дома — сел и поехал, приехал домой — вышел из автомобиля и забыл про него до следующего утра.
тем не менее, вопрос про реальные кейсы с эфиром и контрактами я задал без всякой подоплеки, чисто прагматично. где используется и проявил себя?
как тот же эфириум с его смарт-контрактами, на которых можно добавить монетизацию или обеспечить распределенный консенсус для процессов многих других распределенных систем
Можете привести реальные кейсы, которые отлично решает эфир с контрактами?
А то, то что приводится в качестве примера, обычно из разряда — решение проблемы, которая уже давно решена, но мы ее решили сделать на эфире с контрактами; почему? а потому что можем…
Честно говоря, странный подход, мерить время старта сервера приложений.
В каких реальных кейсах в проме это может быть важнее, чем прочие критерии (время отклика, потребление cpu, ram, io, и т.д.)
ДрВеб, Касперски, сам Майкрософт и т.д. защищают нужные файлы ровно до тех пор пока не загрузились в режим ядра. Соответственно любая такая защита, это защита от дурака. От опытного пользователя с неблагими намерениями она никак не защищает.
По моему очевидно, хочешь безопасно — ограничь права.
Как-то странно ожидать безопасности, от пользователя с изначально неблагими намерениями, обладающего правами администратора/рута.
Представьте, у вас все артефакты лежат в репозитариях, все покрыто тестами, вся инфраструктура управляется специальными cfg mgnt тулами, со всего собираются и анализируются логи, и все это завернуто в единый pipeline. И для вас ценно, что изменения не пушатся напрямую в основной код, а ревьюются человеком. Из-за этого у вас не кошерный CI/CD, а какой-то рафинированный? И кошерным он станет, тогда и только тогда, когда всем будет дадено разрешение пушить напрямую?
CI/CD — про управляемый повторяемый способ контроля качества и доставки изменений. Не про модель контроля версий.
Для меня тоже неясно в чем плюсы/минусы по сравнению с существующими подходами.
Что я услышал: есть некие компоненты, которые разворачиваются у участников, эти компоненты общаются между собой, есть эцп и прочее, чтобы в случае чего, можно было в суде решать спорные ситуации.
И чем это принципиально отличается от существующих подходов?
Ниже упоминают, что если участников будет несколько сот тысяч. Но новое решение не предназначено для сотен тысяч. Там участники обмениваются публичными ключами, и контрактами.
Опять же ниже упоминают про ускорение. Но за счет чего происходит ускорение? И почему этого ускорения нет при традиционных подходах?
И предприятия меняются быстрее, чем города. Помогла бы Kodak, Nokia или Sun его архитектура предприятия? Была бы эта архитектура актуальной?
Да, вот такой вот он agile. Нужно меняться быстро, и с управляемым качеством.
И интерфейс, и прочее оцениваются не через метрики, обычно применяемые к интерфейсам, а через бизнес-метрики. Сколько активных клиентов было, сколько стало. Сколько платежек в месяц генерировалось, сколько стало. Сколько затрачивается времени на одну платежку. и прочее.
Если розовая кнопочка, увеличивает какой-либо бизнес показатель, ее сделают розовой, даже если это противоречит всем канонам дизайна.
И так во всем.
Монолит/микросервис? Не важно. Важно, как быстро ты можешь адаптироваться под новые условия с контролируемым качеством. Если сможешь в монолите, вперед, развивай монолит. Всем клиентам пофиг монолит/микросервис.
Представьте, что вы банк. Какой стратегический план вы ожидаете для банка?
Что в нем должно быть такого, чего нет у других?
Уже известно, что клиенты хотят пользоваться сервисами банка через мобилки.
Клиенты хотят сервисы банка 24/7.
Клиенты хотят безопасности и простоты.
Как эти постулаты из стратегического плана помогут в разработке и внедрении конкретного кредита или депозита? Или приложения?
Мир меняется стремительнее, чем некоторое время назад. Стратегический план предполагает планирование на срок более 3 лет. Сейчас за 3 года меняется все насколько сильно, что все что ты напланировал 3 года назад, сегодня уже просто вызывает смех.
Если я вас не убедил.
Попытайтесль нагуглить стратегический план того же Гугла, или приснопамятного Амазона, Алиэкспресса, и т.д.
Если убедил, то возникает вопрос, а как развиваться, в условиях неопределенности. И вот тут ответ. Развивайтесь итеративно (agile style), следуя вашим ценностями (только ценности остаются долгосрочными).
В чем их главное отличие?
Software (soft) — нечто мягкое, виртуальное, неосязаемое. Внести изменения в Software, и получить обратную связь можно очень быстро.
Поменять что-то в Hardware — существенно дольше, и обычно дороже.
На этом строится разница в подходах развития. В Software просто реализуем и смотрим результат. В Hardware предварительно оцениваем, и пытаемся понять косвенно, идея стоящая или нет.
Сухой итог. Да, 9-этажку нельзя построить мелкими итерациями — построили первый этаж, заселились, начали строить 2-й, заселились и т.д.
А вот какое-нибудь приложение выпускать в production мелкими итерациями — запросто.
тем не менее, вопрос про реальные кейсы с эфиром и контрактами я задал без всякой подоплеки, чисто прагматично. где используется и проявил себя?
Можете привести реальные кейсы, которые отлично решает эфир с контрактами?
А то, то что приводится в качестве примера, обычно из разряда — решение проблемы, которая уже давно решена, но мы ее решили сделать на эфире с контрактами; почему? а потому что можем…
В каких реальных кейсах в проме это может быть важнее, чем прочие критерии (время отклика, потребление cpu, ram, io, и т.д.)
Как-то странно ожидать безопасности, от пользователя с изначально неблагими намерениями, обладающего правами администратора/рута.
Только насчет этого, скорее всего неверно.
Стержни большие и тяжелые. Да, наверно они уменьшаются в весе на 45 грамм в сутки. Но доставлять стержень самолетом?
вы пытаетесь заставить пчел выступать против меда. пчелам очевидно нравится мед
CI/CD — про управляемый повторяемый способ контроля качества и доставки изменений. Не про модель контроля версий.
Он видит все уже существующие сделки? И будет видеть все будущие сделки?
Что я услышал: есть некие компоненты, которые разворачиваются у участников, эти компоненты общаются между собой, есть эцп и прочее, чтобы в случае чего, можно было в суде решать спорные ситуации.
И чем это принципиально отличается от существующих подходов?
Ниже упоминают, что если участников будет несколько сот тысяч. Но новое решение не предназначено для сотен тысяч. Там участники обмениваются публичными ключами, и контрактами.
Опять же ниже упоминают про ускорение. Но за счет чего происходит ускорение? И почему этого ускорения нет при традиционных подходах?