MCP

суббота, 31 декабря 2011 г.

Итоги 2011-ого года

Все подводят итоги года, ну и я решил не отставать и тоже что-нибудь подвести.  Но поскольку мои достижения никому не интересны, больше буду смотреть на ИТ-изменения, произошедшие в этом году, и коснувшиеся меня непосредственно.

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

Всего лишь пару лет назад заплатить за домен в зоне .ru с помощью пластиковой карточки было практически невозможно. Необходимо было использовать всякие недоденьги в виде Яндекс.Денег или Вебманей, при этом их получение (обмен реальных денег на эти фантики) был весьма затруднён. Сегодня же в интернете можно купить практически всё что угодно, и если я уже давно закупаюсь за границей, то в этом году стало вполне реально покупать в России и забирать товары не через почту а в пункте выдачи (или с доставкой на дом). Например, в этом году я купил совершенно не IT-товар — автомобильный аккумулятор через интернет, заполнив простенькую формочку и ответив на звонок.

Государственные службы тоже с большим скрипом но понемногу внедряют сервисы. Можно заплатить налоги, или записаться в ГИБДД без всяких звонков и походов ногами. Надеюсь, в будущем году движение продолжится и очень хотелось бы, чтобы оно было гораздо быстрее.

Радует, что множество компаний активно общается в твиттере, и не просто общается, а помогает решить вопросы (отдельные благодарности Мегафону и Связному Банку). Теперь даже думаешь, стоит ли связываться с компанией у которой нет контакта в Твиттере, и не стоит ли вместо неё выбрать другую.

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

В общем, не буду дальше растекаться мысью по древу, ибо пиво стынет, а салаты греются. Поздравляю всех с наступающим 0x7DC годом, и пусть в следующем году у вас будет всё замечательно, а все возникающие проблемы можно будет решить всего-лишь нажав нужную кнопочку в браузере, не вставая с места.

PS: А я всё-таки постараюсь не забрасывать этот блог и писать чуть-чуть чаще, сюда, или на хабр или ещё куда-нибудь, хотя писать каждый день как Пётр Диденко не обещаю.

воскресенье, 6 ноября 2011 г.

SVN vs DVCS

Последнее время, появилось множество фанатов, орущих про то, что SVN — сраное говно, а Git/Mercurial — активно рулят. При этом, несмотря на плюсы распределённых систем, у них ещё дофига минусов, которые решаются или костылями, или инструкциями по работе, или надеванием штанов через голову, потому что "это модно".

Покопавшись в интернете, я не нашёл особых статей со сравнением DVCS (распределённых системы управления версиями) и SVN (хотя не сильно-то и искал), так что решил написать свою, чтобы Трухин Юрий посмеялся. 
Собственно, буду сравнивать концепцию DVCS (без сильных завязок на Git или Mercurial) и SVN, как одного из самых ярких представителей централизованных систем (TFS тоже яркий, но это комбайн с кучей бантиков и практически только под Visual Studio)

Всё нижеперечисленное, моё личное мнение, которое может не совпадать с мнением фанатов какой-либо системы, да и вообще быть ошибочным.

Начнём с плюсов DVCS:
  • У каждого своя пользователя копия репозитория в которой он может делать всё что угодно, до заливки в основной репозиторий
  • Удобные бранчи и теги 
  • Более приличный мёрж (за счёт ченджсетов)
  • Отличная автономность
  • Возможность устраивать сложную систему иерархий в организации проекта
А теперь, про недостатки, про то, что не пишут или что обходится административными мерами:
  • Один репозиторий — один проект. Т.е. распределённые системы удобны для работы над одним проектом, и очень плохо разделять зону ответственности между связанными проектами. Технически, два независимых проекта, это два полностью независимых проекта, с разными репозиториями и отсутствием общей инфраструктуры
  • Подключение к проекту внешних модулей (например, общей между разными проектами, библиотеки). В svn это весьма коряво решается через svn:externals, и в git и в mercurial есть ещё более корявые решения, но в принципе решить задачу можно, хоть и очень коряво.
  • Проблема с хранением больших бинарных файлов (особенно, если они ещё и изменяются периодически). Т.к. у каждого разработчика по копии своего репозитория, то у каждого по копии всех этих файлов (и всей истории), даже если они ему и не нужны. Решение — использовать всяческие расширения или выносить эти файлы из DVCS в другие системы (например, тот же SVN).
  • Невозможность забрать всего-лишь несколько файлов из проекта. Например, менеджерам абсолютно не нужен код, им нужно только ТЗ, макеты и прочая мелочёвка. При этом, уровень грамотности у них в плане работы с VCS значительно ниже. В общем, как результат, проще документацию хранить отдельно, чем обучать менеджеров работе с DVCS.
  • Отсутствие единой сквозной нумерации. Прощай автоверсионирование в билдах и удобная привязка к багтрекеру. Проблема некритичная, но очень "радует" своим удобством.
  • Отсутствие возможности тонкого разграничения прав, например, запретить писать некоторым пользователям в важные конфигурационные файлы, или же заблокировать от изменений часть проекта.
  • Отсутствие возможности блокировки файлов. Фича редкая, но когда нужна, тогда без неё плохо. Можно обойти административными мерами, но их любят нарушать.
  • Практически всегда необходимо выделять центральный репозиторий (хотя бы для автомтатических билдов), как результат, он выполняет роль сервера SVN, т.е. в принципе, всё сводится назад, к централизованной системе с более умными клиентами у разработчиков.
  • Хуки на определённые группы файлов, и вообще слежение за изменениями. Необходимо прилагать дополнительные усилия для слежки, то, что в SVN делается из коробки.
  • Потеря исходников автоматически означает потерю всего репозитория, т.е. включает в себя всю историю, уже удалённые файлы, даты, список пользователей, ветвления. Т.е. ценность данной информации гораздо выше, стоимость потери — тоже. А с учётом пункта об проблемах с разграничением прав, всё становится совсем плохо. А потерять один ноутбук разработчика гораздо проще чем данные с одного сервера, охраняемого злобным цербером администратором. 
И как закономерный результат: отлично DVCS применимы для распределённой разработки (как и следует из их названия) и слабо применимы для локальной группы разработчиков, когда все преимущества распределённости теряются, а недостатки никуда не деваются.

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

В-общем, мое мнение: DVCS нужно засунуть туда, куда они пришли, в распредённость, и не иметь проблем с ними, если не видно явного преимущества в данный момент. Ведь из SVN всегда можно сделать экспорт в другую систему, когда это понадобится. А вот обратно — уже никак, и от проблем DVCS уже никуда не получится деться.

воскресенье, 18 сентября 2011 г.

Определяем бездействие пользователя в Windows

Сегодня я распишу несколько WinAPI функций для определения того, что пользователя сейчас нет на месте и можно принять соответствующие меры. Какие меры можно принять?

  • Если нужен ответ от пользователя на не очень важный вопрос, можно принять решение самостоятельно или же продолжить заниматься другими вещами, отложив вопрос до появления
  • Если идут вычисления, можно поднять приоритет операции
  • Если идёт демонстрация некой информации, её можно остановить, чтобы зря не переводить ресурсы
  • Если есть подобие мессенжера, можно изменить статус
Итак, как это можо сделать:

GetLastInputInfo

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

SPI_GETSCREENSAVERRUNNING

Это параметр функции SystemParametersInfo, по названию понятно, что можно определить, запущен ли в данный момент скринсейвер. Если запущен, то очевидно, что пользователь не увидит нашу программу, и можно принимать решения самостоятельно

SC_MONITORPOWER

Это глобальное сообщение, рассылаемое системной или приложением, через WM_SYSCOMMAND, сигнализирующее о том, что монитор включен/спит/выключен. Можно считать более продвинутым вариантом скринсейвера (ну и вручную отключать монитор, но это не тема этого поста).

WTS_SESSION_LOCK/WTS_SESSION_UNLOCK

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

четверг, 23 июня 2011 г.

Мифы о многозадачности и прожорливости Android до памяти

Данный пост написан по мотивам подкаста Юрия Трухина и Эльдара Муртазина, где они не очень корректно высказались про то, как устроена многозадачность в андроиде, и зачем ему таскменеджеры. Многозадачность в Андроиде такая же, как в готовящемся Mango для WP7, с точностью до деталей реализации и названий в архитектурных решениях.

Некорректное понимание многозадачности в андроиде я встречаю достаточно часто, и думаю, что это вина Google, что они не могут нормально объяснить обычному пользователю, как всё внутри устроено, и что Task Manager'ы в большинстве своём вредны, нежелели полезны.

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

Отчасти это в чём-то правда, но тут есть весьма тонкий момент. Дело в том, что все программы для андроида модульные. Т.е. программа состоит из множества кусочков, которые работают независимо друг от друга (если явно не вызывают другой модуль). Т.е. наличие в памяти программы совершенно не показывает то, что она вся используется в данный момент. Она может вообще не исполнять никакого кода, а в памяти висеть просто потому, что память есть и почему бы не держать приложение в кеше, чтобы последующая активация произошла быстрее. Естественно, когда память будет нужна другим приложениям, самое ненужное (есть система приоритетов) будет выгружено. Т.е. это тоже самое что и концепция захоронения в WP7. Т.е. в данном случае таскменеджеры просто вредны, так как они выгружают приложения, которые потом будут загружаться снова, тратя ресурсы и время.
Само по себе, наличие приложения в памяти не тормозит телефон, освобождать память ради большой цифры free mem — бесполезное занятие, от этого ничего не изменится.

Но всё же, определённая толика правды тут есть, и сейчас расскажу почему.


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

В андроиде все модули в программе делятся на три основных типа:

  • Activity
  • Broadcast Receivers
  • Services

Рассмотрю их подробнее на виртуальном примере музыкального плеера.

Activity

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

Broadcast Receivers

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

Это части программ, отвечающие за приём глобальных сообщений. Их весьма много стандартных, плюс, можно ожидать абсолютно любое сообщение, сказав про это системе  (это бывает полезно для связи между различными программами). Сообщения бывают самые разные, например, сообщение о том, что появилась WiFi-сеть и можно бежать в интернет за новыми песнями, вставили телефон в док-станцию — рисуем красивое окошко с часиками. Нажали кнопку паузы на гарнитуре — остановим воспроизведение. Собственно таким образом можно отправить картинку в твиттер из галереи: твиттер регистрируется на событие вида "могу шарить картинки", галерея посылает событие всем подобным приложениям и пользователь выбирает, что он хочет сделать с картинкой. Благодаря этому и обеспечивается гибкость андроида в установке различных приложений.

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

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

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

Сервисы

Вот мы и подошли к самому главному потребителю ресурсов. Сервисы, эта часть программы, которая должна работать в фоне, и она предназначена ровно для этого и не для чего больше. Это вот те самые маленькие блоки, которые работают при многозадности и в Android, и в iOS, и в WP7 Mango.
Это сервисы синхронизации, обновления, загрузки. Для музыкального плеера играть музыку должен именно сервис! Даже во время звонка, часть программы, отвечающая за разговор — это сервис, который нужен, чтобы разговор шёл, а пользователь мог играть в Angry Birds в это время.
Собственно это и есть основные потребители ресурсов, но таскменеджеры их очень плохо определяют, лучше на них смотреть в стандартных настройках приложений (Running Services).
Но Android может убивать сервисы при нехватке памяти тоже, хоть они и имеют приоритет по времени жизни, что удивительно, он потом их постарается запустить заново, чтобы вернуть всё как было. Самый высокий приоритет у сервисов с иконкой в статусбаре, как это глупо не звучит. Просто эти сервисы своим видом демонстрируют пользователю, что они существуют и работают, и Android их бережёт до последнего. Именно поэтому большинство музыкальных плееров рисуют иконку в статус баре, такой вот архитектурный финт ушами.

Небольшая ремарка про аналог сервисов в Windows Phone 7 (в грядущем релизе Mango), там подобный функционал называется "Background Agents" (т.е. агенты, работающие в фоне)

  • Агенты более специализированные и реализуются под конкретную задачу (т.е. специальный агент по проигрыванию музыки, специальный агент для скачивания файлов)
  • Есть агенты для своих задач, но WP7 ограничивает их 10% CPU и 5Mb памяти, т.е. они не могут сильно повлиять на производительность телефона
  • У агентов есть ограничение на функционал, например, они не могут использовать камеру и сенсоры. Т.е. нельзя будет сделать видеорегистратор и шагомер (GPS-можно).
  • Агенты выводятся в отдельный хост-процесс, но это детали внутренней организации системы
  • Принципиально отсутствует Task Manager, как результат пользователь не может насильно оставить работу агента
В общем, если в WP7 вдаваться в детали, то там реализация выглядит отличающейся, но если смотреть глазами пользователя, то задача будет решаться одна и та же: небольшая часть приложения, которая делает конкретную часть работы.

Заключение

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

среда, 1 июня 2011 г.

Излечивание от глюков ATI/AMD Catalyst Control Center

Если лень читать целиком, решение в конце поста. 

У владельцев видеокарт от ATI/AMD периодически (судя по гуглу) возникают проблемы с запуском Catalyst Control Center. Выражается это в эпичненьком сообщении при запуске CCC (которое ещё и при старте винды лезет):
The Catalyst Control Center is not supported by the driver version of your enabled graphics adapter. Please update your ATI graphics driver, or enable your ATI adapter using the Displays Manager.
Как говорится: Внушаетъ!
Особенно часто это происходит на Windows Server от 2003 до 2008 R2, при этом AMD до сих пор не смогла это починить по-человечески.

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

Для начала о истоках проблемы (на случай, если в лоб решение не поможет, или для использования его в других случаях, например с nvidia):
После установки драйверов, ATI/AMD скидывает видеокарту в слишком низкий уровень аппаратного ускорения, что приводит к тому, что сами же утилиты от AMD не понимают что у них видеокарта от AMD (Windows бодро рапортует, что это замечательный VGA-адаптер, который ничего не умеет). Под Windows Server это бывает постоянно (типа безопасность, сервер, все дела).
В 2003-ем сервере это решалось элементарно: Свойства экрана, устранение неполадок, слайдер ускорения вправо до упора и все счастливы. Проблема решена. В 2008 (R2), данный пункт меню эпичненько задизаблен с комментарием "драйвер запретил менять". Т.е. получается патовая ситуация: драйвер сбросил ускорение, не даёт его менять и от этого перестаёт работать. Просто счастье, какое-то.


Собственно хватит лить воду, само решение: 

  1. Открываем в реестре следующий ключ: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video
  2. Среди гуидов находим нужную видеокарту (раскрываем, смотрим на описания ключей, пропускаем всякие эмуляторы RDP, VGA, VNC, записывателей видео и т.д.). Возможно, что для AMD будет гуид (хотя не уверен в их определённости): {DA28D4B2-FAF5-45C5-A111-36F83DD8634A}
  3. Находим значение Acceleration.Level и ставим в 0, если там не ноль (0 — полное, 5 — отключено совсем).
  4. Перегружаемся (или пинаем ногами CCC) и наблюдаем на нормальные, человеческие настройи и отсутсвие идиотских ошибок.
Если подитожить всё вышесказанное, то решение такое:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Video\[гуид видеокарты от AMD]\0000\Acceleration.Level ставим 0

воскресенье, 17 апреля 2011 г.

Смена админского пароля без доступа к компьютеру

Если злоумышленник имеет физический
 доступ к вашему компьютеру,
 то это больше не ваш компьютер

Сегодня я расскажу, как с помощью двух зубочисток, зажигалки и туалетной бумаги сломать компьютер... Хотя нет, что-то не туда ушёл. Расскажу об одной простой вещи, когда потерян админский пароль, а доступ к компьютеру нужен. Естественно, как и обычно, из средств я буду использовать только загрузочный диск с семёркой и стандартные средства.

Вообще, данный способ в теории для меня был достаточно ясен, но случилась ситуация, когда старый компьютер сотрудника выпал из домена (привет, Microsoft!), а самого сотрудника уже не было на работе, и невозможно было даже войти по кешированным данным. Был выбран самый простой способ для взлома.

Итак, что нам нужно сделать:

  • Смотрим, работает ли на целевом компьютере режим залипания клавиш по пятикратному нажатию шифта (если нет, придётся испробовать другие варианты, о них позднее, концепция будет та же)
  • Загружаемся с установочного диска, нажимаем shift+F10, получаем консоль. Находим нужный диск и переименовываем cmd.exe в sethc.exe (точнее делаем бекап sethc.exe, и копируем cmd.exe в sethc.exe). Примерный синтаксис:
  • c: //методом тыка и dir находим нужный диск cd windows\system32 ren sethc.exe sethc.exe.bak copy cmd.exe sethc.exe
  • Перегружаемся по-обычному 
  • Нажимаем пять раз shift и у нас есть консоль от SYSTEM (такой, злобный админ)
  • Меняем пароль админу (будем считать что его зовут Administrator):
  • net user Administrator new_password
    Это всё сломает шифрованные файлы для данного пользователя и его приватные ключи, так что аккуратнее с этим, если есть ценные данные. Возможно лучше будет создать нового пользователя и включить его в группу Администраторы.
  • Заходим под этим пользователем в систему и делаем, что нам надо
  • Восстанавливаем sethc.exe на место
Можем ещё повеселиться и запустить explorer от пользователя System, это ещё смешно работает по RDP, в общем получается отличный удобный хоткей для запуска консоли.

Что можно сделать, если "липкие клавиши" отключены?
  • Можно посмотреть, запускается ли от бездействия скринсейвер и подменить его
  • Можно подменить ненужную службу (только придётся сделать подготовления, ибо на обычный cmd, её не заменить)
  • Можно открыть реестр и прописать в автозагрузку нужные вещи
В общем, защищаться от такого сложно (если только ограничить доступ к внешним устройствам: выломать USB, CDROM, LPT, FDD и закрыть корпус на замок), главное, не подпускать злодеев к компьютеру, тогда всё будет хорошо, и вам тоже всё будет замечательно.

суббота, 12 марта 2011 г.

Оживление системы после миграции. Мучения с AHCI

Некоторое время назад я рассказывал об одной интересной возможности миграции с использованием стандартных инструментов Windows и отдельного компьютера/жёсткого диска в качестве хранилища.

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

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

Итак, проблема в том, что из-за каких-то абстрактных побуждений об оптимизации (доли секунды при загрузке) Windows 7 отключает неиспользуемые устройства при загрузке, и не включает.  Поэтому включать нужно вручную. Запустить реестр и переключить тип запуска. Данный способ отлично помогает, если мы можем загрузиться в IDE-режиме. Тогда мы сможем включить драйвера, включить AHCI и компьютер загрузится в продвинутом режиме. Но если мы не можем это сделать, или компьютер не загружается ни в каком из режимов?
Тогда берём загрузочный диск с семёркой или мегафлешку, загружаемся, открываем консоль, и запускаем regedit. В нём выбираем:
  • HKEY_LOCAL_MACHINE
  • File/Load Hive...
  • Находим реестр от нашей системы (диск наверняка будет не C:, так что находим нужный (пусть будет T:), и загружаем файл system, т.е. полный путь будет вида T:\Windows\System32\config\system
  • Выбираем любое имя для него, что-нибудь вида tmp
  • У нас появился данный раздел tmp в HKEY_LOCAL_MACHINE
  • Следуем инструкции от Microsoft и меняем значение Start на 0 в следующих ветках:
    • HKEY_LOCAL_MACHINE\tmp\ControlSet001\Services\Msahci
    • HKEY_LOCAL_MACHINE\tmp\ControlSet001\Services\IastorV
  • Имеем ввиду, что нам нужно сменить значение у активной конфигурации, поэтому может быть не ControlSet001, а ControlSet002 или 3, или 4... В общем, если сомневаетесь, меняйте везде
  • Если проблемы возникают и в IDE-режиме, то можете ещё включить pciide (по тем же путям)
  • Если у вас чипсет от nvidia, то включаем nvstor или nvraid
После этого перегружаетесь и радуетесь загруженной системе. Должно всё получиться.  Если не получилось, то проблема не в жёстком диске, а в чём-нибудь другом или же вы что-то забыли или не там изменили. Пытайтесь выяснить в чём проблема, пытайтесь включить дополнительные устройства. Естественно, если текущий компьютер имеет экзотический конфиг, для которого не подходят стандартные драйвера, то тут всё гораздо хуже, и выполнимо только при затрате большого количества усилий, нужны ли они вам, решайте сами.

Данный способ уже неоднократно выручал меня, и я сожалею, что не знал о нём раньше. Ну и лучши ненависти в Microsoft, где сделали такую "оптимизацю", которая может попортить кучу нервов.

среда, 23 февраля 2011 г.

Впечатления от Microsoft QA Days

Данный пост был написан вчера в поезде, по дороге с QA days, из изменений только проставленные ссылки и форматирование.


Сегодня я посетил мероприятие, проводимое Careerlab и Microsoft под названием Microsoft Quality Assurance Days, проходившее в офисе Microsoft в Крылатском.

Место проведения, конечно, выбрано "шикарное". Построить бизнес-центр в жопе мира далеко от центра и метро, а чтобы было не совсем плохо — пустить бесплатные маршрутки — это весьма сильно. Добираться от вокзала до места проведения час с лишним (хотя для москвичей, наверное это нормально, но для меня это жуть). Я как-то не привык к таким дальним странствиям, поэтому не расчитал, взяв обратный билет так, что остался без фуршета, да ещё чуть не опоздал на поезд. Добирался до своего вагона уже через весь поезд, ибо успел добежать только до первого вагона. Зато поучавствовал в записи подкаста ПолДевятого (если его удастся восстановить после фейла с программой ). Запись прошла отлично, даже сумел вставить пару "веских" слов, надеюсь, что не очень глупых.

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

Ладно, заканчиваю лирику и перехожу к самому мероприятию. Началось всё с приглашённого евангелиста Брайана Келлера. Он рассказал как всё круто с TFS и Visual Studio, какие удобные все инструменты для тестирования. И я ему верю! Правда, чтобы ощутить всё это великолепие в полном объёме, нужно несколько мега-админов, чтобы настроить TFS, Hyper-V, и всю остальную инфраструктуру. Также нужна достаточно мощная техника, но результат будет просто  замечательный. Куча информации, автоматическое и полуавтоматическое тестирование, возможность сохранения состояния, запись всех шагов — в общем сказка. Лишь бы всё это работало не только в презентациях.
Далее, Брайан рассказал про исследовательское и формальное тестирование, когда задача тестера состоит в том, чтобы оценить систему с точки зрения определённого типа пользователя и попробовать всё оригинально сломать. Впрочем, с моей точки зрения, для этого очень хорошо  подходят программисты, которых сорвали с другого проекта и дали потестировать чужой код. Тут уж вредность проявляется в полном объёме, ибо эти гады (программеры), имеют очень хорошее представление, куда ткнуть, чтобы всё сломать.  Правда не надо их этим часто загружать, иначе они расстроятся, и будут всё делать как неважный тестер, особо не думая и не разбираясь в системе.

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

Следующий доклад был ужасен и абсолютно ни про что, пропустим его

Последним был мастер-класс от Дмитрия Андреева где он рассказал про средства для отладки и улучшения качества кода, существующие в студии. К сожалению, он плохо знает решарпер, что привело к тому, что Дмитрий не осветил целый пласт возможностей по улучшению кода, без использования сторонних утилит. Ну и некоторые моменты, вроде политики редких могучих чекинов мне показались странными. Зато рассказал про интересные вещи как Pex и Moles, позволяющие упростить написание юнит-тестов (Pex — генерилка юнит-тестов, Moles — фреймворк для подмены методов, любых, включая системные, чтобы делать заглушки без изменения основного кода).

Далее, у меня было обсуждение новинок в мире Windows Phone 7 и запись подкаста, о котором я упоминал в начале, а основная масса участников зависла на сессии вопросов и ответов, даже не спешила к фуршету

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

воскресенье, 6 февраля 2011 г.

OpenXML и цифровая подпись

Тут некоторое время помучался пытаясь подписать OpenXML, хочу поделиться тем, что у меня вышло с этим неприятным форматом.

Начну издалека сбоку, про то, что явно подразумевается во всех статьях но словами леняться проговорить. Итак, OpenXML это документы формата Open Packaging. Это такой стандартизованный zip-файл, в котором в основном должны храниться XML'ки, но можно и любую другую фигню. Поэтому этот формат в принципе можно использовать для передачи апдейтов вашей программы, или хранения набора патчей, в общем для любых целей хранения стандартизованного пакаджа, который удобно читать и разбирать. Собственно, в .NET за это отвечает класс Package, он всё и умеет.

Разобравшись с общим форматом, переходим к частностям: в этом OPC формате хранятся: .docx, .xlsx, .xps и много других вещей. Соответственно работать в коде с документами вы можете абстрактно, как с пакадаждем содержащим набор частей, или взять специализированного наследника (скачав, например, OpenXML SDK, ну или использовав XpsDocument) и работать уже более детально.

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

  • В 2007-ом офисе по умолчанию подпись будет показываться ошибочной, нужно шаманить с параметрами
  • В 2010-ом подпись по умолчанию будет показываться partial, т.е. офис будет считать что вы подписали лишь некоторые части, а не весь документ, и нервничать (кстати, вы можете подписать только стили, позволив беспрепятственно изменять текст (не через Word), и таким образом подделывать документы, если пользователь не будет настаивать на том что подпись partial).
  • В .NET реализации явно подразумевается (в смысле кодом), что сертификат для цифровой подписи может быть только RSA, да ещё будут проблемы с токенами, ибо вместо использования стандартной инфраструктуры PKI для подписи (что делает, например, сам Word), тут пытаются взять насильно приватный ключ (это плохо! а местами запрещено), кастуют его к RSA (сразу выкидываем все другие алгоритмы, например наш ГОСТ) и подписывют.
В общем, хоть на бумаге всё и гладко — 15 строчек кода, на практике эо всё превращается в весьма опасную неюзабельную штуку, которая непонятно когда и где может выстрелить, поломав всё и вся. А всё из-за криворукости индусов, которые изначально не могли всё сделать грамотно, в результате теперь сделать грамотно невозможно никому.

понедельник, 3 января 2011 г.

Миграция системы с одного компьютера на другой

Хочу рассказать про способ смигрировать операционную систему с одного компьютера на другой, с сохранением всех данных. По факту, это копирование данных с одного винчестера на другой, с использованием стандартных средств. Способ подходит для Windows 7 (возможно для Vista).
Его плюсы:

  • При некоторых условиях — малое время простоя компьютера
  • Возможно использовать на опечатанных компьютерах, когда просто нельзя заменить винчестер
  • Возможность восстановить данные на определённую дату (при соответствующих условиях)
  • Возможно мигрировать по сети
Ну и соответственно минусы:
  • Нужен отдельный внешний винчестер или отдельный компьютер, доступный по сети с достаточным объёмом свободного места на его винчестере
  • Новый компьютер должен иметь по крайней мере такой же винчестер как и на старом (или больше
Ну а теперь, собственно, сам метод. В двух словах он заключается в том, что необходимо проделать стандартную архивацию данных Windows на внешний винчестер или внешнюю сетевую папку и восстановление этих данных на новом компьютере. Дальше буду рассматривать самый интересный вариант, с бэкапом по сети (удобно для организаций, где все компьютеры подключены в сеть, и достаточно физического места).
  1. Запускаем архивацию Windows
  2. Выбираем какую-нибудь сетевую папку, куда будем складывать образ (создаём её на подходящем компьютере)
  3. Убираем все галочки с файлов, но ставим галочку "сделать образ восстановления системы"
  4. Свободного места во внешней папке должно быть по количеству даннных на диске (будет создан виртуальный диск (vhd-файл) с виртуальным размером всего винчестра, а физическим — по размеру реальных данных)
  5. Запускаем, ждём пока завершится, в это время продолжаем работать
  6. Берём свежий компьютер, загружаемся с диска или чудо-флешки
  7. Вместо установки выбираем восстановление системы
  8. Говорим, что хотим восстановиться с образа, и после тщетных попыток его найти, говорим что он расположен в сети. После этого система поднимет сетевой интерфейс (сама, в установочном режиме, она и такое умеет!)
  9. Если настройки сети не раздаются через DHCP то нажимаем Shift+F10, и в консоли набираем:
    netsh interface ip set address name="Local Area Connection" static 192.168.0.100 255.255.255.0 192.168.0.1 1
    Естественно, нужно заменить IP-шники на правильные для вашей сети (тут по порядку — IP-компьютера, маска сети, IP-шлюза). Для русской версии название будет "Подключение по локальной сети", уточнить можно через команду ipconfig
  10. Указываем сетевое размещение папки (если не получится по имени компьютера, можно использовать его IP)
  11. Указываем, если требуется логин с паролем
  12. Выбираем нужный образ (если их несколько) и восстанавливаем
  13. Ждём, перегружаемся и получаем копию старого компьютера на новом
  14. Выключаем старый компьютер, меняем его на новый, продолжаем работать (естественно, все изменения, которые произошли после архивации — потеряются, если они нужны, примите меры для их отдельной архивации)
Вот и всё. Можно работать на старом компьютере, пока не подготовится новый, при желании, компьютер даже можно загрузить с vhd-файла или просто подключить его как отдельный диск, если нужен просто полный архив, но не нужно восстановление). Можно настроить на всех компьютерах архивацию по графику и в случае физической смерти одного из компьютера, восстановить всё на другом.
Какие могт быть проблемы, и что с этим можно сделать:
  • Система отказывается восстанавливаться — убеждаемся что заархивирован винчестер целиком, новый винчестер имеет размер по крайней мере такой же как и старый
  • После восстановления есть неиспользуемое место на винчестере — заходим в управление компьютером и растягиваем разделы на всё доступное место (в упрощённом виде семёрка это позволяет). Можем просто создать дополнительный раздел или воспользоваться специализированными программами для тасования разделов.
  • После восстановления, компьютер улетает в BSOD. Самый тяжёлый случай, обычно связан с тем, что драйвера на старом и новом комьютере сильно отличаются (обычно проблема с контроллером жёстких дисков). Тут можно потанцевать с бубном, попробовать на исходном компьютере удалить все драйвера (оставить стандартные), переключить режим SATA-контроллера в IDE-режим, и только после этого сделать образ.
  • При попытке сделать архив по сети, он падает с ошибкой. — попробуйте сделать архивацию на другой компьютер, попробуйте заменить драйвера сетевой карты, ибо архивируется большой объём данных и могут выплыть проблемы в драйверах (бывали случаи, когда сетевые карты достаточно именитых производителей из-за ошибок в драйверах сжирали всю оперативную память и рушили сервер по недостатку ресурсов).
В общем, на этом всё, способ достаточно прост, я постарался расписать его подробно, уточнить проблемы и подводные камни. Надеюсь, что описание окажется полезным, и вы попробуете стандартные средства для архивации и соответствующей миграции, вместо использования сторонних.