Вот уже раза три сталкивался с этим велосипедом…
Коллеги всегда настаивали мол давай напишем «правильно» — то есть через AppDomain.
И тут начинают вылезать подводные камни пачками:
1. Код выполняемый в созданном домене имеет урезанные права (Code Access Security, что там в .Net 4.0 поменяли — не вкурсе).
Как правило при создании домена приходится настраивать ему права в Full trust.
2. У вас объект унаследован от MarshalByRefObject. А как GC созданного домена узнает, что объект еще нельзя собирать? Гуглим по InitialeLifeTimeService…
3. А значение GetExtensionName вернется по значению или по ссылке? Так как строка не MarshalByRef, то она будет сериализовываться при передаче между доменами со всеми вытекающими…
4. В 90% случаев время жизни плагина (extension) совпадает со временем жизни всего приложения — соответсвенно Unload нам никогда не потребуется.
Вобщем, если вы не пишете что-то типа IIS, то используйте MEF или что-то подобное для этих целей.
1. Про 100л. vs 105л. это не так. Бассейны нынче замкнутые — один раз в год заливают воду, а потом ее постоянно через фильтры гоняют в день приходится доливать около 2% от объема ибо вода испаряется.
2. А вы в озере купаетесь? А там как бы рыба и она тоже простите «писает» и не только. Не брезгуете?
3. Главная проблема очистки воды в бассейне это далеко не моча, а другие неизбежные «остатки» человека — волосы и кожа.
Меня в бассейне больше смущают «тетеньки», которые в косметике и с уложенными волосами лезут в воду.
Мне несколько раз приходилось писать туже самую state машину, что генерируется await'ами, но на ManualResetEvent'ах — выглядело ужасно. С await'ами же все это укладывается в несколько строчек.
Как только фоновый поток завершит работу и вернет результат — будет выполнено «продолжение» в основном потоке — могу сильно ошибаться, но вроде как это не всегда так. Т.е. «продолжение» может быть вызвано в совсем другом потоке нежели начало метода. Все зависит от того, как настроен текущий Dispatcher. В случае с WPF/Winforms приложений Dispatcher всегда вызывает код таски и ее продолжения в UI потоке. В общем случае это не так.
Кстати, это может привести к очень трудноуловимым багам. Представьте следующий код: lock(syncRoot)
{
await Download();
}
Да, он не очень логичен и даже не скомпилируется (внутри lock и catch await делать нельзя).
Беда в том, что многие текущие синхропримитивы привязаны к тому, что код внутри них выполняется в одном потоке, а с тасками это не всегда так.
1. Ставим StyleCop и он заставит вас всегда передавать CultureInfo во всякие double.Parse и пр. Даже Int32 порой может не распарситься взависимости от региональных настроек.
2. Стараемся не использовать строки для хранение нестроковых данных (те же double)
3. Там, где строками нужно общаться внутри программы (записать/прочитать файл, отправить по сети и пр), используется только CultureInfo.InvariantCulture.
4. Только при отображении пользователю (или попытке прочитать, что же ввел пользователь) используется CultureInfo.CurrentUICulture.
5. Не совсем в тему, но все же: даты (DateTime) внутри программы только в UTC (DateTime.UtcNow) только на стороне UI переводим в локальное время.
1. часто неизвестно кто и как будет использовать ваш класс, а меняя GetHashCode вы меняете поведение стандартных коллекций (HashSet, Dictionary), которые будут хранить инстансы этого класса — кого-то ждет сюрприз.
2. GetHashCode в .Net'е заведен только чтобы поддержать хэш таблицы, поэтому использовать его не по назначению ИМХО не очень правильно.
3. Если говорить об оптимизации сравнения: я б тогда уж завел отдельный метод что-то типа if(a.EqualsOptimized(b))
Стоит отметить, что без четкого понимания для чего, и на что это повлияет, лучше не переопределять Equals и GetHashCode — можете добавить пару часов дебага тем, кто ваш класс будет использовать.
Согласен, все вроде бы очевидно и должен знать и понимать каждый.
Но опыт общения с разработчиками показывает, что это не так. Собственно поэтому и написал пост.
Ну хоть что-то…
В сети информации по этому по крупицам собирать.
Как говорится: «Чем богаты.»
А какого разрешения у вас исходное изображение? И до какого размера оно масштабируется?
Просто в иконке 64 на 64 вы можете себе позволить нарисовать гораздно больше деталей, чем в 16х16.
При уменьшении 64х64 до 16х16 все эти детали неизбежно «размоются» и испортят все изображение.
Можно конечно «пожертвовать» и убрать все эти детали, но смысл занимать место на 64х64 когда информации на этом месте показывается столько же сколько и на 16х16?
Именно поэтому любой серьезный «иконщик» должен рисовать иконку под каждое разрешение индивидуально — IconSaveSmall, IconSaveMedium, IconSaveLarge.
Хуже того, порой приходится еще и рисовать отдельное изображение под каждый фон IconSaveSmalHover, IconSaveSmalPressed.
Коллеги всегда настаивали мол давай напишем «правильно» — то есть через AppDomain.
И тут начинают вылезать подводные камни пачками:
1. Код выполняемый в созданном домене имеет урезанные права (Code Access Security, что там в .Net 4.0 поменяли — не вкурсе).
Как правило при создании домена приходится настраивать ему права в Full trust.
2. У вас объект унаследован от MarshalByRefObject. А как GC созданного домена узнает, что объект еще нельзя собирать? Гуглим по InitialeLifeTimeService…
3. А значение GetExtensionName вернется по значению или по ссылке? Так как строка не MarshalByRef, то она будет сериализовываться при передаче между доменами со всеми вытекающими…
4. В 90% случаев время жизни плагина (extension) совпадает со временем жизни всего приложения — соответсвенно Unload нам никогда не потребуется.
Вобщем, если вы не пишете что-то типа IIS, то используйте MEF или что-то подобное для этих целей.
А Lumia весьма неплох…
В статье речь об изменениях в процедуре защиты диссертации.
Раз хотят что-то менять значит чем-то недовольны.
Недовольны качеством защищаемых диссертаций.
Диссертации пишут в основном аспиранты.
От аспирантуры многим нужна только отсрочка, к сожалению.
У меня статистика такая: на 20 выпущенных аспирантов одна девушка. Из этих двадцати лишь двое пошли на защиту.
Но я бы первым пунктом поставил отмену отсрочки от армии для аспирантов. Для и для студентов ВУЗов тоже бы не помешало…
Дико извиняюсь — попутал вкладки
Но я бы первым пунктом поставил отмену отсрочки от армии для аспирантов. Для и для студентов ВУЗов тоже бы не помешало…
Вот здесь интересная статейка (на буржуйском). Там наглядная картинка с иконкой принтера в векторе и растре.
2. А вы в озере купаетесь? А там как бы рыба и она тоже простите «писает» и не только. Не брезгуете?
3. Главная проблема очистки воды в бассейне это далеко не моча, а другие неизбежные «остатки» человека — волосы и кожа.
Меня в бассейне больше смущают «тетеньки», которые в косметике и с уложенными волосами лезут в воду.
Кстати, это может привести к очень трудноуловимым багам. Представьте следующий код:
lock(syncRoot)
{
await Download();
}
Да, он не очень логичен и даже не скомпилируется (внутри lock и catch await делать нельзя).
Беда в том, что многие текущие синхропримитивы привязаны к тому, что код внутри них выполняется в одном потоке, а с тасками это не всегда так.
1. Ставим StyleCop и он заставит вас всегда передавать CultureInfo во всякие double.Parse и пр. Даже Int32 порой может не распарситься взависимости от региональных настроек.
2. Стараемся не использовать строки для хранение нестроковых данных (те же double)
3. Там, где строками нужно общаться внутри программы (записать/прочитать файл, отправить по сети и пр), используется только CultureInfo.InvariantCulture.
4. Только при отображении пользователю (или попытке прочитать, что же ввел пользователь) используется CultureInfo.CurrentUICulture.
5. Не совсем в тему, но все же: даты (DateTime) внутри программы только в UTC (DateTime.UtcNow) только на стороне UI переводим в локальное время.
2. GetHashCode в .Net'е заведен только чтобы поддержать хэш таблицы, поэтому использовать его не по назначению ИМХО не очень правильно.
3. Если говорить об оптимизации сравнения: я б тогда уж завел отдельный метод что-то типа if(a.EqualsOptimized(b))
ИМХО, лучшее руководство по GetHashCode:
Но опыт общения с разработчиками показывает, что это не так. Собственно поэтому и написал пост.
В сети информации по этому по крупицам собирать.
Как говорится: «Чем богаты.»
А какого разрешения у вас исходное изображение? И до какого размера оно масштабируется?
Просто в иконке 64 на 64 вы можете себе позволить нарисовать гораздно больше деталей, чем в 16х16.
При уменьшении 64х64 до 16х16 все эти детали неизбежно «размоются» и испортят все изображение.
Можно конечно «пожертвовать» и убрать все эти детали, но смысл занимать место на 64х64 когда информации на этом месте показывается столько же сколько и на 16х16?
Именно поэтому любой серьезный «иконщик» должен рисовать иконку под каждое разрешение индивидуально — IconSaveSmall, IconSaveMedium, IconSaveLarge.
Хуже того, порой приходится еще и рисовать отдельное изображение под каждый фон IconSaveSmalHover, IconSaveSmalPressed.