Очень часто, глядя на стек падения, хочется увидеть, а с какими значениями параметров были сделаны вызовы. Под отладчиком в VisualStudio мы эти значения посмотреть можем. А как быть в случае, если программа запущена без отладчика и обрабатывает исключения самостоятельно? За ответами добро пожаловать под кат.
Читать полностью »
В предыдущих статьях мы сделали большое и доброе дело — научились автоматически собирать предысторию падения программы и отправлять её с крэш-репортом. Для WinForms, WPF, ASP, Javascript. Теперь научимся показывать все эти горы информации в удобоваримом виде.
Читать полностью »
Разбираться с падениями программы у конечных пользователей — дело важное, но довольно тяжкое. Доступа к машине клиента обычно нет; если есть доступ, то нет отладчика; когда есть отладчик, оказывается, что проблема не воспроизводится и т.п. Что делать, когда нет даже возможности собрать специальную версию приложения и установить её клиенту? Тогда добро пожаловать под кат!
Читать полностью »
После написания функционала авторекордера действий пользователя, названного нами breadcrumbs, в WinForms и Wpf, пришло время добраться и до клиент-серверных технологий.
Начнем с простого — JavaScript. В отличии от десктопных приложений тут все довольно просто — подписываемся на события, записываем необходимые данные и, в общем-то, всё.
Читать полностью »
Недавно мы рассказывали о том, как можно логировать действия пользователей в WinForms приложениях: Оно само упало, или следствие ведут колобки. Но что делать, если у вас WPF? Да нет проблем, и в WPF есть жизнь!
В WPF не надо будет вешать никаких хуков и трогать страшный винапи, собственно за пределы WPF мы и не выйдем. Для начала вспомним, что у нас есть routed events, и на них можно подписываться. В принципе, это все, что нам надо знать, чтобы реализовать поставленную задачу :)
Читать полностью »
Наверное, мало кто из нас задумывался, что практически с рождения пользовался дашбордами. Мы получали некую информацию, анализировали, принимали решение или даже испытывали какие-то эмоции благодаря им. Да-да, градусник, измеряющий температуру, когда вы болели; часы; стрелка спидометра, перевалившая за 200 км/час (ну, это может быть не у всех) — все эти приборы по сути являются дашбордами или их элементом. Но мне бы хотелось рассказать об интерактивных аналитических дашбордах. И, самое главное — показать, что в наше время такие дашборды могут быть полезны каждому человеку, а не только крупным банкам или корпорациям.
Если у вас есть данные — не важно, домохозяйка вы с пачкой чеков от закупок продуктов, спортсмен с данными о пробежках из Strava или кто-либо ещё — вы сможете представить это наглядно, оценить важные показатели, в результате чего принимать более оптимальные решения.
Вы не используете дашборды и думаете, что вам это не нужно? Мнение может поменяться, а кругозор расширится, так как далее: что такое дашборды, какие цели достигаются с помощью них, ключевые понятия и сферы использования, существующие инструменты, множество ссылок на актуальные ресурсы по теме, а также реальный пример, как из обычных на первый взгляд данных, можно извлечь интересные знания…
Читать полностью »
Вот задеплоили мы своё приложение, и, как правильные и опытные разработчики, не забыли вставить в него крэш-репортер. Получаем первые репорты, открываем стек, смотрим на окружение, пробуем воспроизвести, обламываемся и задаём в пространство вопрос «чем ты это сказал? а как так получилось-то?» Что же там пользователь сделал такого, что приложение завалилось?
Читать полностью »
В этой статье я расскажу о том, как настраивал непрерывную интеграцию в Amazon AWS для репозитория DevExtreme.
Уже несколько месяцев мы ведём разработку DevExtreme в открытом репозитории на GitHub. Непрерывная интеграция у нас с самого начала была построена на базе Docker, чтобы не зависеть от CI-платформы (будь то Travis, Shippable или что-то другое), но с момента публикации репозитория мы не выделялись и использовали для прогона тестов хорошо знакомый Travis CI. На GitHub у нас "бегает" только небольшая часть автоматических тестов, так сказать, первая линия, и возможностей Travis для техники Fork and Pull Request хватало.
Со временем коллеги начали сетовать на очередь из пулл-реквестов (но терпели). Мысль о том, что пора уже что-то предпринять, возникла в конце октября, когда на два дня Travis потерял связь с Docker Hub, а мы как раз готовились к beta-релизу DevExtreme 17.2.
Получив добро на эксперименты в корпоративном AWS-аккаунте, я решил дать второй шанс проекту Drone. Почему второй? Потому что мы его уже пробовали в процессе "обкатки выхода на GitHub". Тогда наш репозиторий был приватным, Drone был ещё более сырым, чем сегодня, и запускали мы его на временной наколеночной инфраструктуре, точнее на старых рабочих станциях, оставшихся после апгрейда рабочих мест (наш IT-отдел обещал их вот-вот забрать, но не торопился).
Как известно, программ без ошибок не бывает, и существует очень много инструментов и подходов, призванных улучшить качество выпускаемых приложений, от юнит тестов до анализаторов кода. Однако, даже если использовать все их одновременно, никто не даст гарантии, что ваши приложения лишены каких-либо ошибок. И если проблемы, возникающие во время разработки и тестирования, видны нам сразу, ну или почти сразу, и мы имеем возможность получить подробную информацию, что произошло и оперативно это исправить, то ошибки после выпуска, происходящие на пользовательской стороне, являются более коварными.
Самое главное, что, скорее всего, вам о них просто не сообщат. Как часто вы отправляли ошибки в Microsoft, когда вас об этом просили? :) Пользователи, как правило, либо просто перезапускают приложение, матерятся и продолжают пользоваться дальше, либо удаляют его полностью. Если вам повезет, и о падении вам сообщат, то зачастую это выглядит как-то так:
и это не вносит абсолютно никакой ясности в понимание проблемы. В результате у пользователей формируется негативный опыт от использования вашей программы, а вы не имеете никакой возможности что-то с этим сделать.
Читать полностью »
Время — самый ценный ресурс который у нас есть. Чтобы использовать его максимально продуктивно, существуют всякого рода техники тайм-менеджмента. Если говорить о тайм-менеджменте в масштабах рабочего дня, то одна из самых популярных техник называется Pomodoro. Но эта статья не про GTD, а про код (и немного про железо ^^).
Так вот, для техники Pomodoro есть инструмент Tomighty и у него открытый исходный код на C#, что побуждает к модификации этого самого кода с целью добавления новых возможностей и интеграции со всякими штуками.
Сегодня мы будем интегрировать клиент Tomighty с устройстовм "Большая Красная Кнопка". Нам для этого понадобится:
Зачем? Чтобы получить опыт работы с чужим кодом. В связи с грядущим Hacktoberfest, этот скилл будет крайне актуален.
Welcome!
