ГОЛУБЯТНЯ: Диалектика как отражение сезонных перемещений

Автор: Сергей Голубицкий

«Я почти ничего не понял. А главное – не понял, при чем тут компьютеры. Думаю, если бы этой статьи не было – мир бы не много потерял». Юзер «Рамзес» на форуме «Компьютерры» в адрес «ЗаДом»

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

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

Короче, я предупредил, а теперь перейдем, как было обещано на прошлой неделе, к чудо-кодеку AVC/H.264 и его бесплатной разновидности х264. Думаю, будет справедливо, если мы откажемся от порочной идеи потрафлять гоблинам и заливаться соловьем о спецификациях ITU-T Video Coding Experts Group и его аналогах ISO/IEC Moving Picture Experts Group (MPEG), на которых строится AVC/H.264. Нам, честным ламерам, подобное фанфаронство, уж простите, не к лицу. В нашем палисадике мы занимаемся суровой прагматикой жизни, посему озадачимся простыми вопросами: во-первых, зачем нужен очередной видеокодек, во-вторых – как его использовать?

Больше всего в истории с AVC/H.264 меня поразил факт его уже как четырехлетнего существования в суровом отрыве от потребительского мэйнстрима. Вернее – не в отрыве, а в непроявленности: втихаря AVC/H.264 давно и вовсю используется Министерством обороны США в качестве основного стандарта сжатия видеоданных, в спутниковом цифровом вещании, в трансляциях телевидения высокого разрешения, а также для кодирования видеороликов в культовом iPod’e, а вот преимущества AVC/H.264 для получения видеопотока максимально высокого качества на низких битрейтах мало известны широким народным массам, которые пребывают в наивной уверенности, что лучше DivX и XviD ничего на свете не существует.

Меж тем – еще как существует, причем на мобильных устройствах вроде КПК или Sony PSP преимущества AVC/H.264 над традиционным дуумвиратом (DivX и XviD) заметны невооруженным глазом. Там, где на динамически изменяемой картинке (мчится угнанный автомобиль, суровые люди отчаянно лепят друг другу моваши в ушные раковины) при потоке 750—800 кбит/с кодеки, основанные на компрессии MPEG4 Part 2 (DivX и XviD), рассыпаются мозаикой на цифровые квадратики, AVC/H.264, задействующий алгоритмы следующего поколения MPEG4 Part 10, выдает плавно переливающийся из кадра в кадр видеоряд.

Читателей, не доверяющих восторженному голубятнику, что говорится, «на глазок», отсылаю к результатам тестирования солидной «конторы в законе» Doom9.org: если начиная с 2003 года каждая новая версия кодека с открытым кодом XviD превосходит качеством коммерческий DivX, то уже с 2005 года AVC/H.264 обходит на вираже обоих.

Показательно, что размер видеофайла, сжатого AVC/H.264, нисколько не превышает размера DivX/ XviD, а единственной платой за улучшенное качество видеоряда служит значительное снижение скорости кодирования: в зависимости от сложности изображения – в два-три раза. Учитывая, впрочем, что кодированием честные люди занимаются безмятежными ночами, а не конвульсивными днями, овчинка выделки стоит.

После внесения ясности в «зачем», можно приступать к раскрытию «как». Здесь начинается самое интересное, поскольку кодировщиков много и приходится выбирать, а выбор, как известно, враг молодежи. Из пышного букета реализаций кодека AVC/H.264 можно выделить пятерку продвинутых и насущных (насущных, поскольку многие кодировщики сильно устарели, однако продолжают энергично проталкиваться на рынке). Это:

• некоммерческая версия x264;

• коммерческая NeroDigital AVC, встроенная в утилиту Nero Recode 2.5.2, доступную как отдельно, так и в пакете Nero Premium 7;

• не менее коммерческий «яблочный» QuickTime 7;

• Moonlight из OneCLick Compressor;

• Elecard, задействованный в Elecard Mobile Converter и MainConcept v2 Encoder.

Не забивая баки лишней информацией, можно сказать, что первых двух кодировщиков всем нам, честным ламерам, хватит за глаза, поскольку оба они поддерживают самые продвинутые фичи спецификации MPEG4 Part 10, а именно: компрессию CABAC, без потери качества снижающую битрейт на дополнительные 10–15 %, двухпроходную кодировку, фильтры разблокировки (так называемые Loop/Deblocking Filter), устраняющие артефакты на низких битрейтах, и прочую гоблинскую требуху, до которой, по гамбургскому счету, честным пацанам не должно быть дела. Главное, что на выходе мы получаем замечательного качества видео, которое непременно понравится всем, кроме разве что Антонелло, вынужденного компенсировать неполучение Нобелевской премии по литературе просмотром исключительно фильмов High Definition и музыки SACD.

Кодек x264, как и полагается бесплатным оборванцам, управляется через командную строку – обстоятельство, способное порадовать разве что теоретиков большого секса – из тех, кто вместо поездок в Крым годами ковыряется в гараже, растачивая кожуха и шмакодявя патрубки своим стальным коням. Не удивительно, что честным пацанам приходится применять GUI, внешнюю графическую оболочку. «Гуй» для x264 называется MeGUI, однако, похоже, и он заточен под адептов малакии: обилие настроек таково, что впору опрокинуться. Кто не верит, может полюбоваться скриншотами [1] и даже освоить программу в свободное от жизни время, вот только меня – увольте.

Единственно гуманный вариант кодирования видеофайлов в AVC/H.264 – NeroDigital AVC – утилита, дружественная ламерам и при этом нисколько не уступающая связке x264 + MeGUI по качеству продукта на выходе. Вот как это делается:

• В первом окне задаете фронт работ – перекодировка DVD и видео в Nero Digital (проприетарное название AVC/H.264), которая позволяет использовать в качестве исходника практически любой видеоматериал, либо перекодировка главного фильма в Nero Digital, при которой за бортом остается меню DVD-диска и шелуха пугательно-запретительных роликов. Обратите внимание на то, что первые три опции стартового окна программы (перекодировать весь DVD в DVD, перекодировать главный фильм в DVD и создать DVD) нас не должны интересовать – это простенькие операции авторинга, аналогичные тому, чем занимаются наши старые знакомцы DVDFab и CloneDVD [2].

• В основном окне программы вы нажимаете на кнопку «Импортировать файлы» и добавляете любое количество исходников (NeroDigital AVC самостоятельно анализирует структуру DVD-диска и выдает готовый список видеофрагментов). Затем определяете желаемый размер файла на выходе. Это можно делать либо по выпадающему списку «Размер носителя» (галочка установлена), либо вручную меняя положения движка на линейке (движок включается при отключенной галочке на «Размере носителя») [3].

• Настройку «Категория Nero Digital» оставляете без изменения по умолчанию – «Nero Digital AVC» (что соответствует кодеку AVC/H.264), профиль Nero Digital установите на «Standard – AVC», поскольку профили «Cinema AVC» (разрешение 1280х720) и «HDTV AVC» (1920х1080), как вы догадываетесь, надлежит использовать не для перекодирования DVD-диска, а для первичного кодирования непережатых исходников видеокамеры HDV.

• Нажимаете кнопку «Далее» и выбираете в левой панели «Установки Nero Digital». Единственное изменение в настройках по умолчанию, какое я рискнул бы рекомендовать, – переключите «Управление скоростью» с «Быстрого кодирования (1-проходное)" на «Высококачественное кодирование (2-проходное)" (опция «Управление скоростью»). Существенное увеличение времени кодирования будет компенсировано не менее существенным улучшением качества конечного результата. Все прочие настройки – «Максимальный диапазон векторов», «Свойства GOP», «Максимальные B-Frames», «CABAC», двунаправленный и взвешенный прогноз, разделы макроблока (по умолчанию – все включены), психовизуальные улучшения – бога ради! – оставьте без изменения.

• Жмете на «Запись» и записываете результаты кодирования в файл либо сразу прожигаете болванку.

Как говорят поганые работники рекламного бизнеса: «Вы будете приятно удивлены качеством нашей продукции». Фильмы, кодированные AVC/H.264, и в самом деле много лучше DivX и XviD.

Заключительный мазок – просмотр. AVC/H.264 замечательно играет и VLC Media Player, и «Гомик» (с предварительной доустановкой аудиокодека AAC), и, разумеется, «родной» Nero ShowTime из того же пакета Nero Premium 7. На КПК AVC/H.264 любит и уважает легендарный Core Player (TCPMP), на Sony PSP – разжеванный неделей раньше PMP MOD AVC 1.02. Короче, кодируйте и балдейте!

ИДЕИ: Пять инвариантов ИТ-образования

Автор: Шутов, Илья

Поводом для написания этой статьи, как ни странно, послужила очередная попытка воспользоваться интерфейсом Office 2007. Видимо, я не попадаю в то счастливое подмножество пользователей, для которых эргономисты компании Microsoft проводили такие глобальные переработки. А может, влияние книг – например, Джефа Раскина «Интерфейс: новые направления в проектировании компьютерных систем» – не дает насладиться новым facelifting в полной мере. Подсознание периодически выдает ужасающие метрики для доступа к той или иной базовой функции (вложенная нумерация заголовков, нумерация таблиц и рисунков, работа с колонтитулами, вставка формул, работа со стилями и пр.). Остается читать по губам: «использование таких „сложных“ функций не входит в круг обязанностей типичного пользователя», что не может не повергать в уныние. Но и соскочить никуда нельзя, поскольку Word является повсеместным корпоративным стандартом (OpenOffice можно не упоминать, по своей сути он является хоть и догоняющим, но все же бежит по той же самой тропинке), не позволяя при этом удобно и быстро готовить документы в заданном формате. Особенно если речь идет о документе, содержащем больше одной страницы, а также несколько иллюстраций и таблиц.

Возможно, сложившаяся ситуация зависит от качества полученного образования, причем зависит многогранно. В данном случае интересен аспект ИТ-образования, получаемого в университетах и институтах естественнонаучного направления. В главной кузнице кадров, МГУ им. М. В. Ломоносова, это факультеты ВМиК, физический, мехмат. Состояние современного рынка труда таково, что очень многие студенты упомянутых факультетов посвящают часть жизни работе программиста. Даже на непрофильных факультетах существуют курсы (поточные лекции/практические занятия, примерно два года), посвященные азам программирования. Однако содержание материала оторвано от жизни. То, что было пригодным лет пятнадцать-двадцать назад, сейчас требует переосмысления. Так какими следовало бы сделать эти курсы, чтобы их полезность (для студента в частности и для общества в целом) выросла многократно? Попробую предложить модель, которая является результатом практического опыта, скорректированного сообразно нынешним мировым тенденциям.

Типичный предмет, который преподается, называется «Программирование» или «Информатика». И обучают на этих курсах азам программирования на каком-либо языке из семейства C++/Pascal. Дают базовый синтаксис, учат натягивать на форму объекты и писать обработчики. Иногда рассказывают о быстрых методах сортировки. А затем студенты, прослушавшие такие курсы (а особо одаренные еще и написали несколько простеньких программок), считая себя гуру в указанном вопросе, приходят на работу. И оказывается, что ничего-то они не знают, а то, что знают, совершенно не годится с точки зрения бизнеса. И приходится опять в них вкладывать и обучать элементарным вещам. Причем, как ни удивительно, эти элементарные вещи имеют всеобъемлющий характер и могут быть распространены гораздо дальше общепринятых рамок «Программирования». О чем же идет речь?

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

Какие инварианты я бы выделил в настоящий момент? В первую очередь – искусство совместной работы. Не каждый сам по себе что-то пишет в своей норке, а группа создает нечто, что одному человеку не осилить (из-за сложности, нехватки времени или большого объема). А совместная работа подразумевает разделение кода и текста, версионность документов; формирование различных баз знаний, систем багтрекинга и увязку их с системой контроля версий; использование форумов и досок объявлений, проведение телеконференций. Необходимо рассказать о таких возможностях, показать лучшие практики, продемонстрировать продукты и для закрепления знаний устроить лабораторные работы. Причем все это нельзя давать сухо, конспективно. Желательно привнести популяризаторскую изюминку, далеко ходить не надо – откройте книги Перельмана. Возможно, полезной будет установка одного-другого продукта на лабораторном занятии. Можно, например, разделить группу на две команды, каждая из которых ставит и настраивает свой продукт, а потом сравнить результаты и сделать выводы. И после этого предложить сделать те же самые вещи при помощи Excel-файлов. Как ни смешно, однако ситуация, когда при помощи одного Excel-файла пытаются собрать информацию от нескольких десятков сотрудников и поддерживать ее в актуальном состоянии (делегируя актуализацию самим сотрудникам) – ужасающе типична для российских компаний. То есть снова и снова возникает одна и та же идея использования бинарного файла закрытой структуры для совместной работы, хотя постановка задачи вопиет о необходимости использования элементарной 3-звенной CRM-системы [CRM (customer relationship management) – управление взаимодействием с заказчиками. 3-хзвенная архитектура представляет собой решение в котором существуют 3 уровня: уровень данных (база данных), уровень бизнес логики (сервер приложений) и презентационный уровень (тонкий или толстый клиент на машине пользователя)].

Поскольку в настоящий момент существует масса продуктов с открытым кодом, очень неплохо было бы дать о них информацию и использовать их в программе. Грядущее вступление в ВТО может сильно ударить по карману любителям проприетарного ПО. В качестве следующего инварианта я бы выделил знакомство с паттернами программирования (чтобы знать, что велосипеды изобретены и ждут седоков [Шаблоны проектирования (паттерн, pattern) – это эффективные способы решения характерных задач проектирования, в частности проектирования компьютерных программ. Паттерн не является законченным образцом проекта, который может быть прямо преобразован в код, скорее это описание или образец для того, как решить задачу, таким образом, чтобы это можно было использовать в различных ситуациях. Объектно-ориентированные паттерны зачастую показывают отношения и взаимодействия между классами или объектами, без определения того, какие конечные классы или объекты приложения будут использоваться. Алгоритмы не рассматриваются как паттерны, так как они решают задачи вычисления, а не проектирования.]).В качестве наиболее понятного паттерна, чье влияние может быть распространено и на массу различных задач, выходящих за рамки разработки ПО, я предложил бы MVC [Шаблон MVC широко признан как один из самых хорошо разработанных и зрелых шаблонов проектирования которые используются в данное время. При использовании шаблона MVC, обработка разбивается на три различных части, а именно на Модель(Model), компоненты представления (View) и контроллер (Controller). Модель – это объект приложения. Контроллер описывает, как интерфейс реагирует на управляющие воздействия пользователя. Вид должен гарантировать, что внешнее представление отражает состояние модели. Такой подход позволяет присоединить к одной модели несколько видов, обеспечив тем самым различные представления. Более того, можно создать новый вид не переписывая модель. (Ист.: «Приемы объектно-ориентированного проектирования. Паттерны проектирования», Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес, М., 2007;«Введение в Struts», Кевин Беделл, 2002).]. Даже элементарная задача набора красивого документа должна осуществляться именно через этот паттерн. Статики давно нет, надо учиться оперативно и быстро реагировать на изменения во внешнем мире. Касательно документов – содержание и внешнее представление должны быть разделены! Тогда любые новые требования к оформлению (статья для журнала, включение части документа в объемлющий документ, изменение требований…) удовлетворяются достаточно просто. При этом исходный текст совершенно не затрагивается. Если взять за точку отсчета именно такой подход (а он идет из «программирования» – один первоисточник информации, данные и представление обособлены), то обучение системам а-ля WYSIWYG (Word, OO, FrameMaker, PageMaker, Writer…) является танцем бульдозера, вырвавшегося на городской газон. После работы с Word восприятие студента необратимо искорежено. Начинать надо с систем типа LaTeX, Docbook или обучения CSS (прелесть CSS для веб-страниц можно оценить на www csszengarden com). Только после того, как идея MVC (или стилей) будет принята, можно переходить к Word. Тогда уже можно доходчиво объяснить, ссылаясь на полученный на предыдущем шаге опыт, назначение стилей и пользу от их применения. Можно развивать идею дальше и искать аналогии для других паттернов. В частности, паттерн Facade может быть перенесен как в область построения экспериментальных установок, так и в области сложной обработки данных. Упрощение системы, локализация знаний о специфичных данных, будь то формат картинки или протокол обмена с устройством управления шаговым двигателем – суть одно и то же.

Третий инвариант: любой код стоит денег. Знакомство с реальной стоимостью кода и применение систем резервного копирования. Информация, при всей ее невесомости, стоит дорого. Можно оценивать ее в человеко-часах, например. Необходимо показать студентам, что каждое изменение кода, каждый документ стоит определенных денег. И необходимо заботиться об их сохранности. При всей очевидности этого подхода реальность такова, что разработчики вполне могут откладывать создание резервной копии исходников (либо через систему бэкапов, либо, что более правильно, через систему контроля версий [В терминологии систем контроля версий такая операция называется «commit» или «фиксация изменений»]) до тех пор, пока не будет потеряна многочасовая работа. Тем не менее это мало кого волнует, хотя все всё знают. Так, например, все знают о необходимости пристегивания ремнями, в автошколе экзамены начинаются именно с этого, краш-тесты открыто демонстрируют полезность ремней безопасности, однако на улице легко можно увидеть машину с ребенком, «болтающимся» в салоне, а пойманные гаишниками водители горазды придумывать себе оправдания. Теоретическое и практическое знания – разные вещи. В данном блоке я бы применил подход, аналогичный системе рейдов ГИБДД, а именно случайное форматирование нескольких машин в классе перед зачетной сессией. Все, кто хранил документы только на локальной машине (или в каталоге файл-сервера), смогут ощутить всю прелесть использования (или игнорирования) бэкапов. Возможно, полученный эффект заставит аккуратнее относиться к информации. Несомненно, 99 процентов читателей назовут такие методы зверскими. Однако опыт показывает, что лучше потерять на этом этапе, чем при сдаче коммерческого проекта – дешевле выйдет.

Четвертый инвариант: работа с требованиями [Не секрет, что продвижение компании по CMMI-лестнице определяется умением компании бороться с хаосом, то есть умением превращать процедуру разработки ПО в воспроизводимый процесс. И фундаментом для структуризации являются требования. Если провести аналогии и утрировать, то требования описывают точку, куда должна добраться вызванная машина такси, какими характеристиками она должна обладать и в какое время она должна подъехать]. Сбор, фиксация, изменение, управление. Несмотря на более чем пятидесятилетнее существование компьютерной отрасли, многие компании-разработчики ПО по-прежнему прикладывают значительные усилия для сбора и документирования требований, а также управления ими. Недостаточный объем информации, поступающей от пользователей, требования, сформулированные не полностью, их кардинальное изменение – вот основные причины, из-за которых командам, работающим в области информационных технологий, зачастую не удается вовремя и в рамках бюджета предоставить клиентам всю запланированную функциональность. Многие разработчики не умеют спокойно и профессионально собирать требования пользователей к ПО. Однако разработка ПО включает, по крайней мере, столько же общения, сколько и обычная работа с компьютером, но зачастую мы делаем акцент на работе с компьютером и не уделяем достаточно внимания общению. Пятый инвариант: основы управления проектами и управления рисками. Управление проектами является самостоятельной дисциплиной, но в рамках курса уместно привести базовые элементы и рассказать о специфике управления проектами в области разработки ПО. Любой современный проект (не только разработка ПО) требует десятков и сотен тысяч человекочасов. Для того чтобы такой проект имел шансы на успешное завершение, необходим план его реализации (управление проектом), который должен включать в себя анализ возможных неудачных сценариев и способов борьбы с ними (управление рисками). Ведь любая затяжка сроков приводит к удорожанию продукта, если не к краху компании. Нужно хотя бы вкратце рассказать о способах управления проектами, о том, чем занимается руководитель проекта, каковы его цели, почему команда разработчиков должна иметь руководителя. Практическая демонстрация расползания сроков в MS Project на примере гипотетического проекта из десяти задачек и трех исполнителей поможет перейти к понятию «риск» и объяснить, почему продукт никогда не будет сделан к дате, которая фигурирует в первоначальной версии проекта. Следует искоренять традицию работы в авральном режиме. Эта порочная практика никогда не даст положительного результата.

Разработка ПО и кодерство – разные вещи. Настоящий разработчик, а тем более лидер команды должен быть еще и психологом.

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

С другой стороны, поскольку зависимость бизнеса от ИТ только возрастает, если студент, изучивший такие аспекты, станет руководителем группы/компании, а не простым разработчиком, то польза от этих знаний тоже будет. Понимание внутренней кухни позволит более грамотно и уверенно делать выбор при внедрении в компании новых систем и доводить внедрение до успешного завершения. Знание поможет отличать специалистов от лодырей, выявлять среди неопытных студентов и выпускников тех, в ком есть необходимый потенциал, и позволит собирать под своим крылом профессиональные команды.