Артем Комаров

Как минимум fs.rename у вас асинхронная и вы тут же делаете удаление файла синхронно, логично, что rename будет нечего перемещать.

P.S. использовать синхронные функции - моветон (плюс падение производительности). Лучше перепишите на асинхронные с контролем выполнения.

Вы не дожидаетесь событие коннекта. Вот вам для примера:

var socket = io(); // не стоит ждать загрузки всего документа, сокет должен успеть "открыться" к событию "document ready"

socket.on('joined',function(){
	window.location.replace("/room");
});

socket.on('connect', function () { // Вот теперь emit будет работать сразу
	$( document ).ready(function() {
		$('#create').click(function(){
			socket.emit('Create room',(socket.id).toString());
		});

		$('#join').click(function(){
			socket.emit('join',$('#roomID').val());	
		});
	});	
});

GNU coreutils
git.savannah.gnu.org/cgit/coreutils.git/tree
Это те самые ls, chown, uniq, с которыми люди сталкиваются каждый день работая в консоли. Множество маленьких "проектиков", обильно прокомментированных и уже хорошо оттестированных "на кроликах". Каждая конкретная утилитка выполняет маленькую понятную задачку, но в реальном коде вскрываются множество тонкостей, о которых в базовых учебниках не пишут, а знать надо.

А не проще ли было использовать async.map?

var sql = "getByCityes";
async.map(array, function (item, cb) { 
  procedure(item.mon, item.tue, item.wed, item.thu, item.fri, item.sat, item.sun, item.buksumm, item.ID, sql, cb);
}, function(err, results){
    if(err) console.log(err);
    console.log(results);
  });
};

Под мобильные устройства тестирую с помощью стандартных функций браузера (Firefox & Chrome это умеет в devtools)
Так же есть такая штука - ami.responsivedesign.is
Доступные размеры:
настольный монитор — 1600 x 992px;
ноутбук — 1280 x 802px;
планшет — 768 x 1024px;
мобильный телефон — 320 x 480px.

Так же есть это - deviceponsive.com
Устройства и доступные разрешения экранов.
Macbook — 1280 x 800
iPad портрет — 768 x 1024
iPad портрет — 1024 x 768
Kindle портрет — 600 x 1024
Kindle альбомная ориентация — 1024 x 600
iPhone портрет — 320 x 480
iPhone альбомная ориентация — 480 x 320
Galaxy портрет — 240 x 320
Galaxy альбомная ориентация — 320 x 240

Ну и мой любимый - quirktools.com/screenfly
Доступно 9 больше чем планшет устройств — от 10" ноутбуков, до 24" мониторов, 5 планшетов, 9 телефонов, 3 телевизионных разрешения, а также произвольное разрешение. Есть отдельный переключатель в портретный и альбомный режим, а также опция показа прокрутки.

1) Эмуляция мобильных устройств в devtools в хроме и firefox
2) Эмуляция старых IE в Edge
3) https://www.browserstack.com/

Ну и регулярно вручную смотреть, где есть возможность, да.

Под jsfiddle не удалось таки запустить.
Но вот вариант делающий вид что работает: plnkr.co/edit/iNTPWJOuQhVtC84SaQ6C?p=preview

для чего нужны директивы

Для всего. Директивы дают вам инструмент, позволяющий изолировать элементы UI-я в самодостаточные компоненты, расширять HTML, добавлять новые элементы со своим поведением, расширять поведение имеющихся элементов новыми атрибутами... Директивы ангуляра послужили прообразом стандарта о web-компонентов, это очень гибкая штука, которая позволяет полностью избавиться от выборок элементов и навешивания на нее логики, за счет чего код сильно упрощается.

где их применять

Везде где только можно, весь UI следует строить на иерархии директив, как если бы вы просто верстали. Я бы даже сказал что использовать только контроллер, как например можно увидеть в примерах для ngRoute/uiRouter и шаблон - это плохо, контроллеры и шаблоны использовать можно, но только для того что бы определить какие в рамках этого роута/стэйта будут использоваться директивы и передать туда параметры. То есть по максимуму все запихивать в директивы. Правда это может быть первое время сложно делать, потому лучше постепенно увеличивать степень дробления UI на директивы. Главная сложность сделать так, что бы директивы были независимы от контекста использования. Ну или явно определить этот контекст (параметр require директивы может определять что директива A может быть использована или должна быть использована только в контексте B). Ну и еще по началу может быть сложно определиться что должно быть в link и что должно быть в контроллере, должен ли вообще у директивы быть link или контроллер.

ng-inject

вы про галповский плагин или все же про ng-include? если последнее, как комбинация ng-include + ng-controller, то это тип... для ленивых. При помощи этих двух директив мы можем создать какой-то элемент, присобачить ему поведение и шаблон, да, но оно не будет изолированным, реюзать такое уже не выйдет. Если это вам надо временно, и вам лень - то можно и так, но лучше сделать полноценную директиву, тогда ее можно будет реюзать в рамках проекта и устранить дублирование. Ну и опять же, вариант с ng-include+ng-controller можно покрыть только E2E тестами, что не удобно. Директивы же просто и удобно покрываются юнит тестами, что делает поддержку системы намного проще и дешевле.

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

Посмотрите на polymer, это то чем должны были бы стать директивы а ангуляре (и в angular2 оно почти так), там больше ограничений и более понятно как использовать web-компоненты и как следствие - директивы.

При конвертации png картинки в jpg весь прозрачный фон превращается в черный (что за идиотизм)

А в какой должен? jpeg не поддерживает прозрачность.

Поискал в гугле такую проблему, там все работают с изображением через shell-консоль, а я через модуль в npm и никакого решения найти не смог.

Надо было посмотреть мануал на GraphicsMagick и использовать соответствующий метод (background) модуля.

gm(image).background("#FFF").stream("jpeg", cb);

А версия какая? Они там типа кэш запилили... так что нужно отлавливать по ивентам либо отключить кеширование.

var ids = _.pluck(collection.models, 'id');
collection.fetch({
  data: {
    ids : ids.join(',')
}
});

а зачем вам JQuery если вы его не используете?
.html(0)

Рабочий код

var n = 3;
var n4 = n*n*n*n;
var cells = [];

function declare_grid()
{
    document.writeln('    <div class="grid-container">');
    for (var i = 0; i < n4; i++)
    {
	document.writeln('        <div class="grid-cell" id = "grid-cell'+i+'"></div>');
    }
    document.writeln('    </div>');
        for (var i = 0; i < n4; i++)
    {
	cells[i] = document.getElementById('grid-cell' +i)
        cells[i].style.backgroundColor = "#258";  // этот код работает
    }
    //    cells[0].innerHTML = '0';   если убрать комментарий не работает
   //     document.getElementById('grid-cell0').innerHTML = '0';   тоже не работает
}

function grid_initialize()
{
    // Те же самые инструкции попробовал. Результат такой же
     //    cells[0].innerHTML = '0';   если убрать комментарий не работает
   //     document.getElementById('grid-cell0').innerHTML = '0';   тоже не работает
}

Сила в том что все знают JS. Кто может писать на PHP/Ruby/Python? Те кто пишут на PHP/Ruby/Python соответственно (и скажем по 10%-15% от количества каждых кто может писать хотя бы на двух из трех языков. Кто может писать на JS? Все фронтэндеры + добрых каких 60%-70% от всех этих php/ruby/python/java/c# разработчиков...

Что это дает? ОГРОМНЕЙШЕЕ комьюнити... большая часть быдло конечно но засчет огромнейшего количества разработчиков инструментарий начал просто очень быстро развиваться. Кому нужен инструмент написанный на Ruby если его можно написать на JS и его сможет поддерживать на порядок больше людей?

Вопрос производительности по началу стоял как основная фишка языка. Все кричали наконец-то, V8 на сервере, асинхронность! Самый быстрый интерпритируемый язык на планете и все такое. Но на деле все чуть сложнее. JS реально быстрый. По сравнению с тем же Ruby он в разы быстрее! Но по большому счету на это адекватным людям плевать с высокой колокольни, так как js нифига не асиинхронный. JS работает в один поток. Причем в этом же потоке работает и сборщик мусора. Если он начнет все чистить - все замрет. Обычно это не сильно большая проблема но как-то забавно. Асинхронное в JS только работа с IO которая на плюсах/си реализована...

Революционности так же нету. JS на сервере не новая идея и практиковался еще лет за 5 до. Просто это была очень удачная реализация да ктому же если бы не V8 то так же все было бы не так круто.

Что до сравнения с PHP и т.д. - это инструменты для разных сфер. PHP - разработка web-сайтов. node.js - демоны, инструменты разработки, шины данных, доставка данных и т.д. Для всего остального PHP подходит больше. Есть правда пара интересных проектов главная цель которой устранить дублирование кода на сервере и на клиенте.... но подходят эти наработки пока только для очень простых проектов (хотя все относительно).

Если вас прям плющит от нового, быстрого, современного, с клевым дизайном и тоже где повлиял гугл - golang.

в вк в документах есть дофига книг, в том числе та, которую вы ищите

Чтобы создавать свои плагины, Вам нужно:
- хорошо знать JS и его подводные камни;
- знать, что такое шаблон "модуль" и уметь писать свои модули;
- помнить, что jQuery.fn - всего лишь псевдоним для jQuery.prototype; добавляя свою функцию к этому свойству, Вы расширяете прототип функции jQuery, и важно ничего там не сломать;
- следовать соглашению, по которому любой плагин jQuery на выходе должен вернуть исходный или модифицированный массив переданных на вход элементов (шаблон "цепочка", есть ещё антишаблон, следующий из этого, называемый "крушение поезда")

Собственно, вот Вам заготовка модуля:

(function ($){
    "use strict";
    function myFunction(items){
        return $(items).each(function(){
            $(this).text("Hello, jQuery!");
        });
    }

    $.fn.hellojQuery = myFunction;
}(jQuery));