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

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

Начну с самой приятной утилиты, которая попалась под руку за лето - 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 (добавить папку на диске) - находим папку с книгами Рюноскэ. У нас два варианта добавления папки в виртуальную файловую систему: либо в реальном виде, либо в виде виртуального временного дублирования. Первый способ - самый быстрый, не требует дополнительного напряжения извилин, поэтому выбираем именно его.