Не кажется, что схема слишком бледная получилась? Серый текст на сером и все такое? Лично мне щуриться приходится, чтобы нормально разглядеть все, контраста не хватает. Тестировали на людях со слабым зрения?
На Яндекс.Станции можно выбрать, активируется ли он по «Алиса» или по «Яндекс». Я себе оставил только «Яндекс», так как дочь Алиса — полет нормальный. Наверно, и на телефоне можно выбрать Яндекс или Алиса
В итоге, согласно принципу YAGNI, решили не держаться за проверки и удалили их. Все предупреждения были перенесены из теоретических/формальных в обоснованные.
У нас обычно такое правило — вызовам методов внутри одного класса доверяем и параметры не перепроверяем, а вот все приходящее снаружи — проверяем обязательно. Что-то типа зон доверия.
Воспользовался советом в комментариях выше. Установку можно запустить командой:
lxrun /install /y
Она запускается установку молча, без подтверждения.
Потом уже bash запускается. Правда в нем тоже с кодировками не особо работает, но вроде там уже не критично, играться и так можно.
Пока правда первое впечатление, что это все таки сильная бета, работает далеко не все
Только что поставил на русскую винду, работает. Надо просто дождаться, когда прилетит обновление с Insider версией (у меня оно появилось через пары дней, после подключения к программе Insider Preview) и установить режим разработчика, как в статье написано.
Будет можно переводить в человекочитаемый формат, как я понял. На гитхабе в целях:
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
Разве Skip и Take 10 раз итерируют перечиление? Один обход там только будет, насколько я помню («Не смотря на то, что такой код довольно прост, он имеет один очевидных недостаток: в нем происходит итерирование коллекции 10 раз»)
Кстати, если включить стандартные дотнетные CodeContracts, то они уже написаны в фреймворке в том числе и для стандартных интерфейсов типа ICollection и они в постусловии проверяют, что после вызова Add() Count увеличится на 1.
Столкнулись с этим, когда пробовали включить контракты на своем проекте и сломались тесты на «ленивые» коллекции, которые после Add в реальную коллекцию ничего не добавляли, а делали это при перечислении или вызове Count. В итоге, из-за вызова Count контрактами, вся ленивость потерялась.
В 4й фреймворк они уже включены и стороннего ничего ставить не надо. Делается это не через компилятор, а уже после компиляции «дохачивается» IL-код. Правда, из-за этого оно работает не быстро, но все таки это вполне стандартная поставка
Если вы имеет ввиду разработчиков, то я еще не встречал ни одного, которому бы нравилось заполнять такие отчеты. Хотя всречал одного, который добровольно для самого себя вел что-то типа дневника, куда записывал то, что он сделал, хотя часами там, конечно, и не пахло. Но даже дневники любят писать немногие.
Если же смотреть бухгалтерию и все такое, то тут в крайнем случае можно просто воспользоваться вариантом с автогенерируемыми отчетами. У себя я (переводчик, а не автор статьи) примерно к тому и пришел. Полностью отказаться от отчетов во всей компании пока нельзя, так как есть другие категории сотрудников, кому это надо, а делать две системы — трудоемко.
Оригинал в PDF и у меня так и не получилось выдрать эту ссылку из Adobe reader и открываться она тоже отказывалась. Презентация легко гуглится, да и ссылки уже привели. Я не был стопроцентно уверен, что это именно она, так что не стал вставлять ссылку в статью
Хотя, вообще говоря, аналог «план-фактного анализа корректировки экспертных оценок продолжительности проектных работ», например, в Scrum есть и его роль играет фокус-фактор — коэффициент, на который умножается оценка трудоемкости, данная командой. Коэфициент корректируется по результатам спринтов, но для этого не нужны отчеты о выполненной работе. Просто после спринта на ретроспективе смотрим, сколько успели сделать из запланированного (или насколько больше) и корректируем коэффициент
В Agile, мягко говоря, как-то не приживается «план-фактный анализ корректировки экспертных оценок продолжительности проектных работ», все больше просто Planning Poker для планирования. Не так научно, но зато, как показывает практика, очень эффективно.
Собственно поэтому я и юзаю Spring.Aop из Spring.Net, но и у него есть тоже пара недостатков в сравнении с PostSharp, связанные как раз с тем, что там аспекты навешиваются не в CompileTime, а в RunTime через генерацию динамических проксиков:
1. Нельзя просто создавать объекты через конструктор, так как тогда они не будут обернуты в динамические проксики с аспектами. Но это совсем не проблема, если все создается через IoC.
2. Если через Introduction Advice (в терминах Spring.Aop) добавлять к классу реализацию какого-то интерфейса, например INotifyPropertyChanged, то внутри самого класса нельзя сказать (INotifyPropertyChanged)this, так как понятно, что this — это ссылка на сам объект, а не его проксик с аспектами, и сам объект это интерфейс не реализует. Пару раз нарывался.
3. Забыл уже конкретику, но была проблема с биндингами WPF на объект, обернутый в проксик с аспектами, связанный с особенностью реализации Weak Events в биндингах WPF. Проблема решаемая, но очень неочевидная и в свое время пришлось ковырять исходники .Net, чтобы с ней разобраться.
У АОП через проксики есть и плюсы — например, можно на лету делать подмену таргета (объекта, который оборачивается в проксик). Через это, например, делается ленивая загрузка свойств в NHibernate, при этом исходный объекто остается POCO.
У нас обычно такое правило — вызовам методов внутри одного класса доверяем и параметры не перепроверяем, а вот все приходящее снаружи — проверяем обязательно. Что-то типа зон доверия.
lxrun /install /y
Она запускается установку молча, без подтверждения.
Потом уже bash запускается. Правда в нем тоже с кодировками не особо работает, но вроде там уже не критично, играться и так можно.
Пока правда первое впечатление, что это все таки сильная бета, работает далеко не все
define a human-editable text format that is convertible to and from the binary format, supporting View Source functionality.
Столкнулись с этим, когда пробовали включить контракты на своем проекте и сломались тесты на «ленивые» коллекции, которые после Add в реальную коллекцию ничего не добавляли, а делали это при перечислении или вызове Count. В итоге, из-за вызова Count контрактами, вся ленивость потерялась.
Если же смотреть бухгалтерию и все такое, то тут в крайнем случае можно просто воспользоваться вариантом с автогенерируемыми отчетами. У себя я (переводчик, а не автор статьи) примерно к тому и пришел. Полностью отказаться от отчетов во всей компании пока нельзя, так как есть другие категории сотрудников, кому это надо, а делать две системы — трудоемко.
1. Нельзя просто создавать объекты через конструктор, так как тогда они не будут обернуты в динамические проксики с аспектами. Но это совсем не проблема, если все создается через IoC.
2. Если через Introduction Advice (в терминах Spring.Aop) добавлять к классу реализацию какого-то интерфейса, например INotifyPropertyChanged, то внутри самого класса нельзя сказать (INotifyPropertyChanged)this, так как понятно, что this — это ссылка на сам объект, а не его проксик с аспектами, и сам объект это интерфейс не реализует. Пару раз нарывался.
3. Забыл уже конкретику, но была проблема с биндингами WPF на объект, обернутый в проксик с аспектами, связанный с особенностью реализации Weak Events в биндингах WPF. Проблема решаемая, но очень неочевидная и в свое время пришлось ковырять исходники .Net, чтобы с ней разобраться.
У АОП через проксики есть и плюсы — например, можно на лету делать подмену таргета (объекта, который оборачивается в проксик). Через это, например, делается ленивая загрузка свойств в NHibernate, при этом исходный объекто остается POCO.