Владимир Чернышев

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

Нормально спрашивать на собесе или особенно при получении тестового "это проверка кругозора из резюме или это проверка способности решать ваши реальные задачи?" и во втором случае говорить "извините, мне это совсем неинтересно, имеет смысл продолжать общение?"

В общем случае лучше один. Начинать нужно с него. Когда он начнёт тормозить, то только тогда начинать профилировать, смотреть планы запросов и начинать оптимизировать. Преждевременная оптимизация - зло.

Symfony Validator https://github.com/symfony/validator

Пока не смог найти условий, которые бы он не смог проверить :) Но нужно учесть, что это не столько валидатор форм, сколько валидатор объектов.

Как вариант shell_exec('curl -u "username" https://api.github.com') или exec('curl -u "username" https://api.github.com')

Для начала нужно определить что можно выжать с сервера вообще на каком-нибудь простейшем нативном коде, эмулирующем задачу, типа подключаемся к БД, открываем файл на ФС, читаем/пишем что-то, считаем, выводим и отпрофилировать её.

Если дизайн класса (очень неудачный не только в плане тестирования) изменить нельзя, то смотрите в сторону https://github.com/php-test-helpers/php-test-helpers - как раз полностью ваш случай: переопределение загрузки класса и переопределение exit. Плюс для тестирования защищенного метода нужно будет использовать отражение, если публичными методами без оверхида не вызывать защищенный.

Если бы не потребность в тестировании вызова exit, то с большой вероятностью можно было бы обойтись просто описанием "тупого" класса MainLogger в коде теста до его использования, чтобы не вызывать механизм автозагрузки (вы ведь его используете?).

Как-то так создаются правила валидации:

$form = $app['form.factory']->createBuilder('form')
    ->add('name', 'text', array(
        'constraints' => array(new Assert\NotBlank(), new Assert\Length(array('min' => 5)))
    ))

В хронологическом (вроде) порядке:

php > var_dump(htmlspecialchars('\'', ENT_QUOTES|ENT_HTML401));
string(6) "'"
php > var_dump(htmlspecialchars('\'', ENT_QUOTES|ENT_XML1));
string(6) "'"
php > var_dump(htmlspecialchars('\'', ENT_QUOTES|ENT_XHTML));
string(6) "'"
php > var_dump(htmlspecialchars('\'', ENT_QUOTES|ENT_HTML5));
string(6) "'"

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

www.php.net/manual/en/function.runkit-class-adopt.php — не оно?

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

Пытался делать на РСУБД (MySQL), но не не понравилось — или под каждое событие нужно городить табличку или эмулировать scheme free. Проще взять настоящую scheme free СУБД, остановился на CouchDB. Не для конечного пользователя, но написать по быстрому view на JavaScript может почти любой фронтендер, после небольшого обучения специфики, конечно

Офтоп: я бы сделал так, если уж месить базу данных с сущностями а-ля ActiveRecord

class Entity
{
  protected $database;

  public function __construct(Database $database)
  {
    $this->database = $database;
  }

}

class User extends Entity
{
  public function __construct(Database $database)
  {
    parent::__construct($database); // дурная привычка, чтобы не забыть если решу конструктор расширить
  }

  public function something()
  {
    $this->database->query();
  }
}

Класс Database сделал бы синглтоном или элементом реестра, и в коде вызывал бы примерно так:

$user = new User(Database::getInstance());

Ориентируетесь на это описание: microformats.org/wiki/rest/urls

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

Удобнее, имхо, просто приводить SQL-типы в PHP-типы и обратно непосредственно при чтении/записи, если вы только в своём приложении не используете ООП обёртки для всех скалярных типов в PHP, типа if ($user->login.equal(new String($_POT['login']))

Проконсультируйтесь с тем, кто API предоставляет. Встречал различные варианты, одни ожидают, что придёт application/x-www-form-urlencoded, другие что multipart/form-data, третьи, что application/xml или text/xml, а кто-то может и что-то свое выдумать типа application/mysite+xml.

С рисования. Рисовать пути превращения типичных запросов сначала в данные, а потом данных в ответ, думая где в него может понадобиться внедриться (изменить, заменить, декорировать) по каким-то условиям и прикидывать как это внедрение и проверку условий осуществлять. Так получите схемы взаимодействия ядра и модулей.

Логин у пользователя случайно не что-то вроде "';DROP TABLE "? :)

Сначала напишите на PHP в каком видите вы хотите работать с данными (иерархию объектов, вложенность массивов и т. п.), прикиньте как будете расширять «поля» при необходимости, чтобы не ломать весь код), и только потом думайте как это отобразить на БД. Хотя бы потому что одни и те же отношения между сущностями PHP можно реализовать в БД разными способами, например наследование (от абстрактного «коммента» наследуются «вопрос» и «ответ») отображается минимум тремя способами, а создавая их на основе базы можно просто не заметить, что имеет место какое-то удобное и понятное отношение.

Абстрагируясь от схемы БД вы можете инкапсулировать работу с ней в функции/методы типа $answers = get_answers($question_id) или $answers = Answer.getByQuestion($question) и в них привязывать любую схему БД, или вообще не схему и не БД. Поменяете схему — нужно будет поменять только эти реализации, не трогая основную логику, в ней так и будете обращаться к названию фильма как $questions[$question_id]['answers'][0]['films'][0]['name'] или $questions[$question_id].answers[0].films смотря предпочтётё вы хранить сушности в массивах или объектах.

Если бы PHP умел бы закрывать here/newdoc не с начала строки, то выбрал бы первый вариант для себя, а так нарушается логика отступов, которую я очень люблю в том числе и при смешивании языков, без чего редкое приложение на PHP обходится. Сам использую вариант с конкатенацией.