Алексей Сундуков

Не бывает «30 тыс. онлайн» если это не игра. И даже если это игра, все равно правильнее говорить о количестве запросов в секунду.

1. Количество серверов определяется архитектурой проекта + требуемым потоков запросов. 30кхитов в суточном исчислении ерунда, одного сервера за глаза.

2. Размещение так же зависит от требований проекта. Но если это страницы сайта, то за бугром брать выгоднее, конфирации мощьнее, стоят дешевле, чем в наших ДЦ. Сам беру в Hetzner через fastvds.

4. httperf

Если вопрос в надежности, то выбирать нужно (мы же о зонах рунета говорим, так?) аккредитованного регистратора. Только они имеют официальное права записи в реестр. Остальные не более чем ресселеры и при работе с ними возможны нюансы (ресселер может зарегать домен на себя). Список официальных регистраторов: www.cctld.ru/ru/registrators/

Из все списка лучше регать в nic.ru или reg.ru. Я рекомендую reg.ru потому что: 1) у них есть программный API которые позволяет управлять доменом; 2) бесплатно предоставляют DNS сервер. Ну и в целом более клиенто-ориентированные.

Кстати, стоило бы определиться все же. Или делаем некоммерческий проект которым пользуются люди и не пытается его раскручивать в надежде его когда-нибудь монетизировать (а складывается именно такое впечатление), или же осознаем, что делается коммерческий проект и делаем четкий бизнес план сверяясь с котором можно понять, пора закапывать уже или нет. Любая из этих стратегий (некоммерский/коммерческий) может выгореть, может и не выгореть, но попытка действовать одновременно в рамках этих двух стратегий точно приведет к краху проекта.

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

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

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

С ходу — посмотреть логи.

А если что камитить то?

Попробуй:
git fetch
git merge origin/development2.2
git stash
git rebase origin/development2.2
git push origin development2.2

Какую задачу? Хм… написать модуль к drupal, к примеру. 6-ой версии. А потом сесть и подумать, какие проблемы имеются и как бы их можно было решить используя ООП. Потому что, имхо, для понимания зачем вообще было придумано ООП и почему оно так стало популярно во множестве языков, нужно понимать, какие проблемы решает этот подход. А что бы видеть решаемые проблемы, их сначала нужно найти, пощупать руками на практике.

Факторов может быть масса и если от сервиса не приходит обойник, то узнать почему врятли получится. Но учитывая, что используется сторонний сервис, то ни чего удивительного. Где-то значит клиенты сервиса наспамили, их и забанили. Если у вас вполне легитимные рассылки, тем более приносящие пользу, то нужно как минимум подумать о своем сервисе рассылок, максимум — обзавестись своим почтовый сервером.

Имя: логин (если мыло логин, то сохранять в это поле)
Пароль: ну понятно.

Тогда по Ctrl+B можно скопировать логин в буфер, а по Ctrl+C — пароль.

Как вариант — берем любой адекватный хостинг с поддержкой cron+php/другое и мониторим хоть тысячи сайтов, главное не выходит за лимиты выставляемые провайдером. Для надежности можно взять пару площадок, главное у разных провайдеров.

Да вот на том же малоизвестном ресурсе habr :D в рекламных баннерах крутиться Jira. Создать в ней на дашборде список назначенных задач с сортировкой по времени и приоритету не проблема.

Конечно может. Как минимум можно в конфиге писать, какие статусы возвращать.

Ни чего не мешает сделать самый очевидный вариант — парсинг официального сайта кинотеатра.

А с 00 лет ни чего кардинально не изменилось. Если прочесть каменты, то становиться очевидным, что часть народ изобретает велосипед в своих проекта и выходит у них в итоге gettext. В общем делали-делали, а модуль i18n получился gettext.

Я бы рекомендовал так. gettext использовать для редко изменяющийся информации. Меню, различные надписи делать через него. При этом получаем ряд плюсов:

1) Формат существующий много лет и работающий на огромном множестве платформ. А это означает, что он понятен будет любого кто знает о нем, даже если человек не знаком с тем языком на котором пишется система. Т.е. все преимущества стандартов. С велосипедами же приходится еще разбиратся как оно работает.

2) Кэширование. gettext активно кэшиться в ОЗУ.

3) Обилие софта для переводчиков.

4) Поддержка множественных чисел. Не во всех велосипедах об этом думают в том виде, как это сделано в gettext-е.

5) Поддержка gettext в шаблонных движках.

6) С gettext-ом можно работать не только из PHP. Актуально на гетерогенных проектах.

Ну а контентную часть рекомендую вынести на уровень БД. Лично я использую для каждого языка отдельную таблицу. Плюс по сравнению с хранение в отдельном столбце — отсутствие ALTER-ов при добавление/удалении языка.

На вскидку для NI возникает такой минус — исчерпание размеров левого и правого ключей, когда придется перейти с, допустим, int на bigint. Зависит от соотношения размера дерева и шага для дырок в ключах. В принципе не проблема, потребуется просто чуть больше ресурсов. Но стоит о таких вещах подумать заранее, что бы не получилось так, что в самый неподходящий момент ресурсов то и не хватит.

Алгоритмический минус по сравнению с NS — зная левый и правый ключи узла невозможно вычислить количество потомков, а в NS это можно. К примеру, если каталог товаров храниться в NS, то для текущей категории (узел) можно указывать количество_товара/количество_подразделов/другое просто получив эту категорию и не получая её потомков.

В общем те или иные плюсы/минусы могут рассматриваться в контексте размера дерева, отношения количество_выборок/количество_вставок, аппаратных ресурсов.

Чем HTTPS не угодил?

Вообще не бывает абстрактной безопасности ибо не бывает абстрактных взломов. Система может быть вполне корректно написана, но ломануть могут, к примеру, через одну из служб на сервере, или вовсе через дыру в ОСи.

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

Все это конечно прекрасно, чудесно и удивительно (про первый вариант), но давайте не забывать про такую штуку как ограничение длины URI в GET запросе. Особенно в IE.

Храните в unix timestamp. При этом даже если на сервере будет неактуальная/поврежденная tzdata база (злоключения данной базы я думаю помним все), то данные в базу уйдут корректными. Если же привязываться к зонам, то всегда есть шанс, что формирование даты будет выполнено некорректно и некорректно же запишется в базу.

Эээ… что мешает если ну не посмотреть исходники, то хотя бы почитать мануал?

«The speed of the write depends on the amount of data being updated and the number of indexes that are updated. Indexes that are not changed do not get updated.»
dev.mysql.com/doc/refman/5.0/en/update-speed.html

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

Встречный вопрос.

1) На сколько срочно нужна подобная система?
2) Чем конкретно не устраивают решения на WordPress/Drupal? Потому как складывается ощущение недоговоренности ибо указанный функционал на оных движках реализуем.