Отключаем кэширование загружаемых 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();

});

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

Отзыв о cloud4box.com

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

  1. Нет информации про юрлицо, лицензии и т.д.;
  2. Покупают положительные отзывы. Мне предлагали зачисление на мой баланс месячной стоимости аренды VPS сервера за позитивный пост об их услугах в блоге или соц. сетях. Это сразу насторожило, но сперва не придал этому значения. А зря;
  3. Ужасная поддержка. Телефон не отвечает. Система тикетов — убогая. Для управления учетной записью и серверами, что прикреплены к этой учетной записи — две отдельных панели с разными логинами/паролями. Нет уведомлений об ответах на тикеты — вот сиди и сам проверяй — ответил тебе кто-нибудь, или нет;
  4. Выдают IP адреса, находящиеся в черных списках, спам-листах и т.д. Такое ощущение, что они сами не стесняются заниматься спамом и «чернухой», или их клиенты их же используют в основном именно для этого;
  5. Выделяемые ресурсы не соответствуют заявленным. На сервере крутил только 3proxy крайней версии собранный из исходников. Через сутки сервер просто умирал в прямом смысле этого слова. Только рестарт через панель управления спасал ситуацию, и то — только на сутки. Не верите? Вот ссылка на скриншот. Для эксперимента снёс всё, и поставил чистую ОС. Ресурсы даже на чистой ОС просто утекают куда-то в линейной прогрессии!
  6. Сервер доступен не отовсюду. Cо своего рабочего IP не мог подключиться к серверу! Поддержка говорит «А мы ничего не знаем, проблема не с нашей стороны», хотя проблема ТОЛЬКО с ними;
  7. Разводят на более дорогие тарифы;
  8. Чтоб написать в саппорт — надо ПОКУПАТЬ РАЗРЕШЕНИЯ! ПОКУПАТЬ, КАРЛ (скриншот)!
  9. Деньги не возвращают, даже при обосновании того что они не оказали заказанные услуги в полном объеме;

Вывод: Рекомендуйте их своим врагам. Пускай оплачивают вперед. Тратят нервы, силы, деньги, человеческие ресурсы. Сами же обходите их стороной, при возможности всем рассказывая кто они такие на самом деле.

Поднимаем свой, приватный прокси-сервер

Сегодня мы будем поднимать анонимный и действительно шустренький proxy/socks сервер для себя-любимого. Так чтоб настроить его один раз, да и забыть — пускай пыхтит да нам на радость.

Будем считать что ты уже приобрел себе простенький vps, в качестве ОС выбрал Cent OS 7 и подцепился к нему по SSH, наблюдая девственную чистоту. Первым делом тюним SSH:

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

Дружим rclone с Яндекс.Диском

Сегодня мы поговорим об одном интересном, простом в обращении и в какой-то мере уникальном инструменте. Знакомьтесь: rclone. Разработчики описывают его краткой и ёмкой фразой — «rsync для облачных хранилищ».

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

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

Создать зеркало обновлений для 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.

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