Архив рубрики: Разработка

Рендеринг svg-контейнера с defs внутри

Инлайновые svg-объекты, объявленные внутри элемента <defs>, считаются одним из эффективных способов переиспользования векторной графики. Например, можно объявить несколько иконок:

<svg xmlns="http://www.w3.org/2000/svg">
  <defs>
    <symbol id="icon1" viewBox="0 0 10 10" fill="none">
      <path ... />
    </symbol>
    <symbol id="icon2" viewBox="0 0 10 10" fill="none">
      <path ... />
    </symbol>
  </defs>
</svg>

Затем многократно использовать их в коде:

<svg class="my-icon"><use href="#icon1" /></svg>

Все прекрасно, только корневой элемент <svg> (пустой) будет отрендерен браузером в размере по умолчанию, то есть 300×150 px. Кстати, в спецификации рекомендуется объявлять элементы по возможности раньше. Таким образом, если поставить их в начало документа, мы получим пустое место прямо вверху:

Читать далее 

Плагин Jekyll ExtLinks на RubyGems и GitHub

Плагин ExtLinks для Jekyll добавляет нужные вам атрибуты к внешним ссылкам в контенте (например, rel="nofollow", target="_blank"). Изначально был опубликован здесь.

Теперь Jekyll ExtLinks выпущен на RubyGems, а исходник опубликован на GitHub. Спасибо человеку, который последовательно пинал меня, чтобы это произошло.

Jekyll — отличный генератор статических сайтов на Ruby, он мне нравится, так что пусть это будет небольшим вкладом в «комьюнити».

Плагин ExtLinks для Jekyll

Для Jekyll не нашлось готового плагина, который автоматически проставлял бы rel="nofollow" во внешних ссылках, пришлось сделать его самому. Вероятно, и другим пригодится: Jekyll ExtLinks Plugin. В принципе, он позволяет добавлять не только rel, но и любые другие атрибуты — например, target="_blank". Относительные ссылки не трогает, имеющийся rel тоже не трогает. Можно перечислить список хостов, ссылки на которые надо пропустить при добавлении rel. Краткая инструкция прилагается.

Требуется Nokogiri, плагин основан на этом коде.

Использовать ли PostCSS?

Читал в нежно любимом Smashing Magazine статью An Introduction To PostCSS. Уже в процессе предчувствовал, какие там будут комментарии внизу. И точно: «too much development before you even start development», — сказали люди. Выглядит достаточно сложно, сомнения понятны. При том, что выгода не вполне ясна, стоит ли инвестировать время и силы в изучение того, что через некоторое время окажется пройденным этапом?

Читать далее 

Простой способ настроить Content Security Policy (CSP) для сайта

Зачем?

Настройка Content Security Policy для сайта — не мелочь, а необходимость. Мы не можем знать, что на той стороне у клиента, а это вполне может быть зараженный браузер, зараженные плагины и, в общем, что угодно. Выглядеть это может так: клиент открывает сайт, а вместо ваших рекламных блоков там чужие. Или клиент хочет куда-то нажать, но подгруженный кликандер злоумышленника перехватывает клик и отправляет клиента на левый сайт (возможно, вы найдете переходы на такие сайты в своей статистике LiveInternet).

Content Security Policy защищает пользователя от подобных атак, в явном виде указывая браузеру, откуда разрешено загружать тот или иной контент. Уже два года назад более половины используемых браузеров поддерживали CSP. Сейчас доля поддержки CSP 1.0 приближается к 90% (см. статистику тут).

Читать далее 

Изменения в Facebook API с 30 апреля 2015 года

Operation Developer Love. Подавление разработчиков в любовном порыве

30 апреля 2015 года вступят в силу, пожалуй, самые драматичные изменения в Facebook API за всю его историю. Они коснутся всех без исключения разработчиков. В сущности, это не столько изменения, сколько ограничения, которые для многих приложений будут означать либо прекращение их существования, либо существенное урезание функционала (которое, опять же, поставит под вопрос смысл их существования).

Нам тоже придется отказаться от фейсбучного функционала на крупном проекте. Я посмотрел сегодня — у нас порядка 30 тысяч пользователей воспользовались этим функционалом за все время, и теперь его не будет. Фейсбук хочет, чтобы все просто сидели в Фейсбуке. В интернете OpenGraph уже называют ClosedGraph, что достаточно точно отражает суть происходящего.

Итак, что же произойдет 30 апреля?
Читать далее 

Kirby CMS

Открыл для себя очень приятную CMS на файловой основе — Kirby. Простая, понятная, вроде ничего особенного, но ее внутренняя внимательность к мелочам цепляет. Это из разряда «прямо сейчас не нужно, но я бы купил» (она недорогая, особенно для персонального использования). Если делал бы какой-нибудь личный сайт, выкладывал портфолио и тому подобное — самое то. Собственно, и пришел на нее по упоминанию на сайте Джессики Хиш, который сделан на Kirby.

Расширение HyperComments для MediaWiki

Поскольку очевидный спрос есть, да и хочется внести какой-то вклад в проект, выложил расширение HyperComments на mediawiki.org. Добавляет блок комментариев внизу каждой статьи, кроме главной страницы. Все необходимые пояснения там есть. Успешно используется на Рулусе.

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

Рулус и Вики

Когда мне нужно было выбрать вики-движок для Рулуса, MediaWiki была исключена из возможных вариантов за избыточный функционал (и, возможно, за свою внешность).

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

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

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

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

Рулус был перенесен на MediaWiki (последняя стабильная версия на этот момент — 1.22) и вчера выпущен на промысел. Конечно, там все более четко. Благодаря тому, что от движка зависит Википедия, они не могут позволить себе явных косяков. Но в целом, как мне показалось, дела в сообществе скорее грустные. Например, на Stack Overflow человек что-то спрашивает, и ему говорят: «А почему вы не спросите на странице обсуждения где-то на mediawiki.org?» Он отвечает: «Да я спросил, но там уже несколько месяцев никто не отвечает, поэтому я сюда пришел».

Скажем, к MediaWiki нельзя просто взять и прикрутить вход через OAuth. Есть расширение для Facebook, я взялся за него, но не так-то просто. Последняя версия использует что-то из MediaWiki 1.23, которая сейчас пока в альфе — соответственно, пришлось взять предыдущую. Далее, она использует класс из 1.21, которого уже нет в 1.22 — почему это сохраняется в расширении вплоть до последней версии, я так и не понял. К счастью, реально этот класс не очень-то нужен, так что просто берем его из 1.21 и подсовываем. Была еще проблема с сертификатом, но это уже знакомо и решение есть. В итоге вход через Facebook заработал.

Что касается стилей, выбор небольшой, в основном все очень старое и уродливое. То, что сейчас на Рулусе, было получено допиливанием стиля Vector. Не все гладко с мобильным фронтендом, он почему-то не подгружает дополнительные стили, которые должен подгружать. Вот просто так пишут — в предыдущей версии была ошибка, они не грузились, а в этой должны. Пришлось вшивать это туда довольно грубым способом.

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

Можно ли использовать Gettext?

Вопрос: можно ли кому-либо, когда-либо, при каких-либо обстоятельствах использовать Gettext?

Ответ: нет.

Заменил на php-gettext, для моих целей достаточно (но это может быть и Zend_Translate).

Использую самым примитивным образом:

require_once('gettext.inc');
// ...
T_setlocale(LC_MESSAGES, $locale);
$domain = 'messages';
T_bindtextdomain($domain, $locales_dir);
T_bind_textdomain_codeset($domain, 'UTF-8');
T_textdomain($domain);

Это дает нам функцию T_() для использования вместо _(). Если расширение gettext не будет найдено, то _() все равно будет работать, но через эмуляцию. Чтобы полностью уйти от gettext, у себя везде заменил _() на T_().

Разумеется, сколько-то мы теряем в скорости, но «сколько — никто не знает».