Например, ставку 1.4% может дать только Сбербанк – и она будет ниже себестоимости. Вообще, Сбербанк зачастую работает в минус по эквайрингу, т.е. если бы банк отдал эквайринг, например, в Альфа-Банк, то на interchange Сбер зарабатывал бы больше.
Вопрос, зачем Сберу эквайринг ниже себестоимости, примерно такой же, как, зачем Гуглу поисковый сервис предоставлять бесплатно.
Общий ответ, потому что зарабатывают на экосистеме в целом, а не конкретной этой услуге.
Сможет ли Питон прожевать миллион запросов в секунду?
и
Japronto практически полностью написан на Си. Парсер, протокол, connection reaper, маршрутизатор, request- и response-объекты реализованы в виде расширений на Си.
Results suggest that the industry was a net consumer of electricity as recently as 2010. However, there is a >50% that in 2012 the PV industry is a net electricity provider and will “pay back” the electrical energy required for its early growth before 2020.
Я предполагал, что доказательства эффективности должны быть более научными.
Вот панель, на ее изготовление условный ФотоПромМаш потратил x Вт. Ее поставили в пустыне Атакама, и она за два года произвела y Вт. За это время ее деградация в производстве энергии составила z%. Поэтому ожидается что до момента полной деградации панель произведет yy Вт. Что в итоге будет больше чем x.
Идея потенциально интересна не как автоматизация своих рутинных действий, а как набор популярных публично доступных плагинов, устанавливаемых одной командой, и выполняющих что-то полезное для многих. Как раз то что делает rake.
Что работает и что не работает — зависит от целевой аудитории.
Т.к. целевая аудитория у всех разная, заранее сказать, что вот это работает лучше того, можно нечасто. Иначе любой бизнес был бы просто набором инструкций к действию — следуешь инструкции, зарабатываешь.
Важно — правильно собирать статистику, правильно ее анализировать и делать правильные выводы.
А повелительное наклонение, или призыв к действию, это всего лишь подходы, которые в одних условиях работают, в других нет.
Не могли бы Вы пояснить, по какому критерию определяется, что нужно написать и куда, что в первую очередь. Повертел мысль и так и эдок и не понял, как связан FCR с базой знаний. Например, написал человек с вопросом, ответ на который содержится в документации на первой же странице. Вопрос был закрыт одним ответом публикацией ссылки на эту страницу.
Наличие документации совершенно не означает, что вопросов не будет.
Если вопросы задаются, даже при наличии документации, это значит:
— документацию почему-то не могут найти. нужно придумать, как сделать ее легко доступной.
— либо документация неполна, неточна, и прочее не. нужно ее исправить, актуализировать.
— либо документация описана так, что понимается не так, как должна. нужно переформулировать, перефразировать, по другому структурировать.
— либо функционал устроен так, что вводит в заблуждение. надо переделать функционал.
Т.е. в идеале FCR показывает, что что-то решается очевидным способом, но почему-то это неочевидно с первого раза.
Все зависит от сложности логики в конкретной организации на стороне юрлиц и физлиц.
Если акцент на юриков, может получиться, что проще отнаследоваться от юрлица, и недостающее откопипастить с физиков.
Да, есть еще traits. Но и они не панацея.
И у наследования ИП от физика свои минусы. Насколько я понимаю, при наследовании от физлица, запись по ИП содержит только уникальные для ИП атрибуты, а фио и прочее на физике.
Как с точки зрения БД отличить покупку Васи от покупки ИП Васи? На сущности Покупка у атрибута Покупатель будет одиковый ID в обоих случаях.
У каждого свои плюсы, минусы. Упомянутые принципы ортогональны к микросервисам или монолитам. Просто подходы к обеспечению целостности наряду с традиционным ACID.
Когда ваша ОС стоит в куче мегакорпораций, и мегакорпорации заносят к тебе кучу бабла, и какой-нибудь supercalc.exe перестает работать, то с этим что-то надо делать.
Микросервисы, как и прочие технологии, не серебрянная пуля. Это все лишь инструмент для решения определенного класса задач.
Как и с любым инструментом, микросервисы нужно уметь правильно готовить. Не в смысле взял докер, разделил базы, выставил api в виде rest, etc. А в смысле, правильно оцениваешь риски и выгоды, и распределяешь их в оптимальном сочетании.
При «умелом подходе» на микросервисах запросто можно сваять известную коричневую органическую массу.
Точно так же как и при использовании монолита.
Верно и обратное, с головой можно качественно ваять и на микросервисах, и на монолите.
Главное преимущество микросервисов перед монолитами — собственно говоря почему про микросервисы говорят из каждой кофеварки — микросервисы лучше чувствуют себя в cloud.
Забудьте про ИТ. Представьте, вы градоначальник. Вам нужно построить стадион, или нетривиальную развязку. И вот вам представляют проект, и Архитектор что-то бубнит себе под нос, показывает разные умные, но совершенно непонятные схемы.
Может он и хороший Архитектор чисто с технической стороны, но вы то не строитель, и вам умные схемы и бубнеж не нужны.
Да, умение понятно объяснять сложные вещи, возможно не самое ключевое свойство архитектора. Но точно не последнее.
Вопрос, зачем Сберу эквайринг ниже себестоимости, примерно такой же, как, зачем Гуглу поисковый сервис предоставлять бесплатно.
Общий ответ, потому что зарабатывают на экосистеме в целом, а не конкретной этой услуге.
и
как-то не коррелируют между собой.
http://pubs.acs.org/doi/abs/10.1021/es3038824
Я предполагал, что доказательства эффективности должны быть более научными.
Вот панель, на ее изготовление условный ФотоПромМаш потратил x Вт. Ее поставили в пустыне Атакама, и она за два года произвела y Вт. За это время ее деградация в производстве энергии составила z%. Поэтому ожидается что до момента полной деградации панель произведет yy Вт. Что в итоге будет больше чем x.
Т.к. целевая аудитория у всех разная, заранее сказать, что вот это работает лучше того, можно нечасто. Иначе любой бизнес был бы просто набором инструкций к действию — следуешь инструкции, зарабатываешь.
Важно — правильно собирать статистику, правильно ее анализировать и делать правильные выводы.
А повелительное наклонение, или призыв к действию, это всего лишь подходы, которые в одних условиях работают, в других нет.
Наличие документации совершенно не означает, что вопросов не будет.
Если вопросы задаются, даже при наличии документации, это значит:
— документацию почему-то не могут найти. нужно придумать, как сделать ее легко доступной.
— либо документация неполна, неточна, и прочее не. нужно ее исправить, актуализировать.
— либо документация описана так, что понимается не так, как должна. нужно переформулировать, перефразировать, по другому структурировать.
— либо функционал устроен так, что вводит в заблуждение. надо переделать функционал.
Т.е. в идеале FCR показывает, что что-то решается очевидным способом, но почему-то это неочевидно с первого раза.
Затраты энергии на производство солнечной панели уже стали меньше выработки энергии от этой же самой панели за срок ее эксплуатации?
Если акцент на юриков, может получиться, что проще отнаследоваться от юрлица, и недостающее откопипастить с физиков.
Да, есть еще traits. Но и они не панацея.
И у наследования ИП от физика свои минусы. Насколько я понимаю, при наследовании от физлица, запись по ИП содержит только уникальные для ИП атрибуты, а фио и прочее на физике.
Как с точки зрения БД отличить покупку Васи от покупки ИП Васи? На сущности Покупка у атрибута Покупатель будет одиковый ID в обоих случаях.
Во второй части, с tpt, обойдены вниманием юрлица иностранных государств, физлица иностранных государств, граждане с видом на жительство…
— 2 phase commit
— eventual consistency
У каждого свои плюсы, минусы. Упомянутые принципы ортогональны к микросервисам или монолитам. Просто подходы к обеспечению целостности наряду с традиционным ACID.
Чтобы не править xml руками, можно использовать Job DSL и/или Pipeline
Будет выглядеть как-то так
Плюсы — наглядность конфигов
Минусы — для нетривиальных случаев надо знать особенности Groovy
Так Председатель Совета Директоров или Правления?
Как и с любым инструментом, микросервисы нужно уметь правильно готовить. Не в смысле взял докер, разделил базы, выставил api в виде rest, etc. А в смысле, правильно оцениваешь риски и выгоды, и распределяешь их в оптимальном сочетании.
При «умелом подходе» на микросервисах запросто можно сваять известную коричневую органическую массу.
Точно так же как и при использовании монолита.
Верно и обратное, с головой можно качественно ваять и на микросервисах, и на монолите.
Главное преимущество микросервисов перед монолитами — собственно говоря почему про микросервисы говорят из каждой кофеварки — микросервисы лучше чувствуют себя в cloud.
У Трелло другой рынок. Атлассиан вложились в расширение бизнеса.
Джира и Трелло для разных клиентов.
Точно также как они вкладывались в Hipchat, Bitbucket, Confluence, Fisheye, etc. Каждая из их покупок — это расширение бизнеса.
Может он и хороший Архитектор чисто с технической стороны, но вы то не строитель, и вам умные схемы и бубнеж не нужны.
Да, умение понятно объяснять сложные вещи, возможно не самое ключевое свойство архитектора. Но точно не последнее.