Я упомянул Node, потому что его упомянул автор вопроса. Наследия не было почти вообще, компания заводилась с нуля =)
Когда сравнивали, ноду не взяли по причине того, что разработчики дороже, но выгоды мы от этого не получали, поскольку пошли по пути узкой специализации без фуллстека. К тому же, повторюсь, в ноде существует вагон и маленькая тележка "правильных" архитектур проекта. Это не очень удобно, когда строишь конвейер и нанимаешь сразу много людей. Каждый новый проект как ни следи, получается другой. Преимущества терялись, а минусы оставались.
Если бы он стоит 10000$, можно было бы заморочиться, а так круговой билет из Сан Франциско до Москвы стоит 1200$ и уже куплен, а принтер стоит 200$ ... =)
FireGM: в то же время нагрузка упадет из-за мультиплексирования и падения кол-ва запросов в 10-1000 раз (в зависимости от количества ресурсов на сайте).
Тогда итеративный подход позволит понимать "мощность" команды. А накопленный стек решенных задачек обязательно нужно использовать при оценке каждой задачки из нового проекта. Как-то так. Ну, и использовать вероятностный подход, который описан по ссылке, которую я кидал, что даст Вам дату окончания проекта =)
CI сервер - сервер непрерывной интеграции, конкретно я использую и советую всем Jenkins. В таком случае, ваш разработчик должен использовать vagrant для воспроизведения "тестового сервера" у себя на компьютере. Тестировать на удаленном сервере - это очень плохой тон в случае когда есть 1 тестовый и 1 боевой. Попридержите коней, перестройте свое сознание. В лучших практиках тестовый сервер - это "почти то же самое что боевой", но на всякий случай на него не пускают пользователей. Это просто последняя проверка для тех случаев, если вы ответственно относитесь к качеству своего продукта. В этом и состоит смысл держать идентичные механизмы развертки и на тестовый и на боевой - их тоже стоит проверять. Если уж так необходимо, удлиняйте свою цепочку тестирования, введите 2-3 тестовых сервера. Например, на 1-м бардак и тесты каждые 2 минуты (желательно чтобы он был у разработчика на компьютере локально, о чем я написал выше), на 2-м тоже бардак и вакханалия но уже одна на всех разработчиков, на 3-м уже "чистовик", туда все релизят словно это боевой, затаив дыхание. Тот самый пробный запуск. На боевой уже выкатка с легким сердцем, все уверены в результате потому что то же самое только что произошло на 3-м этапе тестирования.
Макс: у каждого усложнения должна быть цель и я так понял, ваша цель "пользователь должен знать". Но на самом деле это не цель, а, простите, "г-но". Скорее всего ваша цель в привлечении новых пользователей, повышении конверсии или уменьшении отказов существующих.
Теперь подключаем бизнес- логику и пробуем ответить на вопросы:
1) Сколько в деньгах будет стоить усложнение? (часы работы программиста с учетом удорожания введения новых фич * стоимость часа)
2) Сколько денег это принесет вам?
Повысит ли это конверсию? Или никак не повлияет на нее? Есть ли у вас потери в пользователях, которые испугались доверять свои данные сервису и поэтому ушли?
Проведите customer development, опросив 50-100 пользователей о том, волнует ли их безопасность, только не спрашивайте "хотите ли вы эту фичу?", спросите какие варианты угода данных они видят, дайте им выговориться без корректировки потока мыслей. Вдруг откроется что все искренне верят вашему серверу, а вот свой компьютер подозревают, тогда нужно подумать над другой фичей, которая их успокоит.
3) После 2 и 3, узнайте, окупается ли эта фича, может есть аналоги "дешевле"? Например, подключить свой сервис к какому-нибудь безопасному прокси или нанять аудит и повесить у себя сертификационные знаки?
ovdin: вкратце история с лендингами такая:
-Посетитель приходит на сайт и задается вопросами (Что за тема сайта?)
-Крутит дальше, получает ответ, задается другими вопросами, например, "А эти новые правила будут эффективнее"?
-Крутит дальше и получает тут же ответ.
-...
Такой диалог вопрос-ответ должен очень сильно предугадывать мышление пользователя и длится довольно долго, приводя к цели. Иначе человек получит ответы на вопросы которые не задавал, начнет искать по лендингу то что его интересует (а навигация в них отвратительная всегда), запутается и уйдет. Короче, сделать хороший лендинг - сложно и трудоемко. Сделать плохой очень просто.
Реализацию удобного обсуждения дайте на откуп программистам, которые это уже делали. Можно скопировать с хабра подход когда каждый комментарий словно топик для отвечающего на него, мне лично очень нравится. Но опять же, это гипотеза, её нужно проверить на живых людях.
Регистрация не делает нового пользователя на сайте, она делает его в базе. Регистрация прогоняет некоторых пользователей, это факт. Контент же генерировать на сайте люди могут без регистрации при помощи аутентификации сторонними сервисами (вк, фб итд). В итоге получается что связка "регистрация => привлечение пользователей" аналогично "тугой двери в магазине", ну, или спортплощадке, которую обнесли забором чтобы люди перелезали и ВЖИВУЮ общались внутри =)
@LnDt они везде разные. У меня были собеседования вообще без технической части, просто "разговорчики". Кажется, на этих собеседованиях главное, что парит работодателя: "Если я дам этому парню задание поправить форму на джанге, он сможет обстоятельно прочесть мануал и сделать за 3 дня, или будет тиранить меня вопросами? Или за ним нужно будет все переделать?"
Я достаточно зелен в миграциях и архитектура базы, которая мигрирует без нарушения обратной совместимости, меня напрягает... Учитывая, что в любой момент мы можем стать условно из онлайн игры фотохранилищем следуя бизнес-требованиям... Да и руки не у всех такие прямые. Кто их знает, как повернутся условия и хотелки заказчиков? =)
В общем итоге, мне хотелось бы иметь гибкость в миграции базы данных как угодно куда угодно и при том в оба направления.
Нормальная ли это практика? Какие готовые штуки для этого можете посоветовать?
@alekciy ни разу не лагнула, тьфу тьфу) Но очень внимательно тестировал кейсы установки и обновления.
Автосборка производится самописным баш скриптом, который вобрал в себя 2 мануала из гугла по настройке веб-сервера и сборке деб пакетов. Есть плагин к jenkins, но им не пользовался.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
Когда сравнивали, ноду не взяли по причине того, что разработчики дороже, но выгоды мы от этого не получали, поскольку пошли по пути узкой специализации без фуллстека. К тому же, повторюсь, в ноде существует вагон и маленькая тележка "правильных" архитектур проекта. Это не очень удобно, когда строишь конвейер и нанимаешь сразу много людей. Каждый новый проект как ни следи, получается другой. Преимущества терялись, а минусы оставались.