разработка прямо в облаке, без деплоя — проблема деплоя решена — его вообще нет
компиляция происходит прямо на серверах платформы, изменения кода сразу же после сохранения скрипта отражаются на результатах работы
Вот это я бы расценивал как недостаток.
Выделенная фаза деплоя позволяет контролиовать изменения попадающие в продакшн и защищает от соблазна поправить побырому без тестирования.
Видимо, не достаточно подробно.
Здесь производитель БД должен сам написать решение для данной задачи с использованием своего продукта. Если постгри на это не способен, значит для серьезных решений база пока не совсем готова. Да, у опенсорса с этим бедулька, но что поделать?
Затем, что это не синтетические тесты. Эти тесты — признанный эталон производительности уже лет 15, где там пострги и почему вы о них не знаете, если рассуждаете о производительности БД?
Понимаю, «рабинович насвистел».
Вы даже представить себе не можете, насколько изящно решение MS с tempdb. И таки да, это честная мультиверсионность, которая, помимо всего прочего, строже в плане некоторых аномалий чем то что реализовано в Оракле и Постгри.
По данным на 2008, если я правильно помню. Российских IT компаний около 900-950 всего, включая веб-студии. Компаний занимающихся разработкой коробок примерно 100-150.
У WCF есть проблемы со скоростью, просто потому что WCF написана поверх тех же самых сокетов, и основная ее цель предоставить более простую абстракцию, и чуть ли не все сдалть через GUI.
Ого! =)
1. не более простую, а более универсальную. Задача проста — передать данные от одного процесса к другому и обратно, все остальное — транспорт, транзакционность, контракт, прочие условия — детали реализации, которые можно собрать как из кирпичиков под текущую задачу. Это не просто, зато очень гибко.
2. GUI тут вообще не причем, в WCF через GUI не делается ничего :)
Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
Как минимум не отстанет. :) Расходы на сериализацию/десериализацию — минимальны, там весь код эммитится (или LWCG если быть точным, в зависимости от сериализатора), других накладных расходов нет. Чтобы угнаться, придется каждый объект в ручную сериализовать или тоже какой кодогенератор использовать.
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
Так и ваш код тоже будет поверх него. :)
Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
Для доступа из других языков есть стандартые протоколы, зачем еще один?
… может быть у кого то будет сценарий, когда мой пример пригодится.
Вот и хотелось бы понять, что это за сценарии.
Может коллеги просто готовить его не умеют? Со скоростью у WCF все прекрасно, я проверял.
В десятки раз лучше — это не религиозность, я очень хорошо себе представляю во что может обойтись написание клиент-серверного взаимодействия с поддержкой двунаправленности, гарантии доставки, отсутствия дубликатов, смены транспорта, и прочей фигни которая еще может понадобится.
> Всякие SOAP'ы, REST'ы и HTTP идут лесом когда вам нужно выжать максимум скорости.
У WCF нет проблем со скоростью. Транспорт можно выбрать любой, SOAP и REST это только протоколы, как раз и облегчающие кроссплатформенное взаимодействие между сервером и клиентом.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Ага, представил… =)) В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт. А дальше все зависит от того, что это за БД, для каких целей и как будет использоваться — если это общая база, клиенты к которой могут быть где угодно, то REST как раз для этих задач и создавался.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Вот люди мучаются, разрабатывают стандарты, спецификации, протоколы, придумывают всякие SOAP-ы, REST-ы… Но это все не для нас, нам все равно, что под .Net есть WCF, который реализует все это в десятки раз лучше, чем мы когда-либо напишим в ручную…
Нет, мы полезем ковыряться в сокеты, с помощю новомодного инструмента, написанного от безысходности и совсем для другого, и нас не остановит отсутствие документации, нам просто лень прочитать что такое WCF и хорошенько изучить как такие вещи делаются в .Net
=))))
«но встречал упоминания что ...» — это кто писал?
Кто в чем документы готовил — отношения к делу не имеет, я тоже не вчера клавиатуру в первый раз увидел.
Прекрасно… =) Тема падения майкрософт — раскрыта. :)
А между тем Оззи ушел в целом по делу. Основная причина ухода, и в СМИ об этом неоднократно упоминалось — конфликт с Синофски. Оззи, вместе с Алчином, выпускал Висту, Синофски выпускал семерку. Результат можете оценить сами — при Синофски стало меньше болтологии и больше дела. Так что этот уход, на мой взгляд, вполне закономерен и пойдет скорее на пользу MS.
P. S.
По слухам, когда Синофски стал управлять выпуском операционки, он разогнал больше половины менеджеров, а оставшихся заставил заниматья делом — результат налицо.
компиляция происходит прямо на серверах платформы, изменения кода сразу же после сохранения скрипта отражаются на результатах работы
Вот это я бы расценивал как недостаток.
Выделенная фаза деплоя позволяет контролиовать изменения попадающие в продакшн и защищает от соблазна поправить побырому без тестирования.
Здесь производитель БД должен сам написать решение для данной задачи с использованием своего продукта. Если постгри на это не способен, значит для серьезных решений база пока не совсем готова. Да, у опенсорса с этим бедулька, но что поделать?
Вы даже представить себе не можете, насколько изящно решение MS с tempdb. И таки да, это честная мультиверсионность, которая, помимо всего прочего, строже в плане некоторых аномалий чем то что реализовано в Оракле и Постгри.
Ого! =)
1. не более простую, а более универсальную. Задача проста — передать данные от одного процесса к другому и обратно, все остальное — транспорт, транзакционность, контракт, прочие условия — детали реализации, которые можно собрать как из кирпичиков под текущую задачу. Это не просто, зато очень гибко.
2. GUI тут вообще не причем, в WCF через GUI не делается ничего :)
Предлагаю вам написать 2 приложения одно на WCF, а другое на чистых сокетах и посмотреть разницу. В разных сценариях она будет разная, но вряд ли WCF хотя бы в 1м обгонит сокеты.
Как минимум не отстанет. :) Расходы на сериализацию/десериализацию — минимальны, там весь код эммитится (или LWCG если быть точным, в зависимости от сериализатора), других накладных расходов нет. Чтобы угнаться, придется каждый объект в ручную сериализовать или тоже какой кодогенератор использовать.
Можно, но любой из них медленнее чем простой TCP/IP, опять же потому что они реализованы поверх него.
Так и ваш код тоже будет поверх него. :)
Другой сценарий, наоборот, если вы хотите не заморачиваясь предоставить доступ из других языков.
Для доступа из других языков есть стандартые протоколы, зачем еще один?
… может быть у кого то будет сценарий, когда мой пример пригодится.
Вот и хотелось бы понять, что это за сценарии.
В десятки раз лучше — это не религиозность, я очень хорошо себе представляю во что может обойтись написание клиент-серверного взаимодействия с поддержкой двунаправленности, гарантии доставки, отсутствия дубликатов, смены транспорта, и прочей фигни которая еще может понадобится.
У WCF нет проблем со скоростью. Транспорт можно выбрать любой, SOAP и REST это только протоколы, как раз и облегчающие кроссплатформенное взаимодействие между сервером и клиентом.
А теперь представьте что вы пишете БД, и хотите предоставить как можно больше адаптеров для разных языков программирования, используя Thrift этого можно добится проще. Потому как лично я считаю, что БД претендующая на высокую производительность работающая по HTTP это бред.
Ага, представил… =)) В БД основная проблема с производительностью это как раз сама БД, а ни как не транспорт. А дальше все зависит от того, что это за БД, для каких целей и как будет использоваться — если это общая база, клиенты к которой могут быть где угодно, то REST как раз для этих задач и создавался.
Я привел пример того, что например доступ к БД Cassandra можно получить из дотнета именно посредством Thrift, если бы Cassandra была написана по-другому то вряд ли бы мы дотнетчики могли ее пощупать, по крайней мере ждать пришлось бы дольше.
То есть основная область применения Thrift — если кто-то написал с его помощю серверный код и нужно реализовать клиента?
Нет, мы полезем ковыряться в сокеты, с помощю новомодного инструмента, написанного от безысходности и совсем для другого, и нас не остановит отсутствие документации, нам просто лень прочитать что такое WCF и хорошенько изучить как такие вещи делаются в .Net
=))))
Кто в чем документы готовил — отношения к делу не имеет, я тоже не вчера клавиатуру в первый раз увидел.
А между тем Оззи ушел в целом по делу. Основная причина ухода, и в СМИ об этом неоднократно упоминалось — конфликт с Синофски. Оззи, вместе с Алчином, выпускал Висту, Синофски выпускал семерку. Результат можете оценить сами — при Синофски стало меньше болтологии и больше дела. Так что этот уход, на мой взгляд, вполне закономерен и пойдет скорее на пользу MS.
P. S.
По слухам, когда Синофски стал управлять выпуском операционки, он разогнал больше половины менеджеров, а оставшихся заставил заниматья делом — результат налицо.