Евгений Одинец

array-keys

Можно

select adate, 
       sum(case when val > 0 then val else 0 end) psum,
       sum(case when val < 0 then val else 0 end) msum,
 from mytable group by adate

Открываем документацию php.net/manual/ru/function.ksort.php

Возвращаемые значения

Возвращает TRUE в случае успешного завершения или FALSE в случае возникновения ошибки.

https://github.com/Automattic/mongoose/issues/4291

Добавьте mongoose.Promise = global.Promise; перед mongoose.connect(...)

Это распространенная практика, и если регистратор и хостер нормальные - все будет отлично работать.

var arr = Object.values(obj); // [ 300, 250, 'очко' ]

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

Правило хорошего тона: API класса должен быть доступен только через методы или properties (что, по сути - синтаксический сахар над методами), а поля должны быть только private/protected.

На мой взгляд здесь Laravel пришит сбоку с припеку. Node.js умеет работать с MySQL.
Я бы подобный сервис реализовал следующим образом:
Node.js в качестве основного сервера с API и траспортом данных через Socket.io.
Redis в качестве шины сообщений между инстансами Node.js сервера.
Веб-сокеты позволяют обмен данными и пересылку файлов. Ajax в целом вам тут и не нужен.

IMHO, отправка сообщения должна выглядеть следующим образом:
Node.js принимает сообщение из сокетов, выдает идентификатор сообщению и далее передает его по шине сообщений (Redis). На шине несколько слушателей, один из которых отвечает за сохранение данных в базе, а другие рассылают сообщения клиентам.

Заявка в друзья выглядит следующим образом:
Node.js принимает сообщение из веб-сокетов, сохраняет в базу, отправляет запрос по шине сообщений получателю.

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

Хочу добавить пару моментов, которые нужно учитывать при разработке приложения.
1. У вас может быть запущено несколько инстансов приложения как на одном сервере, так и на разных.
2. Нужно контролировать момент, когда система пытается переотправить сообщение в случае потери соединения с инстансом - часто случается при ненадежном соединении с сетью, особенно в мобильных сетях.

Ну, раз
Cannot set property 'user' of undefined
и
req.session.user = User._id;

видимо, у сессии нет такого свойства, как user.
Ваш, К.О.

Можно так:
https://jsfiddle.net/3rjdbvcy/

К методам messages.* получить доступ могут только standalone-приложения. Это приложения, работающие без помощи браузера. Например, клиенты (официальные приложения VK, Kate Mobile, Snapster и т.д.). А у вас тип приложения "веб-сайт".

Вы ничего не сможете с этим поделать и заставить работать Open API с сообщениями не получится. Единственный выход - кидать пользователя на страницу получения токена в вашем standalone-приложении и просить скопировать его в форму на вашем сайте, а затем уже с сервера с этим токеном делать запросы. Но это плохо влияет на UX хотя бы потому, что на странице, откуда пользователь будет копировать этот самый токен, жирным написано, что копирование токена может быть небезопасным.

но код, особенно после C++, не вызывает каких-то положительных эмоций.

А у меня не вызывает положительных эмоций код на C++. Да и код разный бывает. 90% кода на PHP у меня так же не вызывают положительных эмоций, но писать на нем нормально более чем можно.

1) под фразой "php умирает" позразумевает его модель работы. После каждого запроса он умирает, то есть воркер отчищается и запускается по сути заного. Это существенно упрощает работу (у вас хоть сегфлоты могут быть всеравно весь сервак не умрет), а так же масштабирование (за счет отсутствия у самого PHP состояния между запросами, сессии мы не берем в расчет), но существенно бьет по производительности. К счастью с PHP 5.3 писать демоны на PHP не так уж страшно.

Если же посмотреть рынок и динамику развития сообщества - PHP живее всех живых.

2) PHP не такой уж стремный язык. Я не считаю "не консистентные названия функций" таким уж прям фактором влияющим на выбор языка. С моей точки зрения Ruby уродливая отрыжка, попытка сделать объектно-ориентированный перл (это лично мое мнение, мне не приятно работать с ruby, пусть меня за это простят), но за счет того, насколько сообщество ruby-разработчиков ценит и понимает цели бизнеса, насколько уважает тестирование своих решений и т.д... словом PHP комьюнити в этом плане еще расти и расти. Но прогресс виден.

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

3) нет. Шансов на нормальном уровне с нуля изучить еще один язык программирования и к тому же фреймворк - почти нет. Да и в этом нет смысла.

4) судя по вопросу вы уже определились для себя. Дальнейшая дискуссия не имеет смысла. Разбирайтесь. Но если брать шаред хостинги то PHP это пожалуй единственный адекватный вариант на сегодняшний день (если не брать в расчет что шаред хостинги как таковые это не очень адекватный вариант).

5) все зависит от вас. Хорошие разработчики зарабатывают примерно одинаково вне зависимости на каком языке программирования они работают. Они просто хорошие разработчики и таких всегда мало.

6) как хотите.

И так...

Язык программирования - это лишь инструмент для решения задач. Фреймворки - это так же просто инструменты для решения задач. Что важно - уметь задачи решать. И решать эффективно. Понимать что кривыми решениями вы увеличиваете риски для бизнеса.

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

Ruby например бизнес (и стартапы в особенности) выбирает не потому что это хороший язык, а потому что Ruby комьюнити в среднем больше приспособлено для эффективного решения задач бизнеса. Что говорить когда у них любовь тестирования прививают с первых дней знакомства с языком?

Не учите язык программирования. Учитесь разработке с применением этого языка. И тогда все будет намного проще.

p.s. Haters gonna hate

Потому, что запрос асинхронный, и первые два console.log вызываются до того, как получен ответ с сервера.