JSON схемы мы используем только для ответов API. И только потому, что API запросы у нас очень простые. В них нет иерархических структур. Валидация происходит на стороне приложения. А для документирования запросов через JSON схемы просто руки не доходят, профита будет не очень много.

На счет собственной реализации согласен. Принципальных сложностей в создании валидатора JSON схем нет. Было бы время и желание.

Конечно, ОС должна удовлетворять задач пользователя.
Я про то, что сами эти задачи уходят в браузер. И тенденция продолжается.
А значит, есть ощутимый процент пользователей, для которых уже сейчас кроме браузера почти ничего нужно.

Сильным скачком развития дополненной реальности наверняка станут устройства на подобии Google Glass или около того. При условии, что они станут популярными, конечно. Смартфон и планшет все-таки не самые удобные устройства для этих целей.

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

Ну а формат видео для путеводителей — отличная штука. Причем только тогда, когда автор подает информацию одновременно и быстро и так, что она сразу оседает в голове. Это именно тот случай.

1. По-видимому, разработчики CoffeeScript просто хотели быть ближе к Ruby, но не получилось до конца. При вызове функции без параметров и без скобок не понятно, то ли мы вызываем функцию, то ли используем ссылку на нее. Тупик. Поэтому многие разработчики предпочитают всегда указывать скобки для консистентности.

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

Уберегает от ошибок именно в JavaScript. Но, конечно, открывает новые возможности — ошибиться в самом CoffeeScript. Это да. Другое дело, что возможностей выстрелить себе в ногу в чистом JavaScript гораздо больше.

Согласен, крайне важный момент — соответствие между CoffeeScript и JavaScript-кодом. Без поддержки со стороны инструментальных средств я в принципе не представляю себе серьезную разработку на CoffeeScript. Для все того же WebStrom описание здесь — http://www.jetbrains.com/webstorm/webhelp/coffeescript-support.html

На первый взгляд решение с массивом строк и join должно однозначно выполнятся быстрее.
Ведь и правда, конкатенация большого количества строк в лоб, одну за другой должно создавать большое количество временных строковых объектов, которые потом надо вычищать сборщику мусора — это раз. Во-вторых, как не вспомнить легендарного маляра Шлемиэля (http://russian.joelonsoftware.com/Articles/BacktoBasics.html).

Но все дело в том, что современные JavaScript движки достаточно умные, чтобы не хило оптимизировать конкатенацию.
Подробно этот вопрос освещен здесь http://stackoverflow.com/questions/7299010/why-is-string-concatenation-faster-than-array-join.

Можно еще таким способом подключать: http://coffeescript.org/#scripts.
Но он не рекомендуется.

В IE геттеры/сеттеры появились только в 9-ке. В IE8 из ES5 реализовано крайне мало. А IE8 пока в большинстве случаев стараются поддерживать. Поэтому, если говорить про браузерный JavaScript, то ES5 можно использовать, к сожалению, далеко не везде.
Но в целом политика партии с поддержкой IE6, конечно, сдерживает сам язык, согласен.

Сам элемент можно получит как event.target. Есть ли кейсы, когда на самом деле нужен исходный this в этом примере?

Конечно, чудес не бывает, 99 Кб и 75 Кб выбраны только для примера. Надо было это подчеркнуть.
В формате Jpeg особенно сильно видны размытия на границах объектов. Когда мы делаем картинку в два раза большего размера, сжимаем в Jpeg-формате, а потом искусственно уменьшаем в два раза, то как раз вот эти самые размытия на границах становятся менее видны. По ссылке это хорошо видно на 49-ом и на 52-ом слайдах.

Мало того, что не AUTO_INCREMENT, так и его эмуляция кривая — не устойчивая к конкурентным запросам.

Насчет «5. Не меняйте масштаб изображений» — если только это не целенаправленная оптимизация изображений для Retina-экранов.

Пусть у нас есть изображение размером 1024x640 и 99 Кб, а делать его в более высоком качестве слишком дорого, оно будет больше весить. Поэтому возьмем такое же изображение, но с размером 2048x1280 и 75 Кб. Так вот, если второму изображению принудительно задать размер в CSS 1024x640, то изображение будет выглядеть качественнее, чем первое.

Минус этой техники, что заставляем браузер делать лишнюю работу. Поэтому эту технику следует применять, когда на странице не очень много изображений. Источник — pepelsbey.net/pres/clear-and-sharp/.

Немного дополню:
— Желательно подключать jQuery с гугловых серверов, т.к. для большинства пользователей она возьмется из кеша.
— Если на странице нужно следить за 100500 элементами, лучше навесить обработчик на их контейнер и пользоваться всплытием событий.
— $("#foo") на все случаи жизни может не хватить, а вот вместе $(".bar"), который эквивалентен getElementsByClassName, получается минимальный боекомплект для очень быстрого доступа к DOM, конечно если скорость критична. Лично мое мнение, что лучше добавить к элементу лишний id-ик или класс, чем подключать XPath.

При оценке размера решения jQuery + плагины, нужно иметь в виду, что если тянуть jQuery, например, с Гугловых серверов, то с очень большой долей вероятности сама библиотека уже окажется в кеше браузера.

И чем больше программистов в проекте, тем больше отражений этих самых вредных привычек в коде.
К счастью, правильно организованный сode review делает мир лучше.