Совершенно очевидно, что подавляющее большинство посещаемых вами Web-сайтов доступно через Интернет, однако многие компании пришли к заключению, что и разработка приложений для внутренних сетей занимает немаловажное место. Эту идею можно развить дальше и разработать полнофункциональные Web-приложения, которые никогда не будут отправлять ни пакета данных через сетевой интерфейс. Опытные Web-разработчики иногда затрачивают большие усилия на изучение какого-нибудь GUI-инструментария, хотя то, что действительно нужно в их ситуации - это простой CGI-скрипт.
Во всяком случае, Web-приложение, предназначенное для работы только в локальной сети, гораздо проще приложения для универсального применения. Вы легко сможете задать требования для браузера, а производительность сервера, скорее всего, не будет большой проблемой. Простые приложения, использующие стандартные виджеты CGI-форм и им подобные, можно написать за гораздо меньшее время, чем потребовалось бы на разработку самодостаточных приложений. Приложения, построенные вокруг обработки форм или данных, часто являются отличными кандидатами на реализацию в качестве обычных Web-сервисов.
Во многих случаях такое специальное приложение может обеспечить изящное и простое решение определённой узкой задачи. Однажды я написал утилиту для просмотра изображений, которая делала лишь одну вещь: просматривала директорию с изображениями с фотоаппарата и давала мне возможность сортировать картинки по категориям. Программа занимала, возможно, лишь двадцать строчек на Perl, а в результате работала гораздо быстрее, чем более универсальное решение, не говоря уже о времени, которое потребовалось бы на написание приложения с графическим интерфейсом, выполняющего эту же самую функцию.
Итак, чем же нам поможет Web-браузер?
Можно задать совершенно резонный вопрос: ну и что? Что умеет Web-браузер, чего не умеют другие приложения? Ответ очевиден: ничего. Но тогда что же можно написать на высокоуровневых языках, чего нельзя выполнить в машинных кодах? Опять же, ничего. Преимущество при использовании Web-браузера в качестве интерфейса состоит в том, что всё жёсткое кодирование уже выполнено. Не нужно отслеживать события изменения размеров или развёртывания окна или события меню. Всё, что нужно сделать, это прочитать фрагмент данных с выражением запроса и обработать его.
Потенциальная слабость разработки Web-основанных приложений - недостаточные возможности по управлению их внешним видом. На самом деле, это не такой уж и недостаток. Если вы пытаетесь максимально ускорить разработку приложения, вам точно не стоит тратить много времени на возню с внешним видом. На какой бы платформе вы не работали, пользователям будут знакомы кнопки и текстовые виджеты Web-браузера. Это действительно весьма полезная возможность.
Web-браузер делает ещё одну очень полезную вещь: он предоставляет множество настроек и предпочтений, о которых вам не нужно беспокоиться. Пользователь может изменять размер шрифта во время работы. Аналогично, если сгенерированные выходные данные представляются в простой и аккуратной HTML-форме, их можно легко и быстро вывести на печать. Многие функции, которые в ином случае вам пришлось бы реализовывать самостоятельно (например, сохранение выходных данных в файл, вывод выходных данных на печать, изменение размеров окон), уже реализованы.
Однопользовательская архитектура
Хотя может показаться, что однопользовательское окружение полностью устраняет многие проблемы, связанные с разработкой приложений, это не совсем так. Недавно я написал систему для работы с массивом документов как Web-приложение. Поскольку я спроектировал её для одновременной работы максимум с одним пользователем, я подумал, что смогу обойтись без объёмного кода, занимающегося блокировкой файлов, который в ином случае был бы необходим. Я ошибался. В пользовательском интерфейсе использовались фреймы, и одна из программ проверки работоспособности, запущенных моим оконным менеджером, могла зависнуть намертво, если другая программа изменяла базу данных, пока та была запущена. Браузер часто начинал обрабатывать оба запроса одновременно.
При использовании локального сервера отпадают проблемы с пропускной способностью сети; даже то, что может вызвать проблемы при работе через локальную сеть, будет нормально функционировать на локальной машине, хотя большие файлы по-прежнему будут тормозить браузер или приводить к его зависанию.
Сетевая безопасность
Если вы разрабатываете приложение, которое будет запускаться на локальном Web-сервере, задайтесь вопросом, что произойдёт, когда кто-то другой будет обращаться к этому приложению по сети. В идеале, убедитесь, что локальное приложение доступно только через внутреннюю компьютерную сеть. Если сделать этого нельзя, потребуются специальные меры безопасности. Возможно, будет достаточно просто указать вашему приложению отвергать все соединения с любых адресов кроме 127.0.0.1, что гораздо безопаснее, чем использовать пароли.
Возможно, разумнее будет просто выбрать альтернативный номер порта, организовав для приложения выделенный сервер. С помощью командной строки UNIX® потребуется несколько минут, чтобы настроить личную копию Apache для работы через порт 8880, и в результате вы получите полный контроль над функциями и настройками сервера. Кроме того, серверная часть приложения будет выполняться с вашими обычными привилегиями, следовательно, не нужно делать важные файлы доступными для записи, что, несомненно, большой плюс.
Управление данными
Для традиционного Web-приложения использование сервера баз данных в значительной степени упрощает разработку, так как механизм базы данный - в силу того, что это отдельный сервер - обеспечивает большую часть необходимой сериализации и блокировки, а обеспечить остальное довольно просто. Для однопользовательского приложения, которое будет запускаться на одном компьютере, такая схема избыточна и, возможно, реализовывать её не стоит. Локальному приложению всё это не нужно, зато в нём имеет смысл применить простой и легко перемещаемый файл данных. Куда бы я не путешествовал, я всегда синхронизировал файл данных моего приложения для работы с массивом документов между ноутбуком и десктопом. Это была несложная задача, поскольку я использовал файл Berkeley DB.
Формат Berkeley DB предлагает довольно простое решение, легко реализуемое на многих языках. Так как сервер баз данных не используется, это не лучший выбор для приложения, одновременно работающего с множеством пользователей; в целях безопасности необходимо заблокировать базу данных, выполнить нужные операции, а затем разблокировать её. С другой стороны, поскольку сервера БД нет, такое решение подходит для программы, очень редко обслуживающей несколько пользователей одновременно.
Вот пример кода на Perl, подключающего базу данных Berkeley DB (с блокировкой):
Листинг 1: Присоединение базы данных
my %db;
open(DBFILE, '+file.db');
flock(DBFILE, LOCK_EX);
$dbhandle = tie %db, 'DB_File', 'file.db', O_CREAT/O_RDWR, 0666, $DB_HASH;
|
После выполнения этого кода можно получить доступ к базе данных напрямую, как к стандартному хэшу Perl:
Листинг 2: Использование базы данных
$db{user} = "me";
print "<p>User: $db{user}</p>\n";
|
Можно также использовать объект dbhandle для выполнения операций над базой данных:
Листинг 3: Использование database handle
$dbhandle->del("user");
|
После выполнения всех этих действий работа действительно закончена. То есть, когда ваша программа завершает работу, блокировка автоматически снимается. Блокировка с помощью flock() - всего лишь рекомендация. Она не помешает другим программам осуществлять запись в файл, если они её не используют. Если ваша программа реализована в виде нескольких взаимосвязанных программ, добавьте код блокировки во все из них, или ещё лучше, поместите его в модуль общего пользования. Таким образом, эта необязательная блокировка, тем не менее, обеспечивает необходимый результат: это надёжная гарантия, что файлы данных будут изменяться только одной программой одновременно.
Некоторые приложения будут прекрасно работать с обычными файлами, например с CSV-файлами или просто текстовыми файлами с пустыми полями. Другим может потребоваться полнофункциональная SQL-база данных. Вы не обязаны применять решения "корпоративного класса" в небольших приложениях, которые должны быстро и легко выполнять поставленную задачу. Лучше сконцентрируйте усилия на устранении ошибок и создании удобных функций. При этом если вам нужна реляционная база данных - используйте её.
Виджеты интерфейса
Достаточно хорошие приложения получаются при помощи форм, содержащих множество кнопок. Если имеются метаданные или контекст, которые необходимо передавать от страницы к странице, используйте скрытые поля форм; проблемы безопасности, с которыми вы можете столкнуться (пользователи могут обходить их) в данном случае не так уж серьёзны. Кнопки с изображениями можно использовать во многих целях, хотя в этом случае вам придётся заняться разработкой рисунков. Если вы не хотите этого делать, создайте кнопку с альтернативным текстом, указав для изображения несуществующий URL:
Листинг 4: Кнопка, содержащая только текст, без GUI-виджетов:
print $q->image_button(-name => "sort",
-value => "$name",
-src => "/nonexistant",
-alt => $label);
|
Это может показаться нелепым по сравнению с более простой альтернативой использования гиперссылки, но в своей полной форме соответствующая ссылка href=... может быть довольно длинной, и её будет невозможно вычислить заранее, если кнопка отправляет форму. Это очень грубый трюк, но он работает.
Одна задача - одно приложение
Написав пару небольших Web-приложений для запуска на локальной машине, вы быстро заметите следующее: такие приложения часто создаются очень быстро, даже с учётом времени на отладку, а работают они значительно эффективней по сравнению с выполнением стандартных задач вручную. Выигрыш в эффективности, получаемый при упрощении долгих и скучных процедур, с лихвой окупает время на разработку такого приложения, тем более что этот процесс может занять лишь несколько минут.
В стандартной CGI-библиотеке Perl имеется множество полезных базовых рабочих инструментов. Поэкспериментировав с ней пару часов и привыкнув к её чрезвычайно гибкому и богатому набору функций, вы сможете написать множество разнообразных приложений, не прилагая к этому больших усилий. С помощью несложной скриптовой системы можно удобно и эффективно использовать скрипты командной строки, решающие одну определённую задачу. Простые CGI-скрипты делают то же самое в отношении разнообразных программ с графическим интерфейсом. Посвятив им один день, вы быстро обнаружите, что можете с лёгкостью выполнять десятки задач, о программах для решения которых вы так мечтали.
Масштабирование
К сожалению, типичная практика такова: сначала пишут небольшое простое приложение под конкретную задачу, предназначенное, как полагают, только для локального использования, а затем обнаруживается, что существует очевидная причина расширить это приложение для большей аудитории.
Даже если приложение предназначено только для локального использования, пишите понятный код, оснащайте программу средствами контроля и сохраняйте отладочные выходные данные. Хороший код с удобной поддержкой отладки очень быстро окупается невысокими затратами на сопровождение. Если с самого начала в программе была предусмотрена возможность переработки для более широкой (множественное число!) аудитории, выгода будет ещё больше.
Значительную часть работы может составить рефакторинг, но это не так плохо, как вам, вероятно, кажется. По большей части вам придётся заниматься масштабированием самой серверной базы данных или оптимизацией обработки файлов, чтобы обеспечить лучшую и более интеллектуальную блокировку. Если ваша программа занимается обработкой файлов, возможно, стоит написать небольшой сервер, выполняющий эти операции атомарно, обеспечивая таким образом сериализацию. Также для такого сервера будет разумно обрабатывать одного клиента за раз, поскольку отдельные скрипты выполняются быстро.
Главное, на что вам нужно обратить внимание - это программа, делающая предположения о внутреннем состоянии. Например, в программе-классификаторе документов совершенно очевидной представляется функция, отображающая для пользователя "следующий файл", а затем заносящая его в определённую категорию. Если работают два пользователя, необходимо отслеживать, какой файл обрабатывает каждый из них. Также нужен какой-то механизм обработки пограничных ситуаций. Например, если кто-нибудь откроет приложение, а затем в какой-то момент отойдёт, то необходимо разрешить другому пользователю просмотреть этот файл. Иногда для этого потребуется существенная переработка всей серверной части, однако в целом будет довольно просто обеспечить стабильность на стороне клиента.