Новый WebStorm 9: просто лучше. Поддержка Meteor, React и JSX, интеграция с Gulp, PhoneGap и многое другое

Может кто-нибудь сказать почему WebStorm при срабатывании точки останова в node.js иногда очень долго вычисляет переменные? Иногда процесс вычисления затягивается «навсегда».
Например, я заметил, что переменные в которых лежит Buffer с большой вероятностью очень долго «раскрываются».

Семь принципов создания современных веб-приложений

У меня тоже. Хотя это и перевод, это нисколько не умаляет проделанного труда.

Как мы делали аналитику для высоконагруженного сайта

1. fs.exists — проверка на существование файла
2. Что Вам помешало написать вместо этого

image = fs.readFileSync('p.gif');

вот это

fs.readFile('p.gif', function(err, data){
  if (err}{ return; // TODO }
  image = data;
});

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

Как мы делали аналитику для высоконагруженного сайта

Глаз зацепился, не могу оторвать…

image = fs.readFileSync('p.gif');

… прям в середине асинхронного кода.

Как это понимать?

Тонкости nodejs. Часть I: пресловутый app.js

В реальности так и делаю, здесь просто для краткости.
Хорошо, что отметили, пусть останется для читателей.

Тонкости nodejs. Часть I: пресловутый app.js

Не совсем понял где Вы увидели у меня смешение интерфейса и логики? Может в моём коде не хватает комментариев для лучшего понимания…
1. Код конроллёров полностью вынесен из http-интерфейса. Я отметил в коде, что каждый контроллёр находится в отдельном файле и список его входных параметров чётко обозначен. Это даёт им хорошую тестируемость и переиспользование.
2. Код http-интерфейса практически не растёт с ростом методов. Увеличивается только модель интерфейса (в коде это routes). Таким образом отпадает надобность его тестировать вообще.

В вашем варианте у Вас всё-таки остаётся код в интерфейсе.

server.get('/file', function(req, res, next){
    app.file(req.query.file, function(err, file){
        if (err) return next(err);

        res.type('text/plain').end(file);
    });
});

Вам придётся написать на него тест. Но в таком варианте Вы этого сделать не сможете. Это довольно сложно. А сложных тестов быть не должно.

Поправьте, если я что-то не понял.

Тонкости nodejs. Часть I: пресловутый app.js

Вы только в начале пути. В последнем своём проекте, о котором я напишу после его окончания, я сделал следующее:
1. Разделил собственно приложение (настройка express app) и функции, которые обрабатывают запросы (назвал их контроллёрами)
2. Функции-контроллёры получают список входящих параметров с помощью инъекций по полной аналогии с angular framework.

Т.е. просто применил MVC шаблон. Это реально освободило меня от шаблонного кода и я больше сосредоточен на логике функций-контроллёров.

Если схематично, то получается следующее:

// listCtrl.js
module.exports = listCtrl = function(request, response, app) {
};
listCtrl.$inject = ['request', 'response', 'app'];

// fileCtrl.js
module.exports = fileCtrl = function(request, response, app) {
};
fileCtrl.$inject = ['request', 'response', 'app'];

// app.js
var routes = [
  {
    path : '/',
    method : 'get',
    controller : require('./controllers/listCtrl.js')
  },
  {
    path : '/file',
    method : 'get',
    controller : require('./controllers/fileCtrl.js')
  }
];

// middleware которая набивает маршрутами и обработчиками express по модели, делает инъекции при вызове контроллёра и т.д.
express.use(router(routes));

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

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

Но мы надеемся, что люди, которые не ходили в кино, боясь очередей или общения с кассирами

Таким людям только хороший психоаналитик поможет, а уж точно не Smartpass.

Pooling соединений к базе данных на node.js

Раз уж исходники на GitHub`е, зачем Вы продублировали эти простыни на хабр, и даже под спойлер не убрали?

Bundle Transformer: Летние обновления

Борьба с ветряными мельницами все эти бандлы в ASP.NET. На каком этапе развития находится технология, по сравнению с grunt/gulp?

Пишем тестопригодный javascript

Избегайте создания приватных свойств с помощью замыканий

Подобные советы, автору поста не плохо бы оставить при себе и не мутить воду. Публичный интерфейс класса (объекта) должен быть самодостаточным для использования и не должен содержать ничего лишнего (всякие _foo и т.д.). Для чего нужно тестировать приватные части алгоритма ума не приложу. Что он хочет выяснить таким тестом? Что приватный код работает правильно? Это не даёт никакой гарантии, что публичный метод, который его использует, тоже будет работать правильно. Тестировать нужно только публичные методы. Только это даёт гарантию.
Вместо подобного совета, я бы лучше порекомендовал использовать тулу для анализа покрытия кода тестами. Пользы вагон, и, к тому же, при её использовании, многие вопросы по поводу внутренней жизни приватных функций отпадают сами сабой.

Сюрреализм на JavaScript. Советы по разработке на NodeJS

Не спорю. Синхронная работа возможна во время первоначальной загрузки (если точнее, до первого асинхронного вызова). Так же как впрочем не страшны и throw в этот момент. Но как только приложение сделало асинхронный вызов, например, начало читать сокет, после этого всё: никаких синхронных вызовов и throw.

Сюрреализм на JavaScript. Советы по разработке на NodeJS

Совет 1. SQL запросы лучше хранить отформатированными
Совет 2. Жизнь становится проще, когда API различных компонентов принимает на вход любой формат

Общий совет, подойдёт к любому ЯП.

Совет 3. Разукрасьте консоль и отформатируйте вывод информации

Как только Вы наиграетесь с консолью и начнёте весь лог укладывать в БД, Вы откатитесь к первоначальному нечитаемому логу. Решение более сложное. В development окружении сойдёт консоль, в production — уже нужно прибивать любую раскраску.

Совет 4. Оборачивайте все API в try/catch

Не используйте throw в runtime и не нужно ничего оборачивать. Используйте принятый стандарт записи callback-функции. function callback(err, result).

Совет 5. Собирайте запросы в конфиги
Совет 6. Выносите все в конфиги

Общий совет, подойдёт к любому ЯП.

Совет 7. Работа с файлами и Модуль Social Link для СЕО

Не понятно при чём здесь node.js вообще. Но вот следующее, я бы охарактеризовал как вредный совет:

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

Вы нарушаете саму идеологию асинхронного ввода/вывода, за что Вам будет больно.

Совет 8. Без callback`ов жизнь проще

Тоже в раздел вредных советов. Используйте callback`и. Не нравится, или говнокод получается — вас спасут promise`ы. Или не пишите на javascript, найдите другой язык… без колбеков.

Итого:
4 общих совета по программированию вообще. Даже не знаю зачем они, это приходит с опытом;
1 совет так себе, буду считать, что полезный (про консоль). Вреда от него не будет;
1 бессмысленный совет использовать try catch в асинхронном потоке исполнения ( скорее вредный );
2 совета вредных для javascript в принципе. (синхронная работа с вводом/выводом и боязнь коллбеков);

RabbitMQ — отложенные сообщения

Что происходит, если я закладываю в очередь два отложенных сообщения с разным TTL? Например: Message 1/ TTL 1000, и сразу за ним Message 2/ TTL 500.

P.S. Пардон, когда набирал, первого комментария ещё не было.

Ускоренная разработка веб/мобильного приложения

Какие у Вас были мотивы не использовать готовые build системы (grunt/gulp), а писать самопальный скрипт?

Deb.js: самый крохотный отладчик в мире

Присоединяюсь к комментарию @DenAmir.
Я не понимаю, это тонкий троллинг автора или что? Вместо пошаговой отладки автор предлагает прикрутить сомнительный костыль, который идёт вразрез с best practice.

Секретные записки в коде

Стараюсь придерживаться правила: «Почему это делается»

Книжка Discover Meteor переведена на русский

На заметку: пока что Meteorite не поддерживает ОС Windows

Убило всё желание. Javascript как бы… господа.

Анализируем Хабрахабр с помощью Google Page Speed

Спасибо за обзор.

Оставьте ссылку на свой профиль — и добавьте к себе одного хабражителя

Javascript: AngularJs, Node.js
brainstorage
github