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

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

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

Когда дошло до самого тура, я получил выбор между тремя секциями: веб-дизайн, анимация и веб-программирование. Я выбрал последнее, как наиболее близкое по духу. После этого передо мною оказался список из семи (или что-то около того) заданий на разные веб-технологии, включая CSS, PHP и немного JS. Были и “теоретические” задачи, об одной из которых я напишу в следующем посте. но в целом все они были простые и довольно легко решались при наличии базовых навыков. Разве что в задаче про CSS мне пришлось погуглить, чтобы разобраться с трехмерными эффектами в CSS3. В общем, отведенного времени мне вполне хватило, чтобы выполнить большую часть заданий с хорошими баллами и перейти в фазу ожидания результатов.

Через пару дней на сайте появилось сообщение о том, что проверка близка к концу и скоро результаты будут. Еще через пару - появились результаты секций веб-дизайн и анимация, а веб-программирование было обещано “совсем скоро”. Результаты появились лишь через неделю после тура, но долгое ожидание компенсировалось приятной новостью: я занял первое место с почти двукратным отрывом. Одновременно на сайте появилась просьба сообщить контактные данные для рассылки призов, что я тут же и проделал.

Следующий виток событий имел место уже в мае, через месяц. Сайт висел в том же виде, что и в момент публикации результатов, никакой информации о ходе рассылки призов не было. Попытки писать на почтовые ящики, указанные на сайте давали только отлуп “Mainbox is full”. Видимо не я один такой любопытный был, хотел узнать где мои обещанные “ценные призы”. Поэтому мне осталось долбиться в аську, указанную среди прочих контактов. Спустя несколько дней мне все же ответили. при чем весьма вежливо, что посылки и письма уже переданы в общий отдел и скоро будут отправлены. Я успокоился еще на месяц.

Через месяц (в сумме - через два после тура) я снова задался вопросом, где мой “ценный приз”, но пошел с ним уже в свой деканат, так как считал, что пота почтой, но за месяц-то посылка из Бийска до Новосибирска дойти должна. В деканате удивились и сказали, что они вообще без понятия и пишите в оргкомитет олимпиады. И только когда я был в дверях, одна из женщин, сидевших в кабинете припомнила, что им вчера пришло какое-то извещение о посылке из Бийска. Однако, вовремя я пришел. На вопрос, когда же они получат посылку и я смогу забрать приз, я получил совет зайти на следующей неделе, дескать “посылка прислана на имя деканата, а у деканата паспорта нет и на почту он прийти не может. Придется через отдел снабжения получать”. На следующей неделе мне торжественно отдали диплом, но сказали, что посылку еще не забрали (“нужный человек” находится незнамо где, бывает), посоветовали зайти еще через пару дней.

И наконец, через эти пару дней я таки получил в руки длинную коробку, непонятно зачем обклеенную белой бумагой, так что надписи на ней было не прочесть. Вскрытие показало, что в коробке - веб-камера от неизвестного мне бренда marksman. Подключение к компу показало, что у нее безумно крутое разрешение в 0.3 килопикселей и нет встроенного микрофона. Вот такой вот “ценный приз”, большего я, в прочем, и не ждал. Кстати, до сих пор я пользовался веб-камерой от d-link с матрицей (боже правый!) 0.1 мегапиксель, но зато со встроенным микрофоном, полученной в приз 3 года назад в другом конкурсе :) Для скайпа худо-бедно хватало. Прогресс, конечно, есть, но отсутствие встроенного микрофона в новой камере означало геморрой и отдельным микрофоном или гарнитурой, что мне нафиг не сдалось. Посему пока буду юзать старую, а потом присмотрю что-нибудь приличное.

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

Публикую перевод статьи API Battle Plans: Fighting for Next, давным-давно сделанный мною в рамках акции 50 лучших SEO-постов 2009 года и благополуно забытый в пылу учебы и работы :) Только чейчас наткнулся на него в Гуглодоках, когда искал кое-какие материалы по одной интересующей меня теме. Тем не менее, лучше уж поздно, чем никогда, посему публикую.

План битвы API - Сражение за будущее

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

Но с чего дальновидному бизнесу начинать?

Несмотря на то, что API уже довольно давно применяются для доступа к информации, мы все еще находимся в состоянии зарождения API для контента и сервисов. Удивительно, но мы находимся в еще более зачаточном состоянии в отношении применения API для оптимизации цифровых носителей и представления информации. Вы можете себе представить полностью динамическую Сеть? Я знаю, это может показаться непростым, имея за плечами опыт мешапов, которые мы оставляем позади вместе с остальной эпохой Веб 2.0.

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

Bit.ly: Модель армии

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

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

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

КСРА (CUDA): Стек API.

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

Я называю это КСРА (CUDA) потому что… просто потому что я маркетолог и это звучит круто.

Уровень 1. Контентные API: тексты, картинки, звук и видео.

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

В New York Times верят, что их API в 2,5 раза увеличит охват аудитории. Но как? Зависеть от неизвестных третьих лиц в превращении ваших API в вашу прибыль — это сродни менеджеру по продажам, просто сидящему у телефона и ждущему пока он зазвонит. Контентные API - это лишь сырой материал, и то, получите ли вы в результате уголь или алмазы, зависит от того, как вы его обработаете.

Единственная проблема издателей — это то, что они никогда не были сильны в цифровом маркетинге или технологических инновациях. Вдобавок, технологические инновации всегда скептически воспринимаются издателями. Уже тот факт, что Kindle приносит Amazon’у прибыть от подписок на Wall Street Journal большую, чем получает сам WSJ (не принимая во внимание прямые потери прибыли и отношения покупателей для журнала), должен быть достаточной мотивацией для того, чтобы заняться созданием собственного решения. Но когда это произойдет в действительности пока предсказать невозможно.

Уровень 2. Сервисные API: сообщения, платежи, цены.

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

Уже в ближайшее время пред нами предстанет множество платежных API во главе со многоожидаемой платежной системой Facebook. В моей собственной компании RAMP Digital мы встроили мобильный платежный API в отображение рекламы, чтобы облегчить заказ подписки прямо из рекламного блока. И подобные решения — это лишь начало новой волны служб, доступных через API.

Уровень 3. Разработка: службы API.

Как ни крути, разработка — это всегда ключевой уровень. Главные инновации на пути к настоящему Вебу услуг будут построены на их основе. Яркий пример — http://camelbuy.com. C помощью BestBuy API он предоставляет массу ценной и полезной информации. Это хорошее начало, но бизнес не может успокоиться, уповая на то, что успех их API будет обеспечен сторонними разработчиками, получающими партнерские отчисления или победителями конкурсов.

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

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

Если что и сдерживает будущее Веба, то это не оптимизация доставки контента, а оптимизация его представления.

Уровень 4. Аналитическое API: Профили данных, параметры.

Данные, предоставляемые через API, уже оказали значительное влияние на Веб. Google в день обрабатывает 4 миллиарда обращений к своим API (представьте на секунду, какое преимущество они имеют в отношении реализации сбора аналитики).

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

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

Итог

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

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

7 способов определить хостера сайта

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

1. NS-сервера домена
2. Страницы ошибок 403/404
3. Виртуалхост по умолчанию
4. Reverse DNS lookup
5. Traceroute
6. Whois
7. Сигнатура SMTP сервера

Статья целиком.

Добавление поддержки PHP 5.2 в XAMPP

XAMPP — это связка PHP-Apache-MySQL, а так же Perl, ProFTPd, phpMyAdmin и много другого в одной готовой связке. У него есть свои плюсы и свои минусы, и информацией по исправлению одного из таких недостатков я хочу поделиться в этом посте.

«Недостаток» состоит в том, что разработчики стараются включить в паке скорее свежие, нежли стабильные версии софта, которые порою еще не поддерживаются сторонними расширениями. Для меня камнем преткновения стали PHP 5.3, присутствующий в XAMPP с версии 1.7.2, и Zend Optimizer, которого для PHP 5.3 еще нет (хотя и давно обещали). Статья целиком.

Кстати, про XAMPP я уже дважды писал у себя в блоге, вот эти статьи:

1. Установка Zend Optimizer на XAMPP под Linux

2. LAMPP - запуск от обычного пользователя.

### Приглашаю

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

На досуге добавляя в фильтры AdBlock очередную баннерную сеть, подумал такую очевидную мысль: все популярные и как бы доходные рекламные сети, включая столь любимые публикой тизеры, уже давно добавлены во все возможные баннерорезки, коих уже немало. Одно только расширение AdBlock для Firefox, которым я успешно пользуюсь, имеет 813599 загрузок в неделю и является самым популярным расширением. Кроме того, во многих популярных виндоовых фаерволах, включая Outpost,  уже давно есть встроенные баннерорезки.

Оценили насколько сужается аудитория и потенциальная прибыль?

У алчных манимейкеров должен возникнуть вопрос: как бабки вернуть и к себе в карман перенаправить. Вывод напрашивается из самого принципа фильтрации: В первую очередь баннерорезки пытаются срезать скрипты и картинки по URL. При этом в первую очередь под нож идут домены известных сетей, а потом характерные маски URL типа /banner/* или *banner.* Соответственно решать проблему нужно подменой адресов скриптов баннерных систем. Сделать это легко при помощи проксирущих скриптов на своем хостинге. Если при этом имя скрипту дать не /ad/banner.js.php, то баннерорезка скорее всего его пропустит => PROFIT!

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

Отсюда встает вопрос: тянуться за журавлем обходить баннерорезки или не рисковать всем доходом? Каково ваше мнение?

И еще один вопрос: какие сети не запрещают модификацию их кода?

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

Ваши ответы приветствуются в комментариях.

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

А вот и прототип:

Кстати, всем рекомендую. Кто держит (держал) кошку, тот поймет :-)

Свершилось!

Opera Mini для iPhone уже в AppStore!

И она работает!

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

Achtung!

If you are using long file (more than 4Gb) support for C standart library (via defining _FILE_OFFSET_BITS 64 macro or something else) and lint shows you errors like this:

(88) warning: constant in conditional context

argument unused in function
    (18) sig in sighandler

value type declared inconsistently
    lseek               llib-lc:unistd.h(396) long () :: unistd.h(396) long long ()
    tell                llib-lc:unistd.h(515) long () :: unistd.h(515) long long ()
    ftello              llib-lc:stdio.h(319) long () :: stdio.h(319) long long ()

function returns value which is always ignored
    fflush              fprintf             printf              fwrite
    signal              alarm               lseek64

function argument ( number ) declared inconsistently
    ftruncate (arg 2)   llib-lc:unistd.h(320) long  :: unistd.h(320) long long
    lockf (arg 3)       llib-lc:unistd.h(394) long  :: unistd.h(394) long long
    lseek (arg 2)       llib-lc:unistd.h(396) long  :: unistd.h(396) long long
    pread (arg 4)       llib-lc:unistd.h(410) long  :: unistd.h(410) long long
    pwrite (arg 4)      llib-lc:unistd.h(434) long  :: unistd.h(434) long long
    truncate (arg 2)    llib-lc:unistd.h(520) long  :: unistd.h(520) long long
    fseeko (arg 2)      llib-lc:stdio.h(318) long  :: stdio.h(318) long long

declared global, could be static
    min                 main.c(13)
    sighandler          main.c(18)
    fp                  main.c(11)

…Don’t panic! It’s known bug:

Thelint(1B) utility will generate spurious error messages when _FILE_OFFSET_BITS is set to 64. This is because the binary libc lint library, /usr/lib/llib-lc.ln, is compiled only for the standard interfaces, not with _FILE_OFFSET_BITS set to 64. This deficiency hampers static error-checking for programs compiled in the large file compilation environment. (Source)

Damn it, I lost 3 hours before I found it.

Внимание!

Если вы используете в своей программе поддержку больших файлов (больше 4 Гб) в стандартной библиотеке C (с помощью задания макроса _FILE_OFFSET_BITS 64 или как-то иначе) и lint выдает вам ошибки вроде этих:

(88) warning: constant in conditional context

argument unused in function
    (18) sig in sighandler

value type declared inconsistently
    lseek               llib-lc:unistd.h(396) long () :: unistd.h(396) long long ()
    tell                llib-lc:unistd.h(515) long () :: unistd.h(515) long long ()
    ftello              llib-lc:stdio.h(319) long () :: stdio.h(319) long long ()

function returns value which is always ignored
    fflush              fprintf             printf              fwrite
    signal              alarm               lseek64

function argument ( number ) declared inconsistently
    ftruncate (arg 2)   llib-lc:unistd.h(320) long  :: unistd.h(320) long long
    lockf (arg 3)       llib-lc:unistd.h(394) long  :: unistd.h(394) long long
    lseek (arg 2)       llib-lc:unistd.h(396) long  :: unistd.h(396) long long
    pread (arg 4)       llib-lc:unistd.h(410) long  :: unistd.h(410) long long
    pwrite (arg 4)      llib-lc:unistd.h(434) long  :: unistd.h(434) long long
    truncate (arg 2)    llib-lc:unistd.h(520) long  :: unistd.h(520) long long
    fseeko (arg 2)      llib-lc:stdio.h(318) long  :: stdio.h(318) long long

declared global, could be static
    min                 main.c(13)
    sighandler          main.c(18)
    fp                  main.c(11)

…Не пугайтесь! Это известный баг:

Thelint(1B) utility will generate spurious error messages when _FILE_OFFSET_BITS is set to 64. This is because the binary libc lint library, /usr/lib/llib-lc.ln, is compiled only for the standard interfaces, not with _FILE_OFFSET_BITS set to 64. This deficiency hampers static error-checking for programs compiled in the large file compilation environment. (Источник)

Этот пост посвящается таким же несчастным, как я, которые пытаются нагуглить, как поправить эти ошибки. Мне понадобилось чуть больше 3х часов, чтобы найти эту маленькую заметочку. В моем случае это был вопрос “на засыпку” - не ответил бы, не приняли бы лабу. Черт возьми, самое обидное, что к самой лабе это не имеет отношения, чисто повозить мордой об стол.

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

Simple AJAX Long Request (SALR) 1.0

Возможности:

1. Отправка GET запросов с произвольными данными, переданными в виде хеша.
2. Отправка форм POST и GET запросами.
3. Автоматическая конвертация PHP-типов в соответствующие типы объектов JS.
4. Глобальный доступ к PHP API благодаря реализации в виде статического класса.
5. Перехват многих фатальных ошибок (см. http://dklab.ru/chicken/nablas/45.html)

Совместимость:

Протестирован в Firefox 3.5, Opera 10.10, Konqueror 4.3.5r0 и IE 7. Теоретически должен работать и в остальных браузерах, включая IE6 (а может и 5) и WebKit-based браузерах.

JavaScript API

После подключения к веб-странице файла longreq.js становится доступен объект lreq, через который и происходит взаимодействие с библиотекой.

lreq.send(url, data, callback)

Отправляет запрос на адрес url с данными data с переданной функцией callback в качестве обработчика.

Параметры:

url - строка. Адрес скрипта, на который следует отправить запрос.

data - хэш. Хэш с GET-параметрами, передаваемыми в запросе. Преобразование ключей и значений производится вызовом метода .toString()

callback - функция. Функция, которая будет вызываться всякий раз, когда приходят данные с сервера. Подробное описание функции и аргументов приведено ниже.

lreq.sendForm(url, form, callback)

Отправляет форму form на адрес url с переданной функцией callback в качестве обработчика.

Параметры:

url - строка. Адрес скрипта, на который следует отправить запрос.

form - DOM-узел. Объект формы, которая будет отправлена.

callback - функция. Функция, которая будет вызываться всякий раз, когда приходят данные с сервера. Подробное описание функции и аргументов приведено ниже.

Замечание:

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

Функция callback.

function callback(mode, jaData, htmlData)

Параметры:

mode - режим вызова функции.

0, если это первый вызов, произведенный функцией send() на стороне сервера

1, если это не первый вызов, произведенный функцией send() на стороне сервера

2, если это вызов во время завершения работы скрипта.

jaData - это данные, переданные в качестве аргумента функции LongRequest::send(). При mode == 2 всегда null

htmlData - это все данные, выведенные скриптом в браузер в обход функции LongRequest::send(). При моде != 2 всегда null

Замечание:

callback вызывается всегда хотя бы один раз когда серверный скрипт завершает работу с mode, равным 2.

PHP API

После подключения файла longreq.php становится доступен статический класс LongRequest, через который происходит взаимодействие с библиотекой.

LongRequest::init()

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

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

Longrequest::send($data)

Отправляет произвольные данные в браузер. Данные будут переданы callback-функции в качестве аргумента jsData.

Данные приводятся к JS-типам следующим образом:

• null - в null
• Число - в число.
• Строка - в строку.
• Массив - в хэш, все его элементы будут рекурсивно преобразованы согласно этим же правилам.
• Все прочее (объекты) - сериализованы функцией serialize() и представлены как строка.

Параметры:

$data - произвольный тип. Данные, которые будут переданы в браузер.

Скачать: longreq.tar_.gz

Всем нам приходится писать html-код, кому-то больше, кому-то меньше.

В частности, у меня написание шаблонов для моих движков зачастую занимает до трети времени от разработки. Главная причина тому - сравнительная многословность html, да и css. Так бы я и мучился, если бы очередной раз не наткнулся на статью по Zen Coding.

Как постичь Дзен?

Если кратко, то Zen Coding - это целое семейство плагинов к разным редакторам, позволяющее писать сокращенный код, который потом будет автоматически развернут с полную конструкцию. Вот вам сразу пример:

div#page>h3.title+ul.menu>li.item*3>a

Будет развернут в конструкцию

<div id="page">   <h3 class="title"></h3>   <ul class="menu">      <li class="item"><a href="#"></a></li>      <li class="item"><a href="#"></a></li>      <li class="item"><a href="#"></a></li>   </ul></div>

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

1. Внешний элемент -
   с id “page” (помним, что когда мы в css хотим указать стиль для элемента по его id мы пишем [имя_тега-опционально]#id_элемента)
2. Внутри
   создаем элеменит

   с атрибутом “title”

3. На том же уровне, что и

   (т. е. прямо внутри

   ) пишем тег

   с классом “menu”
   • Внутри
     создаем три тега
     • с классом “item”, внутри каждого из которых вложенный тег

Zen Coding v0.5 from Sergey Chikuyonok on Vimeo.

A new way of writing HTML code using CSS-like selector syntax. Read http://www.smashingmagazine.com/2009/11/21/zen-coding-a-new-way-to-write-html-code/ for more info.

Окончательно заинтересовались?

Ну тогда вот вам серьезные ссылки, а не понты с финтифлюшками:

1. Концепт Zen Coding - можно считать основным учебником, после прочтения уже можно приступать к использованию.
2. Селекторы и псевдонимы для плагинов Zen HTML - первая часть подробной библии Дзена. Полный справочник по конструкциям вроде той, которую я привел вначале.
3. HTML-элементы и их псевдонимы для плагинов Zen HTML - вторая часть оной библии. Длиннейшая скатерть с полезнейшими сокращениями. Тоже можно юзать в качестве справочника и запоминать по ходу использования.
4. CSS-свойства и их псевдонимы для плагинов Zen CSS - третья часть. Использовать аналогично предыдущей.
5. Домашняя страница Zen Coding. Самая вкусная ссылка. Там есть все вышеуказанные ссылки, а так же много других, не менее интересных, включая ссылки на добрых два десятка плагинов для разных редакторов и сред.

### Кому говорить спасибо?

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

Спасибо надо сказать в первую очередь Вадиму Макееву, придумавшему концепт Zen Coding в его нынешнем виде, а так же автору ранних версий, и Сергею Чикуёнку, воплотившему его в коде. Так же можно сказать спасибо автору плагина для вашего любимого редактора или же вам самим, если вы таковым пожелаете стать.

Много слов (в том числе нелицеприятных) было сказано о различных интернет-банках и подобных системах, отличающихся крайне кривым интерфейсом, который зачастую еще и работает только в ИЕ6. Безумное количество лучей различного содержания было послано их разработчикам и Биллу Гейтсу заодно, огромное количество нервов вымотано и, по некоторым данным, с несколькими известными дизайнерами и юзабилити-экспертами случился инфаркт.

Почему все это происходит? Недавно мне представился случай увидеть это со стороны программиста. Один из моих друзей работает в компании, разрабатывающей какую-то крупную систему, помимо прочего работающую с финансами и документами. В детали я не вникал, но система здоровенная, работает над ней куча людей. Мой друг работает в этой компании Java-кодером. Сразу скажу, что программист он толковый, гораздо опытнее меня, но с вебдевом дела не имел чуть менее, чем вообще. Недавно он стукнулся ко мне в аську с вопросами по html-верстке, ибо его отрядили писать веб-интерфейс к той системе. Сами вопросы воспроизводить не вижу особого смысла, но куски кода, которые он приводил, просто выносили мозг запутанностью и “семантичностью” верстки. Часть объяснялась применением достаточно запутанного, с моей точки зрения, шаблонизатора wicket (по ощущениям - что-то вроде Smarty, только для Java). Однако были там и такие вещи, как таблица внутри и аналогичные прелести. Неудивительно, что браузер от таких финтов бесился и отрисовывал все как попало.

К чему я это говорю? Да к тому, что мой друг Java-кодер, а не верстальщик. И в его обязанности изначально не входила верстка. Однако кто-то решил сэкономить (опять кризис виноват?) и свалить на него и верстку тоже. Результат: все выглядит совсем не так, как хотелось бы, html-код до жути избыточен и трудночитаем. Думаю, что не погрешу против истины, если скажу, что зачастую та же ситуация возникала и при разработке других систем, интернет-банков и пр. А потом мы сидим на каком-нибудь хабре и поливаем говном разработчиков интернет-банка.

PS. Кстати, когда я подключал себе интернет-банк в альфа-банке, мне в офисе сказали, что он работает только в IE. Однако я уже почти полгода спокойно пользуюсь им из-под Linux’a в Firefox. Так что еще не все потеряно :-)

PPS. Кто-то ищет недорогой хостинг, кто-то говорит, что это миф, а между тем он таки существует :-)

PPPPS. Что-то много сегодня постскриптумов получилось :)