Хм. Ну вообще-то на работу как раз больше времени остается. Все agile практики вообще-то направлены на минимальный уровень бюрократии и деланье того что нужно СЕЙЧАС. Если надо сейчас править баги то и правиш прямо сейчас (замечательное правило что баги со скрамборда всегда берутся первыми). Если нужен рефакторинг — рефакториш сейчас (а это из TDD). А вот запуски приложения и smoke-тестирование (это как раз и прогон минимально осмыслленого сценария на задеплоеном приложение) спасает огромное количество времени и вам и другим членам команды. По личному опыту — при процессе построенном по agile методологиям код реализующий нужную функциональность пишется куда быстрее.
Ну Resolve<Func>() это резолв фабрики (не спортивно и немного криво), Autofac умеет резолвить Lazy что намного более наглядно и автоматом решает проблемы с ReadOnly и двойным резолвом. В принципе Unity умеет так или иначе практически все что умеет Autofac. Эта зараза (Autofac) подкупает тем что он очень explicit (все делается очень явно, никакой магии) и количеством фишек которые идут в комплекте.
Ну мой совет что в этом конкретном сетапе лучше использовать Autofac. Количество кода уменьшится а качество увеличится. Кстати я тоже работал с Prism как раз используя Autofac — получалось в разы приятнее чем с Uniti. Кстати посмотрел сейчас — Autofac отлично интегрируется и с WebAPI и с SIgnalR. Плюс имеет еще класные фишки типа ленивого резолва и автоматического dispose всего что создается вместе с реквестом.
Не холивара ради. А почему Unity? Почему не Autofac например у которого есть интеграция с MVC из коробки и который отлично может тебе сказать что тип зарегистрирован или нет.
Ну не то чтобы нравится, но поставив на одну сторону весов удобство а на другую выбор — я для себя выбрал удобство.
И еще вопрос, объясните мне простому смертном, что бы было с MS, если бы они на обычной x86 винде, запрещали ставить программы в обход их магазина как во всевозможных «сторах» или еще дальше бы пошли: например мне нужна программа, обращаюсь к программисту, он мне ее делает, а поставить я ее не могу, только через какой нибудь MSстор, оплатив еще сверху 30% майкрософт.
Да ничего бы не было. Ставили бы программы из магазина и все. 7% ушло бы на Linux еще 7% пыталось бы крякнуть защиту.
Если что для AppStore можно завести Enterprise аккаунт в котором приложения будут видеть только те кому можно (и можно как раз не платить лишние 30% Apple)
Окей а у Mozilla Foundation монополия на принятие патчей в Firefox. Почему я не могу использовать WebKit в Firefox, Google вместе с Apple должны засудить Mozilla на дикие миллионы баксов :)
А счастье было так рядом :) Всего в 4 кликах в опциях, плюс сам полноэкранный режим выглядит не очень
В каком смысле — сбрасывает?
в прямом — нажимаешь share тебя перебрасывает на страницу где предлагаться выбрать как ты хочешь сделать Share. Только у оперы видел такое поведение — у всех остальных поп-апы или менюшки.
Не видел ажиотажа по этому поводу в BTS. Возможно, что-то у вас не так работает.
Ну это просто супер :) кстати не у меня одного — я штук 5-7 аналогичных отзывов в AppStore видел. Черт я уж думал что хоть для закрытой платформы гениальная отмазка — у вас плохой компьютер, не работает.
Не не так.
Далеко не все и не вся.
Например Windows 8 на планшетах и на смартфонах мне нравится. Так же как например и Chrome на IOS.
Конкретно в Opera Mini мне не нравится
— Ужасный интерфейс — привет 90е когда у моего смартфона занято 10% полезной площади экрана вырвиглазными менюшками
— Share сбрасывает страницу которую я просматриваю
— Невозможно открыть в ней ссылку из другого приложения
— Крешится всреднем раз в час.
У них кусок рынка по установкам и устройствам меньше чем у Android.
Ну скажем ограничение в выборе браузера по умолчанию — ущемление прав пользователей
Ну так если пользователю это не нравится он может без особого труда использовать Android. IOS далеко не монополист рынка операционных систем для мобильных устройств.
А чего учится?
Решение по поводу MS достаточно спорное но и оно было принято потому-что MS занимал что-то около 87% рынка с Windows. MS же судили за то что она использует монополию в Windows для продвижения IE. У IOS или у MacOSX никакой монополии на рынке нет, обе системы даже не лидеры ранка. За что их судить?
Если TDD тесты не описывают спецификацию то это не TDD тесты :)
И грубо говоря, чтобы написать TDD-тест на CRUD нужно как минимум навесить абстракций над БД
Да не надо этого — пишите прямо в базу — никаких проблем если тесты не становятся зависимыми и вас не напрягает время выполнения тестов. Как только появятся зависимые тесты или начнутся проблемы с временем исполнения — прикручиваете абстракцию.
А насчет того как понять что такое TDD — почитайте Кена Бека и читая сравнивайте с тем как вы разрабатываете без TDD.
Я как раз за собой заметил что планирование разработки в модели без тестов -> рисование диаграмм классов, описание пользовательских историй итд, полностью заменяется написанием TDD тестов. Вывод следующий из этого — написание TDD тестов и есть написание спецификации. Вообщем-то они и есть ваша спецификация.
Тут смешанны в кучу и unit-testing (отдельная дисциплина направленная на то чтобы проверить что unit ведет себя так как положено) и интреграционнное тестирование (опять — же отдельная дисциплина, которая проверяет что несколько слоев системы работают вместе именно так как задумывалось) и TDD ( ПРОЕКТИРОВАНИЕ через тестирование).
Это разные вещи.
Абсолютно.
В них есть общий момент — тесты, но в первых двух практиках — тесты ПОДТВЕРЖДАЮТ работоспособность кода, в TDD же тесты являются исполняемой СПЕЦИФИКАЦИЕЙ.
Сама разработка по Agile подрозумевает что спецификации у вас ровно столько сколько нужно для успешной разработки проекта — не больше и не меньше, TDD тесты это лишь способ писать эту спецификацию на том-же языке что вы пишите код и сделать её исполняемой, все.
TDD тест на проверку CRUD функциональности может быть ровно 1 если и так все понятно, он просто говорит вам — для данного типа данных мне нужна CRUD функциональность. В принципе он может быть даже параметризован типом которому нужна CRUD функциональность.
ИМХО 90% разговоров о TDD не нужен происходят из-за того что люди очень тяжело понимают что такое TDD.
То-же самое происходит например и с функциональным и реактивными подходам и к написанию кода, надо только понять как это должно работать.
Эх ладно :) Специально полез в блог Joel чтобы посмотреть его объяснение чем хорош daly-build. Вот что он пишет:
Иногда при использовании системы контроля версий один разработчик случайно вносит изменения, которые нарушают нормальный ход сборки. Например, добавляет новый файл с исходным кодом, и на его машине всё компилируется просто замечательно, но при этом забывает поместить этот файл в репозиторий. Он гасит свою машину и в хорошем настроении идёт домой. Но после этого уже никто не может работать, и все вынуждены тоже идти по домам, причём в гораздо худшем настроении.
И что Гугл патчи у всех принимает? Что-то в это очень тяжело верится. Плюс в Гугловой версии андройда достаточно closed source компонентов.
Да ничего бы не было. Ставили бы программы из магазина и все. 7% ушло бы на Linux еще 7% пыталось бы крякнуть защиту.
Если что для AppStore можно завести Enterprise аккаунт в котором приложения будут видеть только те кому можно (и можно как раз не платить лишние 30% Apple)
А счастье было так рядом :) Всего в 4 кликах в опциях, плюс сам полноэкранный режим выглядит не очень
в прямом — нажимаешь share тебя перебрасывает на страницу где предлагаться выбрать как ты хочешь сделать Share. Только у оперы видел такое поведение — у всех остальных поп-апы или менюшки.
Ну это просто супер :) кстати не у меня одного — я штук 5-7 аналогичных отзывов в AppStore видел. Черт я уж думал что хоть для закрытой платформы гениальная отмазка — у вас плохой компьютер, не работает.
Далеко не все и не вся.
Например Windows 8 на планшетах и на смартфонах мне нравится. Так же как например и Chrome на IOS.
Конкретно в Opera Mini мне не нравится
— Ужасный интерфейс — привет 90е когда у моего смартфона занято 10% полезной площади экрана вырвиглазными менюшками
— Share сбрасывает страницу которую я просматриваю
— Невозможно открыть в ней ссылку из другого приложения
— Крешится всреднем раз в час.
Ну так если пользователю это не нравится он может без особого труда использовать Android. IOS далеко не монополист рынка операционных систем для мобильных устройств.
Решение по поводу MS достаточно спорное но и оно было принято потому-что MS занимал что-то около 87% рынка с Windows. MS же судили за то что она использует монополию в Windows для продвижения IE. У IOS или у MacOSX никакой монополии на рынке нет, обе системы даже не лидеры ранка. За что их судить?
Да не надо этого — пишите прямо в базу — никаких проблем если тесты не становятся зависимыми и вас не напрягает время выполнения тестов. Как только появятся зависимые тесты или начнутся проблемы с временем исполнения — прикручиваете абстракцию.
А насчет того как понять что такое TDD — почитайте Кена Бека и читая сравнивайте с тем как вы разрабатываете без TDD.
Я как раз за собой заметил что планирование разработки в модели без тестов -> рисование диаграмм классов, описание пользовательских историй итд, полностью заменяется написанием TDD тестов. Вывод следующий из этого — написание TDD тестов и есть написание спецификации. Вообщем-то они и есть ваша спецификация.
Это разные вещи.
Абсолютно.
В них есть общий момент — тесты, но в первых двух практиках — тесты ПОДТВЕРЖДАЮТ работоспособность кода, в TDD же тесты являются исполняемой СПЕЦИФИКАЦИЕЙ.
Сама разработка по Agile подрозумевает что спецификации у вас ровно столько сколько нужно для успешной разработки проекта — не больше и не меньше, TDD тесты это лишь способ писать эту спецификацию на том-же языке что вы пишите код и сделать её исполняемой, все.
TDD тест на проверку CRUD функциональности может быть ровно 1 если и так все понятно, он просто говорит вам — для данного типа данных мне нужна CRUD функциональность. В принципе он может быть даже параметризован типом которому нужна CRUD функциональность.
ИМХО 90% разговоров о TDD не нужен происходят из-за того что люди очень тяжело понимают что такое TDD.
То-же самое происходит например и с функциональным и реактивными подходам и к написанию кода, надо только понять как это должно работать.
wiki