Pull to refresh
20
0
Alexey Shcherbak @centur

Cloud Architect @ Drawboard

Send message
Мне кажется большинство таких постов уйдут в прошлое тогда, когда компании начнут использовать swagger для описания своих REST API. А из него и документацию можно сгенерить, и клиентов на разных языках, и просто фронтэнд чтобы поиграть с вызовами. Swagger это прекрасный аналог WSDL для RESTful api

У вас есть?
Ответ на ваш вопрос — если сообщение не помещается в 64Кб — стоит задуматься над архитектурой и тем что вам слишком много данных нужно передавать. Сообщение это больше команда — краткое указание. А по факту — сложите ваши большие данные в блоб и в сообщение засуньте ссылку по которой блоб можно скачать или его ID.

И еще — 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х поросятах — сено и солома. Тепло выветривается быстро. Только пока своего дома нету — изменить ничего не получится в плане переделать и утеплить.
Это не негатив, это простое утверждение — массовое производство энергии\тепла всегда эффективнее индивидуального. Ну фабричные методы эффективнее же ремесленичества.

Про носитель — верно подмечено. Но только вы почему-то не учитываете что газ тоже надо подводить, это тоже инфраструктура и она куда сложнее чем вода в трубах. Газовая система просто более эффективна в передаче «энергии» в определенной форме, с меньшими потерями. Правда куда опасней и сложней в обслуживании. И хорошо когда она уже построена. В мегаполисах она есть — отлично.
Много в многоквартирных домах газового отопления или не разрешают, ибо опасно?

Линии с электричеством — еще круче, много входных источников, проще в обслуживании, универсальный и безопасный формат. Вы же не будете утверждать что производство электричества тоже надо сводить к индивидуальным генераторам на солярке или угле…

А на тему эффективности — думаю как-то просчитали общие затраты обогрев\электрификацию и поделили на население. Стало очевидно что котельные на мазуте и угле не эффективны, а старые ТЭЦ даже с их потерями тепла в трубах — дают фору многим новомодным веяниям. Гибкости меньше зато производство энергии на рубль затрат — выше. Даже включая стоимость инфраструктуры против массовой закупки домашних котлов и кондиционеров.

Если так вопрос интересует как именно авторы считали — можно или почитать оригинальное исследование или написать авторам — вполне могут ответить.
Кстати вместо того чтобы спорить — достаточно привести цитату из самой статьи ( это даже не полное исследование):

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? А то я сейчас покопался — и обнаружил что куда-то пропал графический редактор свойств в С#, похоже раньше это мне какое-то расширение делало… Не то что бы очень надо, просто любопытно, можно ли так обмануть систему…
и да, проект становится проектом «студии» если у него соответствующий ProjectGuid, а не невинные импорты
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.targets" />
То, что они где-то находятся в IDE — не определяет их предназначение. Вы такими выдуманными обозначениями запутаете читателей еще больше, а потом опять будем видеть жалобы на то, что кто-то потратил уйму времени (как автор) просматривая targets мсбилда и все равно ничего не понял.

Да, статью я читал. На соглашения я указал потому, что если им следовать — можно получить некоторые встроенные в msbuild(и поставляемые targets) ништяки. Если не следовать — можно сделать все то же самое, но руками и через «мучения».
$(BlaBlaBla) — это не макрос, это способ адресации Свойства (Property) в MSBuild.

Вообще все остальное, включая ваши наборы свойств выглядит как мало относящееся к MSBuild. Props и Targets это просто «соглашения», можете именовать как угодно, но студия любит их и например может дать возможность редактировать ваши собственные props в окне свойств проекта.

int19h А в чем отличия этой Common Project System от стандартной системы сборки проектов в MSBuild? И почему декларативное описание свойств не будет работать? Мсбилд всегда так работает, ну или я не правильно понимаю ваше высказывание.
Поддержу предыдущего комментатора, по работе вынужден сталкиваться с EF, даже 6тая версия — какие-то наборы архитектурных костылей. Когда была возможность выбирать — использовал PetaPoco и Даппер — ничуть не жалею. Вообще громоздить абстракцию поверх и так уже абстрактного языка SQL — это коряво. А все эти трекинги объектов и контексты — ну не знаю, для меня это издевательство и переусложнение простой задачи — прочитать данные или записать данные. SQL надо знать и надо им пользоваться, а не придумывать велосипеды чтобы его избежать. А аргументы про то как легко сменить базу данных когда у вас есть абстракция — вот честно, кто хоть раз на больших проектах менял базы данных ???
Хмм, ограничение на полное имя файла все также 256 символов. Печально, ждем следующую версию.

Information

Rating
Does not participate
Location
Melbourne, Victoria, Австралия
Date of birth
Registered
Activity