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

https://github.com/FriendsOfSymfony/FOSRestBundle/...

TL;DR

группы сериализации symfony/serializer начал поддерживать только с версии 2.7, до этого только jms serializer умел это дело. Потому fosrest еще просто не умеет использовать symfony/serializer для этих целей. Увы но добавление полноценной поддержки symfony/serializer приведет к довольно грустным BC-break-ам и увидим мы поддержку оного полноценную только в FOSRestBundle 2.0.

Почему аннотации это плохо? Потому что аннотаций в PHP нет (во всяком случае пока). А то что есть - это кастыль основанный на phpdoc.

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

Есть еще одно НО. Скажем я когда-то был категорически против использования аннотаций в сущностях доктрины. Представьте себе типичный проект на symfony. У нас есть какое-то поле и мы должны написать туда минимум аннотацию для доктрины и аннотацию для валидатора. Если мы пишем апишку то появляются всякие сериализаторы и прочая чушь, документация к API и тд. Ну и собственно сам phpdoc. В итоге на одно поле сущности выходят минимум 5 строк в phpdoc с аннотациями.

Но выход из этой ситуации очевиден: перестать использовать сущности доктрины вне сервисного слоя (в контроллерах, формах и прочей чуши), валидировать только DTO, добиться того что бы модель в принципе не могла войти в невалидное состояние. И тогда остаются только аннотации для доктрины, с чем я смириться могу поскольку я ленивая ж. Валидировать же реквест или форму довольно просто.

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

Но мой хостинг на PHP 5.2

через пару дней даже для php 5.4 прекратится выпус обновлений безопаности. Бегите от этого хостера.

В целом ваша проблема в том, что пример использует сокращенный синтаксис массивов. Воспользуйтесь обычной:

$message = array(
    'username' => '123123',
    // ...
);

Behat не совсем для тестирования, Codeception исключительно для тестирования.

Если ваша команда записывает требования в терминах Given-When-Then и загоняется по BDD, то выбор очевиден - Behat. Есть еще команды которые заставляют писать функциональные тесты своих тестировщиков и для этого используют gherkin-сценарии. Если вам надо просто покрыть все функциональными тестами то Codeception (или любой другой фреймворк, я вот peridot использую для этих целей).

В каких сферах программирования активно используется математика?

Что же все таки там происходит?

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

нужно писать TDD тесты.

Нет, нет такой вещи как "TDD тесты". TDD это одна из методик экстремального программирования (XP). Вам уже привели ссылку на книгу Кента Бэка на эту тему (к слову крайне рекомендую)

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

- Красный - перед тем как написать код, мы должны написать тест который ломается (обычно в консоли сломанные тесты подсвечиваются красным). Согласно этой методологии писать код вы должны строго тогда, когда у вас есть сломанные тесты. Если сломанных тестов нет, то и код писать не нужно.
- Зеленый - когда вы получили красные тесты, вы должны максимально быстро дописать код так. что бы тесты были зелеными. Скажем если вы написали тест который ожидает от функции, что она вернет строку "foo" то в коде у вас должно быть не больше чем сама функция и вывод строки "foo". Как только мы этого добились мы либо рефакторим, либо добавляем еще красных тестов что бы потом дописать код. Конечно настолько примитивные вещи делать по такому циклу избыточно, и у Кента Бэка описывается понятие "длины шага", то есть сколько работы мы можем делать на каждом этапе. Вы всегда должны подключать здравый смысл словом.
- Рефакторинг - на предыдущих фазах мы не загонялись о том насколько наш код красив, насколько мы соблюдали принципы DRY и т.д. так что это фаза отчистки кода. Мы можем делать ее на каждой итерации, а можем раз в пару часов, но важно делать это как можно чаще. На этом этапе мы устраняем дублирование как в коде приложения так и в тестах. Важно отметить что хорошей мыслью будет не рефакторить одновременно и код и тесты, ибо у нас должен быть источник правды. Если мы почистили тесты и при этом они начали фэйлиться, то значит мы что-то сломали пока числити. И наоборот. А если менять и то и то между запусками тестов то не понятно кто виноват.

Обычно TDD практикуют используя unit-тесты (что логично, ибо они выполняются достаточно быстро что бы выполнение тестов не заставляло нас заваривать чай), что подразумевает собой то, что мы тестируем один юнит (один класс или объект), а все его зависимости должны подменяться на моки (фэйковые объекты, которые нужны что бы проверить как наш объект взаимодействует с другими, об этом тоже много написано). Но никто не запрещает использовать интеграционные/функциональные тесты и при этом практиковать TDD (так например делают чуваки практикующие BDD), а Кент Бэк это дело называет ATDD.

Собственно TDD дает нам следующие преимущества:
- вы не тратите время на проектирование системы в микроскопических масштабах, это эволюционный подход, архитектура приложения постоянно меняется и эволюционирует вместе с требованиями. Все требования формализуются в виде тестов.
- код всегда покрыт тестами (пусть и не на 100%, обычно хватает и 20% что бы можно было жить, все зависит от сроков жизни проекта и требуемого уровня надежности)
- если вам становится трудно писать тесты (например много зависимостей, сложно мокать) - то это должно навести вас на мысль о не правильной архитектуре и инициировать более глубокий рефакторинг. А при наличии тестов это не так уж и страшно.
- необходимость покрывать тесты увеличивает потребность в соблюдении всяких принципов типа SOLID и т.д. так как иначе мы начинаем писать тесты очень не эффективно и опять же возвращаемся к тому что с архитектурой что-то не так.

updated

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

Минусы TDD проистекают из плюсов. Это эволюционный подход, который хорошо работает когда мы вносим изменения в систему маленькими порциями и всегда рефакторим наш код, что бы он большую часть времени был красивым и удобным к расширению. Если же вам в руки дали легаси проект и сказали отрефакторить, то TDD тут не подходит или подходит плохо. Но опять же такая задача ставится довольно редко, чаще - добавление функционала. И в этом случае мы возвращаемся к внесению изменений маленькими порциями и эволюционному подходу. Просто на это уйдет довольно много времени, но если сравнивать с "рефакторинг + добавление функционала + регрессионное тестирование" то в зависимости от ситуации TDD может дать как профит так и нет. Все зависит от сложности системы. На простых системах в этом нет смысла.

По поводу области применения... Тут есть несколько точек зрения. Как минимум TDD решает вопрос проектирования архитектуры, а не разработки алгоритмов. Этого мы достигаем тестами. Но опять же через юнит тестирование довольно не удобно разрабатывать определенные типы проектов: комиляторы, трансляторы, различные решения основанные на сложных алгоритмах (например алгоритмы сжатия, шифрования и т.д.), штуки завязанные на сетевом взаимодействии, например клиенты для протоколов. Для этих вещей больше подходят функциональные тесты или же их вовсе сложно покрыть тестами.

1) делаем адаптер PSR-7 (или HttpKernel) к вашему движку
2) делаем приложеньку на симфони
3) ставим мидлвэр который будет разруливать на какое приложение какие запросы кидать. Это можно разруливать и через nginx но как-то не круто.
4) когда начинаем пилить функционал на симфони и нужно что-то реюзать из старой кодобазы, стараемся отделить то что мы хотим заюзать от старой инфраструктуры (можно скажем сервис-декоратор запилить для старого движка) и регистрируем его в DI
5) постепенно переносим код, модель можно оставить старую если это возможно.

По сути основная сложность отделить модель от инфраструктуры движка и почистить сервисный слой.

Правильный способ: не использовать сущности в контроллерах, вообще, и никогда не скармливать их ни JMS Serializer-у ни формам.

Более-менее правильный способ, определить свой Object Constructor для JMS Serializer-а что бы дать возможность указывать в какой объект пихать данные.

1) карта взездного неба не проблема
2) для определения что сейчас доступно вам нужно:
- координаты пользователя
- направления взгляда
- время
3) для того что бы сделать все совсем клево нужно научиться искать уровень горизонта, тогда можно будет относительно него уже все делать. То есть придется опять же работать с акселерометром и компасом.

А про вариант с анализом звезд с камеры можно смело забыть.