MCP

воскресенье, 15 ноября 2009 г.

Мои впечатления о Платформе 2010. Общее.

Попробую рассказать свои впечатления о недавно прошедшей Платформе 2010 от Microsoft. Впечатлений много, попробую их немножко структурировать, но если получится сумбурно, то заранее извиняюсь. В любом случае, не я первый буду писать о платформе, не я последний, так что всегда можно найти какие-либо другие мнения. 

Для начала несколько слов о том, как я вообще попал на платформу. Дело в том, что участие в ней стоило 20000 руб., со скидками дешевле, но тем не менее за свои деньги хоть и хотелось ехать, но всё-таки сумма смущала. Но совершенно случайно, благодаря твиттеру, я оказался среди победителей конкурса, который проводил Гайдар Магдануров, и как результат получил приглашение на Платформу. Ехал я не один, а с Денисом Гладких, который кроме всего прочего еще является MVP, так что в отличие от меня он ехал в качестве Эксперта (я обычный участник). Кстати, думаю он тоже поделится впечатлениями, и они наверняка будут с другого ракурса, и возможно даже более интересные чем мои. 

Не буду особо рассказывать про то как добирались, но добрались до места проведения, которое было в Центре Международной Торговли, без особых приключений. При регистрации я сразу же получил в качестве подарка весьма симпатичную сумку для ноутбука (кстати, размер оказался 14", а я достаточно долго искал сумку именно под данный размер, так что всё оказалось просто замечательно в этом плане), набор рекламных материалов (уже заботливо уложенных в данную сумку, так что отдельных пакетов таскать не пришлось), и беджик со штрихкодом и статусом. При этом беджик содержал бумажку с расписанием конференции и расположением залов, что весьма пригодилось впоследствии.

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

Про саму организацию мероприятия могу сказать, что всё было просто замечательно. Всегда можно было спросить как и куда добраться, перекусить в Атриуме, сдать вещи в камеру хранения, чтобы не таскать с собой, посидеть в интернете за компьютером (я обычно сидел со своего ноута, так что для меня было более важно что почти везде был WiFi), или поиграть в XBox. При этом можно было пообщаться с докладчиками в зоне "Спроси Эксперта", побродить по рекламным стендам Dell, HP, IBM, Intel, Microsoft Embedded и прочим.

При этом можно было получить кучу разных подарков за какие либо действия (например, заполнить анкеты). Из подарков запомнился оригинальностью подарок от HP — средство для разогревания замков в машине с фонариком, которое первоначально было принято за странную отвёртку, и лишь потом, когда я обжёгся, мне объяснили, что это.  Кстати, на стенде HP были самые красивые девушки.

Также от Интела получил в подарок интересный USB-hub, и дополнительно узнал много интересного про их программу ITGalaxy.

Дальше началось пленарное заседание на котором вначале выступил Николай Прянишников (президент российского подразделения Microsoft), а потом Норм Джуда вкратце рассказал план мероприятия, периодически вызывая других докладчиков, которые вкратце рассказывали о технологиях Microsoft. 

При этом, для тех, кто не очень хорошо владеет английским языком выдали девайсы, позволяющие слушать перевод (не знаю как они правильно называются, но смысл надеюсь понятен: приёмник с наушником). Хоть и по-английски было весьма понятно, я таки включил переводчика и уже слушал его. Всё-таки синхронный перевод с сохранением интонации и технических терминов, это весьма сложная работа, но переводчик с ней замечательно справился. 

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

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

Ну и в конце, чтобы не выглядело всё слишком замечательно, немного про минусы конференции.  На самом деле их было немного. Один из основных — сильно разнесённые в пространстве помещения. Например, чтобы сходить перекусить во время перерыва нужно было потратить минут 5 в одну сторону, до некоторых залов идти было ещё дольше. Но это больше связано с самим зданием WTC. Ну и местами было весьма тяжело подключиться к интернету, так что когда это удавалось приходилось стоять посреди холла, лишь бы отправить нужное письмо (чтобы не дай бог не сломать интернет).  Но это опять, особенности здания и большого количества народа. Во второй день с интернетом было уже гораздо лучше.

суббота, 31 октября 2009 г.

Запуск процесса на удалённом компьютере

Сегодня постараюсь быть кратким.

Итак, есть задача: запустить процесс на удалённом компьютере, RDC запускать не хочется, ибо тяжёлая артиллерия и не автоматизируется. Поиск стандартных утилит выявил только: sc — может многое, но только для сервисов, при этом tasklist и taskkill есть, а taskstart — нет.

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

wmic /node:remoteComputer process call create "calc.exe"

Всё просто, отдельными параметрами если нужно, то можно задать пользователя.

среда, 28 октября 2009 г.

Использование DefaultHttpHandler для отдачи файлов пользователю

Тут на конкурсе задали вопрос: чем отличаются Http Handlers и Http Modules. Ответов полно, дублировать их желания нет.  Всегда можно открыть MSDN и почитать про это.

Вкратце, Handler, это обработчик запроса, например, когда обращаемся на /default.aspx, в web.config ищется подходящий обработчик и ему запрос отдаётся на растерзание. Естественно, если вы поглядите в web.config для вашего приложения, вы там скорее всего такого не найдёте. Но если вспомнить иеархию конфигруационных файлов в .NET, то становится ясно, что нужно искать в базовом web.config файле. У меня он находится тут: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config.

Этот зверь в 30Кб, полностью описывает стандартные настройки приложения, которые можно заменить в своём. Там как раз и есть обработчик aspx-файлов:

<add path="*.aspx" verb="*" type="System.Web.UI.PageHandlerFactory" validate="true">

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

<add path="*.config" verb="*" type="System.Web.HttpForbiddenHandler" validate="true"/>
...
<add path="*.soap" verb="*" type="System.Runtime.Remoting.Channels.Http.HttpRemotingHandlerFactory, System.Runtime.Remoting, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" validate="false"/>

Например, эти говорят что *.config файлы нельзя показывать (например тот же web.config), а *.soap нужно для Remoting. Естественно, все эти правила можно заменить в своём приложении, да и при этом не забыть, что сам IIS по умолчанию не все расширения отдаёт ASP.NET, и надо добавить соответствующий фильтр в  настройках вашего приложения (ну или глобальный, на все файлы).

Про Http Handler's почему-то не получилось коротко, но это я случайно.   Дальше я расскажу более интересную вещь. А пока немножко про Http Modules.

Собственно, с ними всё просто, поскольку файл мы уже открыли и видим что за httpHandlers идут httpModules. Они-то  и будут будут вызваны HttpApplication во время обработки запроса, при этом они могут сделать что-нибудь полезное не прерывая и не перенаправляя запрос. Например, разобраться с сессией, авторизацией или логгированием. Да мало ли чем, всегда их можно подключить и отключить. Например мы хотим фатальные ошибки приложения сразу отправлять админу по ICQ. Сделали модуль, подключили к нужным приложениям. Всё работает, красота.  


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

Я часто встречал реализацию в виде /getfile.ashx?id=123 — где собственный хендлер как-то пытается отдать файлы. Идея хорошая, но не очень красивая, к тому же приходится рисовать собственный хендлер, отдающий файлы, что как-то неправильно.

Небольшое отсупление, по возможности старайтесь передавать имя файла в запросе, а не через Content-Disposition, иначе будут  проблемы с русскими именами файлов, да и периодические глюки, когда у клиента имя какое-то не такое. Для этого всего-лишь нужно делать запросы вида /getfile.ashx?id=123/requiredFileName немного подправить разбор входящих параметров, а дальше браузер сам придумает как обозвать файл.

Собственно моя идея состоит в том, что нужно использовать существующий DefaultHttpHandler, который и предназначен для отдачи статики, только для этого придётся выполнить пару простых условий:

  • Необходим .NET Framework 3.5 SP1, потому что в предыдущих реализация данного хендлера более примитивная.
  • Файлы должны быть физически доступны из приложения, т.е. пользователь должен иметь теоретическую возможность их скачать (правда имя может быть любое и лежать они могут как хотят. Для запрета прямой скачки, делаем соответствующие правила в web.config)

Теперь, собственно, осталось придумать по какому пути пользователи будут обращаться к файлам и навесить на этот путь свой простенький хендлер, отнаследованный от DefaultHttpHandler. Можете использовать различные url-rewriting решения, или написать своё. Если вам приходится вешаться на aspx файлы, то можете в фабрике возвращать следующий Handler:

PageParser.GetCompiledPageInstance(url, null, context)

Т.е. практически вручную запустить обработку страницы (с некоторым оговорками, но не о них сейчас речь).

Далее, в своём хендлере делаем следующее:

  • В методе BeginRequest  определяем "настоящий" путь к файлу по запросу. Например, запрос, /123/myfile.jpg меняем на /files/storedFile_123.dat
  • вызываем у контекста (вам его передадут) метод: context.RewritePath с полученным путём.
  • Дальше, чтобы не отдавать запрос IIS (а для оптимизации DefaultHttphandler попробует это сделать), что-нибудь пишем в Response, например context.Response.Write(' '). 
  • Вызываем базовый метод BeginRequest

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

  • Записывает в заголовки Content-Location с настоящим именем файла, т.е. хоть и не страшно, но мы светим то, как у нас хранятся файлы, т.е. неаккуратненько как-то
  • Если он не знает расширения файла, то в целях безопасности может его и не отдать (Свойства сервера, типы MIME — тут указаны расширения, которые IIS знает)

Ещё можно обрабатывать ошибки, писать логи и статистику, но это уже тонкости и детали, главное, что достаточно быстро (гораздо быстрее чем читать этот пост ).


Вышесказанное относится к IIS 6.0, в седьмом, возможно всё будет ещё проще, но я с ним мало работал, и в основном в классическом режиме, так что не буду ничего утверждать заранее.

вторник, 27 октября 2009 г.

Калькулятор размеров мониторов

Я как-то давно написал простенькую страничку, которая по введённой диагонали монитора и разрешению выдаёт его физический размер, dpi и соотношение сторон. Вещь на самом деле очень полезная и интересная, можно узнать, например, что:

  1. Монитор в 22" с разрешением 1920х1080 имеет по вертикали практически такой же размер как и обычная 17"-ка (1280х1024)
  2. Sony Vaio P имеет безумное разрешение в 1600x768, что даёт 222 dpi, что в 2.3 раза меньше стандартной точки (!!) Другими словами, в комплект должна идти лупа
  3. Ноутбуки в 15.4" обычно имеют разрешение 1280х800 что близко к классическим 96dpi (98 если точно)
  4. и многое другое

Надеюсь что данный скрипт поможет вам выбрать подходящий размер монитора, да и просто оценить размеры.

Пользуйтесь.

Изменение буквы системного диска в Windows

Раз уж сегодня начал активно писать в блог, то продолжу.  На этот раз не про конкурс, а небольшая заметка про то, как изменить букву диска в Windows, в случаях когда стандартными средствами (Управление Дисками) это не получается (нельзя, запрещено и так далее, в том же духе).

Стандартная ситуация, это когда при установке Windows не на основной диск система оказывается на диске D:, вместо диска C: и изменить это не получается, ибо диск системный и вообще загрузочный. Иногда подобное желание бывает и позднее (например системный диск X: а хочется сделать Y:).

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

Итак, всё просто. Открываем реестр, смотрим следующую ветку:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

Дальше находим ключ \DosDevices\X: — где X, это имя диска, которое нужно сменить. Ну и меняем на то, что нужно.  Потом перегружаемся и наслаждаемся жизнью или ловим проблемы с тем, что ничего не работает.

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

  1. Загрузиться из другой системы. Если её нет под рукой, замечательно подходит установочный диск от Висты или свежее. Вместо установки выбираем Recovery и открываем командную строку. Если у вас есть Far, то можете ж
    80;ть припеваючи на данном шаге.  Если нет, то работайте в консоли.
  2. Копируем все файлы (чтобы проще было) из Windows\System32\Config в любую другую подходящую папку. Там хранится реестр и журнал событий.
  3. Для надёжности копируем Documents And Settings\ntuser.dat — реестр для конкретного пользователя (в Висте и Семерке путь немного другой: Users)

Собственно, на этом всё. Для восстановления нужно проделать те же действия, только скопировать обратно. В частности, этот способ часто помогает, если нужно переустановить Windows на такой же, по причине фатального сбоя. Это поможет восстановить реестр и может быть даже всё заработает. Но очень опасный способ (с другой стороны уже всё сломано, можно и попробовать починить).

GAC

Не выдержал и решил написать ответ на вопрос про GAC для конкурса Гайдара про платформу.

Переписывать MSDN и Рихтера не буду, для разнообразия скажу своё мнение про GAC, чтобы ответ отличался от остальных.   Собственно расскажу, не про то, чем хорош GAC, а чем он плох.

Для начала в двух словах про него — это глобальный кеш сборок, и любое приложение, которое использует опредёленную сборку сначала посмотрит на её наличие в GACе, а только потом будет искать в других местах. Т.е. можно считать GAC банальным хранилищем DLLек, как Windows\System32, но с одним важным отличием. Сборки хранятся не по имении библиотеки, а по имени, Strong Name ключу, версии, культуре и платформе (x86, x64). Т.е. можно хранить разные версии сборок и даже умудряться их использовать в одном приложении (хотя лучше постараться не делать так). Т.е. GAC полезная функциональность, но есть несколько НО.

Самое главное, теряется возможность xcopy deployment, необходимо использовать gacutil или делать приличный Installer. Но если подумать, то что нужно класть в GAC? Нужно туда размещать библиотеку, которую будут использовать несколько приложений на компьютере, иначе особого смысла в этом нет. Другими словами, это должен быть конкретный shared-компонент. А кому нужен shared-компонент? Только разработчикам. Для обычных пользователей это в большинстве случаев не нужно. А разработчики очень не любят сложные процессы установки библиотек. Им бы в проект скопировать что надо, и не думать потом о библиотеках. В противном случае получается, что у разработчика может всё работать, ибо сторонняя сборка в GACe, а у клиента уже всё будет падать, ибо разработчик забыл её приложить к приложению.

Например, мой epic fail был с библиотекой Microsoft.mshtml.dll, которая оказалось что ставится со студией, и напрямую в приложении не используется, а используется через третьи библиотеки. В результате, у меня приложение работало на всех компьютерах, а половина клиентов ругалась. Конечно, я уже умный, и подобных вещей стараюсь не допускать, но вот пример как легко можно сломать приложение использованием GACа.

Собственно, если мы планируем использовать сборку в GACе, то у нас сразу усложняется разработка. Необходимо писать скрипты для билда, которые будут выковыривать сборку из GAC, компилировать новую версию и вставлять обратно. Вроде не сложно, но программисты ленивые, и обязательно что-нибудь схалтурят, и при деплое получим проблемы.  Ещё нужно обязательно использовать Strong Name, что на этапе разработки иногда плохо, ибо придётся раздавать ключ всем разработчикам (проблема в секурности), также сразу включается версионирование, которое менять нужно вручную. Иначе получатся две абсолютно разных сборки с версией 1.0.0.0, одна из которых в GAC, а вторая нужна приложению, и это вызовет замечательные проблемы, которые будет очень весело отлаживать.


Собственно, что я хотел сказать:

  • Использовать GAC нужно, когда есть проблемы с версионированием. Это позволит их решить. Например, приложение А использует библиотеки B и С. B использует библиотеку D версии 1.0.0.0, а C использует D версии 1.2.0.0. Как это это необходимо решать. Тут нужен GAC, ибо два файла с одним именем к приложению подцеплять плохо.
  • Использовать GAC нужно, когда есть много приложений, использующих одну сборку. Как вариант — хостинг многих приложений с общим компонентом. И то, может быть проще не использовать GAC, ибо места на диске не так уж и много сэкономится, а если случайно выкинут сборку из GAC, то можно получить проблемы.
  • Хороший пример того, что нужно класть в GAC — системные библиотеки .NET Framework
  • Во всех остальных случаях — не стоит. (Моё личное мнение).