Что нового возможно будет в WCF 4.5

Как то я успел пропустить такое замечательное событие, как  .NET Framework 4.5 Developer Preview. Лично для меня интересно больше всего - что будет в WCF 4.5. Так как это всего лишь Preview, то расчитывать на фичи сильно не стоит, но все равно приятно.

Как всегда, MS говорит что жить нам будет проще и все усилия кидает на упрощение разработки. Давайте посмотрим что же готовит нам WCF 4.5:
Улучшение поддержки Streamed
Ура! Неужели я наконец то этого дождался. Улучшили потоковую передачу данных. Тут сразу 2 новинки. Во-первых, теперь передача потока действительно будет потоковой и не будет блокировать поток, в случае, если принимающая сторона не принимает потока. Во-вторых, удалили ограничения на буферизацию сообщения, в случае пересылки сообщения от клиента сервису, который располагается на IIS.
Улучшение конфигурирования SSL
Еще раз Урааа! Это второе счастье. Теперь чтобы выставить сервис поверх HTTPS нужно всего лишь настроить IIS под SSL и включить его для виртуальной дирректории.
Генерация плоского WSDL файла.
Третье Ураааа!!! Ликуют все, кто когда либо делал клиентов к WCF сервису на MSSOAP! Теперь не надо будет запариваться над тем, что WSDL файл не подхватывается с сервиса и нужно его выгружать отдельно и удалять там все зависимости, делая один plain файлик описания. Теперь WCF сможет выдавать плоский файл описания.
Поддержка нескольких моделей аутентификации
Четвертое и самое главное УРА !!! IIS давно позволяет настроить аутентификацию сразу по нескольким моделям, однако один endpoint WCF мог работать только с использованием одного способа аутентификации. Теперь, надеюсь, можно будет настроить на один endpoint несколько способов аутентификации.
Конфигурирование сервиса прямо в коде реализации сервиса
Потрясная штука, которую давно хотел. Для того, чтобы понять о чем речь, надо посмотреть примеры кода вот тут. Суть – теперь для того, чтобы сконфигурировать сервис кодом, не нужно подвешивать свои собственные behaviors. Теперь стоит только определить метод Configure в реализации сервиса и сконфигурировать все там. Кроме этого, в этом же методе можно подгрузить ВСЮ конфигурацию из другого конфига.
Кеширование ChannelFactory
ChanelFactory это штука, в которую вынесен определенный слой логики, дающий оверхед. Теперь при использовании автогенерируемого проксика ChanelFactory будет закеширован, чтобы устранить оверхед. А это значит только одно – клиент станет работать быстрее, но возможно будет кушать дополнительную память.
Поддержка WebSockets
Пока не понимаю ликовать или нет, надо попробовать работать. Но думаю что для всех веб-разработчиков это будет приятным изменением. WebSockets это технология, которая предоставляет двунапрвленный канал поверх 80 или 443 порта с производительностью TCP канала. Соответственно добавляется 2 новых типа биндинга: NetHTTPBinding и NetHTTPSBinding.
Упрощение генерации конфигурационных файлов.
Конфиги для WCF всегда были проблемой. Они большие, они тяжелые и главное – новичку в них разобраться бывает просто нереально. В WCF 4 версии упростили конфиги, вынесли дефолтную конфигурацию, но это слабо спасает если разбираться нужно в уже сконфигурированном проекте. Хотя «вхождение» в технологию упростилось.
В 4.5 обещают упростить генерацию клиентских конфигов и выкинуть из них все ненужное, оставить лишь то, что действительно нужно конфигурировать.
Поддержка принципа разработки «contract-first»
Принцип разработки, при котором первым делом разрабатывается не реализация сервиса, а его контракт и способы взаимодействия с внешним миром.
Упрощение настройки совместимости с ASP.NET
Штука сомнительная и призвана на мой взгляд, упростить жизнь ASP.NET разработчикам, которые добавляют на свои сайта WCF сервисы. В общем, теперь AspNetCompatibilityRequirementsAttribute будет по умолчанию установлен в Allowed.
Изменения в настройках по умолчанию для свойств транспорта
Значения для свойств транспорта будут изменен так, чтобы в большинстве случаев их конфигурирование не требовалось.
Изменения в настройках по умолчанию для XmlDictionaryReaderQuotas
Опять же упрощение конфигурирования.
Проверка конфигурационных файлов при сборке проекта.
При сборке проекта будут проверяться конфигурационные файлы на наличие ошибок, что должно уменьшить количество ошибок после запуска сервиса. Решение для тех, кто еще не научился читать ошибки WCF, в которых все подробно написано. Кроме этого, ко всем элементам конфигурации WCF добавятся подсказки в XML редакторе.
Binary encoder будет поддерживать сжатие
Теперь и для бинарного энкодера можно установить сжатие для экономии (еще большей) трафика.
Поддержка IDN
Тут не знаю что сказать, не занимался проблемой. Судя по описанию улучшение коснётся дуплексного канала в случае единовременной отправки сервисом сообщений куче клиентов.

Posted via email from Комуникликабельность

Рекомендации по разработке под WCF от Michele

Давненько ничего не выкидывал в блог по WCF. Пора наверстать упущеное.

Некоторые рекомендации от Michele Leroux Bustamante по разработке WCF сервисов в моем вольном переводе. Оригинал записи тут.

·         SOA

o   SOA хорошая штука, сервисы хороши для повторного использования, однако не стоит перебарщивать.

o   Попробуйте создать 2-3 при простом обращении к сервису.

·         Addressing

o   Никогда не зашивайте в коде базовый адрес или адрес endpoint’а.

o   Задавайте базовый адрес в конфигурации.

o   Будет еще лучше, если вы будете использовать runtime конфигурацию для упрощения управления конфигурацией веб-фермы (необходимо дописывать свой код).

·         Хостинг

o   Используйте хостинг в консольном приложении для начального тестирования, если конечно хостинг на IIS\WAS не доступен локально.

o   Всегда тестируйте сервис на реальном хостинге.

o   Попробуйте использовать WAS с AppFabric если это возможно.

o   Используйте AppFabric для автостарта и визуализации ошибок (предпочтительно использовать свою систему диагностики для централизации предупреждений, исключений, отладочной информации и трейсов).

o   Служба Windows удобна в случае неизвестной конфигурации при развертывании.

o   Оператор using

§  Нормально для тестовых хостов (например консольного), когда при закрытии уничтожается домен приложения.

§  Не круто для остальных хостов (cлужбы Windows, рабочей роли, клиента windows), где вы должны разделять вызов Close() в обычном случае и Abort() при наличии исключений, чтобы нормально очистить ресурсы.

§  Никогда не используйте using для проксиков.

o   Типично использовать свой хост для настройки общих behavior и инициализации endpoint’ов

§  Требуется ServiceHostFactory для endpoint’ов на IIS/WAS.

·         Bindings

o   Вы всегда будете настраивать стандартные binding’и

§  Ограничения на размер сообщения и чтения из пакета.

§  Безопасность

o   Часто требуется <customBinding>.

§  Для настройки специальных возможностей, которые не предоставляют стандартные binding’и.

o   Сначала завершите разработку общего дизайна системы, потом устанавливайте шаблон binging’а.

§  Включение модели безопасности.

§  Вы, возможно, придете к 2-3 binding’ам, которые будут использованы клиентами/сервисом и другими слоями.

§  Оберните их в повторно используемые типы binding’ов, чтобы вызывать в runtime или сконфигурируйте с помощью своей секции конфигурации.

o   Создание разделяемого кода между клиентом и сервисом (если такое возможно).

§  Клиентская версия может незначительно отличаться.

·         Endpoints

o   Храните требования enpoint’а в разделяемом коде между клиентом и сервисом, если он у вас есть с обеих сторон.

§  Динамические аспекты, такие как базовый адрес придет из соответствующих конфигурационных файлов.

o   Инициализируйте endpoint’ы программно (свой  ServiceHost и код для инициализации прокси).

§  Хорошо, при использовании веб-ферм. Уменьшает затраты на обновление множества серверов.

§  Не требуется для Windows Azure? Но все равно полезен.

·         Proxies (клиентские прокси-классы)

o   Используйте генерацию прокси классов только для тестирования или клиентов, которые не распостраняют свои компоненты.

o   Создайте отдельную разделяемую библиотеку контрактов (контракты сервисов, сообщений, исключений) и сущностей (контракт данных, код собственной сериализации).

o   Всегда вызывайте Close() явно и Abort() в случае исключений.

o   Желательно не использовать ClientBase<T>, больше контроля наз каналом и фабрикой каналов.

§  Используйте свой базовый класс, например WCF Proxy Generator (http://wcfproxygenerator.codeplex.com/)

§  Примечание: обновленный экземпляр будет размещен на этой неделе.

Posted via email from Комуникликабельность

Стоимость найма

Замечательная статья о найме и удержании сотрудников.

Из раза в раз я видел один и тот же процесс, связанный с увольнением и наймом: человек уходит, зачастую из-за достаточно небольшой суммы, которую ему отказываются давать, заодно еще пытаясь промотивировать его остаться высказываниями в духе «ты этих денег не стоишь», «таких зарплат на рынке сейчас нет» и т. д. Проблема в том, что в подавляющем большинстве случаев экономии для компании в конечном итоге не получается.
В этом играют роль несколько моментов: стоимость найма, стоимость обучения, снижение производительности, риски, связанные с новым сотрудником, зарплата.
Во-первых, практически всегда платить в конечном итоге новому сотруднику приходится столько же, сколько просил ушедший. Это откровение обычно шокирует: мы же в прошлый раз нанимали человека на эту позицию за гораздо меньшие деньги!
Кроме того почему-то практически никто и никогда не считает стоимость найма и обучения. Нанимая программистов к себе в команду, я проводил минимум 6-8 собеседований с кандидатами. При этом на собеседовании присутствую не только я, но и hr, а на «втором круге» еще и руководитель группы, куда должен попасть человек (да, у нас была странная ситуация, когда фактически второе и первое собеседование были поменяны местами). Учтите при этом, что собеседования с хорошим кандидатом получаются долгими и выматывающими, каждое это минимум 3-4 человеко-часа далеко не самых низкооплачиваемых сотрудников. Добавьте к этому время на работу с резюме, переговоры с кандидатами, внутренние согласования, и получится, что найм одного кандидата стоит в среднем 2 человеко-недели вовлеченных в этот процесс. В рубли, думается, каждый пересчитает сам.
Печально, но расходы на этом не заканчиваются: человека надо учить, учить долго и внимательно. В зависимости от специфики и обучаемости уходит на это от полугода до года (да, как-то сложилось, что я работал в достаточно специфичной области, так что на рынке просто не было готовых специалистов, которых можно было бы сразу выпустить в бой). Через полгода на человека уже тратится времени меньше, чем он экономит, через год следить за ним постоянно уже не нужно, да и разжевывать задачи излишне: навыков и опыта ему хватает, чтобы самому разобраться, что к чему. Таким образом, всё время обучения, выплачивая полноценную зарплату, мы фактически спонсируем обучение человека.
При этом не надо забывать, что в любом случае найм нового человека – риск. Пройдет ли он испытательный срок, впишется ли в команду, насколько точно его удалось оценить, не уйдет ли он через пол года... заранее сказать очень тяжело, если вообще возможно. С учетом вышеприведенных факторов получается, что нанимать человека меньше, чем на два года просто экономически невыгодно, а тех, кого уже выучили, недо держать... Понятно, вот только редко так делается.

Оригинал статьи находится здесь.

Репост на itblogs. Думаю там обсуждение будет активней.

Posted via email from Комуникликабельность

Untitled

По тесту Тест Айзенка на интеллект (IQ), 40 вопросов на сайте Психологические тесты у меня следующие результаты:

Правильных ответов - 30 из 40. Коэффициент интеллекта - 135. Уровень Вашего интеллекта находится выше среднего уровня. Поздравляем!!! Или Вы сейчас занимаете в жизни хорошую позицию или у Вас хорошие перспективы! Согласно исследованиям, таким уровнем интеллекта обладает небольшая часть населения, что можно наблюдать ниже.

Вот как распределяются значения IQ у всех людей:

Пройдите и вы тесты

Развлекаловка конечно, но приятно.

Posted via email from Комуникликабельность

Заглядываем сайту под капот

На хабре промелькнула ссылка на очень любопытный ресурс, который по косвенным и не только признакам определяет какие технологии использует сайт.

Про сайты билайна и МТС он говорит что они хостятся на IIS и крутятся поверх ASP.NET, хотя руками я viewstate в коде странички вроде бы не нашел. А сайт мегафона - на nginx (подозреваю что на пхп).

В общем то ресурс выдает кучу инфы, которая будет полезна разработчикам. 

Кроме этого, вспоминается ресурс, который умеет распознавать популярные CMS движки. Правда про сайты мобильных операторов он мало что говорит, но остальное угадывает достаточно неплохо.

Posted via email from Комуникликабельность

dotPeek похоже "жульничает"

Сегодня вся моя лента гугларидера мельтешит сообщениями о том, что вышел dotPeek. Скачал его, установил и запустил. И очень уж меня поразило что код, который показал мне этот инструмент был до жути похож на мой. Причем похож до последнего пробела, все комментарии были на месте (при компиляции все комментарии, и тем более пробелы игнорируются).

Тогда закрались в мою голову подозрения о том, что тулза вовсе не дезасемблирует код, а просто находит по атрибуту CodeBase сборки файлик, где лежат исходники и открывает его. Чтобы не быть голословным – открываю сборку в dotPeek, меняю файлик без перекомпиляции и получаю вот такую картину:

Отсюда вывод – будьте осторожны, когда будете применять тулзу чтобы узнать, актуален ли код сборки.

UPD:

Нашел в опциях интересную галочку

Она как раз и определяет, будет ли использоваться для отображения кода информация из pdb файликов.

Posted via email from Комуникликабельность

Бажная терминология

Гейзенбаг (англ. Heisenbug) — термин, используемый в программировании для описания программной ошибки, которая исчезает или меняет свои свойства при попытке её обнаружения. Примером могут являться ошибки, которые проявляются в окончательном варианте программы (релизе), однако не видны в режиме отладки, или ошибки синхронизации в многопоточном приложении. Гейзенбаги очень сложно искать, поскольку они проявляются в зависимости от случайных факторов и воспроизводятся нестабильно (свою роль играет и сложность анализа состояния многопоточной системы). Поэтому их стараются отсечь еще на этапе проектирования, продумывая процедуры синхронизации.

Борбаг (англ. Bohr bug) — термин, используемый в программировании для описания программной ошибки, которая, в противоположность гейзенбагу, не исчезает и не меняет своих свойств при попытке её обнаружения. Это слово, в отличие от слова «баг», в русском языке практически не используется. Близкий по значению русскоязычный аналог — «стабильный» или «устойчивый» баг.

Мандельбаг (англ. Mandelbug) — термин, используемый в программировании для описания программной ошибки, чьё поведение столь сложно, что выглядит хаотичным. Это также подразумевает, что говорящий полагает, что это скорее борбаг, чем гейзенбаг.

Шрёдинбаг (англ. Schroedinbug) — термин, используемый в программировании для описания программной ошибки, которая никак не проявляет себя, однако внезапно возникает, если кто-то наткнётся на неё в исходном коде или попытается использовать программу в необычных условиях и осозна́ет, что система вообще не могла работать при наличии такой ошибки. После этого программа перестаёт работать вообще до тех пор, пока ошибка не будет исправлена. Хотя это звучит невероятно, некоторые программы содержат в себе такие ошибки.

Баги фазы луны

Термин «фаза луны» зачастую возникает, как понятие о глупом параметре, от которого может зависит баг, после того, как все утомились искать истинные причины. Jargon File отмечает два редких случая, в которых проблемы с обработкой данных действительно вызваны фазами луны.

Статистические баги

Статистические баги можно отловить только при многократном запуске фрагмента кода. Обычно эти ошибки появляются при создании случайных или псевдослучайных результатов. Например, программа, равномерно распределяющая точки по поверхности, скажем, сферы, в результате демонстрирует, что в нижнем полушарии значительно больше точек, чем в верхнем. Пошаговое исполнение создания одной точки совершенно не может пролить свет на происхождение ошибки, потому что невозможно назвать каждый отдельный результат неверным — в конце концов, он же должен быть случайным! Проблема становится понятной только при создании множества точек. Стандартные приемы отладки, вроде проверки начальных и конечных условий, тоже мало чем помогут. Похожие пробемы часто случаются в численных методах, где каждая конкретная операция точна в пределах выбранной погрешности, но после большого числа итераций накапливаются ошибки, особенно при наличии статистического смещения.

Альфа-баг

Термин альфа-баг происходит от исторического феномена «ошибок железа», вызванных излучением альфа-частиц. Эти частицы, появляющиеся случайным образом, могут повлиять на электроны в RAM и превратить 0 в 1 или наоборот. То есть термин используется для описания типа ошибок, продемонстрировавших неверный результат, но анализ кода говорит, что баг невозможен. Таким образом, единственный вариант разгадки — это альфа-частицы, повлиявшие на электрон. Обычная причина таких багов — ошибки билда или сборки, или какой-то необычный дефект памяти.

Posted via email from Комуникликабельность