Жизнь в 100 словах

Колыбель. Пеленки. Плач.
Слово. Шаг. Простуда. Врач.
Беготня. Игрушки. Брат
Двор. Качели. Детский сад.
Школа. Двойка. Тройка.Пять.
Мяч. Подножка. Гипс. Кровать.
Драка. Кровь. Разбитый нос.
Двор.Друзья. Тусовка. Форс.
Институт. Весна. Кусты.
Лето. Сессия. Хвосты.
Пиво. Водка. Джин со льдом.
Кофе. Сессия. Диплом .
Романтизм. Любовь. Звезда.
Руки. Губы. Ночь без сна .
Свадьба. Теща. Тесть. Капкан.
Ссора. Клуб. Друзья. Стакан.
Дом. Работа. Дом. Семья.
Солнце. Лето. Снег. Зима.
Сын. Пеленки. Колыбель .
Стресс. Любовница. Постель.
Бизнес. Деньги. План. Аврал.
Телевизор. Сериал.
Дача. Вишни. Кабачки.
Седина. Мигрень. Очки.
Внук. Пеленки. Колыбель .
Стресс. Давление. Постель.
Сердце. Почки. Кости. Врач.
Речи. Гроб. Прощанье. Плач.

Обработка ссылок в системе

Проблема: есть программа, которая генерирует ссылки на свои объекты в некотором формате (например http://sample.ru/object.aspx?sys=sys_code&id=object_id ) при этом происходит обращение к веб-серверу, который возвращает файл с некоторым MIME типом, открываемый на клиенте зарегистрированной для этого типа программой (например, некоторым обработчиком объектов данной программы). Изменить формат ссылок нельзя, но вся необходимая для открытия объекта информация содержится непосредственно в ссылке.
Как одно из решений - написание расширений для браузеров, которое будет отрезать обращение к серверу для ссылок определенного формата и обрабатывать их самостоятельно.

• IE: решением для IE было бы создание Asynchronus Pluggable Protocol, но такое решение сталкивается с несколькими проблемами. Такое решение будет работать только если браузером по умолчанию стоит IE. Сложно писать (все таки ActiveX). Проблемы при установке. Проблемы при открытии ссылок из сторонних приложений.
• Firefox: для firefox все несколько проще. можно навеситься на событие ввода адреса в строку адреса и на событие загрузки браузера. А с помощью XUL можно запустить произвольное прилоджение
• Opera: Для этого браузера сделать подобный перехват не удастся. браузер конечно поддерживает пользовательские скрипты и плагины, но навеситься на перехват перехода по ссылке я не смог, кроме того, я не смог из пользовательского скрипта запустить внешнее приложение или обратиться к COM классам.

Однако, писать плагины под каждый браузер - несколько нелепо. Ведь обработка гиперссылок может по разному обрабатываться внутри приложений, а при передаче гиперссылок должны отрабатывать одни и те же системные механизмы. Универсальным решением все таки стала бы обработка имено таких событий.
Как я понял, в Windows обработкой гиперссылок занимается модуль urlmon.dll. Он же вызывает методы интерфейса IInternetProtocol и IInternetProtocolSink для Asynchronus Pluggable Protocol.
Универсального решения проблемы я так и не нашел. Если кто нибудь знаешь в какую сторону копать - подскажите плз.

Фото

Симпотичная фотка. Как раз на рабочий стол :) стырено отсюда

Подписка на события

Уже давно слышал о идее службы подписки на различные события: приход почты, возникновения ошибки, входа пользователя и т.д. Как правило простые события достаточно просто отслеживаются и необходимости в подписке не возникает.
Однако, порой нужно уметь подписываться на нестандартные события. Например недавно встретился с задачей: при записи в лог файл десятого сообщения, соответствующего определенному формату нужно отправлять письмо администратору.
Для такой задачи очень бы пригодилась система, способная генерировать сообщения, в зависимости от происходящих событий.
Что такая система должна делать:

• Уметь определять момент возникновения события системы(как ОС, так и прикладной системы, причем во втором случае может возникнуть необходимость или в периодическом опросе или в жесткой интеграции)
• Генерировать события подписки (рассылать почту, вызывать внешние методы, обращаться к веб-сервисам, издавать звук и т.д.)

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

Vista Aero и Web

Наткнулся на вот такой блог и задумался о том, действительно ли красота темы Aero Glass адекватна вэбу. Прозрачный интерфейс хорош, но стоит ли он того, чтобы переносить его в веб?
Менюшки потрясные, полупрозрачные png'шки очень неплохо смотрятся, но очень уж тяжело это все. Да и без картинок это будет выглядеть не совсем красиво.

ЗЫ: Кстати, на этом же блоге живет удивительный крысомамонт(замена RSS :) ). Улыбнуло.

Мониторинг состояния системы

Откуда вы обычно узнаете что ваша система не работает? От разгневаных клиентов? Или от неменее разгневаного руководства?

А как вы узнаете о причине неполадки? Используя собственный опыт и знание системы? Или долго и продолжительно изучаете логи, выискиваете ошибку, определяете причины?

А может не стоит дожидаться когда пользователь наткнется на отказ системы? Может этот процесс можно автоматизировать?
Только представьте, некоторая служба, регулярно проверяющая работоспособность системы(или нескольких систем). Она отслеживает работоспособность основных элементов системы (база, подключение, доступность, основной функционал), автоматически исправляет некоторые ошибки, и выдает подробный удобочитаемый сводный отчет о состоянии системы в целом и ее элементов.

И так, что требуется от службы мониторинга:

1. Иметь базовый набор тестовых методов для проверки базового функционала системы(здесь очень пригодятся автоматические тесты, написанные на этапе разработки или тестирования)
2. Уметь запускать мониторинг состояния системы в определенное время, проверять базовый функционал, логи и т.д.
3. Уметь формировать сводный отчет и отправлять его ответственному(администратору или разработчику)
4. Уметь устранять некоторые неисправности(например, перезапускать веб-сервер)

Недостатки такой системы:

1. Жестко связана с обследуемой системой.
2. Низкая гибкость, малая универсальность. Для каждой новой функциональности нужно писать свой метод для его мониторинга.
3. Большие накладные расходы на полный мониторинг(трафик, время, загрузка сервера).

Для устранения этих недостатков можно

1. Использовать автоматические тесты, созданные на этапе разработки или тестирования.
2. Проводить мониторинг эпизодически (по требованию) для устранения неполадок.

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

Веб-сервисы. Xml серелизация COM объектов.

Сегодня столкнулся со следующей проблемой. Веб-сервис должен обмениваться данными, которые получаются посредством некоторого COM класса. Данные хранятся в полях данного класса. При этом .NET не умеет серелизовать COM классы, да ему это и не нужно .
Решение проблемы может быть одним из следующих:

1. Выдирать из класса необходимые данные и записывать в свою структуру данных, которая уже будет серелизоваться. Достоинства: можно просто управлять серелизацией класса, можно также манипулировать полученными данными в классе, можно сделать свою систему хэширования данных на основе данных структур данных. Недостатки: необходим механизм преобразования COM класса в нашу структуру данных, причем такой механизм необходимо организовывать для каждого класса, сам же механизм представляет из себя лишь перенос данных из полей COM объекта в поля данных нашего класса.
2. Организовать "универсальный" механизм серелизации необходимых нам COM классов в виде, скажем, фабрики. Достоинства: общий механизм для серелизации, нет накладных расходов на хранение "промежуточных" классов с данными - вся работа ведется непосредственно через COM. Недостатки: данные COM объектов могут быть в спецефическом формате, и общий механизм серелизации его некорректно обработает.
   
3. Организовать "обертку" для COM, свойства которой серелизуются. Достоинства: Нет накладных расходов на хранение данных COM объектов, обертка просто серелизуется. Недостатки: Для каждого COM класса нужна своя обертка.
   

Вообще передача самого COM объекта для веб-сервисов не актуальна - необходимо передавать только данные, которые хранятся в их полях. Но для удобства разработки необходим универсальный подход. Удобно бывает не задумываться о том, как серелизуется и десерелизуется объект, для разработчика важны только данные, переданные методами сервиса.
Возможно для этих целей уже есть стандартное решение и я на него пока(!) не натолкнулся.