14 советов по написанию чистого React-кода. Часть 2

Хуки конечно имеют как свои плюсы, так свои и минусы.
И было бы отлично, и интересно посмотреть, на неправильное использование функциональных компонент, с небольшими примерами. А если будет объяснение, "почему именно так делать плохо", то сообщество пополнится правильными знаниями.

Redux: отправляем асинхронность туда, где ей самое место

Так же можно посмотреть на redux-api-middleware

Xperia Z3+. Тоньше, легче и быстрее

Вот скажите, а этот обновленный Z3, такой же хрупкий как и старая модель? Я уже потерял все надежды на то что смогу нормально пользоваться своим Z3 compact.
Первое падение было из рук(120-140см) на идеально ровный бетонный пол. Задняя крышка вся пошла трещинами. Весь экран покрылся поутинкой трещин. При этом не было проблем с изображением, но тач перестал работать. Про стоимость ремонта и отвратетильное качество ремонта — я молчу.
Второе падение было так же из рук, но уже на паркет(!!!). Задняя крышка — в паутинку из трещин. Экран похоже спасло то, что телефон упал ровно на заднюю крышку.
Настолько хрупких телефонов, я ещё не встречал. До этого были нексусы, которые переживали более серьезные падения без каких либо повреждений, либо с незначительными царапинами.

Я использовал робота, чтобы ходить на работу на удалении в 3500 миль

Отличная ссылка для твиттера.
Но зачем здесь побликовать в таком формате? Если бы вы перевели исходную статью или описали своими словами, то было бы информативней.

Google придется вернуть руль и педали в свои роботизированные автомобили

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

Ожидающая функция fnDelay

Да, в jQuery такой функции нет. Как и множества других полезных функций которые присутствуют в underscore/lodash. Конечно же, ради одного debounce, не совсем рационально подключать дополнительную либу, но в них есть не менее полезные функции: values, invert, extend, pick, omit, clone, uniqueId, итд.

Ожидающая функция fnDelay

Зачем изобретать велосипеды, если уже существует реализация в большинстве подключаемых библиотек? Например: underscorejs.ru/#debounce и lodash.com/docs#debounce

Постим новости с картинкой в группы Вконтакта (Perl)

На выходе должен получиться хеш. И совершенно не важно в каком порядке контак отдаст параметр.

Постим новости с картинкой в группы Вконтакта (Perl)

# Парсим url и достаём из него все параметры

Зачем же так сложно и не понятно? Почему бы не сделать map {split("=")} split("&", $str)?

Переменное количество аргументов: проблемы и решения

Нет нужды в магии или «языке определения параметров»

Это скорее минус, чем плюс. Если уж возникла ситуация когда необходимо написать функцию принимающую на вход различное кол-во аргументов, то я хочу быть уверен, что аргументы окажутся на своих местах, в зависимости от типов данных. Беглый поиск по модулям показал что rearg умеет это делать, обладая синтаксисом аналогичным vargs-callback.
Но я не понимаю проблемы передачи разного кол-ва аргументов. Можно взять за правило, что если не знаешь cколько аргументво нужно — все аргументы передавать в объекте: func(params:Object, callback:Function)

AngularJS 1.2.0: Своевременная доставка

Действительно странное решение. Были же переменные, которые начинались с $ и $$, которые по сути и являлись приватными. Не совсем понимаю, зачем было добавлено новое поведение для переменных с _.

Angular.js vs Meteor.js vs Derby.js

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

RESTful API на Node.js + MongoDB

Если я не ошибаюсь, то express по кол-ву аргументов определяет что это функция обработки ошибок. Было бы три аргумента у функции, то это был бы обычный middleware со следующими параметрами: req, res, next
А уж использовать next внутри функции, или нет, это на усмотрение разработчика.

RESTful API на Node.js + MongoDB

Очень удобно использовать app.param. Плюс бонус, один хендлер вместо двух на обновление и добавление статьи.

var underscore = require('underscore');
app.param(":articleId", function(req, res, next, articleId){
    ArticleModel.findById(articleId, function(err, article){
        if(err || !article) {
            return next('route');
        }
        req.dbArticle = article;
        next();
    });
});

app.post("/api/articles/:articleId?", function(req, res, next){
    if(!req.dbArticle) {
        req.dbArticle = new ArticleModel();
    }
    req.dbArticle.set(underscore.pick(req.body, 'title', 'description', 'author', 'images'));
    req.dbArticle.save(function(err, article){
        // ..............
    })
});

Node.js не подходит для типовых веб-проектов

Callback hell это не только лесенка в коде, но и то что ошибки приходится эскалировать. Coffeescript помогает сократить письмо до приемлемого уровня, но всё равно каждый раз приходится писать: return callback(err) if err?.
Наверное вы правы, что это совершенно другая проблема. Вот только я не до конца понимаю какая. Можете объяснить чем принципиально отличается идеология обработки ошибок в ноде, с идеологий обработки ошибок в пхп?

Node.js не подходит для типовых веб-проектов

Блокирующих вызовов в ноде не используется. Заблокировать поток совершенно просто. Достаточно элементарного «while(1){}».

Node.js не подходит для типовых веб-проектов

Да, именно так это и называется — callback hell. Ошибки, как правило, эскалируются вверх до определенного уровня, и там уже обрабатываются.
Обработкой исключений (try..catch, throw), используется редко, при этом только для синхронных операций, чтобы потом поймать и в асинхронном стиле передать ошибку.
От callback hell в скором времени можно будет избавиться, используя generators описанные в черновике ECMAScript 6. Они уже есть в unstable node.js v0.11.

Node.js не подходит для типовых веб-проектов

Нет практически никакого смысла запускать запросы к бд в разных узлах кластера(ядрах процессора), т.к. основное время уходит на ожидание ответа от бд. Другое дело со сложными мат вычислениями — их логичнее запускать параллельно в разных ядрах. Но сложные вычисления, это не типичная задача для Node.js. А со своей основной задачей — обслуживание большого количества клиентов, node.js справляется вполне удачно.
Несомненным плюсом является как раз отсутствие реальной асинхронности, т.к. не приходится заботиться о синхронизации и локах.

Node.js не подходит для типовых веб-проектов

А я бы в любом случае посмотрел бы на ваше решение — очень интересно.

Node.js не подходит для типовых веб-проектов

Замедление при использовании async? С одной стороны, вы конечно же правы. С другой стороны, это трудно назвать задержками, на фоне хотя бы одного запроса к бд.
Точно так же можно «экономить» на уменьшении кол-ва вызываемых функций. И уж ни в коем случае не использовать наследование и классы.