Фильтрация и проверка данных PHP. Частые ошибки

Материал предназначен в основном для начинающих веб-программистов.

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

Здесь я постараюсь описать как можно подробнее частые ошибки при фильтрации данных в PHP скрипте и дать простые советы как правильно выполнить фильтрацию данных.

В сети много статей по поводу фильтрации данных, но они как правильно не полные и без подробные примеров.

Разбор полетов.

Фильтрация. Ошибка №1

Для числовых переменных используется такая проверка:

$number = $_GET['input_number'];
if (intval($number))
{
... выполняем SQL запрос ...
}


Почему она приведет к SQL инъекции? Дело в том, что пользователь может указать в переменной input_number значение:
1'+UNION+SELECT


В таком случаи проверка будет успешно пройдена, т.к. функция intval получает целочисленное значение переменной, т.е. 1, но в самой переменной $number ничего не изменилось, поэтому весь вредоносный код будет передан в SQL запрос.
Правильная фильтрация:
$number = intval($_GET['input_number']);
if ($number)
{
... выполняем SQL запрос ...
}


Конечно, условие может меняться, например если вам нужно получить только определенный диапазон:
if ($number >= 32 AND $number <= 65)



Если вы используете чекбоксы или мультиселекты с числовыми значениями, выполните такую проверку:
$checkbox_arr = array_map('intval', $_POST['checkbox']);


array_map
Так же встречаю фильтрацию в виде:
$number = htmlspecialchars(intval($_GET['input_number']));

htmlspecialchars
Или:
$number = mysql_escape_string(intval($_GET['input_number']));


mysql_escape_string

Ничего кроме улыбки это не может вызвать :)

Фильтрация. Ошибка №2.

Для стринг-переменных используется такая фильтрация:
$input_text = addslashes($_GET['input_text']);


Функция addslashes экранирует спец. символы, но она не учитывает кодировку БД и возможен обход фильтрации. Не стану копировать текст автора, который описал данную уязвимость и дам просто ссылку Chris Shiflett (перевод можно поискать в рунете).

Используйте функцию mysql_escape_string или mysql_real_escape_string, пример:
$input_text = mysql_escape_string($_GET['input_text']);


Если вы не предполагаете вхождение html тегов, то лучше всего сделать такую фильтрацию:
$input_text = strip_tags($_GET['input_text']);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);

strip_tags — убирает html теги.
htmlspecialchars — преобразует спец. символы в html сущности.
Так вы защитите себя от XSS атаки, помимо SQL инъекции.
Если же вам нужны html теги, но только как для вывода исходного кода, то достаточно использовать:
$input_text = htmlspecialchars($_GET['input_text']);
$input_text = mysql_escape_string($input_text);



Если вам важно, чтобы значение переменной не было пустой, то используйте функцию trim, пример:
$input_text = trim($_GET['input_text']);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);



Фильтрация. Ошибка №3.

Она касается поиска в БД.
Для поиска по числам используйте фильтрацию, описанную в первой ошибке.
Для поиска по тексту используйте фильтрацию, описанную во второй ошибке, но с оговорками.
Для того, чтобы пользователь не смог выполнить логическую ошибку, нужно удалять или экранировать спец. символы SQL.
Пример без доп. обработки строки:
$input_text = htmlspecialchars($_GET['input_text']); // Поиск: "%"
$input_text = mysql_escape_string($input_text);


На выходе у нас получится запрос вида:
... WHERE text_row LIKE '%".$input_text."%' ... // WHERE text_row LIKE '%%%'


Это значительно увеличит нагрузку на базу.
В своём скрипте я использую функцию, которая удаляет нежелательные мне символы из поиска:
function strip_data($text)
{
    $quotes = array ("\x27", "\x22", "\x60", "\t", "\n", "\r", "*", "%", "<", ">", "?", "!" );
    $goodquotes = array ("-", "+", "#" );
    $repquotes = array ("\-", "\+", "\#" );
    $text = trim( strip_tags( $text ) );
    $text = str_replace( $quotes, '', $text );
    $text = str_replace( $goodquotes, $repquotes, $text );
    $text = ereg_replace(" +", " ", $text);
            
    return $text;
}


Конечно, не все из выше перечисленных символов представляют опасность, но в моём случаи они не нужны, поэтому выполняю поиск и замену.
Пример использования фильтрации:
$input_text = strip_data($_GET['input_text']);
$input_text = htmlspecialchars($input_text);
$input_text = mysql_escape_string($input_text);


Также советую сделать ограничение по количеству символов в поиске, хотя бы не меньше 3-х, т.к. если у вас будет большое количество записей в базе, то поиск по 1-2 символам будет значительно увеличивать нагрузку на БД.

Фильтрация. Ошибка №4.

Не фильтруются значения в переменной $_COOKIE. Некоторые думаю, что раз эту переменную нельзя передать через форму, то это гарантия безопасности.
Данную переменную очень легко подделать любым браузером, отредактировав куки сайта.
Например, в одной известной CMS была проверка, используемого шаблона сайта:
if (@is_dir ( MAIN_DIR . '/template/' . $_COOKIE['skin'] )){
	$config['skin'] = $_COOKIE['skin'];
}
$tpl->dir = MAIN_DIR . '/template/' . $config['skin'];


В данном случаи можно подменить значение переменной $_COOKIE['skin'] и вызвать ошибку, в результате которой вы увидите абсолютный путь до папки сайта.
Если вы используете значение куков для сохранения в базу, то используйте одну из выше описанных фильтраций, тоже касается и переменной $_SERVER.

Фильтрация. Ошибка №5.

Включена директива register_globals. Обязательно выключите её, если она включена.
В некоторых ситуациях можно передать значение переменной, которая не должна была передаваться, например, если на сайте есть группы, то группе 2 переменная $group должна быть пустой или равняться 0, но достаточно подделать форму, добавив код:
<input type="text" name="group" value="5" />


В PHP скрипте переменная $group будет равна 5, если в скрипте она не была объявлена со значением по умолчанию.

Фильтрация. Ошибка №6.

Проверяйте загружаемые файлы.
Выполняйте проверку по следующим пунктам:
1. Расширение файла. Желательно запретить загрузку файлов с расширениями: php, php3, php4, php5 и т.п.
2. Загружен ли файл на сервер move_uploaded_file
3. Размер файла

Проверка. Ошибка №1.

Сталкивался со случаями, когда для AJAX запроса (например: повышение репутации) передавалось имя пользователя или его ID (кому повышается репутация), но в самом PHP не было проверки на существование такого пользователя.
Например:
$user_id = intval($_REQUEST['user_id']);
... INSERT INTO REPLOG SET uid = '{$user_id}', plus = '1' ...
... UPDATE Users SET reputation = reputation+1 WHERE user_id = '{$user_id}' ...


Получается мы создаем запись в базе, которая совершенно бесполезна нам.

Проверка. Ошибка №2.

При выполнении различного рода действий (добавление, редактирование, удаление) с данными не забывайте проверять права пользователя на доступ к данной функции и дополнительные возможности (использование html тегов или возможность опубликовать материал без проверки).

Давно исправлял в одном модуле форума подобную ошибку, когда любой пользователь мог отредактировать сообщение администрации.

Проверка. Ошибка №3.

При использовании нескольких php файлов сделайте простую проверку.
В файле index.php (или в любом другом главном файле) напишите такую строчку перед подключением других php файлов:
define ( 'READFILE', true );


В начале других php файлов напишите:
if (! defined ( 'READFILE' ))
{
	exit ( "Error, wrong way to file.<br><a href=\"/\">Go to main</a>." );
}


Так вы ограничите доступ к файлам.

Проверка. Ошибка №4.

Используйте хеши для пользователей. Это поможет предотвратить вызов той или иной функции путём XSS.
Пример составления хеша для пользователей:
$secret_key = md5( strtolower( "http://site.ru/" . $member['name'] . sha1($password) . date( "Ymd" ) ) ); // $secret_key - это наш хеш


Далее во все важные формы подставляйте инпут со значением текущего хеша пользователя:
<input type="hidden" name="secret_key" value="$secret_key" />


Во время выполнения скрипта осуществляйте проверку:
if ($_POST['secret_key'] !== $secret_key)
{
exit ('Error: secret_key!');
}



Проверка. Ошибка №5.

При выводе SQL ошибок сделайте простое ограничение к доступу информации. Например задайте пароль для GET переменной:
if ($_GET['passsql'] == "password")
{
... вывод SQL ошибки ...
}
else
{
... Просто информация об ошибке, без подробностей ...
}


Это позволит скрыть от хакера информацию, которая может ему помочь во взломе сайта.

Проверка. Ошибка №5.
Старайтесь не подключать файлы, получая имена файлов извне.
Например:
if (isset($_GET['file_name']))
{
include $_GET['file_name'] .'.php';
}


Используйте переключатель switch:
switch($_GET['file_name'])
{         
         case 'file_1':
         include 'file_1.php';    
         break;     
         
         default:
         include 'file_0.php';    
         break;
}


В таком случаи вы предотвратите подключение файлов, которые не были вами предусмотрены.

Совет.

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

UPD: Поправил пост. Перенес все советы по поводу функций и переменных, которые были в комментариях.

Добавлено: 19 Ноября 2021 07:27:05 Добавил: Андрей Ковальчук

Tailwind CSS: за и против

По данным опроса The State of CSS 2020, больше всего разработчиков в мире, использующих CSS-фреймворки, сейчас заинтересованы в изучении и применении Tailwind CSS. Он опережает конкурентов в этом рейтинге уже второй год подряд. Команда Tailwind предлагает альтернативный подход для поддержки и стилизации HTML-разметки, но у него есть и свои противники. Проштудировав статьи и комментарии на таких ресурсах, как Dev.to, Product Hunt и Codeburst, мы собрали наиболее популярные доводы за и против использования этого фреймворка.

Концепт Tailwind CSS
Но сначала о том, чем Tailwind отличается от других CSS-фреймворков. Главное отличие — в том, что он не содержит какой-либо концепт дизайна, а предоставляет готовые классы, утилиты и директивы для стилизации и разметки HTML-тегов. Такой подход позволяет реализовать полностью настраиваемый дизайн компонентов без написания даже строчки пользовательского CSS-кода. Авторы фреймворка предполагают, что разработчики получат от этого следующие преимущества:

Не нужно тратить время на придумывание названий для CSS-классов.
CSS код почти не увеличивается в размерах, а все классы и утилиты используются многократно. Поэтому редко когда придется писать новый CSS-код.
Вносить изменения безопаснее. Не нужно переписывать CSS, если достаточно поменять классы в HTML.
Еще из полезных функций: тему можно настроить под свой проект, адаптивные утилиты Tailwind помогут создать полностью отзывчивый интерфейс, а наведение, фокус и другие состояния легко стилизовать с помощью служебных классов. Функция @apply при этом позволяет использовать Tailwind-классы для создания собственных переиспользуемых абстракций:

<!-- Using utilities -->
<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-500 hover:bg-green-700">
  Click me
</button>
 
<!-- Extracting classes using @apply -->
<button class="btn btn-green">
  Button
</button>
 
<style>
  .btn {
    @apply py-2 px-4 font-semibold rounded-lg shadow-md;
  }
  .btn-green {
    @apply text-white bg-green-500 hover:bg-green-700;
  }
</style>

За Tailwind CSS
Синтаксис
Синтаксис Tailwind очень прост: к элементам HTML или JSX добавляются имена классов. Вот как это выглядит на примере уведомления, созданного с помощью этого фреймворка:

<div class="max-w-sm mx-auto flex p-6 bg-white rounded-lg shadow-xl">
  <div class="flex-shrink-0">
    <img class="h-12 w-12" src="/img/logo.svg" alt="ChitChat Logo">
  </div>
  <div class="ml-6 pt-1">
    <h4 class="text-xl text-gray-900 leading-tight">ChitChat</h4>
    <p class="text-base text-gray-600 leading-normal">You have a new message!</p>
  </div>
</div>


Каждое имя класса содержит одно или несколько свойств CSS. Например, flex — это display: flex;, p-6 — padding: 1.5rem, mx-auto — margin-left: auto; margin-right: auto; и так далее. Этот подход очень прост и полезен, так как сложные компоненты строятся из ограниченного набора примитивных утилит.

Встроенная отзывчивость, псевдоклассы и стили
Отзывчивый дизайн, стилизация элементов и псевдоклассов, таких как hover, focus, active, доступны прямо в HTML-коде. Весь стиль определяется самим элементом. Это означает, что посмотрев на элемент, вы сразу поймете его стили. При этом вам не нужно открывать другой файл, чтобы редактировать CSS-правила.

По умолчанию Tailwind использует систему брейкпоинтов mobile first, аналогичную той, которая используется в других фреймворках, таких как Bootstrap.

Меньше CSS-кода
Размер CSS-кода не растет линейно. Имена классов совместно используются элементами, а это гарантирует постоянный размер пакета. Кроме того, Purge CSS удалит все неиспользуемые стили, поэтому кодовая база не будет перегружена.

Более высокая производительность
Написание классов Tailwind происходит быстрее, чем в CSS или CSS-in-JS. С использованием Tailwind верстка сводится к добавлению классов CSS к HTML-разметке.

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

Рассмотрим это на примере. В обычном CSS у нас было бы:

/* Small (sm) */
@media (min-width: 640px) { /* ... */ }
 
/* Medium (md) */
@media (min-width: 768px) { /* ... */ }
 
/* Large (lg) */
@media (min-width: 1024px) { /* ... */ }
 
/* Extra Large (xl) */
@media (min-width: 1280px) { /* ... */ }

Это может показаться легким для чтения. Однако представьте, что у вас есть сотни классов. Вскоре код может стать трудным для чтения и изменения.

Теперь посмотрим на Tailwind:

<!-- Width of 16 by default, 32 on medium screens, and 48 on large screens -->
<img class="w-16 md:w-32 lg:w-48" src="...">

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

Множество вариаций настройки проекта
Tailwind предоставляет разработчику рабочую тему по умолчанию, которая подойдет для множества проектов. Есть и возможность расширять или изменять настройки с помощью файла tailwind.config.js. Он также позволяет добавлять собственные плагины, что открывает целый мир возможностей для сторонних разработчиков.

Против Tailwind CSS
Создание сложных анимаций
Несмотря на то, что простые анимации включены в готовом виде, а другие можно добавить через конфигурацию, сложную анимацию в Tailwind очень сложно реализовать. Но проблему можно решить с помощью простого CSS, библиотеки анимации, такой как Framer Motion, или библиотеки CSS-in-JS, такой как Styled Components.

Уродливый HTML
Базовые классы содержат одно-два CSS-правила, поэтому может потребоваться много классов для стилизации отдельного тега. Это значит, что HTML-разметка будет выглядеть раздуто и неряшливо с эстетической точки зрения. Но не только эстетика может пострадать — во множестве классов, написанных в одну строку, будет легко запутаться.

Для наглядности посмотрите на пример ниже:

<div class="min-w-0 flex-auto space-y-0.5">
  <p class="text-lime-600 dark:text-lime-400 text-sm sm:text-base lg:text-sm xl:text-base font-semibold uppercase">
    <abbr title="Episode">Ep.</abbr> 128
  </p>
  <h2 class="text-black dark:text-white text-base sm:text-xl lg:text-base xl:text-xl font-semibold truncate">
    Scaling CSS at Heroku with Utility Classes
  </h2>
  <p class="text-gray-500 dark:text-gray-400 text-base sm:text-lg lg:text-base xl:text-lg font-medium">
    Full Stack Radio
  </p>
</div>

Для решения этой проблемы авторы фреймворка предлагают использовать @apply. Например в проектах, где большая часть HTML ориентирована на имена классов с компонентной областью видимости (что близко по концепции к методологии БЭМ), @apply широко используется. Но это подводит к следующему вопросу.

@apply принципиально несовместим и нестандартен
Проблемы возникнут, если попробовать отказаться от Tailwind. Везде, где классы были созданы с помощью @apply, они просто перестанут работать. Особенно это будет болезненно для проектов, использующих компонентный подход.

Избыточная сложность настроек
Токены дизайна Tailwind настраиваются с помощью сложной системы на JavaScript. Настройки темы Tailwind можно заменить настраиваемыми CSS-переменными (CSS Custom Properties), которые поддерживаются всеми браузерами, кроме Internet Explorer.

Tailwind CSS плохо работает через CDN
Минусы подключения через CDN:

Нельзя настроить тему
Нельзя использовать директивы: @apply, @variants и т.д.
Нельзя включить дополнительные варианты, такие как group-focus
Нельзя устанавливать сторонние плагины
Нельзя избавиться от неиспользуемых стилей
Это будет минусом для тех, кто привык не хранить у себя стандартный код. Единственный приемлемый вариант использования CDN — для прототипирования.

Tailwind забывает о существовании веб-компонентов
Tailwind полностью непригоден для использования в Shadow DOM. Некоторые предприимчивые разработчики придумали решения, в которых отдельные элементы стиля Tailwind можно внедрить в компоненты в процессе сборки, но это определенно “костыль”.

Вместо этого Tailwind поощряет суп с тегами div/span. Использование тегов <div> и <span> повсюду в разметке — это анти-шаблон. Пользовательские элементы полностью поддерживаются современными браузерами, и нет причин этим пренебрегать. Например вместо <div class = “card”> </div> можно написать <ui-card> </ui-card>.

Заключение
Tailwind как низкоуровневый фреймворк CSS — подходящее решение для стилизации. Он лишен множества недостатков, которые возникают в других решениях CSS. Tailwind повышает продуктивность, уменьшает размер файлов, ускоряет разработку.

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

Добавлено: 29 Июня 2021 07:37:08 Добавил: Андрей Ковальчук

Git за полчаса: руководство для начинающих

В последние годы популярность git демонстрирует взрывной рост. Эта система контроля версий используется различными проектами с открытым исходным кодом.

Новичков часто пугает большое количество замысловатых команд и сложных аргументов. Но для начала все они и не нужны. Можно начать с изучения наиболее часто используемых команд, и после этого постепенно расширять свои знания. Именно так мы и поступим в этой статье. Поехали!

Основы
Git — это набор консольных утилит, которые отслеживают и фиксируют изменения в файлах (чаще всего речь идет об исходном коде программ, но вы можете использовать его для любых файлов на ваш вкус). С его помощью вы можете откатиться на более старую версию вашего проекта, сравнивать, анализировать, сливать изменения и многое другое. Этот процесс называется контролем версий. Существуют различные системы для контроля версий. Вы, возможно, о них слышали: SVN, Mercurial, Perforce, CVS, Bitkeeper и другие.

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

Установка
Установить git на свою машину очень просто:

Linux — нужно просто открыть терминал и установить приложение при помощи пакетного менеджера вашего дистрибутива. Для Ubuntu команда будет выглядеть следующим образом:

sudo apt-get install git

Windows — мы рекомендуем git for windows, так как он содержит и клиент с графическим интерфейсом, и эмулятор bash.
OS X — проще всего воспользоваться homebrew. После его установки запустите в терминале:
brew install git

Если вы новичок, клиент с графическим интерфейсом(например GitHub Desktop и Sourcetree) будет полезен, но, тем не менее, знать команды очень важно.

Настройка
Итак, мы установили git, теперь нужно добавить немного настроек. Есть довольно много опций, с которыми можно играть, но мы настроим самые важные: наше имя пользователя и адрес электронной почты. Откройте терминал и запустите команды:

git config --global user.name "My Name"
git config --global user.email myEmail@example.com

Теперь каждое наше действие будет отмечено именем и почтой. Таким образом, пользователи всегда будут в курсе, кто отвечает за какие изменения — это вносит порядок.

Создание нового репозитория
Как мы отметили ранее, git хранит свои файлы и историю прямо в папке проекта. Чтобы создать новый репозиторий, нам нужно открыть терминал, зайти в папку нашего проекта и выполнить команду init. Это включит приложение в этой конкретной папке и создаст скрытую директорию .git, где будет храниться история репозитория и настройки.
Создайте на рабочем столе папку под названием git_exercise. Для этого в окне терминала введите:

$ mkdir Desktop/git_exercise/
$ cd Desktop/git_exercise/
$ git init

Командная строка должна вернуть что-то вроде:

Initialized empty Git repository in /home/user/Desktop/git_exercise/.git/

Это значит, что наш репозиторий был успешно создан, но пока что пуст. Теперь создайте текстовый файл под названием hello.txt и сохраните его в директории git_exercise.

Определение состояния
status — это еще одна важнейшая команда, которая показывает информацию о текущем состоянии репозитория: актуальна ли информация на нём, нет ли чего-то нового, что поменялось, и так далее. Запуск git status на нашем свежесозданном репозитории должен выдать:

$ git status
On branch master
Initial commit
Untracked files:
(use "git add ..." to include in what will be committed)
hello.txt

Сообщение говорит о том, что файл hello.txt неотслеживаемый. Это значит, что файл новый и система еще не знает, нужно ли следить за изменениями в файле или его можно просто игнорировать. Для того, чтобы начать отслеживать новый файл, нужно его специальным образом объявить.

Подготовка файлов
В git есть концепция области подготовленных файлов. Можно представить ее как холст, на который наносят изменения, которые нужны в коммите. Сперва он пустой, но затем мы добавляем на него файлы (или части файлов, или даже одиночные строчки) командой add и, наконец, коммитим все нужное в репозиторий (создаем слепок нужного нам состояния) командой commit.
В нашем случае у нас только один файл, так что добавим его:

$ git add hello.txt

Если нам нужно добавить все, что находится в директории, мы можем использовать

$ git add -A

Проверим статус снова, на этот раз мы должны получить другой ответ:

$ git status
On branch master
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
new file: hello.txt

Файл готов к коммиту. Сообщение о состоянии также говорит нам о том, какие изменения относительно файла были проведены в области подготовки — в данном случае это новый файл, но файлы могут быть модифицированы или удалены.

Коммит(фиксация изменений)
Коммит представляет собой состояние репозитория в определенный момент времени. Это похоже на снапшот, к которому мы можем вернуться и увидеть состояние объектов на определенный момент времени.
Чтобы зафиксировать изменения, нам нужно хотя бы одно изменение в области подготовки (мы только что создали его при помощи git add), после которого мы может коммитить:

$ git commit -m "Initial commit."

Эта команда создаст новый коммит со всеми изменениями из области подготовки (добавление файла hello.txt). Ключ -m и сообщение «Initial commit.» — это созданное пользователем описание всех изменений, включенных в коммит. Считается хорошей практикой делать коммиты часто и всегда писать содержательные комментарии.

Удаленные репозитории
Сейчас наш коммит является локальным — существует только в директории .git на нашей файловой системе. Несмотря на то, что сам по себе локальный репозиторий полезен, в большинстве случаев мы хотим поделиться нашей работой или доставить код на сервер, где он будет выполняться.

1. Подключение к удаленному репозиторию
Чтобы загрузить что-нибудь в удаленный репозиторий, сначала нужно к нему подключиться. В нашем руководстве мы будем использовать адрес https://github.com/tutorialzine/awesome-project, но вам посоветуем попробовать создать свой репозиторий в GitHub, BitBucket или любом другом сервисе. Регистрация и установка может занять время, но все подобные сервисы предоставляют хорошую документацию.
Чтобы связать наш локальный репозиторий с репозиторием на GitHub, выполним следующую команду в терминале. Обратите внимание, что нужно обязательно изменить URI репозитория на свой.

# This is only an example. Replace the URI with your own repository address.
$ git remote add origin https://github.com/tutorialzine/awesome-project.git

Проект может иметь несколько удаленных репозиториев одновременно. Чтобы их различать, мы дадим им разные имена. Обычно главный репозиторий называется origin.

2. Отправка изменений на сервер
Сейчас самое время переслать наш локальный коммит на сервер. Этот процесс происходит каждый раз, когда мы хотим обновить данные в удаленном репозитории.
Команда, предназначенная для этого - push. Она принимает два параметра: имя удаленного репозитория (мы назвали наш origin) и ветку, в которую необходимо внести изменения (master — это ветка по умолчанию для всех репозиториев).

$ git push origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 212 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://github.com/tutorialzine/awesome-project.git
* [new branch] master -> master

В зависимости от сервиса, который вы используете, вам может потребоваться аутентифицироваться, чтобы изменения отправились. Если все сделано правильно, то когда вы посмотрите в удаленный репозиторий при помощи браузера, вы увидите файл hello.txt

3. Клонирование репозитория
Сейчас другие пользователи GitHub могут просматривать ваш репозиторий. Они могут скачать из него данные и получить полностью работоспособную копию вашего проекта при помощи команды clone.

$ git clone https://github.com/tutorialzine/awesome-project.git

Новый локальный репозиторий создается автоматически с GitHub в качестве удаленного репозитория.

4. Запрос изменений с сервера
Если вы сделали изменения в вашем удаленном репозитории, другие пользователи могут скачать изменения при помощи команды pull.

$ git pull origin master
From https://github.com/tutorialzine/awesome-project
* branch master -> FETCH_HEAD
Already up-to-date.

Так как новых коммитов с тех пор, как мы склонировали себе проект, не было, никаких изменений доступных для скачивания нет.

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

Уже рабочая, стабильная версия кода сохраняется.
Различные новые функции могут разрабатываться параллельно разными программистами.
Разработчики могут работать с собственными ветками без риска, что кодовая база поменяется из-за чужих изменений.
В случае сомнений, различные реализации одной и той же идеи могут быть разработаны в разных ветках и затем сравниваться.
1. Создание новой ветки
Основная ветка в каждом репозитории называется master. Чтобы создать еще одну ветку, используем команду branch <name>

$ git branch amazing_new_feature

Это создаст новую ветку, пока что точную копию ветки master.

2. Переключение между ветками
Сейчас, если мы запустим branch, мы увидим две доступные опции:

$ git branch
amazing_new_feature
* master

master — это активная ветка, она помечена звездочкой. Но мы хотим работать с нашей “новой потрясающей фичей”, так что нам понадобится переключиться на другую ветку. Для этого воспользуемся командой checkout, она принимает один параметр — имя ветки, на которую необходимо переключиться.

$ git checkout amazing_new_feature

3. Слияние веток
Наша “потрясающая новая фича” будет еще одним текстовым файлом под названием feature.txt. Мы создадим его, добавим и закоммитим:

$ git add feature.txt
$ git commit -m "New feature complete.”

Изменения завершены, теперь мы можем переключиться обратно на ветку master.

$ git checkout master

Теперь, если мы откроем наш проект в файловом менеджере, мы не увидим файла feature.txt, потому что мы переключились обратно на ветку master, в которой такого файла не существует. Чтобы он появился, нужно воспользоваться merge для объединения веток (применения изменений из ветки amazing_new_feature к основной версии проекта).

$ git merge amazing_new_feature

Теперь ветка master актуальна. Ветка amazing_new_feature больше не нужна, и ее можно удалить.

$ git branch -d awesome_new_feature

Дополнительно
В последней части этого руководства мы расскажем о некоторых дополнительных трюках, которые могут вам помочь.

1. Отслеживание изменений, сделанных в коммитах
У каждого коммита есть свой уникальный идентификатор в виде строки цифр и букв. Чтобы просмотреть список всех коммитов и их идентификаторов, можно использовать команду log:
[spoiler title='Вывод git log']

$ git log
commit ba25c0ff30e1b2f0259157b42b9f8f5d174d80d7
Author: Tutorialzine
Date: Mon May 30 17:15:28 2016 +0300
New feature complete
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
commit 09bd8cc171d7084e78e4d118a2346b7487dca059
Author: Tutorialzine
Date: Sat May 28 17:52:14 2016 +0300
Initial commit
[/PLAIN]
Как вы можете заметить, идентификаторы довольно длинные, но для работы с ними не обязательно копировать их целиком — первых нескольких символов будет вполне достаточно. Чтобы посмотреть, что нового появилось в коммите, мы можем воспользоваться командой show
[PLAIN][spoiler title='Вывод git show']

$ git show b10cc123
commit b10cc1238e355c02a044ef9f9860811ff605c9b4
Author: Tutorialzine
Date: Mon May 30 16:30:04 2016 +0300
Added content to hello.txt
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?
[/PLAIN]
Чтобы увидеть разницу между двумя коммитами, используется команда diff (с указанием промежутка между коммитами):
[spoiler title='Вывод git diff']

$ git diff 09bd8cc..ba25c0ff
diff --git a/feature.txt b/feature.txt
new file mode 100644
index 0000000..e69de29
diff --git a/hello.txt b/hello.txt
index e69de29..b546a21 100644
--- a/hello.txt
+++ b/hello.txt
@@ -0,0 +1 @@
+Nice weather today, isn't it?
[/PLAIN]
Мы сравнили первый коммит с последним, чтобы увидеть все изменения, которые были когда-либо сделаны. Обычно проще использовать git difftool, так как эта команда запускает графический клиент, в котором наглядно сопоставляет все изменения.

2. Возвращение файла к предыдущему состоянию
Гит позволяет вернуть выбранный файл к состоянию на момент определенного коммита. Это делается уже знакомой нам командой checkout, которую мы ранее использовали для переключения между ветками. Но она также может быть использована для переключения между коммитами (это довольно распространенная ситуация для Гита - использование одной команды для различных, на первый взгляд, слабо связанных задач).
В следующем примере мы возьмем файл hello.txt и откатим все изменения, совершенные над ним к первому коммиту. Чтобы сделать это, мы подставим в команду идентификатор нужного коммита, а также путь до файла:

$ git checkout 09bd8cc1 hello.txt

3. Исправление коммита
Если вы опечатались в комментарии или забыли добавить файл и заметили это сразу после того, как закоммитили изменения, вы легко можете это поправить при помощи commit —amend. Эта команда добавит все из последнего коммита в область подготовленных файлов и попытается сделать новый коммит. Это дает вам возможность поправить комментарий или добавить недостающие файлы в область подготовленных файлов.
Для более сложных исправлений, например, не в последнем коммите или если вы успели отправить изменения на сервер, нужно использовать revert. Эта команда создаст коммит, отменяющий изменения, совершенные в коммите с заданным идентификатором.
Самый последний коммит может быть доступен по алиасу HEAD:

$ git revert HEAD

Для остальных будем использовать идентификаторы:

$ git revert b10cc123

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

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

// Use a for loop to console.log contents.
for(var i=0; i<arr.length; i++) {
console.log(arr[i]);
}
Тим предпочитает forEach:

// Use forEach to console.log contents.
arr.forEach(function(item) {
console.log(item);
});

Они оба коммитят свой код в соответствующую ветку. Теперь, если они попытаются слить две ветки, они получат сообщение об ошибке:

$ git merge tim_branch
Auto-merging print_array.js
CONFLICT (content): Merge conflict in print_array.js
Automatic merge failed; fix conflicts and then commit the result.

Система не смогла разрешить конфликт автоматически, значит, это придется сделать разработчикам. Приложение отметило строки, содержащие конфликт:
[spoiler title='Вывод']

<<<<<<< HEAD // Use a for loop to console.log contents. for(var i=0; i<arr.length; i++) { console.log(arr[i]); } ======= // Use forEach to console.log contents. arr.forEach(function(item) { console.log(item); }); >>>>>>> Tim's commit.
[/PLAIN]
Над разделителем ======= мы видим последний (HEAD) коммит, а под ним - конфликтующий. Таким образом, мы можем увидеть, чем они отличаются и решать, какая версия лучше. Или вовсе написать новую. В этой ситуации мы так и поступим, перепишем все, удалив разделители, и дадим git понять, что закончили.

// Not using for loop or forEach.
// Use Array.toString() to console.log contents.
console.log(arr.toString());
Когда все готово, нужно закоммитить изменения, чтобы закончить процесс:

$ git add -A
$ git commit -m "Array printing conflict resolved."

Как вы можете заметить, процесс довольно утомительный и может быть очень сложным в больших проектах. Многие разработчики предпочитают использовать для разрешения конфликтов клиенты с графическим интерфейсом. (Для запуска нужно набрать git mergetool).

5. Настройка .gitignore
В большинстве проектов есть файлы или целые директории, в которые мы не хотим (и, скорее всего, не захотим) коммитить. Мы можем удостовериться, что они случайно не попадут в git add -A при помощи файла .gitignore

Создайте вручную файл под названием .gitignore и сохраните его в директорию проекта.
Внутри файла перечислите названия файлов/папок, которые нужно игнорировать, каждый с новой строки.
Файл .gitignore должен быть добавлен, закоммичен и отправлен на сервер, как любой другой файл в проекте.
Вот хорошие примеры файлов, которые нужно игнорировать:

Логи
Артефакты систем сборки
Папки node_modules в проектах node.js
Папки, созданные IDE, например, Netbeans или IntelliJ
Разнообразные заметки разработчика.
Файл .gitignore, исключающий все перечисленное выше, будет выглядеть так:

*.log
build/
node_modules/
.idea/
my_notes.txt

Символ слэша в конце некоторых линий означает директорию (и тот факт, что мы рекурсивно игнорируем все ее содержимое). Звездочка, как обычно, означает шаблон.

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

Официальная документация, включающая книгу и видеоуроки – тут.
“Getting git right” – Коллекция руководств и статей от Atlassian – тут.
Список клиентов с графическим интерфейсом – тут.
Онлайн утилита для генерации .gitignore файлов – тут.
Оригинал статьи доступен на сайте http://tutorialzine.com

Добавлено: 22 Апреля 2021 07:16:54 Добавил: Андрей Ковальчук

Landing page или многостраничный сайт?

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

Если вы знакомы с продвижением в интернете, то слышали слово - Конверсия.

Конверсия - это соотношение общего числа посетителей сайта или страницы к тем посетителям, что выполнили на этом же сайте/странице какие-либо целевые действия.


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

Чаще всего структура у таких посадочных страниц следующая:

1. Шапка - чаще всего небольшой блок с лого, контактами.
2. Первый блок, основной - блок с основной информацией. Часто объединенный с шапкой. На нем располагается слоган, название товара или бренда. В большинстве случаев имеется кнопка призыва.
3. Второй блок - информация, описание подробно что к чему. Часто на нем располагается кнопка призыва если ее не было на предыдущем блоке, а иногда и независимо от этого.
4. Блок с преимуществами - почему мы, а никто другой.
5. Блок акции или призыва - новый блок с призывом заказать, купить, посмотреть.
6. Дополнительный инфо блок - в котором рассказывается подробно о всем или описывается процесс получение чего-то.
7. Блок с отзывами - тут важно размещать настоящие и правдивые отзывы.
8. Блок гарантий - размещаются гарантии, сертификаты, документы и тд.
9. Контакты - для возможности связаться или заказа. Может быть размещена карта с офисами - статичная или от Google, Yandex.
10. Подвал - обычный подвал как и остальных сайтов с копирайтом и другой информацией.

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

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

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

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

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

Я не раз встречал такое на своей практике у моих клиентов и других вебмастеров. Да и в далеком 2013 году, когда я решил создать этот сайт - он был одностраничником. Просто рекламой моих услуг для клиентов, которым я предлагал их. Через время я все переделал, перевел сайт на систему управления WordPress и наполнил его многим интересным материалом.

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

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

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

Таким образом, мы с вами пришли к тому что не всегда нужно выбирать что-то одно, возможно нужно искать компромисс. К тому же универсальность часто играет на руку и упрощает жизнь. Мой выбор, как раз на универсальном сайте. Рекомендую его и вам, но все же вам решать.

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

Думаю вы сделали выводы и определили для себя будущую стратегию. Надеюсь, моя статья помогла вам в решении и вы выбрали верный вариант.

Добавлено: 17 Апреля 2021 07:07:41 Добавил: Андрей Ковальчук

Обоснование необходимости хранилища данных

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

А теперь перечислим, для чего компании может понадобиться Хранилище:

Для выполнения серверных/дисковых задач, связанных с созданием запросов и отчетов на серверах/дисках, не используемых в системах обработки транзакций (oltp - online transaction processing)

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

Для использования моделей данных и/или серверных технологий, ускоряющих создание запросов и отчетов, но не предназначенных для обработки транзакций
Существуют методы моделирования данных, существенно сокращающие время выполнения запросов и отчетов (например схема "звезда"), но не предназначенные для обработки транзакций, так как лежащие в их основе технологии замедляют и усложняют oltp-процессы. Кроме того, некоторые серверные технологии хотя и повышают эффективность обработки запросов и отчетов, но замедляют обработку транзакций (например битовое индексирование - bit-mapped indexing), и наоборот (например восстановление транзакций). Причем влияние того или иного метода моделирования или серверной технологии меняется от поставщика к поставщику, а также в зависимости от того, в какой ситуации они применяются.

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

Для создания репозитория "очищенных" данных системы обработки транзакций и последующего получения отчетов из этих данных без изменения самой oltp-cистемы.

Типы ошибок, которые нужно устранить для "очистки" данных описаны в небольшой статье "Неформальная систематика ошибок в хранилище данных" (an informal taxonomy of data warehouse data errors). Хранилище дает возможность очистки данных без изменения систем обработки транзакций. Тем не менее, стоит обратить внимание на то, что в некоторых реализациях этой технологии предусмотрена возможность фиксировать исправления и затем переносить их обратно в oltp-системы. Иногда такой способ исправления ошибок удобнее, чем непосредственные изменения в системе обработки транзакций.

Для упрощения формирования запросов и отчетов по данным из нескольких систем обработки транзакций, а также из внешних источников данных и/или по данным, которые хранятся только для отчетности.

Долгое время для составления отчетов по данным из нескольких систем организации были вынуждены писать специальные процедуры извлечения данных и выполнять операции сортировки и объединения, а затем уже составлять отчеты по отсортированным (и/или объединенным) выборкам данных. Во многих случаях эта стратегия вполне адекватна. Но если организация хранит большой объем данных, требующих частой сортировки (объединения), а также "очистки", то лучше всего реализовать Хранилище.

Для создания репозитория данных oltp-системы, содержащего долговременную информацию, хранение которой в системе обработки транзакций не эффективно. Либо для генерации отчетов, отражающих ситуацию в предыдущие периоды
Чтобы не замедлять выполнение операций, старые данные часто удаляются из систем обработки транзакций. Однако для отчетности и составления запросов есть смысл держать эту информацию в Хранилище, где время отклика не так критично. Что касается отчетов по прошлым периодам, то их создание часто затруднено, а то и вовсе невозможно. Пусть, например, нужно получить информацию о зарплате сотрудников третьего разряда согласно сетке оплаты труда на начало каждого месяца 1997 года. Это оказывается невыполнимым, поскольку в базе данных хранятся записи только о текущем разряде сотрудников. Для решения подобного рода проблем удобно воспользоваться Хранилищем данных, поддерживается так называемое "медленно изменяющееся измерение".

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

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

В заключении повторим сказанное выше. Для того чтобы реализовать возможности business intelligence, а также получить более подробную информацию о клиентах и иметь хорошие "конкурентные преимущества", организации не достаточно просто разработать Хранилище данных. Необходимо решить (как правило методом проб и ошибок) не менее сложную задачу об оптимальном использовании Хранилища и последующем изменении практики деловых отношений.

Добавлено: 30 Июля 2018 20:19:07 Добавил: Андрей Ковальчук

Выявление нарушений авторских прав и работа с этой проблемой

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

С другой стороны, если у вас есть относительно новый сайт или сайт с небольшим количеством входящих ссылок, а плагиаторы постоянно стоят в рейтинге выше вас (или вашу работу крадет какой-то мощный сайт), то вы можете кое-что предпринять. Один из вариантов— отправить запрос о нарушении авторских прав (DMCA) в Google, Yahoo! и Bing (этот же запрос вам следует отправить и той компании, у которой размещен сайт).

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

Добавлено: 25 Июля 2018 07:56:46 Добавил: Андрей Ковальчук

Последствия дублированного контента

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

Пользователи хотят видеть в результатах разнообразие (а не одни и те же результаты снова и снова). Поэтому поисковые движки стараются отфильтровывать дублированный контент и это имеет следующие последствия:

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

- ссылки на страницы дублированного контента приводят к потере "сока ссылок". Дублированные страницы могут получить рейтинг PageRank или "сок ссылок", а поскольку он не помогает им в рейтинге, то этот "сок" теряется впустую;

- ни один из поисковых движков не дал четкого объяснения, как его алгоритм выбирает ту версию страницы, которую показывает. Иначе говоря, если он обнаруживает три копии одного и того же контента, то какие две из них он отфильтрует? Какую покажет? Зависит ли это от поискового запроса? В итоге поисковый движок может показать не ту версию, которая вам нужна.

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

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

Для исправления такого положения надо применить тег canonical ко всем версиям страницы, чтобы указать оригинальную версию.

Второй вариант может появиться тогда, когда вы синдицируете контент сторонним организациям. Проблема состоит в том, что поисковый движок может выкинуть из результатов поиска вашу копию и предпочесть ей версию, используемую тем человеком, который перепечатывает вашу статью. Лучшим средством исправления такой ситуации (кроме пометки тегом Noindex той копии, которую использует ваш партнер) является реализация партнером обратной ссылки на оригинальную страницу на вашем сайте. Поисковые движки практически всегда интерпретируют это правильно и выделяют вашу версию контента.

Добавлено: 25 Июля 2018 07:56:20 Добавил: Андрей Ковальчук

Уникальность и глубина контента

Никто не станет оспаривать ту ценность, которую поисковые движки придают надежному и уникальному контенту. В частности, Google уже провела несколько компаний по "вытряхиванию" сайтов с контентом низкого качества из своих индексов, причем другие движки также последовали ее примеру.

Первое, чего следует избегать, — это "тонкий контент". Этим словосочетанием обозначают такой контент, который поисковые движки считают дающим недостаточное количество уникального материала (и поэтому его не показывают в результатах поиска). Критерии никогда не обнародывались официально, но многие обсуждения с инженерами и представителями поисковых движков позволяют включить в этот список следующее:

- наличие от 30 до 50 уникальных слов, формирующих уникальные предложения, которых нет на других сайтах/страницах;

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

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

- уникальный контент в виде видео/аудио/изображений. Движки стали умнее при выявлении и индексировании страниц для вертикального поиска, которые раньше не могли бы пройти проверку на уникальность.

Добавлено: 25 Июля 2018 07:55:34 Добавил: Андрей Ковальчук

Текст документа

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

Фактически такая страница, которая перегружена многократным повторением ключевых слов (чтобы понравиться поисковым движкам), производит очень плохое впечатление на пользователя. В настоящее время некоторые специалисты по оптимизации призывают обращать внимание на "вес термина" (математическое уравнение, берущее свое начало в науке об информационном поиске) или на другие (еще более "модные") методы использования ключевых слов. Однако на практике почти всю оптимизацию можно выполнить очень просто.

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

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

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

Добавлено: 25 Июля 2018 07:54:47 Добавил: Андрей Ковальчук

Метатеги описания

Метаописания используются в следующих целях:

- чтобы дать точное и краткое описание контента страницы;

- чтобы служить кратким текстовым "анонсом" ваших страниц в результатах поиска;

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

Хорошие метаописания (подобно хорошим рекламным объявлениям) может быть написать непросто, но для нацеленных на ключевые слова страниц (особенно в конкурентных результатах поиска) они являются важнейшей составляющей частью привлечения трафика из поисковых движков на ваши страницы. Их важность гораздо выше для тех поисковых терминов, где намерение пользователя неясно (либо пользователи имеют различную мотивацию). Вот семь хороших правил для метаописаний.

Говорите правду.
Всегда честно описывайте свой контент. Если он не настолько привлекателен, как вам бы того хотелось, добавьте ему остроты; не заманивайте и не "заводите" пользователей, иначе у них будут плохие ассоциации с вашим брендом.

Будьте лаконичны.
Учитывайте ограничения по количеству символов. В настоящее время Google показывает до 160 символов, Yahoo! — до 165 символов, a Bing— до 200 с лишним (в некоторых случаях до 300). Придерживайтесь самого меньшего количества (как в Google) и следите за тем, чтобы эти описания не превышали 160 символов (включая пробелы).

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

Тестируйте, очищайте, промывайте и повторяйте.
Подобно рекламным объявлениям, вы можете протестировать метаописания результатами поиска, но при этом нужно быть внимательными. Вам нужно будет купить рекламу с оплатой за клики, чтобы узнать, какой тираж показов имели критические ключевые слова за определенный промежуток времени. Затем вы сможете использовать аналитику, чтобы увидеть, сколько кликов получено по этим ключевым словам, а также вычислить свой показатель кпикабельности.

Анализируйте психологию.
В отличие от рекламного объявления, мотивация для клика в результатах естественного поиска часто существенно отличается от той, которая имеется у пользователей, кликающих по платным результатам. Кликающие по платным рекламным объявлениям пользователи могут быть очень конкретно сосредоточены на покупке, а пользователи, кликающие по естественным результатам поиска, могут быть больше заинтересованы в изучении товара (или вашей компании). Не рассчитывайте, что удачный текст платного рекламного объявления будет хорошим метаописанием (или наоборот).

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

Не применяйте метаописания везде.
Метаописание нужно писать не всегда. Здравый смысл подсказывает, что лучше самому написать хорошее метаописание (чтобы максимизировать вероятность его показа в SERP), чем позволить поисковому движку создать Tajcoe описание из контента вашей страницы. Однако это не всегда верно. Если страница нацелена на один, два или три термина, часто используемых в поиске, то создавайте метаописание для тех пользователей, которые делают такой поиск.

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

Добавлено: 25 Июля 2018 07:53:56 Добавил: Андрей Ковальчук

Целевое использование ключевых слов

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

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

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

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

Поскольку ссылки и прочие факторы составляют значительную часть алгоритмов поисковых движков, то теперь движки не ставят в рейтингах страницу с 61 упоминанием слов free credit report выше страницы с 60 такими упоминаниями. На самом деле, "фаршировка" ключевыми словами (как это называется в мире оптимизации) может привести к падению ваших страниц в рейтингах (из-за накладываемых поисковыми движками штрафов). Движки не любят, когда с ними жульничают, они считают фаршировку ключевыми словами нечестной тактикой.

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

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

Добавлено: 25 Июля 2018 07:53:24 Добавил: Андрей Ковальчук

XML Sitemap

Компании Google, Yahoo! и Microsoft поддерживают протокол, известный как XML Sitemap. Google первой объявила его в 2005 г., а затем Yahoo! и Microsoft в 2006 г. согласились поддержать этот протокол. При помощи протокола Sitemap вы можете снабдить поисковые движки списком всех URL, которые вы бы хотели проиндексировать.

Добавление URL в файл Sitemap вовсе не является гарантией того, что этот URL будет просмотрен пауком или проиндексирован. Однако с его помощью можно просмотреть и проиндексировать те страницы, которые иначе не обнаруживаются и не индексируются. Кроме того, Sitemap помогает тем страницам, которые были переведены во вспомогательный индекс Google, вернуться обратно в главный индекс.

Эта программа является дополнением (а не заменой) обычного просмотра поискового движка по ссылкам. Преимущества Sitemap в следующем:

- для страниц, о которых поисковые движки уже знают вследствие регулярного их просмотра, используются предоставляемые вами метаданные, такие как дата последней модификации контента (lastmod date), частота изменений страницы (changefreq);

- для страниц, о которых движки не знают, используются предоставляемые вами дополнительные URL (для улучшения охвата просмотром);

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

- верификация/регистрация карт Sitemap может означать позитивный сигнал доверия/авторитета;

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

Инженер компании Google, который в форумах фигурирует как GoogleGuy (известный также как Matt Cutts, руководитель команды Google по web-спаму), объяснил протокол Sitemap компании Google следующим образом:

"Представьте себе, что на вашем сайте есть страницы А, В и С. Мы находим страницы А и В при помощи нормального просмотра по вашим ссылкам. Затем вы строите Sitemap и перечисляете в списке страницы В и С. Теперь появляется шанс, что мы просмотрим и страницу С, но мы этого не обещаем. Мы не выбросим страницу Л только потому, что вы не включили ее в список вашей Sitemap. И само включение в список страницы, о которой мы не знали, не гарантирует Того, что мы просмотрим ее. Но если по какой-то причине мы не видим никаких ссылок на С, либо мы знаем о странице С, но URL был отвергнут из-за слишком большого количества параметров или по другой причине, то появляется шанс, что мы просмотрим страницу С".

Sitemap использует простой формат XML, о котором вы можете прочитать по адресу http://www.sitemaps.org. Sitemap — это полезный, а в некоторых случаях просто необходимый инструмент для вашего web-сайта. В частности, если у вас есть причина думать, что сайт не проиндексирован полностью, то Sitemap может помочь вам увеличить количество проиндексированных страниц. По мере того, как сайты растут в размерах, ценность файлов Sitemap существенно увеличивается (поскольку на новые включенные в них URL поступает дополнительный трафик).

Добавлено: 25 Июля 2018 07:50:50 Добавил: Андрей Ковальчук

Сделайте конкурентный анализ

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

1. Проанализируйте web-сайты ваших конкурентов и посмотрите, какие ключевые

фразы они используют для своих товаров и услуг (конкурирующих с вашими).

2. Запишите те термины, которые они используют для своего бизнеса.

3. Прочитайте все статьи, которые они написали и опубликовали на других сайтах.

4. Обратите внимание на то, что о них говорили в средствах массовой информации.

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

Вы можете спросить — зачем эти хлопоты? Разве специальные инструменты для ключевых слов не сделают все это за вас?

Есть две причины, почему эти дополнительные усилия так важны:

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

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

После выполнения этих шагов у вас в руках окажется богатый набор терминов. Следующий шаг — это расширение диапазона собранных терминов при помощи инструментов изучения ключевых слов.

Добавлено: 25 Июля 2018 07:47:58 Добавил: Андрей Ковальчук

Важность анализа ключевых слов

Еще один важный компонент аудита архитектуры — это анализ ключевых слов. Он включает в себя 4 основных шага.

Шаг 1 — изучение ключевых слов.
Чрезвычайно важно сделать это как можно раньше. Ключевые слова являются движущей силой оптимизации страниц, поэтому вам нужно знать, какие именно использовать.

Шаг 2 — архитектура сайта.
Создание архитектуры сайта может быть очень сложным. На данной стадии вам нужно посмотреть на результаты изучения ключевых слов и на уже существующий сайт, чтобы производить как можно меньше изменений. Представьте себе этот процесс как карту вашего сайта. Вам нужна такая иерархия, которая ведет ко всем вашим "денежным страницам" (т. е. к тем страницам, на которых происходят конвертации). Понятно, что хорошая иерархия сайта позволяет родителям ваших "денежных страниц" иметь рейтинг по релевантным ключевым словам (которые, скорее всего, низкочастотные).

Большинство товаров имеют совершенно очевидную иерархию, в которую они укладываются, но когда вы начинаете говорить о том, что имеет несколько естественных иерархий, то все становится невероятно сложно. По нашему мнению, самые сложные иерархии получаются тогда, когда в них участвует местоположение. В одном только Лондоне, например, есть районы города, муниципальные районы, станции подземки, а также почтовые коды. Лондон даже имеет в своем составе отдельную центральную часть (Лондон-сити).

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

Шаг 3 — соответствие ключевым словам.
После того как вы получите список ключевых слов и хорошее представление об общей архитектуре, начинайте устанавливать соответствие между основными релевантными ключевыми словами и URL (а не наоборот). В таком случае будет достаточно легко найти такие места, которые вы не считали нацеленными на ключевые слова, и что более важно, найти такие ключевые слова, которые не имеют страницы.

Необходимо отметить, что между шагами 2 и 3 вы должны будете удалить все бесполезные страницы.

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

Шаг 4 — анализ сайта.
После того как вы получите соответствие ключевым словам, остальная часть анализа сайга становится гораздо легче. И теперь, когда вы посмотрите на теги названий и заголовки, то сможете обратиться к соответствию ключевых слов и не только увидеть, есть ли заголовок в теге h1, но также увидеть, содержит ли он правильные ключевые слова.

Добавлено: 25 Июля 2018 07:44:55 Добавил: Андрей Ковальчук

Наш король — контент

Чтобы определить желаемую аудиторию вашего web-сайта, необходимо понять, с кем же вы хотите установить контакт, а для этого требуется понимание того, что вы можете предложить посетителям вашего сайта (как сейчас, так и в будущем).

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

Имеющийся в вашем распоряжении контент будет влиять на ваши ключевые слова и архитектуру сайта, поскольку контент вашего сайта— это главный источник информации, который используют поисковые движки для определения, о чем же ваш сайт. Релевантный контент вам нужен даже для того, чтобы просто быть "в игре" (т. е. в поиске). Если кто-то будет искать Iefthanded golf clubs, а у вас нет никакого контента на эту тему, то, скорее всего, вы не будете иметь хорошего рейтинга по этому запросу.

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

Рассмотрим сайт А, который собрал солидный комплект статей по определенной теме. Однако есть еще 20 сайтов, которые имеют такой же солидный комплект статей по этой же теме, и многие из этих сайтов находятся в индексах основных поисковых движков гораздо дольше, чем сайт А.

У сайта А серьезная проблема! Зачем кому-то на него ссылаться? У него нет ничего нового. Возможно, что сайту А и удастся получить несколько ссылок на свои статьи, однако он, вполне вероятно, никогда не утвердится как лидер (поскольку не может предложить ничего нового).

Чтобы стать лидером, сайт А должен принести на рынок что-то новое и уникальное. Может быть, он сможет предложить решение для такой проблемы, которую раньше не мог решить никто другой. Или, возможно, он имеет такой же контент, что и конкуренты, но первым поместил видео высокого качества по данной теме. А возможно, он фокусируется на специфичной вертикальной нише и является лидером в этой конкретной нише.

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

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

В итоге критически важной частью планирования оптимизации является приведение в соответствие оптимизации и бизнес-целей web-сайта с имеющимися средствами на добавление нового контента, а также расстановка приоритетов в списке возможностей (чтобы оценить потенциал возврата инвестиций).

Добавлено: 25 Июля 2018 07:42:50 Добавил: Андрей Ковальчук