Алексей: ну это ссылка на объект, так что смысла "возвращать" ее нет, изменения всеравно будут доступны.
Iliyaity: потому что такой вот код. В Javascript конструктор это просто функция. Если вы вызываете ее через оператор new, внутри происходит немного магии с копирование прототипа, но конструктор всеравно просто функция. По умолчанию если мы явно не возвращаем значения, нам всеравно возвращается this, но мы можем вернуть все что угодно, хоть строку или другой объект если явно пропишем return. В целом обычно за return в конструкторе в приличных обществах бьют по рукам.
Vladislav: повторяю - используя функцию time вы получаете время в таймзоне UTC. То есть для москвы вам надо прибавить еще пару часов (насколько там разница в часовых поясах).
Время относительно. Если вам нужно получить время с учетом таймзоны - есть стандартные функции date и стандартный объект DateTime, с которым можно делать что хотите и выводить дату для любой таймзоны.
lega: нет, в этом нет особо смысла. Я использую data mapper (Doctrine2) в качестве ORM, миграции генерируются автоматически (ну мол именно добавление/удаление/переименовывание пропертей), дописывать иногда приходится (если изменения совсем уж ломают BC) но в основном все происходит почти полностью автоматически.
в целом же возможно это специфика конкретных проектов, но как по мне это не очень здоровая ситуация... хотя подход имеет право на жизнь, все же не в jsonb дело а в связях между объектами.
Если структуру базы надо часто менять (например с точки зрения оптимизаций) есть и другие практики, типа того же event sourcing-а. Правда опять же все от задачи зависит.
Знакомый программист посоветовал пропустить пока что js и посмотреть в сторону php и mysql.
тут сразу стоит спросить себя, зачем вы собираетесь изучать php и mysql. В особенности вместе а не по отдельности.
Лет так 10 назад да, можно было бы пропустить JS, но могу вам сказать так, если вам интересно делать то, что можно посмотреть и потыкать - лучше учите JS. Сейчас по объему знаний фронтэнд не сильно слабее бэкэнда и нормальных фронтэндщиков поменьше будет.
lega: вот и я о том же. Для подавляющего большинства проектов я предпочитаю использовать монгу только в качестве хранилища для агрегаций данных, хотя в последнее время больше нравится использовать эластику для этого.
almac: я сторонник идеи что PSD это дно в контексте современной web разработки. Фотошоп отличный инструмент но уже сейчас слишком сложно в виде статического макета описать динамику и т.д. Мне нравится тенденция смещения профессий, когда дизайнер может накидать живой прототип на том же html + css, тем более что под какой-нибудь хром это сделать не сильно сложно.
Останется ли место для верстальщиков - без понятия.
lega: не очень правильно сравнивать правильно настроенное что-то с дефолтом. Ну и опять же разница именно в модели хранения данных, документоориентированность это хорошо, но как только в монге появляется создавать связи между документами жизнь превращается в маленький ад. Я за монгой уже года два не слежу, может чего и поменялось, но не думаю.
По поводу шард - шарды нужны очень редко, по сути тогда когда индексы в память уже не помещаются. Для примера у меня сейчас есть проекты где используются сервера с 256 гигоа оперативки и там уже нужны шарды. Но в моем случае нет сложных зависимостей по данными и потому можно спокойно разделить это дело.
Есть масса вариантов как решить проблемы и я отношу шардинг к "последней мере".
sergey1989: там есть особенности с наследованием скоупов. Есть ngModel, у нее свой скоуп. Когда она сэтит скалярное значение оно не наследуется сверху. По ссылке которую я привел рекомендуют всегда использовать элиас контроллера, это автоматически фиксит целую кучу проблем.
Андрей: может имело бы смысл тогда отказаться от ватчинга файлов в принципе? Почему бы в inmemory хранилище это дело не хранить. Тогда можно было бы подписываться на изменения данных и т.д. более простым способом.
