Impact — отличный коврик, у меня было два таких, как раз в Германии и покупал. 8 ножек без проблем танцуется — он толще и тяжелее стандартных ковриков, не скручивается под ногами и не ездит.
Мне это тоже интересно. Но, к сожалению, используя только данные со страницы приложения узнать это не получится – разработчики не обязаны информировать о наличии рекламы или платных дополнений.
Я видел еще более извращенный способ: вместо NotifyPropertyChanged(«name») использовался метод Notify(), который анализировал фрэймы call stack'a, для выяснения из какого свойства его вызвали и вызывал для него NotifyPropertyChanged.
Все хорошо в меру. Если у класса есть много редко вызываемых свойств, я предпочитаю использовать лямбды. Если несколько интенсивно используемых — DependencyObject.
Пользуемся .NET Reactor'ом, в целом довольны. Из минусов — суппорт просто никакой, после защиты увеличивается время старта программы.
Для следующего проекта планируем потестировать альтернативы, спасибо за список :)
Из интересных, не вошедших в обзор, еще есть CodeFort — появился недавно, помимо прочего поддерживает обфускацию Xaml/Baml (по заявлению разработчиков).
Так же присматриваемся к Crypto Obfuscator — по описанию выглядит интересно, есть менеджер лицензий от того же разработчика.
Мой первоночальный комментарий — ни в коей мере не критика, просто хотел добавить что существуют готовые решения подобного рода. Я с удовольствием посмотрю на код вашего движка — Fit расширяем и мы постоянно этим пользуемся, адаптируя его для наших проектов. Возможно мы сможем позоимствовать интересные идеи и у вас :)
Исключительно для информации:
Таблица в Fit-тесте это просто метод задания данных. То, как эти данные интерпретируются, находиться полностью на усмотрении программиста. Мы используем таблица как непосредственно для передачи данных в тест, так и для задания пути к файлу, где эти данные можно получить. Это же относится и к пользовательским данным — все в руках пишущего спецификацию.
Fit-тест можно условно разделить на три части: html-спецификация, инфраструктурный код, использующий Fit-framework и собственно тестируемые классы. Инфраструктурный код интерпретирует получаемые данные, вызывает тестируемый код и возвращает результаты, в коде программы для поддержки Fit ничего менять не надо.
Основной метод отчота — html, но консольные утилиты Fit позволяют интерпретировать эти отчеты, выводить результаты на консоль и использовать Fit-тесты в автоматическом билде.
По поводу движка для интеграционного тестирования – идея не новая, мы давно и успешно используем Fitnesse.
Для описания Fit-теста используется HTML документ, который вполне может создать тестировщик и передать программисту для использования. В документе описываются входящие данные, операции над ними и ожидаемые результаты.
В связи со сменой работы было немного не до нее, но после НГ собираюсь к ней вернуться — накопилось много идей и желание переделать метод хранения тегов, что-бы нормально поддерживать и сеть и переносимые диски.
В текущей версии, к сожалению, сложно это поменять.
Unity предоставляет возможность конфигурирования без XML файлов. Вся конфигурация выполняется средствами языка, что гораздо удобнее и надежнее. Тоже самое можно сказать про фреймворки Autofac и Ninject — последний мой любимый, им я и пользуюсь. Если кому то это интересно, у меня есть PowerPoint презентация про Ninject — могу выложить.
DI столь же уместны как и фабрики. В случае с DI код получается «прозрачнее» — обычно нет необходимости явного требования объекта, создание необходимых экземпляров проходит за сценой. К тому же, проще сконфигурировать одно правило, чем добавить фабрику.
Переопределение свойств в ручную — это хорошо, но когда у тебя сотня классов, создавать связи в ручную не очень интересно.
Цель DI — избежать самокофигурирующихся объектов, т.к. это снижает возможность их повторного использования и тестирования.
Если после переустановки системы файлы, которым присвоены теги, останутся на прежних местах, то можно просто сохранить базу тегов, а затем записать ее обратно – пару человек, обращавшихся с подобным вопросом, воспользовались этим способом без проблем.
Программа ориентирована на работу в пределах одного компьютера, по этому, перенос тегов на другой компьютер не предусмотрен. Но, к примеру, один из пользователей использует TaggedFrog для работы с внешним винчестером: и база тегов и программа у него размещены на самом винчестере и используется на нескольких компьютерах.
Размер добавленных файлов не критичен, но при добавлении большого числа файлов c одним тегом программа может работать медленнее. Я как раз сейчас это оптимизирую.
До тех пор, пока теги качественно не поддерживаются операционной системой, все подобные решения – это как костыль, что бы хоть как то решить проблему.
Для внешних программ есть два основных подхода – хранить теги вместе с файлом, в дополнительном NTFS потоке, или создавать свою библиотеку тегов, ссылающуюся на файлы. В обоих случаях есть и преимущества и недостатки.
В случае с хранением тегов в файлах – это работает только до тех пор, пока файл находится в пределах NTFS, отсутствует центральная точка управления тегами, слабая связность тегов между собой, необходимость помнить какие теги уже использовались. Преимущества – при копировании теги сохраняются, отсутствует необходимость в какой-либо синхронизации.
В случае библиотеки – легкий доступ ко всем тегам и файлам, но, зато, при перемещении файлов необходима синхронизация. Я выбрал для программы этот вариант, поскольку он позволяет мне, как пользователю, контролировать библиотеку тегов, не допускать ее разбухания и при этом иметь возможность быстрого доступа к файлам.
Вообще, изначально я писал программу для быстрого доступа к ограниченному числу документов, используемых каждый день. Но постепенно в программу добавляется поддержка дополнительных функций. Например, в одной из следующих версий появится возможность хранения тегов в ADS, с синхронизацией с основной базой.
Все хорошо в меру. Если у класса есть много редко вызываемых свойств, я предпочитаю использовать лямбды. Если несколько интенсивно используемых — DependencyObject.
Для следующего проекта планируем потестировать альтернативы, спасибо за список :)
Из интересных, не вошедших в обзор, еще есть CodeFort — появился недавно, помимо прочего поддерживает обфускацию Xaml/Baml (по заявлению разработчиков).
Так же присматриваемся к Crypto Obfuscator — по описанию выглядит интересно, есть менеджер лицензий от того же разработчика.
Исключительно для информации:
Таблица в Fit-тесте это просто метод задания данных. То, как эти данные интерпретируются, находиться полностью на усмотрении программиста. Мы используем таблица как непосредственно для передачи данных в тест, так и для задания пути к файлу, где эти данные можно получить. Это же относится и к пользовательским данным — все в руках пишущего спецификацию.
Fit-тест можно условно разделить на три части: html-спецификация, инфраструктурный код, использующий Fit-framework и собственно тестируемые классы. Инфраструктурный код интерпретирует получаемые данные, вызывает тестируемый код и возвращает результаты, в коде программы для поддержки Fit ничего менять не надо.
Основной метод отчота — html, но консольные утилиты Fit позволяют интерпретировать эти отчеты, выводить результаты на консоль и использовать Fit-тесты в автоматическом билде.
Для описания Fit-теста используется HTML документ, который вполне может создать тестировщик и передать программисту для использования. В документе описываются входящие данные, операции над ними и ожидаемые результаты.
В текущей версии, к сожалению, сложно это поменять.
dimecasts.net/Casts/ByTag/IoC
DI столь же уместны как и фабрики. В случае с DI код получается «прозрачнее» — обычно нет необходимости явного требования объекта, создание необходимых экземпляров проходит за сценой. К тому же, проще сконфигурировать одно правило, чем добавить фабрику.
Переопределение свойств в ручную — это хорошо, но когда у тебя сотня классов, создавать связи в ручную не очень интересно.
Цель DI — избежать самокофигурирующихся объектов, т.к. это снижает возможность их повторного использования и тестирования.
Программа ориентирована на работу в пределах одного компьютера, по этому, перенос тегов на другой компьютер не предусмотрен. Но, к примеру, один из пользователей использует TaggedFrog для работы с внешним винчестером: и база тегов и программа у него размещены на самом винчестере и используется на нескольких компьютерах.
Для внешних программ есть два основных подхода – хранить теги вместе с файлом, в дополнительном NTFS потоке, или создавать свою библиотеку тегов, ссылающуюся на файлы. В обоих случаях есть и преимущества и недостатки.
В случае с хранением тегов в файлах – это работает только до тех пор, пока файл находится в пределах NTFS, отсутствует центральная точка управления тегами, слабая связность тегов между собой, необходимость помнить какие теги уже использовались. Преимущества – при копировании теги сохраняются, отсутствует необходимость в какой-либо синхронизации.
В случае библиотеки – легкий доступ ко всем тегам и файлам, но, зато, при перемещении файлов необходима синхронизация. Я выбрал для программы этот вариант, поскольку он позволяет мне, как пользователю, контролировать библиотеку тегов, не допускать ее разбухания и при этом иметь возможность быстрого доступа к файлам.
Вообще, изначально я писал программу для быстрого доступа к ограниченному числу документов, используемых каждый день. Но постепенно в программу добавляется поддержка дополнительных функций. Например, в одной из следующих версий появится возможность хранения тегов в ADS, с синхронизацией с основной базой.