В предыдущих статьях — мы выяснили, что ни солнечная энергетика не сможет удовлетворить потребности человечества (из-за быстрого выхода из строя аккумуляторов и их стоимости), ни термоядерная (т.к. даже после достижения на экспериментальных реакторах положительного выхода энергии — остается фантастическое количество проблем на пути коммерческого использования). Что же остается?

Уже не первую сотню лет, не смотря на весь прогресс человечества, основной объем электроэнергии получается от банального сжигания угля (который до сих пор является источником энергии для 40.7% генерирующих мощностей в мире), газа (21.2%), нефтепродуктов (5.5%) и гидроэнергетики (еще 16.2%, в сумме все это — 83.5% по данным на 2008 год).

Остается — ядерная энергетика, с обычными реакторами на тепловых нейтронах (требующих редкий и дорогой U-235) и с реакторами на быстрых нейтронах (которые могут перерабатывать природный U-238 и торий в «замкнутом топливном цикле»).

Что это за мифический «замкнутый топливный цикл», в чем отличия реакторов на быстрых и тепловых нейтронах, какие существуют конструкции, когда нам от всего этого ждать счастья и конечно — вопрос безопасности — под катом.

Новый миниатюрный квадрокоптер MeCam, недавно представленный компанией Always Innovating, способен поменять наши представления о способах видео- и фотосъёмки. MeCam представляет собой летающую камеру на базе Linux, которая управляется голосом и передаёт фото и видео по Wi-Fi либо Bluetooth на iOS либо Android-устройство с возможностью последующей публикации в Youtube, Google+, Facebook либо Twitter. Также, как альтернатива управлению голосом, поддерживается функция «Follow Me», при которой квадрокоптер неотступно следует за пользователем, ориентируясь на сигнал его смартфона либо планшета. В устройство встроено 14 датчиков, позволяющие самостоятельно преодолевать препятствия, имеется система стабилизации для получения плавного изображения и возможность панорамной съёмки.

Мое детство прошло среди людей которые все время на чем то летали. Строили, разрабатывали новое и тут же на нем летали. В 5 лет для меня стало открытием, что кто то в этом мире может не летать. К своим 26 годам я успел попробовать почти все на чем можно летать. Хочу поделиться своим опытом и рассказать о доступных возможностях.
Что бы начать летать у Вас есть такие варианты:

1. Парители (в этой статье)

• Параплан
• Дельтаплан
• Планер

2. Моторный полет (вторая статья)

• Легкий самолет
• Мотодельтаплан
• Паратрайк
• Парамотор
• Мотопланер

Любят на Хабре солнечную энергетику: вот Гугл строит солнечные электростанции (1 2 3 4 5 6), вот Германия однажды генерировала треть текущего энергопотребления на солнечных электростанциях…

Комментарии делятся на 2 категории: «Вот молодцы, а мы только нефть жгем» и "EROEI! Производство солнечных батарей требует больше энергии чем они производят!".

Въедливый читатель наверняка подумает: Как это производит меньше, чем требуется на производство? Их же поставил — они работают, каши не просят, 10 лет, 50лет, 100лет — значит суммарная произведенная энергия равна бесконечности, и они должны быть выгодны при любой стоимости постройки…

Как обстоит все на самом деле, какие есть подходы к солнечной генерации, что ограничивает КПД солнечных элементов, какие гениальные идеи уже были реализованы и почему солнечная энергетика как-то не активно захватывает мир — под катом.

Года полтора назад я выкладывал на Хабр цикл видеолекций с моим видением того как работает мозг и каковы возможные пути создания искусственного интеллекта. За прошедшее с тех пор время удалось существенно продвинуться вперед. Что-то получилось глубже понять, что-то удалось смоделировать на компьютере. Что приятно, появились единомышленники, активно участвующие в работе над проектом.

В настоящем цикле статей планируется рассказать о той концепции интеллекта над которой мы сейчас работаем и продемонстрировать некоторые решения, являющиеся принципиально новыми в сфере моделирования работы мозга. Но чтобы повествование было понятным и последовательным оно будет содержать не только описание новых идей, но и рассказ о работе мозга вообще. Какие-то вещи, особенно в начале, возможно покажутся простыми и общеизвестными, но я бы советовал не пропускать их, так как они во многом определяют общую доказательность повествования.

Привет Хабр. В последнее время среди программистов все больше стала набирать популярность цифровая электроника, появляются все новые платформы, позволяющие без каких либо особых знаний в электронике собирать различные устройства. Сам я начинал заниматься аналоговой электроникой, позже — цифровой и программированием. Многие же — наоборот — сначала программированием, а потом пытаются заниматься железом, при этом знания по части электроники практически нулевые и люди не знают/не понимают элементарных для олдфажного электронщика вещей. В данной статье я постараюсь затронуть наиболее важные на мой взгляд моменты, как по части проектирования схем, так и по части разводки плат. Надеюсь мои советы помогут миновать некоторые грабли

Четвёртая версия фреймворка Ruby on Rails уже не за горами. Хотя официальной даты релиза еще нет, многие ожидают release candidate уже в начале этого года.
Эта версия фреймворка разрабатывается уже год и представляет из себя множество изменений во внутренней архитектуре. Фреймворк эволюционировал и прибрёл более модульный формат, большинство из нововведений раскидано по отдельным джэмам, для того, чтобы основной код оставался чистым. Таким образом, устаревший функционал можно официально не поддерживать, но использовать, если такая необходимость возникнет.

Во время написания этих строк Engine Yard пока что официально не поддерживает Rails 4 в наших облачных продуктах. Однако, если вы хотите таки их опробовать, вы, конечно, же сможете. Однако будьте внимательны — некоторые возможности, особенно live streaming, скорее всего не будут работать.

Если вы столкнётесь со сложностями при попытке развёртывания приложений на Rails 4, то их нужно регистрировать как feature requests, а не как баг, так как мы ещё не закончили интегрирование Rails 4 в наши продукты.

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

Обычно я не жалуюсь, но сейчас, думаю, самое время оглянуться назад и посмотреть, что же не так с ООП. В таком духе я и подготовил скромный список десяти вещей, которые я терпеть не могу в ООП.

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.

Последняя за новогодние каникулы, но не последняя в этой серии статья, посвященная внутренностям jQuery. Прошлая получилась очень быстрой и маленькой, но интерес хабражителей к теме, судя по опросу «стоит ли продолжать?», который висят в каждом посте некоторое время после его создания, не пропадает.

Тема для сегодняшнего поста достаточно большая и я постараюсь рассказать о ней поинтереснее и не слишком поверхностно. Рассмотрим мы сегодня методы attr, prop и data.

jQuery однозначно стал стандартом в индустрии веб-дева. Есть много отличных js-фреймворков, которые заслуживают внимания, но jQuery поразил всех своей лёгкостью, изящностью, магией. Люди пишут с использованием jQuery, люди пишут плагины для jQuery, люди даже пишут статьи про jQuery, но мало кто знает (особенно из новичков), КАК устроен jQuery.

В этой статье проведем небольшой экскурс во внутренности этого фреймворка и разберем, что внутри.
Статья рассчитана на базовые знания Javascript. Задумайтесь и, если вы знаете, как написать клон jQuery, то, скорее всего, вы тут не найдёте ничего нового. Остальным — добро пожаловать под кат

Эта статья содержит необходимый минимум тех вещей, которые просто необходимо знать о типизации, чтобы не называть динамическую типизацию злом, Lisp — бестиповым языком, а C — языком со строгой типизацией.

В полной версии находится подробное описание всех видов типизации, приправленное примерами кода, ссылками на популярные языки программирования и показательными картинками.

Это статья об изменениях, которые произошли в мире веб-разработки. Я наблюдаю огромное количество веб-разработчиков, которые буквально застряли в устаревших технологиях, особенно в мире .NET. Если вы еще не начали совершенствовать свои навыки, и адаптироваться к изменяющимся трендам, вы должны начинать уже сегодня.

От переводчика: предлагаю вам перевод начала презентации Michael Fairley — Extending Ruby with Ruby. Я перевел только первую часть из трех, потому что она имеет максимальные практические ценность и пользу, на мой взгляд. Тем не менее, настоятельно рекомендую ознакомиться с полной презентацией, в которой помимо Python приводятся примеры заимствования фишек из Haskell и Scala.

Декораторы функции

В Python есть такая штука — декораторы, которая представляет собой синтаксический сахар для добавления в методы и функции кусочков часто используемой функциональности. Сейчас я покажу вам некоторые примеры того, что такое декораторы и почему они могли бы быть полезны и в Ruby.

Раньше я очень много работал с Python и декораторы функции определенно являются тем, чего мне так не хватает с тех пор, и кроме того тем, что может помочь практически всем нам сделать наш код на Ruby чище.

Возьмем Ruby и притворимся, что нам нужно перевести деньги с одного банковского аккаунта на другой. Вроде все просто, так?

def send_money(from, to, amount)
  from.balance -= amount
  to.balance += amount
  from.save!
  to.save!
end

В оригинале название звучит как «How Not To Sort By Average Rating». Я подумал, что дословный перевод «Как не сортировать по усреднённому рейтингу» будет малопонятен и хуже отражает содержание статьи.

Постановка проблемы

Вы занимаетесь веб программированием. У вас есть пользователи, которые оценивают контент на вашем сайте. Вы хотите разместить высоко оцененный контент наверху, а низко оцененный — внизу. Для этого на основе пользовательских оценок вам нужно вычислить некий «рейтинг».

Неправильное решение №1

Рейтинг= (Число положительных оценок) - (Число отрицательных оценок)