Что такое DNS

DNS (англ. Domain Name System — система доменных имён) — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).

Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.

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

Начиная с 2010 года, в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.

Ключевые характеристики DNS

DNS обладает следующими характеристиками:
Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности и (возможно) адреса корневых DNS-серверов.
Кеширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.

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

DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.

Терминология и принципы работы

Ключевыми понятиями DNS являются:
Доме́н (англ. domain — область) — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются), то есть именованная ветвь или поддерево в дереве имен. Структура доменного имени отражает порядок следования узлов в иерархии; доменное имя читается слева направо от младших доменов к доменам высшего уровня (в порядке повышения значимости), корневым доменом всей системы является точка ('.'), ниже идут домены первого уровня (географические или тематические), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org домен первого уровня — org, второго wikipedia, третьего ru). На практике точку в конце имени часто опускают, но она бывает важна в случаях разделения между относительными доменами и FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена).
Поддомен (англ. subdomain) — подчинённый домен (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.
Ресурсная запись — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных, формат и содержание которого зависит от типа.
Зона — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах (см. ниже). Целью выделения части дерева в отдельную зону является передача ответственности (см. ниже) за соответствующий домен другому лицу или организации. Это называется делегированием (см. ниже). Как связная часть дерева, зона внутри тоже представляет собой дерево. Если рассматривать пространство имен DNS как структуру из зон, а не отдельных узлов/имен, тоже получается дерево; оправданно говорить о родительских и дочерних зонах, о старших и подчиненных. На практике, большинство зон 0-го и 1-го уровня ('.', ru, com, …) состоят из единственного узла, которому непосредственно подчиняются дочерние зоны. В больших корпоративных доменах (2-го и более уровней) иногда встречается образование дополнительных подчиненных уровней без выделения их в дочерние зоны.
Делегирование — операция передачи ответственности за часть дерева доменных имен другому лицу или организации. За счет делегирования в DNS обеспечивается распределенность администрирования и хранения. Технически делегирование выражается в выделении этой части дерева в отдельную зону, и размещении этой зоны на DNS-сервере (см. ниже), управляемом этим лицом или организацией. При этом в родительскую зону включаются «склеивающие» ресурсные записи (NS и А), содержащие указатели на DNS-сервера дочерней зоны, а вся остальная информация, относящаяся к дочерней зоне, хранится уже на DNS-серверах дочерней зоны.
DNS-сервер — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. DNS-сервер может быть ответственным за некоторые зоны и/или может перенаправлять запросы вышестоящим серверам.
DNS-клиент — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента.
Авторитетность (англ. authoritative) — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные (англ. Non-authoritative), когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кеширования).
DNS-запрос (англ. DNS query) — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным (см. Рекурсия).

Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.

Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.

Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.[1]

Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется для AXFR-запросов.

Рекурсия

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

DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.

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

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

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

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
браузер отправил известному ему DNS-серверу рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо пустой ответ и код ошибки NXDOMAIN;
DNS-сервер, получивший запрос от браузера, последовательно отправлял нерекурсивные запросы, на которые получал от других DNS-серверов ответы, пока не получил ответ от сервера, ответственного за запрошенную зону;
остальные упоминавшиеся DNS-серверы обрабатывали запросы нерекурсивно (и, скорее всего, не стали бы обрабатывать запросы рекурсивно, даже если бы такое требование стояло в запросе).

Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.

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

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

Что такое dependency injection

Если вы занимаетесь разработкой программного обеспечения хотя бы какое-то время, вы, скорее всего, уже натыкались на термин «dependency injection» или «внедрение зависимости». Если вы ещё только-только присоединились к миру разработки ПО, то, вероятно, пока старались избегать попыток разобраться с этой концепцией. Но что бы вам ни казалось, внедрение зависимости является отличным инструментом при разработке поддерживаемого и тестируемого кода. В сегодняшней статье автор попытается рассказать, что же такое dependency injection настолько просто, насколько он сможет.
Injection



Рассмотрим простой кусок кода:

class Photo {
   /**
    * @var PDO Подключение к БД
    */
   protected $db;
 
   /**
    * Конструктор
    */
   public function __construct()
   {
      $this->db = DB::getInstance();
   }
}

На первый взгляд, всё просто и безобидно. Да, если не обращать внимания на тот факт, что в класс уже жёстко внедрена зависимость в виде подключения к БД. Что мы будем делать, если понадобиться хранить фотографии не в базе данных, а, скажем, на диске? Да и вообще, подумайте, с какого перепугу объект фотографии должен осуществлять изнутри себя какое-либо взаимодействие с внешним миром? Разве это не противоречит принципу разделения ответственности? Однозначно противоречит. Объект не должен знать ни о чём другом, кроме того, что касается непосредственно самого объекта.

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

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

Внедрение в конструкторе

class Photo {
   /**
    * @var PDO Подключение к БД
    */
   protected $db;
 
   /**
    * Конструктор
    *
    * @param PDO $dbConn Подключение к БД
    */
   public function __construct($dbConn)
   {
      $this->db = $dbConn;
   }
}
 
$photo = new Photo($dbConn);

В приведённом примере внедрение зависимости происходит в момент создания экземпляра объекта, вместо того, чтобы жёстко внедрять зависимость в классе.

Внедрение методом

class Photo {
   /**
    * @var PDO Подключение к БД
    */
   protected $db;
 
   /**
    * Конструктор
    */
   public function __construct($dbConn) {};
 
   /**
    * Внедряет подключение к БД
    *
    * @param PDO $dbConn Подключение к БД
    */
   public function setDB($dbConn)
   {
      $this->db = $dbConn;
   }
}
 
$photo = new Photo;
$photo->setDB($dbConn);

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

Проблема

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

$photo = new Photo;
$photo->setDB($dbConn);
$photo->setConfig($config);
$photo->setResponse($response);

Упс. Вместо того, чтобы облегчить жизнь, мы добавили лишней сложности. Если раньше пользователь просто создавал объект и работал с ним, то теперь ему придётся изрядно потанцевать с бубном, прежде чем двигаться дальше.

Решение

Решение заключается в том, чтобы создать отдельный класс-контейнер, который будет делать за нас всю тяжёлую работу. Если вы когда-нибудь сталкивались с термином Inversion of Control (IoC) — инверсия управления, то вы, вероятно, в курсе, о чём речь.

Класс-контейнер хранит информацию обо всех зависимостях, присутствующих в проекте, и выполняет всю работу по созданию зависимых объектов, а также внедрению в них зависимостей. Можно разными способами реализовать этот подход, мы же пока ясности ради реализуем всё прямо в методах класса-контейнера:

class IoC {
   /**
    * @var PDO Соединение с БД
    */
   protected $db;
 
   /**
    * Создаёт экземпляр Photo и внедряет зависимости
    */
   public static newPhoto()
   {
      $photo = new Photo;
      $photo->setDB(static::$db);
      $photo->setConfig();
      $photo->setResponse();
      return $photo;
   }
}
 
$photo = IoC::newPhoto();

Теперь всё вернулось на круги своя: одним-единственным вызовом метода класса-контейнера мы получаем полностью готовый к употреблению экземпляр объекта Photo.

Лучшим решением, всё-таки, будет более общее решение класса-контейнера:

class IoC {
   /**
    * @var Реестр
    */
   protected static $registry = array();
 
   /**
    * Добавляет resolver
    *
    * @param  string $name Идентификатор
    * @param  object $resolve Создатель объектов
    * @return void
    */
   public static function register($name, Closure $resolve)
   {
      static::$registry[$name] = $resolve;
   }
 
   /**
    * Создаёт экземпляр объекта
    *
    * @param  string $name Идентификатор resolver'a
    * @return mixed
    */
   public static function resolve($name)
   {
      if ( static::registered($name) )
      {
         $name = static::$registry[$name];
         return $name();
      }
      throw new Exception('Нет у нас такого в наличии :(');
   }
 
   /**
    * Определяет, зарегистрирован ли resolver
    *
    * @param  string $name ID resolver'а
    * @return bool
    */
   public static function registered($name)
   {
      return array_key_exists($name, static::$registry);
   }
}

Данный класс предоставляет возможность регистрировать резолверы (функции, выполняющие непосредственную работу по созданию объектов и внедрению зависимостей) при помощи метода register() и позднее использовать метод resolve() для того, чтобы получать экземпляры объектов классов. Например, зарегистрируем резолвер для нашего класса Photo:

// Добавляем резолвер 'photo' в реестр
IoC::register('photo', function() {
   $photo = new Photo;
   $photo->setDB('...');
   $photo->setConfig('...');
   return $photo;
});

И теперь там, где нам нужен экземпляр объекта, получаем его простым и понятным способом:

// Получаем экземпляр Photo, полностью готовый к работе
$photo = IoC::resolve('photo');

Теперь оба зайца убиты: зависимости вынесены за пределы класса, при этом сохранилась простота работы с ним. Немножко добавилось писанины:

// До
$photo = new Photo;
 
// После
$photo = IoC::resolve('photo');

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

Магические методы

Если пойти ещё дальше, желая минимизировать и упростить сам класс-контейнер, можно задействовать магические методы __set() и __get():

class IoC {
   protected $registry = array();
 
   public function __set($name, $resolver)
   {
      $this->registry[$name] = $resolver;
   }
   public function __get($name)
   {
      return $this->registry[$name]();
   }
}

Теперь добавлять и использовать резолверы стало намного интуитивно-понятнее:

$c = new IoC;
$c->mailer = function() {
  $m = new Mailer;
 
  // Настраиваем объект, внедряем зависимости
 
  return $m;
};
 
$mailer = $c->mailer; // И получаем экземпляр

Что такое CSS, основы css и html

Как вы помните HTML - это язык разметки, но его создатели так хотели улучшить жизнь сайтостроителей, что добавляли в него элементы и параметры, отвечающие за внешний вид страницы: теги <font>, <b>, <i>, <bgcolor> и так далее.

Но на какой-то момент код страниц стал таким громоздким и нечитабельным, что стало ясно - этот путь ведет "в никуда". Тогда было принято решение разделить разметку страницы (HTML) и ее визуальное оформление (CSS). В совокупности HTML и CSS позволяют творить чудеса и в этом вы скоро убедитесь.

Что такое CSS

CSS (Cascading Style Sheets) - каскадные таблицы стилей.

Стиль - набор параметров, задающий внешнее представление объекта. Например, пусть мы хотим, чтобы все заголовки первого уровня (теги <h1>) на одной странице имели красный цвет, размер - 24 и были написаны курсивом, а на другой странице были бы синего цвета, размера - 12. Наш заголовок - это объект, а цвет, размер и начертание - это параметры. Просто параметры нашего объекта для разных страниц разные, т.е. они отличаются стилем.

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

Если для одного элемента задано несколько стилей (как в примере с заголовками), то применяется каскадирование, которое определяет приоритет того или иного стиля.

Преимущества CSS

• CSS позволяет значительно сократить размер кода и сделать его читабельным.

• CSS позволяет задавать такие параметры, которые нельзя задать только языком HTML. Например, убрать подчеркивание у ссылок.

• CSS позволяет легко изменять внешний вид страниц. Представьте, вы сделали сайт из 50 страниц, на которых все заголовки синего цвета. Через какое-то время, вы захотели поменять синий цвет на зеленый. Вам придется пройтись по всем 50 страницам и поменять цвет в соответствующем атрибуте. С CSS вам придется сделать это лишь один раз, в таблице стилей.

• С CSS связана так называемая блочная верстка сайта.

Что такое #13#10?

Несомненно, вы много раз видели в Delphi-коде нечто "#13#10". Если вы не знаете, что это такое и каждый раз удивляетесь, то здесь вы узнаете ответ.

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

К примеру, если вы хотите сделать текст (Caption) элемента TLabel в две строки, то это можно сделать следующим образом:

Label1.Caption := 'Первая строка' + #13#10 + 'Вторая строка';  

Комбинация "#13#10" - это комбинация возврата каретки и символа новой строки. "#13" - это ASCII-эквивалент значения CR (carriage return - возврат каретки); "#10" представляет собой LF (line feed - признак новой строки).

Также наиболее интересными управляющими символами являются:
#0 - NULL-символ (нулевой);
#9 - <Tab> (символ табуляции).

Что слышат разработчики и дизайнеры

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

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

-Они также сомневаются, что улучшение доступности веб-контента выгодно всем. Некоторые выгодны – в качестве классического примера приведем субтитры, которые часто бывают удобны для тех, кто может слышать. Но поскольку никто, кажется, не приводит других примеров, то примерно с таким же успехом можно было бы доказывать, что космическая программа была полезна, потому что благодаря ей у нас есть «Тенг». И разработчикам, и дизайнерам намного легче представить себе случаи, когда адаптация, призванная улучшить доступность веб-контента, скорее лишь затрудняет восприятие для «всех остальных».

Хуже всего в этом скепсисе то, что он заслоняет собою тот факт, что лишь одна причина имеет значение:
-Это правильно.

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

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

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

Что случилось с PNG?

Помните тэг <marquee>? Одним тэгом можно было встроить в страницу бегущую строку, но людям эта идея не понравилось, и этот тэг почти не используется. А VRML - язык моделирования трехмерных объектов? Много ли вы найдете сайтов, где он используется? А как насчет PNG?

Ведь PNG, вроде как отличная штука?

PNG (Portable Network Graphics) был (и есть) одним из величайших событий, когда либо произошедших в мире веб-графики, но и это не помешало ему стать забытым и почти не используемым графическим форматом.

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

Когда был создан графический формат GIF, его сразу стали использовать везде, где это только было возможно. Да это и не удивительно, ведь новый формат для того времени был действительно отличный; он использовал алгоритм сжатия графической информации, разработанный когда-то фирмой Unisys. Но когда внезапно стали без счета появляться веб-странички с использованием картинок в GIF, Unisys'овцы решили поскорее лицензировать свой графический формат. Все заговорили о том, каким образом придется платить этой фирме за использование GIF. Придется ли платить каждый раз, как вы помещаете изображение на сервер? Или каждый раз, когда пользователь увидит это изображение? При этом большинство все же продолжало использовать GIF в ожидании, пока все немного поутихнет.

Но не все люди привыкли ждать, пока что-то произойдет само собой. Так, группа профессионалов в области графических компьютерных изображений решила найти достойную замену GIF'у. Надо было создать формат, который бы не являлся чьей-то собственностью, который мог бы бесплатно использовать каждый. Кроме того к тому времени в GIF'е нашлись недостатки. Например, палитра из 255 цветов уже явно устарела, хотелось использовать все доступные 24 бита. Да и компрессия могла бы быть значительно лучше.

Их решение проблемы было следующим: они достаточно быстро разработали формат с открытым кодом (open source), т.е. каждый мог использовать его как и где хотел. Они разработали спецификацию формата, который генерировал файлы меньшего чем GIF размера, которые могли содержать 24- или 8-битное изображение. Кроме того, PNG "умел" много такого, что GIF'у и не снилось.

Но многие вспомнили происшествие с GIFом, испугались высокого налога на использование формата. Все это время PNG существовал и поддерживался браузерами но... никто его не использовал.

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

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

Что следует помещать в теге <title>?

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

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

Простые названия – «Глава 2», «Часть 6» – не помогают пользователю догадаться, о чем пойдет речь. Более описательная манера изложения, например «Глава 2: Мастерство бального танца» или «Часть 6: Юность и зрелость Черчилля», дает сведения о положении документа в некотором собрании и о его особенном содержании, приглашающем читателя ознакомиться с ним. Ничего не дает ссылка на самое себя. Наименование «Моя домашняя страница» полностью лишено содержания; тем же отличаются «Страница отзывов» или «Популярные ссылки». Вам нужно название, несущее сведения о содержании и назначении документа, чтобы пользователи могли, основываясь только на нем, решить, посетить вашу страницу или нет. «Домашняя страница любителей кумкватов» что-то описывает и, вероятно, привлечет любителей этого горького фрукта так же, как «Книга отзывов любителей кумкватов» или «Популярные среди любителей кумкватов ссылки».

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

Что нужно помнить, используя json в php

В этой статье я расскажу, с какими проблемами вы можете столкнуться при использовании json в php.

Рассмотрим два примера.

Пример 1. Обычный нумерованный массив.

$myArray = array('firstValue', 'secondValue');
$myArrayJsonEncoded = json_encode($myArray);
print_r(json_decode($myArrayJsonEncoded));
//Array ( [0] => firstValue [1] => secondValue )
Пример2. Ассоциативный массив.

$myAssotiativeArray = array(
    'firstKey' => 'firstValue',
    'secondKey' => 'secondValue'
);
 
$myAssotiativeArrayJsonEncoded = json_encode($myAssotiativeArray);
print_r(json_decode($myAssotiativeArrayJsonEncoded));
//stdClass Object ( [firstKey] => firstValue [secondKey] => secondValue )

Во 2м примере вместо ассоциативного массива нам возвращается объект! Дело в том, что в JavaScript понятие ассоциативного массива как такового нет. Обычные массивы могут иметь только числовые индексы, потому для эмуляции ассоциативных массивов, ключами которых могут быть в том числе и строковые значения, используются объекты. Поэтому на декодировании мы получили не массив, а объект класса stdClass.

В этом случае, в функцию json_decode можно передать второй параметр - true, тогда результат получим в виде массива:

$myAssotiativeArrayJsonEncoded = json_encode($myAssotiativeArray);
print_r(json_decode($myAssotiativeArrayJsonEncoded, true));
//Array ( [firstKey] => firstValue [secondKey] => secondValue )

Что нового в РНР 5?

Лучший способ подготовится к будущему - это придумать его. John Sculley

Введение
Только время покажет, будет ли РНР 5 столь же успешен, как его предшественники (РНР 3 и РНР 4). Новые возможности и изменения призваны избавить РНР от его слабых мест и гарантировать, что он по-прежнему будет занимать лидирующее положение в вебе.

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

В этом разделе будет рассмотрены:

Новые возможности языка;
Новости, касающиеся расширений PHP;
Другие изменения, заслуживающие внимания.

Новые возможности языка Новая объектно-ориентированная модель

Когда Зив Сераски (Zeev Suraski) добавил объектно-ориентированный (ОО) синтаксис в PHP 3, это можно было рассматривать как "синтаксический подсластитель для поддержки классов" ("syntactic sugar for accessing collections"). Объектно-ориентированная модель получила поддержку наследования и позволяла классу (и объекту) объединять методы и свойства, но не более того. Когда Зив и Анди переписали движок для PHP 4, это был полностью новый движок, работающий много быстрее, намного стабильнее и с еще многими другими возможностями. Однако, изменения практически не затронули ОО модель, первоначально введенную еще в РНР 3.

Хотя объектная модель имела серьезные ограничения, она широко использовалась, часто в очень больших приложениях, написанных на PHP. Это победное шествование парадигмы ООП, даже такой ограниченной в РНР 4, привело к тому, что изменения объектной модели стали центральными в новом релизе РНР.

Какие были ограничения в PHP 3 и 4? Самым большим ограничением (которое и приводило ко всем остальным ограничениям) был тот факт, что семантика экземпляра объекта была такой же, что и для родных типов. Как это фактически отражалось на разработчиках? Когда вы присваивали переменную (которая указывает на объект) другой переменной, то создавалась копия объекта. Мало того, что это влияло на производительность, но и это обычно приводило к ошибкам в приложении, потому что многие разработчики думали, что обе переменные будут указывать на тот же самый объект. А они указывали на разные копии того же самого объекта, поэтому, изменяя один объект, мы не меняли другой.

Например:

<?php 
class Person { 
    var $name; 
    function getName() { 
        return $this->name; 
    } 
    function setName($name) { 
        $this->name = $name; 
    } 
    function Person($name) { 
        $this->setName($name); 
    } 
} 

function changeName($person, $name) { 
    $person->setName($name); 
} 

$person = new Person("Andi"); 
changeName($person, "Stig"); 
print $person->getName(); 
?>

В РНР 4 этот код выведет "Andi". Причина кроется в том, что мы передаем объект $person в функцию changeName() по значению, а не по ссылке, таким образом, объект $person будет скопирован, и changeName() будет работать уже с копией объекта $person.

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

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

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

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

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

Новое в объектно-ориентированном подходе

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

Ниже представлен обзор главных изменений:

public/private/protected - модификаторы доступа для методов и свойств
Позволяют управлять доступом к методам и свойствам.

<?php 
class MyClass { 
    private $id = 18; 

    public function getId() { 
        return $this->id; 
    } 
} 
?>

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

<?php 
class MyClass { 
    function __construct() { 
        print "Inside constructor"; 
    } 
} 
?>

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

<?php 
class MyClass { 
    function __destruct() { 
        print "Destroying object"; 
    } 
} 
?>

Интерфейсы
Класс может наследовать только один класс, но при этом может иметь столько интерфейсов, сколько потребуется.

<?php 
interface Display { 
    function display(); 
} 

class Circle implements Display { 
    function display() { 
        print "Displaying circle "; 
    } 
} 
?>

Оператор instanceof
Поддержка проверки зависимости от других объектов. Функцией is_a(), известной из PHP 4, пользоваться теперь не рекомендуется.

<?php 
if ($obj instance of Circle) { 
    print "$obj is a Circle"; 
} 
?>

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

<?php 
class MyClass { 
    final function getBaseClassName() { 
        return __CLASS__; 
    } 
} 
?>

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

<?php 
final class FinalClass { 
} 

class BogusClass extends FinalClass { 
} 
?>

Явное клонирование объекта
Чтобы явно клонировать объект, вы должны использовать ключевое слово clone. Вы можете объявить метод __clone(), который будет вызван при клонировании объекта (после того, как все свойства будут скопированы из исходного объекта).

<?php 
class MyClass { 
    function __clone() { 
        print "Object is being cloned"; 
    } 
} 
$obj = new MyClass(); 
clone $obj; 
?>

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

<?php 
class MyClass { 
    const SUCCESS = "Success"; 
    const FAILURE = "Failure"; 
} 
print MyClass::SUCCESS; 
?>

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

<?php 
class Singleton { 
    static private $instance = NULL; 

    private function __construct() { 
    } 

    static public function getInstance() { 
        if (self::$instance == NULL) { 
            self::$instance = new Singleton(); 
        } 
        return self::$instance; 
    } 
} 
?>

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

<?php 
class MyClass { 
    static function helloWorld() { 
        print "Hello, world"; 
    } 
} 
MyClass::helloWorld(); 
?>

Абстрактные классы
Класс может быть объявлен как абстрактный при помощи использования ключевого слова abstract, для исключения из обработки движком описания класса. Однако, вы можете наследовать абстрактные классы.

<?php 
abstract class MyBaseClass { 
    function display() { 
        print "Default display routine being called"; 
    } 
} 
?>

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

<?php 
abstract class MyBaseClass { 
    abstract function display(); 
} 
?>

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

<?php 
function expectsMyClass(MyClass $obj) { 

} 
?>

Поддержка разыменования объектов, которые возвращаются методами.
В PHP 4 вы не могли непосредственно разыменовывать объекты, которые возвращаются из методов. Вы должны были бы сначала присвоить такой объект некой фиктивной переменной.

Поясним на примере. В PHP 4:

<?php 
$dummy = $obj->method(); 
$dummy->method2(); 
?>

В PHP 5:

<?php 
$obj->method()->method2(); 
?>

Итераторы
PHP 5 позволяет последовательно получать доступ к элементам класса через конструкцию foreach().

<?php 
$obj = new MyIteratorImplementation(); 
foreach ($obj as $value) { 
    print "$value"; 
} 
?>

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

В PHP 5 в этом больше нет необходимости. Вы можете определить функцию __autoload() , которая автоматически будет вызываться в случае использования класса, который не был определен выше. Вызывая такую функцию, Zend Engine дает возможность загрузить файл с определением класса прежде, чем будет сформировано сообщение об ошибке и выполнение скрипта прекратится.

<?php 
function __autoload($class_name) { 
    include_once($class_name . "php"); 
} 

$obj  = new MyClass1(); 
$obj2 = new MyClass2(); 
?>

Другие новые возможности языка

Обработка исключений
PHP 5 добавляет парадигму обработки исключений, вводя структуру try/throw/catch. Вам остается только создать объекты, которые наследуют класс исключений Exception.

<?php 
class SQLException extends Exception { 
    public $problem; 
    function __construct($problem) { 
        $this->problem = $problem; 
    } 
} 

try { 
    ... 
    throw new SQLException("Couldn"t connect to database"); 
    ... 
} catch (SQLException $e) { 
    print "Caught an SQLException with problem $obj->problem"; 
} catch (Exception $e) { 
    print "Caught unrecognized exception"; 
} 
?>

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


foreach с сылкой
В PHP 4 вы не могли пройтись с помощью foreach() по массиву, изменяя его значения. В PHP 5 разрешено выполнять foreach (), используя признак ссылки ("&"), таким образом, меняя переменную, вы меняете элементы массива, по которому проходит итерация.

<?php 
foreach ($array as &$value) { 
    if ($value === "NULL") { 
        $value = NULL; 
    } 
} 
?>

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

<?php 
function my_func(&$arg = null) { 
    if ($arg === NULL) { 
        print "$arg is empty"; 
    } 
} 
my_func(); 

?>

Основные изменения в РНР XML и Web Services

После изменений, касающихся самого языка, изменения в работе с XML в PHP 5 являются, вероятно, самыми существенными и захватывающими. Расширение функциональных возможностей XML в PHP 5 делают язык полностью равноправным другим, используемыми в сети.

Основы

Поддержка XML в PHP 4 базировалась на разнообразных библиотеках XML. Поддержка SAX осуществлялась старой библиотекой Expat, для использования XSLT необходима была библиотека Sablotron, для DOM использовалась более мощная libxml2 - библиотека проекта GNOME.

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

В PHP 5 все расширения XML были переписаны, чтобы использовать отличный набор инструментов, предоставляемый libxml2 (http://www.xmlsoft.org/). Это библиотека богатая возможностями, отлично сопровождаемая и эффективно реализовавшая стандарты XML, предоставляющая передовые возможности технологии XML в PHP.

Все вышеупомянутые расширения (SAX, DOM и XSLT) теперь используют libxml2, включая новые дополнительные расширения - SimpleXML и SOAP.

SAX

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

DOM

Хотя поддержка DOM в PHP 4 была также основана на библиотеке libxml2, она изобиловала ошибками, грешила утечками памяти, и API во многих случаях не соответствовал рекомендациям W3C. Расширение DOM было полностью переписано для PHP 5. Мало того, что расширение было коренным образом переписано, теперь оно соответствует рекомендациям W3C. Например, названия функций теперь используют нотацию studlyCaps (присваивание имен со смешанным употреблением заглавных и строчных букв) как предписано по стандарту W3C, облегчая для вас применение прочитанного в документации W3C в PHP. Кроме того, расширение DOM теперь поддерживает три вида схем для валидации XML документов - DTD, XML Schema и RelaxNG.

В результате этих изменений код, написанный для PHP 4 с использованием DOM, не всегда будет выполняться в PHP 5. Однако, простая корректировка названий функций к новому стандарту в большинстве случаев решает проблему.

XSLT

В PHP 4, было два расширения, которые поддерживали XSL-преобразования. Первое использовало Sablotron, а второе - поддержку XSLT в расширении DOM. В PHP 5 новое расширение XSL было основано на использовании libxml2. Так, в PHP 5 XSL-преобразование не принимает таблицу стилей XSLT в качестве параметра, но зависит от расширения DOM, чтобы загрузить ее. Таблица стилей может кэшироваться в памяти, и может быть применена ко многим документам для существенной экономии времени выполнения.

SimpleXML

Вероятно, через год или два, оглянувшись назад, мы сможем сказать, что SimpleXML коренным образом изменил работу с XML-документами для PHP разработчиков. SimpleXML можно было бы действительно называть "XML для чайников". Вместо того, чтобы иметь дело с DOM или, что еще хуже, SAX, SimpleXML позволяет представить ваш XML-документ как родной объект PHP. Вы можете читать, писать или пробегаться по вашему XML-документу, с легкой непринужденностью получая доступ к элементам и атрибутам.

Рассмотрите следующий XML-документ:

<clients> 
<client> 
    <name>John Doe</name> 
    <account_number>87234838</account_number> 
</client> 
<client> 
    <name>Janet Smith</name> 
    <account_number>72384329</account_number> 
</client> 
</clients>

Следующий фрагмент кода печатает имя каждого клиента и номер его аккаунта:

<?php 
$clients = simplexml_load_file("clients.xml"); 
foreach ($clients->client as $client) { 
    print "$client->name has account number $client->account_number "; 
} 
?>

Как видим, SimpleXML действительно прост.

А в случае, если есть необходимость сделать что-то, что невозможно выполнить в рамках SimpleXML, вы можете преобразовать свой объект SimpleXML в дерево DOM, вызвав функцию dom_import_simplexml(), выполнить необходимое, и вернуться назад к SimpleXML, используя simplexml_import_dom(). Благодаря тому, что оба расширения реализованы в одной библиотеке XML, переключения между ними теперь реальны.

SOAP

Официально поддержка SOAP в PHP 4 отсутствовала. Обычно, при необходимости использовать SOAP, приходилось использовать PEAR, но поскольку код был написан полностью на PHP, приложение не могло выполняться так же, как встроенное С-расширение. Другие доступные С-расширения так и не смогли достичь стабильной версии и широкого применения, и поэтому не были включены в PHP 5.

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

Следующий код демонстрирует вызов функции SomeFunction(), определенной в WSDL-файле:

<?php 
$client = new SoapClient("some.wsdl"); 
$client->SomeFunction($a, $b, 
$c); 
?>

Новое расширение MySQLi (усовершенствованная MySQL)

В PHP 5 для MySQL AB (http://www.mysql.com/) было написано новое расширение MySQL, которое позволяет вам полностью использовать преимущества новых функциональных возможностей в MySQL 4.1 и более новых версий. В противовес старому расширению MySQL новое дает вам возможность использовать оба интерфейса: функциональный и объектно-ориентированный. Так что теперь у вас есть выбор что предпочесть. Новые возможности, поддерживаемые этим расширением, включают контроль транзакций, поддержку репликаций, SSL и многое другое...

Расширение SQLite

Поддержка SQLite (http://www.sqlite.org/) изначально была введена в PHP 4.3.x. Это встроенная библиотека SQL, которая не требует SQL сервера и очень подходит для приложений, которые не требуют масштабируемых SQL-серверов, или если вы разворачиваете свое приложение у провайдера, который не предоставляет вам доступ к SQL-серверу. Вопреки названию, SQLite очень богата возможностями и поддерживает транзакции, вложенные выборки, представления (view) и большие DB-файлы. Здесь это упомянуто, как возможность PHP 5, потому что поддержка SQLite была введена довольно в поздних релизах PHP 4, и поскольку PHP 5 предоставляет новый объектно-ориентированный интерфейс и поддерживает итераторы.

Tidy расширение

PHP 5 включает поддержку очень полезной библиотеки Tidy (http://tidy.sf.net/). Она позволяет разработчикам PHP разбирать, диагностировать, чистить и восстанавливать документы HTML. Tidy расширение поддерживает как функциональный, так и объектно-ориентированный интерфейс, и ее API использует механизм исключений РНР 5.

Perl extension

Хотя и не включенное по умолчанию в РНР 5, расширение Perl позволяет вам вызывать Perl-скрипты, использовать объекты Perl и использовать другие функциональные возможности Perl прямо из кода PHP. Это новое расширение можно найти в репозитарии PECL http://pecl.php.net/package/perl.

Другие новшества в PHP 5

Новый менеджер памяти

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

Прекращена поддержка Windows 95

Запуск PHP на платформе Windows 95 более не поддерживается, потому что невозможна поддержка функциональных возможностей, которые использует PHP. Поскольку Microsoft официально прекратила поддерживать эту платформу более года назад, разработчики PHP решили, что это будет мудрое решение.

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

Что нового в HTML5 новые теги и разметка

Многие интересуются, что нового внедрили в обновленной гипертекстовой разметке html5. За последние 10 лет web технологии развиваются очень быстро и прогрессивно. А сам html не менялся. В связи как раз с высоким прыжком в развитии интернет технологий разработчики гипертекстовой разметки решились обновить его до 5 версии. Давайте приведу пример новых тегов, которые появились в новом html 5

1) header.
2) footer.
3) nav.
4) section.
5) article.
6) aside.
7) figure.
8) dialog.
9) m (mark).
10) time.
11) meter.
12) progress.
13) video.
14) audio.
15) details.
16) datagrid.
17) menu.
18) command.

А некоторые в тоже время убрали. Давайте посмотрим, что исчезло.

font
center

В остальном в тегах разметки ничего особенного не произошло, если вы знаете основной язык гипертекстовой разметки HTML то несколько новых тегов не введут вас в заблуждение. Какие теги новые добавлены в разметку форм на html5 я уже описывал, кому интересно, можно просмотреть по этой ссылке. Далее давайте рассмотрим, как теперь может выглядеть или даже как должна выглядеть структура документа по стандартам html 5. Давайте приведу пример кода ниже

Код HTML

//Открываем теги body и html
<header>
   <h1>Основной заголовок</h1>
</header>
<section>
<article>
   <h2>Заголовок статьи или публикации</h2>
   <p>Текст материала</p>
</article>
<article>
   <h2>Заголовок статьи или публикации</h2>
   <p>Текст материала</p>
</article>
<nav>
   <a href="">Тут ссылка</a>
   <a href="">Тут ссылка</a>
</nav>
</section>
<footer>
   <p>Copyright 2010 phpguru.com.ua</p>
</footer>
//Закрывающие теги body и html

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

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

header - Определяет верхнюю часть сайта. В народе ее обычно называют шапка сайта.

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

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

article - Выделение определенной части текста. На моем сайте можно увидеть в исходнике такой тег.

Вот мы и рассмотрели коротко и, надеюсь, понятно основные теги разметки, которые были введены в новом html5.

Далее рассмотрим три новых элемента блока в html5

1) aside.
2) dialog.
3) figure.

Давайте теперь опишем их назначение.

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

Код HTML

<h3>Заголовок</h3>
<p>Текст просто</p>
<aside>
<p>Выделенный текст, цитата, например</p>
</aside>

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

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

Код HTML

<dialog>
 <dt>Автор 1</dt>
   <dd>Сообщение автора</dd>
 <dt>Автор 2</dt>
   <dd>Сообщение второго автора</dd>
</dialog>

Как вы заметили внутри элемента dialog ставятся два дополнительных тега разметки - <dt> и <dd>. Первый тег означает Автор сообщения, а второй - текст сообщения. На этом в принципе с данным тегом и все.

Далее разберем еще тег <figure>. Это довольно необыкновенный тег в HTML5, который может дополнительно описывать изображения, например, так:

Код HTML

<figure>
   <legend>Описание</legend>
   <img alt="Здесь описание изображения" src="путь к изображению" width="200" height="200">
</figure>

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

Что не хватает блогу и блогеру для популярности?

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

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

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

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

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

Не забрасывайте блог и ведите регулярный постинг, а не от случая к случаю через каждые 2-3 месяца. Едва ли постоянным подписчикам понравится ваше длительное отсутствие тем более без предупреждения. Это может спровоцировать панику, когда другие начнут думать, что 2-3 месяца вас уже нет и вряд ли вы появитесь, значит, обмен ссылками можно самовольно отменить. Я сам убираю ссылки на те блоги, которые не развиваются в течении нескольких месяцев, 5-6 и более. Маловероятно, что блогеры к ним вернутся, скорей всего продадут и дело с концом, помните, блоги — это не статические сайты, которые не требуют развития и объяснения, например, какая-то справочная служба, которой не обязательно обновляться хотя бы каждую неделю. Но не следует писать чушню, лишь бы что-то писать для видимости живучести ресурса, это навредит еще больше.

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

Не шифруйтесь в сети, будьте открыты другим. Это позволит избежать пустых комментариев не в тему и повысит вашу узнаваемость в сети. Не стоит придумывать различные умные не информативные клички по которым вас будет трудно идентифицировать, которые вы наверняка забудите сами или захотите сменить в дальнейшем. Например, сейчас вам 20 лет и кличка (никнейм) "Пупсик" кажется классной и прикольной, то через 5-10 лет она будет казаться не только другим, но и вам глупой. Лучше уж тогда назовите красиво и понятно свой сайт и подписывайтесь названием своего сайта. О брендинге, вернее правильном подборе названия сайта или своего ника — бренда будет сказано в следующих статьях. Также постараюсь рассмотреть графический брендинг более подробней, помните, что фотография (или рисунок) более важен текста, именно по этой причине часто баннеры оформляют не только картинкой (или текстовой картинкой), но еще и в динамике.

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

Не полагайтесь на внимательность автора блога и не сторонитесь его, если читаете и комментируете. Все мы, так сказать, люди и всем нам свойственны ошибки. Так, например, у меня помимо Акисмет (Akismet) стоял также и другой плагин от спама — Спам вьювер (SpamViewer), они оба обновлялись несколько раз, как и сам блог (движок). Вероятно, сбой среди плагинов либо ваша левая seo-раскрутка сыграли роль: комментарии не поступали на модерацию в отдельную папку, а прямиком уходили в спам, минуя другие разделы; также сомнительные комментарии не уведомлялись по почте, что также может говорить о глюках отдельных плагинов или самого движка за последние 3 месяца.

Что и когда тестировать?

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

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

Сначала попробуйте воспользоваться ими сами. Потом понаблюдайте, как ими пользуются другие (один-два человека), и определите, что в них работает и что не работает. Многие пропускают этот шаг, но он очень полезен: для вас кто-то бесплатно создал рабочий прототип вашего сайта.

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

С уже существующими сайтами можно проводить два вида тестирований:
-Тестирование «Что здесь?». Пользователям демонстрируют сайт и выясняют, понимают ли они, что видят: понятно ли назначение сайта, его «ценное предложение», структура, функционирование и т. д.

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

Как правило, результаты будут более ценными, если вы сумеете сделать так, чтобы пользователи сами определяли задания для выполнения. Например, лучше сказать: «Найдите книгу, которую вы хотите купить или которую недавно купили», чем «Найдите книгу о приготовлении пищи по цене не выше 14 долларов». Если людям дают выдуманные задания, то у них не возникает эмоционального отношения к ним, и поэтому они не используют весь свой личный опыт при их выполнении.

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

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

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

Что должен уметь и знать php кодер

1. Настраивать сервера под всевозможными осями от соляриса до виндовс.
2. Настраивать и устанавливать веб сервер и прочие плюшки.
3. Настраивать и устанавливать базы данных: мускул, постгрис, оракл.
4. В совершенстве владеть проектированием баз данных.
5. Владеть фотошопом, рисовать дизайны.
6. Верстать на HTML.
7. Программировать на javascript и на java тоже.
8. Читать мысли работодателя.
9. Ставить диагнозы серверам на расстоянии.
10. Лечить сервера и скрипты на расстоянии и без паролей.
11. 24 часа быть онлайн.

Что должен уметь и знать php кодер

    Настраивать сервера под всевозможными осями от соляриса до виндовс.
    Настраивать и устанавливать веб сервер и прочие плюшки.
    Настраивать и устанавливать базы данных: мускул, постгрис, оракл.
    В совершенстве владеть проектированием баз данных.
    Владеть фотошопом, рисовать дизайны.
    Верстать на HTML.
    Программировать на javascript и на java тоже.
    Читать мысли работодателя.
    Ставить диагнозы серверам на расстоянии.
    Лечить сервера и скрипты на расстоянии и без паролей.
    24 часа быть онлайн.

Что возвращает input типов checkbox и radio

Элемент типа checkbox при в выбранном состоянии()может возвращать 3 значения.1.Указав значение checkbox например:

<input type="checkbox" name="formcheckbox" value="checkbox">

в результате мы получим переменную $formcheckbox со значением checkbox2. Если значение пусто, например:

<input type="checkbox" name="formcheckbox" value=""> 

в результате мы всё же получим переменную $formcheckbox но с пустым значением.3. Если мы специально не укажем атрибут value в элементе, например

<input type="checkbox" name="formcheckbox"> 

то получим переменную $formcheckbox с значение onЭлемент input типа radio делает тоже самое если он присутствует в единственном экземпляре с определенным именем, например name="formradio", а если этот элемент будет в нескольких экземплярах, например:

<input type="radio" name="formradio" value=aaa>
<input type="radio" name="formradio" value=bbb>

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