Сильный пароль, который хорошо запомнить? Легко!

У меня есть простой способ, который позволяет придумать сильный пароль, который легко запомнить и (что еще более важно :)) легко вспомнить через время.

Суть метода в следующем. Берем какое-нибудь четверостишие или несколько строк из хорошо знакомого стихотворения и затем трансформируем текст в пароль по следующему алгоритму:

1. Для формирования пароля используем первые буквы слов. Лучше с учетом регистра.
2. Для русскоязычного текста используем транслитерацию.
3. Для обозначения переносов строк используем специальные символы _ – = # % ^ *.
4. Заменяем буквы похожие на цифры – цифрами или специальными символами
   • A - @
   • S - $
   • O - 0
   • L – 1
   • B -6
   • I - &
5. Для слов отрицания используем символ ! или ~.
6. Знаки препинания можно сохранить, а можно исключить.

Пункты 1 и 2 должны выполняться первыми, остальные – в произвольном порядке.

А теперь от слов к делу – рассмотрим пример. В качестве примера возьмем вот такую фразу

Прошла зима, настало лето — спасибо Путину за это!

Выполнив пункты 1 и 2 получим следующий текст:

Pznl-sPze!

Пунктов 3 и 5 у нас нет. После пунктов 4 и 6 получим итоговый пароль:

Pzn1-$Pz!

Теперь проверим качество пароля, например, при помощи Password Meter:

А вот с использованием Password Checker от Майкрософт пароль получил среднюю оценку.

.

Попробуем еще раз. Теперь возьмем текст подлиннее:

Наша Таня громко плачет:
Уронила в речку мячик.
- Тише, Танечка, не плачь:
Не утонет в речке мяч.

Выполнив пункты 1, 2 и 5 получим следующий текст:

nTgp

Yvrm

TT!p

!yvrm

Выполнив пункт 3 получим:

nTgp_Yvrm-TT!p=!yvrm

Пункта 4 у нас нет и по этому итоговый пароль следующий:

nTgp_Yrvrm-TT!p-!yvrm.

Несмотря на то, что в пароле не оказалось цифр, в этот раз Рassword Сhecker оказался более благосклонным:

И на последок. Не используйте приведенные здесь примеры паролей.

Как востановить поврежденный файл данных Outlook

Однажды, после неудачной синхронизации со смартфоном (я в это время еще игрался с Search Folders) Outlook меня порадовал вот таким сообщением:

Признаюсь, меня чуть кондратий не хватил – у меня там и почта и митинги и таски.

Как ни странно, но никакие рестарты (а именно это и советуется в сообщении об ошбике ;)) ему не помогли.

Традиционый совет, который я нашел в интернете, в подобном случае – запусить запустить Outlook c командой /resetnavpane тоже к результату не привел. Что вобщем-то и логично. Поскольку проблема не в кривом размещении окон, а в поврежденном файле данных Outlook. Какой-либо другой команды по рестарту Outlook c востановлением у Outlook тоже не обнаружилось (официальный список команд здесь).

После целенаправленных поисков по востановлению файла данных Outlook нашел ссылку на Inbox Repair Tool (Scanpst.exe).

Хоть название утилилты не особо вселяло надежду (у меня грохнулся не просто Inbox, а весь файл с почтой, календарем и пр.), програму я нашел и запустил. У меня она располагается здесь "C:\Program Files (x86)\Microsoft Office\Office12\SCANPST.EXE".

Файл сканировался больше часа (а что ж вы хотели пару гигов то ;)) и к моему счатью ему помогло.

Пару выводов из всей этой истории:

1. Совет в сообщении об ошибке 'Microsoft Office Outlook' must be restarted – что мертвому припарка. Лучще бы сразу советовали запустить сканирование Scanpst.exe, если поврежден файл данных.

2. Inbox Repair Tool стоит переназвать. Что-то вроде Outlook Data File Repair Tool куда больше соответсвует действительности.

3. Такую ценную утилиту стоит выноить в Start Menu.

4. Ну и последнее. Не настраивайте Search Folders во время синхронизации с Outlook ;).

Использование C# кода и объектов расширения (extension objects) в XSLT-процессоре .NET Framework

В .NET реализована спецификация XSLT 1.0 и его возможностей за частую не хватает. Например, отсутствует использование регулярных выражений, нет кодирования строк для использования в URL и т. д. В то же время .NET Framework позволяет обойти ограничения за счет таких средств как:

1. параметры XSL трансформации;
2. встраивание кода на JavaScript, VB.NET, C# и других языках;
3. использование объектов расширения (extension objects.

В этой статье я хочу остановиться только на 2-х способах, которые сам регулярно использую, внедрение кода на С# и объекты расширения. Чтобы примеры были более конкретными, допустим, что у нас есть XML файл в котором содержатся данные для формирования линки на поиск в Bing. Вот пример такого XML файла:

Чтобы примеры были более конкретными, допустим, что у нас есть XML файл в котором содержатся данные для формирования линки на поиск в Bing.

Вот пример такого XML файла:

xml version="1.0" encoding="utf-8" ?>

<queries>

<query title="A & B" term="A & B"/>

queries>

Если в такого рода задаче не кодировать параметры для URL, то специальные символы (как &) не будут закодированы и URL будет распознан не верно либо может сформироваться невалидный URL.
Ниже приведен пример поиска по запросу из XML файла без кодирования параметров

А здесь правильный вариант

В первом случае символ & не был закодирован и не распознан, как часть строки поиска. Во втором случае & был закодирован и Bing распознал его.

Ниже приведены примеры, как можно добавить кодировние URL внедрением C# кода и с использованием объектов расширения. Фрагменты C# кода и XSLT на которые надо обратить внимание, выделены жирным и увеличенным шрифтом.

Пример XSLT с внедрением С# кода

xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet

version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:utility="urn:utility-scripts"

exclude-result-prefixes="msxsl">

<xsl:output method="html" indent="yes"/>

<xsl:template match="query">

<xsl:element name="a">

<xsl:attribute name="href">

<xsl:value-of select="concat('http://bing.com/search?q=', utility:EncodeUrl(@term))"/>

xsl:attribute>

<xsl:value-of select="@title"/>

xsl:element>

<br />

xsl:template>

<msxsl:script language="C#" implements-prefix="utility">

<msxsl:assembly name="system.web" />

public string EncodeUrl(string rawUrl) {

return System.Web.HttpUtility.UrlEncode(rawUrl);

}

]]>

msxsl:script>

xsl:stylesheet>

Пример с использованием объектов расширения
XSLT:

xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet

version="1.0"

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

xmlns:msxsl="urn:schemas-microsoft-com:xslt"

xmlns:utility="urn:utility-scripts"

exclude-result-prefixes="msxsl">

<xsl:output method="html" indent="yes"/>

<xsl:template match="query">

<xsl:element name="a">

<xsl:attribute name="href">

<xsl:value-of select="concat('http://bing.com/search?q=', utility:EncodeUrl(@term))"/>

xsl:attribute>

<xsl:value-of select="@title"/>

xsl:element>

<br />

xsl:template>

xsl:stylesheet>

Вызывающий C# код:

class Program

{

static void Main(string[] args)

{

XslCompiledTransform xsltAndExtObjTransform = new XslCompiledTransform();

xsltAndExtObjTransform.Load("..\\..\\XsltAndExtObj.xslt");

XsltArgumentList arguments = new XsltArgumentList();

arguments.AddExtensionObject("urn:utility-scripts", new Program());

using (StreamWriter writer = File.CreateText("XsltAndExtObj.html"))

{

xsltAndExtObjTransform.Transform("..\\..\\Data.xml", arguments, writer);

}

}

public string EncodeUrl(string rawUrl)

{

return System.Web.HttpUtility.UrlEncode(rawUrl);

}

}

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

Если же сравнивать межу собой внедрение c# кода и объекты расширения, то предпочтительней использовать объекты расширения. Их проще разрабатывать – есть подсветка синтаксиса и синтаксические ошибки выявляются на этапе компиляции проекта . Проще сопровождать – можно (и нужно) написать unit-test для проверки логических ошибок. Ну и на конец объект расширения можно будет использовать повторно (и не только в XSLT).

Удобство в использовании объектов расширения в том, что весь код, необходимый для их работы находится в том же XSLT файле. Без каких либо дополнительных усилий и зависимостей, XSLT c объектами расширения можно использовать в другой трансформации, другом .NET проекте.

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

Эрик Гамма переходит на работу в Майкрософт

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

Незаменимых нет? (или чем заменить .NET Reflector)

Многие знают, что с июня месяца рефлектор стал платным. За неделю до этого события я решил подыскать себе бесплатную альтернативу. Выбирал среди ILSpy, JetBrains dotPeek и Telerik JustDecompile. Около недели я ими пользовался, и свои наблюдения я фиксировал в файлике. Таким образом, у меня появилась небольшая статья, которая, возможно, кому-нибудь облегчит выбор.

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

Наиболее важные для меня критерий выбора декомпилятора были следующие:

1. Удобство работы
2. Скорость работы (загрузка, поиск типа, декомпиляция)
3. Функционал
1. Analyze
2. Декомпиляция в Visual Basic
3. Search MSDN
4. Поиск типа, метода, строки.

Естественно, поскольку, удобство работы, это очень нечеткий критерий, то и вывод мой, что мой вывод будет субъективным.

По скорости работы особых нареканий у меня тоже не оказалось. Точнее все работают приблизительно одинаково медленно ;), разве что Telerik JustDecompile грузится немого медленей других.

А вот по развитости второстепенного функционала продукты отличаются довольно сильно.

К сожалению, на текущий момент ни один из декомпиляторов не поддерживают следующие операции:

• Поиск строки
• Поиск выбранного типа в MSDN
• Поиск выбранного типа в Bing

Однако, что поскольку разработка этих продуктов началась сравнительно недавно (февраль 2011) и еще идет полным ходом, функционал может существенно измениться. Поэтому ниже я привожу версии продуктов, между которыми я выбирал.

Далее я приведу скриншоты декомпиляторово и их краткое описание (отличие).

ILSpy билд 1.0.0.822

Очень похож на.NET Reflector. Умеет декомпилировать в C# и IL. Есть приятная функция, которой нет в рефлекторе и в других декомпиляторах – при декомпиляции кода показывает комментарии, что очень удобно.

Единственный из продуктов, который позволяет пометить сразу несколько сборок для удаления.

Telerik JustDecompile Beta билд 2011.1.516.2

Минусы начинаются со скачивания инсталлятора – при скачивании требует регистрации. У меня регистрация была, но в противном случае я бы его не стал скачивать.

Интересное совпадение, пока я писал эту статью JustDecompile показал мне уведомление, что есть обновленние, но что бы его скачать надо было опять вводить регистрационные данные. Лень мне стало их искать и обновление не стал скачивать.
Переборщили они с этим.

Немного не типичный интерфейс пользователя из-за чего создается впечатление что у программы Из рассматриваемых продуктов единственный, который на текущий момент умеет декомпилировать в C# и Visual Basic .NET.

Функция Analyze здесь называется Find Usages. Есть проблемы с поиском типов. Почему-то не всегда находит типы, так же не всегда при поиске типов фокус ввода в поле ввода. Мелочь, а неприятно.

JetBrains dotPeek билд 1.0.0.1219

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

Из существенных ограничений – умеет только декомпилировать в C#.

Для тех, кто пользуется решарпером интерфейс и горячие клавиши будут знакомы. Жаль, но не работает как в решарпере поиск элемента по заглавным буквам. Отличается и немного терминология. Т.е. нет команды Analyze, но есть Find Usages и Find Usages Advanced.

Нет панели инструментов с кнопками навигации (как-то привык я к нему в рефлекторе), чтобы перемещаться по коду вперед-назад надо выбирать пункта Navigate главного меню, что откровенно говоря не удобно. К счастью для этих команд горячие клавиши такие же как и в студии по дефолту.

Автоматически не выделяется текущий тип в дереве (но есть специальная команда ;)).

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

Из интересных новшеств подметил, что dotPeek умеет подгружать с сайта Майросовт реальный исходный код (как это делает студия), но у меня почему-то это не сработало (возможно, тоже какой-то дефект).

Выводы

Меньше всех понравился JustDecompile. Оставлю только на случай если понадобится декомпиляция в Visual Basic .NET. Между ILSpy и dotPeek окончательный выбор я так пока не сделал. Я хоть и пользусь решарпером и нравится мне продвинутая функциональнось dotPeek, но как-то в большинстве случаев ILSpy пользоваться удобней. Возможно, сказывается привычка к .NET Reflector, а ILSpy больше всего на него похож.

Офисный фитнес

Пятница навеяла.

Один из краеугольных камней таймменеджмента – это отдых. Отдыхать надо регуляно и правильно . Правильный отдых для программистов – это не чтение новостей и блогов под кружку чая или кофе (как многие из нас любят делать), а какая-либо физическая нагрузка.

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

Заметил интересный побочный эфект. Во время ходьбы по лестницевспоминается что-то что хотел бы сделать, но нигде не записал, приходят интересные идеи (но как правило не связанные с работой ). Всем хорошего отдыха!

Если хочешь что-то спрятать – положи на видном месте

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

Ниже скриншот с моего прошлого поста