Андрей Смирнов

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

В данном случае, скорее всего, PHPStorm просто не знает, что где-то заранее вызывается функция init, в которой создаются экземпляры класса. Возможно попробовать это обойти, напрямую добавив вызов функции init в __construct, или унаследовать __construct, создавая экземпляры в нем.

Недавно делал похожую систему.
Баланс пользователя хранится отдельно, там фиксируется актуальное «реальное» число условных единиц.
Есть таблица транзакций, с описанием, датой, суммой, направлением списания (на баланс или с баланса), поле «заморозка» и поле «статус».

Соответственно, на клиенте показывается реальное число, показывается, исходя из списка транзакций, сколько денег на счету заморожено (такие транзакции, как правило, лежат с состоянием «на проверке» и галочкой в поле «заморозка» до тех пор, пока их не подтвердят, тогда галочка снимается, и замороженная снимается со счета).

В принципе, вполне хватает для всех нужд. Как только транзакция проводится, ее статус меняется на «исполнена», и деньги вычитаются уже из таблички пользователей.

Можно использовать стандартные способы вроде параметра в ссылке ?refId=4 или хэша #ref10, который потом можно записать на стороне клиента простым JS-скриптом

На счет группировки в таблице wall не все так гладко, ибо, если запись собирает, например, все добавленные пользователем заметки за час/день, тогда вопрос, как будут выглядеть подобные посты, скажем, за вчера, при условии, что половину фотографий/заметок, указанных в записи, удалили? В таком случае, надо для каждого wall message либо проверять при выводе доступность каждого элемента, перечисленного в нем, либо наплевать, но тогда и результат соответствующий будет.

activity stream не очень важен, разве что он будет хранить дискретные записи, например, создание одной фотографии/заметки, просто для лога. Как вариант, в нем можно хранить wall_message_id, который будет указывать на сгруппированную запись, в которой это действие будет отображаться. Тогда немного облегчается процесс, о котором я писал выше, так как, например, удаляя какую-то фотографию, мы можете найти обратную запись (создание) в таблице activity stream, оттуда выбрать wall_message, из которого уже удалить ту самую фотографию из перечисленной группы.

git pull <путь к проекту> master?
Или просто git merge master

Сейчас многие прикручивают такую классную штуку, как вертикальный или горизонтальный виртуальный скроллбар, который, скажем, по всей своей длине олицетворяет общее количество записей, которые можно просмотреть, а определенной длины ползунком на этом баре текущее положение просмотра. Соответственно, сдвигая его по бару, можно динамически листать порции записей

В контакте позволяет добавить в центр уведомлений вроде как пока только сообщения, для этого надо открыть диалоги и нажать «включить оповещения в браузере».

Пишется стандартная ЧПУ-система с тремя строчками в .htaccess, и с функцией в index.php, которая, хотите, по case, хотите, через регулярки (по аналогии с Yii routes) определяет, чего хочет пользователь и в зависимости от этого подтягивает нужные зависимости

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

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

А еще, если вдруг кто знает, как организована, например, база «вконтакте» или «мой круг»? Судя по наличию городов, у контакта точно (хотя, может быть, и всего лишь частично) используется база КЛАДР, но вот как они ее организовали?