Мне кажется большинство таких постов уйдут в прошлое тогда, когда компании начнут использовать swagger для описания своих REST API. А из него и документацию можно сгенерить, и клиентов на разных языках, и просто фронтэнд чтобы поиграть с вызовами. Swagger это прекрасный аналог WSDL для RESTful api
Ответ на ваш вопрос — если сообщение не помещается в 64Кб — стоит задуматься над архитектурой и тем что вам слишком много данных нужно передавать. Сообщение это больше команда — краткое указание. А по факту — сложите ваши большие данные в блоб и в сообщение засуньте ссылку по которой блоб можно скачать или его ID.
И еще — 20 000 сообщений в секунду для очереди — это не опечатка? вот тут msdn.microsoft.com/library/azure/hh697709.aspx говорят только про 2000 сообщений в секунду на очередь, 20 000 это вроде предел на весь аккаунт…
Не особо — трудно разделить отопление и остальное потребление. Можно было бы проследить и сравнить с летним периодом — но там опять же кондишен на охлаждение работает.
А так если интересно — вот свежий счет
Семья из 3х человек, 2хбедрумная квартира ( т.е. 3 комнаты, зал совмещен с кухней)
Довольно сильный скачок в апреле-мае на потребление, потому что стали включать кондиционер на обогрев.
Изоляция тут в домах — да, гипсокартон и будки. Ну и строят они их как в 3х поросятах — сено и солома. Тепло выветривается быстро. Только пока своего дома нету — изменить ничего не получится в плане переделать и утеплить.
Это не негатив, это простое утверждение — массовое производство энергии\тепла всегда эффективнее индивидуального. Ну фабричные методы эффективнее же ремесленичества.
Про носитель — верно подмечено. Но только вы почему-то не учитываете что газ тоже надо подводить, это тоже инфраструктура и она куда сложнее чем вода в трубах. Газовая система просто более эффективна в передаче «энергии» в определенной форме, с меньшими потерями. Правда куда опасней и сложней в обслуживании. И хорошо когда она уже построена. В мегаполисах она есть — отлично.
Много в многоквартирных домах газового отопления или не разрешают, ибо опасно?
Линии с электричеством — еще круче, много входных источников, проще в обслуживании, универсальный и безопасный формат. Вы же не будете утверждать что производство электричества тоже надо сводить к индивидуальным генераторам на солярке или угле…
А на тему эффективности — думаю как-то просчитали общие затраты обогрев\электрификацию и поделили на население. Стало очевидно что котельные на мазуте и угле не эффективны, а старые ТЭЦ даже с их потерями тепла в трубах — дают фору многим новомодным веяниям. Гибкости меньше зато производство энергии на рубль затрат — выше. Даже включая стоимость инфраструктуры против массовой закупки домашних котлов и кондиционеров.
Если так вопрос интересует как именно авторы считали — можно или почитать оригинальное исследование или написать авторам — вполне могут ответить.
Кстати вместо того чтобы спорить — достаточно привести цитату из самой статьи ( это даже не полное исследование):
Moscow has built the largest district heating system in the world, providing combined heat and power to buildings housing 12 million people; this being more efficient that using separate systems for each building.
Т.е. сами исследователи говорят — центральная система (даже такая старая и проблемная, построенная еще в СССР) более эффективна чем индивидуальные (которые динамичные и легче модернизируются).
Неужели, кто-то действительно серьёзно может говорить о том, что в США и Канаде что-то там не подсчитали и просто так выкидывают деньги на ветер?
Неужели кто-то проживший дольше года в любой западной стране продолжает ее идеализировать и считать что вот они то самые умные и эффективные?
Во всех странах есть свои особенности как государственной так и локальной политики, и поварившись немного в теме начинаешь замечать — В «А» это сделано лучше, а это хуже чем в «Б». Где-то нагло воруют бюджет, а где-то официально тратят его на перераздутые программы якобы улучшений. Где-то топят газом и теряют тепло при передаче, потому что инфраструктура плохая, а где-то топят мазутом и углем потому что это дешево и инфраструктура под это уже есть. А где-то законодательно запрещено муниципалитетом делать что-то, поэтому все вынуждены пользоваться более дорогими системами.
А еще есть официально разрешенное лобби, и там вообще эффективностью не пахнет, только для вида…
Интересная статья, спасибо.
Никто не говорит что чехи дураки, но опять же домовая система, которая является самой популярной в Чехии, это совсем не индивидуальная. Это централизация отопления но в масштабах дома, а не района.
В итоге достигается экономия на потерях при передаче тепла от точки генерации к точке потребления, что есть классно и правильно (хотя современные методы изоляции тоже могут сократить эти потери). Все отличие этой системы от системы центрального отопления только в том, что у там нету больших ТЭЦ, которые выглядят страшно но вырабатывают самое дешевое тепло. И вместо котельных которые производят донагрев, там есть современные и автономные котельные в каждом дом которые производят полный нагрев. В итоге — платите больше за определенную долю гибкости. Если пойти дальше до этажных и индивидуальных систем — вы увидите ровно ту же тенденцию что я описал — чем более индивидуальные средства обогрева начинают использоваться — тем больше гибкость, но ниже энергоэффективность в пересчете на затраты.
В индивидуальных домах может даже газа не быть (потому что газ это тоже инфраструктура), только электричество, тогда греемся маслянными\конвекционными обогревателями и кондеями. Любите тепло — получите счет в 1000 долларов за зимний период ( и это Мельбурн где средняя зимняя температура +13, в Чехии еще даже могут не включить обогрев в такую зиму, судя по статье). Тащить вот эту индивидуальную систему в мегаполисы где есть высотная застройка — глупо и экономически не выгодно.
И да, не забывайте что централизованная система создавалась тогда, когда еще не было всей умной автоматики которая убережет котел от перегрева и взрыва, а массовые индивидуальные котлы — были из разряда фантастики. Взрыв котельной в соседнем дворе и в подвале вашего подъезда \на этаже — совсем разные вещи.
Знаете, индивидуальное отопление ни капельки не эффективно по сравнению с централизованным
Оно имеет смысл и применяется на больших территориях просто потому что тянуть трубы к индивидуальному домохозяйству — не выгодно. Как и высокоскоростной интернет, например. В мегаполисах, с высокой концентрацией потребителей на квадратный километр, как раз выгодно делать централизованные услуги, потому как в этом случае есть доступ к оборудованию и технологиям промышленного качества.
Централизованное и массовое производство тепла позволяет эффективнее распределять его излишки или создавать сложные схемы по пере-использованию тепла от промышленных производств.
Все это недоступно для индивидуалов и все что можно реально сделать — выбрать чуть более эффективную модель кондиционера ( который все равно за 2-3 месяца может нагенерить счет на $1000 за электричество) или более дорогой но быстрее нагревающий комнату обогреватель.
Это вся свобода выбора в вашей прославляемой индивидуальной системе. Достаточно даже школьной арифметики чтобы понять насколько она чудовищно неэффективна и должна применяться только выборочно, когда централизованная система недоступна ( индивидуальные участки, дома, отсутствие инфраструктуры).
Как человек, поживший в городе с централизованными услугами и сейчас живущий в условиях этого индивидуального отопления и умеющий считать затраты на это самое отопление, могу сказать — индивидуальное отопление это вынужденная мера и крайне неэффективная система, но единственно применимая на территориях с низкой плотностью населения и индивидуальной застройкой.
Вы же говорите откровенные глупости, не приводя аргументов и используете разжигание ненависти и оскорбления, как способ подтвердить свою точку зрения. Читайте меньше литературы пропагандистско-истерического толка и чаще применяйте ганглий между ушами.
От Object-Relational Mapper — да, мне необходим именно маппер, потому что все остальное оно делает хуже чем нативный интерфейс.
Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
Что то POCO ( plain old class objects) тут и не пахнет, все эти аттрибуты и navigation property засоряют модель. Пример работы с POCO — PetaPoco, берем любой класс и в него маппим результат SQL запроса. И не надо fluent городить — SQL для общения с базой — самый правильный и родной вариант.
Эти системы (я про fake &psake) направлены на другое — это просто обертка, которая прячет от вас функциональную часть сборки. Мсбилд — возможность заглянуть и понять что происходит под капотом. Просто не понимая что внутри — невозможно модифицировать систему чтобы она делала что нужно вам, всегда будут ритуальные пляски — а вот такой плагин добавим, а вот такой модуль, а еще их надо вызвать в строгом порядке, а между вызовами очистить вот эту папку. Это называется культ карго.
Да, мсбилд использует не самый дружественный синтаксис, да, весь каскад импортов и переопределенных свойств может вызвать мигрень, да, половина таргетов для не основных продуктов написана криворукими идиотами, но понимание самой системы сборки дает вам знание о том, что происходит когда вы вызываете msbuild ./mylib.csproj. А также вы знаете как повлиять на это, в любой билд системе. И это кстати совсем не хардкор 8-)
PS про TFS — ппкс, и спасибо за наводку, как то пропустил что появились детали 2015…
А еще есть TFS — вообще гуй есть и можно в workflow в drag-and-drop стиле редактировать, не то что ваши тестикулярные скриптовые языки. Типа ура…
Обычно, необходимость в скриптовых и императивных языках возникает когда в команде многие не способны ( в силу ограниченности кругозора) понимать XML мсбилда и его декларативность. Ну это в общем проблемы команды, а не мсбилда. Хоть на batch пишите, только все эти обвязки — как забивать гвозди микроскопом — от непонимания.
Ок. т.е. получается в данном случае они не только используют свойства как способ хранения, но и используют такой же синтаксис? Или все-таки они заимствуют синтаксис из мсбилда, потому что само строковое значение будет интерпретироваться\разворачиваться не студией, а мсбилдом? Кто их разворачивает, эти «макросы»? Если второе — то все-таки это сущность билда, а не макрос студии.
Классно, спасибо за пояснения, как работает мсбилд я знаю неплохо, а вот такие детали про проектные системы и их проекции на систему сборки — очень полезны.
Кстати такой технический вопрос — можно ли убедить студию что ей нужно отрисовать содержимое файла Х как набор свойств проекта в GUI (т.е. убедить ее в том, что «проектная система — C#, но вот тут отрисуй пожалуйста используя другой компонент, из CPS» ), или это все жестко связано с расширениями и внутренними Guid? А то я сейчас покопался — и обнаружил что куда-то пропал графический редактор свойств в С#, похоже раньше это мне какое-то расширение делало… Не то что бы очень надо, просто любопытно, можно ли так обмануть систему…
То, что они где-то находятся в IDE — не определяет их предназначение. Вы такими выдуманными обозначениями запутаете читателей еще больше, а потом опять будем видеть жалобы на то, что кто-то потратил уйму времени (как автор) просматривая targets мсбилда и все равно ничего не понял.
Да, статью я читал. На соглашения я указал потому, что если им следовать — можно получить некоторые встроенные в msbuild(и поставляемые targets) ништяки. Если не следовать — можно сделать все то же самое, но руками и через «мучения».
$(BlaBlaBla) — это не макрос, это способ адресации Свойства (Property) в MSBuild.
Вообще все остальное, включая ваши наборы свойств выглядит как мало относящееся к MSBuild. Props и Targets это просто «соглашения», можете именовать как угодно, но студия любит их и например может дать возможность редактировать ваши собственные props в окне свойств проекта.
int19h А в чем отличия этой Common Project System от стандартной системы сборки проектов в MSBuild? И почему декларативное описание свойств не будет работать? Мсбилд всегда так работает, ну или я не правильно понимаю ваше высказывание.
Поддержу предыдущего комментатора, по работе вынужден сталкиваться с EF, даже 6тая версия — какие-то наборы архитектурных костылей. Когда была возможность выбирать — использовал PetaPoco и Даппер — ничуть не жалею. Вообще громоздить абстракцию поверх и так уже абстрактного языка SQL — это коряво. А все эти трекинги объектов и контексты — ну не знаю, для меня это издевательство и переусложнение простой задачи — прочитать данные или записать данные. SQL надо знать и надо им пользоваться, а не придумывать велосипеды чтобы его избежать. А аргументы про то как легко сменить базу данных когда у вас есть абстракция — вот честно, кто хоть раз на больших проектах менял базы данных ???
У вас есть?
И еще — 20 000 сообщений в секунду для очереди — это не опечатка? вот тут msdn.microsoft.com/library/azure/hh697709.aspx говорят только про 2000 сообщений в секунду на очередь, 20 000 это вроде предел на весь аккаунт…
А так если интересно — вот свежий счет
Billing Period: 29-January-2015 — 03-May-2015
1031 kWh — $285.08
Семья из 3х человек, 2хбедрумная квартира ( т.е. 3 комнаты, зал совмещен с кухней)
Довольно сильный скачок в апреле-мае на потребление, потому что стали включать кондиционер на обогрев.
Изоляция тут в домах — да, гипсокартон и будки. Ну и строят они их как в 3х поросятах — сено и солома. Тепло выветривается быстро. Только пока своего дома нету — изменить ничего не получится в плане переделать и утеплить.
Про носитель — верно подмечено. Но только вы почему-то не учитываете что газ тоже надо подводить, это тоже инфраструктура и она куда сложнее чем вода в трубах. Газовая система просто более эффективна в передаче «энергии» в определенной форме, с меньшими потерями. Правда куда опасней и сложней в обслуживании. И хорошо когда она уже построена. В мегаполисах она есть — отлично.
Много в многоквартирных домах газового отопления или не разрешают, ибо опасно?
Линии с электричеством — еще круче, много входных источников, проще в обслуживании, универсальный и безопасный формат. Вы же не будете утверждать что производство электричества тоже надо сводить к индивидуальным генераторам на солярке или угле…
А на тему эффективности — думаю как-то просчитали общие затраты обогрев\электрификацию и поделили на население. Стало очевидно что котельные на мазуте и угле не эффективны, а старые ТЭЦ даже с их потерями тепла в трубах — дают фору многим новомодным веяниям. Гибкости меньше зато производство энергии на рубль затрат — выше. Даже включая стоимость инфраструктуры против массовой закупки домашних котлов и кондиционеров.
Если так вопрос интересует как именно авторы считали — можно или почитать оригинальное исследование или написать авторам — вполне могут ответить.
Т.е. сами исследователи говорят — центральная система (даже такая старая и проблемная, построенная еще в СССР) более эффективна чем индивидуальные (которые динамичные и легче модернизируются).
Неужели кто-то проживший дольше года в любой западной стране продолжает ее идеализировать и считать что вот они то самые умные и эффективные?
Во всех странах есть свои особенности как государственной так и локальной политики, и поварившись немного в теме начинаешь замечать — В «А» это сделано лучше, а это хуже чем в «Б». Где-то нагло воруют бюджет, а где-то официально тратят его на перераздутые программы якобы улучшений. Где-то топят газом и теряют тепло при передаче, потому что инфраструктура плохая, а где-то топят мазутом и углем потому что это дешево и инфраструктура под это уже есть. А где-то законодательно запрещено муниципалитетом делать что-то, поэтому все вынуждены пользоваться более дорогими системами.
А еще есть официально разрешенное лобби, и там вообще эффективностью не пахнет, только для вида…
Никто не говорит что чехи дураки, но опять же домовая система, которая является самой популярной в Чехии, это совсем не индивидуальная. Это централизация отопления но в масштабах дома, а не района.
В итоге достигается экономия на потерях при передаче тепла от точки генерации к точке потребления, что есть классно и правильно (хотя современные методы изоляции тоже могут сократить эти потери). Все отличие этой системы от системы центрального отопления только в том, что у там нету больших ТЭЦ, которые выглядят страшно но вырабатывают самое дешевое тепло. И вместо котельных которые производят донагрев, там есть современные и автономные котельные в каждом дом которые производят полный нагрев. В итоге — платите больше за определенную долю гибкости. Если пойти дальше до этажных и индивидуальных систем — вы увидите ровно ту же тенденцию что я описал — чем более индивидуальные средства обогрева начинают использоваться — тем больше гибкость, но ниже энергоэффективность в пересчете на затраты.
В индивидуальных домах может даже газа не быть (потому что газ это тоже инфраструктура), только электричество, тогда греемся маслянными\конвекционными обогревателями и кондеями. Любите тепло — получите счет в 1000 долларов за зимний период ( и это Мельбурн где средняя зимняя температура +13, в Чехии еще даже могут не включить обогрев в такую зиму, судя по статье). Тащить вот эту индивидуальную систему в мегаполисы где есть высотная застройка — глупо и экономически не выгодно.
И да, не забывайте что централизованная система создавалась тогда, когда еще не было всей умной автоматики которая убережет котел от перегрева и взрыва, а массовые индивидуальные котлы — были из разряда фантастики. Взрыв котельной в соседнем дворе и в подвале вашего подъезда \на этаже — совсем разные вещи.
Оно имеет смысл и применяется на больших территориях просто потому что тянуть трубы к индивидуальному домохозяйству — не выгодно. Как и высокоскоростной интернет, например. В мегаполисах, с высокой концентрацией потребителей на квадратный километр, как раз выгодно делать централизованные услуги, потому как в этом случае есть доступ к оборудованию и технологиям промышленного качества.
Централизованное и массовое производство тепла позволяет эффективнее распределять его излишки или создавать сложные схемы по пере-использованию тепла от промышленных производств.
Все это недоступно для индивидуалов и все что можно реально сделать — выбрать чуть более эффективную модель кондиционера ( который все равно за 2-3 месяца может нагенерить счет на $1000 за электричество) или более дорогой но быстрее нагревающий комнату обогреватель.
Это вся свобода выбора в вашей прославляемой индивидуальной системе. Достаточно даже школьной арифметики чтобы понять насколько она чудовищно неэффективна и должна применяться только выборочно, когда централизованная система недоступна ( индивидуальные участки, дома, отсутствие инфраструктуры).
Как человек, поживший в городе с централизованными услугами и сейчас живущий в условиях этого индивидуального отопления и умеющий считать затраты на это самое отопление, могу сказать — индивидуальное отопление это вынужденная мера и крайне неэффективная система, но единственно применимая на территориях с низкой плотностью населения и индивидуальной застройкой.
Вы же говорите откровенные глупости, не приводя аргументов и используете разжигание ненависти и оскорбления, как способ подтвердить свою точку зрения. Читайте меньше литературы пропагандистско-истерического толка и чаще применяйте ганглий между ушами.
Ну и удобный способ исполнять мои запросы на языке базы данных. А не универсальный комбайн-переводчик с свистоперделками. Уже все вроде наелись с EF и признались — создание суррогатных языков, пусть даже с автокомплитами и все такое — всегда генерит худший результат (и если смотрели в профайлере — сильно худший) чем обычный SQL, который lingua franca реляционных БД.
Да, мсбилд использует не самый дружественный синтаксис, да, весь каскад импортов и переопределенных свойств может вызвать мигрень, да, половина таргетов для не основных продуктов написана криворукими идиотами, но понимание самой системы сборки дает вам знание о том, что происходит когда вы вызываете msbuild ./mylib.csproj. А также вы знаете как повлиять на это, в любой билд системе. И это кстати совсем не хардкор 8-)
PS про TFS — ппкс, и спасибо за наводку, как то пропустил что появились детали 2015…
Обычно, необходимость в скриптовых и императивных языках возникает когда в команде многие не способны ( в силу ограниченности кругозора) понимать XML мсбилда и его декларативность. Ну это в общем проблемы команды, а не мсбилда. Хоть на batch пишите, только все эти обвязки — как забивать гвозди микроскопом — от непонимания.
Кстати такой технический вопрос — можно ли убедить студию что ей нужно отрисовать содержимое файла Х как набор свойств проекта в GUI (т.е. убедить ее в том, что «проектная система — C#, но вот тут отрисуй пожалуйста используя другой компонент, из CPS» ), или это все жестко связано с расширениями и внутренними Guid? А то я сейчас покопался — и обнаружил что куда-то пропал графический редактор свойств в С#, похоже раньше это мне какое-то расширение делало… Не то что бы очень надо, просто любопытно, можно ли так обмануть систему…
Да, статью я читал. На соглашения я указал потому, что если им следовать — можно получить некоторые встроенные в msbuild(и поставляемые targets) ништяки. Если не следовать — можно сделать все то же самое, но руками и через «мучения».
Вообще все остальное, включая ваши наборы свойств выглядит как мало относящееся к MSBuild. Props и Targets это просто «соглашения», можете именовать как угодно, но студия любит их и например может дать возможность редактировать ваши собственные props в окне свойств проекта.
int19h А в чем отличия этой Common Project System от стандартной системы сборки проектов в MSBuild? И почему декларативное описание свойств не будет работать? Мсбилд всегда так работает, ну или я не правильно понимаю ваше высказывание.