Присланные тезисы на PHPConf 2009, которая пройдет 8,9 октября 2009 в Москве
www.phpconf.ru/reg — регистрация уже открыта


День первый – WebArchitect WorkShop Day 8 октября (чт)
Это день полностью состоящий из мастер-классов. Их прочитают признанные гуру. Каждый мастер-класс могут посетить не более 30 человек. На данный момент планируется 3 потока по 6 часов. Каждый мастер-класс длительностью от 1,5 до 6 часов.

День второй – PHPCONF 2009 9 октября (пт)
Пополните ваши знания! Что нового произошло за 1,5 года? Какие методики разработки стали общепринятыми в профессиональной среде? Как их внедрить малой кровью? Как повысить эффективность вашей работы и работы вашей команды в разы?


Главные новости PHP 5.3, о которых все говорят
Johannes Schluter

Главные новости PHP 5.3, о которых все говорят — это пространства имён (namespaces) и замыкания (closures). Однако, в PHP 5.3 есть и много другого нового фунционала, который делает этот релиз значительной вехой в истории проекта: модули Intl, Phar, mysqlnd, улучшения в SPL, позднее статическое связывание (late static binding) и много другое.

Такая вот ситуация: дизайнер присылает макет, а у верстальщика открывается какая то лабуда светлая, или темная (если верстальщик испольует МасOS, а дизайнер Win.). Или же верстальщик сохраняет картинку, а там цвета другие стали.

Разберемся почему так и как с этим жить.

Наверняка вы видели разные шпаргалки по веб-программированию. Теперь появились шпаргалки по HTML 5 и CSS 3.
Ссылки на скачивание под катом

Часто перед разработчиком стоит задача установить определенный элемент на сайте, который случайным образом выводит информацию.Будь то коллаж в шапке, изречения философов и т.д. Задача тривиальная, но для обычных языков программирования, а если возможности использовать их нет?Java Script не в счет, зависеть от настроек пользователя в таких задачах — не кошерно. На помощь приходит SSI, хотя, положа руку на сердце, это не те задачи, которые должен выполнять.

Современные проекты всё больше и больше персонализируются. Один из последних проектов предполагал постоянное присутствие пользователя на сайте. Пользователь является диспетчером и отслеживает появление новых заказов, участвует в аукционах итп. Помимо уже стандартных SMS уведомлений итп, хотелось сделать звук, т.к. пользователи действительно постоянно находятся на проекте. Самым простым способом показался флеш. Флеш уже есть почти у всех, все смотрят ютуб, играют в фермера и так далее. И не смотря на мои антифлешевские взгляды, решил что для проигрывания звука флеш подходит лучше всего.
Однако при попытке написать флешку для проигрывания звуков я вдруг вспомнил, что не работал с флешем уже лет 5 =( и вместо того, чтобы написать свой компонент, стал искать готовые…

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

Gopher

«To Gopher, the world is just one big file system»

Gopher — один из протоколов интернета, был популярен в начале 1990-х, впоследствии его роль уменьшилась. В основном с повсеместным развитием WWW. Ошибочно считается (а именно так написано в русской и английской википедии), что протоколы Gopher и HTTP были своего рода конкурентами, это и привело к уменьшению доли одного и увеличению другого. Нет, изначально Gopher был разработан для своеобразной замены FTP, протокола, который был разрабтан еще в 1960-х годах.

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

Буквально сегодня попал на сайт MadBanner и увидел предложение "MADBANNER В АРЕНДУ" — это автоматический сервис, с помощью которого вы можете быстро начать пользоваться MadBanner, без нудного оформления договоров и установки на сервер.

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

Старт

Итак, проект Холиварс.ру запущен. Запущен удачно, он что называется выстрелил. Это когда вести о проекте сами собой разносятся людьми, которых он впечатлил. После публикации обзоров только на хабре и ещё одном ресурсе, без вложения денег в рекламу — более тысячи упоминаний в блогосфере, десяток упоминаний на новостных сайтах, даже сюжеты по ТВ, отчего у нас волосы выпучились и глаза встали дыбом — по Эксперт-ТВ и в программе Телепорт на МТВ.

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

Начало

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

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

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

Задача

Совместить lite-версию сайта (работающую без JavaScript'а) с обычной. Иными словами, сделать graceful degradation для JavaScript-решений. Далее в посте небольшое руководство для тех, кому актуальна данная проблема.

27 по 30 октября 2009 года на ВВЦ будет проводится выставка «WEB-Студия 2009». Пройдет она в рамках выставки «SOFTOOL».

Предлагаем Вам стать участником или посетителем этого яркого интернет-события осени 2009 года.

Получить бесплатный билет можно здесь:
www.ws2009.ru/visitors

Команда JetBrains (известная многим по продукту R#) создает новый продукт с кодовым именем “Charisma”.

Charisma – это web-ориентированный issue tracker (система отслеживания ошибок). Ее основные функции, отличающие ее от подобных систем:

• Поиск при помощи вопроса в качестве альтернативы стандартным поисковым фильтрам (эта функция видна на картинке – запрос вида By Me Fixed – закрытые задачи мной).
• Легковесный пользовательский интерфейс, основанный на AJAX – позволяет работать с системой быстрее.
• Расширенная поддержка клавиатуры для более быстрого создания, редактирования и перехода между задачами при помощи клавиатуры.
• Возможность выполнения командных операция по выбранным запросам.

Charisma разрабатывается с помощью JetBrains MPS и уже используется для отслеживания ошибок в системе JetBrains TeamCity (там как раз и можно попробовать их расхваленный пользовательский интерфейс). Charisma уже доступна в Early Access Program (EAP), потому каждый может попробовать ее скачать и установить себе (на любой J2EE сервер, такой как Apache Tomcat 5+, Mortbay Jetty, JBoss, Caucho Resin), последний билд был 28 июля под номером 45. Ну и конечно же команда JetBrains с удовольствием выслушает все ваши замечания и предложения (так написано на сайте EAP). Жалко что не опубликованы цены, но, думаю, те, кто будет участвовать достаточно сильно в обсуждении и поиске ошибок может быть JetBrains и отблагодарит скидками или подарками.

А вы знаете, что по-настоящему валидному HTML-документу не требуются теги <HTML>, <BODY>, <HEAD>, которые многие считают обязательными атрибутами HTML-документа. И вот такой документ:

<!DOCTYPE html>
<title>Валидный HTML-документ</title>

на ура пройдет валидацию. Хотя желательно добавить <meta http-equiv=«Content-Type» content=«text/html; charset=utf-8»>, чтоб было меньше warnings, но тоже необязательно.
Так что, если вам лень набирать лишние буквы или вы экономите каждый байт, заботясь о пользователе и снижая объем потребляемого им траффика, то можете использовать вот такой шаблон HTML-документа (уже HTML5 документа):

<!DOCTYPE html>
<meta charset="utf-8">
<title>Валидный HTML-документ</title>

И далее, соблюдая семантику элементов
P.S. Написать заметочку решил по прочтении поста, посвященного HTML5. В одном комментарии упомянули, что BODY опционален, но почему-то не рекомендовали этим пользоваться. Не вижу причин. Кстати, в коде страницы яндекса упомянутые теги отсутствуют)

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

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

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

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

Simplicity does not precede complexity, but follows it. /Alan J. Perlis/

История эта началась в начале 2000-х, когда все поняли на примере Gnutella, что пиринговую сеть убивает фрирайдерство — масса пользователей-паразитов, только скачивающих, но не раздающих. Была написана масса статей про доверие и учёт траффика в пиринговых сетях. Например, «The EigenTrust Algorithm for Reputation Management in P2P Networks», одна из самых популярных и цитируемых статей этого направления, где в соавторах был сам Гарсия-Молина, была представлена на WWW'2003. Как говорится, всё по классу «А». Статья подразумевала, что пиры будут совместно высчитывать PageRank-подобную метрику, передавая друг другу векторы размером N, где N-количество участников. Я знаю несчастных, которые даже сегодня продолжают заниматься такими метриками, с O(N) данных на узел и сложными правилами вывода. А в реальной жизни «победил» BitTorrent, в котором некоторый репутационный элемент конечно был — алгоритм tit-for-tat, «ты мне — я тебе», но всё это было сильно проще репутационно-учётных систем на основе DHT и прочего подобного. Просто каждый пир пытается отвечать взамностью и слать траффик (интересное в мелочах) трём пирам, которые закачали ему больше всего в последние 20 секунд и ещё одному, случайно выбранному. Конечно, следует признать, что простые репутационные системы тоже в ходу. Пóфиксы, как я их называю, или затычки. Sharing ratio enforcement есть на том же torrents.ru, tvtorrents.com и где только его нет. Но с моей точки зрения, это доказывает следующее: траффика будет море, если только есть какое-то, пусть даже самое символическое вознаграждение. Если вознаграждения нет совсем, то траффик будет. Но не море. Как на thepiratebay.com.

В каком же направлении эта область развивается сейчас? По-видимому, в сторону упрощения. Дело в том, что алгоритм tit-for-tat потребовал разделения файла на мелкие кусочки и затем обмена ими по алгоритму rarest-first (о чём также было написано море забавных статей). Плюс ещё «рейтинги». Всё это довольно сложно. А что если убрать коренную причину конфликта — тот мотив, из-за которого пользователи прекращают сидить? Конкретнее, проблема в том, что лазить по интернету при работающем BitTorrent становится сильно неудобно. Это вызвано тем, что все 50 соединений, открываемых BitTorrent'ом, получают свои доли траффика на равных с теми робкими 4 TCP-соединениями, которые открывает браузер. В результате, браузер тормозит. А если отказаться от TCP и использовать для P2P более робкий транспорт, загружающий аплинк, когда тот свободен и быстро уступающий всплескам TCP-траффика? Многие читали новости про такой транспорт (uTP) в µTorrent. Его разработкой в BitTorrent Inc занимается Станислав Шалунов. Если uTP хорошо пойдёт, возможно удастся искупать пользователей в халявном траффике.

От себя добавлю. Тогда станет возможным забить и на tit-for-tat и на rarest-first и наконец-то, скачивать файлы по порядку и смотреть кино «по клику», как в YouTube. Возможно, для этого понадобится ещё пара пóфиксов, но фундаментально уравнение таково: пользователи не могут скачивать кино 24 часа в сутки. А сидить 24 часа в сутки могут. Если только это не создаёт неудобств.

Наткнулся тут недавно на одном сайте на способ защиты от ботов без использования каптчи и javascript.
Все очень просто — достаточно добавить скрытое поле с символом кодированным в HTML сущность (например &amp;copy; &amp;#151; и т. д.). Дело в том что браузер найдя такой символ преобразует его перед отправкой в обычный, а робот использующий парсер форм так и отправить закодированным (причем у меня есть свой парсер форм и он сделал бы именно так). При проверки формы достаточно просто посмотреть длину строки в этом поле. Если отправлял человек то она будет равна числу символов в строке, а если нет значительно больше.
Так что такое решение пусть и не обеспечивает серьезной защиты но вполне может применяться в тех случаях если что то более сложное использовать нельзя.

P. S. пример
P. P. S. Оказывается у меня тут в черновиках статья лежит про методы защиты от ботов и их обходы, стоит дописать?

Peer-to-peer сеть BitTorrent очень популярна. И тем обидней, что базируется такая сеть на веб-сайт, трекер, что совершенно не пиртупирно и потенциально опасно. Соответственно, с тех пор, как жив BitTorrent, предпринимались различные попытки децентрализовать и оставшуюся часть — получение списка пиров.

Есть у студентов computer science популярный шаблон мышления: «Децентрализовать? DHT!». DHT, Distributed Hash Tables — умозрительно простая идея: диапазоны ключей хэш-таблицы разбрасываются на пиров, выстраиваются взаимные ссылки и ура. Ура — в жопе дыра. Потому что при столкновении с реальной сетью, в отличие от симулятора или кластера, начинается преогромное количество проблем. Более половины пиров, например, скрыты за NATами и фэйрволами, поэтому на запросы DHT одним пирам они отвечают, а другим — нет, причём труднопредсказуемым образом. Пиры постоянно приходят и уходят, некоторые пиры глючат, есть злоумышленные пиры, кто-то подключён по диал-апу. Чтобы всё это предусмотреть и подкрутить соответствующие затычки, пришлось серьёзно потрудиться. И получившийся код всё равно вызывает нарекания. Коренная проблема в том, что DHT вынужден строить свою отдельную P2P-сеть по своим отдельным правилам. Что плохо влияет на сложность, эффективность, безопаснось.

Другая попытка в том же направлении — PEX (Peer EXchange)*, gossip протокол, в котором уже соединённые пиры просто обмениваются адресами тех, к кому они уже присоединены. У протокола была нелёгкая судьба, потому что изначально Брам Коэн (автор BitTorrent) был уверен, что PEX будет вести к распадению роя. Он сделал по-быстрому какой-то симулятор и увидел полный распад. Некоторое время назад мне показалось, что я понимаю, почему и него рои распадались. Я тоже сделал симулятор, но при разумных параметрах распадения роя добиться не удалось. Видимо, была у него какая-то ошибка.

А PEX работает отлично. Его изначально реализовали в неофициальных клиентах, кажется Azureus и µTorrent (второй ещё не был куплен BitTorrent Inc). Постепенно реализация µTorrent, под названием ut_pex, стала общепринятой. Протокол очень эффективен: я с моего лаптопа своим специальным BitTorrent-пауком за пару-тройку минут переписывал всех пиров в 100-тысячном рое. Логика работы простая, экспоненциальная. Получив от трекера двадцать пиров и успешно присоединившись к двум, мы тут же по ut_pex получаем ещё двести. Ну и так далее. Сам протокол чрезвычайно прост и состоит из одного (!) сообщения. Ещё один популярный шаблон мышления: все думают, что сообщения должно быть два: запрос и ответ. Нет, запроса нет. Просто сообщения так малы, что экономить нет смысла. А с запросами куча мороки. Поэтому если пир видит, что вы понимаете ut_pex, он просто периодически шлёт вам IP-адреса. Реализация ut_pex в libtorrent-rasterbar занимает в 7 раз меньше места, чем довольно компактная реализация DHT там же**.

<sub>* А то, что сейчас написано про PEX в Википедии — это original research или попросту лажа.

** Внимательный читатель, возможно, заметит подтасовку — ut_pex не обеспечивает полной децентрализации трекинга, ведь ему нужны стартовые пиры. Поделюсь секретом. DHT этого тоже не обеспечивает. Во-первых, пользователи всё равно идут на сайт, потому что иначе их собрать сложно. Во-вторых, из того что я знаю, DHT на практике бутстрапится с корневых серверов (только это большой секрет! :) )</sub>

The cheapest, fastest, and most reliable components of a computer system are those that aren't there. — G. Bell

as simple as possible, but not simpler

В 2001, после эпидемии CodeRed, Николас Вивер написал крайне интересную статью про быстрораспространяющихся червей «Warhol Worms: The Potential for Very Fast Internet Plagues», у которой была потом ещё пара сиквелов. Краткое содержание статьи: если к механизму распространения червя добавить ряд оптимизаций, то червь может поразить всю уязвимую популяцию за 15 минут и даже быстрей. Грубо говоря, сломать интернет быстрей, чем админ допьёт кофе. Оптимизации были интересные:

1. hitlist scanning (заранее создать список первых 1000-10.000 жертв, чтобы избежать начальной пологой стадии экспоненциального роста)
2. permutation scan (обнаружив уже заражённую машину, перескочить в списке адресов, поскольку следующие за заражённым адреса уже наверняка просканированы)
3. partitioned scan (родительский червь раздаёт потомкам диапазоны адресов, чтобы совершенно исключить повторное сканирование)
4. subnet scan — очевидное сканирование локальной подсети в первую очередь

Меня тогда очень поразили такие возможности червестроения. Я тогда накатал статью «Modular Worms», что черви будущего будут со сменными насадками, апдейтиться прямо в сети и т.д. Мою статью, как обычно, отклонили, а лет через пять, как обычно, именно такие черви стали использоваться для строительства ботнетов. Сначала был Agobot, а потом дело встало на поток. Даже появился термин «open-source worm».

Реальный же червь Уорхола появился 25 февраля 2003 года. Он назывался SQL Slammer, заражал MS SQL Server. И этот червь не использовал ни единой хитрой оптимизации. Он тупо распространялся по UDP, умещаясь внутри одной-единственной датаграммы. Это было проще, это было дешевле. Ведь все мы знаем, что TCP нужно отправить три пакета только чтобы начать общение. При этом необходимо держать структуры данных в ядре, ждать ответа, ставить таймеры и т.д. и т.п. Напротив, UDP червь мог тупо забивать аплинк датаграммами, сколько уж влезет. А влазит много: 1Mbits это 332 «споры» в секунду, каждая спора 376 байт. Глобальное распространение червя произошло за 10 минут. Может и быстрее, подумал я, ведь моя статистика собиралась с шагом 10 минут. И в одном файле червя не было, а в следующем он уже был. Я проверил таймстампы — да, примерно 10 минут. Зарубежные коллеги тоже сказали 10 минут. Этот рекорд до сих пор не побит.

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