Фреймворк это инструмент, в первую очередь, для ускорения разработки и там много лишнего.
ОРМ тоже много занимает, а нужен ли он в хайлоад?
Для такого масштабного хайлоада можно взять какие-то библиотеки, но вряд ли стоит брать большой фреймфорк
Интервью: новый веб-сервис «Яндекса» построен на языке Python и фреймворке Django
И многое другое в яндексе на питоне. Про яву вообще смешно говорить — на ней очень много всего, включая биллинг — что намного сложнее простой соц сети. HipHop где-то в статьях оценивали в 300к строк… а facebook можно и в 100к уложить было без всяких hiphop'ов
Пруф линкhttp://soft.compulenta.ru/346012/
Да конечно. Чего только стоит восхищения от того, что php научили раз в n секунд проверять не изменился ли код и ставить на него опкод кэшеры — проще тогда взять в питон, где эти вещи работают постоянно из коробки.
Это верно и примеры хорошие. Начал не правильно и потом придется переписывать.
PHP гениальная вещь в плане разработке простых сайтов — быстрая разработка, простой вход, огромное кол-во программистов и т.д.
Но это не повод делать на нём всё подряд — для каждой задачи разные языки по разному подходят
Вообще в описание Mongo только Ваш вопрос и надо обсуждать.
Смысл в том, что используется «документ» как конечный элемент базы.
Самый простой пример — Вы делаете новостной портал.
Есть там новости, потом добавляются статьи, потом добавляются интервью и т.д.
С mongoDB и подобными не надо плодить новых сущностей — все записи лежат в одной коллекции(таблице) и могут отличаться набором полей — у интервью есть участники, у статьи есть автор, у новости есть новостное агентство
Реальный плюс для разработки такого сайта — шаблон будет тоже один — просто показываете те поля, что есть. В реляционной базе тоже можно так сделать, если сразу предусмотреть абсолютно все колонки таблицы или в таблице хранить XML документ(как в CMS DJEM)
Красиво и прогрессивно благодаря платформе Unity, но из-за этой же платформе бизнес составляющая проекта сильно страдает, имхо. т.к. практически ни у кого нет этого плагина и многие не в состояние его поставить по разным причинам
Конечно, работал в большой закрытой студии и не увидел ни одного закрытого в срок проекта.
НО у обоих сторон всегда были веские аргументы из договора, что заставляло искать компромисы
Это не тот риск.
Это компенсация риска участника сообщества, а не клиента.
т.е. участник рискует остаться без зарплаты и рекламы.
Клиент же рискует срывом своих планов(временем и всем что этот проект будет завязано) и то что он не заплатит за нереализованный проект никак не скомпенсирует понесенный ущерб.
будет идти по дефолту для начала на андройде.
а как у проверенной рынком технолигии флэш с этим? айфоны и все такое
но в любом случае это будет цифра меньше 300к
ОРМ тоже много занимает, а нужен ли он в хайлоад?
Для такого масштабного хайлоада можно взять какие-то библиотеки, но вряд ли стоит брать большой фреймфорк
И многое другое в яндексе на питоне. Про яву вообще смешно говорить — на ней очень много всего, включая биллинг — что намного сложнее простой соц сети. HipHop где-то в статьях оценивали в 300к строк… а facebook можно и в 100к уложить было без всяких hiphop'ов
Пруф линкhttp://soft.compulenta.ru/346012/
А чтоб работало быстрее надо на сях писать :-D
PHP гениальная вещь в плане разработке простых сайтов — быстрая разработка, простой вход, огромное кол-во программистов и т.д.
Но это не повод делать на нём всё подряд — для каждой задачи разные языки по разному подходят
Смысл в том, что используется «документ» как конечный элемент базы.
Самый простой пример — Вы делаете новостной портал.
Есть там новости, потом добавляются статьи, потом добавляются интервью и т.д.
С mongoDB и подобными не надо плодить новых сущностей — все записи лежат в одной коллекции(таблице) и могут отличаться набором полей — у интервью есть участники, у статьи есть автор, у новости есть новостное агентство
Реальный плюс для разработки такого сайта — шаблон будет тоже один — просто показываете те поля, что есть. В реляционной базе тоже можно так сделать, если сразу предусмотреть абсолютно все колонки таблицы или в таблице хранить XML документ(как в CMS DJEM)
xml в базе это не всегда база на xml
НО у обоих сторон всегда были веские аргументы из договора, что заставляло искать компромисы
Это компенсация риска участника сообщества, а не клиента.
т.е. участник рискует остаться без зарплаты и рекламы.
Клиент же рискует срывом своих планов(временем и всем что этот проект будет завязано) и то что он не заплатит за нереализованный проект никак не скомпенсирует понесенный ущерб.