там же в коде стоит sleep на 5 секунд. А вообще можно использовать подключение через демон + pub/sub очередь какую. Причем в этом случае можно демона на node.js поднять, и воспользоваться готовыми решениями, которые используют нормальные websockets + fall back в long pooling.
вы же сказали что боди у них одинаковый, так в чем проблема? Если там форма - подставляйте в инпуты значения при открытии модального окна. Если там текст какой- точно так же - подменяйте содержимое.
Если вы не знаете как работать с DOM - гуглите. Просто уберите из вопроса все что относится к модальным окнам, они вам в этой задаче никак не мешают и не помогают.
@HDApache, менеджер проекта не должен принимать решения о выборе стэка технологий, используемых на проекте, так что пример с поисковыми движками я считаю не лучшим. Это все на планинг-митингах обсудить можно, или во время оценки дать просто разные варианты реализации с описанием влияния на качество результата.
А вот знать что такое адаптивная верстка и адаптивный дизайн (не как а что) довольно полезно, ибо встретив задачу такую менеджер будет знать, что нужно будет привлекать при тестировании больше ресурсов (не только на десктопе прогнать. но и на девасах). Тонкости же реализации оного это задача дизайнера и фронтэндера.
Я как-то работал с PM-ом который мелкие правки вносил в код сам. Это конечно мило, когда тебя не тревожат изза какой-то мелочи аля "клиент захотел тут сделать другим цветом", но все же каждый должен заниматься своим делом.
@Jailbird, на запись она не выигрывает. В большинстве бенчмарков пренебрегают тем фактом что mongodb по умолчанию использует отложенную запись. То есть она сначала собирает все в базе и только потому записывает. В этом случае конечно прирост будет, но в случае потери питания, могут пострадать данные. Так же там много нюансов при реализации транзакций и т.д. Не говоря уж о том, что в случае с MySQL как правило вы обновляете одну запись, ибо нормализация данных. В монге же за целостность отвечаете вы, так что если у вас тысячи связанных записей, один апдейт превращается в 1000-ю.
Все зависит от архитектуры, типа приложений и т.д. Универсальные инструменты всегда будут медленнее специализированных.
@hadra, nginx непосредственно php не обрабатывает, он делегирует все это в php-fpm, который вешает свои воркеры. Я не знаю что вы там читали, но рекомендую перечитать. И что-то мне подсказывает что в итоге вы упретесь в производительности в архитектуру вашего приложения, выборки из базы и т.д.
@hadra MongoDB медленная на запись, так же что бы все летало под монгой нужно изначально базу проектировать с расчетом на агрегаты. То есть каждая коллекция будет представлять из себя уже сформированную выборку (без фанатизма конечно), то есть выигрывать в производительности она может только за счет денормализации. Но это увеличивает время записи, усложняет поддержку целостности базы и т.д.
@hadra, nginx + php-fpm пошустрее (он просто будет проксировать запросы в fpm) и менее прожорливо к памяти. Так же есть свои плюшки. В плане настройки доступов - все что угодно можно настроить.
@hadra, после вашей фразы "можно как-то прицепить для отдачи Sphinx" у меня как-то закрались сомнения что вы не понимаете предмета разговора, и не можете сформулировать вопрос.
@hadra, вы же понимаете что все популярные СУБД очень быстрые? Все зависит от задачи, если вам нужна большая скорость записи - CouchDB. Postgress имеет поддержку отложенной записи (то есть вы можете в коде просто поставить данные на запись и не дожидаться окончания процесса). Словом все от задачи отходит, универсальной и быстрой базы нету.
Windows в виртуалке работает лучше чем linux в виртуалке... По ощущениям даже нежнее и плавнее чем linux на хостовой машине. Так что проблемы фотошопа не стоит.
Насколько я помню из дискуссии о 2-ой ветке, AngularJS в последствии будет использовать вместо директив WebComponents, так же как заменит свою систему модулей на ту, что представлена в ES6. Словом, больше использовать нативных средств.
