Эта книга адресована читателю, делающему первые шаги в изучении самого популярного языка программирования Visual Basic .NET. Ознакомившись с материалами, изложенными в ней, вы узнаете о графических возможностях Visual Basic .NET и способах создания различных видов компьютерной графики: элементов интерфейса компьютерных программ, дизайна Web-страницы, анимации или компьютерных игр. Изучить материал данной книги не составит труда, так как написана она просто и доходчиво. Кроме того, читатель будет иметь возможность рассмотреть общие правила программирования на Visual Basic .NET, что значительно облегчит изучение предложенной темы.
Описание: Книги, написанные коллективом авторов под руководством профессора, доктора технических наук Берлинера Э.М., посвященные операционной системе Microsoft Windows и многофункциональному пакету офисных приложений Microsoft Office, хорошо известны читателям компьютерной литературы. В каждой новой книге авторы стремятся учесть накопившийся опыт и подробнее рассмотреть основные возможности нового продукта.
В настоящей книге рассмотрены оптимальные способы решения повседневных задач, возникающих при профессиональной работе с пакетом Microsoft Office 2003.
Эта электронная книга - попытка рассмотреть все наиболее распространенные современные методы управления промышленным предприятием. Для большинства российских предприятий, стремящихся успешно развиваться и конкурировать не только на внутреннем, но и на внешнем рынке, сейчас самое время узнать, как наиболее эффективно управлять предприятием.
Точно вовремя (Just-In-Time, JIT) - концепция управления промышленными предприятиями, широко использующаяся на промышленных предприятиях различного профиля и различного размера во всем мире. Эта книга - попытка рассмотреть все наиболее распространенные современные методы управления промышленным предприятием. Для большинства российских предприятий, стремящихся успешно развиваться и конкурировать не только на внутреннем, но и на внешнем рынке, сейчас самое время узнать, как наиболее эффективно управлять предприятием. В книге рассматриваются эволюция систем управления - от самых простых методов к более сложным (MRP II - планирование производственных ресурсов), новые, только получающие широкое распространение компьютерные системы (APS-системы, или системы синхронного планирования и оптимизации производственных процессов), теория ограничений и теория `Точно вовремя`, некоторые практические аспекты использования корпоративных компьютерных систем (ERP-систем), а также место ERP-систем в информационном пространстве предприятия и возможности интеграции ERP-систем с другими системами (бухгалтерскими, CAD/CAM, PDM-системами). Значительное место в книге занимают вопросы организации проекта внедрения описанных методов управления и поддерживающих их компьютерных систем. Рассматривается тактика выбора системы, подходящей предприятию, а также вопросы организации проекта успешного внедрения.
В книгу включены наиболее важные предложения базового варианта SQL, позволяющие познакомиться с основными средствами манипулирования данными. Недостаток места не позволил подробно рассмотреть другие его конструкции. Однако и таких знаний достаточно для получения данных из баз, находящихся под управлением большинства современных СУБД (если, конечно, вам предоставят привилегии доступа к ним).
В данной статье приведены общие сведения об организации работы системы 1С:Предприятие с распределенной информационной базой (ИБ). Также описаны внутренние особенности организации механизма работы с распределенными данными для того, чтобы специалисты, осуществляющие конфигурирование и администрирование распределенных систем могли лучшее понимать выполняемые системой действия. Данная информация может также быть использована для оценки дополнительных затрат ресурсов системы, расходуемых на поддержание распределенной информационной базы.
Так как средства системы 1С:Предприятие для работы с распределенными информационными базами поставляются отдельно, сначала кратко остановимся на назначении и основных принципах организации работы системы 1С:Предприятие с территориально удаленными подразделениями.
Назначение и основные принципы
В тех случаях, когда предприятие представляет собой территориально распределенную структуру, зачастую сохраняется потребность в ведении единой системы учета. То есть необходимо иметь возможность работать в едином пространстве документов, получать отчеты, отражающие состояние дел как в территориально удаленных подразделениях предприятия, так и на предприятии в целом и т.п. При этом не всегда имеется возможность организовать работу всех подразделений с единой информационной базой в режиме он-лайн.
Для решения подобных задач предназначена компонента "Управление распределенными ИБ". С помощью указанной компоненты можно организовать двухуровневую структуру информационных баз (ИБ) системы 1С:Предприятие, состоящую из одной центральной и нескольких периферийных информационных баз, работающих с единой конфигурацией. При этом система будет стремиться поддерживать одинаковое состояние объектов данных во всех узлах распределенной ИБ.
Содержимое информационных баз синхронизируется путем переноса измененных объектов данных между каждой из периферийных и центральной ИБ. Для переноса данных используются так называемые файлы переноса данных. Перенос изменений выполняется только между центральной и периферийными ИБ. Перенос данных непосредственно между периферийными ИБ невозможен. Поэтому изменения данных, произведенные в одном из периферийных узлов распределенной ИБ попадают в другие периферийные узлы только через центральную ИБ.
В простейшем случае (по умолчанию) областью распространения изменений для всех объектов является вся распределенная ИБ. Таким образом, в случае если в течение какого-то времени изменения данных системы не будут производиться, и, в то же время, будут произведены все необходимые действия по обмену изменениями между узлами распределенной ИБ, то все узлы будут содержать абсолютно одинаковые данные.
В некоторых случаях может возникнуть необходимость в том, чтобы объекты того или иного типа никогда не попадали в те или иные узлы распределенной ИБ или никогда не покидали места своего создания. Для обеспечения такой возможности предназначен механизм настройки параметров миграции объектов. С его помощью можно ограничить распространение изменений объектов того или иного вида. Кроме того, в версии 7.7 системы 1С:Предприятие можно создавать периферийные ИБ, которые будут принимать информацию о измененных объектах из центральной ИБ, но не будут передавать изменения, сделанные в них самих.
Механизмы распространения изменений объектов работают полностью автоматически. Разработчик конфигурации лишен возможности вмешиваться в функционирование этих механизмов. Для того, чтобы механизмы распределенной ИБ начали работать, не нужно производить никаких специальных действий по конфигурированию системы.
Однако, для того, чтобы документы, элементы справочников и другие объекты, созданные в разных узлах распределенной ИБ, имели заведомо непересекающиеся пространства номеров, кодов и т. п., может потребоваться внести в конфигурацию некоторые изменения. Также изменения в конфигурации должны вноситься при необходимости обеспечить специальные ограничения работы пользователей на периферийных информационных базах.
Для переноса измененных объектов в распределенной ИБ и для первичного создания периферийной ИБ используется файл переноса данных. Он представляет собой упакованный (сжатый) файл, содержащий объекты информационной базы (все при создании периферийной ИБ или измененные при передаче изменений) в специальном формате. Формат данного файла не предназначен для использования его способами отличными от тех, которые предусмотрены механизмами выгрузки/загрузки и передачи изменений. Файл переноса фактически отражает содержимое объектов информационной базы в формате, не зависящем от формата базы данных. Это позволяет использовать в распределенной информационной системе в различных узлах различные форматы хранения данных, поддерживаемые системой 1С:Предприятие (DBF/CDX и MS SQL Server).
Регистрация изменений
Перенос измененных данных производится "пообъектно". То есть единицей переноса данных является так называемый ведущий объект. С точки зрения работы в распределенной информационной базе в 1С:Предприятии существуют следующие типы ведущих объектов:
константа,
элемент справочника,
документ,
календарь,
счет бухгалтерского учета,
типовая операция.
Вместе с документами переносятся все действия, выполняемые ими в процессе проведения: движения регистров, акты расчета, бухгалтерская операция, проводки. В случае, если при проведении документа производятся изменения периодических реквизитов элемента справочника, то производится перенос всего элемента справочника.
Регистрация изменений объектов производится автоматически при любом изменении объекта, независимо от того каким способом это изменение производилось (интерактивно или из встроенного языка). Кроме того в версии 7.7 системы 1С:Предприятие для таких объектов как элементы справочников и документы появилась возможность управления регистрацией изменений. Для этого у соответствующих объектов метаданных введен признак "Автоматическая регистрация изменений". Если этот признак установлен (значение по умолчанию), то автоматическая регистрация производится, а если признак сброшен, то регистрация не производится и изменения объектов в распределенной ИБ не распространяются. Но и в данном случае, при выполнении записи изменений объектов из встроенного языка можно управлять регистрацией изменений с помощью метода встроенного языка РегистрацияИзменений().
Регистрация изменений ведущих объектов производится в специальной служебной таблице. При этом фиксируются следующие данные об изменении объекта:
Сам ведущий объект;
Идентификатор той ИБ, в которую должно быть передано изменение;
Идентификатор ИБ, в которую должно быть передано изменение, служит для отслеживания переноса данных в каждую из ИБ, с которой данная ИБ обменивается данными. Таким образом, при изменении какого-либо объекта в центральной ИБ в таблицу будет помещено по одной записи для каждой из зарегистрированных периферийных информационных баз. Если же изменение объекта происходит в периферийной ИБ, то в таблицу будет занесена только одна запись, соответствующая центральной ИБ, так как каждая из периферийных ИБ непосредственно взаимодействует только с центральной.
Заметим, что удаление объекта является частным случаем изменения. Оно также помечается в таблице регистрации изменений и передается при выгрузке.
Выгрузка и загрузка изменений
Каждая выгрузка изменений осуществляется в адрес конкретной ИБ. В файл переноса, создаваемый при выгрузке попадают все объекты, записи об изменениях которых содержатся в таблице регистрации изменений для данной ИБ.
Заметим, что выгружаются не изменения объектов, а сами измененные объекты. То есть, если в документе изменилось значение одного реквизита, то будет передаваться весь документ и он будет полностью перезаписан на той ИБ, в которую переносится. Как уже отмечалось, вместе с документом будут перенесены и сделанные им движения регистров, операция и проводки. Если изменяется любой реквизит справочника, то передается полностью весь элемент. При этом история периодических реквизитов передается целиком. Последнее означает, что изменения сделанные в истории периодического реквизита элемента на в двух ИБ не будут сливаться вместе.
В процессе выгрузки в таблице регистрации изменений отмечается выгрузка изменений объектов.
При загрузке файла переноса данных помимо загрузки измененных данных выполняется так называемый прием подтверждений.
В случае, когда пришло подтверждение на получение выгрузки, содержащей последнее изменение объекта, запись об изменении удаляется из таблицы регистрации. То есть записи об изменении объектов данных хранятся в таблице регистрации до тех пор, пока не будет получено подтверждение о доставке измененного объекта по назначению.
Причем выгрузка измененного объекта будет производиться до тех пор, пока не будет получено подтверждение, о доставке изменения. Это значит, что если выполнять перенос все время в одном направлении и не выполнять обратного переноса то объем файла переноса данных будет все время расти, так как каждый раз будут передаваться все объекты, измененные после последнего полученного подтверждения.
При загрузке изменений объектов из периферийной ИБ в центральную, в таблицу регистрации изменений (если, конечно, параметры миграции настроены соответствующим образом) заносятся записи, указывающие, что загруженные из периферийной ИБ изменения объектов должны быть переданы в другие периферийные ИБ.
Изменения конфигурации
Как уже отмечалось, при работе с распределенной ИБ, конфигурация системы может быть изменена только в центральном узле.
Для регистрации изменений конфигурации и передачи ее на периферийные ИБ используется тот же механизм, что и для объектов данных. При записи измененной конфигурации, в таблицу регистрации изменений объектов по числу известных периферийных ИБ заносятся записи, фиксирующие факт изменения конфигурации.
После записи измененной конфигурации в распределенной ИБ складывается такая ситуация, что центральная и периферийные ИБ работают фактически с разными конфигурациями. В таком состоянии созданные на периферийной ИБ файлы переноса данных не могут быть загружены на центральной ИБ по той причине, что в условиях различных конфигураций содержащаяся в файле информация не может быть правильно интерпретирована. Обмен будет восстановлен только после того, как в периферийную ИБ будет загружена измененная конфигурация с центральной ИБ. То есть после изменения конфигурации требуется выполнить перенос из центральной ИБ в каждую из периферийных, а уже затем выполнять перенос из периферийных ИБ в центр.
Перенос измененной конфигурации в периферийные ИБ осуществляется тем же способом, что и перенос измененных объектов данных. В процессе очередной выгрузки из центральной ИБ, в файл переноса данных целиком включается измененная конфигурация, если, конечно, в таблице регистрации изменений содержится запись о том, что измененную конфигурацию следует передать в соответствующую периферийную ИБ. Выгрузка конфигурации также будет производиться до получения извещения о приеме измененной конфигурации.
Заметим, что конфигурация считается измененной при любых изменениях метаданных, форм, модулей, таблиц конфигурации, наборов прав, пользовательских интерфейсов, описаний. В состав конфигурации не входит список пользователей, а также внешние по отношению к файлу конфигурации (1CV7.MD) файлы (внешние отчеты, отдельно записанные таблицы и тексты). И эти внешние файлы не переносятся механизмом управления распределенной ИБ. Поэтому при конфигурировании распределенной системы не рекомендуется использовать в конфигурации находящиеся в отдельных файлах модули, таблицы и отчеты.
Для изменения уже работающей конфигурации можно рекомендовать использовать механизм загрузки измененной конфигурации. Он позволяет специалисту скопировать конфигурацию, выполнить в ней все необходимые изменения, отладить внесенные изменения (этот процесс может занять и несколько дней), а затем загрузить измененную конфигурацию в центральную ИБ, после чего изменения будут распространены на все периферийные ИБ с очередной передачей изменений. Такая последовательность позволит избежать многократной передачи измененной конфигурации в периферийные ИБ в процессе ее модернизации.
При загрузке файла переноса данных на периферийной ИБ, этап загрузки измененной конфигурации (если, конечно, она содержится в файле переноса данных) предшествует этапу загрузки измененных объектов данных. В случае неудачного завершения загрузки конфигурации, загрузка объектов данных производиться не будет и информационная база останется в том же состоянии, что и была до начала загрузки.
Загрузка измененной конфигурации может завершиться неудачей, если измененная конфигурация не соответствует существующим данным. Например, было уменьшено число уровней справочника, а новое число уровней оказывается меньшим, чем фактически содержащееся в справочнике или в других подобных случаях. Если такое произошло, то следует привести данные в соответствие с новой конфигурацией или изменить конфигурацию в центральной ИБ и заново произвести выгрузку, чтобы ликвидировать возникшее противоречие.
Коллизии
При работе в реальных распределенных ИБ один и тот же объект может изменяться одновременно в различных узлах распределенной ИБ. И при переносе измененных объектов из одной ИБ в другую может случиться так, что в какую-либо ИБ будет загружаться объект, зарегистрированный в самой этой ИБ как измененный. Такая ситуация носит название коллизии. Приведем описание действий системы в наиболее типовых вариантах коллизий.
Один и тот же объект изменен более чем в одной ИБ.
Общий принцип здесь состоит в том, что "главным" считается изменение, произведенное в центральной ИБ. Отработка ситуации различается в зависимости от того, на какой ИБ - центральной или периферийной коллизия обнаружена. Если коллизия обнаружена на центральной ИБ, то есть при загрузке файла переноса из периферийной ИБ обнаружено, что один из измененных объектов также изменен и в центральной ИБ, то изменения объекта в центральную ИБ не загружаются. При этом гарантируется, что при очередной выгрузке в адрес периферийной ИБ будет передано состояние объекта как оно есть в центральной ИБ. Если же коллизия обнаружена на периферийной ИБ, то изменения объекта, прибывшие из центральной ИБ загружаются.
Объект, измененный в одной ИБ, удален в другой.
В данном случае принцип заключается в том, что изменение всегда "главнее" удаления. В случае, если на центральную ИБ прибывает файл переноса, в котором содержится информация, что некоторый объект удален на периферийной ИБ, то в центральной ИБ объект не удаляется, а в записи таблицы регистрации изменений данный объект помечается как измененный. То есть при очередном обмене объект будет восстановлен в той ИБ, в которой он был удален, причем само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Аналогичные действия производятся, если коллизия обнаружена на периферийной ИБ.
Объект, удаленный в одной ИБ, не может быть удален в другой по причине наличия ссылок на него.
При загрузке изменений, если загружается информация об удалении объектов, автоматически включается механизм контроля ссылочной целостности и выполняется проверка наличия ссылок в данной ИБ на объекты, которые переданы как удаленные.
В случае обнаружения коллизии такого рода, вне зависимости от того на какой из ИБ она была обнаружена, выполняется следующее: удаление не выполняется, а в таблицу регистрации изменений заносится запись о том, что объект должен быть перенесен в адрес той ИБ, из которой была прислана информация о его удалении.
При очередном обмене объект восстанавливается в той ИБ, в которой он был удален, однако само содержание объекта будет соответствовать той ИБ, которая "отвергла" удаление.
Таким образом, управление распределенной информационной базой имеет определенную стратегию автоматического разрешения любых коллизий с описанными приоритетами. Однако, в реальных условиях рекомендуется средствами конфигурации определить возможные действия пользователей на различных узлах таким образом, чтобы исключить или минимизировать вероятность возникновения коллизий. Основным путем является определения средствами конфигурации "ответственного" узла за каждый ведущий объект в распределенной ИБ и ограничение всем остальным возможности его редактирования и удаления. Определение "ответственных" должно происходить исходя из логики работы предприятия. Очевидно, что многие виды объектов можно разрешить изменять только в центральной ИБ (например, список складов). Для многих объектов можно рекомендовать средствами встроенного языка установить возможность изменения только на той ИБ, на которой они созданы, например для документов.
Параметры миграции
С помощью настройки параметров миграции можно ограничивать области распространения изменений объектов. Настройка параметров миграции происходит по видам "ведущих" объектов. То есть для каждого вида "ведущих" объектов можно определить конкретную настройку параметров миграции. В настройке параметров миграции объектов ведущую роль играет выбор того или иного варианта области распространения изменений объектов данного вида. Существуют три варианта настройки области распространения:
Все информационные базы. Данный вариант настройки используется по умолчанию для всех объектов. В этом случае любые изменения объектов данного типа будут распространяться по всем узлам распределенной ИБ. Этот вариант обеспечивает полную синхронизацию объектов данного вида во всей распределенной ИБ. Очевидно, что этот вариант наиболее прост для конфигурирования.
Место создания. Данный вариант настройки также является довольно простым. В этом случае изменения объекта не передаются в другие ИБ. При такой настройке параметров миграции, объект данного вида никогда не "покидает" места своего создания и не появляется в других ИБ. Однако при выборе данного варианта следует учитывать возможные ссылки на объекты данного вида из объектов других видов, имеющих другие параметры миграции. Например, если установить такой вариант для справочника, и в документах, которые участвуют в обмене, будет содержаться реквизит типа справочник данного вида, то при переносе документа получится неразрешенная ссылка.
Место создания и центр. При таком варианте настройки области распространения объектов существенную роль играет понятие места создания объекта. Местом создания объекта считается ИБ, в которой был создан конкретный объект. Естественно, что различные объекты одного вида могут быть созданы в различных ИБ. Однако место создания объекта может быть определено не для всех видов "ведущих" объектов. Для таких объектов как константы, календари или корректные проводки место создания не определено. Поэтому для этих видов объектов вариант настройки "Место создания и центр" не может быть установлен.
В случае выбора такого варианта области распространения, объекты данного вида помимо места их создания попадают еще и на центральную ИБ. То есть, в случае, если для некоторого вида объектов установлена область распространения "Место создания и центр", то для объектов этого вида, созданных на периферийной ИБ, их изменения будут передаваться между местом их создания и центральной ИБ. Для объектов того же вида, созданных на центральной ИБ, изменения не будут передаваться никуда. С помощью такого варианта области распространения можно добиться такого эффекта, что все объекты того или иного вида будут "собираться" на центральной ИБ, а на любой из периферийных ИБ будут находиться только те объекты, для которых она является местом создания.
В случае выбора области распространения "Место создания и центр", для вида объекта можно задать перечень периферийных узлов распределенной ИБ, которые дополнительно включаются в область распространения всех объектов данного вида. Этот перечень задается как список кодов периферийных ИБ, разделенный запятыми. При задании кодов ИБ допускается использование символов-заменителей '*'. Символ-заменитель должен завершать последовательность символов, образующих код одной или нескольких периферийных ИБ. Таким образом, "A*" представляет собой обозначение всех периферийных ИБ, коды которых начинаются символом 'А'. Последовательность "A*B" является ошибочной, так как символ '*' не завершает последовательность символов, представляющих код периферийной ИБ.
Кроме того, как отмечалось выше, дополнительной возможностью управлять распространением изменений объектов в версии 7.7 системы 1С:Предприятие является особый вид периферийных ИБ, которые получают изменения из центральной ИБ, а сами информацию о сделанных в них изменениях не передают. Для создания периферийной ИБ такого рода, надо при ее инициализации указать признак "Только получатель".
Отдельно стоит рассмотреть случай, когда параметры миграции объектов изменяются в процессе изменения конфигурации уже работающей системы. Изменения параметров миграции для каждого из объектов производится независимо от других. То есть, Конфигуратор не отслеживает ссылки между объектами при настройке параметров миграции. Таким образом, при определенных вариантах настройки параметров миграции у некоторых объектов могут появиться ссылки, указывающие "никуда". Ответственность за сохранение ссылочной целостности в распределенных ИБ возлагается на лицо, занимающееся конфигурированием системы. Общим правилом настройки параметров миграции является определение области миграции для конкретного вида объектов равной более широкой, чем область миграции ссылающихся на него объектов. Например, для справочника область миграции должна быть определена не уже, чем области миграции документов и справочников, в которых есть реквизиты типа "справочник" данного вида. Если, например, измерение регистра имеет тип "справочник" данного вида, то область миграции справочника должна покрывать области миграции всех документов, которые могут записать движения данного регистра.
При изменении параметров миграции того или иного объекта система старается привести имеющиеся данные в соответствие с новыми параметрами. Общим принципом здесь является то, что при изменении параметров миграции объекты никогда ни в каком узле распределенной ИБ не удаляются. Даже в том случае, если в соответствии с вновь установленными параметрами миграции их там быть не должно. Изменения производятся лишь в таблице регистрации изменений. Рассмотрим случаи изменения параметров миграции объектов подробнее.
Наиболее простой случай - это смена любого из вариантов области распространения на вариант "Место создания". В этом случае из таблицы регистрации изменений удаляются все записи по данному виду объектов. То есть все изменения объектов, еще не переданные в другие ИБ, не будут переданы. При этом, все объекты для которых данная ИБ не является местом создания, не будут удалены. Просто их изменения (как и изменения других объектов данного вида) не будут больше передаваться в другие ИБ.
Следующий случай - это смена области распространения "Место создания" на варианты "Все информационные базы" или "Место создания и центр". В этом случае в таблицу регистрации изменений заносятся записи для передачи всех объектов, для которых текущая ИБ является местом создания во все ИБ, в которые должны передаваться изменения в соответствии с вновь заданной настройкой. В случае, если такая смена производится для объектов, для которых место создания не определено (константы, календари, корректные проводки), то записи в таблицу регистрации изменений будут произведены только в центральной ИБ. Этими двумя вариантами и ограничиваются возможные случаи изменения параметров миграции для такого рода объектов. Все остальные случаи возможны только для тех объектов, для которых место создания можно определить.
При изменении области распространения объектов с "Место создания и центр" на "Все информационные базы", какие-либо действия предпринимаются только в центральной ИБ. В этом случае определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. После этого производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи состояния объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Последний и самый сложный случай - это изменение области распространения объектов с "Все информационные базы" на "Место создания и центр" или изменение списка дополнительных ИБ в варианте "Место создания и центр". Действия, производимые в данном случае различаются в зависимости от того, производятся они в центральной ИБ или в периферийной. В центральной ИБ для каждой из периферийных ИБ, не попавших в новый перечень дополнительно включаемых в область распространения, выполняется удаление из таблицы регистрации изменений записей соответствующих данному виду объектов, но только для тех объектов, для которых эта периферийная ИБ не является местом создания. Затем определяется список периферийных ИБ, попавших в список дополнительно включаемых в область распространения, но ранее в него не входивших. Естественно, что в случае, если предыдущим вариантом настройки области распространения было "Все информационные базы", то этот список окажется пустым. Затем, как и в предыдущем случае, производится обход всех объектов данного вида и для каждого из объектов в таблицу регистрации изменений вносятся записи для передачи объекта в каждую из попавших в список периферийных ИБ, за исключением ИБ места создания объекта.
Проблемы конфигурирования и администрирования
При разработке конфигурации для распределенной ИБ проявляется ряд объективно существующих проблем, которые решаются как средствами конфигурации, так и административными решениями.
Очевидной проблемой, которая уже упоминалась выше, является уникальная и последовательная нумерация документов и элементов справочников. Для организации уникальной нумерации используется механизм префиксов. Для его включения в конфигурацию, прежде всего, следует выработать некоторую дисциплину, зависимости префикса от ИБ, в которой создается объект. В простейшем случае это может быть собственно код ИБ. Однако часто префикс может автоматически определяться на каждой ИБ, но не являться ее кодом, так как он может участвовать в печатных формах документов и должен быть понятным для пользователей системы. Более сложной задачей является обеспечение сквозной нумерации объектов без префиксов в случае, когда такая нумерация регламентируется нормативными документами. Особенно сложным является обеспечение строго последовательной нумерации. Очевидно, что полного решения данной проблемы не может быть в принципе, так как объекты создаваемые динамически в независимых системах не могут иметь строгой сквозной нумерации. Отчасти данная проблема решается с помощью введения диапазонов номеров, выделяемых для каждой ИБ. Следует заметить, что номера документов и коды справочников не являются внутренними идентификаторами и их уникальность для системы не обязательна. Это значит, что поддержку уникальность номеров и кодов можно отключить для тех видов, объектов, для которых она не нужна. Кроме того, средствами конфигурации можно организовать перенумерацию объектов, например в центральной ИБ. Однако следует иметь ввиду, что эти изменения будут передаваться как и любые другие изменения, что может вызвать достаточно большой объем передаваемых между узлами данных.
Более сложной проблемой является ситуация, когда возникает необходимость использования некоторого нового объекта в двух и более узлах одновременно, до осуществления передачи данных. Например, новый товар должен быть введен и на центральной ИБ и на периферийной. Важно понимать, что созданный ведущий объект системы 1С:Предприятие обладает некоторой сущностью - внутренним идентификатором, который уникален во всей распределенной системе. То есть один и тот же объект не может быть введен в двух узлах. Даже при полном соответствии кодов, номеров и всех данных это будут два разных объекта. Такой принцип необходим для четкой работы системы со всех точек зрения.
Заметим, что возможные варианты ввода двух объектов и затем автоматической замены на центральной ИБ всех ссылок на один из объектов, достаточно сложны в реализации и весьма ненадежны.
Поэтому, на наш взгляд, решение проблемы должно лежать в области администрирования системы. Технология работы пользователей должна быть построена таким образом, чтобы ввод объекта производился на одном узле.
В отдельных случаях может использоваться следующее решение. В справочник заранее вносится некоторое количество новых элементов со специальными кодами или в специальную группу. При появлении необходимости ввода нового товара реально не вводится новый элемент, а изменяется один этих элементов. При этом административными силами должно быть обеспечено идентичное изменение одного и того же "зарезервированного" объекта в тех узлах распределенной ИБ, в которой он должен быть использован до обмена данными. При обмене данными сами реквизиты элемента будут системой синхронизированы, а ссылки в других объектах, разумеется будут идентичными, так как использовался один и тот же объект.
В любых случаях следует учитывать, что раздельный ввод и использование объектов потребует от пользователей правильного ввода данных. Так, например, при вводе нового товара в двух узлах с разными ценами могут иметь место серьезные ошибки в оформлении документов.
Еще одна проблема, с которой приходится сталкиваться при конфигурировании распределенной ИБ, это правильное поддержание механизмов учета компонент при неполной миграции объектов. Следует учитывать, что итоги оперативного и бухгалтерского учета не являются самостоятельными объектами. Они не переносятся, а рассчитываются на основании перенесенных движений регистров и проводок. Движения регистров и проводки переносятся соответственно только вместе с документами. Таким образом, для правильного состояния итогов на некоторой ИБ, на нее должны переноситься все документы, осуществляющие движения регистров или записывающие проводки влияющие на эти итоги. С другой стороны, это не означает, что переноситься должны все документы, записывающие движения конкретного регистра и проводки. Например, если на периферийной ИБ вводятся документы, выполняющие движения по одному складу, и итоги регистра учета товарного запаса в данной ИБ нужны только по данному складу, то, разумеется, в данном узле будет достаточно наличия всех документов выполняющих движения регистров по данному складу. Это достигается установкой параметра миграции "Место создания и центр".
Environmental Audio (дословно окружающий звук)- это новый стандарт звука, разработанный фирмой Creative Labs, создающий эффекты окружающей среды реального мира на компьютере. Environmental Audio сегодня ужк много больше простого surround -звука и 3D моделирования. Это и настоящее моделирование окружающей среды с помощью мощных эффектов с учётом размеров комнаты, её звуковых особенностей, реверберации, эхо и многих других эффектов, создающих ощущение реального аудио мира.
Как работает Environmental Audio
Эффекты окружающей среды моделируются при помощи технологии E-mu Environmental Modeling, поддерживаемой аудиопроцессором EMU10K1, установленного на серии звуковых карт SBLive! Технология Environmental Audio разработана с учётом работы на наушниках, двух или четырёх колонках. Чип EMU10K1 раскладывает любой звуковой поток на множество каналов, где накладывает эффекты в реальном времени. За счёт этого создаются уже новые звуки, такие, как они должны быть в природе. На стадии обработки звука кроме его пололжения в пространстве должны быть учтены, как минимум, два фактора: размер помещения и реверберация, так как человеческое ухо слышит не просто оригинальный звук, а звук с учётом дистанции, местоположения и громкости. Стандарт Environmental Audio обрабатывает все эти условия для получения высококачественного реального звука.
Environmental Audio использует координаты X, Y, Z, а также реверберацию и отражения звука. Эти координаты используются при базовой подготовки каналов аудио источника и эффектов "окраски" звуковой сцены. Основная мощность аудиопроцессора расходуется на обработку каждого звукового источника по всем каналам и на добаление эффектов в реальном времени. Как уже говорилось, для создания ощущения реального звука нужно учитывать как минимум 3 фактора: расстояние до источника звука, размер звукового помещения и реверберацию.
Environmental Audio Extensions (EAX)
Это API, разработанный фирмой Creative Labs для достижения реальных звуковых эффектов в компьютерных играх. EAX- это расширение API DirectSound3D от фирмы Microsoft На 18 Октября 1999 года единственной звуковой картой, поддерживающей этот стандарт является Sound Blaster Live! (в разных модификациях). На сегодня Creative выпустила три версии этого стандарта.
DirectSound3D управляет местоположением в 3D пространстве игры источников звука и слушателя. Например, игра может использовать DirectSound3D для создания раздельных источников звука для каждого существа в игре, получая, таким образом, звуки выстрелов и голоса в разных местах 3D-мира. Эти звуки, также как и слушатель, могут перемещаться в пространстве. Разработчики игр могут использовать такие звуковые возможности, как палитра направлений (звук в одном направлении может идти громче, чем в другом), эффект Допплера (звук может нарастать, достигнув слушателя, и потом спадать, как бы удаляясь в пространство).
EAX улучшает DirectSound3D созданием виртуального окружающего аудио мира вокруг источников звука и слушателя. Эта технология эмулирует реверберации и отражения, идущие со всех сторон от слушателя. Эти эффекты создают впечатление, что вокруг слушателя существует реальный мир со своими параметрами, как то: размер помещения, отражающие и поглощающие свойства стен и другие. Программисты игр могут создавать различные акустические эффекты для разных помещений. Таким образом, игрок, который играет в EAX игру может слышать разницу в звуке при переходе из коридора в пещеру.
В дополнении к созданию окружающих эффектов, EAX 1.0 может изменять параметры различных источников звука. При изменении местоположения источника звука относительно слушателя автоматически изменяются параметры реверберации.
Что касается программирования, то здесь EAX предоставляет следующие возможности.
* Выбор среди большого числа "пресетов" для моделирования эффектов окружающей среды.
* Возможность изменять параметры пресетов окружающей среды для каждого источника в отдельности.
* Автоматическое изменение критических параметров, применяемых к позиции. Когда источник звука движется по отношению к слушателю, EAX автоматически изменяет параметры отражения звука и реверберации для создания более реальных звуковых эффектов при движении источника звука через 3D звуковой мир.
Occlusions и Obstructions
Эффект occlusions создаёт впечатление, что источник звука находится в другой комнате, в другом месте, за стеной. Это свойство позволяет изменять параметры передачи звуковой характеристики для получения эффекта различных материалов стен и их толщину. Например, программа может использовать это свойство для создания звука, идущего из-за двери, или из-за стены.
Эффект obstructions позволяет эмулировать звуковые препятствия, создавая ощущение, что источник звука находится в той же комнате, но за препятствием. Например, можно сделать так, что звук будет идти из-за большого камня, находящегося в той же пещере, что и слушатель.
Геометрическое моделирование и EAX
Геометрическая модель сцены используется как в графических целях, так и для создания 3D звука. Для создания геометрической модели компьютер должен иметь данные о физических свойствах мира: какие объекты где расположены, какие звуконепроницаемые, какие звукопоглощающие и так далее. После того, как эта информация получена, производится расчёт некоторого количества слышимых отражений и поглощений звука от этих объектов для каждого источника звука. Это приводит к затуханиям звука, из-за препятствий, звуконепроницаемых стен и так далее. Расчёты отражений методом "зеркала" широко используются для создания акустики зданий. Этот метод подразумевает, что звук отражается прямо (как от зеркала) без преломлений и поглощений. На самом же деле, вместо того, чтобы в реальном времени рассчитывать все отражения и особенности среды (что на самом деле процесс трудоёмкий) используются заранее рассчитанные упрощённые модели геометрических аудио сред, которые отличаются от графических представлений о среде. То есть в игре используются одновременно отдельная среда для визуальных эффектов и более простая для звуковых эффектов. Это создаёт проблемы, как, например, если бы вы захотели передвинуть часть стены в комнате, то вам пришлось бы создавать новую среду для звука. В настоящее время над геометрическим моделирование звука ведутся работы во многих звуковых лабораториях.
EAX для разработчиков
EAX не требует того, чтобы источники звука привязывались к графическому представлению об окружающей среде. Но при желании разработчик, который хочет создать звуковые эффекты "повышенной реальности", которые максимально близки к графическому представлению о сцене может использовать дополнительное управление ранними отражениями, преломлениями и поглощениями. При создании своих эффектов EAX использует статические модели среды, а не её геометрические параметры. Эти модели автоматически рассчитывают реверберации и отражения относительно слушателя с учётом размеров помещения, направления звука и других параметров, которые программист может добавлять, для каждого источника звука. Поэтому EAX намного проще других стандартов, так как он не требует описания геометрической среды сцены, а использует подготовленные заранее модели. Игра может менять звуковые модели при переходе от одного места к другому для создания реальных эффектов. Я хочу рассмотреть это подробней. Допустим, у вас есть сцена в игре ввиде каменной пещеры. Есть два способа получить высокореалистичные эффекты. Первый из них- рассчитать геометрическую модель и использовать её как аудио маску для сцены, причём новые технологии будут позволять делать это в реальном времени. Второй способ- взять готовый пресет и, при необходимости, изменить его для получения более качественных эффектов. Разумеется, первый способ даст больший реализм, чем второй, но и потратит ресурсов в несколько раз больше. А если учитывать лень программистов, то в этом случае EAX наиболее благоприятный вариант.
Различия между EAX 1.0, 2.0 и 3.0
EAX 1.0
* Поддерживает изменение места в игре реверберации и отражений.
* Имеет большое количество пресетов.
* Позволяет (ограниченно) изменять реверберацию окружения.
* Позволяет автоматически изменять интенсивность реверберации, в зависимости от положения источника звука относительно слушателя.
EAX 1.0 строит звуковую сцену на основе заранее созданных пресетов, учитывая дистанцию между источниками звука и слушателем. Соответственно, EAX 1.0 предоставляет большой набор пресетов "на каждый случай жизни". Также имеется возможность изменять параметры поздней реверберации (дэмпинг, уровень) и автоматическое изменение уровня в зависимости от расстояния. Благодаря этому происходит улучшенное восприятие расстояния до источника.
EAX 2.0
* Обновлена реверберационная модель.
* Добавлены эффекты звуковых преград (Obstructions) и поглощений (Occlusions).
* Отдельное управление начальными отражениями и поздними реверберациями. Продолжительный контроль размеров помещений. Улучшенная дистанционная модель для автоматического управления реверберациями и начальными отражениями, основанными на местоположении источника звука относительно слушателя.
* Возможность учитывать звуковые свойства воздуха (поглощение звука).
* Теперь для использования эффектов Environmental Audio не не требуется описание геометрии помещения.
EAX 2.0 построен на возможностях первой версии и создаёт ещё более реалистичные эффекты засчёт поддержки преграждения и отражения звука, а также на улучшенной технологии определения направления звука.
EAX 3.0
* Контроль за ранними реверберациями и отражениями для каждого источника звука.
* Динамический переход между окружающими моделями.
* Улучшенная дистанционная модель для автоматического управления реверберацией и начальными отражениями в зависимости от положения источников звука относительно слушателя.
* Расчёты Ray-Tracing (отражение лучей) для получения параметров отражения для каждого источника звука.
* Отдельные отражения для дальних эхо.
* Улучшенное дистанционное представление, призванное заменить статические реверберационные модели.
EAX 3.0 совмещает вторую версию с более мощными возможностями. Новый уровень реализма достигается засчёт поддержки местных отражений, изолированных отражений, продолжительных переходов между звуковыми сценами и другими особенностями.
Вывод: по всему вышесказанному можно судить о том, что на сегодня EAX является очень перспективным и конкурентоспособным стандартом. Любой программист, несведующий в особенностях 3D звука сможет создавать реальные эффекты для своих игр с помощью пресетов. Что касается качества 3D звука, то оно вне конкуренции. Сейчас большинство игр не поддерживает (или поддерживает криво) такие эффекты, как преграждение и поглощение звука. Первой игрой, полностью поддерживающей EAX 2.0 обещает быть Unreal Tournament, если его не опередят. Там будет видно.
P.S. Я специально не стал сравнивать EAX с другими стандартами, как, например, A3D. Для этого нужны игры, поддерживающие одновременно и то и другое в полной форме. На сегодня таких игр нет.
Главное о чем стоит упомянуть это, что ваш хранитель экрана будет работать в фоновом режиме и он не должен мешать работе других запущенных программ. Поэтому сам хранитель должен быть как можно меньшего объема. Для уменьшения объема файла в описанной ниже программе не используется визуальные компоненты Delphi, включение хотя бы одного из них приведет к увеличению размера файла свыше 200кб, а так, описанная ниже программа, имеет размер всего 20кб!!!
Технически, хранитель экрана является нормальным EXE файлом (с расширением .SCR), который управляется через командные параметры строки. Например, если пользователь хочет изменить параметры вашего хранителя, Windows выполняет его с параметром "-c" в командной строке. Поэтому начать создание вашего хранителя экрана следует с создания примерно следующей функции:
Поскольку нам нужно создавать небольшое окно предварительного просмотра и полноэкранное окно, их лучше объединить используя единственный класс окна. Следуя правилам хорошего тона, нам также нужно использовать многочисленные нити. Дело в том, что, во-первых, хранитель не должен переставать работать даже если что-то "тяжелое" случилось, и во-вторых, нам не нужно использовать таймер.
Процедура для запуска хранителя на полном экране - приблизительно такова:
Во-первых, мы проинициализировали некоторые глобальные переменные (описанные далее), затем прячем курсор мыши и создаем окно хранителя экрана. Имейте в виду, что важно уведомлять Windows, что это - хранителя экрана через SystemParametersInfo (это выводит из строя Ctrl-Alt-Del чтобы нельзя было вернуться в Windows не введя пароль). Создание окна хранителя:
Теперь окна созданы используя вызовы API. Я удалил проверку ошибки, но обычно все проходит хорошо, особенно в этом типе приложения.
Теперь Вы можете погадать, как мы получим handle родительского окна предварительного просмотра ? В действительности, это совсем просто: Windows просто передает handle в командной строке, когда это нужно. Таким образом:
Как Вы видите, window handle является вторым параметром (после "-p").
Чтобы "выполнять" хранителя экрана - нам нужна нить. Это создается с вышеуказанным CreateThread. Процедура нити выглядит примерно так:
Нить просто заставляет обновляться изображения в нашем окне, спит на некоторое время, и обновляет изображения снова. А Windows будет посылать сообщение WM_PAINT на наше окно (не в нить !). Для того, чтобы оперировать этим сообщением, нам нужна процедура:
Если мышь перемещается, кнопка нажала, мы спрашиваем у пользователя пароль:
Это также демонстрирует использование registry на уровне API. Также имейте в виду как мы динамически загружаем функции пароля, используюя LoadLibrary. Запомните тип функции?
TVSSFunc ОПРЕДЕЛЕН как:
Теперь почти все готово, кроме диалога конфигурации. Это запросто:
Трудная часть -это создать диалоговый сценарий (запомните: мы не используем здесь Delphi формы!). Я сделал это, используя 16-битовую Resource Workshop (остался еще от Turbo Pascal для Windows). Я сохранил файл как сценарий (текст), и скомпилированный это с BRCC32:
Почти также легко сделать диалоговое меню:
После того, как пользователь выбрал некоторые установочные параметры, нам нужно сохранить их.
Загружаем параметры так:
Легко? Нам также нужно позволить пользователю, установить пароль. Я честно не знаю почему это оставлено разработчику приложений ! Тем не менее:
Мы динамически загружаем (недокументированную) библиотеку MPR.DLL, которая имеет функцию, чтобы установить пароль хранителя экрана, так что нам не нужно беспокоиться об этом.
TPCPAFund ОПРЕДЕЛЕН как:
(Не спрашивайте меня что за параметры B и C ! :-)
Теперь единственная вещь, которую нам нужно рассмотреть, - самая странная часть: создание графики. Я не великий ГУРУ графики, так что Вы не увидите затеняющие многоугольники, вращающиеся в реальном времени. Я только сделал некоторые ящики.
И последнее - глобальные переменные:
Затем исходная программа проекта (.dpr). Красива, а!?
Ох, чуть не забыл! Если, Вы используете SysUtils в вашем проекте (например фуекцию StrToInt) вы получите EXE-файл больше чем обещанный в 20k. :) Если Вы хотите все же иметь20k, надо как-то обойтись без SysUtils, например самому написать собственную StrToInt процедуру.
Если все же очень трудно обойтись без использования Delphi-форм, то можно поступить как в случае с вводом пароля: форму изменения параметров хранителя сохранить в виде DLL и динамически ее загружать при необходимости. Т.о. будет маленький и шустрый файл самого хранителя экрана и довеска DLL для конфигурирования и прочего (там объем и скорость уже не критичны).
Хочется немного осветить вопрос индексации сайта основными поисковиками (к которым относятся грозный и страшный Яндекс, рвущийся к лидерству уже и на просторах русскоязычного поиска Google, скатывающийся назад Рамблер, “всемирный” соперник Гугла Yahoo, ну и непонятно зачем все еще существующий Апорт ).
Проще всего рассмотреть скорость индексации на примере данного сайта. Сайту нет еще даже месяца, поэтому интересна динамика попадания страниц сайта в индекс (выдачу) поисковиков. Немного удивило то, что уже в день появления сайта на просторах всемирной сети (именно физического появления, т.е. момента, когда данные сайта стали доступны) Google каким-то образом успел проиндексировать несколько десятков страниц, и это при том, что сайт в “Google для вебмастеров” не вносился, вручную в Google не добавлялся, на сайт вообще была всего одна ссылка, правда на главной странице более-менее посещаемого (в том числе роботами) мини-портала .
Также в тот же день этот сайт был добавлен в Яндекс.вебмастер - якобы это ускоряет индексацию Яндексом. Как выяснилось - не ускоряет… вообще, складывается впечатление, что хоть какие-то обновления в базе Яндекса происходят раз в неделю, обычно в выходные, при том робот шарит по сайту стабильно - но почему-то на выдачу это никак не влияет.
Следом за Гугле, буквально через день, сайт заметил Яху, примерно столько же страниц - около 60. Несмотря на отстутствие в первые дни sitemap.xml (сейчас в нем чуть более 1600 страниц), Гугле уже за первую неделю проиндексировал более 500 страниц, а через 2.5 недели в базе было 1.5 тысячи страниц, то есть почти весь сайт. Примерно в это же время первые несколько страниц (а именно 4) появились в выдаче Яндекса - впечатляющая скорость. Да, сайт в первый же день был зарегистрирован в каталоге-рейтинге Рамблера, и через пару дней там появился, а вот в выдаче Рамблера до сих пор нет ни одной страницы (код счетчика стоит на каждой странице), Рамблер в этом плане отстает даже от Апорта, в котором уже есть несколько десятков страниц.
Яху меня несколько раз впечатлял скоростью индексации ссылок на сайт - показывал некоторые бэклинки буквально через час-два после их появления, просмотр бэклинков на Яндекс.вебмастер тоже немного порадовал - несмотря на то, что Яндекс знает всего 4 страницы сайта, но тем не менее он уже знает около 20 ссылок на сайт - то есть примерно 70% на данный момент… что не так уж плохо.
Ну вот собственно пока и все, надеюсь из этого коротенького обзора можно сделать кое-какие выводы о скорости попадания сайта в индекс (выдачу) основных поисковиков.
Множество владельцев малого бизнеса просто не имеют достаточно ресурсов для проведения рекламной компании, которая бы позволила раскрутить их интернет-ресурс. Именно для решения этой проблемы в интернете существует множество online сервисов, которые позволяют владельцу сайта самостоятельно (DIY, do-it-yourself) заняться популяризацией своей веб-странички.
На сайтах подобного рода специалисты по поисковой оптимизации могут дать вам множество полезных советов и рекомендаций. Эта статья предоставляет возможность мне поделиться с вами своим опытом в области поисковой оптимизации. Назовем эти рекомендации как "10 минут для поисковой оптимизации".
Эти советы будут полезны для каждого, у кого есть хотя бы несколько страничек, сверстанных на HTML, но все же главной темой данной статьи будет привлечение посетителей на вашу домашнюю страничку.
Первые шаги
Перед тем, как начать, следует рассмотреть несколько моментов, которые необходимо знать перед началом оптимизации. Только вот для этого может потребоваться и более 10-ти минут. Итак, следует учесть следующее:
Определитесь со своей целью:
99% из вас знают, какой именно товар вы собираетесь рекламировать, поэтому вам нужно только определиться с ключевыми словами, по которым посетитель и попадет на ваш сайт. Вот несколько полезных советов. Во-первых, нужно проанализировать статистику посещаемости сайта, чтобы узнать, по каким ключевым словам посетители попали на ваш сайт. Во-вторых, посетите сайт вашего конкурента, который широко известен в просторах интернета.
Посмотрите на заголовки нескольких его страничек и попытайтесь определить, какие именно ключевые слова используются. Также посмотрите исходный текст странички (в Internet Explorer'е его можно посмотреть с помощью пункта меню View (Вид) - > Source (Просмотр html-кода)) и скопируйте информацию, содержащуюся в META-тегах. На своей страничке же вы должны определиться с частотой (разумной) использования наиболее запрашиваемых ключевых слов.
Здесь очень важно заметить, что профессиональные оптимизаторы имеют у себя под рукой гораздо больше инструментов, да и информации для установки нужных ключевых слов (с высокой их частотой в тексте страницы).
Дизайн сайта - привлекателен ли он для покупателя?
Вот тут-то и находится один из подводных камней. Суть его в том, что непривлекательный дизайн сайта - это прямой путь к низкой посещаемости ресурса. Безусловно, на тему разработки юзабилити сайта (т. е его дизайна), написано очень много и книг, и статей. Но пусть в рамках данной статьи все аспекты юзабилити рассмотреть и не получиться, то несколько замечаний тут не помешает:
1. Избегайте использовать в цветовой гамме сайта необычные и странные цвета. В противном случае посетителю будет тяжело прочитать информацию на вашем ресурсе (красный текст на голубом фоне - вот вам и яркий пример ужасного дизайна). Также не рекомендуется использовать текст мелкого шрифта; старайтесь придерживаться размера шрифта в пределах от 10 до 12 (2 или 3 в Macromedia Dreamweaver).
2. Использование на сайте рекламных блоков (как графических, так и текстовых), будут только отвлекать ваших посетителей. К примеру, если вы продаете автомобили BMW, то рекламировать на сайте средство для повышения потенции "Виагра" будет очень некстати.
Каждый графический элемент на вашей страничке может как повышать, так и понижать доверие посетителей к вашему ресурсу. Старайтесь использовать это место на сайте очень мудро и пользователи это оценят.
10 минут на раскрутку
1. Проверка на спам
Перед началом работ по оптимизации одним из ключевых моментов является тот факт, для раскрутки своего сайта вам не следует использовать приемы, которые могут быть восприняты поисковой машиной как спам. Но самое неприятно в этом то, что вы можете об этом и не подозревать! Некоторые веб-мастера (с устаревшими знаниями о принципах работы поисковых машин) используют на веб-страницах скрытый текст. Они ошибочно полагают, что таким методом помогут сайту подняться в глазах поисковика. Но это в корне неверно и данный прием может только добавить проблем для поисковой оптимизации.
Для обнаружения скрытого текста нужно всего лишь с нажатой левой кнопкой мыши провести от начала до конца страницы. Выделив таким образом всю страничку, можно легко найти скрытый текст (как правило, цвет шрифта у скрытого текста совпадает с цветом фона странички) - он просто будет выглядеть как подсвеченный.
Также вам захочется проверить частоту ключевых слов, которые встречаются на страничке. В данном случае является недопустимым повторение 5-6 ключевых слов, которые расположены друг за другом. Таким образом поисковую машину уже не проведешь, так что лучше таких приемов не использовать.
Для получения более детальной информации о нечестных методах раскрутки, которые приводят только к негативным результатам, можно ознакомиться с документом: "Inspecting your Web Site for Spam."
2. Проверка на релевантность (значимость) сайта для поисковой машины
Очень важно для вашего ресурса всегда быть в фокусе у поисковика. Для примера, если ваш ресурс будет ассоциироваться с ключевой фразой "Продажа автомобилей BMW", то ссылка или информация о продаже недвижимости будет совершенно излишней. Имейте в виду, что большинство поисковых машин будут судить о вашем ресурсе именно в зависимости его тематики. А она в первую очередь зависит от текстовой информации, которая содержится на страницах вашего сайта.
3. Подбор правильного содержания сайта
Текстовая информация на вашем сайте является решающей для удержания на сайте человека, который только что на него зашел. К слову, что это так важно, хочу добавить, что у множества компаний есть свой профессиональный копирайтер, который и занимается контентом (информацией на сайте). Поэтому так важно при написании статей придерживаться ключевых слов, которые вы выбрали в качестве цели для поисковой оптимизации своего ресурса. Но, в свою очередь, размещать ключевые слова в тексте без связи с остальной информацией (т. е ключевые слова не соответствуют тематике статьи) - верный путь потерять посетителя вашего сайта.
Важное замечание: очень часто первые 25-30 слов вашего сайта - это то, что каждый поисковик будет использовать для его описанию. Постарайтесь использовать ваши ключевые слова внутри этой области, не забывая при этом, чтобы это самое описание выглядело разборчиво и наглядно.
4. Работа над заголовком сайта (Title)
В заголовок вашей странички очень желательно поместить те ключевые слова или фразы, которые наиболее полно характеризуют предмет рекламы на ней. Для примера: "Продажа автомобилей BMW - MeBMW.com" Для поисковых машин заголовок является очень важным, а ключевые слова (фразы) в нем только помогут выше подняться в рейтингах. Но здесь главное не переусердствовать и использовать ключевые слова в пределах разумного. Заголовок также играет большую роль и в релевантности сайта. Именно его содержание будет сравниваться с текстовой информацией (контентом) остальной части веб-страницы. Чем больше будет совпадений у заголовка страницы с ее контентом, тем более она будет значимой для поисковой машины.
6. Навигация сайта... Сделайте ее интуитивно понятной
Могу предположить, что вы, как и большинство, используете для навигации на своем сайте графические элементы или текстовые ссылки. Здесь вам один мой небольшой совет - создайте меню для навигации на своем сайте предпочтительнее в виде текстовых ссылок его разделы. А разместить его лучше внизу страницы - так удобнее для посетителя. Теперь, при добавлении разделов, вы их можете называть, используя ключевые слова/фразы для лучшей информативности описания вашего раздела. Для примера сравним два варианта меню:
Аксессуары к автомобилям BMW | Продажа автомобилей BMW | Подробнее о MyBMW.com
и как после этого смотрится вот такое:
Аксессуары | Продажа автомобилей | О нас
7. Проверьте работоспособность ссылок и орфографию/грамматику
Совсем уж не помешает еще разок проверить все ссылки на сайте и правописание. После чего, если вы уверены, что это уже окончательный вариант, можете смело загружать сайт в интернет.
Спешить нужно медленно
А что же дальше? Сейчас много поисковых машин предлагают такую платную услугу, как предоставление вашему новому веб-сайту постоянную или срочную индексацию. В противном случае неизвестно, когда же до него доберется поисковый паук и проиндексирует его в своей базе. Если же вы воспользуетесь услугой срочной индексации, что уже через пару дней можно пожинать плоды в виде посетителей. Правда, у каждой поисковой машины здесь свои сроки.
Но все же эта статья посвящена тем, у кого денег для такой услуги попросту нет (да и стоит она недешево, вот может с первой прибыли ею и воспользуемся). Тем не менее, если ваш сайт уже посетил поисковый робот и внес его в свою базу, то вам остается теперь только ждать, когда он опять посетит его вновь на предмет наличия нового материала. Вот поэтому так важно своевременно обновлять контент на сайте - добавлять новые статьи, заводить новые разделы и т.д. (все зависит от вашей фантазии и сообразительности).
Но что же делать, если же вы желаете уменьшить это время или если до вашего сайта робот еще и не добрался? Вот для этого и придется кропотливо регистрировать все ваши новые странички вручную на сайте поисковика. А перед регистрацией (первой или повторной) не помешает также внимательно ознакомиться с правилами, которые очень подробно расписаны у каждого поисковика. Так, на всякий случай.
В данной статье я бы хотел рассмотреть и сравнить между собой несколько способов раскрутки сайтов. Некоторые способы уже известны многим как быстрый путь к увеличению посещаемости сайта. Посмотрим так ли это на самом деле.
Достижение высоких позиций невозможно только редактируя meta-теги.
В свое время я прочел очень интересную книгу Стефана Ковея "7 привычек успешного человека". Мне в этой книге особенно понравился раздел "Персональная этика". В нем автор упоминает о том, как некоторые люди изо всех сил пытаются найти "быстрый и простой способ достичь успеха в жизни не работая и не совершенствуя свои профессиональные навыки".
Далее автор подводит итог: "Персональная этика - вещь иллюзорная и обманчивая. Вот поэтому пытаться достичь каких-либо значимых целей так просто и быстро так же утопично, как найти Эйфелеву башню на карте Мадрида".
Я думаю, что сказанное выше можно смело применить и к поисковой оптимизации: простых путей нет. Вот поэтому я считаю мифом, что раскрутить сайт можно только путем редактирования meta-тегов.
Почему meta-теги бессильны?
Все дело в том, что толком неизвестно насколько важными являются meta-теги для релевантности сайта. Да и вообще используют ли информацию из них поисковые машины.
Иначе обстоит дело с поиском внутри самого сайта. Вот здесь информация из meta-тегов как раз и помогает найти пользователю страничку на сайте с необходимой информацией. Или, по крайней мере, сузить количество возможных страниц до минимума.
К сожалению, разница между внутренним поиском и поиском с помощью поисковой машины (напр. той же Google) очень велика. Например, с помощью внутреннего поиска можно без проблем найти минимальное количество страничек, которые будут максимально соответствовать поисковому запросу. К тому же содержание сайта (контент) и meta-теги только помогут пользователю добраться до нужной ему информации.
С другой стороны, все главные поисковые машины интернета имеют свои базы данных, которые содержат информацию о всех интернет страничках, о которых они только знают. Они-то не всегда доверяют информации из meta-тегов, так как она запросто может отличаться от истинного содержания сайта. К примеру, вы как владелец сайта, желаете видеть свой сайт на верху результатов поиска по многим ключевым словам (фразам), но поисковик все равно поместит туда наиболее релевантные по данным ключевым словам сайты.
Вот по этой причине только изменять информацию в meta-тегах не приведет к росту рейтинга сайта и увеличению трафика.
И о контенте замолвим мы слово...
Бесспорно, вы можете наполнять свой сайт статьями любого содержания и тематики и надеяться на быстрый эффект. Но вот только написание хороших статей (т.е контента) требует времени и часто довольно много. Можно, конечно, потратить годы на написание статей, что в конечном итоге приведет к появлению довольно весомого архива полезной информации. Вот только у меня возникаю сомнения, что кто-то сможет писать 100 статей в неделю, да еще и интересных и полезных в информационном плане для посетителя. Тут нужно либо нахально воровать контент с других сайтов, либо пользоваться программами для его генерации, либо становиться роботом с множеством рук!
А как же ссылки?
Да, без сомнений, ссылки - это очень важный инструмент, который помогает вашему сайту хотя бы просто быть замеченным (проиндексированным) поисковой машиной. Вот только делается это не так и быстро, ввиду довольно большой инертности поисковиков. Да ведь играет еще и "вес" ссылающегося на вас сайта, а в данном случае лучше получит одну ссылки с сайта с PR=6-7, чем с сотни с PR=2-3. Но пока ваш сайт еще не раскручен, то крупные сайты вряд-ли поставят на ваш сайт ссылки. Зачем это им?
Так что лучше пока забудьте о популярности ссылки и вместо этого подумайте о привлечении на сайт целевой аудитории и как она узнает о существовании вашего сайта. Тут все проще пареной репы, как говорится. У вас есть сайт и вы занимаетесь бизнесом, который [лучше] [уникальнее] [качественнее] чем аналогичный у ваших конкурентов. Вам, естественно, нужно его заставить приносить прибыль. Не обязательно в вас должно быть много денег для рекламы вашего сайта.
Хорошая реклама в (пусть и не в самом популярной) газете, журнале или даже телепрограмме уже поможет обратить внимание на ваш ресурс. Ведь, чем популярнее сайт, тем о нем должны больше говорить. Можно даже использовать PPC (Paid per click, сервис показа баннеров с вашей рекламой с оплатой за клики), который поможет привлечь на ваш сайт заинтересованных посетителей.
Но, как бы вы не рекламировали свой сайт, не рассчитывайте на бум в течении суток.
А теперь снова вернемся к книге Стефана Ковея. Конечно, можно научиться быстро редактировать meta-теги и зарегистрировать сайт в тысячах поисковых машин, поставить свою ссылку на миллионах бесполезных сайтов. Тем не менее, если вы не потратите время на написание хорошего и уникального контента, который будет понятен и интересен посетителю, написан простыми словами без использования сленга, у вас никогда не будет долговременных положительных результатов.
Как достичь долговременных результатов
Одним из способов быстрой раскрутки есть оптимизация сайта под малоиспользуемые ключевые слов. Ваш ресурс-то будет высоко в поисковых рейтингах, да вот толку от этого маловато.
Но так как мы уже решили, что эффективная оптимизация - процесс довольно долгий, то следующие 5 советов помогут вам с пользой это время использовать.
1) Тщательно исследуйте нужные вам ключевые слова с помощью таких сервисов, как Wordtracker или KeywordDiscovery. Пусть эти сервисы и платные, но, как я считаю, чтобы заработать деньги, их нужно сначала потратить. Рано или поздно все к этому приходят. А вот как раз платные сервисы по анализу ключевых слов - совершенный инструмент раскрутки сайта.
2) Не перегружайте свой сайт графикой. Тут есть два недостатка: до сих пор толком неизвестно, как поисковые роботы обрабатывают графику; да и мало у кого из посетителей хватит терпения долго ждать загрузки вашей веб-странички.
3) Используйте понятный посетителю язык, на котором написана информация на сайте. Пусть посетителю будет понятно, что вы желаете ему рассказать. Не забывайте также оптимизировать текст под те ключевые слова, по которым вы желаете достичь высоких позиций в поисковиках.
4) Не лишним будет убедиться, что текст в теге "title" и в описании ссылки полностью сходится с контентом вашего сайта.
5) Будьте терпеливы и настойчивы. Как правило, нужно около 6-9 месяцев, чтобы получить стабильный трафик на ваш сайт с популярных поисковиков. Что поделать, так уж устроены поисковые алгоритмы - им нужно некоторое время, чтобы присмотреться к новым ресурсам. И тут не следует расстраиваться, лучше потратить время на наполнение сайта хорошим контентом.
И помните, что ваши труды по оптимизации - это работа на будущее. Как и все в этой жизни, если вы тратите время и деньги правильно и для конкретной цели, то ожидаемые результаты не заставят себя ждать.
Это поисковые системы, что в конечном итоге приведет вашего сайта до сведения потенциальных клиентов. Поэтому лучше знать, как эти поисковые системы фактически, и как они представляют информацию для потребителя начать поиск. В данной статье я бы хотел рассмотреть и сравнить между собой несколько способов раскрутки сайтов.
Существуют два вида поисковых систем. Первый роботами называемых сканеров или пауков. Поисковые машины использовать пауков для индексирования веб-сайтов.
Когда Вы отправляете страницах вашего сайта для поисковых систем, выполнив их требуется представления страницы Поисковая система паук будет индексировать весь сайт. "Спайдер" является автоматизированной программой, что осуществляется с помощью поисковой системы, системы.
Круговой посетителей веб-сайта, прочесть его содержимое на фактических сайте сайт Мета-теги, а также по ссылкам, что место соединения. Паук затем возвращается все, что информацию в центральный депозитарий, где данные индексируются. Он посетит каждой ссылки вы на сайте и индексировать эти сайты, а. Некоторые пауки будет индексировать только определенное количество страниц на сайте, тем не создавать сайт с 500 страницы!
Паук будет периодически возвращаться к местам для проверки любой информации, которая изменилась. Частота, с которой это происходит, определяется модераторами поисковой системой. Паук почти как книгу, где он содержит оглавление, Фактическое содержание и ссылки на все сайты, найденные в ходе обыска, и она может индексировать до миллиона страниц в день.
Пример : Excite, Lycos и Google еффект. Когда вы поисковую систему найти информацию, это фактически поиск по индексу, которые он сам создал и не ищут в Интернете. Разные поисковые системы производят различные рейтинги, потому что не во всех поисковых системах используется один и тот же алгоритм поиска индексов.
Одним из событий, поисковая система сканирует алгоритм является частота и расположение ключевых слов на веб-страницу, но может также обнаружить искусственное наполнение ключевыми словами или Поисковый спам. Затем алгоритмы анализа образом, чтобы страницы со ссылками на другие страницы в Интернете.
Установив, как страниц, ссылающихся друг друга, оба двигателя можно определить, о чем эта страница, если ключевые слова связаны страницы похожие на ключевые слова, по оригинальную страницу.
Поиск
