Смысл — это иллюзия

По переводу:

Скорее всего это самая важное, что я когда-либо писал, т.к. я считаю, что нашёл ни что иное, как смысл жизни, или его отсутствие.

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

По тексту:

Мы знаем, что эмоция, и даже духовный опыт, по своей природе химические события.

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

Построение модульной системы на основе Nodejs

В инфрастуктуре ноды/npm очень много пакетов, которые состоят из пяти строчек, но, тем не менее, делают жизнь лучше. Я рекомендую узнавать про такие штуки и пользоваться ими, потому что они перекладывают часть технических проблем на пакеты, позволяя сосредоточиться на значимых вещах.

Лично я не пользуюсь require-dir, и этим подходом вообще. Я предпочитаю создавать файл index.js и вручную в него подключать все субмодули. Снаружи можно просто подключать директорию, в этом случае читается индексный файл. Это позволяет прогонять код через бандлеры CommonJS. Да и явное лучше неявного.

Построение модульной системы на основе Nodejs

//лист всех файлов в директории

Можно подключать директории с помощью require-dir. Есть несколько пакетов, которые справляются с этой задачей, например require-dir.

Китайцы построили 57-этажный небоскреб за 19 дней

В районе 3:25 на видео мимо пролетает Звезда Смерти.

Еженедельник io.js, 6 марта 2015

Статья одной фразой: у нас всё хорошо, а что нехорошо, то будет хорошо.

Некоторые тонкости работы с Github и NPM — со вкусом ES6

Так как никакой компиляции в действительности не происходит, то слог «ком» действительно лишний. Так что «транспилятор» или «транспилер» это более верный перевод. В этом поддерживаю оратора выше. Хотя перевод не идеальный. К примеру, я не уверен, что говорить «транспилер» в целом верно, просто потому что сейчас многие так говорят, но лучшего перевода нет. Чуть более длинный термин «транспиляция» тоже сути не передаёт. Говорить «трансформация над кодом» слишком длинно. Рискую привлечь Мицгола в тред, но, вероятно, если бы кто-то и правда заморачивался корректным переводом, то у него получилось бы что-то вроде «кодопреобразования».

Некоторые тонкости работы с Github и NPM — со вкусом ES6

Везде где возможно, npm должно писаться строчными буквами и начинаться со строчной буквы, даже если стоит в начале предложения. Иное допустимо только если строчные буквы недоступны (например, на man-страницах).

Канадца осудили за непредоставление в аэропорте пароля к своему смартфону

Чертёж пистолета, для распечатки на 3д-принтере :)

Google собирается построить «стеклянную утопию» в Маунтин-Вью

Кроме Google, сейчас масштабное строительство проводят Apple, Facebook и LinkedIn.

Цитадели Добра.

Практика функционального программирования на JavaScript с использованием Ramda

Вполне возможно. Такое неприятное ограничение на конструктор имеет место быть.

Правда, существует и для этой неприятности обходной манёвр:

function make () {
  var instance = Object.create(class.prototype);
  class.apply(instance, arguments);
  return instance;
}

Практика функционального программирования на JavaScript с использованием Ramda

При этом они сами приводят пример такой композиции выше:

return getItems()
    .then(R.pluck('cost'));

Практика функционального программирования на JavaScript с использованием Ramda

Подтверждаю. Интересно, откуда у автора возникла такая строка? А переводчик не проверил.

Возможно, в старых версиях было такое ограничение.

Я сразу полез проверить, может там применена страшная оптимизация, с развёрткой кода в «китайский стиль», но нет, всё чисто.

Решение задачи сброса тяжелой логики на одну из множества открытых вкладок

Что используется в качестве идентификатора вкладки?

node-seq на новый лад (опять про асинхронность)

Рекомендую обратить внимание на Highland. Он несовместим с node-seq, как ваша библиотека, но в целом очень интересен, например, умеет принимать всё, от массивов до функций, промисов и потоков ноды. Просто ознакомьтесь с некоторыми решениями, очень интересная либа.

А по поводу отлова ошибок я бы хотел развеять ваше предубеждение, что их поведение неочевидно. Как правило, по взгляду на код можно определить как срабатывают catch, есть простое правило:
1. catch отлавливает все ошибки, возникшие выше него.
2. Если отработавший catch не выбросил ошибку сам, то она считается отловленной и следующие обработчики ошибок не срабатывают.
3. Если же он породил новую ошибку, то она будет передана ниже.
Так это реализовано в Promise и это очень наглядно (и тут полная аналогия с синхронным try-catch, только без многих уровней вложенности). Я думаю в node-seq такой же механизм, поэтому задавал вам уточняющий вопрос.

node-seq на новый лад (опять про асинхронность)

мы программируем только оптимистичный случай когда все работает как надо

Да, понял стратегию. Это достаточно просто и наглядно, и ещё я думаю более производительно в реализации.

Оригинальную библиотеку я не использовал, потому у меня и возник такой вопрос. Я много использую Promise, но от основной идеи далеко не уйдёшь, асинхронный поток он и есть поток. В вашем примере указан как раз perEach, как я понял из документации, он-таки дожидается результата. forEach — нет, но в документации не сказано, что forEach сам может быть эмитентом ошибки. Вероятно, forEach нужен для вызова сайд-эффектов, поэтому он не влияет на состояние потока. В других либах для этого есть функция tap или doto.

node-seq на новый лад (опять про асинхронность)

Во-первых, не понятно что делать если [...] выбросят несколько ошибок

Ну тут, очевидно, два варианта. Либо ловить первую, либо собирать их в массив. Promise.all работает по первой стратегии: если один из входов фейлит, то фейлит и их композиция с этой ошибкой. Тут плюс в том, что не нужно дожидаться ответов от всех входов, можно продолжать после первого фейла. И с другой стороны, попробуйте придумать ситуацию, когда нам действительно нужно получить весь массив ошибок? Как правило, нам достаточно того, что ошибка совершилась, и нужно переходить к её обработке. А что там с остальным, так разберёмся, когда этот блок перестанет выдавать ошибку.

А если мы уже ушли далеко вниз а в каком-нибудь parEach выше по таймеру выскочила ошибка?

Я, наверно, не до конца понимаю идею этой библиотеки. Как мы можем «уйти вниз», если ещё не получены все результаты? Документация грит:

parEach waits for all actions to call this() before moving along to the next action in the chain.

Если она ждёт ответа ото всех входов, то она дождётся и любой ошибки.

Поэтому, я решил, что в каждом YAFF должна быть только одна конструкция для обработки ошибок и она должна быть в конце.

Так нельзя, это всё равно что предлагать в синхронном программировании сделать один блок try-catch на всю программу и обязать программистов размещать catch в main. Многоуровневые catch просто необходимы. Например, у нас есть асинхронная либа, которая кормит нас такими потоками (flow). У неё есть внутренние ошибки, например, вызванные отсутствием файлов. Но на выходе, она преобразует невнятные внутренние ошибки в понятные ошибки из своего API. Или ещё пример: либа скармливает нам типизированные ошибки, мы хотим отлавливать их по-отдельности, на разных уровнях. Для всего этого нужны многоуровневые catch.

Смысль финального catch, это отловить все ошибки, чтобы программа хотя бы не падала, но в действительности, может быть ещё много промежуточных catch под более конкретные ситуации.

Операционные системы, потерянные и обретённые внебраузерным джаваскриптом

Хотел бы увидеть рантайм в основе которого был бы SpiderMonkey со всеми модными наворотами. Мне он по какой-то причине видится перспективным. Во-первых: Mozilla, во-вторых: asm.js, в-третьих у них тоже есть JIT. Иногда даже посещают мысли сделать такой самому, по фану, без надежд на какую-либо популярность.

В статье сказано, что клёвые ребята из JSCore делают многопоточный аналог ноды, но вопрос в том как это будет реализовано. С подкапотной точки зрения это может выглядеть по-разному, но я думаю, с точки зрения пользователя должна быть модель сообщений. Не нужно тащить блокировки и прочие прелести в JS.

А ещё бы хотелось вместо node_modules директорию зависимостей назвать .js_deps или что-то в этом роде :)

Translit для JavaScript и ГОСТ-7.79-2000

Начните отсюда:
docs.npmjs.com/files/package.json

Если возьмётесь, могу помочь с оформлением пакета и возникающими вопросами (вопросы сюда в лс).

Translit для JavaScript и ГОСТ-7.79-2000

код и его оптимизация и есть тема обсуждения

Не совсем. Намного лучше было бы, если бы статья представляла целостное повествование, от идеи до реализации, с элементами кода. В духе «здесь я использовал такое решение JS», «здесь пригодилась такая фишка Unicode» и так далее. Обсуждение строится уже на этом повествовании. В конце можно дать ссылку на репозиторий. Кстати, репозиторий необходим не для выпендрёжа, а для коллаборации: чтобы другие могли воспользоваться тем, что вы достигли, либо прислать вам дополнения.

оставил, код под ECMA 3

Это нормально и адекватно в условиях совместимости, и это не противоречит созданию пакета. Пакет нужен не для того, чтобы заточиться под конкретную платформу (ноду, в данном случае), а чтобы формализовать ваши наработки в виде некоторого юнита, у которого будут описаны версия, описание, лицензия, точка входа, что с ним можно сделать, зависимости (если есть). npm, кстати, позиционируется, как пакетный менеджер для всего. И он не прибит гвоздями к ноде, в нём есть поле engines, которое позволяет указать на каких движках пакет работает или не работает. Пакет можно потом преобразовать для браузера.

Кстати, я вчера поискал в npm registry пакет для транслита и не нашёл: два очень старых, неподдерживаемых пакета. Так что ваша работа может оказаться очень полезной, если доведёте до ума.

Translit для JavaScript и ГОСТ-7.79-2000

Транслит это не исключительно задача клиента. Я за CommonJS модули на сервере и клиенте.