Ох уж эти заветные 256 килобит! Какими недостижимыми они казались, когда мы кое-как подключались к провайдеру через старую аналоговую АТС, и кое-как соединялись на скорости 14400 или, если повезет, 18600. Пара килобайт в секунду прокачивается – и уже отлично! При этом у самого «крутого» саратовского провайдера ширина канала на Москву равнялась мегабиту. У остальных – поменьше. У кого в два раза, а у кого и в четыре.

Но вот быстрый Интернет действительно стал обыденностью. Его отсутствие вызывает раздражение – словно отключили горячую воду или забыли подать ток в розетку. Даже в дальнем зарубежье войти в Сеть не составляет никакого труда. Не в гостинице, так в кафе. Не в кафе, так через местную сим-карту. Ну и просто можно встать около жилого дома и посканировать эфир: почти наверняка найдется ретроград, не желающий настраивать шифрование WiFi у своего роутера.

Что до устройств, способных выходить в Сеть, то с ними у нас все просто замечательно. Смартфон, планшет, ноутбук – это уж наверняка. Иногда им на помощь приходят еще умные плееры и портативные игровые консоли. Пара кликов – и вот они, любимые почта, мессенджер, Facebook да Twitter. Все знакомые здесь, словно ты и не уезжал никуда (кстати, это «словно никуда не уезжал» работает и в другую сторону. Недавно прикинули с другом, давно живущим в Китае, сколько же мы с ним не виделись. Оказалось – не меньше пяти лет. При этом ощущения разлуки нет никакого, потому что мы почти каждый день общаемся по ICQ и почте). Помню, поначалу меня это ощущение очень радовало – надо же, чувствуешь себя дома по всему миру. Но вот в последние годы меня это ощущение стало почему-то раздражать…

Нет, дело не в острой форме мизантропии. Просто вместе с «чувством дома» Интернет приносит чувство долга. Ведь мой ноутбук (простите, UltraBook ™) представляет собой абсолютно полноценное рабочее место. Я могу на нем отвечать на письма, писать статьи, обрабатывать фотографии… А раз могу – то и делаю. Помнится, раньше, побыв свидетелем какого-то IT-события, я шел заниматься своими делами, и уже по возвращению домой писал статью. Теперь же я пишу ее ночью, чтобы как можно скорее опубликовать на сайте. Отдельное «спасибо» цифровой фотографии: снимки готовы для обработки сразу, без необходимости вмешательства фотолаборатории. И нашему брату-трудоголику никак нельзя лечь спать, пока лучшие двадцать-тридцать кадров не попадут в заботливые руки коллег…

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

Все мы сейчас напоминаем эдаких гребцов, прикованных к галерам. Разве что галеры у нас довольно изящные, и обычно мы их подбираем себе сами. Добавить еще к Интернету постоянно работающий мобильник («спасибо» подешевевшему роумингу), и причины неуклонного роста благосостояния врачевателей неврозов становятся очевидными.

Как журналист и просто любитель техники я аплодирую прогрессу в области аппаратных и программных средств. Действительно, техническая сторона работы становится все проще и удобнее. Но как человек я немного насторожен. Сейчас нам еще удается выскакивать из колеса, которое мы упорно крутим. Но тропка-то на волю все сужается. И как бы нам не нащупать этот самый предел возможностей, благо психо-физиологические возможности гомо сапиенс не способны поспевать за законом Мура.

Что скажете, коллеги? Нагнетаю не по делу? Или есть рациональное зерно? Просто скоро сезон отпусков, а у вас-то рабочее место тоже всегда при себе. Как бороться с работой, если она так заманчиво близка на любом расстоянии от дома?

В Лондоне проходила презентация нового флагманского смартфона Samsung Galaxy SIII. Так получилось, что из России на нее полетел только я, и потому поступили заказы на «живые фотографии» для двух ресурсов, кроме нашего собственного. Помочь коллегам – святое дело, и отказываться не стал. Правда, задачка встала непростая: сначала отснять много-много кадров на два фотоаппарата, чтобы каждому ресурсу достались оригинальные снимки, потом быстро добежать до гостиницы, выбрать лучшие кадры, обработать их (снимаю исключительно в RAW) и отправить всем заинтересованным сторонам. Времени в обрез: читатели ждут оперативного отчета.

Для обработки картинок у меня на ультрабуке стоят Photoshop CS5.1 и IrfanView. Обычно это пара из Photoshop и ACDSee, однако после покупки камеры Canon PowerShot S100 у последнего приложения возникли проблемы с показом получающихся на ней RAW. Вроде бы новая версия ACDSee этим тайным умением обладает, но пока руки не дошли ее купить. IrfanView, теоретически, ничем не хуже, однако на практике ограничений здесь масса, и, например, просматривать на сразу много относительно крупных preview фотографий в RAW невозможно, а изменение размера у пары десятков кадров сразу реализовано, по крайней мере, не очень интуитивно. По крайней мере, я так и не сообразил – как это сделать. Возможно, причина в спешке и недосыпе. Но, конечно, дареному коню в зубы не смотрят, а IrfanView бесплатна целиком и полностью.

Презентация смартфона закончилась примерно в 23-20 по Москве, а уже в половине первого я отослал первую партию обработанных фотографий. К часу с хвостиком было отослано вообще все. RAW-файлы мои камеры выдают немаленькие, по 11-13 мегабайт каждый. Однако обрабатывать их на ультрабуке – сплошное удовольствие. Никакой разницы в скорости по сравнению с настольным компьютером, по крайней мере, не заметил. Если бы не мои старомодные привычки обрабатывать каждый файл в Photoshop’е по отдельности, а не общим скриптом, получилось бы еще быстрее. В результате, еще до того, как я рухнул спать, фоторепортажи были опубликованы сразу в трех местах (раз, два и три). Надо будет в следующий раз и видео снять.

Наутро, более-менее выспавшись, отправился по магазинам. Дело в том, что все культурные места в Лондоне я истоптал во время прошлых визитов, в десятый раз припадать губами к переходу на Abbey Road счел излишним, а в магазинах всегда что-то новенькое. Не рискну публиковать здесь полный фоторепортаж о лондонском шоппинге, но несколько кадров все же выложу. Забрел я в один из огромных и довольно бестолковых магазинов. На первом этаже часы и косметика, на втором и третьем женская одежда, на четвертом мужские вещи, на пятом – подушки, кастрюли и прочие домашние принадлежности. А на самом верху разместился отдел, торгующий электроникой. Ультрабуков там насчитал шесть штук, причем стоят они на отдельных маленьких стендах с разъяснительными надписями.

Выбор довольно приличный – от первопроходца Acer Aspire S3 до свежих Samsung. Некоторые бренды представлены сразу двумя-тремя моделями. Причем, подчеркиваю, это просто отдел в большом универсаме, а не специализированный магазин электроники.

На меня сильное впечатление произвела вот эта «таблетка» на Core i5. По характеристикам – настоящий мощный компьютер, с 4 гигабайтами ОЗУ, SSD на 64 гигабайта, емкостным мультитач-экраном с разрешением 1366х768 (причем матрица не TN, а PLS), USB-портами и другими привычными вещами. При необходимости подключаем мышь, клавиатуру и монитор, и тогда получается совсем уж бескомпромиссная рабочая лошадка.

При этом вес – 860 грамм, толщина корпуса 13 миллиметров, а время автономной работы – до шести с половиной часов. Последнее, правда, относится к очень оптимистичным фантазиям маркетологов, но пять часов тянет точно. И все это, замечу, на процессоре, который для таких нужд, прямо скажем, заточен средне. Чует, чует мое сердце – на Ivy Bridge пойдут уже не красивые экспериментальные модели, вроде этой, а вполне себе массовые решения. И цена, надо думать, снизится: все же 1000 фунтов (47 000 рублей) за планшет, каким бы функциональным он ни был, дороговато. Также очень любопытно, на какой операционной системе планшетных компьютеров с x86 внутри будет больше, на Android или Windows 8? Вам как кажется?

А знаете, что было самым знаковым во время лондонской командировки? Я впервые за последние полтора года не взял с собой iPad. С ультрабуком он оказался не очень-то и нужным…

В свое время сотрудник Apple дал мне мудрый совет по сохранению экрана в чистоте: надо просто отказаться от всяческих чехлов и носить iPhone в кармане джинсов. Действительно, помогает. Особенно если не класть по соседству ключи от квартиры. Но все это не тянет даже на полумеру: в конце концов, просто нереально ходить круглый год в джинсах, а карман пиджака, классических брюк или шорт чистящим эффектом в должной мере не обладает. Казалось бы, остается лишь смириться с неизбежным злом, но, возможно, его удастся забороть немного с другой стороны. Как вы, наверное, знаете, со 2 февраля в продажу поступила версия Microsoft Kinect для Windows, а также стал доступным для скачивания Kinect Windows SDK версии 1.0. Ходят слухи, что сейчас тестируется версия Kinect, встраиваемая в ноутбуки и ультрабуки, а там, глядишь, дело дойдет до таблеток и смартфонов. Я, конечно, слабо верю в то, что кто-то будет прыгать перед экраном телефона, изображая веселого тигренка, или даже боксировать с виртуальным противником. Но многие привычные операции можно будет совершать без физического контакта. Речь, конечно, не только о банальной идентификации по лицу – это работает и безо всяких мудреных Kinect’ов. Но вот управление жестами может оказаться очень кстати. Пальцами можно изображать много всякого, и одна фигура будет запускать любимое приложение, вторая – открывать адресную книгу, третья, наоборот, возвращать на главный экран. И так далее, и тому подобное. Кстати, только представьте – какой жест будет выбран большинством для звонка любимому руководителю… Результат: экран чистый, аппаратные кнопки испытывают минимум нагрузки и служат дольше, у людей планеты резко улучшается мелкая моторика. Побочный эффект – сокращение времени автономной работы, потому что пара-тройка камер, работающих постоянно, кушает ох как много энергии. Но, глядишь, к тому времени модули камер научат хорошим манерам.

Сама Microsoft тоже не напирает на игровое использование Kinect на компьютерах. Уже выложены ролики о том, как хороша система во время презентаций; как хирург, не нарушая стерильности рук, листает на экране слайды с УЗИ-обследования прямо во время операции, и т.д. и т.п. Выглядит красиво и практично. И все же чуть отстраненно от широких масс.

В связи с этим не могу не поинтересоваться у читателей – а какую практическую пользу вы видите от проникновения на мобильные компьютеры возможности бесконтактного «мимически-ручного» управления? Я, например, вижу огромное облегчение для людей с ограниченными возможностями, причем без дополнительных и недешевых ухищрений, прямо из коробки. А что еще? Как Kinect и его альтернативы могут пригодиться в ультрабуке, в планшетном ПК, в смартфоне? И, главное, насколько удобно добавлять поддержку подобных вещей в программное обеспечение? Просто наизобретать-то можно чего угодно, а реализация на практике частенько прихрамывает на все четыре лапы по весьма банальной причине непродуманности технологии в этом аспекте. Кто уже изучал Kinect Windows SDK живьем?

Кстати, насчет альтернатив – это не оборот речи. На той же CES я познакомился с парнями из израильской компании Omek Interactive, которая придумала технологию, позволяющую соорудить аналог Kinect из подручных средств. Подключаете к компьютеру буквально любые камеры, от камкордеров до вебок, система все это распознает, объединяет, и понеслась. Учитывая, что и сам Kinect родился в Израиле, удивляться не приходится

Статья под названием «Acer Aspire S3, ультрабук-первопроходец» опубликована на Хабре, добро пожаловать читать и плюсовать (ну, или минусовать, если не понравится). Но вот представьте, купили вы себе что-то подобное, установили привычные программы и призадумались – эх, а чем бы его таким зарядить, чтобы чувствовалось не только «бук», но и «ультра»? При поддержке моего коллеги Андрея Крупина могу предложить несколько вариантов на подобный случай.

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

Многим, наверное понравится и программка Luxand Blink!, позволяющая отказаться от ввода пароля или сканирования пальца при входе в свой эккаунт. Достаточно просто заглянуть в объектив встроенной камеры – и все, добро пожаловать. А защищать ноутбук хотя бы паролем надо непременно – мало ли что может случиться в дороге. Самые же ценные данные можно зашифровать при помощи программы, вроде Folder Lock. Я очень-очень надеюсь, что ни мне, ни вам никогда не придется потерять ноутбук, но, право же, в подобных случаях о железке переживаешь гораздо меньше, чем о личной информации, попадающей в лапы непонятно кому.

Возвращаясь к вопросу энергосбережения, вспомним о программке Aerofoil которая поможет детально настроить функциональность ультрабука при питании от сети и от батареи, а потом мгновенно переключиться между настройками. Многое из этого можно проделать стандартными средствами Windows, но придется повозиться, а вещи, вроде интерфейса Aero, все равно надо будет включать/выключать вручную. Лучше сэкономить время, благо программка-то бесплатная.

Мы с вами понимаем, что перечисленное выше ПО написано не для ультрабуков, а «просто так». И вот вопрос – а можно ли придумать что-то особенно полезное именно для этого нового класса мобильных компьютеров? Или это слишком нишевая штука, чтобы ломать голову? Или ничего особенного в ультрабуках, с точки зрения разработчика, нет и не будет?

Поделитесь мыслями, пожалуйста.

В практическом программировании периодически возникают задачи, связанные с необходимостью модификации программного обеспечения при условии отсутствия доступа к его исходным кодам (например, в случае утраты исходных кодов приложения, необходимости доработки стороннего программного обеспечения (добавление в сторонние продукты поддержки сертифицированных в России криптоалгоритмов, реализованных в сторонних криптопровайдерах, например «Крипто-Про JCP»).
Автором предлагается для модификации ПО использовать отладочный интерфейс (в данной статье рассмотрена платформа Java и Java Debug Interface (JDI)): устанавливать в некоторые места точки останова и ждать их активации (по активации точек останова анализировать состояние внутренних структур данных модифицируемого приложения и выполнять действия на основании полученных данных).
В статье описывается, как можно провести анализ модифицируемого приложения (реверс инжиниринг), дается небольшой обзор JDI и общие рекомендации по созданию модифицирующего приложения-отладчика. В конце стать есть пример.

Рисунок 1. Общая архитектура программного комплекса

На рис.1 представлена общая архитектура программного комплекса, состоящего из отлаживаемого модифицируемого приложения, которое необходимо запускать с ключом JVM, активирующим отладку, и разработанного приложения, которое подключается к целевому приложению в качестве отладчика, устанавливает необходимые точки останова и ожидает их активации.
В первую очередь для модификации ПО необходимо провести анализ модифицируемого приложения (реверс-инжиниринг) и выявить места, где необходима и возможна установка точек останова. Это описано в разделе «Анализ модифицируемого приложения». Далее необходимо создать приложение, которое через отладочный интерфейс: создает необходимые точки останова, следящее за их состоянием и анализирующее внутренние структуры данных модифицируемого приложения при их активации. Этот этап описан в разделе «Создание приложения-отладчика». Замечания по полученной системе, ее компонентах и их развертывании описаны в разделе «Развертывание модифицированного приложения».

Анализ модифицируемого приложения

Получение примерных исходных кодов модифицируемого приложения

Для начала анализа модифицируемого приложения необходимо получить его бинарные jar-файлы с основной логикой его работы (обычно находятся в папке, куда устанавливается модифицируемое приложение). Далее для простоты описания предполагается, что вся логика модифицируемого приложения содержится в одном jar-файле.
Первоначально необходимо получить примерные исходные коды приложения, для этого следует распаковать jar-архив как архив zip. В результате этого действия в целевой директории (куда происходила распаковка jar-архива) окажется откомпилированный байт-код Java, сгруппированный в class-файлы, находящиеся в каталогах, соответствующих пакету класса.

Для класса a.b.c.D – файл .\a\b\c\D.class

Для последующего анализа целесообразно получить примерные исходные коды приложения. При этом следует иметь в виду, что декомпиляторы для Java не могут полностью восстановить исходные коды реальных приложений. Полностью восстановить исходные коды возможно лишь для примитивных примеров. Для восстановления исходных кодов по откомпилированному байт-коду, находящемуся в class-файлах, автор использует декомпилятор JAD, распространяемый как свободный для некоммерческого использования. JAD запускается командой вида:

jad -o -r -sjava -dsrc tree/**/*.class

tree/**/*.class – путь к скомпилированным class-файлам, распакованным из jar-архива приложения.
По выполнению данной команды в каталоге src будут находиться декомпилированные исходные коды классов модифицируемого приложения.

Нумерация строк в восстановленных исходных кодах отличается от реальной. Для установки точки останова по линии необходимо обратиться к ассемблерному листингу class файла.

jad не совсем корректно определяет try…catch блоки обработки исключений.

Анализ исходных кодов

Следующие 2 пункта являются итерационными действиями. Т.е., если по их выполнении не достигнута цель, необходимо повторить их выполнение.

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

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

Проверка положения точек останова

Для уточнения и проверки мест, при выполнении которых будут активироваться точки останова, необходимо воспользоваться отладочными функциями платформы Java. Необходимо запустить виртуальную машину Java (далее JVM – Java Virtual Machine), которая выполняет модифицируемое приложение в отладочном режиме. Для этого необходимо скорректировать (добавить) параметры, передающиеся приложению JVM при старте (параметры командной строки). Обычно java-приложение запускается строчкой вида Java –jar ПутьКJAR.jar (для более серьезных программных продуктов используются собственные «запускальщики», в конфигурационных файлах которых содержатся параметры запуска JVM), к которой необходимо добавить параметры

-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y

Теперь можно открыть среду программирования на Java (например, NetBeans) и начать удаленную отладку приложения: среда подключится к модифицируемому приложению в качестве отладчика, что даст возможность уточнить места модифицируемой функциональности, в которые необходимо устанавливать точки останова. В первом приближении для более точного определения участка, обрабатывающего необходимое событие, автор рекомендует ставить точки останова (Breakpoint) для всех методов класса (флажок All Methods), полученного в ходе анализа декомпилированных исходных кодов. Также рекомендуется установить реакцию на точку останова – продолжение выполнения.

Если исходные коды были скомпилированы без информации о:

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

локальных переменных, то информация о локальных переменных будет недоступна

Стоит обратить внимание на поле ввода “Print Text” свойств точек останова – во время активации точки останова на панель Output будет выводиться сообщение из этого поля ввода. В это поле ввода можно добавить вывод значений полей или выполнения методов. Вычисляемые значения обрамляются символами “{=” и “}” в начале и конце соответственно. Пример: Break point active: {=SomeField}, {=toString()}, {=SomeMethod()}

Далее следует проанализировать результат, выведенный в панели Output. В нем необходимо найти классы и методы, вызываемые при возникновении ожидаемого события. В результате этого будет получен список методов классов, пригодных для обнаружения факта возникновения события.

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

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

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

Можно рекомендовать изменить окно стека и проанализировать поля/локальные переменные других окон стека.

Также возможна реализация такого механизма модификации: выявляется некий относительно простой (по объему кода) класс (возможно, предок какой-то иерархии), чей код достаточно читаем после декомпиляции. Необходимо полностью восстановить его, чтобы класс компилировался и добавить необходимый функционал (например, записи в файл). Откомпилированный класс, представляющий собой class файл можно будет на лету заменить при помощи метода redefineClasses(…) объекта, реализующего интерфейс VirtualMachine (подробнее рассмотрено в разделе «Выполнение методов в отлаживаемой JVM»).

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

Создание приложения-отладчика

Установление связи отладчика и отлаживаемого приложения

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

Автор использовал реализацию JDI от Sun, распространяемую вместе с Java Development Kit (JDK) в виде jar-архива tools.jar.

Для установки соединения c удаленной JVM используются классы com.sun.jdi.Bootstrap com.sun.jdi.VirtualMachineManager. В результате подключения к удаленной JVM будет получен объект, реализующий интерфейс com.sun.jdi.VirtualMachine (см. Листинг 1).

1. VirtualMachineManager VMManager = Bootstrap.virtualMachineManager();
2. for (AttachingConnector Connector : VMManager.attachingConnectors())
3. {
4.   if (Connector.transport().name().equals(“dt_socket”))
5.   {
6.     AttConnector = Connector;
7.     break;
8.   }
9. }
10. Map<String, Argument> connectorParameters = AttConnector.defaultArguments();
11. connectorParameters.get("port").setValue(Port);
12. connectorParameters.get("hostname").setValue(Host);
13. VirtualMachine result = AttConnector.attach(connectorParameters);

Листинг 1. Подключение к отлаживаемой JVM

В документации JavaDoc описаны несколько методов подключения отладчика. Выше показано использование самого интересного варианта – подключение на лету (Just-In-Time Debugging). Стоит отметить, что подключение к отлаживаемой JVM возможно с помощью нескольких коннекторов:

• dt_socket – подключение через сетевые сокеты;
• dt_shmem – подключение через общий участок памяти

Выбор коннектора из списка возможных, возвращаемых методом attachingConnectors() экземпляра класса VirtualMachineManager, осуществляется по названию. Различные реализации JVM могут предоставлять разные коннекторы.

Описание параметров подключения для каждого коннектора представлены в Таблице 1.

Таблица 1. Коннекторы и их параметры

Пример, приведенный в Листинге 1, иллюстрирует подключение через коннектор dt_socket. Данный коннектор позволяет отлаживать приложения не только в рамках локального компьютера, но и удаленно (по сети).

Типы точек останова, поддерживаемые JVM

Интерфейс JDI поддерживает типы точек останова, представленные в Таблице 2. Все точки останова унаследованы от интерфейса EventRequest.

Таблица 2. Типы точек останова

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

1. EventRequestManager Manager = JVM.eventRequestManager();
2. ReferenceType RefType = JVM.classesByName("Целевой.Класс").get(0);
3. Method RefMethod = RefType.methodsByName("ЦелевойМетод").get(0);
4. BreakpointRequest Request = Manager.createBreakpointRequest(RefMethod.location());
5. Request.setSuspendPolicy(BreakpointRequest.SUSPEND_EVENT_THREAD);
6. Request.enable();

Листинг 2. Создание и «включение» точки останова

Пояснения к коду: первоначально создается менеджер точек останова (объект Manager). Далее происходит получение объектов с интерфейсами ReferenceType и Method, описывающих, соответственно, целевой класс и метод, находящиеся на удаленной JVM. Интерфейс Method унаследован от интерфейса Locatable, в результате чего можно получить точное местоположение метода в выполняемом байт-коде и создать в этом месте точку останова. Далее создается точка останова (объект Request типа BreakpointRequest), активирующаяся при выполнении каким-либо потоком приложения целевого метода (точнее, его начала, на которое указывает метод location()).

При создании точки останова можно изменить политику остановки потоков при активации точки останова с помощью метода setSuspendPolicy(int policy). На данный момент в JDI возможно 3 значения:

• SUSPEND_ALL – останавливать все потоки при активации точки останова
• SUSPEND_EVENT_THREAD – останавливать только поток, активировавший точку останова
• SUSPEND_NONE – не останавливать потоки

Главный цикл обработки событий активации точек останова

После создания всех необходимых точек останова и их «включения» (методом enable()) необходимо перейти к ожиданию активации точек останова. Если необходимые классы не были загружены на момент старта JVM и создания точек останова, можно создать дополнительную точку останова, активирующуюся по загрузке класса, и следить за моментом загрузки этого класса (см. полный текст программы в приложении).

После создания всех точек останова можно возобновить выполнение JVM, прерванное подключением отладчика, с помощью метода JVM.resume().

Для обработки активации точек останова необходимо получить объект типа EventQueue с помощью метода JVM.eventQueue(). Этот объект позволяет получить итератор событий активации точек останова (объектов с интерфейсом Event). Реализацию данных действий иллюстрирует листинг, приведенный ниже:

1. EventQueue  Events = JVM.eventQueue();
2. while(true)
3. {
4.   EventSet ProcessedEvents = Events.remove();
5.   try
6.   {
7.     EventIterator ItEvents = ProcessedEvents.eventIterator();
8.     while (ItEvents.hasNext())
9.     {
10.       Event NextEvent = ItEvents.nextEvent();
11.       ...
12.     }
13.   } finally {
14.     ProcessedEvents.resume();
15.   }
16. }

Листинг 3. Обработка очереди активированных точек останова

После обработки всех событий следует вызвать метод resume(), возвращающий управление в отлаживаемую JVM.

Обработка событий активации точек останова

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

1. if (NextEvent instanceof BreakpointEvent)
2. {
3.   BreakpointEvent Event = (BreakpoinEvent)NextEvent;
4.   StackFrame CurrentMethodContext = Event.thread().frame(0);
5.   ObjectReference SomeObject = CurrentMethodContext.thisObject();
6.   Field SomeFldRef = SomeObject.referenceType().fieldByName(FieldName);
7.   StringReference FieldValue =
8.     (StringReference)SomeObject.getValue(SomeFldRef);
9.   System.out.println(FieldValue.value());
10. }
11. else if (NextEvent instanceof ClassPrepareEvent)
12. {
13.   //обработка загрузки класса
14. }

Листинг 4. Обработка события активации точки останова

В данном листинге стоит обратить внимание на получение объекта this из верхнего окна стека и получение полей объекта this. У событий активации точек останова, реализующих интерфейс LocatableEvent (события о доступе/модификации поля, пошаговом выполнении, выполнении определенного кода и т.д.), есть возможность получить объект потока отлаживаемой JVM, в котором произошла активация точки останова. Данный объект предоставляет крайне широкие возможности: обход окон стека (получение объекта this, локальных переменных и полей объекта в выбранном окне стека), выполнение методов в отлаживаемой JVM.

Выполнение методов в отлаживаемой JVM

Для выполнения метода объекта необходимо первоначально получить объект, описывающий необходимый метод (как Method из reflection)(в данном примере получение метода упрощено). Для передачи параметров выполняемому методу передается массив объектов типа Value. Интерфейс Value представляет собой ссылку на конкретное значение в отлаживаемой JVM. Маршалинг из JVM отладчика в отлаживаемую JVM значений примитивных типов осуществляется с помощью перегруженных методов mirrorOf() интерфейса VirtualMachine, показанных в [1]. Таким же образом можно провести маршалинг строк (точнее, объектов типа java.lang.String). Таблица 3. Методы для маршалинга примитивных типов в отлаживаемую JVM

Возвращаемое значение	Сигнатура метода
BooleanValue	mirrorOf(boolean value)
ByteValue	mirrorOf(byte value)
CharValue	mirrorOf(char value)
DoubleValue	mirrorOf(double value)
FloatValue	mirrorOf(float value)
IntegerValue	mirrorOf(int value)
LongValue	mirrorOf(long value)
ShortValue	mirrorOf(short value)
StringReference	mirrorOf(String value)

1. static public Value InvokeMethod(ThreadReference Context,
2.   ObjectReference Object, String MethodName, Value[] Params)
3. {
4.   Method CallMethod = Object.referenceType().methodsByName(MethodName).get(0);
5.   List<Value> ParamsList = new ArrayList<Value>();
6.   result = Object.invokeMethod(
7.                        Context,
8.                        CallMethod,
9.                        Arrays.asList(Params),
10.                        ObjectReference.INVOKE_SINGLE_THREADED
11.                    );
12.  
13.   return result;
14. }

Листинг 5. Выполнение метода в отлаживаемой JVM

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

Еще одной чрезвычайно интересной возможностью JDI является переопределение байт-кода класса на лету, во время выполнения. Доступность данной возможности можно определить с помощью метода canRedefineClasses() интерфейса VirtualMachine. Переопределение байт-кода класса производится с помощью метода redefineClasses(Map<? extends ReferenceType,byte[]> classToBytes) интерфейса VirtualMachine. Данный метод будет успешно выполнен и модификация классов осуществится только если метод canRedefineClasses() вернул истину, т.е. отлаживаемая JVM поддерживает динамическое переопределение классов.

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

Развертывание модифицированного приложения

Для развертывания модифицированного приложения рекомендуется создать bat-файл, запускающий JVM в отладочном режиме (или дописать необходимые параметры в конфиг «стартера» приложения), вида:

Java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y –jar ПутьКJARПриложения.jar

Особо стоит обратить внимание на флаг suspend (ожидание подключение отладчика), установленный в “y” (сокр. от “yes”). Это сделано сознательно, с целью предотвратить запуск приложения отдельно от приложения-отладчика, реализованного в виде стороннего приложения.

После выполнения данной команды ОС загрузит JVM, которая будет ожидать подключения отладчика на порт 8787. После подключениия отладчика выполнение jar-файла будет продолжено.

Пример работы с JDI

Для запуска примера необходимо:

1. Скомпилировать отлаживаемое приложение.
2. Запустить отлаживаемое приложение командой вида:
   

   Java -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n –jar ПутьКJARПриложения.jar

3. Скомпилировать приложение-отладчик.
4. Запустить приложение-отладчик командой вида:
   

   Java –jar ПутьКJARПриложения.jar

Пример приложения-отладчик

1. package Jdi;
2.  
3. import com.sun.jdi.*;
4. import com.sun.jdi.event.*;
5. import com.sun.jdi.connect.AttachingConnector;
6. import com.sun.jdi.connect.Connector.Argument;
7. import com.sun.jdi.connect.IllegalConnectorArgumentsException;
8. import com.sun.jdi.request.BreakpointRequest;
9. import com.sun.jdi.request.EventRequestManager;
10. import java.util.Map;
11. import java.io.IOException;
12.  
13. /**
14.  *
15.  * @author Sergey Melnikov
16.  */
17. public class HelloJDI
18.   private static final String TRANSPORT = "dt_socket";
19.   private static final String ClassName = "Jdi.Main";
20.   private static final String MethodName = "PrintFieldValue";
21.   private static final String FieldName = "_someField";
22.  
23.  
24.   private VirtualMachine JVM;
25.  
26.   // создаем точку останова для класса ClassName, метода MethodName
27.   private BreakpointRequest CreateBreakpointRequest()
28.   {
29.       // получаем менеджер точек останова
30.       EventRequestManager Manager = JVM.eventRequestManager();
31.  
32.       // получаем типы
33.       ReferenceType RefType = JVM.classesByName(ClassName).get(0);
34.       Method RefMethod = RefType.methodsByName(MethodName).get(0);
35.  
36.       //создаем точку останова
37.       BreakpointRequest Request =
38.           Manager.createBreakpointRequest(RefMethod.location());
39.       Request.setSuspendPolicy(BreakpointRequest.SUSPEND_EVENT_THREAD);
40.  
41.       return Request;
42.   }
43.  
44.   // подключаемся к удаленной JVM, ожидающей подключения отладчика
45.   private void ConnectToJVM(String Host, String Port)
46.     throws IOException, IllegalConnectorArgumentsException
47.   {
48.       VirtualMachineManager JVMManager = Bootstrap.virtualMachineManager();
49.  
50.       AttachingConnector AttConnector = null;
51.       for (AttachingConnector Connector : JVMManager.attachingConnectors())
52.       {
53.         if (Connector.transport() !=
54.           null && Connector.transport().name().equals(TRANSPORT))
55.         {
56.           AttConnector = Connector;
57.           break;
58.         }
59.       }
60.  
61.       // заполняем параметры
62.       Map<String, Argument> ConnectionParams =
63.         AttConnector.defaultArguments();
64.       if (ConnectionParams.containsKey("port"))
65.           ConnectionParams.get("port").setValue(Port);
66.       if (ConnectionParams.containsKey("hostname"))
67.           ConnectionParams.get("hostname").setValue(Host);
68.       if (ConnectionParams.containsKey("timeout"))
69.           ConnectionParams.get("timeout").setValue("10000");
70.  
71.       JVM = AttConnector.attach(ConnectionParams);
72.   }
73.  
74.   public HelloJDI()
75.   {
76.   }
77.  
78.   public void Process () throws Exception
79.   {
80.     // подключаемся к JVM
81.     ConnectToJVM("127.0.0.1", "8787");
82.     //создаем и активируем точку останова
83.     CreateBreakpointRequest().enable();
84.  
85.     // возобновляем выполнение в JVM
86.     JVM.resume();
87.  
88.     int i = 0;
89.     // получаем очередь
90.     EventQueue  Events = JVM.eventQueue();
91.     while (true)
92.     {
93.       EventSet ProcessedEvents = Events.remove();
94.       try
95.       {
96.         // разбираем очередь
97.         EventIterator ItEvents = ProcessedEvents.eventIterator();
98.         while (ItEvents.hasNext())
99.         {
100.           Event NextEvent = ItEvents.nextEvent();
101.           BreakpointEvent MyEvent = (BreakpointEvent) NextEvent;
102.  
103.           // получаем окно стека, объект this и поле FieldName
104.           StackFrame CurrentMethodContext = MyEvent.thread().frame(0);
105.           ObjectReference SomeObject = CurrentMethodContext.thisObject();
106.           Field SomeFldRef =
107.             SomeObject.referenceType().fieldByName(FieldName);
108.           //получаем и выводим значение поля
109.           StringReference FieldValue =
110.             (StringReference)SomeObject.getValue(SomeFldRef);
111.           System.out.println(FieldValue.value());
112.  
113.           SomeObject.setValue(SomeFldRef, JVM.mirrorOf(String.valueOf(i)));
114.  
115.           ++i;
116.         }
117.       }
118.       finally
119.       {
120.         ProcessedEvents.resume();
121.       }
122.     }
123.  
124.   }
125.  
126.   public static void main(String[] Args) throws Exception
127.   {
128.     HelloJDI Hello = new HelloJDI();
129.     Hello.Process();
130.   }
131. }
132.  

Тестовое модифицируемое приложение

1. package Jdi;
2.  
3. /**
4.  *
5.  * @author Sergey Melnikov
6.  */
7. public class Main
8. {
9.  
10.     private String _someField = "text";
11.  
12.     public void PrintFieldValue()
13.     {
14.         System.out.println(_someField);
15.     }
16.  
17.     /**
18.      * @param args the command line arguments
19.      */
20.     public static void main(String[] args) throws InterruptedException
21.     {
22.         // TODO code application logic here
23.  
24.         Main obj = new Main();
25.         while(true)
26.         {
27.             obj.PrintFieldValue();
28.             Thread.currentThread().sleep(1000);
29.         }
30.     }
31.  
32. }

Список литературы

1. JavaTM Debug Interface [Электронный ресурс] : Java SE Technical Documentation. URL: http://download.oracle.com/javase/1.5.0/docs/guide/jpda/jdi/
2. JPDA Enhancements [Электронный ресурс] : Java SE Technical Documentation. URL: http://download.oracle.com/javase/1.5.0/docs/guide/jpda/enhancements.html
3. JavaTM Native Interface (JNI) [Электронный ресурс] : Java SE Technical Documentation. URL: http://download.oracle.com/javase/1.5.0/docs/guide/jpda/jdi/
4. Java Art Chapter 3. Tracing with JPDA [Электронный ресурс] URL: http://fivedots.coe.psu.ac.th/~ad/jg/javaArt3/traceJPDA.pdf
5. Java Virtual Machine Specification, The class File Format [Электронный ресурс] URL: http://java.sun.com/docs/books/jvms/second_edition/html/ClassFile.doc.html

Как кто-то мудро подметил, планшетные ПК придуманы для потребления контента, а ноутбуки – для его создания. В принципе, так и есть: пока тебе надо что-то просто читать, проблем особых не возникает. Но при малейшей попытке даже не создать, а чуть изменить контент, появляется масса непреодолимых препятствий.

О редактировании чего-либо объемного без клавиатуры и мыши даже говорить не хочу – мучительное и бесполезное занятие. Неприятности возникают даже при банальных ретвитах: так, когда я решил поделиться с читателями линком на пост о Козьмодемьянске, коварный клиент где-то потерял http перед ссылкой, так что многие получили ее не кликабельной. Но самый настоящий цирк начался, когда мне понадобилось подключить одну услугу на сайте своего оператора мобильной связи. Там, знаете ли, фрэймы используются, а браузеры Safari и Opera в мобильной инкарнации их отрабатывают отвратительно. Поэтому не прокручивается фрейм – и хоть ты тресни. Выход, конечно, нашелся: будучи в Козьмодемьянске, я при помощи утилиты TeamViewer подключился к NAS на Atom, круглосуточно работающему в Москве (заодно посмотрел через вебкамеры, все ли дома в порядке). Открыл на нем стандартный IE, зашел на сайт оператора и сделал все, что надо. А вот для редактирования статьи, опубликованной на сайте 3DNews, пришлось ждать, пока доберусь до ноутбука: сочетание фреймов и 30 килобайт текста с большими картинками сделало связку iPad+NAS неработоспособной.

Еще у меня в дороге обрушилась файловая система на флэшке с фоторепортажем. Смотреть картинки на iPad и его ARM-собратьях уже кое-как можно (особенно, говорят, интересно получается с 30-мегабайтными RAW), а восстанавливать карточки – никак. Не будь под рукой ноутбука, потерял бы покой и сон до возвращения в Москву, а так – всего-то часа три понервничал.

Что мы имеем в итоге? Сам планшетный ПК в дороге – штука нужная. Нет, ну серьезно, гораздо удобнее потреблять на большом экране, да еще и особо не задумываясь о времени автономной работы. Но вместо того, чтобы делать сумку путешественника легче, «таблетка» ее наоборот утяжеляет. Ведь без нее после пары месяцев использования уже плохо, а без ноутбука по-прежнему никак. Вот и таскаешь на себе два устройства вместо одного.

Но зато после недели экспериментов над самим собой удалось сформулировать – каким хочется видеть правильный планшет. Внешне он может остаться таким, как сейчас, но в нем непременно должны жить две операционные системы. Одна – чуть урезанная – для мобильно-социальных нужд. MeeGo, Android 3.1, iOS - кому что нравится. При этом частота процессора может быть принудительно уменьшена вдвое для пущей автономности. Но по соседству непременно должно стоять нечто «большое» - Windows или Mac OS. Чтобы можно было за считанные секунды перезагрузиться, подключить мышь с клавиатурой и от потребления перейти к работе.

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

Да, и, пожалуй, нет смысла уточнять – на какой платформе всё это будет работать

Если вы все же проследовали по линку, который я дал выше, то, наверное, знаете, что на Computex показали огромное количество планшетников на Intel Atom. Это чистая правда, но в то же время – лишь половина правды, потому что планшетных ПК НЕ на Atom показали еще больше. Причем я сначала морщился, что варианты с «атомом» отличаются слишком теплой тыльной частью. А потом вдруг выяснилось – мощные двухъядерники на альтернативной архитектуре под нагрузкой лишь немногим холоднее. Особенно если разработчики решили шикануть и сделать корпус потоньше.

Но пока мелкие и средние компании показывали очередные «просто планшеты» (вы не поверите, но один китайский бренд таки сделал планшетник с двумя симками и грозится вот-вот выбросить на рынок улучшенную версию - с телевизором!), гранды прикидывали – как бы довести его до ума? Ведь в нынешнем виде планшетный ПК, к сожалению, не может заменить нетбук и, в силу габаритов, не способен составить конкуренцию плееру. А раз так, при всей кажущейся мегапопулярности, этот тип устройств рискует остаться нишевым. Нет, ну серьезно – только очень состоятельным и продвинутым людям легко убедить себя в необходимости покупки еще одного недешевого гаджета, который ничего не заменяет, но зато мило дополняет. Оно бы и неплохо, но мало, катастрофически мало таких людей – спросите у любой незамужней жительницы мегаполиса с высшим образованием.

Что же делать?

Если смотреть в Computex, как в хрустальный шар, явно вырисовывается два направления развития. Первое – фактические сращивание с клавиатурой. Планшетный ПК превращается в ноутбук с отстегивающимся экраном: поносил полдня отдельно, а потом вернул на место и начинаешь полноценно работать. Лично мне такой вариант очень симпатичен: можно брать в дорогу только вот такой комбайн, а не ноутбук плюс планшетник, как сейчас. Да и люди на такую идею реагируют крайне позитивно.

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

Вставляем его туда, и – вуаля! – получаем все телефонные возможности на большом экране, да с могучей батареей и, если разработчик не пожадничал, улучшенным звуковым трактом. Тоже, кстати, отличная тема: я слабо верю в то, что телефон способен вдохнуть жизнь в настоящий мобильный компьютер (одна такая попытка, представленная на CES, с треском провалилась), но на планшет его способностей хватит с запасом. Благо и в «маленьких», и в «больших» зачастую используется одно и то же железо. И чем покупать всю электронную начинку еще раз, я бы лучше заплатил за дополнительные ячейки батареи. Рраз, и телефон переходит на внешнее питание, весь нужный контент под руками, интернет работает (хочешь 3G, хочешь WiFi), память тоже приросла… Ну и цена такой «док-станции» должна быть довольно гуманной – с учетом того, что оптовая цена роскошного экрана с диагональю 10 дюймов укладывается в $100, а батареи, которой хватает на сутки, в двадцатку.

И вот тут мы подходим к самому интересному. По какому бы из путей не двинулась индустрия, наиболее комфортно и, если хотите, естественно будет использовать платформу х86 и Intel Atom. Нет, я не переел на Тайване местных веселящих орехов. Просто когда речь идет об отстегивающемся экране, можно прекрасно использовать опыт, накопленный за время выпуска нетбуков, разве что немного перекомпоновать конструкцию. В остальном же все действительно просто, а широкий выбор программных платформ и быстрое переключение между ними делает такие устройства весьма удобными для людей.

Что до варианта с док-станцией, то в мире PC такие конструкции уже выпускаются разными компаниями больше десяти лет, и технология отработана до мелочей. Поправьте меня, если ошибаюсь, но с технической точки зрения нет особой разницы - подключаешь ты маленький ноутбук к базе с жестким диском, батареей и набором внешних интерфейсов, или вставляешь смартфон в гнездо такой же точно базы, но еще и со встроенным сенсорным экраном. Если путь уже успешно пройден – стоит ли тратить немалые средства на организацию новой экспедиции?

Погружаясь в историю нашей индустрии, трудно не заметить, что она стремится к простоте, удобству изготовления и техническому единообразию. Даже очень упорные компании с пассионарными лидерами в итоге не выдерживали и вливались в тренд, не теряя, впрочем, ни в деньгах, ни в любви поклонников. Чисто по-человечески я, конечно, поддерживаю председателя Мао с его высказыванием «Пусть расцветают сто цветов, пусть соперничают сто школ». Однако при нынешнем уровне развития техники разнообразие аппаратных платформ – слишком большая роскошь, и, помяните мое слово, через поколение или два в Самом Популярном Планшете вдруг обнаружится что-то очень маленькое с архитектурой х86.

Между тем, реальные различия будут. Частично – на уровне дизайна корпуса, но в основном, все же, в сфере ПО. И именно вы, уважаемые разработчики, будете провоцировать людей на холивары в обозримом будущем. Удачи и терпения вам в работе, которая становится все интереснее буквально на глазах.

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

Я уже писал, что правильный NAS может не только работать сетевым диском и торрентораздатчиком, но и конвертировать видео или заменять домашнюю систему видеонаблюдения. Но недавно он выручил меня еще раз – и очень по-крупному.

Дома уже с год живет МФУ – вполне приличное, но с возможностью подключения к компьютеру только по USB. До поры всех устраивало, что печатать и сканировать можно только с одного компьютера в домохозяйстве, но по мере роста потребностей в комфорте назрела необходимость сделать МФУ сетевым. Но как? Роутер принт-сервером работать не умеет. Держать главный компьютер включенным круглые сутки – неправильно. Что же, покупать новое МФУ с поддержкой Ethernet/WiFi или, как минимум, более умный роутер? Ничего подобного: просто переподключаем МФУ к NAS, и с него раздаем услуги печати на все компьютеры в сети. Больше того, при помощи специальной программки BlindScanner удалось сделать сетевым не только принтер, но и сканер. Учитывая, что я уже на полном серьезе собирался в магазин – экономия налицо.

Можно сказать: ха-ха, так ведь и к NAS без х86 внутри можно подключать принтеры! Да, действительно, ко многим можно. Но слишком высока зависимость от прошивки NAS: если в ней что-то не дописано, или, наоборот, принтер попадется какой-то кочевряжистый (у меня как раз такой), ничего вы не напечатаете. Если же NAS работает под Windows или другой стандартной операционной системой, в случае каких-то шероховатостей можно найти десятки обходных маневров. Ведь даже относительно редкий дистрибутив Linux все равно на порядки популярнее самоделок, живущей в NAS на ARM, и советчиков в Интернете найти будет проще.

Теперь у меня навязчивая идея подключить к «атомному» NAS обычный беспроводной телефон. В свое время тестировал DECT-адаптер Siemens, который, будучи воткнутым в USB-порт, позволял выбирать – звонить по проводам или через SkypeOut. Сейчас такие на глаза что-то не попадаются, но я парень упорный, найду.

Экономить – так экономить.

И только в редких случаях, когда оба собеседника на одной волне, и повод для беседы есть интересный, и время не ограничено, получаются действительно интересные интервью (пользуясь случаем, приглашаю побеседовать в таком формате Пола Отеллини – Paul, let’s add a bit more life to ISN Russia!)

С Алексом Блэквеллом, главным полевым инженером Western Digital, мы встретились на днях в третий раз. Названию должности не удивляйтесь – этозападный аналог нашего «инженера по внедрению». Алекс активно перемещается по Европе, Ближнему Востоку и Африке, разъясняет своим подчиненным на местах суть нововведений в жестких дисках, дает консультации заказчикам и собирает отзывы о радостях и печалях последних. Такой опыт в сочетании с великолепным чувством юмора делает Алекса настоящей находкой для журналиста, а ему, в свою очередь, не очень скучно общаться с тем, кто искренне любит жесткие диски (ничего не могу с собой поделать – они ведь такие сложные и полезные). Сидим, общаемся, шутим, и вдруг Алекс говорит: «А мы тут в жесткий диск двухъядерный процессор добавили».

Ха-ха, говорю, отличная шутка! А Алекс серьезно так отвечает: «Да какие шутки? Правда добавили. С недавних пор винчестеры стали очень сложными – мало того, что головки приблизились к поверхности диска до 2 нанометров (еще недавно было 15), так еще к температурному датчику добавились сенсор давления, гироскоп, специальные «грелки» в головках, чтобы если изменится давление – приподнять или опустить ее над пластиной… Ну и скорость передачи данных серьезно выросла. В общем, одно ядро захлебывается от обработки столь разной информации, поставили еще одно по соседству. Теперь отлично».

Тут бы мне остановиться в восхищении, но не удержался – начал копать дальше. И обнаружилось, что частота кварцевого резонатора чудо-процессора составляет… 25 мегагерц. Производительность лишь в 50 раз больше, чем у ветхозаветного компьютера IBM PC AT. То есть погонять в Quake на винчестере пока не получится. Но сам факт!

Я поинтересовался – не планируется ли со временем добавить ядер и переложить на процессор часть работы CPU. Например, декодирование видео в специальных версиях HDD для телеприставок. Узнал, что ядер со временем, конечно, станет больше, но вот непрофильные задачи на них повесят вряд ли, потому что а) это потребует существенного изменения интерфейса и б) резко усложнит производство. Последнее очень важно: заводу загружают исходя из предварительных заказов, поступивших от клиентов, и если вдруг кто-то откажется от миллионной партии дисков для телекоробочек, комплектующие можно будет без труда использовать в других моделях. Благо механически все HDD очень похожи и очень многое зависит от прошитой микропрограммы. А излишне умный диск так вот просто не перемаркируешь, его на вторсырье пускать придется.

К чему я все это написал?

Товарищ! Многоядерность – это всерьез и надолго. Она поселилась в CPU, GPU, беспроводных сетевых контроллерах и вот теперь даже в жестких дисках. Обратного пути просто нет. Оптимизируй свое приложение для работы с несколькими ядрами! Вступай в программу Intel Software Partner!

Сейчас читаю тексты коллег, причем особенно забавно получилось у тех, кто на CES не летал и отслеживал анонсы по пресс-релизам. Например, десятки изданий написали о планшетном компьютере Motorola с Android 3.0, но на самом-то деле никакого «3.0» на CES не показывали, а сотрудники стенда Motorola совершенно честно признавались, что даже не знают – какой будет это версия. Вместо этого на прототипе планшетника в замкнутом цикле крутился видеоролик, где рассказывалось о некоторых «фичах» новой ОС, и не более того.

Но вообще, как я уже писал, планшетов на CES было – море разливанное, и добрых две трети работают на архитектуре x86 (процессоры от Intel Atom до Core i5). Нет никаких сомнений, что через 2-3 месяца экспонаты выставки в промышленных количествах появятся на прилавках, и, судя по моей почте, многие с нетерпением ждут этого момента. Однако я позволю себе высказать крамольную мысль: планшеты в чистом виде, т.е. один сенсорный экран без клавиатуры, лишь ступень эволюции. В итоге же клавиатура станет важным элементом сенсорного ПК, который будет эффективно дополнять его функционал.

Объяснюсь. Поначалу всем очень нравится управлять обновкой при помощи пальцев и гироскопа, однако довольно скоро обнаруживается, что эта связка, мягко говоря, неудобна в целом ряде задач. Я молчу про редактирование текстов или работу с таблицами – тут все очевидно. Но даже в играх, на которые планшетники очень даже горазды, одних виртуальных экранных кнопок не хватает. Попробуйте поиграть даже в простенькие гонки – уверяю, надоест очень быстро. А уж о более-менее серьезных шутерах и говорить не приходится, хотя погонять таковые на планшетах с х86 многим ой как захочется. Набор адресов в строке браузера, переписка, вбивание новых контактов в адресную книгу – это и многое другое с виртуальной клавиатурой столь же удобно, как и на лучших моделях смартфонов. То есть при необходимости – вполне себе можно. Но радости никакой.

Возможно, поэтому на CES показали так много способов прикрутить аппаратную клавиатуру к планшетнику. Где-то их объединяли в один корпус, делая сенсорный экран «отстегиваемым» (Lenovo), где-то применили подход из телефонов-слайдеров (Samsung), а некоторые вообще передали пламенный привет Артемию Лебедеву и сделали клавиатуру из маленьких дисплейчиков, где каждая кнопка меняет значение в зависимости от приложения (Razor&Intel). И во всех случаях идея сразу же становилась законченной: можно брать в дорогу всего одно умное устройство, даже если в командировке или на так называемом отдыхе придется поработать. А не так, как сейчас – планшетник и ноутбук. Первый – потому что с ним веселее, а второй – потому что без него никак.

А следующим шагом, скорее всего, станет использование в планшетных ПК 3D-экранов, благо аппаратные возможности позволяют обслуживать их потребности. Плюс, учитывая небольшую диагональ, вполне реально будет устанавливать экраны, не требующие специальных очков для достижения желанного эффекта. Интересно, каким будет первое приложение, использующее возможности 3D и «сенсорности»? Включим фантазию?