copal

В конфиге /etc/mongod.conf есть строки

# Listen to local interface only. Comment out to listen on all interfaces. 
bind_ip = 127.0.0.1

По умолчанию (раньше, по крайней мере) bind_ip было закомментировано. Как видно из комментария, сервер действительно слушал все интерфейсы и принимал соединения со всех адресов. Опасненько было. Если строка не закомментирована, то всё тип-топ, соединение возможно только локальное. У меня на VDS операционная система Debian, там такого ни разу не видел.

win->ccs
окно->свойства ccs

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

1. docker-окружение
(в 90% случаев для веб-разработки достаточно php -S 0.0.0.0:8000)
виртуальные машину становятся нужны:
- когда надоест переустанавливать хост-систему из-за обилия хлама
- когда работаешь с несколькими проектами имеющие специфические (разные) настройки окружения(php, web-сервер, база)
- когда надоест решать проблемы в команде из-за того что по разному настроено окружение

2. git - система контроля версий
Помнить что ты и когда изменял, должен не человек, а машина.
Это необходимо:
- чтобы не испортить всю работы за прошедший год нажав del
- чтобы определить кто из команды злодей и все испортил
- чтобы не думать как перенести свежую версию проекта с одной машины на другую

3. composer - пакетный менеджер для php
Нужно, когда лениво помнить все ссылки на все php библиотеки, самому качать их, подключать в автозагрузку

4. behat + phpspec
Тесты нужны:
- когда хочется почувствовать себя безопасности и для сладко спать ночь, забыв о кошмарах о сломанном коде
- когда в production все снова сломалось
- когда ты написал одну новую фичу, а сломал три

5. zsh
Хорошей консолью приятно пользоваться, работа идет быстрее.
Консоль есть жизнь, жизнь есть shell.

6. tmux
Мало одно окошка в консоли, тогда tmux идет к вам.
В качестве бонуса получите возможность парного программирования совершенно бесплатно

7. tmuxinator
Надоело каждый раз открывать кучу окон для tmux, попробуйте его )
8. vim
- Потянуло на что-нибудь необычное?
- Хочется эффективнее писать код ?
Ну что открыли vim? В первый раз? Поздравляю закрыть вы его не сможете )
Вызывает зависимость при частом потреблении

9. continuous integration сервер
Вообще ci сервер это одушевленная машина. Это твой тамагочи, ты кормишь его хорошим кодом, он радуется и ты видишь приятный зеленый огонек. Если ты дал с код от скажет что не вкусно. Ну а если ты ему, что гнилое он будет долго на тебя орать плохими словами. Со временем он растет и учится делать более серьезные вещи, и начнет помогать тебе:
Его скилы:
- он может сам выполнить 10 минутные тесты
- подготовить и опубликовать проект
- рассказать о твоем коде, даже то что ты не знаешь
Он легко обучается и ты легко сможешь научить его удивительным вещам.

10. куча линтеров на pre commit hook
Чтобы ci не кормить плохими продуктами, хорошо бы проверять что ты сделал до отправки на сервер. Что бы не забыть это сделать git сам работу.

11. gulp
gulp - это еще один твой помощник.
как если использовать, как watcher файлов + livepreview, можно забыть о F5 в браузере

12. bower
Тоже что и composer но для управления ассетами. Это я о всяких jQuery и Bootstrap

666. Линукс
Даже если не хочется ставить как хост-систему, его все равно надо знать. Ваш код будет работать на нем )

Docker или Vagrant + Ansible/Puppet для окружения.

PhpStorm(IDE)+lamp(сборка сервера)+composer(менеджер пакетоа)+git(контроль версий)

но тогда у полозователя не будет возможности сделать что-то самому

Я уже вам написал в комментариях к другому вопросу но продублирую. Когда пользователь выбирает какой-то другой вариант сортировки или фильтрации, мы просто уведомляем контроллер об этом. Тот уже будет просить сервисы что бы тот предоставил данные согласно нашим новым условиям. Сервис все это сделает и вернет нам данные в контроллер. Мы чуть чуть может еще подготовим данные под наше представление и выплюнем во view (по сути данные попадают в $scope). Далее за счет дата биндинга view реагирует на изменение состояния данных и подстраивается под них согласно вашему описанию (все эти ng-repeat и т.д. Не спроста шаблоны в ангуляре называют декларативными).

Это собвенно и есть MVC, при таком подходе нашему view будет глубоко плевать на реализацию фильтрации, а нашей модели (логике по работе с данными) плевать на то как эти данные выводятся. А контроллер будет лишь посредником который будет знать как эти два слоя связываются друг с дружкой.

updated

Решил сделать пример, на который буду ссылаться дальше:

Пример

А теперь немного поясню зачем вообще так загоняться и когда допустимо фильтровать все в контроллере или вообще во вью, что бы небыло недопонимания.

Давайте представим что мы мысленно раздели наше приложение на два слоя: слой который работает с данными (M), и слой который занимается отображением этих данных пользователю (V), ну и посовместительству хэндлит взаимодействие пользователя с этим view (формы например).

Что бы упростить поддержку системы, нам надо снизить связанность этих двух слоев, сделав их максимально независимыми. Что бы изменения в одном слое не вызывали особой необходимости менять что-то в другом. Для этого мы вводим промежуточный слой - контроллеры (С). Это по сути и есть основная идея MVC. Разделяй и властвуй.

Теперь давайте задумаемся. Вот вы делаете каталог товаров по схеме аля "загружаем все данные на клиент и там все фильтруем". И все идет хорошо, мы быстро все запилили и вот данных становится уже сильно много. Настолько много что приложение начинает пидалить или же просто загрузка всех данных занимает чудовищно много времени. И вот вы приняли решение о том что фильтрация теперь будет происходить на сервере, а вы будете загружать только то что нужно сейчас.

Если у вас работа с данными уже была разделена сделать это не составит проблем. Мы просто поменяем наш ProductCatalog и заменим там методы на нужные нам. View от этого не поменяется ни сколички. Более того мы можем спокойно покрыть этот функционал быстрыми юнит тестами.

Но есть еще такая штука как "технический долг". Это когда нам надо запилить этот самый фильр в первый раз, к вам подходит клиент или менеджер и говорит "нет времеин объяснять нужно срочно еще позавчера". И у нас тут выбор:
- спорить с заказчиком о том что надо делать все правильно
- плюнуть и сделать максимально быструю реализацию, таким образом взяв у нашего кода "взаймы". То есть все работает но в будущем нам этот долг придется вернуть. Мол решили мы потом перенести фильтрацию на сервер и времени на это уйдет уже больше, так как когда-то мы сэкономили на разработке.

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

Но вернемся к реалиям anuglar-а. Дело в том что когда вы используете фильтры в шаблонах, они будут дергаться на КАЖДЫЙ $digest цикл, так работает дата биндинг. То есть при относительно небольшом объеме данных у нас приложение уже будет жутко педалить. Потому использовать фильтры с коллекциями в шаблонах простительно только если вы на 100% уверены что данных пока будет мало, а потом можно будет переделать.

Как-то так. Поскольку у вас есть возможность использовать ангуляровские фильтры внутри сервисов или контроллеров, "экономный" вариант будет занимать не больше времени разработки и поддерживать такой код будет проще.

вы всегда можете использовать свой сертификат для организации шифрованного соединения. Это есть и в PHP и в Node.js. Гуглить - TLS в контексте того что вы используете.

Хороший пример - организация работы с серверами APNS (Apple push notifications). Можете посмотреть как реализован клиент для оного, они есть и для ноды и для пыха.

Но поскольку речь идет о POST запросах, то все сводится к старому доброму HTTPS со своими сертификатами.

Никак.

Через this._handler.bind(this) не работает потому что Function#bind возвращает новую функцию (причем каждый раз разную, т.е.

this._handler.bind(this) !== this._handler.bind(this)

).
Соответственно, надо как-то так:

this.boundHandler = this.handler.bind(this);
window.addEventListener(eventType, this.boundHandler);
//...
window.removeEventListener(eventType, this.boundHandler);

Ну естественно можно написать какую-то обертку. Например:

function bound (eventType: string, handler: Function, context: any): Function {
    var boundHandler = handler.bind(context);
    window.addEventListener(eventType, boundHandler);
    return () => window.removeEventListener(eventType, boundHandler);
}

Такая функция вернет функцию, которая при вызове отвяжет ранее привязанный обработчик.