Будни программиста

Однажды, после неудачной синхронизации со смартфоном (я в это время еще игрался с Search Folders) Outlook меня порадовал вот таким сообщением: Признаюсь, меня чуть кондратий не хватил – у меня там и почта и митинги и таски. Как ни странно, но никакие рестарты (а именно это и советуется в сообщении об ошбике ;)) ему не помогли. Традиционый совет, который я нашел в интернете, в подобном случае – запусить запустить Outlook c командой / resetnavpane тоже к результату не привел. Что вобщем-то и логично. Поскольку проблема не в кривом размещении окон, а в поврежденном файле данных Outlook. Какой-либо другой команды по рестарту Outlook c востановлением у Outlook тоже не обнаружилось (официальный список команд здесь ). После целенаправленных поисков по востановлению файла данных Outlook нашел ссылку на Inbox Repair Tool ( Scanpst.exe ) . Хоть название утилилты не особо вселяло надежду (у меня грохнулся не просто Inbox, а весь файл с почтой, календарем и пр.), програму я нашел и запустил.

В .NET реализована спецификация XSLT 1.0 и его возможностей за частую не хватает. Например, отсутствует использование регулярных выражений, нет кодирования строк для использования в URL и т. д. В то же время .NET Framework позволяет обойти ограничения за счет таких средств как: параметры XSL трансформации; встраивание кода на JavaScript, VB.NET, C# и других языках; использование объектов расширения (extension objects. В этой статье я хочу остановиться только на 2-х способах, которые сам регулярно использую, внедрение кода на С# и объекты расширения. Чтобы примеры были более конкретными, допустим, что у нас есть XML файл в котором содержатся данные для формирования линки на поиск в Bing. Вот пример такого XML файла: Чтобы примеры были более конкретными, допустим, что у нас есть XML файл в котором содержатся данные для формирования линки на поиск в Bing . Вот пример такого XML файла: xml version = " 1.0 " encoding = " utf-8 " ?> < queries > &l

Как пишет в своем блоге Janson Zanders, признанный эксперт в области разработки программного обеспечения, соавтор книги Design Patterns, один из разработчиков JUnit и Eclipse -- Эрик Гамма присоединится к команде разработчиков Visual Studio и возглавит Visual Studio development lab в Цюрихе. Подробнее здесь .

Многие знают, что с июня месяца рефлектор стал платным. За неделю до этого события я решил подыскать себе бесплатную альтернативу. Выбирал среди ILSpy, JetBrains dotPeek и Telerik JustDecompile. Около недели я ими пользовался, и свои наблюдения я фиксировал в файлике. Таким образом, у меня появилась небольшая статья, которая, возможно, кому-нибудь облегчит выбор. С основной задачей – декомпиляцией кода все приложения справляются достаточно хорошо. Поэтому следующим шагом стал выбор наиболее удобной в использовании замены рефлектора и развитость «второстепенного» функционала. Наиболее важные для меня критерий выбора декомпилятора были следующие: Удобство работы Скорость работы (загрузка, поиск типа, декомпиляция) Функционал Analyze Декомпиляция в Visual Basic Search MSDN Поиск типа, метода, строки. Естественно, поскольку, удобство работы, это очень нечеткий критерий, то и вывод мой, что мой вывод будет субъективным. По скорости работы особых нареканий у меня тоже не оказалось. Точнее вс

Пятница навеяла. Один из краеугольных камней таймменеджмента – это отдых. Отдыхать надо регуляно и правильно . Правильный отдых для программистов – это не чтение новостей и блогов под кружку чая или кофе (как многие из нас любят делать), а какая-либо физическая нагрузка. Я стараюсь поступать так. Накапливаю мелкие задачи, чтобы выполнить во время отыха: занести справку в бухгалтерию, отнести админам диск, распечатать что-либо на принтере (принтер в другой комнате). Но любимый мой способ отдыха – это ходьба по лестнице. Поднимаюсь на 7-9 этажей, спускаюсь, и т.п, Темп и количество этажей зависят от настроения. Заметил интересный побочный эфект. Во время ходьбы по лестницевспоминается что-то что хотел бы сделать, но нигде не записал, приходят интересные идеи (но как правило не связанные с работой ). Всем хорошего отдыха!

В продолжение темы залоченных файлов. Совершенно случайно обратил внимание что оказывается стандартный диалог File In Use показывает имя процесса, который держит файл. Жаль что не позволяет его разлочить и не работает для каталогов. Ниже скриншот с моего прошлого поста

Я регулярно пользуюсь утилитами Sysinternals и хочу поделиться одним из cпособов как при помощи Process Explorer выяснить какой процесс заблокировал доступ к файлу или папке. Использовать утилиты очень удобно – они бесплатны, не требуют инсталляции и могут быть запущены без предварительного скачивания из интернета (см http://live.sysinternals.com/ ). Последние 2 пункта делают их очень удобными при анализе и устранении проблем на серверах. Я недавно завел Ютуб-канал, где выкладываю видео по теме блога. Приглашаю Вас посмотреть и подписаться что бы не пропустить новые выпуски. Итак, как же узнать, кто держит тот или иной файл или папку. Для скриншотов я смоделировал такую ситуацию нарочно, открыв в Word файл "D:\temp\Doc1.docx" и пытаясь его в это же время удалить в проводнике. При попытке удалить файл получаю следующее сообщение Поищем этот документ в Process Explorer: Find->Find Handle or DLL… В появившемся окне вводим имя заблокированного файла и жмем Search Двойной к

Друзья! Более двух лет в блоге не было ни одного сообщения. Как верно заметил BrigOS, в одном из комментариев, по сути блог был мертв и его можно было удалить из RSS ридера. Но блог не умер, он просто спал и набирался сил. За два года много изменилось – айфоны и айпэды захватили мир, а Live Search стал Bing. Изменилась и моя жизнь – у меня родился сын (и ему уже почти 2 года ;)), немного изменились и мои увлечения. Что бы успевать больше я стал верным адептом тайм-менеджмента и появилось время для ведения блога. Более того, появилось большое желание снова его вести. Возможно, немного изменится тематика блога – по мимо чисто програмистских тем, мне хочется поделисться опытом применения тайм-менеджмента в собственной жизни, появятся отзывы на прочитанные книги. Планируемая периодичность обновления блога – раз в 2 недели. До следующей встречи!