Описание вашей программы на сайте

Если вы разрабатываете программы и представляете их на своем сайте, то эта статья — для вас. В ней объясняется, каким образом можно наиболее эффективно сделать описание вашей программы в специальном файле, который называется PAD. Он размещается на сайте, и в него записывается вся информация, необходимая тем, кто хочет что-то узнать о вашем продукте. Если же вы являетесь опытным шароварщиком и уже пользуетесь PAD’ом, то вы безболезненно можете пропустить первую и вторую части этой заметки, но я весьма рекомендую пробежаться глазами по третьей — там описаны наиболее распространенные ошибки, связанные с созданием и использованием PAD-файлов. Причем ошибки эти встречаются очень часто, в том числе и у «маститых» программистов…

итак, часть первая. Что такое PAD?

PAD (Portable Application Description) — это XML-файл с описанием основных данных вашей программы. В PAD’е указываются данные об авторе программы, ее название, версия, адрес сайта, адреса файлов, поддерживаемые платформы и так далее — словом, вся та «фактологическая» информация, которая нужна любому, кто захочет что-то узнать (или рассказать) о вашем продукте. В частности, эта информация нужна программным архивам.

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

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

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

Часть вторая. Плюсы и минусы PAD’ов.

Формализованное описание программ позволяет значительно упростить процесс сабмита программ на архивы. Занесение основных данных в базу происходит автоматически и быстро, оставляя разработчику время на, собственно, программирование. Значительно снижается количество опечаток, некорректных данных о продуктах и прочих ошибок.

Намного упрощается и обновление данных о программе, которая уже опубликована в архиве. Некоторые софтовые сайты поддерживают pad-pulling, то есть регулярно перечитывают лежащий на вашем сайте PAD и при обнаружении изменений автоматически вносят их в базу (или же информируют редактора об обновлении программы). Таким образом, все, что требуется от автора — это обновить PAD-файл, лежащий у него на сайте, а все остальное произойдет само по себе. Если же сайт не перечитывает PAD автоматически, то все равно намного проще зайти на него и нажать кнопку «Обновить», чем заново вбивать все данные.

Таким образом, если вы не забываете обновлять PAD при выходе новых версий программы, то ее (программы) обновление на огромной куче архивов, разбросанных по всему м
иру, будет происходить в течение нескольких дней и не потребует от вас почти никаких усилий. Согласитесь, это весьма заметное преимущество!

Однако, как и у любого универсального описания, у PAD’ов есть и недостатки. Прежде всего, здесь можно указать на недостатки самого стандарта. Скажем, в PAD’е можно указать ссылки для скачивания вашей программы, но нельзя дать ссылки на дополнительные файлы (например, библиотеки, языковые модули). Нет возможности дать описания ссылкам. Нельзя указать разные файлы для разных языков. И многое-многое другое, что хотелось бы видеть. Частично это решается различными дополнениями, которые тоже можно найти на сайте ASP и подключить к PAD-генератору, но есть подозрение, что число таких подключаемых модулей будет все расти и расти…

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

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

Но, тем не менее, на сегодня PAD является очень удобным, хотя и несовершенным инструментом, значительно облегчающим жизнь как разработчикам программ, так и редакторам программных сайтов.

Часть третья. Типичные ошибки при работе с PAD’ами.

Первое и самое главное. идея PAD’а в том, что он лежит у вас на сайте, а софтовые архивы его периодически перечитывают. Поэтому не надо создавать PAD-файлы, содержащие в названии номер версии! Если адрес файла изменится (скажем, при выходе новой версии программы), то архив при попытке его перечитать наткнется на ошибку 404, и не исключено, что он просто удалит вашу программу из базы.

Не поможет здесь и указание в поле ссылки на «номерной» PAD-файл. Столкнувшись с тем, что «реальный» адрес (с которого был скачан PAD-файл) не совпадает с адресом, прописанным в самом PAD’е, архив просто заменит исходный адрес новым (резонно полагая, что PAD может быть куда-то скопирован, а вот информация в нем содержится корректная) и все — в качестве основного адреса прописался «номерной», и архив не замечает обновлений вашей программы (здесь я не беру в расчет то, что «правильные» архивы проверяют не только PAD, но и дату изменения и размер файлов программы и прочие тонкости).

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

То же самое относится и к скриншотам. Любимое развлечение авторов — указать вместо скриншота картинку коробки, логотип, иконку, сослаться на страничку или, как минимум, отредактировать скриншот, сделав его размером 120х80 пикселей. А зачем, спрашивается?.. Ведь скриншот нужен для того, чтобы ваш потенциальный покупатель мог познакомиться с интерфейсом программы! А что можно разглядеть на картинке размером с почтовую марку? Сделайте нормальный скриншот 800х600, подготовьте его для публикации в сети (практически любой граф
ический редактор умеет сжимать картинки) и положите у себя на сайте. А архивы эту картинку автоматически подгонят под свой дизайн. И все довольны…

Следующая очень типичная ошибка заключается в указании неправильной кодировки. В заголовке PAD файла прописано, в какой кодировке он записан, и сервер ориентируется именно на это указание при «расшифровке» файла. К сожалению, большинство программ для создания PAD’ов не знают о существовании KOI8-R или Windows-1251 и по умолчанию указывают либо ISO-8859-1, либо Windows-1252. Надо ли говорить, что русский, например, текст в этих кодировках выглядит нечитабельно?

Кстати, с кодировками связана и еще одна не то чтобы ошибка, но неприятность. Есть такая штука — UTF-8. В ней, в принципе, можно отлично записать русский (или какой-то еще) текст, но… большинство небольших сайтов написаны с использованием PHP. В том числе, PHP используется для разбора PAD’ов. В PHP есть даже функция для раскодирования UTF-8, но вот беда — раскодирует она в ISO-8859-1, заменяя все непонятные символы знаками вопроса, и русский снова становится нечитаемым (разумеется, если веб-мастер не потратил некоторое время на написание своего раскодировщика)…

Еще одна ошибка связана с использованием HTML-форматирования в описании программ. Это, правда, не совсем ошибка — явно оно не запрещено, но ни один нормальный веб-мастер не разрешит вставлять в свои страницы чужие тэги… Поэтому заботливо расставленные вами <font>, <p> и <a href=…> будут только портить вид страницы с описанием вашей программы, а оно вам надо? лучше грамотно разбить текст на абзацы и сделать его удобочитаемым.

Очень часто встречаются и ошибки, связанные с самим языком XML. Он, в отличие от HTML, значительно менее терпим к некорректному синтаксису и будет активно противиться вашим попыткам написать документ абы как. К сожалению, многие PAD-генераторы об этом не подозревают и забывают проверить корректность самого документа, проверяя только заполненность необходимых полей. Не стоит оставлять пустой первую строку и вставлять пробелы перед указанием <?xml…

Одним из хороших способов проверки корректности вашего PAD’а является банальное открытие его в браузере (только желательно не в Internet Explorer, который по своей привычке старается догадаться, что же пользователь имел в виду, а в более «строгом» — например, в Mozilla). использовать специализированные XML-валидаторы тут смысла не имеет, поскольку в полностью корректном XML-документе должны содержаться данные о типе документа, его соответствии тем или иным стандартам и прочая служебная информация, которая в PAD’е не нужна.

Ну и, наконец, то, без чего PAD’ы потеряют две трети своей функциональности — их надо обновлять! К сожалению, очень многие авторы об этом забывают — у себя на сайте, например, я даже был вынужден ввести дополнительную проверку и проверять — не просто не изменился ли номер версии, но и сравнивать, где версия старше — на «Листсофте» или в PAD’е… А ведь автору намного проще потратить лишние 10 минут на запись корректной информации в PAD, чем редактору софтового сайта ежедневно просматривать сотни сайтов программ, подозреваемых на обновление…

А раз уж мы заговорили об обновлениях, то стоит добавить пару слов и о версиях ваших программ. Для начала, указывая в PAD’е версию, не надо приписывать ее к названию программы и не надо писать «версия 1.23» — достаточно указать только «1.23». То, что это именно версия, понятно из того поля в котором значение записано и большинство сайтов автоматически добавляют слово «версия» или что-то аналогичное. Кстати, по поводу того, как стоит «нумеровать» релизы своих программ, попробуйте прочитать заметку «Новая версия» — может быть, найдете что-то полезное для себя…

Очень хочется надеяться, что эта статья хоть чуть-чуть снизит количество ежедневно отправляемых мне сервером сообщений об ошибках в проверенных PAD-файлах…