Я бы как раз 10 раз подумал прежде чем использовать ConcurrentDictionary вместо Dictionary. Как раз из-за реализации. Использование механизмов lock поверх методов обычного Dictionary выигрывают в производительности по сравнению с lock free в ConcurrentDictionary. К тому же lock предоставляет больше контроля над процессом и ты точно знаешь, есть ли элемент в коллекции в определенный момент времени. Есть определенные ситуации с high concurrency, когда ConcurrentDictionary действительно будет лучше, но... их не очень много.
Помню, когда был студентом 4го курса переводчика (не основная специальность, допом), преподаватель попросил меня записать аудиогид для этого музея. Перевод делал он сам. Преподаватель, вроде, неплохой, но почему-то перевёл шерстистого носорога как fluffy rhinoceros (хотя он, конечно, woolly). Такой, в общем, пушистик получился:) Меня ещё просили отдельно сделать перевод гида по часам музейным, но я немного не успевал, а потом у музея сменился директор и никому это уже не было нужно. Надеюсь, с тех пор записали нормальный гид на нормальном английском где хотя бы читает человек с нормальной дикцией:)
P. S. А записывали, кстати, в самом здании музея. Для атмосферы, так сказать...
У меня самый трудно-отлавливаемый баг был связан с системой обновления ПО. На предприятии были трудности с выделением нормального хранилища для обновлений, зато был сервер с SQL СУБД. Потому было решено хранить файлы обновлений в отдельной БД в виде блобов. И обновления успешно скачивались в головном офисе, а вот у филиалов постоянно выползали ошибки и обновления не скачивались. Я добавил логов в под программу обновления, но не смог её полноценно распространить, потому что… Ну, обновления не скачивались. Потому для всех филиалов мы просто переустановили продукт до свежей версии и забыли о проблеме. Пока через полгода она не всплыла вновь… Но теперь то у нас были логи! Оказалось все довольно банально, в филиалах был медленный дешёвый интернет, а на запрос select был установлен таймаут в 30 секунд, потому когда приходил "тяжёлый" апдейт, он просто не успевал скачаться. Пришлось снова переустанавливать ПО во всех филиалах, но это была уже совсем другая история. Выводы простые… Пользуйтесь проверенными способами деплоймента и логгируйте все что можно.
Для коллекции:
MethodImplAttribute — с помощью него можно задать, например, инлайн метода.
CallerMemberNameAttribute — весьма полезен при реализации INotifyPropertyChanged
Вообще, рекомендую ознакомиться с остальными атрибутами в CompilerServices, могут оказаться полезными.
Вот ещё интересное наблюдение ко всему, что наследуется от WebRequest.
Задача:
передать на сайт данные с помощью POST запроса с компьютера, с доступом в сеть через прокси;
Выставляем параметры прокси и аутентификации из настроек сети (System.Net.WebProxy.GetDefaultProxy(), System.Net.CredentialCache.DefaultNetworkCredentials)
Отправляем POST-запрос, если объем переданных данных меньше 100 кБ, все ОК (сначала возвращается 407, потом 200)
Если объем больше — только 407, данные не передаются, на клиент возвращается только таймаут операции. Грешили на прокси, но там таких ограничений не стояло. Подозреваю, что это все же ошибка многопоточности в C#, но могу провести расследование, если кому интересно.
Кстати, да, о изрядной реалистичности кадров взлома в перезагрузке в свое время разве что ленивый не упоминал (пример не ленивого michael-borisov.com/2012/11/25/the-matrix-reloaded) ну а так как Тринити кулцхакер то и фильм заслуживает места в списке.
Кстати, проектор дейтвительно очень удобен во всех случаях, когда нужно реализовать некую визуальную модель на практике. Мы так фотографии на стене развешивали. Сначала разложили все рамки на полу, потом сфотографировали и результат уже переносили на стену с помощью проектора. В общем, рекомендую, если нет своего, всегда можно умыкнуть на работе.
Я бы как раз 10 раз подумал прежде чем использовать ConcurrentDictionary вместо Dictionary. Как раз из-за реализации. Использование механизмов lock поверх методов обычного Dictionary выигрывают в производительности по сравнению с lock free в ConcurrentDictionary. К тому же lock предоставляет больше контроля над процессом и ты точно знаешь, есть ли элемент в коллекции в определенный момент времени. Есть определенные ситуации с high concurrency, когда ConcurrentDictionary действительно будет лучше, но... их не очень много.
Подтверждаю. Очень приятная модель для работы, комфортный экран, клавиатура, легкий и довольно мощный.
Помню, когда был студентом 4го курса переводчика (не основная специальность, допом), преподаватель попросил меня записать аудиогид для этого музея. Перевод делал он сам. Преподаватель, вроде, неплохой, но почему-то перевёл шерстистого носорога как fluffy rhinoceros (хотя он, конечно, woolly). Такой, в общем, пушистик получился:) Меня ещё просили отдельно сделать перевод гида по часам музейным, но я немного не успевал, а потом у музея сменился директор и никому это уже не было нужно. Надеюсь, с тех пор записали нормальный гид на нормальном английском где хотя бы читает человек с нормальной дикцией:)
P. S. А записывали, кстати, в самом здании музея. Для атмосферы, так сказать...
У меня самый трудно-отлавливаемый баг был связан с системой обновления ПО. На предприятии были трудности с выделением нормального хранилища для обновлений, зато был сервер с SQL СУБД. Потому было решено хранить файлы обновлений в отдельной БД в виде блобов. И обновления успешно скачивались в головном офисе, а вот у филиалов постоянно выползали ошибки и обновления не скачивались. Я добавил логов в под программу обновления, но не смог её полноценно распространить, потому что… Ну, обновления не скачивались. Потому для всех филиалов мы просто переустановили продукт до свежей версии и забыли о проблеме. Пока через полгода она не всплыла вновь… Но теперь то у нас были логи! Оказалось все довольно банально, в филиалах был медленный дешёвый интернет, а на запрос select был установлен таймаут в 30 секунд, потому когда приходил "тяжёлый" апдейт, он просто не успевал скачаться. Пришлось снова переустанавливать ПО во всех филиалах, но это была уже совсем другая история. Выводы простые… Пользуйтесь проверенными способами деплоймента и логгируйте все что можно.
Пустое приложение будет весить около 1,5 метров. Но это бессмысленная оценка. В реальности все будет зависеть от потребностей веб страницы, моё тестовое приложение занимало около 20 мб, но там использовалось много библиотек. Вообще, у мелкомягких большие планы на оптимизацию размера.
https://github.com/dotnet/blazor/wiki/FAQ#q-wouldnt-the-app-download-size-be-huge-if-it-also-includes-a-net-runtime
Для коллекции:
MethodImplAttribute — с помощью него можно задать, например, инлайн метода.
CallerMemberNameAttribute — весьма полезен при реализации INotifyPropertyChanged
Вообще, рекомендую ознакомиться с остальными атрибутами в CompilerServices, могут оказаться полезными.
Интересно, какая вероятность, что предустановленный в ОС офисный пакет станет нелегитимным и придётся ломать глаза об МойОфис...
Задача:
передать на сайт данные с помощью POST запроса с компьютера, с доступом в сеть через прокси;
Выставляем параметры прокси и аутентификации из настроек сети (System.Net.WebProxy.GetDefaultProxy(), System.Net.CredentialCache.DefaultNetworkCredentials)
Отправляем POST-запрос, если объем переданных данных меньше 100 кБ, все ОК (сначала возвращается 407, потом 200)
Если объем больше — только 407, данные не передаются, на клиент возвращается только таймаут операции. Грешили на прокси, но там таких ограничений не стояло. Подозреваю, что это все же ошибка многопоточности в C#, но могу провести расследование, если кому интересно.