Расширения для chrome

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

Сейчас, зайдя в галерею, удивился обилию расширений. Сразу же поставил себе несколько (не буду говорить какие, дабы лишний раз не рекламировать, если хотите знать – спрашивайте лично). Что меня поразило, что chrome стал очень хорошо поддерживать расширения. Это касается и их установки и их работы. В принципе, я покрыл несколько своих потребностей, которые были у меня на работе, например, уведомлялку о почте на Gmail или отображение RSS лент. Помимо этого, нашел плагин, который хотел было уже писать сам – iReader (черт, все таки получилась реклама), который для некоторых статей, блогов и прочего может отображать основную статью крупно, без всякой рекламы и т.д. (привет версиям для печати) читать такую статью становится невероятно приятно.

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

Примеры использования технологий MS

В блоге J.D. Meier's Blog появились коллекции примеров кода  а также сценариев применения для различных технологий MS: ADO.NET, ASP.NET, Silverlight, WCF, Windows Azure, Windows Phone. Примеры кода ссылаются на MSDN. Очень удобная штука, если нужно быстро применить какой то типовой сценарий использования технологии, да и выбрать технологию по области ее применения, а не как обычно «да в принципе подойдет».

Для меня интересной показалась коллекция ссылок на примеры кода по WCF. В принципе есть все что нужно для быстрой разработки «более сложного» функционала сервисов, как то прикручивание безопасности или транзакционности.

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

WCF и Streamed

Прихожу постепенно к мысли, что WCF просто напросто не предназначен для того, чтобы передавать большие куски данных. А Streamed, который в нем реализован – это просто костыль, который покрывает часть задач, но не ложится в общую идею WCF. Вообще, иногда складывается впечатление, что в WCF все построено по «кусочному принципу». Функционал реализован мелкими кусками, как будто разработчики пытались «растянуть» архитектуру на как можно больший пласт задач, а она (архитектура) в силу технических ограничений никак не позволяла это сделать. Вот пример, того, что WCF не покрывает ряд задач аутентификации при Streamed режиме. Я кстати об этом же писал недавно.

Какие варианты потокового доступа к данным и раздачи контента есть еще?..

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

Прикольные 404 страницы

Сегодня случайно ткнул куда то не туда, и нарвался на вот такую веселую 404 страничку.

Сразу вспомнил 404 страницу с каким то скриптом, который печатал фразы. Создавалось впечатление что веб-сервер разговаривает с тобой. Кто еще помнит прикольные 404 ошибки?

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

Ищем ошибки WCF сервиса

Последнее время стал отслеживать всякие форумы и другие хранилища знаний в области WCF, вроде такой http://www.gotdotnet.ru/forums/19/. Удивился тому, что люди просто напросто не знают как выяснить какая ошибка мешает работе WCF сервиса. Причем проблема скорей не в том, что люди не хотят выяснить ошибку, они просто не знают как это сделать. Поэтому сейчас я буду играть в детектива, говорить «элементарно, Ватсон», пуская круги дыма из трубки … В общем сейчас расскажу простые вещи, которые можно сделать, чтобы выяснить в чем ошибка.

Включаем отображение ошибок для IIS

Для asp.net разработчиков, да и для всех более менее адекватных разработчиков дело привычное и вроде бы понятно что делать – включить отображение ошибок. Значит добавляем в web.config следующие строчки:

<customErrors mode="RemoteOnly" />

Или

<customErrors mode="Off" />

И сразу все становится понятно:

Скажу еще, что отображение ошибок полезно в случае, когда сервис просто не запускается. Возможно из-за ошибок, связанных с компиляцией, правами доступа и еще 1000 ошибок, которые мешают нормальному запуску сервиса.

Включаем трассировку WCF

Подробней о трассировке WCF можете посмотреть тут. Как правило, долго сидеть с конфигураций не хочется. Прописывать здоровый кусок конфига дело неблагодарное. Благо, есть такая интереная утилитка, как WCF Service Configuration Editor. Вызывается она либо из меню Tools студии, либо из контекстного меню Solution Explorer на конфиге. Утилитка работает и вне контекста студии, так что можно использовать и там, где установить студию нельзя. Нас в данной утилите интересует раздел Diagnostics и его подраздел - Tracing.

Нас в большинстве случаев интересует две настройки:

1.       Непосредственно включение Tracing.

2.       Log file – файл, куда будет писаться лог.

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

Для файлов трейса есть интересная особенность, они находятся в монопольном доступе у службы, поэтому прежде, чем их просматривать с помощью утилиты нужно закрыть хост сервиса. В случае с IIS – перезапустить группу приложений, что в некоторых случаях невозможно.

Отладка

Если перечисленные выше простые способы не помогают, приходится использовать тяжелую артиллерию, в данном случае – отладку. Однако и она не всегда помогает. Пример тому – ошибка в недрах WCF, когда просто напросто невозможно подхватить ошибку отладчиком. Такое случается как правило, когда переписываются стандартная инфраструктура WCF, как то свой сериализатор, или система аутентификации. В данных случаях бывает полезным включение трейсов.

В итоге

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

Удачной отладки!!! ;)

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

Windows Live Essentials 2011

Попробовал поставить Windows Live Essentials. Изменений нашел достаточно немного.

Что я увидел после установки:

1.       Messenger научился работать с Facebook и другими социалками (Linked In и т.д.).

2.       Добавили SkyDrive, вроде раньше не было в базовом пакете.

3.       Writer получил наконец то Ribbon, стало красиво и функционально.

4.       Writer нормально без проблем из коробки настраивается на Wordpress блог.

В итоге, не нашел причин, чтобы переходить на использование Windows Live.

1.       Writer я давно и успешно заменил постингом по почте. Писать как в outlook, так и в writer одинаково.

2.       Пока Live Mail не научится работать с Mobile Center для синхронизации календаря, задач и почты переходить на него для меня бессмысленно.

3.       Переходить на альбомы смысла нет, поскольку Picassa покрывает все мои необходимости.

4.       Остальные приложения пакета для мне пока что не нужны.

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

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

WCF transfer large DataSet or DataTable - Part 2

Продолжение размышлений, которые я начал в прошлой статье WCF transfer large DataSet or DataTable.

Начал реализовывать свою версию chunked коллекции. Вот на какие вопросы сразу же наткнулся:

1.       Интероперабельность. Написание клиентов для не WCF платформы, или нового WCF клиента с нуля становится нетривиальной задачкой без кода непосредственно подгружающего данные порциями.

2.       Серверная логика. Если на сервере крутится 2 независимых сервиса, то для произвольных данных нужно либо уметь выбирать данные порциями, либо сохранять /кешировать результат запроса, для того, чтобы не вытаскивать кучу раз кучу данных (а именно в ситуации с кучей данных нужны такие извращения). Да и хранение такого количества данных накладно.

3.       Клиентская логика. Коллекцию нужно уметь сливать. Для примера: я гружу коллекцию в трех потоках 1-100 записи, 100-200 записи и 200-300 записи. Первым отрабатывает поток, который отдаст 100-200 записей, соотвественно мне как то надо при получение остальных порций данных слить все в одну коллекцию. При рассмотрении произвольных данных ситуация ухудшается.

4.       Идентификация. Нужно как то водить дополнительный уровень идентификации, для того, чтобы знать к какому объекту мы хотим обращаться.

Попробую все же добить эти вопросы и написать нормальную реализацию для коллекций. На 1 вопрос придется видимо просто забить, тут ничего не поделаешь, идеологически не прокатит. Вопрос 2 и 4 оставлю видимо на усмотрение разработчика сервиса, поскольку большие зависимости от того, какие передаются данные.

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

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