Vladislav Churakov

Коротко - быстро и дёшево - никак.

Менее коротко - наймите профессионала/профессионалов, которые этим занимаются (мы, например, занимаемся). Я серьёзно. Это самый эффективный метод (и по деньгам, и по времени и по нервам), если только вы сами лично не планируете освоить профессию бизнес-аналитика.

Более подробно
Если вы попросите разных людей пробежать марафон - люди назовут разное время и разную стоимость. Никакой "правильной" оценки по срокам и бюджету в реальности не существует.
Или другой пример. Гораздо более простой по сравнению с (почти) любым ИТ проектом продукт - хлеб, который выпускается массово и опыт его создания у человечества - тысячелетний, если не больше. Так вот 1) один и тот же хлеб в разных магазинах стоит по разному 2) всяких хлебов в магазине десятки 3) разные люди его согласятся делать за разные деньги и сроки.

Что делать
Никаких волшебных методик нет. Ваша задача требует кучи работы так или иначе. Создать Техническое Задание и оценить его, тем более по каждой фиче - это куча работы для высококвалифицированного и опытного (а значит дорогого) специалиста.

1. Определитесь, с кем будете работать. Это должно не сильно зависеть от денег (в т.ч. потому что у вас ещё нет оценок), а больше от того, насколько вы доверяете друг другу, насколько вы сработались, и вам комфортно работать вместе. (Отсутствие доверия или несовместимость методов работы - слишком большой риск провала проекта, мы к примеру за такие проекты даже не берёмся).
2. Сядьте вместе с исполнителями или его представителем и разбейте проект на фичи, можно довольно грубо. Т.е. составьте нумерованый список всех фич. В экселе или гугл таблицах.
3. Исполнитель их оценит, проставит свои оценки в соседних колонках. Оценки тоже будут довольно грубые. По деньгам и срокам скажем. Т.е. этот список отдаёте команде исполнителя, команда оценивает. Это может занять часы или дни (для проекта в 2 месяца). Понятно, что фичи могут быть взаимосвязаны, оценки тоже и т.д. Это держим в уме (в очевидных случаях) или делаем пометки о зависимостях рядом в колонке (в неочевидных).
4. После этого вы смотрите на оценки и решаете что делать, а что нет.
5. С теми фичами, что вы решили оставить, работаете более подробно. Пишете более подробную спецификацию, делаются проверки, оценки корректируются, план работ ещё раз уточняется и т.д.

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

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

Не согласен с предыдущим оратором (@geeek), в частности с утверждением

В общем если хочешь быть в тренде - бери

- Meteor совсем не в тренде.

Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.

Через oplog - это грязный хак.
У вас есть код который пишет в базу, вот пусть он и "оповещает" об изменениях, с доставкой через websocket.

Ну первое что приходит в голову caniuse.com

В России у Эппл очень плохая клавиатура, с жуткой клавишей энтр и коротким шрифтом (но человек конечно ко всему привыкает).
Это большой плюс в пользу американской версии.

В данном контексте использования разницы не какой.
За исключением того, что GET имеет ограничение на длину запроса (url)

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

server {
    listen 80;
    server_name www.site.com site.com;
    return 301 https://site.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.site.com;
    return 301 https://site.com$request_uri;
}

server {
    listen 443 ssl;
    server_name site.com;
    # основная часть
}

Открываете инструменты разработчика в Chrome. Там есть вкладка Sources. Справа внизу раскройте список Event Listener Breakpoints и отмечайте галочкой любое событие, которое вы хотите отслеживать.