Журнал "Компьютерра" №751

Однако за все приходится платить, и похоже, стерео накладывает не меньше ограничений (в первую очередь творческих), чем дает возможностей. Вы не можете быстро двигать камеру, как привыкли на съемке видеоклипов, все ваши панорамы должны быть плавными. Забудьте про нормальные отъезды и наезды. Вы не можете склеить два кадра, стыкующиеся по всем закона монтажа, если они не согласованы по глубине. Забудьте про вертикальные вращения камеры. Если вдруг в вашем кадлре случайно появляется объект, который выходит за рамки уже существующей глубины кадра, он мгновенно разрушает весь стереоэффект. Вы не можете просто пересчитать существующую анимацию, заменив одну камеру на две, зритель не переживет скачков глубины. Все ваши текстуры нуждаются в редактировании, ведь светопоглощающие стереоочки накладывают ограничение на "темность" сцен и материалов, некоторые мрачные сцены просто не будут восприниматься в стерео. Что делать с глубиной резкости? Просчитать/cнять ее в кадре или обойтись без нее, полагаясь на то, что зрительский глаз сам физиологически создаст ее в процессе просмотра стереокадра? Как быть с просмотром материала, ведь стереоогрехи, незаметные на мониторе или в просмотровой комнате, могут бросаться в глаза на большом экране.

Не являются ли все эти технологические ограничения ограничениями творческой свободы? Время, наверное, покажет, но я не удивлюсь, если через три-четыре года, выходя из кинотеатра и потирая красные глазки, вы скажете: "А не посмотреть ли мне пару старых добрых плоских фильмов с безумным монтажом и шустрой камерой?"

ГОЛУБЯТНЯ: 377-я Диабетическая

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

Сегодня попробуем обойтись без культур-повидла. Не из вредности или желания поднасолить гуманитарно заточенным читателям либо потрафить гоблинам, а по чисто техническим обстоятельствам: состоялся зашкал софтверного потока. В смысле, что я ставлю и ставлю новые программы, тестирую их тестирую, а в "Голубятни" из-за плотности культур-повидла прорываются лишь жалкие ошметки отважных экспериментов. Так никуда не гадидзе. Будем исправлять.

Начну с самой приятной утилиты, которая попалась под руку за лето - HFS, персонального файл-сервера, созданного умелой рукой италийца Массимо Мелина. HFS - штука абсолютно бесплатная, абсолютно воздушная и абсолютно user-friendly. Последнее обстоятельство - безусловный карт-бланш не только в мир ламернутых пользователей, но и всех реалистичных пацанов, которые пришли в компьютер работать, а не цацку мусолить.

Иными словами, если вы не гоблин (для которого мусол цацки уже сам по себе является оплачиваемой работой!) и стремитесь получить эффективный результат вне контекста удовольствия от общения с компьютерными программами per se, то HFS - единственная альтернатива всему, что только существует на сегодняшний день в категории персональных файл-серверов. Поясню позицию на житейском примере. У меня есть некий информационный массив, который я хочу переслать другу. Речь идет не об одиночном файле, программе, фотографии, аудиотреке, а именно о массиве: музыкальном альбоме, большой фотосессии, набору программ, подборке текстов какого-то писателя.

Какие существуют способы эффективной во всех отношениях (по времени, по учебной курве, по скорости передачи данных и пр.) доставки массива? Первый - самый распространенный, самый дебильный и самый неэффективный: пакуем данные в архив, прикрепляем к электронному письму и отсылаем. Телодвижений куча, КПД вышибает слезу. Дело даже не в неудобстве упаковки данных на стадии отправки и потере времени на обратное действие на стадии получения информации моим корреспондентом. Дело в протоколе smtp, который минимум в полтора раза увеличивает размер передаваемой информации. То есть файл в 10 мегабайт передается по почте как файл в 15 мегабайт. Точно так же он и получается. В итоге 10 Мбайт превращаются в 20 Мбайт только по вине протокола передачи. Добавьте сюда ограничения, налагаемые на размер письма каждым вторым почтовым сервером (обычно те самые 10 Мбайт), из-за которых наш архив придется еще разбивать хорошо если на две части, и вы получите максимально неэффективный вариант решения поставленной задачи.

Поймите правильно, почта замечательно справляется с 99% повседневных потребностей по передаче данных, поскольку эти потребности в большинстве случаев задействуют весьма скромные объемы информации: статью послать в редакцию с тремя-четырьмя скриншотами, фотографию отправить родственникам с очередным маковым натюрмортом, ну вы понимаете. Стоит, однако, возникнуть диалогу в чате типа: "Как, ты не читала Акутагаву Рюноскэ?! Это невозможно! Это возмутительно! Это непростительно! Сиди смирно, никуда не дергайся - я сейчас тебе все пришлю!", как мигом возникают сложности: рассказов Акутагавы в моей электронной библиотеке 55 штук, аккурат на 8 мегов после упаковки в архив.

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

Второй вариант для транспортировки информационного массива - использование стационарных ftp-серверов, кои находятся в постоянном распоряжении у каждого уважающего себя обитателя виртуального мира. Скажем, если мне нужно передать жирную программу на 100 Мбайт либо выложить для читателей видеоролик с каким-нибудь своим интервью или передачей, я использую собственный сервер. Заливаю на него файл, а затем по почте пересылаю нужный линк. Равно и Антонелло выкладывает для меня все вкусное и свежее на свой ftp.ekozl.ru в специально созданную для меня директорию.

Подобный вариант хорош для обмена информацией с постоянными и - главное!
– продвинутыми корреспондентами, которым не нужно объяснять, что такое ftp-клиент, бинарная передача и прочие глупости. Единственный недостаток: на относительно узком канале (как, например, на моем теперешнем CDMA EV-DO без важного привеска в виде Revision A, который только и обеспечивает высокую скорость при передаче данных) приходится заливать файлы на ftp-сервер в прямом смысле слова часами.

Короче говоря, читатели уже поняли, что HFS представляется мне сегодня чуть ли не единственным максимально эффективным, максимально быстрым и максимально простым способом решения обозначенной выше задачи. HFS расшифровывается как HTTP File Server и представляет собой один-единственный исполняемый файл (hfs.exe) размером 550 килобайт, не требующий никакой установки. Кликаем мышью и сразу приступаем к делу. Философия HFS проста: запуская исполняемый файл, мы сразу же создаем на своем компьютере виртуальный веб-сервер и добавляем в него директорию или отдельный файл, доступ к которым желаем предоставить нашим корреспондентам. На все про все уходит секунд десять-пятнадцать. Еще пять секунд - на то, чтобы впечатать линк в окошко чата, и в следующее мгновение ваш собеседник уже закачивает напрямую с вашего компьютера весь информационный массив, который вы для него заготовили.

Сказка эта так эффективна, так удобна и так впечатляюща, что не могу удержаться, чтобы не продемонстрировать работу HFS на примере все того же Акутагавы Рюноскэ. Вот как это выглядит в три клика:

1) Запускаем HFS, кликаем правой кнопкой мыши в окне Virtual File System - выбираем опцию Add Folder From Disk (добавить папку на диске) - находим папку с книгами Рюноскэ. У нас два варианта добавления папки в виртуальную файловую систему: либо в реальном виде, либо в виде виртуального временного дублирования. Первый способ - самый быстрый, не требует дополнительного напряжения извилин, поэтому выбираем именно его.

2) Собственно - всё! В верхней строке экрана указан ваш IP-адрес, который достаточно скопировать в любой браузер, чтобы мгновенно соединиться с вашим файловым веб-сервером и приступить к загрузке. Не верите? Смотрите: открываем Firefox, вставляем в адресную строку и - voila результат. Кликаем на папке и получаем полный список рассказов писателя, доступных к скачиванию.

3) На этом можно было бы и закончить работу с HFS - достаточно передать другу адрес (в моем случае по аське, и закачка пошла. Описанная ниже процедура пригодится разве что пользователям, чья чувствительность к безопасности балансирует на грани разумного. Впрочем, возможна и рядовая ситуация, когда дополнительные изменения в настройке файл-сервера позволят вам спать спокойнее: например, вашему другу предстоит многочасовая закачка данных, которые вы ни при каких обстоятельствах не хотели бы доверить постороннему взгляду (фильм? фотографии?). В этом случае, дабы защититься от автоматического сканирования сети нехорошими хацкерами, достаточно поменять номер порта (по умолчанию http-сервер задействует стандартный порт 80) и/или ограничить доступ: выделяем папку в окне Virtual File System - правая кнопка мыши Restrict Access (ограничить доступ) - New Account (новый аккаунт) - логин и пароль.

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

На этом описание HFS для деловых пацанов завершаю, поскольку полученной информации более чем достаточно, чтобы немедленно приступить к эффективной работе. Софточервям (под стать Старому Голубятнику) и просто любителям поковыряться сообщу, что дополнительные возможности и настройки HFS просто невероятны: это и наложение дифференцированных фильтров на папки (чтобы определить, какие файлы можно скачивать, а какие нет), и создание файловых масок, и полный контроль за трафиком (ограничения по скорости, по объему, по числу одновременных соединений), и наложение запретов (bans), и защита от личинга, и работа с отпечатками (fingerprints), и использование службы динамических DNS (чтобы сообщать корреспондентам не временный IP-адрес вашего файл-сервера, а постоянное доменное имя, которые вы получаете, скажем, на сервисе DynDNS), и море еще всякого разного. Короче, не программа, а песня какая-то!