Ne v kontakte Asocial programmer's blog

Кодекс саппортера.

Вступление

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

Мы — гики

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

Пользователь заслуживает уважения

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

Практически

Уважай себя. Делай так, чтобы тебя уважали другие. «Боятся — значит уважают» — это не про нас. Да и вообще ни про кого, если уж на то пошло.

  1. Будь корректен, ты пример для всех.

  2. Эмоции — плохой помощник, они отвлекают от дела.

  3. Знаешь ответ — ответь. Не знаешь — промолчи. Не уверен, скажи об этом прямо или запроси нужную дополнительную информацию.

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

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

  6. Если времени нет, просто молча пройди мимо. У кого-нибудь другого оно найдется и все будут довольны.

  7. Если кто-то ответил неправильно, поправь и объясни, почему его ответ неправильный. Аргументы в духе «ты идиот и кругом неправ» не канают.

  8. Иди на контакт. Не бойся общаться в личке, если это требуется для решения проблемы. Пользователю будет приятно, что тебе небезразлична его проблема, а тебе — что пользователь будет тебе благодарен.

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

  10. Наказывай всех. Если кто-то нарушил правила, то он должен получить наказание, независимо от репутации и стажа.

  11. Будь снисходителен. Если ты видишь, что нарушение несущественно и сделано неумышленно, просто объясни пользователю в личке, в чем он нарушил правила и, что больше так не надо делать.

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

  12. Позволь пользователю исправиться и сними наказание. Для тех, кто нарушил правила не со зла это будет очень хорошим стимулом придерживаться правил.

  13. Если пользователь не может исправить нарушение сам, сделай это за него. Права модератора тебе даны именно для этого, а не для нажатия кнопки «бан».

  14. Другие будут уважать тебя тогда и только тогда, когда ты уважаешь других. Так устроен мир.

Если пользователи — дятлы

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

Я уже постил эту песню, но позволю себе нарушить традицию и вставлю ее еще раз, уж очень она хорошо подходит к ситуации.

Let’s cloud!

Feature image

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

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

Отправной точкой для меня стала почта. Исторически у меня было 7 разных почтовых ящиков, которые нужно было читать. Они все были забиты в настройки почтовика на моем настольном компе и на нем же был примерно четырехлетний архив переписки. В итоге, доступ к большей части почты у меня был только из дома, что создавало массу неудобств. В какой-то момент я принял волевое решение настроить сборку почты на моем основном ящике GMail’a и импортировать туда весь архив, заодно сменить kmail на более продвинутый Thundebird и архаичный POP3 на IMAP.

Потратив один выходной, я все это сделал и принялся наслаждаться результатами труда: дома я по-прежнему пользовался почтовиком, с остальных девайсов — веб-интерфейсом GMail. И через пару недель я начал осознавать, что IMAP не вполне корректно работает с ярлыками GMail’a, а основная польза от почтовика — счетчик писем в трее. В итоге, Thunderbird в одночасье оказался заменен на аддон для Firefox WebMail Notifier и веб-интерфейс почты. Так я полностью перенес поту в облако.

Параллельно с этим я стал пользоваться такими штуками, как DropBox (рефералка принесет мне и вам лишних 200 мб бесплатной квоты), с помощью которого я стал обмениваться файлами с коллегами и значительно уменьшил беготню с флешкой от компа к нетбуку и обратно. Read It Later стал перекидывать ссылки на почитать между компами и на телефон. Todoist заменил стикеры и выгодно отличается от них тем, что он не приклеен к одному монитору. Оказалось, что даже для телефона есть его клиент (глючноватый, но есть). Xmarks утащил в облако мои закладки (хотя тут с облачностью можно поспорить, но тем не менее). Жить стало чуточку легче.

Но всему есть цена, и облачность — не исключение. Платить приходится тремя вещами:

  1. **Конфиденциальность.**Отправляя данные сервис-провайдеру мы должны доверять ему и надеяться, что никто посторонний наши данные не увидит.
  2. **Интернет.**Облачность практически всегда требует постоянной связи с интернетом. Та же почта — чтобы прочесть старую переписку нам придется подключаться к интернету и потом уже смотреть. В классическом случае с почтовым клиентом весь архив почты у вас на жестком диске и доступен хоть в Антарктиде. Ситуацию смягчает растущая доступность мобильного интернета, но сотовый ведь ловит не везде.
  3. Зависимость от третьих лиц. Решит ваш сервис закрыться или стать платным, и вам придется тратить силы на поиск альтернативы и привыкание к ней. Тот же Xmarks не так давно напугал всех пользователей тем, что он в скором времени собирается закрыться. К счастью, довольно скоро было объявлено, что апокалипсис отменяется, а у сервиса будет новый владелец.

Я довольно долго шел к тому ,чтобы принять эту цену, но в конце концов удобство окупило ее.

А что вы думаете об облаках? Чем пользуетесь или собираетесь использовать? А может у вас есть аргументы против? Мне интересно услышать ваше мнение!

UPD (Apr 2020): Десять лет спустя я вернулся обновить битые ссылки в посте в связи с закрытием Xmarks. Любопытно заметить, что из сервисов, упомянутых в посте, до сего дня не дожил только Xmarks. Read it later переименовался в Pocket, но по-прежнему живет, GMail и Dropbox так же живее всех живых.

Железобетонные мьютексы в PHP

Feature image

Я хочу рассказать об одном нестандартном применении механизма сессий в PHP. Вспомнилось мне это в связи с позавчерашним постом Тормоза на тему, что опять в Даосе проблема с параллельным доступом к файлам - функция блокировки дала очередной сбой. И хотя Тормоз в комментах уже писал, что обкатывает исправленный алгоритм, успешно выдерживающий стресс-тест, я все же поделюсь своим решением. Сразу оговорюсь, все нижеизложенное было проделано just for fun и имеет свои недостатки. Зато и работает практически безотказно.

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

Реально проблема встает, когда во время выполнения некоторого длительного запроса (стримминг потока или long polling) надо обеспечить клиенту возможность посылать и другие запросы (ходить по страничкам) и вовремя получать ответы. Решают задаю обычно одним из трех путей:

  1. Реализуют полностью свой механизм сессий.
  2. Переопределяют обработчики операций с данными сессии во встроенном механизме (с помощью session_set_save_handler(), этим вариантом я в свое время и воспользовался).
  3. Как можно раньше освобождают сессию с помощью session_write_close().

Но я отвлекся. В нашем случае мы не только не будем избавляться от этого, но наоборот будем использовать для реализации мьютекса: будем создавать сессию с заранее известным session_id, к примеру db_mutex, выполнять критические действия и закрывать сессию. Именно эту функциональность и реализует мой класс PHP_Mutex.

Надо признать, такой подход имеет ряд недостатков по сравнению с полноценными мьютексами:

  1. Захватить можно не более одного мьютекса в одно и то же время.
  2. Механизм хранения сессий не должен быть переопределен.
  3. Если вы при этом используете стандартный механизм сессий, возможны потери данных сессии, поскольку на время использования мьютекса блокировка на файл основной сессии снимается.

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

Сам класс вы найдете во вложении, распространяется он свободно согласно лицензии New BSD License. Если кому пригодится - на здоровье :-)

Скачать: mutex.php

PS. Arsis - A Diamond For Disease

Я в Parallels

Feature image

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

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

Что касается самой компании Parallels, то в зону моего внимания она попала достаточно давно, однако ее продукты у меня вызывали самые разные чувства. Два основных продукта, с которыми мне приходилось иметь дело - это Parallels Plesk Panel и OpenVZ.

С OpenVZ дело обстояло довольно просто, года два назад (офигеть, этому блогу уже два с половиной года и он мне еще не надоел) у меня случился пик интереса к технологиям серверной виртуализации и я естественно не мог обойти вниманием OpenVZ. Тогда я получил массу удовольствия, играясь с контейнерами и прикидывая, для чего оно мне могло бы сгодиться в хозяйстве, но так и не придумал и отложил в долгий ящик. Но теплые воспоминания остались. Позже я столкнулся с этой технологией уже как клиент и на данный момент обе мои VPS работают именно под этой технологией.

А вот с Plesk’ом у меня отношения сложились не так гладко. Года эдак три назад я работал с один человеком, у которого на VPS (точные параметры уже не вспомню, но довольно мощной) был установлен Plesk 7. Это было нечто. С одной стороны, он жрал почти половину памяти сервера даже в простое, держал много файловых дескрипторов и давал небольшую, но постоянную нагрузку на проц за счет постоянно запущенного собственного демона. В результате, сайт весьма основательно тормозил и падал с разными ошибками о нехватке ресурсов. Ну а интерфейс меня вообще приводил в тихое отчаянье: сделанный в стиле Windows XP он требовал для каждого осмысленного действия 3-4 перехода со страницы на страницу, каждый из которых происходил секунд по 10-15 еще и блокируя все действия на время загрузки страницы. То есть, если ты промахнулся и кликнул не туда, то ты не кликаешь тут же куда надо, а ждешь 10 секунд, пока загрузится ненужная тебе страница, потом еще 10 - пока вернешься назад и еще 10 - пока грузится та страница, куда ты хотел изначально. К счастью, клиент был вполне солидарен со мной и мы волевым решением избавились от панели управления вовсе, благо особой нужды в ней не было - на впс жил всего один сайт. С тех пор моими любимыми панелями стали Kloxo и ISPManager за легкость и эффективность.

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

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

GRUB: Получаем полный доступ к системе

Feature image

Дублирую сюда мой пост на Хабре:

GRUB, безусловно, является самым продвинутым загрузчиком на сегодняшний день, и за это любим админами и разработчиками по всему миру. Его функционал настолько широк, что он практически монополизировал рынок загрузчиков в мире *NIX, а некоторые вообще говорили, что GRUB2 — это скорее маленькая операционная система, чем просто загрузчик. Эдакий швейцарский нож в мире загрузчиков.

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

Сценарий 1: загружаемся со внешнего носителя

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

  1. Изготавливаем загрузочную флешку любым способом, например, с помощью unetbootin.

  2. Вставляем флешку и включаем компьютер.

  3. Дожидаемся появления экрана grub (иногда для того, чтобы успеть его поймать, надо держать Shift).

  4. Перед нами появляется список вариантов загрузки.

  5. Нажимаем c и входим в интерактивный режим.

  6. Теперь требуется указать носитель, с которого будем грузиться. Обычно (hd0) — это родной жесткий диск компьютера, а флешка становится (hd1). Выяснить, как назовется флешка в вашем случае, нетрудно просто опытным путем.

    Так или иначе, вводим: root (hd1) для GRUB Legacy или set root=(hd1) для GRUB2

  7. Просим передать управление загрузчику на указанном диске: chainloader +1

  8. Загружаемся! boot

Если вы все сделали правильно, то в результате вы успешно загрузитесь со своей флешки, несмотря на запрет в биосе. Опытным путем мне удалось выяснить, что метод не работает если ваша материнка не умеет грузиться с usb или не опрашивает устройства при каждой загрузке (как, например, на моем eee PC при включенном Boot Booster).

Лирическое отступление: этот метод мне удалось опробовать в одном из терминальных классов нашего университета, где на компах стояли в дуалбуте винда с линуксом. Прелесть того случая в том, что факультетский сервер экспортировал /home по NFS и та терминалка была занесена в разрешенные подсети. В результате, мне удалось прочитать домашние каталоги пользователей того сервера и уйти так никем и незамеченным.

Сценарий 2: получаем консоль root’a

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

  1. Аналогично, добираемся до списка вариантов загрузки.
  2. Выбираем нужный нам вариант.
  3. Входим в режим редактирования. Здесь есть небольшие отличия между GRUB Legacy и GRUB2. В GRUB2 после нажатия клавиши e мы сразу попадаем в режим редактирования, а в GRUB Legacy нужно нажать e первый раз, выбрать строку для редактирования и еще раз нажать e.
  4. Выбираем строку, которая начинается со слова linux или kernel.
  5. Удаляем из нее слова quiet и splash, если они есть, и дописываем в конец single init=/bin/bash
  6. Если у нас GRUB2, то сразу жмем Ctrl+X, а если GRUB Legacy — Esc и потом b

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

Защита?

И GRUB2, и GRUB Legacy предоставляют возможность ограничить доступ к интерактивному режиму и редактированию с помощью директивы password. Подробности описаны в руководстве по GRUB2 и GRUB Legacy. В обоих случаях манипуляции весьма просты и не требуют много времени.

Баян!

В общем, да, ничего нового я не сказал — все это можно нагуглить, например так. Однако, проблема от этого меньше не становится, наоборот. Более того, если с января в школах действительно поставят linux, то желающих считерить или просто «похакать терминалку» станет на порядок-другой больше. И не стоит недооценивать школьников — найдутся и те, кто умеют гуглить. Если же принять во внимание лирическое отступление, которое я сделал в первой части, то тут еще и поле для утечки данных. Думаю, каждый сможет придумать еще пару способов применения.

Nevkontakte.me — introducing Qby CMS

Feature image

Пришло время опубликовать первый из проектов, которые я упоминал в позапрошлом посте. Позвольте представить вам мой новый сайт-визитку: Nevkontakte.ME.

Мысль о том, что неплохо было бы сделать небольшой сайт-визитку проскальзывала у меня уже довольно давно, однако делать еще один тупой трехстраничник в духе “Главная, обо мне, контакты” было неинтересно. И тут я вспомнил об одном из старых постов Тормоза, в котором он предлагал концепт Cuby CMS — движка для микросайтов в виде, как это ни странно, куба. Однако у Тормоза дело не пошло дальше концепта, а у меня как раз была нужда в чем-то оригинальном и в добавок желание поупражняться в JavaScript-fu.

Взяв за основу идею Тормоза, я добавил анимацию перехода между сторонами с помощью CSS3 2D Transforms (по началу хотел для большей реалистичности юзать 3D Transforms, однако его пока поддерживают только nightly-билы вебкита), немного плюшек для более прозрачной навигации и удобную AJAX-админку.

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

Вживую все это вы можете повертеть на Nevkontakte.ME, а админку посмотреть на скриншоте:

acp-qby.jpg

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

Полнотекстовый RSS - это удобно!

Feature image

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

Почему же такая практика стала популярной? Я сходу могу назвать такие причины:

  1. Защита от автоматического воровства контента (по-видимому, самая главная).
  2. Стимуляция пользователя лишний раз зайти на блог.
  3. Желание защитить пользователя от “попадания на трафик” на случай, если вдруг получится большой пост с кучей картинок.
  4. Все так делают.

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

  1. Современные парсеры-грабберы достаточно умны, чтобы пройти по ссылке из ленты на сайт и стащить полный пост.
  2. На самом деле тут все, как мне кажется, наоборот: пользователь как правило или ленив или спешит, поэтому он не будет утруждать себя чтением огрызка и кликом, если тот его не заинтересует с первого взгляда. А заинтересовать не так-то просто. Кроме того, все мы знаем о собственном любопытстве и что если начнем читать - наверняка захочется прочитать все, а кликать лень, лучше не напрягаться и не начинать читать вовсе. В результате блоггер не только не увеличивает посещаемость блога, но и “теряет” часть подписчиков из-за того, что они не читают его посты целиком.
  3. Признайтесь честно, вы не так уж и часто пишете такие посты. И если вдруг случится, что напишете, то вручную поставить кат совсем недолго.
  4. Ну это вообще просто стадный эффект.

Помимо этого я вижу еще как минимум один минуса:

  1. Этот актуален для многих блоггеров, а именно - тех, кто сидит на Вордпрессе. ВП имеет дурное свойство при автоматической генерации тизера для RSS срезать половину форматирования, которое пересекает границу отсечения и в результате выглядит этот тизер ну совсем непривлекательно. Да и обрыв на полуслове тоже не добавляет изящества.
  2. Здесь затронуты мобильные пользователи вроде меня - те, кому удобно закачать обновления ленты дома, а потом спокойно читать в том же транспорте, не тратя деньги на мобильный трафик, цены которого всегда казались мне сильно завышенными.

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

Вообще, самое грамотное решение этой проблемы я видел у vitashok‘a: у него есть два фида: полный и урезанный. Рекомендую все брать с него пример ;)

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

PS. В RSS я полные посты отдаю уже давно, а с этого момента и на главной блога посты тоже будут отображаться целиком.

Летнее

Feature image

Вот и прошло лето :-)

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

Как и у любого студента приход лета знаменуется не первым обгоранием на пляже и даже не легко одетыми девушками, а сессией. Какие уж тут девушки, когда надо за месяц пройти семестровую программу по 5 предметам :D Тем не менее, мне удалось побороть даже самые зверские предметы и избежать троек, честно заработав стипендию (1300р./мес. !).

А вот дальше все пошло гораздо приятнее. Весь июль у меня прошел под знаком Parallels®, поскольку я в этом году все же решил изменить ЛШЮП’у (прости, в следующем году постараюсь наверстать) и пошел на летнюю практику в лабораторию Параллелс-НГУ. Там я работал в довольно большой команде аж из 16 человек над проектом PCI Scanner.

С этим проектом связана достаточно забавная история. Согласно задумке нашего куратора-научрука в команду набрали студентов, окончивших 1-2 курсы и из тех, кто после летней школы останется на стажировку в лаборатории, будет сформирована команда, ориентированная на информационную безопасность. В конце концов, именно эта команда должна заняться изготовлением инструмента проверки биллинговых систем стандарту безопасности PCI. Но, учитывая общую неопытность команды в качестве триального проекта, который позволит нам набить руку в программировании и веб-технологиях в частности, было выбрано создание сайта с играми, основанными на разных математических проблем. Так, например, игра Complexity имеет в своей основе тот факт, что решение системы уравнений над кольцом Z2 - задача NP-трудная, то есть разрешима только полным перебором.

Таким образом, весь июль у меня был посвящен проекту NP-Hard Games, где в мои обязанности входила разработка самого движка сайта. И несмотря на то, что новичком в веб-программировании я уже давно себя не считаю, мне довелось столкнуться с несколькими новыми для меня интересными проблемами и получить массу полезного опыта. В частности я познакомился с новым для меня фреймворком Yii и уже успел его полюбить :-) Еще одной новой для меня задачей стала разработка API для сетевого взаимодействия в играх (да, даже в математических играх бывает мультиплеер ;-)

Происходило все это с 28 июня по 29 июля, и финишной чертой в виде отчетной конференции 30-го июля. Все это время я работал в режиме фулл-тайм, по 8 часов в день с 9 до 18 и часовым перерывом на обед, тоже довольно занимательный опыт. Зато пятидневная рабочая неделя для нас стала раем на земле!

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

На август у меня была запланирована поездка в город Абаза, что в Хакасии, в гости к родителям моей девушки, аж на целых три недели. И, надо отдать должное, эти три недели не сумели омрачить даже такие прелести жизни в частном секторе, как “туалет типа сортир” на улице. 3 недели полной безответственности, вкусной еды, свежего воздуха и позитивного общения оказались именно тем, что нужно измученному учебой, сессией, а потом и летней практикой студенту. Так что теперь я точно знаю, где проведу следующий август :-) Кстати, несмотря на то (или скорее благодаря тому), что Абаза - довольно маленький город, он очень симпатичный, а природа вокруг просто зашибись, да еще и мошек нет (те, кто живут в Академгородке меня поймут). Взять хотя бы то, что я, насквозь городское дитя, с удовольствием дважды съездил по грибы, второй и третий раз в жизни соответственно. Еще одним результатом поездки стало, что я наконец вплотную занялся своим проектом-долгостроем и теперь он уверенно движется к завершению, что не может не радовать.

Вот такое вот было лето. Одно из самых приятных в моей жизни :-)

И напоследок немного о планах - их до фига, дай бог свободного времени. Я планирую написать пару-тройку статей по мотивам разработки nphardgames.com, а так же представить парочку своих последних проектов. Кроме того, я уже давно собираюсь модернизировать этот блог и перевести в порядок уже вышедшие продукты. Наиболее интересными свершениями скорее всего станут две вещи: Google&Bing Cache Dumper станут доступны по свободной цене, а RegSubmitter и вовсе станет бесплатным. Правда, еще не очень скоро, но станет. А еще блог переедет на новый домен и заодно модернизируется.

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