Креатив: более-менее законченные статьи

Удобная разработка букмарклетов


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

О букмарклетах

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

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

Кроме того, букмарклет — это практически единственный шанс для честного вебмастера выполнить свой код в контексте чужого сайта (-:

 Когда нужно писать букмарклет?

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

Так как же его написать?

Основные концепции написания букмарклетов хорошо изложены в статье на javascript.ru. Я же не буду лишний раз повторяться и сразу перейду к своей методике.

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

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

function my_bookmarklet() { /* ... */ }

Мы прибегнем к альтернативному варианту:

var my_bookmarklet = function(arg1, arg2) { /* ... */ }

Это связано с тем, что в букмарклете нам нужна не именованная функция, а анонимная, чтобы не засорять пространство имен и избежать конфликтов.

Генерация итогового букмарклета

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

// Ключевой момент: делаем из анонимной функции строку с ее исходниками.
var code = my_bookmarklet.toString();
// Вырезаем однострочные и многострочные комментарии.
code = code.replace(/\/\/.*/g, "");
code = code.replace(/\/\*[\s\S]*\*\//, "");
// Заменяем переносы строк пробелами
code = code.replace(/\n/g, " ");
// Вырезаем повторяющиеся пробелы.  Если у вас внутри строковых литералов
// есть повторяющиеся пробелы, то этого лучше не делать.
code = code.replace(/\s+/g, " ");
// Генерируем uri, при этом экранируем спецсимволы.
var link = encodeURI("javascript:void("+code+"(\""+value_for_arg1+"\", \""+value_for_arg2+"\"))");

Обратите внимание на переменные value_for_arg1 и value_for_arg2. Если вам нужно (как в моем случае) генерировать параметризованные букмарклеты, то вы можете это легко реализовать, передавая параметры вашей анонимной функции.

Далее с переменной link можно делать все, что хотите — генерировать и вставлять на страницу ссылку с этим значением href, отображать просто так или что вам еще в голову придет.

Грабли

Есть только одни грабли, на которые легко попасться в процессе написания букмарклета таким способом: ни в коем случае нельзя пользоваться какими-либо функциями или переменными, объявленными вне экспортируемой функции, ведь во время исполнения букмарклета (а это почти наверняка произойдет не на вашем сайте и в чужом окружении) все они доступны не будут. Я, кстати, на эти грабли тоже наступил, правда, довольно быстро это обнаружил и исправился.

Итог

В качестве итога еще раз перечислю все бонусы, которые мы получаем при разработке букмарклетов таким способом:

  1. Правильно форматированный код.
  2. Возможность спокойно писать код в вашей любимой IDE.
  3. Простота тестирования - вы можете в считанные секунды сгенерировать тестовый букмарклет и запустить его, не тратя время на его переформатирование оформление.
  4. Возможность динамически генерировать букмакрлеты с разным поведением, за счет использования параметров.

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


Вступление

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

Мы — гики

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

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

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

Практически

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

  1. Будь корректен, ты пример для всех.
  2. Эмоции — плохой помощник, они отвлекают от дела.
  3. Знаешь ответ — ответь. Не знаешь — промолчи. Не уверен, скажи об этом прямо или запроси нужную дополнительную информацию.
  4. Вопрос уже обсуждался — дай ссылку на то, где обсуждался, и закрой тему. Посылаешь в поиск — дай запрос, по которому искать. Придумывать правильные запросы легко, но только когда знаешь, что искать. Ты — знаешь, но пользователь — нет, иначе не спрашивал бы.
  5. Если вопрос требует времени, потрать его. Ведь ты здесь в первую очередь для решения сложных проблем.
  6. Если времени нет, просто молча пройди мимо. У кого-нибудь другого оно найдется и все будут довольны.
  7. Если кто-то ответил неправильно, поправь и объясни, почему его ответ неправильный. Аргументы в духе «ты идиот и кругом неправ» не канают.
  8. Иди на контакт. Не бойся общаться в личке, если это требуется для решения проблемы. Пользователю будет приятно, что тебе небезразлична его проблема, а тебе — что пользователь будет тебе благодарен.
  9. Если тебе хамят, будь еще корректнее. Умение вежливо отвечать на грубость даст тебе лишь преимущество. Напрашивается на бан — забань, но вежливо и согласно правилам.
  10. Наказывай всех. Если кто-то нарушил правила, то он должен получить наказание, независимо от репутации и стажа.
  11. Будь снисходителен. Если ты видишь, что нарушение несущественно и сделано неумышленно, просто объясни пользователю в личке, в чем он нарушил правила и, что больше так не надо делать.
    Это очень важное правило! Я неоднократно убеждался, что пользователи после такого обращения начинают гораздо тщательнее придерживаться правил, чем после бана или ворнинга. Так же важно это обращение делать именно в личке, ибо всякому будет обидно, если его огрехи будут обсуждаться публично. Найти золотую середину между этим и предыдущим пунктом непросто, но очень важно.
  12. Позволь пользователю исправиться и сними наказание. Для тех, кто нарушил правила не со зла это будет очень хорошим стимулом придерживаться правил.
  13. Если пользователь не может исправить нарушение сам, сделай это за него. Права модератора тебе даны именно для этого, а не для нажатия кнопки «бан».
  14. Другие будут уважать тебя тогда и только тогда, когда ты уважаешь других. Так устроен мир.

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

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

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


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

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, то желающих считерить или просто «похакать терминалку» станет на порядок-другой больше. И не стоит недооценивать школьников — найдутся и те, кто умеют гуглить. Если же принять во внимание лирическое отступление, которое я сделал в первой части, то тут еще и поле для утечки данных. Думаю, каждый сможет придумать еще пару способов применения.

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


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

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


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

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


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


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

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