p4s8x

В PHP есть XPath, есть библиотеки аля PhpQuery, ну и т.д. Есть возможность запускать одновременно несколько запросов через multi curl. Так что можно организовать это все худо бедно нормально. Все то же самое и даже больше есть в питоне да и в любом другом языке. Так что для этой задачи подойдет любой язык, который вы знаете.

reg.ru таки один из лучших. Просто покупать надо не напрямую, а через партнеров. Можно попробовать обратиться к одному из партнеров reg.ru (я пользуюсь услугами 2domains.ru) и уточнить, как организовать продление через него.

Попробуй посмотреть PocketBook 611 Basic или Touch

Перешел с Python (Flask, Bottle) на Ruby (Sinatra, Rails). Не жалею. В плане web-разработки, ИМХО, Ruby экосистема развита лучше.

Каждое достижение — это отдельная логика обработки событий. В него приходит цепочка событий, а на выходе результат — текущее состояние (например, % завершения).

Поэтому:
1. Делаем архитектуру подписки на события. В зависимости от платформы, может понадобится отдельный диспетчер событий.
2. Инкапсулируем логику достижения как то, что зависит от цепочки пришедших в него событий.
3. Вызываем проверку по триггерам (например, у нас есть 90 достижений, обновляем статус по ним в конце каждой миссии, при условии, что в достижение пришло какое-либо событие).
4. Храним состояние в базе каким угодно образом.

Мой путь был бы таким:
— key-value db;
— каждое действие генерирует событие;
— для каждого достижения есть свой подписчик который случает необходимые ему собития;
— при срабатывании подписчик читает поле в базе с ключем __;
— сравнивает с лимитом;
— увеличивает его или генерирует событие добавления нового достижения.

Не претендую на решение, но идея такова:
Большая часть достижений это количество каких то действий, то есть нужно что то сделать несколько раз. Для этих целей создается таблица, с полями id пользователя, достижение 1, достижение 2,… достижение N. Соответственно при выполнении нужного действия нужно достижение в таблице наращивается.
Далее можно создать таблицу с уже полученными достижениями, чтобы можно уже было учитывать те достижения для получения которых нужно выполнить несколько конкретных.
Само присвоение достижений думаю проще будет вести триггерами которые будут проверять достигнуто ли достижение когда обновляется запись.
Такой вариант позволит вам в любой момент добавлять достижения, обычным добавлением поля в таблицу, и триггера на более сложные достижения

Использую там, где это уместно.
Часто выполняемые операции на фронтэнде, конечно имеет смысл оптимизировать, отказавшись от AR.
Да и вообще, недурно профайлингом озаботиться, если планируются нагрузки, а иногда и если не планируются, ради интереса. =)

Я не верю что может быть затык в этом месте. Затыки бывают — БД, сеть и дисковые операции. На генерацию объектов тратиться относительно мало времени. Я знаю, некоторые крупные и действительно высоконагруженные прокеты используют внутри аццки тормозные технологии типа расширенных xslt преобразований. При этом у пользователя все летает. Это достигается кешированием и горизонтальным масштабированием.

Поиск по графу?
из влгоритмов — A*, MST, TSP

В phpStorm такой проблемы нет.

я бы постучался куда-то на noc@вашпровайдер, обычно такие всем известные адреса читаются технарями и мало известны юзверям и спросил у них. Ну или пообщался с техподдержкой активно

Я бы на PHP. А что за требования по масштабируемости? Серверов приложений на PHP можно хоть сотню в ряд выстроить.

templatemonster.com/ru/

Вообще вот либа, с нормальным описание(и даже на русском).
github.com/Nodge/yii-eauth
Или есть что то еще, что пропустил?

linkedin.com