Сочинение локальных веб-приложений будет мгновенным, легким и действенным методом решения некоторых задач во внешней сети. Выясните, почему в отдельных случаях браузер предлагает самый лучший внешний вид сравнивая с GUI-приложением, а простеньким и наиболее изысканным решением будет CGI-скрипт.

Абсолютно логично, что большинство популярных вами сайтов доступно через сеть-интернет, но очень многие компании пришли к решению, что и разработка дополнений для внешних сетей занимает важное место. Данную мысль можно развить далее и спроектировать полнофункциональные веб-приложения, которые никогда в жизни не будут посылать ни пакета данных через сетевой внешний вид. Квалифицированные веб-разработчики время от времени тратят огромные старания на исследование какого-либо GUI-инструментария, впрочем то, что на самом деле нужно в их обстановки — это простой CGI-скрипт.

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

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

Так вот, чем все-таки нам сможет помочь браузер? Можно задать абсолютно наглядный вопрос: ну и что? Что может браузер, чего не могут другие дополнения? Ответ предельно ясен: ничего. Однако тогда что можно написать на высокоуровневых языках, чего нельзя осуществить в механических кодах? Опять таки, ничего. Преимущество при применении веб- интернет-браузера в роли внешнего вида заключается в том, что все твердое кодирование сделано. Не нужно выслеживать мероприятия перемены габаритов либо развертывания окна либо мероприятия меню. Все, что нужно сделать, это прочесть кусок данных с запросом и обработать его.

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

Браузер делает вторую весьма необходимую вещь: он предлагает большое количество опций и предпочтений, о которых вам не нужно волноваться. Клиент может менять объем шрифта во время действия. Подобно, если сгенерированные выходные данные представляются в простой и элегантной HTML-форме, их можно без проблем и оперативно вывести на печать. Очень многие функции, которые в другом случае вам понадобилось бы осуществлять самостоятельно (к примеру, сбережение выходных данных в документ, вывод выходных данных на печать, изменение габаритов окошек), выполнены. Кванториум и все о нем ищите на сайте hm.codame.online.

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

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

Если вы разрабатываете приложение, которое будет запускаться на локальном веб-сервере, задайтесь вопросом, что случится, когда кто-то другой будет направляться к данному дополнению по сети. Если рассматривать идеальный вариант, удостоверьтесь, что локальное приложение доступно лишь через внешнюю компьютерную сеть. Если сделать этого нельзя, понадобятся особые меры предосторожности. Вероятно, будет довольно легко показать вашему дополнению отторгать все объединения с любых адресов помимо 127.0.0.1, что намного безопаснее, чем использовать пароли.

Вероятно, умнее будет просто выбрать другой номер порта, организовав для дополнения выделенный сервер. При помощи командной строки UNIX® понадобится 5 минут, чтобы настроить собственную копию Apache для работы через шлюз 8880, и в итоге вам предоставят общий контроль над функциями и опциями сервера. Также, серверная часть дополнения будет производиться с вашими стандартными преимуществами, значит, не нужно делать значительные документы подходящими для записи, что, очевидно, большой плюс.

Для классического веб-приложения применение сервера баз данных сильно упрощает подготовку, в связи с тем что механизм базы данных — в силу того, что это автономный сервер — гарантирует огромную часть нужной сериализации и блокады, а обеспечить прочее достаточно легко. Для однопользовательского дополнения, которое будет запускаться на одном ПК, такая схема сверхизбыточна и, вероятно, осуществлять ее не следует. Локальному дополнению это не нужно, но несмотря на это в нем имеет резон использовать простой и без проблем переволакиваемый документ данных. В какую бы сторону я не странствовал, я всегда синхронизировал документ данных моего дополнения для работы с массивом документов между компьютером и десктопом. Это была элементарная цель, так как я применял документ Berkeley DB.

Формат Berkeley DB предлагает достаточно элементарное решение, без проблем реализуемое на многих языках. В связи с тем что сервер баз данных не применяется, это далеко не самый лучший выбор для дополнения, синхронно работающего с обилием клиентов; для обеспечения безопасности нужно блокировать информационную базу, осуществить необходимые процедуры, а потом деблокировать ее. С иной стороны, так как сервера БД нет, такое решение подходит для платформы, крайне редко обслуживающей несколько клиентов синхронно.

После проведения всех этих действий работа на самом деле завершена. Другими словами, когда ваша программа заканчивает работу, блокада автоматом снимается. Блокада при помощи flock() — лишь рекомендация. Она не навредит иным платформам производить запись в документ, если они ее не применяют. Если ваша программа выполнена в качестве нескольких взаимозависимых программ, добавьте код блокады во все из них, либо еще лучше, расположите его в модуль совместного использования. Так что, данная добровольная блокада, все-таки, гарантирует нужный итог: это качественная гарантия, что документы данных будут изменяться лишь одной платформой синхронно.

Определенные дополнения будут отлично работать со стандартными документами, к примеру с CSV-файлами либо просто текстовыми документами с пустейшими полями. Иным может понадобиться полнофункциональная SQL-база данных. Вы не должны использовать решения «коллективного класса» в незначительных дополнениях, которые должны оперативно и без проблем делать намеченную цель. Лучше сосредоточьте старания на устранении ошибок и разработке комфортных функций. При этом если вам необходима реляционная база данных — применяйте ее.

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

Это может показаться вздорным сравнивая с не менее простой заменой использования гиперссылки, однако в собственной абсолютной фигуре аналогичная сноска href=… вполне может быть достаточно короткой, и ее будет нельзя определить загодя, если клавиша посылает фигуру. Это весьма топорный трюк, однако он работает.

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

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

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

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

Главное, на что вам нужно обратить свое внимание — это программа, делающая мнения о внутреннем состоянии. К примеру, в программе-классификаторе документов абсолютно тривиальной кажется функция, отображающая для клиента «следующий документ», а потом заносящая его в установленную группу. Если работают 2 клиента, нужно выслеживать, какой документ обрабатывает любой из них. Также необходим какой-нибудь механизм обработки соседних ситуаций. К примеру, если кто-либо раскроет приложение, а потом в какой-нибудь момент отойдет, то нужно разрешить другому клиенту посмотреть данный документ. Время от времени для этого понадобится значительная переделка всей серверной части, но в общем будет достаточно легко обеспечить надежность на стороне заказчика.