В 2004 году мировое производство железной руды превысило 1 млрд тонн.[4] Для сравнения, один небольшой астероид класса M диаметром в 1 км может содержать до 2 млрд тонн железо-никелевой руды[5], что в 2-3 раза превышает добычу руды за 2004 год. Астероид (16) Психея содержит 1,7·10^19 кг железо-никелевой руды. Этого количества хватило бы для обеспечения потребностей населения земного шара в течение нескольких миллионов лет, даже с учётом дальнейшего увеличения спроса. Небольшая часть извлечённого материала может также содержать драгоценные металлы.
Сейчас пруфы уже не найду, но читал пару лет тому назад, что в одном из европейских городов сделали экспериментальную улицу с подогревом. Так оказалось, что это тратит огромное количество энергии и что обычная регулярная чистка на порядки дешевле обходится.
Такой биндинг только в крайних и исключительных случаях. Обычно пишется что-то типа "{Binding Price}" и всё. Или, если очень надо, сделать обычного наследника от стандартного Binding, в котором это всё прописать.
Ну, представленные заголовки XAML и HTML-страницы совершенно не идентичны по функциональности. Как-то неправильно их сравнивать.
Странно, что автор не сравнивает сам код HTML с XAML. HTML — это ужас и ад, набор кучи грязных хаков, головная боль с поддерживаемостью кучи браузеров, нетипизированный и примитивный javascript и пр. После HTML писать код на XAML — сплошное удовольствие.
Microsoft имеет возможность модифицировать язык под фреймворк (ниже покажу на примере Expression Trees).
То, что Microsoft может вводить в C# для поддержки EF, можно использовать и в NHibernate.
Если у db-класса Entity есть поле int EntityId, оно автоматически становится primary key, без дополнительных подсказок, если есть поле Order Order и поле int OrderId, фреймворк понимает, что OrderId — foreign Key для Order.
«Автоматическое» определение чего-либо обычно уж очень подозрительно и чревато граблями. Указать поле для ключа совсем не долго.
В отличии от NH, EF не требует описания каждого поля как virtual, а только для lazy-полей.
Вроде он требует описывание как virtual не просто так? А для автоматического отслеживания изменений.
Запросы в EF строятся через знакомый всем linq, а не с использованием новых классов и новых методов, как в NHibernate (всякие ICriterion, DetachedCriteria, Restrictions и т. п.)
Возможность описывать запрос linq-выражением была ещё во второй версии отдельной библиотекой. В третьей она уже включена.
Ещё о NH. Маппинги описываются в XML-аннотациях. Обычно, каждый entity-класс сопровождается xml-файлом с маппингом. Существует велосипед в community contrib делать маппинги атрибутами, который при запуске проекта рефлектит все классы в указанных сборках, делает XML из атрибутов и скармливает его ORM. Но не все конструкции, выражаемые в XML, можно описать атрибутами (хотя в одном проекте можно совмещать два подхода). В-общем, после NH переход на EF кажется очень приятным.
В третьей версии NH появилась возможность описывать маппинги кодом. Причём возможности там, похоже, абсолютно все (я не сталкивался с тем, что что-то можно описать xml, но нельзя кодом).
Из минусов EF отмечу катастрофичекое падение производительности при большом количестве объектов в контексте.
Аналогично, была программа, где NH был почти в 3 раза быстрее. Как я ни бился, но разогнать EF не удалось.
Огромное преимущество и огромный недостаток NH по сравнению с EF в том, что он гораздо мощнее. И гораздо сложнее в освоении. Написать с нуля маппинг и сущности на NH почти на порядок дольше, чем на EF. Зато столько возможностей…
Дык в том то и суть, что можно без проблем взять (выслушать подсказку, найти в Гугле) эти уравнения и полный их вывод и проверить самому. Любой — и верующий и сомневающийся может убедиться в их истинности.
Вообще считается, что Марс после образования был расплавлен не целиком. И те элементы, которые на Земле просто утонули в ядре планеты (ведь по сути всё тяжелее кремния что добывается у нас — это остатки от поздней планетарной бомбардировки да некоторый результат активности вулканов) там должны быть равномерно распределены.
Вы утверждали, что «технического потолка» в космической индустрии не существует. Вот в выводе на орбиту такой потолок был достигнут.
И вообще, ядерному реактору нужно много подвижных и сложных частей. Теплообменники, системы управления, охлаждения, средства контроля и экстренной остановке. Это маленький реактор можно сделать компактным и необслуживаемым. Вы правда думаете, что обслуживают атомные электростанции тысячи человек только из-за того, что никто даже не думал уменьшить их количество?
Создать такие ракеты раньше было просто невозможно. И то, что частные компании сумели возвращать ракету целой и при этом не терять в эффективности, ещё не известно. Опыты у SpaceX (или кто там этим занимался?) только начались. Тут ещё можно вспомнить и невероятно многообещающий проект Skylon. Но всё это — просто тупое развитие идей Циолковского. Как он придумал конструкцию почти век тому назад — так она и используется сейчас. С её крайней неэффективностью (больше 90% массы корабля — топливо, чтобы поднимать корабль и само топливо — ну куда это вообще годится???). И именно эта конструкция — потолок.
Странно, что автор не сравнивает сам код HTML с XAML. HTML — это ужас и ад, набор кучи грязных хаков, головная боль с поддерживаемостью кучи браузеров, нетипизированный и примитивный javascript и пр. После HTML писать код на XAML — сплошное удовольствие.
То, что Microsoft может вводить в C# для поддержки EF, можно использовать и в NHibernate.
«Автоматическое» определение чего-либо обычно уж очень подозрительно и чревато граблями. Указать поле для ключа совсем не долго.
Вроде он требует описывание как virtual не просто так? А для автоматического отслеживания изменений.
Возможность описывать запрос linq-выражением была ещё во второй версии отдельной библиотекой. В третьей она уже включена.
В третьей версии NH появилась возможность описывать маппинги кодом. Причём возможности там, похоже, абсолютно все (я не сталкивался с тем, что что-то можно описать xml, но нельзя кодом).
Аналогично, была программа, где NH был почти в 3 раза быстрее. Как я ни бился, но разогнать EF не удалось.
Огромное преимущество и огромный недостаток NH по сравнению с EF в том, что он гораздо мощнее. И гораздо сложнее в освоении. Написать с нуля маппинг и сущности на NH почти на порядок дольше, чем на EF. Зато столько возможностей…
И вообще, ядерному реактору нужно много подвижных и сложных частей. Теплообменники, системы управления, охлаждения, средства контроля и экстренной остановке. Это маленький реактор можно сделать компактным и необслуживаемым. Вы правда думаете, что обслуживают атомные электростанции тысячи человек только из-за того, что никто даже не думал уменьшить их количество?