Сергей Протько

Нууу как это сделано у большинства:
у разработчика есть локальная копия репозитория (иначе зачем вам git), и он пишет все у себя локально. Локально интегрирует код других девелоперов со своим ну и т.д. То бишь разработка исключительно локально.

Сервер только один, выкатывать туда можно либо на прямую из git (скажем в gitlab можно добавить доступ по ssh только на чтение) и пулить туда мастер. По сути на сервере всегда должна быть стабильная версия кода, мол с уже заимплеменченными фичами. ну или можно собирать билд в ci по пушу и автоматически разворачивать его.

Давайте по порядку.
У вас есть посещаемый ресурс, где пользователям должны в режиме реального времени приходить уведомления о чем-то. Ну мол например о непрочитанных сообщениях. Для этого я так понимаю вы ежеминутно опрашиваете сервер, и оттуда и появляются кучи одинаковых запросов. Поидее если mySQL настроен нормально, то все эти запросы он будет пытаться кешировать сам. У вас точно есть проблемы с производительностью БД в этом ключе?

С другой стороны, самый оптимальный способ решить эту задачу: WebSockets/long pooling. Реализовать простенький сервер на каком node.js + scocket.io. Как шину данных поставить какой rabbitmq или чего подобное. В случае сообщений, при отправлении сообщения другому пользователю, в очередь отправляется сообщение. Оно принимается push-сервером и, если у нас есть соединение с нужным пользователем, отправляем ему уведомление. При таком подходе мы имеем: данные уходят с минимальными задержками. Уменьшается нагрузка на сервер за счет уменьшения количества запросов (push сервер просто держит соединение и работает только с небольшим количеством за раз). Ну и последнее — масштабируемость за счет rabbitmq: из основного приложения всего лишь отправляются в очередь небольшие сообщения. А то как оно паралелит сообщения и их обработка вынесены в rabbitmq. Меньшая связанность систем. Да и готовых реализации хватает.

зачем покупать ssd и не использовать его? Сама виртуалка вам ничего плохого не сделает с ssd, а операционную систему можно чуть поднастроить при желании. И да, прирост есть (у меня две виртуалки подняты, обе на debian, одна на ssd другая на hdd. Разница ощутима),

А зачем вам тогда angular?

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

stackoverflow.com/questions/2473989/list-of-big-o-for-php-functions

Как альтернативный вариант можно настроить локальную версию репозиториев для ваших зависимостей. Обычный git clone в какую-либо директорию, и просить composer обновляться оттуда. Можно так же поставить satis какой и т.д. а можно просто папку с архивами или git репозиториями.

nginx + php-fpm и проблема решена. Я использую встроенный сервер только во время разработки (обычно это апишки, так что больше чем один запрос за раз выполнять и не нужно).

1) Node.js идеально подходит для подобных целей, так что я считаю что оправдано. Тем более что готовых реализаций полно.
2) Все зависит от загрузки. Что бы сделать нормальный чат, вам придется писать его с применением websokets или long-pooling. в любом случае выйгрыш не на стороне php. Только если применять всякие экстеншены для распаралеливания, писать демон и т.д. Намного проще поднять сервер на Node.js (даже с учетом что вы не так сильны в этом). Да и написать надежный сервер на PHP это то еще приключение.
3) stackoverflow.com/questions/5741792/node-js-chat-user-authentication
4) опять же проблем особо нету. Правда все зависит от реализации.

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

ну раз базовые знания html есть то стоит почитать и про css (надеюсь вы это и имели ввиду).
Затем идет развилка. Это и выбор направлений разработки сайтов (сервер/клиент), и у каждого из направлений есть свои поджанры так сказать. А еще стоит выбор языка (благо для клиентской части выбор не велик — либо js либо никак… почти никак).

Но можно выделить общее: нужно иметь представление, хотя бы базовое о том как работает интернет (наверное даже ограничиваться штуками вида DNS, HTTP, HTTPS) (возможно это будет интересно и познавательно).

Раз уж вы начинающий, предлагаю начать с изучения javascript. Опять же на нем можно писать как клиентские скриптики галерейки, так и сервер. Но не советую останавливаться на одном языке. Попробуйте php, ruby, python… что понравится по синтаксису, что вообще понравится то и используйте. Со временем придет опыт, и вы станете выбирать язык уже по мере необходимости. Все языки в общем похожи, так что проблем с переходом с языка на язык особо не возникнет. Правда переход с js на что-то другое возможно будет тяжелым.

а с каких это пор php поддерживает примеси? трейты != примеси, и использовать их для реализации orm как-то глупо.

Как тема диплома, ну… на фоне тех что я видел еще нормально, хотя как-то скучно.

не оно?

проще и удобнее будет написать подобную утилитку на C#. Как минимум проще взаимодействовать будет с vk api.
По поводу доступа к светодиодам — www.aboutmycode.com/miscellaneous/faking-num-lock-caps-lock-and-scroll-lock-leds/

Думаю этого должно хватить для реализации.

Эм… а почему просто не добавить в rest-API систему логирования запросов/ответов? Подмена данных в запросах? опять же, почему просто не составлять свои и отправлять через тот же curl…

p.s. сам занимаюсь тем же, но как-то вот ни разу не было необходимости мониторить что кто присылает. Зачем?

M — модели… если упростить — это просто проекция вашего хранилища данных (будь то ORM/ODM или обычные файлы) на объекты. И все… Бизнес логику они содержать не должны. Так же модель никак не должна знать как именно она будет сохраняться в хранилище, ибо тогда при смене хранилища начнутся приключения. В этом смысле концепция AR в том виде, в котором она реализована в Yii мне не нравится. Какой-то класс CActiveRecord который знает кучу всего о том что и как он будет сохранять, и от него надо наследовать нашу простенькую модельку содержащую в себе всего пару полей. Опять же есть разные реализации паттерна ActiveRecord, хотя мне больше по душе DataMapper (например Doctrine), при котором у вас есть отдельный компонент, знающий о том что и куда пихать. Логика по выборкам в этом случае выносится в репозитории, эдакие менеджеры записей. Плюсы этого способа — очень легко в системе заменить тип хранилища, расширять и поддерживать за счет слабой связанности компонентов. Контроллеры знают только о том что есть репозитории, которые имеют для каждой записи свой интерфейс (аля getPendingPayments()), и они не знают откуда эти модели выходят, из базы, висят в памяти или еще чего.

V — тут все просто… шаблоны призваны отвязать представление от логики работы с данными, что бы изменение первого не вызывало редактирование какого-то сервиса/контроллера.

C — тут сложнее. Есть две концепции, толстые и тонкие контроллеры. Последние наиболее распространены, и включают в себя два слоя: сами контроллеры и сервисный слой. Контроллеры разруливают какое действие нужно произвести с данными в зависимости от пришедших параметров, прав пользователя и т.д. Они же разруливают ситуации когда нету исхомых данных, различные ошибки и т.д. Вся бизнес логика же выносится в сервисный слой. Сервисы должны минимально знать о контексте использования и заниматься только тем, для чего они были написанны. Скажем, сервис валидации данных ничего не должен знать о сервисе для обработки платежей, или о правах доступа и т.д. Ему на вход приходят данные, и он их проверяет по правилам, описанным для этой модели.

Так же есть некоторые рекомендации по поводу использования тонких контроллеров: дублирование кода контроллеров — это нормально. Если у вас есть несколько контроллеров, реализующих примерно одно и тоже. То есть если отличия минимальны, скажем права пользователей разные, разные вьюшки, разные модели (актуально для простых CRUD операций), то лучше уж пусть будет много очень похожих методов, чем городить какой-то один базовый контроллер и внутри городить логику для обработки всего этого. Так как вся бизнес логика вынесена в сервисы, дублирования именно ее нету. А за время жизни проекта многое может и поменяться, и намного удобнее вносить изменения в отдельные методы а не в один здоровенный супер класс.

Так же при работе с сервисами очень помогает использование контейнера зависимостей. Благо готовых реализаций (как простых, как Pimple так и сложных, как например DiC в Symfony2 или Zend2) достаточно много.

p.s. Мое мнение не претендует на истину. Если кто-то увидел что-то в таком подходе что-то не корректное, буду рад если укажите.

Простите, а зачем при таком подходе вам вообще require.js? Можно же использовать всякие head.js и прочее, раз уж у вас настолько связанные модули. Да и плагины для jquery это не модули вовсе. Можно их сгруппировать вместе с jquery, раз уж они только в этом контексте используются. Так делают с плагинами от twitter bootstrap к примеру.