Отключаем кэширование загружаемых RequireJS файлов при разработке

Мне нравится RequireJS. Нравятся принцип построения приложения с его использованием, то как он работает с зависимостями, его гибкость и настраиваемость. Но часто может возникать проблема при разработке на локале — кэширование ресурсов браузером (файл подправил, а изменения не отображаются, так как файл берется из кэша).

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

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

Ниже будет пример его содержания в полном объеме, и думаю что комментарии тут будут излишне (ссылка на док). Такой код можно оставить работать и на продакшене без особых переживаний, но для разработки на локале есть как минимум одно очевидное ограничение — необходимо чтоб домен верхнего уровня был указан в массиве local, а так как для всех своих локальных проектов использую домен верхнего уровня dev — неудобств совсем не замечаю.

Подробнее под катом

Синглтон для RequireJS

Частенько при разработке приложения с использованием requirejs возникает необходимость в реализации паттерна синглтона. И вот, испробовав пример его реализации что описан ниже заявляю — он имеет право на жизнь. Не без своих недостатков, разумеется, но в целом вполне применибельно:

'use strict';

define([], function () {

  /**
   * Singletone instance.
   *
   * @type {OurNewSingletone|null}
   */
  var instance = null;

  /**
   * OurNewSingletone object (as singletone).
   *
   * @returns {OurNewSingletone}
   */
  var OurNewSingletone = function () {

    /**
     * Initialize method.
     *
     * @returns {}
     */
    this.init = function () {
      // Make init
    };

    // Check instance exists
    if (instance !== null) {
      throw new Error('Cannot instantiate more than one instance, use .getInstance()');
    }

    // Execute initialize method
    this.init();
  };

  /**
   * Returns OurNewSingletone object instance.
   *
   * @returns {null|OurNewSingletone}
   */
  OurNewSingletone.__proto__.getInstance = function () {
    if (instance === null) {
      instance = new OurNewSingletone();
    }
    return instance;
  };

  // Return singletone instance
  return OurNewSingletone.getInstance();

});

И после, указывая наш модуль в зависимостях — мы получаем уже готовый к работе инстанс объекта (один и тот же в разных модулях), что и требуется.

Создать зеркало обновлений для Eset Nod32?

Однажды я уже писал об этом, но с того момента над скриптом было проведено не мало работы. Скажу более — он был переписан чуть менее чем полностью, и как следствие — выяснились некоторые очень «интересные» моменты. Один из них заключается в том, что старая версия скрипта хоть и работала, но совсем не так, как надо.

Если подробнее — то она не подходила для версий антивируса старше четвертой. Как оказалось — нод не умеет самостоятельно определять под-директорию из которой ему следует обновиться, и как следствие все пытались обновиться из корня — и как следствие обновлялась только «четверка». Далее — старая версия не умела обновлять компоненты антивируса. Далее — в итоговое зеркало не попадали все необходимые «модули». Ещё — был чертовски кривой веб-интерфейс.

Так же просмотрел значительное количество решений других разработчиков. Забавно то, что 90% из них написаны на php, и состоят из одного файла с лютым хардкодом всего что можно, и чего нельзя. Да и не поддерживаются совсем.

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

Подробнее под катом

Автоматический деплой WordPress темы/плагина с Bitbucket

Времена, когда приходилось ручками заливать изменения файлов на prod-сервер — стремительно проходят, и на смену им приходят системы контроля версий и автоматизированный деплой. Ведь это чертовски удобно, когда ты один или с командой можешь работать над проектом, обкатывать изменения на локальном/тестовом сервере, и уже протестированный код отправлять на «боевой» сервер простым коммитом или слиянием. Ничего более не запуская, Карл!
Временами так же приходиться работать над проектами, построенными на (пускай и по дизайну очень убогому) WordPress, у которого очень низкий порог вхождения как у разработчиков, так и у конечных заказчиков (с первого раза правильно прочитал «конечных заказчиков»?).
Почему бы не настроить автоматический деплой кода из приватного репозитория на Bitbucket.org (или GitHub — не принципиально, но на нем нет халявных бесплатных репозиториев) на «боевой» сервер под управлением этой CMS?

Давай сперва определимся с некоторыми моментами:

  • В репозитории будет храниться только тема. Хранить в репозитории код самого WP и плагинов с wordpress.org смысла не имеет, так как авто-обновление (надеюсь, включенное и настроенное по умолчанию) делает это совершенно бессмысленным. Можно аналогичным способом деплоить и кастомные плагины;
  • Конфиги для nginx так же в репозиторий не попадают. Да, можно было бы подключать их директивой include /path/to/theme/config/*nginx*.conf, но это и потенциальная возможность править от имени пользователя php конфиги nginx, и необходимость ему же дать право перезапускать его. Нельзя так делать;
  • Использовать мы будем webhooks, а это ещё тот костыль по большому счету, так как не дает гарантии корректного выполнения кода на prod-сервере по причине отсутствия контроля состояния запроса;
  • Синхронизацию БД придется делать любыми другими средствами, если они необходимы. О миграциях и прочих «вкусных» штучках задумываться есть смысл при разработке именно плагина, и реализовывать их придется самостоятельно;
  • Придется разрешить php выполнять функцию exec().

Но не смотря на озвученные выше очевидные минусы — это в дохрена раз удобнее, чем ничего. Работать будем под CentOS 7.

Подробнее под катом

RSS → Bash → Transmission

Нахрен долгое вступление. Если на вопрос «Нравится автоматизировать и любишь посмотреть кино?» ты неосознанно ответишь положительно, то то что здесь написано — тебе понравится. Итак, наверняка у тебя есть своя железяка, которая стоит дома/офисе где-то в уголочке и выполняет роль файлошары/торрентокачалки и Джа знает ещё чего.

Железяка (4 фотки в 1)
Hardware:
Мать MSI C847IS-P33
Камень Распаян на плате, Intel(R) Celeron(R) CPU 847 @ 1.10GHz / 2 ядра
Память DDR3 @ 2 Gb
SDD (система) Kingston @ 8 Gb
HDD (данные) WG Green @ 2 Tb

Что такое RSS torrent?

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

Которые этим и живут. Конечный пользователь приходит, выбивает интересный ему контент, получает ссылку на свою ленту, кормит её своему торрент-клиенту (который в свою очередь должен поддерживать torrent rss) — получая в конечном счете новые серии любимых сериалов/фильмов определенной тематики почти без задержки и лишних действий. Пиздец как удобненько.

Подробнее под катом

Индикатор загрузки страницы (css + pure js)

Время загрузки страницы — самая унылая часть веб-серфинга :) До того момента, пока страница не загрузилась до конца, велика вероятность что она будет отображаться не так как мы задумывали — блоки могут «наезжать» друг на друга, текст — не отображаться (пока не загрузились шрифты), про корректную работу скриптов а анимации тоже зачастую можно забыть.

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

Итак, каким же требованиям должен отвечать наш индикатор загрузки?

  • Отсутствие растровых изображений;
  • Старые браузеры — в топку, мы будем использовать современные CSS3 методы;
  • JavaScript поддерживается и включен по умолчанию более чем на 90% браузеров — не стесняемся его использовать;
  • Минимализм по возможности во всем — это же индикатор загрузки, и именно он должен загрузиться и отрисоваться у клиента быстрее всего;
  • И не забываем про адаптивность под мобильные гаджеты.

Подробнее под катом

JavaScript — получаем статус Skype, VK и Jabber аккаунтов

Вывод статуса аккаунта — довольно удобная хреновина которая позволяет, например, на странице контактов сразу указать — аккаунт в данный момент в сети, или же нет. Сейчас мы рассмотрим функции на Javascript (с использованием jQuery) для получения статуса аккаунта из трех наиболее популярных сервисов — Skype, VK.com и Jabber. Комментарии имеются лишь у первой по причине некоторой их однотипности — разобрав как работает одна — ты поймешь как работают и остальные. Демка так же имеется в конце этого поста.
Подробнее под катом