Ne v kontakte Asocial programmer's blog

RoboMap: привет из прошлого.

Feature image

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

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

Сегодня утром я первым делом убедился, что сайт снова онлайн, и стал разбираться, в чем причина. Каково же было мое удивление, когда я увидел, что 70% квоты трафика пришлось на robomap.nevkontakte.org.ru - тот самый проект двухлетней давности! Я тут же полез смотреть его собственную статистику и увидел, что лог посещений поисковиками за два года раздулся до полутора сотен тысяч записей, при чем последние записи датировались сегодняшним днем!

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

Оказалось, что будут и еще как. Google и Rambler принялись с таким энтузиазмом жрать страницы, что в июле выкачали с сайта 16 Гб абсолютно неинтересного, генерированного контента. Почему? Хотел бы я знать, но в индексе Google в данный момент сидит 5 тысяч страниц, а у Рамблера - 14. Яндекс оставил только заглавную и еще парочку, а на остальных я не смотрел.

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

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

PS. Все чаще встречаю на блогах вместо стандартных комментариев комментарии от сервиса Disqus. Лично у меня они вызывают противоречивые чувства, но если кому интересно, то вот: установка плагина Disqus на Wordpress.

Концепт всесторонне полезного файлохранилища.

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

Вот что мне удалось сочинить за час, который я потратил на это задание:


I. Термины.

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

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

II. Общая концепция.

Учитывая последние тенденции (которые некоторыми называются web 3.0) для создания успешного файлового хранилища стоит следовать трем важным условиям:

  • Простота использования
  • Простота интеграции
  • Персонализация
  • Так же следует принять во внимание популяризацию облачных хранилищ (Ubuntu One, Dropbox).

Из этих посылок можно прийти к таким выводам относительно свойств файлового хранилища:

  1. Должно предоставляться удобное API для управления файлами в персональном хранилище с одной стороны и API для доступа к публичным файлам с другой.
  2. Необходимо реализовать софт на базе первого API для прозрачной интеграции в систему пользователя. Это могут быть решения на базе fuse для Linux и Installable File System для Windows.
  3. Пользователь может открывать общий доступ к некоторым файлам, что позволяет посетителям их скачивать. Возможно устанавление стоимости скачивания файла - посетитель должен будет оплатить доступ к файлу.
  4. Пользователь может присваивать файлам дополнительную метаинформацию, на основе которой он может структурировать файлы (это в дополнение, но не взамен папок)
  5. Для посетителя не должно быть прямых препятствий для получения доступа к желаемому файлу. Реклама демонстрируется в процессе скачивания/поиска нужного файла.
  6. Глобальная система поиска по публичным файлам (для этого можно так же использовать метаинформацию из п. 4.
  7. Реклама таргетируется на конкретного посетителя с учетом его интересов. Для этого можно использовать его историю скачивания файлов и, возможно, интеграцию с какой-нибудь популярной системой web-статистики (Liveinternet.ru и т. п.) для получения сведений о посещаемых сайтах.

III. Реклама.

Контекстная.

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

Медиа-реклама.

Реклама, интегрируемая непосредственно в содержимое файла. Возможные варианты:

  1. Водяные знаки на изображении/видео. Перед отдачей файла пользователю эта реклама (выбранная с учетом интересов пользователя) накладывается на контент и после этого передается в браузер. Вариант более щадящий в отношении нагрузки на сервер - добавление рекламы к файлу в момент добавления на сервис в соответствии с извлеченной метаинформации, предусмотренной форматом файла, и дополнительно указанной пользователем.
  2. Рекламные ролики в начале/конце/середине видео файлов. Подход аналогично предыдущему.
  3. Дополнительные файлы с рекламой в архивах. А архивы пользователя добавляются дополнительные файлы какого-либо формата с рекламой.

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

IV. Монетизация сервиса.

Пользователь (владелец файлов):

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

Посетитель:

  1. В процессе навигации по сайту ему показывается контекстная реклама.
  2. Бесплатный доступ к файлу предоставляется при условии интеграции в файл медиа-рекламы.
  3. Платный доступ позволяет скачивать оригинальный файл без рекламы.

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

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

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

Как я участвовал в олимпиаде по веб-технологиям

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

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

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

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

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

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

IMG_0255.JPG

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

promotional_merchandise_marksman_tangle_web_cam.jpg

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

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

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

Публикую перевод статьи 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 очередную баннерную сеть, подумал такую очевидную мысль: все популярные и как бы доходные рекламные сети, включая столь любимые публикой тизеры, уже давно добавлены во все возможные баннерорезки, коих уже немало. Одно только расширение AdBlock для Firefox, которым я успешно пользуюсь, имеет 813599 загрузок в неделю и является самым популярным расширением. Кроме того, во многих популярных виндоовых фаерволах, включая Outpost,  уже давно есть встроенные баннерорезки.

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

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

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

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

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

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

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

Заметка на манжетах

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

100_1513.JPG100_1514.JPG100_1515.JPG100_1516.JPG

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

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

Opera Mini для iPhone

Свершилось!

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

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

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

IMG_0180.PNGIMG_0181.PNGIMG_0182.PNGIMG_0183.PNGIMG_0184.PNGIMG_0187.PNGIMG_0188.PNGIMG_0189.PNGIMG_0191.PNGIMG_0192.PNGIMG_0193.PNGIMG_0194.PNGIMG_0195.PNG

lint, large file, _FILE_OFFSET_BITS 64, problem, solaris, llib-lc

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х часов, чтобы найти эту маленькую заметочку. В моем случае это был вопрос “на засыпку” - не ответил бы, не приняли бы лабу. Черт возьми, самое обидное, что к самой лабе это не имеет отношения, чисто повозить мордой об стол.

Simple AJAX Long Request

Для одного из моих проектов, над которым я сейчас активно работаю понадобилось сделать возможность выполнения длинных запросов с “обратной связью”, т. е. с возможностью отсылки информации о ходе выполнения скрипта. Поскольку подключать к проекту какого-нибудь монстра типа 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