Для себя такие приятности постгреса нашел:
1) Как вы сами выше сказали, можно сделать ALTER TABLE на пару миллионов записей, и это не займет 4 часа. Единственная тяжелая операция в постгресе — CREATE INDEX. И даже она может быть выполнена без лока БД в бэкграунде.
2) Запросы типа ALTER TABLE не коммитят автоматически транзакцию — забудьте о наполовину выполненных миграциях из-за ошибки в середине миграции.
3) В целом субъективно планировщик запросов работает очень хорошо, ни разу не приходилось на каком-либо проекте заниматься оптимизацией порядка джойнов и т.п.
4) EXPLAIN[ ANALYZE] это просто сказка — нате вам дерево плана запроса, нате вам ожидаемую и реальную стоимость каждого шага в понятном виде, а не этот трэш в MySQL.
Не стоит путать, кстати, выход на совершенно несуществующий рынок (например, особый жанр игрушки) и выход на сформированный и всем понятный рынок, скажем, роутеров. Если вы хотите сделать супер крутую сетевую железку, аналогов которой пока что нету вообще, то делать ее два года только чтобы проверить она вообще нужна кому-нибудь или нет вы не будете. Вы сделаете ее на соплях побыструхе — корпус в виде коробки от обуви, 5 ардуин там, договоритесь с парочкой датацентров заинтересованных, будете ее пилить вместе с владельцами датацентров, выпуская прошивки раз в месяц и фикся баги.
Я, конечно, понимаю, что сейчас на меня налетят люди, говорящие «исключение только подчеркивает правило» (фу, не понимал никогда этого), но. Альфа майнкрафта была написана за неделю, если что. Вы этого, возможно, не видите, но постоянно появляются много очень крутых инди игрушек, которые делаются по нормальным Lean методологиям (т.е. фигак-фигак и в продакшен раз в месяц, а дальше смотреть на фидбек игроков).
Идеальный продукт можно сделать в идеальном мире. В реальном же мире можно сделать продукт в два раза дороже и в два раза медленнее, который (если повезет) глючит немного меньше. Пока конкуренты сделали одну версию, протестировали ее на рынке и поняли, что этот подход не работает и надо все фичи выкинуть и сделать с нуля по-другому.
Мдаа, без success story действительно выглядит как-то не очень убедительно все это. То что автору некомфортно работать в таком ритме еще не значит, что все остальные работают плохо.
Нет, это так не работает. Работает так: конверсия второго варианта на Х% меньше конверсии первого. Говорить о не измеренных величинах вообще бессмысленно. И если очевидно, что конверсия первого больше либо равна конверсии второго (вопрос только насколько и вообще имеет ли экономический смысл поддерживать отдельный тип аккаунта для первого варианта), то разница между вторым и третьим вообще непонятна и может быть совершенно не такой на самом деле, какой вы ее представляете.
Поправьте меня, пожалуйста, если я не прав. Мне кажется, что в AngularJS не спроста нету CSRF из коробки. Потому что когда вы делаете API, делать в нем аутентификацию при помощи кук это как-то странно ИМХО. Я думаю, лучше этот токен хранить где-то в Local Storage, например, и посылать его со всеми запросами в заголовках, тогда никакие CSRF будут не страшны.
Или, например, моя мама юзает Nokia 3510i до сих пор (ну делали телефоны раньше хорошие), ей придется сохранять на флешечку QR код и идти в интернет-клуб ближайший распечатывать. =)
Конечно, это справедливо, пока очередей в терминал нету больших. Но очередь в терминал, где люди подходят, вводят код и забирают билет намного быстрее очереди в кассу, где еще чел будет выбирать ряд и деньги искать.
Ну не знаю. Мне как пользователю есть разница — принести в кино с собой 6-значный код или QR-код. Первое намного удобнее и гибче: можно попросить друга по телефону купить билет и продиктовать код, например, или еще 100500 нестандартных кейсов. QR код нужно или распечатывать (не у всех всегда есть доступ к принтеру, у меня, например, дома нету) или нести с собой на смартфоне (а если вдруг разрядится?)
У нас сделали в Минске так: покупаешь билет в интернете, тебе дают шестизначный код, в кинотеатре рядом с кассой стоит терминал, в который вводишь код и он выплевывает билет. Не надо париться о том, чтобы распечатать QR код или еще что: 6-значный код можно и на бумажке записать в крайнем случае или в SMS другу передать.
Я могу один билд запустить в 10 потоков для того чтобы быстрее получить фидбек? Скажем у меня есть пак достаточно тяжелых тестов, для которых надо кучу всего поднятого — бд, сервер очередей, несколько vhost-тов в nginx, этот пак выполняется достаточно долго. Поэтому я арендую несколько дроплетов на digitalocean и запускаю на них тесты параллельно, чтобы время билда держать в пределах 10-15 минут. Я могу что-то подобное сделать на вашей системе? К сожалению, логин не работает сейчас, не могу сам посмотреть это в UI.
Можно сделать второй CI сервер, который будет гонять билды для вас, а если билд зеленый — пушить в другой репозиторий, откуда уже будет собираться билд, который видит заказчик =)
1) Как вы сами выше сказали, можно сделать ALTER TABLE на пару миллионов записей, и это не займет 4 часа. Единственная тяжелая операция в постгресе — CREATE INDEX. И даже она может быть выполнена без лока БД в бэкграунде.
2) Запросы типа ALTER TABLE не коммитят автоматически транзакцию — забудьте о наполовину выполненных миграциях из-за ошибки в середине миграции.
3) В целом субъективно планировщик запросов работает очень хорошо, ни разу не приходилось на каком-либо проекте заниматься оптимизацией порядка джойнов и т.п.
4) EXPLAIN[ ANALYZE] это просто сказка — нате вам дерево плана запроса, нате вам ожидаемую и реальную стоимость каждого шага в понятном виде, а не этот трэш в MySQL.