App Crash Handler

Может быть, вы замечали у себя в системе процесс GoogleCrashHandler.exe, который постоянно работает, появляясь в системе с установкой браузера Chrome. Долгое время где-то в подкорке постоянно крутилась мысль о том, как же он может работать. Интуитивно мне было понятно, что это относится к браузеру, что этот процесс отслеживает падения браузера и отсылает отчеты с параметрами падения, чтобы инженеры в Гугл могли оценить причины прекращения работы и принять какие-то решения по улучшению работы. Я не поддерживаю конспирологические теории на счет того, что с помощью этого процесса собирается приватная информация о пользователе.

Скриншот не с моей машины.

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

Исходя из названия и общей идеи мне стало интересно сделать свой «велосипед», так как коммерческие решения на рынке существуют, а вот о бесплатных я как-то не слышал. Да, есть программы у Microsoft (бесплатно) или у RedGate (платно), по которым тебе будут высылаться все отчеты об ошибках, которые возникли во время работы, но для этого нужно, чтобы пользователь нажал на кнопку «отправить данные». Зарегистрировать свою программу у вендора для участия в таком сборе. В корпоративном секторе, когда разработка внутренняя и градус паранойи повышен, такие варианты слабо прокатывают – все должно быть внутри и за пределы компании не выходить из соображений безопасности.

Идея

Почему это может быть важно для вас?

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

  • анализировать частоту возникновения ошибок
  • тип ошибок
  • можно сразу реагировать на ошибки, так как не требуется письма или звонка пользователя
  • писать автоматизированные отчеты о критических ошибках на основе данных в БД

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

Подробнее

Обновление WCF конфигурации online

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

Сервисов сейчас больше 50 и каждый имеет свой отдельный адрес и порт. Количество сервисов постепенно растет, и я не удивлюсь, если через полгода их уже будет 100+. Естественно в таком подходе вопрос настройки сервиса и клиента встает в полный рост. Руками такое править сложно, да и не хочется. При таком количестве сервисов риск того, что порт будет уже занят, сильно отличен от нуля.

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

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

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

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

Подробнее

Notepad – –

Это несколько необычная статья в сравнении со всеми предыдущими, потому что это скорее как аккумулирование и сумма предыдущих статей этого сезона. Это пример взаимодействия компонентов о которых я писал недавно: межпроцессное взаимодействие, менеджер команд, регистрация расширений. Пример назвал я так, потому что примером был выбран Notepad++, но в виду того, что эта программа только демонстрирует возможнсти в условиях приближенным к боевым, то получается минус-минус.

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

Думаю, что стоит все же рассмотреть как это работает в реальности. Остановившись только на отличиях, которые появились в реальной жизни. Заодно и будет видно насколько описательный материал отличается от рабочего прототипа.

Подробнее

Interprocess Communications

Давно было интересно, как делается так, чтобы был запущен только один экземпляр программы. Т.е. я знал в теории примерно с помощью чего это делается, но попробовать это в деле руки так и не доходили. Еще очень интересно было как так делается, что я открываю скажем таблицу Excel и она открывается не в еще одном приложении, а в том что уже открыто. Это конечно выбешивает порой, но все равно технология интересна.

Шуршание в интернете подвело к тому, что это называется Interprocess Communication (IPC) и существует множество способов как это осуществить, в зависимости от конечной цели, то ли вам надо только один экземпляр программы, то ли как в Экселе, то ли еще чего. Дальнейшее изучение вопроса и родило эту статью.

Подробнее