• Favicon сегодня: форматы, поддержка, автоматизация

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



    Читать дальше →
  • Чек-лист по выживанию сайта



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

      «Это все только для хайлода» — скажет вдумчивый и прозорливый читатель. Плох тот веб-проект, который не мечтает стать популярным хайлодом.

      Читать дальше →
    • Создание пакета Debian с нуля

      • Перевод
      Создание пакета Debian с нуля является своего рода волшебным процессом. Вы могли бы начать гуглить с запросом “Создание пакета Debian с нуля” и получить множество результатов, ни один из которых не стал бы тем, который Вам необходим. Несомненно, Вы найдете большой обзор команд, которые используются в Debian и, если Вы роете достаточно глубоко, Вы сможете все же найти пару команд, которые помогут создать базовый пакет Debian, но не смогут объяснить, что происходит. Более подробную информацию о том, что все же «происходит» Вы можете получить, в данном посте мы попробуем это частично затронуть.

      Читать дальше →
    • Как покрыть мониторингом все слои инфраструктуры

        image

        Как-то я посчитал, что 1 минута простоя hh.ru в будни днем затрагивает около 30 000 пользователей. Мы постоянно решаем задачу снижения количества инцидентов и их длительности. Снизить количество проблем мы можем правильной инфраструктурой, архитектурой приложения — это отдельная тема, ее мы пока не будем брать во внимание. Поговорим лучше о том, как быстро понять, что происходит в нашей инфраструктуре. Тут как раз нам и помогает мониторинг.

        В этой статье на примере hh.ru я расскажу и покажу, как покрыть мониторингом все слои инфраструктуры:
        • client-side метрики
        • метрики с фронтендов (логи nginx)
        • сеть (что можно добыть из TCP)
        • приложение (логи)
        • метрики базы данных (postgresql в нашем случае)
        • операционная система (cpu usage тоже может пригодиться)

        Читать дальше →
      • Полный перевод Unix-коанов на русский язык



          Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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

          Итак
        • Альтернативы нелегальным ресурсам

          Насколько развиты легальные сервисы по предоставлению кино, сериалов, книг в России? Мне хотелось отойти от пиратских трекеров в пользу официальных ресурсов – на первый взгляд, задача тривиальна донельзя, ведь правообладатели, по идее, должны приложить максимум усилий для удобного доступа к своему контенту. Ведь не возникает же ни у кого сложностей с поиском сока в магазине? Но не тут-то было…
          Пост можно рассматривать как дополнение/продолжение к «А что, если я хочу смотреть фильмы легально?», написанного maep.
          Читать дальше →
        • Test::Spec: плюсы, минусы и особенности

          • Tutorial
          image

          Test::Spec (https://metacpan.org/pod/Test::Spec) — модуль для декларативного написания юнит-тестов на Perl. Мы в REG.RU активно его используем, поэтому хочу рассказать, зачем он нужен, чем отличается от других модулей для тестирования, указать на его преимущества, недостатки и особенности реализации.

          Эта статья не является вводной ни в юнит-тестирование в целом, ни в использование Test::Spec в частности. Информацию по работе с Test::Spec можно получить из документации (https://metacpan.org/pod/Test::Spec и https://metacpan.org/pod/Test::Spec::Mocks). В статье же речь пойдёт о специфике и нюансах этого модуля.

          Читать дальше →
        • Функции в Perl

          • Tutorial
          image

          В Perl заложено огромное количество возможностей, которые, на первый взгляд, выглядят лишними, а в неопытных руках могут вообще приводить к появлению багов. Доходит до того, что многие программисты, регулярно пишущие на Perl, даже не подозревают о полном функционале этого языка! Причина этого, как нам кажется, заключается в низком качестве и сомнительном содержании литературы для быстрого старта в области программирования на Perl. Это не касается только книг с Ламой, Альпакой и Верблюдом («Learning Perl», «Intermediate Perl» и «Programming Perl») — мы настоятельно рекомендуем их прочитать.

          В этой статье мы хотим подробно рассказать о маленьких хитростях работы с Perl, касающихся необычного использования функций, которые могут пригодится всем, кто интересуется этим языком.
          Читать дальше →
        • Документация Mojolicious: Потерянные Главы

          • Tutorial
          Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

          Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

          Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay


          Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

          • описание последовательно выполняющихся операций без «лапши» callback-ов
          • передачу результатов из callback-а(ов) текущего шага на следующий
          • общие данные для callback-ов, объединённых в одну задачу
          • синхронизацию групп callback-ов
          • перехват и обработку исключений в callback-ах

          Используемые термины:

          • (асинхронная) операция — обычно это вызов асинхронной функции вроде  таймера или выкачивания url, которой необходимо передать callback
          • шаг — callback, который анализирует данные полученные с предыдущего  шага (если это не первый шаг), и запускает одну или несколько новых  операций, либо возвращает финальный результат (если это последний шаг)
          • задача — список шагов, которые должны выполняться последовательно  (т.е. следующий шаг вызывается только после того, как все операции  запущенные на предыдущем шаге завершаются)

          Альтернатива Promises

          Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+
          Читать дальше →
        • Документация Mojolicious: Потерянные Главы

          • Tutorial
          Update: статья обновлена для соответствия Mojolicious 6.0.

          Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

          Этот цикл статей предполагает, что читатель уже поверхностно знаком с фреймворком, и у него возникла потребность разобраться в деталях, которые либо не описаны в документации, либо описаны недостаточно подробно и понятно. Для начального ознакомления идеально подходит официальная документация (на английском).

          Содержание


          1. Недостатки
          2. Роутинг: внутреннее устройство
          3. Роутинг: настройка
          4. Параметры HTTP-запроса
          5. Парсинг
          6. Tips & Tricks
            1. Поддержка неблокирующих приложений в режиме CGI
            2. Как работает Mojo::UserAgent при тестировании своего приложения
            3. ojo и Mojolicious::Lite
            4. Переменные окружения


          Другие статьи в этой серии



          Недостатки


          В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код
          sub secret { shift->secrets([shift]) }
          
          либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

          Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

          С проблемой обратной совместимости мы мало что можем сделать (хотя, наверное, можно сделать плагин к Mojolicious, который будет её эмулировать по мере возможности). Зато вторую проблему решить не сложно — недостающую документацию можно написать самостоятельно. По мере изучения Mojolicious я планирую описывать некоторые вещи, которые, по-хорошему, должны быть в официальной документации, отсюда и название этой статьи.
          Читать дальше →
          • +20
          • 11,5k
          • 7