О чём речь?

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

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

В этом обзорном посте я бы хотел рассмотреть незаметные для пользователя методы защиты от ботов.

Методы защиты

Перевод статьи Oliver Reichenstein «The 100% Easy-2-Read Standard».

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

Экран и журнал: 100%-размер шрифта — это не много. Фотограф: Wilson Miner.

Не заставляйте нас изменять размер шрифта

Мы не хотим изменять настройки браузера каждый раз когда посещаем новый сайт!

Когда во сне снится «ой а если сервера не хватит...»

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

Kohana — довольно молодой PHP фреймворк, форк CI, всецело завязанный на ООП. К достоинствам Kohana можно отнести использование всех возможностей PHP5 на 100%, высокую скорость работы, «легковесность» и простоту как использования, так и изучения. Из минусов отчетливо выделяется небольшое комьюнити, как следствие, не шибко качественная документация и небольшое количество модулей и библиотек.

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

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

Статья рассчитана на людей, имеющих понятие об MVC и ООП, но не имевших, либо мало имевших, дело с фреймворками.

Предположим у Вас есть сайт. Предположим вы его оптимизировали по самое «немогу», но всеравно хочеться больше.
Лично мне хотелось, но долгое время не получалось.
Когда я победил тормознутость базы кэшированием запросов, тормознутость блоков — кэшированием блоков, а целые страницы кэшировать я не мог…
Cайт конечно стал работать много быстрее, но начал тормозить уже… мемкэшед?

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

Уже сейчас работает уведомление по e-mail, icq.
Но как быть, если администратор в дороге, и не имеет доступа к почте и мессенджеру? Нужно сделать уведомление SMSкой. Это будет полезно как админу, так и пользователю, т.к. последний сможет уведомиться об обработке его проблемы/заявки.

«Совершенный Ajax» — новый подход к построению web-приложений, при котором web-сервер не генерирует ни строчки HTML-кода и взаимодействует с внешним миром только посредством web-служб; а клиентский интерфейс реализуется только на основе клиентских HTML, CSS, JavaScript.

Статья состоит из двух частей. В первой части — более живой и провокационной я постараюсь заинтересовать проблемой, рассказать о технологии «Совершенный Ajax» и показать ее применение на примере нашего проекта «Система Интерактивного Тестирования Знаний “Синтез”» (который имеет ряд интересных особенностей, таких, как использование серверного JavaScript на платформе Mozilla Rhino, прототипно-ориентированная ORM и поддержка SPARQL — языка запросов к Semantic Web).

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

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


Попробуйте угадать: к какой архитектуре относятся web-приложения?

К клиент-серверной говорите? Я ожидал, что Вы так ответите :-)

Что ж, давайте разберемся. В клиент-серверной архитектуре выделяют:

• Сервер — отвечает за хранение данных и реализацию бизнес-логики приложения.
  
  
• Клиент — отвечает за взаимодействие с пользователем ^[1].
  
  

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

Преимущества клиент-серверной архитектуры очевидны; мы их все знаем:

1. Бизнес-логика не смешивается с пользовательским интерфейсом.
2. Можно реализовать несколько клиентов с разными пользовательскими интерфейсами: интерфейс командной строки, оконный Windows-интерфейс, Flash, web-интерфейс, мобильный интерфейс и т.д.
3. Клиентский компьютер не требователен к ресурсам;
4. И т.д.

Но, относятся ли web-приложения к клиент-серверной архитектуре?

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

Но! За реализацию интерфейса отвечает не клиент, а тоже сервер. На сервере происходит обработка клиентской формы. Сервер генерирует HTML-код пользовательского интерфейса.

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

Данная статья — первая из цикла на тему укрощения CSS. Сегодня мы рассмотрим технологию CSS Reset.

Зачем это нужно?

Каждый браузер устанавливает свои значения стилей по умолчанию для различных HTML-элементов. С помощью CSS Reset мы можем нивелировать эту разницу для обеспечения кроссбраузерности стилей.

Например, вы используете элемент a в вашем документе. Большинство браузеров, как Internet Explorer и Firefox, добавляют ссылке синий цвет и подчёркивание. Однако представьте, что через пять лет кто-то решил создать новый браузер (назовём его UltraBrowser). Разработчикам браузера не нравился синий цвет и раздражало подчёркивание, поэтому они решили выделять ссылки красным цветом и полужирным шрифтом. Именно исходя из этого, если вы установите базовое значение стилей для элемента a, то он гарантированно будет таким, каким вы хотите его видеть, а не как предпочитают его отображать разработчики UltraBrowser.

Что такое веб-сервисы?

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

Если посмотреть на веб-сервисы в разрезе стека сетевых протококолов, мы увидим, что это, в классическом случае, не что иное, как еще одна надстройка поверх протокола HTTP.

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

Но и сам Интернет — разнороден, т. е. различные приложения на различных узлах сети функционируют на разных аппаратно-программных платформах, и используют различные технологии и языки.

Чтобы связать все это и предоставить возможность одним приложениям обмениваться данными с другими, и были придуманы веб-сервисы.

Многие программисты оптимизируют JavaScript и CSS-код, чтобы страница грузилась быстрее.
Но не все они делают прелоадеры, которые дают пользователю эффект субъективно более быстрой загрузки.

REST (Representational state transfer) — это архитектурный стиль или свод соглашений для web-приложений и сервисов, основанный на манипулировании ресурсами и спецификацией HTTP. Впервые об этом заговорил Рой Филдинг (Roy Fielding) — один из отцов основателей HTTP (Hypertext Transfer Protocol).

Web-приложения зачастую игнорируют спецификацию HTTP и двигаются вперёд используя полюбившиеся возможности: GET и POST, 200 OK и 404 NOT FOUND. Так как используются программируемые web-приложения, со своими собственными API, то решение игнорировать спецификацию HTTP, может создать проблемы в дальнейшем. Как следствие — имеем множество приложений с интерфейсами GET и POST. Например интерфейс удаления пользователя: GET /user/1/delete против POST /user/delete {id=1}; в случае REST можно указать /user/1 это ресурс, а удаление HTTP метод DELETE.

Предыстория

Решив запустить небольшой сервис на подаренном мне хостинге, оказалось, что там нету ни одного xml-парсера: ни SimpleXML, ни DOMXML, а только libxml и xml-rpc. Недолго думая, я решил написать свой. Мне требовался разбор не сложных rss-лент, поэтому хватило достаточно просто класса xml => array.^[1]

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

Постановка задачи

Доступ к элементам у нас будет осуществляться как доступ к свойствам класса, например $xml->element, а доступ к атрибутам элемента, как к массиву, те $xml->element['attr'], также реализуем проверку на существование атрибута при помощи isset() и итерацию по элементам при помощи foreach. И так, начнем.

Подборочка ошибок начинающих PHP разработчиков…

В очередной раз ковыряясь в чужом коде, понимаю насколько больная тема — стандарты кодирования в PHP…

О чем это?

Возможно ли узнать более детальную информацию о браузере посетителя кроме строки, содержащейся в $_SERVER[«HTTP_USER_AGENT»]: поддерживает ли яву, апплеты, таблицы стилей и фреймы? А может это вообще гуглобот зашел?

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

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

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

Выражения — это краеугольный камень PHP. Почти все, что вы пишете в PHP, является выражением. Самое простое и точное определение выражения — «все что угодно, имеющее значение». (с сайта php.net)

UPD: Статья только о том, как МОЖНО делать в некоторых случаях, когда это оправданно. В большинстве случаях (и тем более повсеместно) описанную практику применять не стоит ни в коем случае, так как она сильно усложняет код. Цель статьи — расказать о возможностях языка, не более того.

Без всякой лирики, прямо: использование ссылок для передачи значений снижает производительность. Мы думаем, что вместо того что бы передавать копию переменной, сценарий передает саму переменную, исходя из чего делаем вывод, что это должно работать быстрее. Увы, это заблуждение. Что бы понять почему давайте разберёмся с тем, как процессор Zend Engine обрабатывает значения.

Недавно, у меня случилась проблема с GD на сервере — он перестал понимать png, после получаса мытарств, решил посмотреть на ImageMagick и его PHP интерфейс IMagick
После недолгого гугления нашел замечательный блог посвященный Imagick. Там же нашел способ делать красивые превьюшки. Однако, способ, предложенный там, правильно отрабатывал только с png картинками. Я немного поковырялся и сделал свой.

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