Однажды я выбирал платную IDE, чтобы купить, так как в тех, которыми я прежде пользовался, что-либо не устраивало. Пока не наткнулся на NetBeans.
Не нашел в вашей статье, а сам использую часто: Окно -> Задачи (Ctrl + 6).
Если в коде ставишь метки на будущее (TODO, @todo), то эта фишка все их покажет списком.
И все бы ничего, и обошелся бы я какой-нибудь левой библиотечкой, но кое-какие специфичные штучки-финтеплюшки, так необходимые мне, в библиотеках не нашлись.
Можно добавить ещё, что тем, кто хочет начать работать с Symfony2 более легко, не обязательно использовать сразу весь фреймворк.
Можно использовать компоненты, как отдельные самодостаточные части.
Либо есть какой-то старый проект, который не использует фреймворка.
Сразу весь проект переделывать с нуля бывает нецелесообразно, но в нём можно
начать использовать какие-то компоненты.
К примеру, для работы с формами и т.д.
Тестируемая система не при чём.
Пространство имён определено в двух местах, в данном случае:
— в хелпере и самом тесте.
Хелпер подключается к тесту, для него и создан.
При работе с миграциями ничего никому говорить не требуется.
Или я не понял, — о чём «Сценарий 2».
Почему утром Петя и Вася «занимаются сексом с базой»?
Разница в удалённой разработке и разработке в офисе есть.
В офисе можно поставить на какой-то общий сервер одну базу,
и почти безболезненно с ней работать.
При этом проблемы:
сервер упал и вся команда курит в ожидании поднятия
кто и когда и зачем внёс правки в бд непонятно, если нет
системы миграций, и хранения миграций в vcs
При удалённой разработке так же можно поставить общую базу, но:
те же проблемы, что и в офисе, плюс:
запросы к бд значительно медленнее, тк бд удалённая
проблемы любые с инетом и т.п., — работа встаёт
локальная работа, без интернета, вообще не возможна
С системой миграций:
любые изменения фиксированы, можно отследить всё, — кто, когда и что менял
возможна локальная работа
(я, например, часто работал вдали от дома, имея под рукой интернет только через
мобилку с платным трафиком)
быстрое развёртывание копии проекта, без необходимости в скачивании полного дампа
(или быстрое доведение локальной копии до рабочего состояния, опять же без дампа)
Например, у меня проекты есть и на ноутбуке, где я уже давно не работал, для того, чтобы
быстро переключиться туда я обновляюсь из репозитория и апгрейдю базу через миграции.
По моему, — это уже достаточные основания для использования подобной схемы.
Ну и фактически обязательно использовать при удалённой разработке.
«Да, дома мы зовем его Инъекшка»
Читайте документацию:
www.php.net/manual/en/intro.mysql.php
Не нашел в вашей статье, а сам использую часто: Окно -> Задачи (Ctrl + 6).
Если в коде ставишь метки на будущее (TODO, @todo), то эта фишка все их покажет списком.
А можно конкретней, чем например не подошло: ru2.php.net/manual/ru/book.pdf.php?
Бывает и с твёрдым месячным окладом, при чём с белым.
Можно использовать компоненты, как отдельные самодостаточные части.
Либо есть какой-то старый проект, который не использует фреймворка.
Сразу весь проект переделывать с нуля бывает нецелесообразно, но в нём можно
начать использовать какие-то компоненты.
К примеру, для работы с формами и т.д.
Но в «отечественной» сборке комментарии богаче )
Пространство имён определено в двух местах, в данном случае:
— в хелпере и самом тесте.
Хелпер подключается к тесту, для него и создан.
Каким образом это повлияет на систему?
Будет удобнее, если будет в наличии дефолтная конфигурация.
При работе с миграциями ничего никому говорить не требуется.
Или я не понял, — о чём «Сценарий 2».
Почему утром Петя и Вася «занимаются сексом с базой»?
В офисе можно поставить на какой-то общий сервер одну базу,
и почти безболезненно с ней работать.
При этом проблемы:
системы миграций, и хранения миграций в vcs
При удалённой разработке так же можно поставить общую базу, но:
С системой миграций:
(я, например, часто работал вдали от дома, имея под рукой интернет только через
мобилку с платным трафиком)
(или быстрое доведение локальной копии до рабочего состояния, опять же без дампа)
Например, у меня проекты есть и на ноутбуке, где я уже давно не работал, для того, чтобы
быстро переключиться туда я обновляюсь из репозитория и апгрейдю базу через миграции.
По моему, — это уже достаточные основания для использования подобной схемы.
Ну и фактически обязательно использовать при удалённой разработке.