Серебренной пули нет.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.
Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.
Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.
По моему игнорирование composer.lock в конечном коде, самое плохое что можно предложить.
Этот файл фиксирует точные версии всех установленных пакетов, что бы при деплое, и при разработке можно было быть уверенным что новые версии будет соответствовать тем с которыми были выполнялись тесты.
Иначе можно получить ошибки при деплое, так как версия пакета может отличаться от той с которой проводились тесты.
Разработчики на PHP будут рады узнать, что Upsource теперь поддерживает Composer и внешние зависимости.
Это точно, очень рады.
Но я с ходу не смог понять как оно работает и куда нужно эти зависимости положить. И к сожалению не смог найти инструкции по настройке.
Есть ли какое-то описание настройки этой функциональности?
Дело не в успешности, и не в том что кто-то придёт на рынок вторым.
Просто это объективно не нужные трудозатраты. Веб сервер это значительно больше чем то что есть сейчас в PHP. Это множество модулей, которые уже реализованы, и на реализацию которых потрачено множество человеко лет. Нет смысла писать это заново.
> Разработчики php не ставят задачу написать вот сервер не для разработки
Эта фраза о том что сами разработчики PHP не ставят себе задачу написать высокопроизводительный встроенный вебсервер. Так что в ближайшие 5 лет ждать координальных изменений не стоит.
Это может быть обусловлено тем что sublime создаёт всплывающие окна иными средствами, и DE не считает их окнами. По типу того как можно просто нарисовать html окно.
Это не проблема IDE, это лечиться настройками DE (Desktop Environment).
Вангую что у вас выставлена раскладка на каждое окно. Можно выставить например на приложение или глобально, и проблема уйдёт.
Да такой случай может быть, но это не проблема, ибо если у разработчика тесты проходят, а на CI нет, то понять что проблема в phpunit.xml не так сложно, и они тут же его приведут к общему виду. И снова нет проблемы, и снова всем удобно.
Это очень просто. Например у нас есть CI и для него нужен специальный printer, и он должен включатся по умолчанию, что бы не делать лишних телодвижений. При этом большинство использует phpstorm для запуска тестов, и ему не столь важно какой по умолчанию стоит printer. Но есть человек который запускает тесты из консоли, и ему удобно использовать стандартный принтер для консоли, и вот что бы ему каждый раз при запуске тестов не прописывать нужный printer, он может положить рядом изменённых phpunit.xml который заменит при исполнении phpunit.xml.dist и будет использоваться, и теперь ему не нужно каждый раз дописывать опции при запуске тестов.
Вопрос о том как пользователи будут использовать ваш продукт очень важен, без этого нельзя. Но всё же при тестовом задании для от программиста(если говорить о бэкэнде) требовать таких вещей странно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.
Мой основной посыл был именно в том что PHP сам по себе не течёт уже давно.
Хотя при желании их можно сделать самому. Но в целом сборщик мусора всё собирает нормально.
Автор предлагает написать простой ValueObject, что в целом очень удобно и даёт дополнительную проверку типов.
Идеально в твоём случае попасть в хорошую команду, где есть люди с понимание и опытом.
Вот я не очень люблю Yii, из за того что мне кажется он уж слишком мало пропагандирует best practics программирования, типа SOLID.
При этом я не могу сказать что, например, Symfony это прям то что нужно что бы эти практики постичь.
Идеально на мой взгляд писать код так что бы он не зависил сильно от фрэймворка. Т.е. когда вся бизнес логика заключена не в ActiveRecord модели, как часто бывает как раз в Yii, и не в контроллерах, а в отдельном месте, и уже для этой логики используется обвязка для использования фрэймвоком этого когда.
А вот как это написать, может сказать только опыт и хорошая команда, в которой такие вещи можно обсудить.
Этот файл фиксирует точные версии всех установленных пакетов, что бы при деплое, и при разработке можно было быть уверенным что новые версии будет соответствовать тем с которыми были выполнялись тесты.
Иначе можно получить ошибки при деплое, так как версия пакета может отличаться от той с которой проводились тесты.
Это точно, очень рады.
Но я с ходу не смог понять как оно работает и куда нужно эти зависимости положить. И к сожалению не смог найти инструкции по настройке.
Есть ли какое-то описание настройки этой функциональности?
Просто это объективно не нужные трудозатраты. Веб сервер это значительно больше чем то что есть сейчас в PHP. Это множество модулей, которые уже реализованы, и на реализацию которых потрачено множество человеко лет. Нет смысла писать это заново.
> Разработчики php не ставят задачу написать вот сервер не для разработки
Эта фраза о том что сами разработчики PHP не ставят себе задачу написать высокопроизводительный встроенный вебсервер. Так что в ближайшие 5 лет ждать координальных изменений не стоит.
Вангую что у вас выставлена раскладка на каждое окно. Можно выставить например на приложение или глобально, и проблема уйдёт.
Работает отлично.
Не баш, потому что это просто менее удобно.
И в первую очередь по тому что если разбираться как и кто будет использовать эту систему, то не может не возникнуть вопроса, а зачем писать своё? Есть ли готовые решения? А какую проблему должен решать наш продукт? А есть ли такая проблема? А кто пользователи? И так далее и тому подобное. В итоге ни одно тестовое задание не будет выполнено, ибо оно ни кому не нужно и не имеет смысла его делать.