Описан встроенный язык программирования пакета «1С: Предприятие», методы настройки и конфигурирования системы с его помощью. Дополнительно содержит необходимый минимум сведений об объектно-ориентированном программировании и теории баз данных.
Книга написана доступным языком, изложение материала основано на актуальных и полезных примерах. Рассмотрен полный спектр задач, встречающихся на практике: от внесения небольших изменений до создания собственной конфигурации.
Издание предназначено не только для программистов или системных администраторов, но и бухгалтеров, экономистов, менеджеров и других специалистов, планирующих вносить изменения в конфигурацию без посторонней помощи.
Книга ориентирована как на обычных пользователей Интернета, которым нужно в кратчайшие сроки создать свой сайт, так и на разработчиков, которые заинтересованы в построении собственной системы управления сайтом. Рассмотрены три уже готовые системы управления сайтом — Joomla!, Slaed, PHP-Nuke. С позиции пользователя описывается, как установить, настроить, разработать графическую тему и расширить возможности каждой системы. Для разработчиков описано программирование собственных расширений для рассмотренных движков, а также создание собственной системы управления сайтом. Отдельное внимание уделяется защите от взлома разрабатываемой системы, а также интеграции с популярным форумом phpBB из файла задания.
В этой книге предпринимается попытка проследить пути компьютерного андеграунда и воссоздать, основываясь на реальных фактах, квртану киберпанк-культуры. Это причудливая смесь современнейших технических знаний с моралью изгоев. Как правило, в книгах о киберпанках рассказывается о талантливых компьютерщиках-бунтарях, отказывающихся повиноватьсяустановленному порядку, причем события обычно разворачиваются на фоне некоего смутно обрисованного будущего, в мире, где царствуют высокие технологии, а гигантские города перенаселены и приходят в упадок. В этом мире всё решает безграничная мощь компьютеров. Обширные компьютерные сети образуют новую вселенную, в неизведанных пространствах которой обитают электронные демоны. По лабиринтам этих сетей рыщут перехватчики информации. Многие из них живут тем, что скупают, перепродают или просто воруют информацию - валюту электронного будущего. Таким киберпанком считался, например, телевизионный персонаж Макс Хэдрум, который будто бы обитал в дебрях информационных сетей масс-медиа и время от временило собственной воле появлялся оттуда на экранах компьютеров и телевизоров. Таким был снятый в 1982 году фильм "Бегущий по лезвию бритвы", где показан мрачный и жутковатый мир будущего, в котором техника одержала полную и окончательную победу над человеком.
Первые замыслы к созданию этой книги появились у нас, когда мы стали замечать, что люди пользуются компьютерами уже не так, как в прежние годы. Обнаружились предвестники киберпанк-поколения-молодые парни, одержимые компьютерами и компьютерными сетями, причем эта их одержимость уже начала переходить пределы того, что компьютерщики-профессиоиалы считали допустимым с точки зрения морали, а юристы - с точки зрения закона. Этих парней стали называть хакерами. И обществу стало казаться, что от них исходит какая-то не совсем понятная опасность. Вот мы и попытались рассказать в этой книге, кто такие хакеры и что движет их поступками.
В книге три повести. Кевин Митник полностью соответствовал представлениям о "классическом" хакере. Говорили, что он способен прослушивать телефоны, подтасовывать данные о платежеспособности на случай проверок и контролировать работу компьютеров на большом расстоянии. Сам себя он считал одаренным энтузиастом, покинувшим сообщество своих бывших собратьев-компьютерщиков. Кевин причинил немало неприятностей одной очень известной компьютерной фирме. Однако в конце концов он пал жертвой собственного высокомерия и заносчивости.
В 80-е годы компьютерщики создали свою особую культуру, такую же универсальную, какой была молодежная культура 60-х. Юному берлинцу, называвшему себя Пенго, мир компьютерных чудес открылся уже в подростковом возрасте. Его родители ничего не смыслили в вычислительной технике, и поэтому никакие опасения не приходили им в голову, когда они видели сына, часами просиживающего перед монитором. Чтобы воплотить свои недозволенные фантазии, Пенго примкнул к группировке, которая стала не без выгоды продавать результаты его авантюр в международных компьютерных сетях советской разведке.
Можно сказать, что современная корпорация буквально "пропитана" данными. Они повсюду и, более того, очень часто одни и те же данные могут находиться в нескольких местах. Корпорация должна иметь возможность идентифицировать источник, происхождение, семантику и пути доступа к данным. Метаданные или, как их обычно называют, "данные о данных", являются ключом для получения этой информации. Но, как это ни удивительно, у большинства корпораций нет отчетливой стратегии относительно метаданных. Различные подразделения организации используют разные наборы инструментов для поддержки своих данных.
Каждому такому набору соответствуют определенные метаданные. Поэтому картина, типичная для многих корпораций, - это так называемые "острова метаданных", т.е. некоторые объемы информации, которые невозможно связать друг с другом. Для решения этой проблемы некоторые организации начинают крупные проекты по интеграции метаданных, тратя на это значительные средства и время. Но, к сожалению, в большинстве проектов отсутствует структурный подход, поэтому временные и финансовые затраты не окупаются.
В предлагаемой статье обсуждаются подходы к управлению метаданными, в том числе то, какие метаданные необходимо собирать, как их можно моделировать, как создать требуемое архитектурное решение и как обеспечить простоту поддержки метаданных в долгосрочной перспективе. Большинство этих подходов уже существуют в той или иной форме в различных организациях. В данной статье сделана попытка собрать и обобщить имеющийся опыт.
Классификация метаданных
На самом высоком уровне метаданные могут быть разделены на две категории:
Элементы общих метаданных должны иметь совместные (непротиворечивые) определения и семантику в масштабах всей корпорации. Например, определение понятия "клиент" должно быть единым для всей компании.
Метаданные могут быть классифицированы и по другим параметрам:
Метаданные бизнеса включают определения объектов, относящихся к корпоративным пользователям, логическим картам данных и словарям Хранилищ данных. Технические метаданные включают данные о физических объектах: названия таблиц и столбцов, ограничения и правила физического преобразования между различными зонами. В метаданных процессов отражается статистическая информация о различных процессах: статистика загруженности, информация о календарном планировании и обработка исключений.
Создание решения для управления метаданными
Для создания успешного решения по управлению корпоративными метаданными автор рекомендует следовать определенной последовательности шагов:
1. собрать все требования, предъявляемые к метаданным;
2. выбрать соответствующую модель метаданных;
3. определить общие подходы к архитектуре;
4. внедрить выбранное решение и осуществлять его поддержку.
Сбор требований, предъявляемых к метаданным
Определение требований, предъявляемых к метаданным, может оказаться непростой задачей. Ключевые стороны, которым могут быть нужны метаданные, разнообразны и пространственно разобщены. Это могут быть как конечные пользователи или аналитики, так и приложения или наборы инструментов. Процесс сбора стандартных требований не должен слишком расплываться. Автор предлагает следующий подход, учитывающий специфическую природу метаданных:
* определение ключевых сторон для каждого элемента метаданных;
* отнесение каждого элемента метаданных к определенной категории: метаданным бизнеса, техническим или метаданным процессов;
* отнесение каждого элемента метаданных к категории общих или уникальных на основе их использования в тех или иных процессах.
Следующий шаг - идентификация источника элемента метаданных. Обычно они называются "официальными метаданными" или "метаданными записи"1. Метаданные записи указывают на официальную версию определенного элемента для какого-либо события, в котором может быть несколько источников одних и тех же данных. Для того чтобы назвать определенный элемент метаданных официальным, важно понимать различные процессы, которые могут привести к созданию этого элемента. Эта информация помогает определить официальный источник метаданных. Например, компания розничной торговли создает корпоративное Хранилище данных, при этом элементы, содержащие информацию о клиентах, появляются в нескольких местах, таких как Хранилище данных о потребителях, система управления отношениями с клиентами (Customer Relationship Management, сокр. CRM) и система сбыта. При этом важно проводить анализ надежности и полноты каждого источника и оценивать, какие именно определения могут использоваться в качестве официальной версии. В данном случае уже может существовать Хранилище данных о потребителях, определяющее соответствующее измерение, поэтому можно будет считать словарь данных этого Хранилища официальными метаданными записей. После того как этот процесс будет закончен для всех элементов метаданных, можно будет сказать, что организация требований к метаданным завершена.
Выбор метамодели
Следующий шаг после формализации требований к метаданным - создание модели. Моделирование метаданных важно, поскольку оно может стать элементом, который используется во всей корпорации. Существует несколько способов выбора модели метаданных:
* создание специальной модели данных для работы с метаданными;
* использование имеющихся стандартных моделей;
* оснащение доступного репозитория метаданных инструментами, позволяющими использовать его как источник интеграции.
Для создания специальной модели метаданных важно иметь корректные определения элементов, их атрибутов и связей с другими элементами. Такая модель может быть объектно-ориентированной или моделью типа объект-отношение. Что касается стандартных моделей, то тут существует два варианта: модель открытой информации (Open Information Model, сокр. OIM) и общая метамодель Хранилища данных (Common Warehouse Meta-Model, сокр. CWM). CWM описывает обмен метаданными между Хранилищами данных, средствами Business Intelligence и управления знаниями и портальными технологиями. Согласно компании Meta Data Coalition, OIM - это набор спецификаций метаданных для облегчения их совместного и многократного использования в области разработки приложений и Хранилищ данных. OIM описывается с помощью универсального языка моделирования (Unified Modeling Language, сокр. UML) и организуется по предметным областям, которые могут быть легко использованы и при необходимости расширены. Эта модель данных основана на отраслевых стандартах, таких как UML, XML и SQL.
Выбор подходящей метамодели является непростой задачей. Хотя специальные модели бывают гораздо более гибкими, создание надежной модели на корпоративном уровне и ее долгосрочная поддержка могут оказаться довольно обременительными. Для решения такой задачи нужен хорошо продуманный план. С другой стороны, стандартные модели довольно широкие: они охватывают большинство требований, предъявляемых на корпоративном уровне. Но настройка таких моделей под специфические нужды корпорации может оказаться проблематичной. Для тех корпораций, где существуют наборы инструментов и связанные с ними метаданные, хорошим решением будет использование метамоделей от любого поставщика. При этом, безусловно, понадобятся существенные интеграционные усилия. С другой стороны, если корпорация только начинает работать с метаданными и у нее нет несовместимых наборов инструментов, то хорошим решением может быть создание собственной специальной метамодели.
После завершения моделирования метаданных важно определить репозиторий для хранения данных. Это может быть реляционное или объектно-ориентированное Хранилище.
[pagebreak]
Определение архитектуры высокого уровня
Для внедрения решений по работе с метаданными существует целый ряд архитектурных возможностей. Одно из решений - централизованный репозиторий, где хранятся все метаданные.
Основные элементы метаданных, которые будут храниться в таком центральном репозитории, - это метаданные приложений, систем управления базами данных, бизнеса и метаданные, связанные с различными процессами. Создание и модификация элементов метаданных должны осуществляться с помощью общего интерфейса. Для такого решения можно разработать специальную метамодель или использовать одну из стандартных. Данная архитектура имеет несколько преимуществ:
* сравнительно простая поддержка метаданных;
* упрощенные процедуры взаимодействия между компонентами;
* простые процедуры подготовки отчетности.
Некоторые корпорации пытаются создавать очень небольшие решения для работы с метаданными. Это означает, что каждое подразделение организации конструирует свое собственное решение.
Для облегчения обмена метаданными в качестве основы для их передачи используется XML. Каждое приложение, система управления базами данных или инструмент вступает в контакт с репозиторием с помощью XML. Парсер репозитория преобразует формат XML в формат метамодели и обновляет содержимое репозитория.
Наконец, третье архитектурное решение известно под названием распределенной архитектуры. Это тот случай, когда корпорация уже потратила значительное количество ресурсов на создание локального решения для работы с метаданными, а интеграция в масштабах всей корпорации оказывается слишком дорогостоящей. В результате локальное решение продолжает существовать, а в тех случаях, когда это оправдано и выгодно, происходит совместное пользование метаданными из нескольких источников.
Внедрение и поддержка решения для работы с метаданными
После завершения разработки архитектуры и выбора метамоделей можно приступать к внедрению решения. При этом надо иметь в виду следующее:
1. природу репозитория метаданных (реляционная база данных, система файлов, объектно-ориентированная база данных или репозиторий XML);
2. вопросы безопасности репозитория метаданных (кто управляет репозиторием; кто имеет право читать информацию репозитория или обновлять ее);
3. механизмы создания, чтения и добавления компонентов метаданных;
4. инфраструктуру отчетности для метаданных.
После разработки плана и обеспечения соответствующих инструментальных средств можно приступать к внедрению решения для работы с метаданными.
Но собственно внедрение еще не обеспечивает решения всех проблем. Важно обеспечить достаточно продолжительное функционирование созданной системы и ее соответствующее обслуживание. Одно из основных требований при этом - правильное распределение ролей и ответственности в корпорации.
После распределения ролей и ответственности необходимо создать процесс, определяющий жизненный цикл метаданных. Этот цикл задает следующие параметры: кто создает метаданные, кто использует их компоненты и кто отвечает за поддержку этих компонентов. Один из главных критериев долгосрочного успеха решения для работы с метаданными - это его расширяемость. Архитектура должна позволять легко добавлять новые требования к метаданным. Для этого необходим специальный процесс, обеспечивающий добавление новой информации о метаданных. При этом необходимо получить ответы на следующие важные вопросы:
* нужно ли хранить новые метаданные в общем репозитории (если таковой имеется);
* каковы методы доступа к элементам этих метаданных (только чтение или чтение и запись);
* являются ли эти метаданные уникальными или будут использоваться несколькими приложениями.
На основе ответов на эти вопросы принимаются соответствующие решения о хранении компонентов новых метаданных.
Пример решения для работы с метаданными
В качестве примера автор приводит розничную компанию, имеющую несколько Хранилищ данных для обеспечения различных видов бизнес-отчетности. Компания имеет Хранилище для составления отчетов по каналам поставок, Хранилище для CRM, Хранилище для данных о продажах и отдельное Хранилище для финансовой информации. Компания хочет создать единое корпоративное Хранилище данных с помощью консолидации информации в масштабах всей организации. Это хранилище будет центральным репозиторием для всех корпоративных данных, а отдельные подразделения будут создавать себе витрины данных на его основе. В процессе реализации этого проекта пришло понимание того, что также необходимо выработать стратегию консолидации метаданных.
Для этого можно использовать подход, описанный выше, который включает четыре основных действия. Первое действие - определение требований к метаданным. Этот процесс включает идентификацию заинтересованных сторон и классификацию метаданных. Поскольку это проект консолидации Хранилища данных, то типы метаданных будут достаточно простыми. Основные элементы - это некоторые корпоративные измерения, которые должны быть определены, и корпоративные факты. Оба этих элемента связаны с одними и теми же метаданными бизнеса. Следующий набор метаданных - это список таблиц и граф, использующих данные измерения и факты, т.е. это технические метаданные. Наконец, для документирования процессов ETL (extraction, transformation, loading - извлечение, преобразование и загрузка) и создания витрин данных необходима информация о тех шагах, из которых они состоят, т.е. это метаданные о процессах.
Для этих метаданных заинтересованными сторонами являются те, кто занимаются моделированием данных, а также разработчики ETL, витрин данных и отчетов. Помимо этого, такие метаданные нужны для работы с инструментами ETL и отчетности. Для консолидации метаданных требуются все элементы метаданных, их классификация, а также информация о том, кто и какие именно данные использует.
Следующий шаг - моделирование решения для работы с метаданными. В организации было принято решение создать свою метамодель, которая бы учитывала требования к модели данных, процессу ETL, витринам данных и инструментам отчетности.
После создания метамодели необходимо определить общую архитектуру. Было решено создать единый репозиторий для метаданных и определить процесс, который обеспечит его наполнение из всех систем. Например, после определения измерений и фактов метаданные экспортируются из инструментов моделирования данных и сохраняются в репозитории. Информация о процессах ETL создается вручную и также сохраняется в репозитории. Репозиторий инструментов отчетности наполняется с помощью заранее определенной технологии. Для выполнения требований отчетности, предъявляемых к метаданным, была создана система отчетности на основе интернета, которая создает запросы к репозиторию для получения информации.
После создания такого решения консолидация метаданных может считаться практически законченной. Следующая проблема - обеспечение долговременной работы данного решения. Например, как должен обрабатываться новый элемент или измерение, созданные в модели данных? Как вносится информация о новом процессе ETL или новом отчете? Все это определяется процессом поддержки метаданных. Для моделей данных периодически используется процесс синхронизации репозиториев инструментов и метаданных. Для ETL и отчетности существуют аналогичные процессы.
Заключение
Важность метаданных для корпораций уже общепризнанна. При работе с метаданными очень важно предварительно выработать соответствующую стратегию. Также важно понимать, что метаданные не являются универсальным средством для управления данными. Это мощное средство, которое может существенно улучшить качество анализа данных в корпорации, тем самым способствуя росту эффективности ее работы. При этом важно не распыляться в поисках абсолютно совершенного решения, а создавать решение, наиболее оптимальное для конкретного бизнеса.
1.Защита информации и криптография - близнецы-братья
2.Во всем виноваты хакеры
3.Абсолютная защита
МИФ ПЕРВЫЙ.
"Защита информации и криптография - близнецы-братья"
Этот миф, видимо, связан с тем, что с самого начала своего развития системы информационной безопасности разрабатывались для военных ведомств. Разглашение такой информации могла привести к огромным жертвам, в том числе и человеческим. Поэтому конфиденциальности (т.е. неразглашению информации) в первых системах безопасности уделялось особое внимание. Очевидно, что надежно защитить сообщения и данные от подглядывания и перехвата может только полное их шифрование. Видимо из-за этого начальный этап развития компьютерной безопасности прочно связан с криптошифрами.
Однако сегодня информация имеет уже не столь "убойную" силу, и задача сохранения ее в секрете потеряла былую актуальность. Сейчас главные условия безопасности информации - ее доступность и целостность. Другими словами, пользователь может в любое время затребовать необходимый ему сервис, а система безопасности должна гарантировать его правильную работу. Любой файл или ресурс системы должен быть доступен в любое время (при соблюдении прав доступа). Если какой-то ресурс недоступен, то он бесполезен. Другая задача защиты - обеспечить неизменность информации во время ее хранения или передачи. Это так называемое условие целостности.
Таким образом, конфиденциальность информации, обеспечиваемая криптографией, не является главным требованием при проектировании защитных систем. Выполнение процедур криптокодирования и декодирования может замедлить передачу данных и уменьшить их доступность, так как пользователь будет слишком долго ждать свои "надежно защищенные" данные, а это недопустимо в некоторых современных компьютерных системах. Поэтому система безопасности должна в первую очередь гарантировать доступность и целостность информации, а затем уже (если необходимо) ее конфиденциальность. Принцип современной защиты информации можно выразить так - поиск оптимального соотношения между доступностью и безопасностью.
МИФ ВТОРОЙ.
"Во всем виноваты хакеры"
Этот миф поддерживают средства массовой информации, которые со всеми ужасающими подробностями описывают "взломы банковских сеток". Однако редко упоминается о том, что хакеры чаще всего используют некомпетентность и халатность обслуживающего персонала. Хакер - диагност. Именно некомпетентность пользователей можно считать главной угрозой безопасности. Также серьезную угрозу представляют служащие, которые чем-либо недовольны, например, заработной платой.
Одна из проблем подобного рода - так называемые слабые пароли. Пользователи для лучшего запоминания выбирают легко угадываемые пароли. Причем проконтролировать сложность пароля невозможно. Другая проблема - пренебрежение требованиями безопасности. Например, опасно использовать непроверенное программное обеспечение. Обычно пользователь сам "приглашает" в систему вирусы и "троянских коней". Кроме того много неприятностей может принести неправильно набранная команда. Так, при программировании аппарата ФОБОС-1 ему с Земли была передана неправильная команда. В результате связь с ним была потеряна.
Таким образом, лучшая защита от нападения - не допускать его. Обучение пользователей правилам сетевой безопасности может предотвратить нападения. Другими словами, защита информации включает в себя кроме технических мер еще и обучение или правильный подбор обслуживающего персонала.
МИФ ТРЕТИЙ.
"Абсолютная защита"
Абсолютной защиты быть не может. Распространено такое мнение - "установил защиту и можно ни о чем не беспокоиться". Полностью защищенный компьютер - это тот, который стоит под замком в бронированной комнате в сейфе, не подключен ни к какой сети (даже электрической) и выключен. Такой компьютер имеет абсолютную защиту, однако, использовать его нельзя. В этом примере не выполняется требование доступности информации. "Абсолютности" защиты мешает не только необходимость пользоваться защищаемыми данными, но и усложнение защищаемых систем. Использование постоянных, не развивающихся механизмов защиты опасно, и для этого есть несколько причин.
Одна из них - развитие вашей собственной сети. Ведь защитные свойства электронных систем безопасности во многом зависят от конфигурации сети и используемых в ней программ. Даже если не менять топологию сети, то все равно придется когда-нибудь использовать новые версии ранее установленных продуктов. Однако может случиться так, что новые возможности этого продукта пробьют брешь в защите.
Кроме того, нельзя забывать о развитии и совершенствовании средств нападения. Техника так быстро меняется, что трудно определить, какое новое устройство или программное обеспечение, используемое для нападения, может обмануть вашу защиту. Например, криптосистема DES, являющаяся стандартом шифрования в США с 1977 г., сегодня может быть раскрыта методом "грубой силы" - прямым перебором.
Компьютерная защита - это постоянная борьба с глупостью пользователей и интеллектом хакеров.
В заключение хочется сказать о том, что защита информации не ограничивается техническими методами. Проблема значительно шире. Основной недостаток защиты - люди, и поэтому надежность системы безопасности зависит в основном от отношения к ней служащих компании. Помимо этого, защита должна постоянно совершенствоваться вместе с развитием компьютерной сети. Не стоит забывать, что мешает работе не система безопасности, а ее отсутствие.
Выбрал куски из своей почты, растерзал по привычке синтаксической правкой (солнышки, ну почему вы так не любите русский язык? Что плохого он вам сделал?) и теперь считаю себя вправе включить в очередной FAQ. Рискую лицезреть возникновение необходимости отправить большим дядям из адсенса предложение переделать нафиг их собственный раздел частозадаваемых вопросов.
Как стать Вашим рефералом?
В правой колонке блога есть кнопка "Заработайте деньги на Вашем сайте. Google AdSense". Регистрация - на русском языке. Однако предварительно необходимо создать блог, пригодный для отправки на рассмотрение: зачисление в программу AdSense не происходит автоматически.
С моей же стороны набор требований минимален, то есть вообще нулевой. Даром что я ксенофоб, шовинист и ещё кто-то (кажется, анархист и люблю устраивать теракты в годовщину терактов). От самого реферальства мне ни горячо, ни холодно. Однако среди трудолюбивых и креативных (почему-то слово "творческих" никак сюда не лезет, ибо в последние годы творчеством в инете стали называть такое, что… ладно, не по теме) рефералов я буду подыскивать кандидатов для других проектов, не связанных с адсенсом; основная заповедь интернет-маркетинга гласит: разнообразные источники дохода! Иными словами, чеки должны приходить от разных юридических контор.
Адсенс хорош, но душа требует разнообразия. Опыт, который рефералы приобретут при работе с адсенсом, поможет им в достижении того самого разнообразия в получаемых чеках. Кроме того, пособие в формате .pdf будет доступно рефералам без всякой мзды, причём на русском языке.
Где брать контент для блогов?
Гугл не только всё знает - он многое отдаёт за "спасибо" (намалюйте в подъезде "ихь либе гугл"). К любому запросу добавляйте "free article" или "free articles". Подсказка для трудолюбивых: годные тексты статей, а не рекламная однострочная ботва с ключевыми словами, хорошо ищется по запросам: tips, tricks, advice, tutorial, manual, guide…
Разумеется, думайте головой, прежде чем искать tips по теме "некрофильское порно". Правда, адсенс будет бессилен показать тематические объявления по вышеозначенной теме на вашем блоге, но горячие головы упорно думают, что блоги должны быть непременно с hardcore. А ещё лучше с виагрой. Не буду ударяться в объяснения, чем дорвеи отличаются от адсенса - пусть это сделает кто-нибудь, кто занимается и тем, и другим. Я бы спросил Джоэла Комма, но он, зараза, про дорвеи ни слова не сказал до сих пор.
Пример запроса для поиска контента по ключевому слову Christmas turkey:
christmas turkey "free article"
christmas turkey "free recipes"
Обратите внимание на то, что я использовал слово "рецепты", так как индейка - это всё-таки ритуальная еда, и статьи просто про рождественское мясо писать непопулярно. Берите статьи с третьей страницы выдачи и далее, можно и с первой, но статьи из топа, сами понимаете, наверняка зачитаны до дыр. Те, что с более поздних страниц, имеют больше шансов оказаться малоизвестными потенциальным серферам. То есть статьи им понравятся, и они с радостью пойдут по объявлениям адсенса дальше. Подчёркиваю - с радостью! Ибо опечаленный серфер может с тоски неразделённой сказать гуглу, какую гадость вычитал на вашем блоге, а гугл возьмёт и согласится с печальным серфером… появится ещё один печальный адсенс-публишер. А зачем плодить печаль в миру?
Нужно ли хорошенько проспамить блог для раскрутки и подождать перед тем, как подавать заявку, или же главное - качественный ресурс, неважно, что он новый и пока поисковики о нем не знают?
Я не работаю аппрувером в команде AdSense (чьё-то счастье, хых), но полагаю, что команду link: тамошние мальчики и девочки знают и пользуют. И если заявленый на регистрацию в адсенсе блог имеет тучу входящих линков с виагровых гостевых книг, то тут уже и недалёкий человек догадается, что автор блога - ушлый крендель и уже приготовил лопату для адсенсовских денег.
Проявите свою прыткость в другом. В уникальном (да, я не опечатался) контенте. Не страдайте мозговым плоскостопием или шаблонностью, пишите с размахом и от души! Но чтите грамматику вне зависимости от языка. Поймите, аппрувер читает ВАШ блог, а не один из миллионов. И ваш блог должен ему понравиться. Дизайн может быть на любителя, но текст должен цеплять.
Кстати, не используйте в URL блога какие-либо заведомо денежные ключевые слова. То есть блог с адресом badcreditreport2006.blogspot.com, даже полный уникальных авторских статей (защищённых внешними скриптами собственной разработки для предотвращения считывания ботами), в глазах потенциального апррувера будет сильно походить на творение кренделя, вооружённого даже не лопатой, а бульдозером для сгребания адсенсовских денег.
Блог не должен за версту разить жаждой его обладателя поживиться. Блог - это самовыражение. Плевать, что по выбранной вами теме адсенс не сможет показать релевантные объявления - не это не волнует аппрувера. Его волнует соотношение контента и предполагаемых объявлений - чтобы последних было не в два раза больше, буде они появятся. Его волнует, чтобы контент был читабельным и личностным. Используйте местоимения "я", "мы", рассказывайте истории из своего жизненного опыта, о своих друзьях, об увлечениях - но если вы некрофил, то надейтесь, что ваш некрофильский бог сыщет для вас в команде адсенса аппрувера-некрофила, который проникнется вашим онлайн-дневником и откроет вам аккаунт в AdSense.
Сколько времени уходит на рассмотрение заявки на участие в программе AdSense?
Многие факторы влияют на конечный срок; подайте заявку в конце декабря, и ждите месяца два… А вообще от нескольких дней до нескольких недель. Хочу обратить ваше внимание, что письмо, которое приходит в ваш почтовый ящик сразу же после отправки заявки - не есть аппрув, это всего лишь проверка вашего электронного адреса.
На какую тему создавать блог, чтобы его приняли к регистрации в программе AdSense?
Не стоит высказывать какие-либо требования по ограничению, но среди беспроигрышных упомяну:
* Туризм, путешествия;
* Цифровая фотография (и не только цифровая), советы начинающим, инструкции, описание частых ошибок…;
* Видеосъёмка; свадебщики могут плясать от радости
* Обработка графики и видео; любители Adobe Premiere и Vegas Video тоже могут плясать
* Программирование - на любом языке (или без оного ) ;
* Домашняя выпечка, кулинария, приготовление индейки
* Спорт - велосипеды, спуск на байдарках, дайвинг и всё остальное;
* Психология, помощь в общении, советы по навыкам коммуникации в обществе; это настолько актуально в теперешние времена, что апрувер должен быть полным казлом, чтобы отказать такому блоггеру в регистрации;
* Образование, воспитание; дети - это вообще святое, за детей сам фюрер пасти рвал (правда, только за немецких детей, но зато пасти рвал всем, даже самим немецким детям);
* Семья, отношения; но будьте осторожны! Опишите происходящее в вашей постели - и вы пролетите с адсенсом как фанера над Парижем. С такими текстами вам будет уютнее на стульчик.ру.
* А вот от обсуждения американских политиков, восхваления Ким Чен Ира, насмешек над отцами католической церкви, порицания датских газетчиков - лучше воздержаться. Вы не исправите этот грешный мир. Максиммум, что вы можете сделать - поправить своё материальное положение. Думайте о втором.
* Как можно управлять сотнями блогов двумя кликами мышки? Чтобы само всё делалось, а я типа только раз в месяц отрываю задницу от стула, чтобы отнести чек в банк? Не знаю.
* Нужны ли комментарии в блогах? Стоит ли их создавать в режиме автомата? Смотрите сами; умеете защищаться от ребят с хрумером - вперёд. Я лично этих ребят обоснованно побаиваюсь
* На каком языке создавать блог? Обязателен ли английский? Несколько месяцев назад, до ввода полноценной службы поддержки программы AdSense на русском языке, я бы не рекомендовал пользоваться русским языком. Но теперь, видимо, это не аргумент, тем более, что гугл проявляет растущее внимание к российским вебмастерам. Блог на русском языке, скорее всего, будет оценивать русский аппрувер, наш эмигрант, так что это увеличивает шансы на благожелательное отношение.
С другой стороны, от всего русского принято ожидать подвоха. Думаете, почему так не любят доменную зону .ру? Вот по этой причине, если вы располагаете средствами создания блога на английском языке (допустим, студентка-отличница с филфака МГУ проживает в вашей постели), то используйте английский. Заодно подучите язык.
Можно ли в качестве контента использовать генераторы оного?
Можно. Как сказал вебмастер одной из директорий ссылок, "если вам лень вручную заполнять заявку на размещение ссылки, то мне точно также лень её размещать". Делайте выводы.
Как часто размещать статьи в регистрационном блоге ДО подачи заявки в AdSense? И сколько должно быть статей?
За две недели напишите десять полноценных статей объёмом 500-700 слов каждая. Это покажет аппруверу, что вы - серьёзный сетевой напесатель и программа AdSense от вашего участия сильно выиграет.
Стоит ли для подстраховки создавать несколько регистрационных блогов? Или ограничиться одним?
Если у вас так много прыти, сделайте супер-блог, одного взгляда на который хватит, чтобы апрувер схватился за сердце, выпил карвалола и сказал: "Свершилось! Этот блог создан! И мне выпала честь выдать его автору разрешение на размещение рекламы AdSense! Святые небеса, благодарю вас за то, что я избран для этой великой миссии!"
Отказ в регистрации делает лишённой смысла попытку зарегистрироваться в тот же день заново. Придётся ждать хотя бы пару месяцев.
Как утверждает Joel Comm, адсенс очень благосклонно относится к блогам с сервиса blogger.com, поэтому создавать регистрационный лучше всего там. Собственное же доменное имя не выступает гарантом успешной регистрации.
Резюмируем:
Для повышения процента вероятности успеха регистрации в программе адсенс с первого захода следует:
напрячься и ещё ДО создания блога подумать, на какую тему вы сможете влёгкую накатать десяток статей, заведомо не нарушая условия соглашения, не затрагивая сверхдорогие ключевые слова типа некоторых видов рака; придумать доменное имя, в котором НЕ будут фигурировать дорогие ключевые слова; я использовал свой ник Attente;
избегать использования цифр и всяческих внеалфавитных символов в доменном имени: вариант my_nickname-_2006–_coolguy не прокатит; мыслить широко и интересно для потенциальной аудитории; если вы открыли секрет, как ставить куриные яйца на торец - опишите сей процесс в деталях, с кучей фотографий, интервью с другими "яйцеставильщиками", статьями с других смежных по теме ресурсов - и адсенс-аппрувер будет в отпаде, зуб даю! Сам два часа учился яйца ставить вертикально, пока до меня дошло, как именно это делается;
излагать мысли и переживания реального человека; описывайте жизнь в динамике - ибо аппруверы в своём большинстве мужчины и лучше воспринимают действие, нежели описание;
использовать реальные имена, места, даты, топографические названия, номера частей и дивизий Минобороны за последнее по головке не погладит, но аппрув выдаёт пока что не оно;
размещать фотографии - стопроцентно сделанные любительской камерой (вашей); натыренные снимки из Google Images могут запросто вырыть вам могилку куда глубже шести футов;
указывать в качестве адреса электронной почты что-нибудь цивильное; вероятно, gmail просто идеален хотя признанный лидер бесплатной почты MSN и Hotmail тоже рулит.
Услуги по предоставлению хостинга бывают следующих видов:
Бесплатный хостинг (Free web hosting service)
Полностью бесплатен для пользователя. Как правило, дается доменное в поддомене хостера, на хостинге часто висит баннерная реклама, которая мешает дизайну, список поддерживаемых технологий ограничен, часто нет поддержки скриптовых языков (php, asp.net и java). Подобный хостинг на большее, чем под домашняя страничка, не подходит.
Виртуальный хостинг (Shared web hosting service)
Ваш веб-сайт находится на том же сервере, как и многие другие сайты, в диапазоне от нескольких до сотен или тысяч. Как правило, все домены могут разделить общий пул серверных ресурсов, таких как память и процессор. Управление работой всех сайтов идет через виртуальные хосты средствами веб-сервера apache.
Реселлеры хостинга (Reseller web hosting)
Когда провайдер хостинга позволяет клиентам стать самостоятельными провайдерами хостинга. Дилеры могут самостоятельно настраивать свой сервер, создавать отдельные домены. Реселлеры затем перепродают свой хостинг по более высокой цене своим клиентам, зарабатывая на разнице. Дилеры могут сильно отличаться по размерам: они могут иметь свои собственные сервера или же арендовать их у хостера.
Аренда части сервера. Отличается от виртуального тем, что каждый пользователь считает, что у него как бы свой собственной выделенный сервер, но он фактически лишь делит его с другими пользователями. Как правило, пользователи имеют доступ к настройкам конфигурации той части сервера, которая ими арендована, также регулировать размеры трафика, количество баз данных, электронных почтовых ящиков и ftp-аккаунтов.
Выделенный сервер (Dedicated hosting service)
Пользователь получает в аренду или ставит свой сервер на площадке хостера. Предоставляется полный контроль над сервером (корневой доступ для Linux / администратора для Windows). Выделенный хостинг делится на самообслуживание клиентов или на обслуживании администраторов хостера (за дополнительную плату). Если пользователь имеет полный административный доступ, то это означает, что он несет ответственность за обеспечение безопасности и поддержание своего сервера.
Управляемые службы хостинга (Managed hosting service)
Пользователь получает свой собственный Web сервер, но не имеет полного контроля над ним (корневой доступ Linux / администратора для Windows). Однако он может управлять своими данными через FTP или другие средства удаленного управления. Пользователям запрещается полный контроль по той причине, что провайдер должен гарантировать качество обслуживания, не позволяя пользователю изменять конфигурацию сервера или создавать потенциально опасных проблем конфигурации. Пользователь, как правило, не владеет сервером, а лишь арендует его.
Колокейшен (Collocation web hosting service)
Предоставляются услуги, аналогичные выделенному серверу, но пользователь владеет размещенным сервером. Хостинговая компания обеспечивает физическое пространство и обеспечивает работоспособность сервера (питание, охрану, защиту от перегрева, пыли и влаги).
Это самый мощный и дорогостоящий вид услуг веб-хостинга. В большинстве случаев колокейшен провайдер почти не оказывает поддержки непосредственно для своих клиентов, а предоставляет только электричество, доступ в Интернет и стойку для сервера.
В большинстве случаев для колокейшена, клиент имеет собственного системного администратора, который может в любое время посещать дата-центр хостера для настройки и конфигурирования сервера (программное обеспечение, замена оборудования сервера).
Ресселинг веб-хостинга является разновидностью веб-хостинга, в котором владелец счета имеет право и возможность использовать полный объем жесткого диска и пропускной способности выделенных ему каналов, чтобы организовать веб-сайты от имени третьих сторон.
Обычно веб-хостинг получает реселлер как разработчик, системный интегратор или студия веб-дизайна. Они берут хостинг как бы оптом и им он обходится дешевле, а уже своим клиентам они продают его дороже или по себестоимости, если речь идет о клиентах студии веб-дизайна.
Помимо этого реселлерами хостинга становятся предприниматели, которые хотят создать новую компанию. Вообще большинство хостинговых компаний для реселлеров создают свой собственный план и предоставляют нужный им набор услуг.
Реселлерам также предоставляется панель управления и полный доступ к ней. С ее помощью они могут создавать свои собственные учетные записи и администрировать сервер.
Реселлер хостинга не требует обширных знаний технических аспектов веб-хостинга. В этом случае обычно достаточно оператора центра обработки данных, который отвечает за поддержание сетевой инфраструктуры и аппаратного обеспечения. Еще нужен системный администратор, который настроит программное обеспечение и будет следить за работоспособностью сервера.
Реселлер отвечает за взаимодействие собственной клиентской базы, но любые сбои оборудования и проблемы с каналами как правило направляется провайдеру, у которого реселлер приобрел хостинг.
Через контрольную панель реселлеры могут создавать и управлять своими клиентами в соответствии с их потребностью через простой интерфейс. Они также могут использовать программное обеспечение. Тот же MordenBill является одним из популярных программ для автоматизации создания счета и расчетов с покупателями.
Вот лишь основные возможности панели управления реселлера хостинга:
* WHM/cPanel (Unix) (Вскоре должна выйти версия под ОС Windows)
* Plesk (Windows/Unix)
* DirectAdmin (Unix)
* Webmin (Unix)
* Ensim Pro (Windows/Unix)
* Helm (Windows)
* Hosting Controller (Windows)
Одной и наиболее сильных сторон среды программирования Delphi является ее открытая архитектура, благодаря которой Delphi допускает своего рода метапрограммирование, позволяя “программировать среду программирования”.
Такой подход переводит Delphi на качественно новый уровень систем разработки приложений и позволяет встраивать в этот продукт дополнительные инструментальные средства, поддерживающие практически все этапы создания прикладных систем.
Столь широкий спектр возможностей открывается благодаря реализованной в Delphi концепции так называемых открытых интерфейсов, являющихся связующим звеном между IDE (Integrated Development Environment) и внешними инструментами. Данная статья посвящена открытым интерфейсам Delphi и представляет собой обзор представляемых ими возможностей.
В Delphi определены шесть открытых интерфейсов: Tool Interface, Design Interface, Expert Interface, File Interface, Edit Interface и Version Control Interface. Вряд ли в рамках данной статьи нам удалось бы детально осветить и проиллюстрировать возможности каждого из них.
Более основательно разобраться в рассматриваемых вопросах вам помогут исходные тексты Delphi, благо разработчики снабдили их развернутыми комментариями. Объявления классов, представляющих открытые интерфейсы, содержатся в соответствующих модулях в каталоге ...DelphiSourceToolsAPI.
Design Interface (модуль DsgnIntf.pas) предоставляет средства для создания редакторов свойств и редакторов компонентов. Редакторы свойств и компонентов – это тема, достойная отдельного разговора, поэтому напомним лишь, что редактор свойства контролирует поведение Инспектора Объектов при попытке изменить значение соответствующего свойства, а редактор компонента активизируется при двойном нажатии левой кнопки мыши на изображении помещенного на форму компонента.
Version Control Interface (модуль VCSIntf.pas) предназначен для создания систем контроля версий. Начиная с версии 2.0, Delphi поддерживает интегрированную систему контроля версий Intersolv PVCS, поэтому в большинстве случаев в разработке собственной системы нет необходимости. По этой причине рассмотрение Version Control Interface мы также опустим.
File Interface (модуль FileIntf.pas) позволяет переопределить рабочую файловую систему IDE, что дает возможность выбора собственного способа хранения файлов (в Memo-полях на сервере БД, например).
Edit Interface (модуль EditIntf.pas) предоставляет доступ к буферу исходных текстов, что позволяет проводить анализ кода и выполнять его генерацию, определять и изменять позицию курсора в окне редактора кода, а также управлять синтаксическим выделением исходного текста.
Специальные классы предоставляют интерфейсы к помещенным на форму компонентам (определение типа компонента, получение ссылок на родительский и дочерние компоненты, доступ к свойствам, передача фокуса, удаление и т.д.), к самой форме и к ресурсному файлу проекта.
Также Edit Interface позволяет идентифицировать так называемые модульные нотификаторы, определяющие реакцию на такие события, как изменение исходного текста модуля, модификация формы, переименование компонента, сохранение, переименование или удаление модуля, изменение ресурсного файла проекта и т. д.
Tool Interface (модуль ToolIntf.pas) предоставляет разработчикам средства для получения общей информации о состоянии IDE и выполнения таких действий, как открытие, сохранение и закрытие проектов и отдельных файлов, создание модуля, получение информации о текущем проекте (число модулей и форм, их имена и т. д.), регистрация файловой системы, организация интерфейсов к отдельным модулям и т.д.
В дополнение к модульным нотификаторам Tool Interface определяет add-in нотификаторы, уведомляющие о таких событиях, как открытие/закрытие файлов и проектов, загрузка и сохранение desktop-файла проекта, добавление/исключение модулей проекта, инсталляция/деинсталляция пакетов, компиляция проекта, причем в отличие от модульных нотификаторов add-in нотификаторы позволяют отменить выполнение некоторых событий.
Кроме того, Tool Interface предоставляет средства доступа к главному меню IDE Delphi, позволяя встраивать в него дополнительные пункты.
Expert Interface (модуль ExptIntf.pas) представляет собой основу для создания экспертов — программных модулей, встраиваемых в IDE c целью расширения ее функциональности. В качестве примера эксперта можно привести входящий в Delphi Database Form Wizard, выполняющий генерацию формы для просмотра и изменения содержимого таблицы БД.
Вот несколько функций для операций с двухмерными массивами. Самый простой путь для создания собственной библиотеки. Процедуры SetV и GetV позволяют читать и сохранять элементы массива VArray (его Вы можете объявить как угодно).
Например:
Самый простой путь - создать массив динамически
сделайте функцию fetch_num типа
и затем вместо myarray[2,3] напишите
Вот способ создания одно- и двухмерных динамических массивов:
Поиск
