У меня игра закрывается ровно через 10 минут после запуска. По их совету удалил антивирус. Потом удалил тимспик, интернет эксплоер(!), высылал список процессов, выгруженный через taskmgr, при том что этот список есть в логе их шилда, вместе с информацией по всем установленным драйверам и ПО. Первый тикет был создан 29 декабря 2013, на сегодня это моё самое долгое и бесполезное общение с тех. поддержкой :)
Могли бы вы пояснить как пришли к матрице финальной линейной системы — М? Эта же матрица отличная от «наброска матрицы линейной системы», возможно следует изменить обозначение?
Но не всё так плохо. При увеличении узлов эта фигурка сжимается
4a. Аналитик\архитектор формулируют задачу в терминах сначала бизнес\функциональных требований, затем в виде частного технического задания. Текст задачи уходит в Source Control (Git), задание в Jira и BPM
Пожалуйста, подскажите зачем текст задачи в Git, ведь он есть в Jira? Это отдельный репозитарий от репозитария с исходным кодом?
Вообще такой разброс — это плохо. Ведь практически для любого языка есть стандарт оформления кода (иногда к сожалению несколько).
Скорее всего люди начинают программировать, не зная о существовании таких стандартов, а потом не могут переучиться и возводят привычное им написание до уровня «так общепринято», начинают находить в нем преимущества, красоту и простоту.
Это как игнорировать правила орфографии. Да, смысл сохраняется, только бы знающему человеку на глаза не попадало.
А есть ли возможность решить эту проблему со стороны провайдера? Допустим, специальный VPN тариф, где пользовательский трафик шифруется от квартиры абонента и до прокси-сервера за пределами действия законодательства РФ.
… Но удивляет то, что один Смысл обходит Деньги плюс Смысл. Вы считаете, что чем больше кто-то замотивирован, тем лучше, и что два фактора лучше, чем один? Однако это не так.
Это выражается в том, что люди в Microsoft, которые любят то, что они делают и не заботятся о показателях в системе оценок, справляются лучше, чем те, кто постоянно думает о своих результатах.
Можно пояснить эту мысль? То есть результат работы не зависит от зарплаты? Можно не повышать оклад толковым разработчикам, мотивируя это тем, что захотят — сделают, не захотят — зачем деньги тратить?
И как определяется «справляются лучше», если это не отражается в системе оценок?
Может быть есть готовый сервис, откуда можно было бы подключать js скрипт для редиректа этих самых нежелательных клиентов?
Для сайтов на виртуальном хостинге это было бы подходящим решением.
В данном куске кода нужно тестировать именно create.
Метод create() протестирован в тесте фабрики. Метод __construct() тестируется в тесте класса, в котором он объявлен.
В данном куске кода проверяется работа тестируемого сервиса, а не используемых в нем.
Вы описали выгоды использования DI для DI.
Мне кажется, сейчас вы путаете частный случай DI и сам принцип IoC. Вопрос сводится к обоснованию самой инверсии управления?
Если переносимый сервис пользуется ограниченным набором методов, допустим одним лишь find(), вполне возможно не подключать в проект доктрину, а создать адаптер к имеющейся субд.
Если вам нужна большая часть функционала доктрины, скорее всего вам нужна именно доктрина.
это совершенно не значит, что проектируя с DI мы свободно сможем заменять любые компоненты.
На самом деле, означает. Целесообразность замены, конечно, зависит от конкретного случая.
Прошу прощения за сарказм в первом предложении поста, я действительно считаю этот проект большим и достойным единой продуманной концепции работы с объектами.
Если у вас где-то используется entity manager — перенести класс в проект без доктрины уже нельзя.
Почему же, достаточно определить свой entity manager. В симфони весьма гибкая система конфигов и сервис doctrine.entity_manager вполне возможно заменить. Конечно, если в целевом объекте явно не указан класс менеджера сущностей, а подставляемый сервис имеет соответствующий интерфейс.
Если реально стоит вопрос тестирования, лучше заюзайте AspectMock.
Чем же непереносимый код лучше подхода с использованием многократно описанных паттернов?
Что выпрыгнет из черного ящика?
Абсолютно не важно, главное чтобы оно имело соответствующий интерфейс.
DI реально усложняет код.
FooBar::getSome();
$this->fooBar->getSome();
Возможно, это всё-таки дело привычки и конкретной реализации.
По ссылке из википедии:
Используя же внедрение зависимости, объект просто предоставляет свойство, которое в состоянии хранить ссылку на нужный тип сервиса; и когда объект создается, ссылка на реализацию нужного типа сервиса автоматически вставляется в это свойство (поле), используя средства среды.
Да, реализация примитивна, здесь вышеназванным средством среды выступает SimleDi\ServiceLocator, который занимается и созданием объектов и внедрением зависимостей, в одноименном паттерне (service locator) такого не предусмотрено. Да, это не его задача.
Подразумевается зависимость от конкретных классов. При описанном подходе во-первых возможно изменить используемый класс через настройки сервис локатора, во вторых явно задать реализацию сервиса (при наличии set- метода).
Что мешает даже при использвании DI засунуть в класс статики?
Использование DI ничему не мешает, оно позволяет этого не делать.
Почему класс созданный через фабрику легче подается тестированию?
Всё-таки фабрика создает экземпляры, а не классы. В приведенном абзаце подразумевается удобство тестирование именно порождающего объекты класса, а не порождаемого.
Т.е. для тестирования класса, в котором имеется подобный код:
$m = new Model();
$m->setValue('a', 1);
return $m;
Необходимо существование класса «Model». В то же время убедиться в том, что тестирумый класс действительно выполнил setValue() не всегда возможно, для этого необходимо, чтобы класс Model уже работал.
И в тесте, подменяя фабрику, мы можем через метод modelFactory()->create() вернуть mock объект, для которого проверим однократный вызов setValue() с ожидаемыми параметрами.
Тут подразумевается увеличение количества узлов?
Пожалуйста, подскажите зачем текст задачи в Git, ведь он есть в Jira? Это отдельный репозитарий от репозитария с исходным кодом?
А в чем проблема? Пустой список вполне нормальный и довольно частый результат, почему он не должен кэшироваться?
Скорее всего люди начинают программировать, не зная о существовании таких стандартов, а потом не могут переучиться и возводят привычное им написание до уровня «так общепринято», начинают находить в нем преимущества, красоту и простоту.
Это как игнорировать правила орфографии. Да, смысл сохраняется, только бы знающему человеку на глаза не попадало.
github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md
Можно пояснить эту мысль? То есть результат работы не зависит от зарплаты? Можно не повышать оклад толковым разработчикам, мотивируя это тем, что захотят — сделают, не захотят — зачем деньги тратить?
И как определяется «справляются лучше», если это не отражается в системе оценок?
Какое в Греции забавное определение алгоритма.
Может быть есть готовый сервис, откуда можно было бы подключать js скрипт для редиректа этих самых нежелательных клиентов?
Для сайтов на виртуальном хостинге это было бы подходящим решением.
Ответ на ваш вопрос есть в этом абзаце:
ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D1%83%D0%BB%D1%8C%D0%BD%D0%BE%D0%B5_%D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.9E.D1.82.D0.B4.D0.B5.D0.BB.D0.B5.D0.BD.D0.B8.D0.B5_.D0.B8.D0.BD.D1.82.D0.B5.D1.80.D1.84.D0.B5.D0.B9.D1.81.D0.B0_.D0.BE.D1.82_.D1.80.D0.B5.D0.B0.D0.BB.D0.B8.D0.B7.D0.B0.D1.86.D0.B8.D0.B8
Метод create() протестирован в тесте фабрики. Метод __construct() тестируется в тесте класса, в котором он объявлен.
В данном куске кода проверяется работа тестируемого сервиса, а не используемых в нем.
Мне кажется, сейчас вы путаете частный случай DI и сам принцип IoC. Вопрос сводится к обоснованию самой инверсии управления?
Если вам нужна большая часть функционала доктрины, скорее всего вам нужна именно доктрина.
На самом деле, означает. Целесообразность замены, конечно, зависит от конкретного случая.
Почему же, достаточно определить свой entity manager. В симфони весьма гибкая система конфигов и сервис doctrine.entity_manager вполне возможно заменить. Конечно, если в целевом объекте явно не указан класс менеджера сущностей, а подставляемый сервис имеет соответствующий интерфейс.
Чем же непереносимый код лучше подхода с использованием многократно описанных паттернов?
Абсолютно не важно, главное чтобы оно имело соответствующий интерфейс.
FooBar::getSome();
$this->fooBar->getSome();
Возможно, это всё-таки дело привычки и конкретной реализации.
То позже возникают проблемы в поддержке проекта.
По ссылке из википедии:
Используя же внедрение зависимости, объект просто предоставляет свойство, которое в состоянии хранить ссылку на нужный тип сервиса; и когда объект создается, ссылка на реализацию нужного типа сервиса автоматически вставляется в это свойство (поле), используя средства среды.
Да, реализация примитивна, здесь вышеназванным средством среды выступает SimleDi\ServiceLocator, который занимается и созданием объектов и внедрением зависимостей, в одноименном паттерне (service locator) такого не предусмотрено. Да, это не его задача.
Подразумевается зависимость от конкретных классов. При описанном подходе во-первых возможно изменить используемый класс через настройки сервис локатора, во вторых явно задать реализацию сервиса (при наличии set- метода).
Использование DI ничему не мешает, оно позволяет этого не делать.
Всё-таки фабрика создает экземпляры, а не классы. В приведенном абзаце подразумевается удобство тестирование именно порождающего объекты класса, а не порождаемого.
Т.е. для тестирования класса, в котором имеется подобный код:
Необходимо существование класса «Model». В то же время убедиться в том, что тестирумый класс действительно выполнил setValue() не всегда возможно, для этого необходимо, чтобы класс Model уже работал.
При использовании фабрики, код будет таким:
И в тесте, подменяя фабрику, мы можем через метод modelFactory()->create() вернуть mock объект, для которого проверим однократный вызов setValue() с ожидаемыми параметрами.