docker-compose

Итак, главный герой, docker-compose. Эта утилита помогает специфицировать контейнеры в декларативном виде, то есть запуск, остановка и другие задачи выполняются посредством конфигурационного файла (по умолчанию docker-compose.yml). Давайте взглянем, каким образом нужно его оформить, чтобы запустить официальный контейнер веб-сервера nginx, который будет отдавать статику из указанной директории. В моём случае я располагаю файл docker-compose.yml в корневой директории проекта.

version: '3'
services:
  nginx:
    image: "nginx:latest"
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - "./build:/usr/share/nginx/html:ro"

Выглядит просто, но давайте разберём всё по порядку.

version

version: '3' указывает версию конфигурационного файла, на момент написания заметки, 3-я версия является наиболее актуальной.

services

Каждый элемент раздела services отвечает за конкретный сервис. В нашем случае он один, где nginx это просто имя сервиса, ничего более.

image

image: "nginx:latest" специфицирует, из какого образа будет создан контейнер, в данном случае это официальный образ веб-сервера nginx, а :latest это тег образа, который чаще всего отвечает за версию.

ports

- "127.0.0.1:8080:80" отвечает за маппинг 80 порта контейнера на интерфейс 127.0.0.1 и порт 8080 хостовой машины. Иными словами, nginx, слушающий 80-й порт внутри контейнера, позволит нам работать с ним, открывая в браузере адрес 127.0.0.1:8080, или, даже проще, localhost:8080.

volumes

- "./build:/usr/share/nginx/html:ro" определяет маппинг разделов.

• ./build — директория нашего проекта, в которой лежит собранная версия сайта, то есть статика, которую и необходимо отдавать через веб-сервер.
• /usr/share/nginx/html — директория внутри контейнера, в которую будет примонтирован раздел с содержимым ./build. Если задаётесь вопросом, почему именно /usr/share/nginx/html, то всё просто, эта директория указана в конфигурации nginx, а конфигурация в свою очередь зашита в базовом образе nginx:latest. Чтобы не собирать руками свой образ со своей конфигурацией, мы просто опираемся на официальный, конфигурация которого уже готова отдавать статику именно из этой директории.
• ro в конце декларации отвечает за то, что раздел будет работать в режиме read-only для нашего контейнера.

Запуск контейнера

Итак, файл конфигурации готов, осталось только запустить. Заходим в корневую директорию проекта и выполняем:

docker-compose up

При первом запуске docker-compose скачает образ nginx, а затем на его основе создаст новый контейнер. При последующих запусках скачивание больше не потребуется, запуск контейнера будет происходить весьма быстро.

Что дальше

Если продолжать развивать тему, то можно увидеть, что docker-compose.yml вполне может отвечать не за один сервис, а за несколько. Это крайне удобно, когда у вас есть проект, требующий сразу несколько серверов (например, веб-сервер и сервер БД). В таком случае, при помощи простой команды docker-compose up достаточно легко подготовить комплексный рантайм зависимостей вашего проекта.

Итак, в итоге мы разобрались, как пользоваться docker-compose в примитивном случае отдачи статического сайта через nginx. Благодарен за ваше внимание, за сим откланиваюсь.

Ссылки

1. Документация по файлу docker-compose.yml
2. Официальный образ nginx в репозитории докера, стоит обратить внимание на примеры

Проблематика

Началось всё довольно давно, с моего знакомства с Node.js в 2014-м. Тогда я поддерживал RESTful API, написанный на фреймворке Express, сессии в котором были реализованы с помощью Passport. Это вряд ли можно было назвать правильными инструментами для тех задач, но тогда я впервые столкнулся с избыточностью Passport и недостаточной гибкостью его сессионных миддлвар. В моём проекте требовалось передавать идентификаторы сессий через кастомный HTTP-заголовок, а не через cookie. Чтобы добиться этого, я делал несколько подходов, пытался законтрибьютить, но в итоге всё закончилось банальным форком, в котором была реализована нужная мне функциональность.

Последняя капля

Время шло, на дворе был уже 2017-й год, я занимался реализацией одного API для своего домашнего проекта на том же Node.js (в этот раз у меня на руках уже был фреймворк Restify). Но, так вышло, что индустриальный стандарт в виде Passport добрался и до туда. Нет, на самом деле, не очень-то он и добирался, просто так вышло, что API его миддлвары подходил к в том числе и к Restify. И, в какой-то прекрасный момент, отлаживая некоторую странность в поведении авторизации, со мной и случилось то самое «психанул». Я увяз в коллбэках, и меня вконец достал неявный нейминг абстракций Passport, который был сделан, мягко говоря, совсем не для людей.

Какое-то время поискав альтернативы Passport’у, я понял, что ничего хорошего в обозримом пространстве нет. В голове пронеслась мысль, многим наверное уже набившая оскомину: «если хочешь сделать что-то хорошо, сделай это сам».

Тогда-то, засучив рукава, я сел и начал писать свой первый серьёзный проект с открытым исходным кодом, который и получил имя auzy, как вы могли уже догадаться.

Проект и его концепция

Насмотревшись и натерпевшись от старых подходов, я твёрдо решил, что у проекта будет современная кодовая база с поддержкой последней стабильной версии Node.js, на тот момент 8-й. Благо, у меня уже был неплохой опыт работы с промисами, async/await, классами и многими другими прелестями ES6+.

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

И ещё один важный момент, документация. Её нехватка или отсутствие примеров могут запросто свести на нет пользу от любого проекта, ведь если у пользователей не будет чёткого понимания, как применять библиотеку, никто не станет ей пользоваться. Я пообещал себе ни в коем случае не допускать такого в своём проекте.

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

Разработка

За все свои годы работы с вебом, мне не раз доводилось иметь дело с сессионной логикой. Несколько раз приходилось реализовывать её с нуля. Для меня в этой логике не было ничего особенного, в голове она выстраивалась как на ладони, а пережитый опыт лишь добавлял уверенности и подливал масло в огонь.

Вечерами около месяца я активно работал над проектом, и он наконец начал обретать желаемый вид. Мне удалось реализовать поддержку Restify, Connect, Express и koa.js, покрыть проект функциональными и юнит-тестами. Иными словами, минимальный результат был достигнут.

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

Подключение в проект

Несколько слов о технологическом стеке проекта, которому требовались сессии. Фреймворк Restify, база данных MongoDB, хранилище сессий Redis. Идентификатор сессии требовалось передавать в заголовке (к слову, auzy пока не поддерживает передачу сессий в куках). В данном случае express-session-header это форк, как раз позволяющий передавать сессию в заголовках.

Passport

Давайте взглянем, как выглядело раньше подключение Passport в проекте:

const passport = require('passport');
const session = require('express-session-header');
const RedisStore = require('connect-redis')(session);
const redisStore = new RedisStore({
    ttl: 60 * 60 * 24 * 30 * 6,
});
server.use(session({
    secret: config.session.cookie.secret,
    store: redisStore,
    resave: false,
    saveUninitialized: false,
    header: 'X-Session-Token',
}));
server.use(passport.initialize());
server.use(passport.session());
const LocalStrategy = require('passport-local').Strategy;
passport.use(new LocalStrategy({
        usernameField: 'user[email]',
        passwordField: 'user[password]',
    },
    function (email, password, done) {
        // логика поиска пользователя в БД и возврат через done
    },
));

passport.serializeUser(function (user, done) {
    return done(null, user.id);
});

passport.deserializeUser(function (id, done) {
    User.Model.findOne({_id: new ObjectId(id), status: User.statuses.ACTIVE}, done);
});

Громоздко, не правда ли? Что здесь у нас? require 4-х модулей, 3 миддлвары через use, логика serialize и deserialize. Ну а локальная стратегия (LocalStrategy) неподготовленному человеку вообще покажется лёгким безумством, это объект, который в свою очередь является миддлваром для Passport, у которого ещё и формат полей задан в виде user[email], хотя на деле это не обязательно urlencoded, это также может быть путём в объекте.

Кому как, а на мой взгляд всё это выглядит чрезмерно запутанным. Я тратил немало нервов, когда доходил до этих кусков кода, особенно когда нужно было что-то поменять. С auzy от этих ощущений не должно было остаться и следа.

auzy

Итак, когда я начал подключать auzy к своему домашнему проекту, это для меня стало глотком свежего воздуха:

const auzy = require('auzy');
const config = {
    session: {
        sessionName: 'X-Session-Token',
        ttl: 60 * 60 * 24 * 30 * 6 * 1000,
        alwaysSend: true,
        loadUser: sessionData => {
            // логика поиска пользователя в БД и возврат через промис
        },
    },
};
const environment = {
    framework: 'restify',
    storage: 'redis',
    transport: 'header',
};
server.use(auzy(config, environment));

Благодаря тому, что auzy знает о популярных фреймворках, подключение выглядит заметно проще, оно занимает примерно в 2 раза меньше строк, где выполняется один require и use всего 1-го миддлвара. И это всё при нулевых зависимостях (в будущем, возможно, добавится библиотека cookie, но пока ноль).

Что же с API? Если кратко, то почти всё задаётся через конфигурацию. Здесь стоит выделить основные сущности, которыми оперирует auzy:

• framework специфицирует, каким образом будет выполняться работа с объектами запросов/ответов, как будет складываться и удаляться из них пользователь.
• storage определяет хранилище данных для сессий.
• transport реализует способы передачи идентификаторов сессий, например, в заголовке.

Десериализация и локальная стратегия Passport заменены на функцию loadUser, а от сериализации и аутентификации осталась только аутентификация, которая выставляет в сессию данные настоящего пользователя. В данном случае под аутентификацией я конечно имею ввиду лишь последний этап фиксации успешности аутентификации.

Планы

Конечно, есть ещё много всего, что было бы неплохо сделать в проекте. Но тут как с ремонтом, его нельзя закончить, его можно только прекратить. И пока я переключился обратно на свой домашний проект, у auzy томится TODO-список. Надеюсь, в скором будущем у меня найдётся время продолжить разработку.

На этом я завершаю свое немалое повествование о том, как я двинулся в СПО. Спасибо всем, кто дочитал до этих строк.

Ссылки

1. Само собой, главный герой заметки auzy.
2. Если вам нужна особая гибкость, пока ещё имеет смысл взглянуть на Passport.

Для таких проверок и приходит на помощь CLI-среда REPL (read-eval-print-loop), которая по сути является неким инлайн-интерпретатором, в нём вы можете написать строку кода и тут же увидеть результат.

Node.js REPL

Чтобы запустить REPL Node.js, достаточно просто набрать в терминале:

node

В нём легко выполнять какие-то простые вещи и сразу видеть результат:

> [1, 2, 3].join(':')
'1:2:3'

REPL и библиотеки

Давайте представим, что мы попали в следующую ситуацию: нам понадобилось посмотреть, как именно ведёт себя функция библиотеки lodash keyBy. Мы наивно пробуем:

> _.keyBy([{ id: 1, name: 'Justin' }, { id: 2, name: 'Bob' }], 'id')
TypeError: Cannot read property 'keyBy' of undefined

Естественно, никакой магии нет, мы никак не обозначили, что собираемся использовать lodash в REPL, да и более того, lodash у нас не установлена глобально, и REPL просто не может её увидеть. Что ж, ставим:

yarn global add lodash
# или
npm i -g lodash

И пробуем запустить REPL, но в этот раз сделаем это несколько хитрее:

node -i -e "const _ = require('lodash')"

И видим Error: Cannot find module 'lodash'. Давайте пока отложим эту неприятность и посмотрим, какими ключами мы воспользовались:

• -e "const _ = require('lodash')" выполняет указанный код, в данном случае импортирует модуль lodash в константу _.
• -i форсирует интерактивный режим, нам это необходимо, так как предыдущий ключ -e подразумевает под собой только выполнение кода, без интерактивного режима.

С ключами разобрались, но почему же не видна библиотека, мы же поставили её глобально? Тут стоит проверить, а верно ли указана переменная окружения NODE_PATH. В моём случае она не была установлена вообще, и пришлось её добавить в конфиги шелла (в моём случае это был fish), указав в ней путь до глобальных модулей:

set -x NODE_PATH ~/.config/fnm/lib/node_modules

Эта переменная может задаваться по-разному, если у вас, например, bash или zsh, и в зависимости от того, пользуетесь ли вы nvm или fnm. Если вдруг у вас возникнут трудности на этом этапе, не стесняйтесь задавать вопросы, будем разбираться вместе!

Итак, пробуем снова:

node -i -e "const _ = require('lodash')"

И, наконец, попадаем в REPL без ошибок, с надеждой снова пробуем функцию из lodash:

> _.keyBy([{ id: 1, name: 'Justin' }, { id: 2, name: 'Bob' }], 'id')
{ '1': { id: 1, name: 'Justin' }, '2': { id: 2, name: 'Bob' } }

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

Также хотелось бы отметить, что это далеко не единственный и даже не самый простой способ использовать внешние библиотеки в REPL. Например, есть trymodule, который довольно просто позволяет открывать REPL с импортированными библиотеками. Но честно говоря, в моём случае я столкнулся с небольшими субъективным недостатками, поэтому пока остаюсь на нативном REPL.

Итак, подытожим, мы с вами научились из Node.js создавать свою песочницу для различных проб и экспериментов.

Ссылки

1. Документация к REPL-режиму Node.js
2. trymodule

В целом, заметка будет небольшой, я лишь рассмотрю несколько простых команд, которые позволят поднять сервер mongodb в docker и продолжить работу с ним.

Инициализация

Для инициализации запускаем контейнер из официального образа со следующими параметрами:

docker run -d -p 127.0.0.1:27017:27017 --name mongo-exp-project mongo

• -d выполнить детач от текущего терминала и вывести ID контейнера.
• -p публикует порт контейнера для хоста (это нужно, чтобы сервер mongodb, запущенный внутри контейнера, было видно извне, и к нему можно было подключиться, например, из Node.js).
• --name просто имя контейнера, чтобы было проще ориентироваться в последствии.

mongo — это образ, на основе которого будет запускаться контейнер. В данном случае это наиболее свежий официальный образ mongodb.

Запуск контейнера

Допустим, наш контейнер оказался остановлен. Это могло произойти, например, из-за банальной перезагрузки операционной системы.

Для начала, выясним ID нашего контейнера:

docker ps -a

CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS                          PORTS                        NAMES
a7bec3375bdc        mongo:latest        "docker-entrypoint..."   7 weeks ago         Exited (0) 3 seconds ago        127.0.0.1:27017->27017/tcp   mongo-exp-project

Ключ -a позволяет нам увидеть весь список контейнеров, в том числе и остановленных. Затем просто запускаем наш контейнер при помощи start, указав ID:

docker start a7bec3375bdc

Запуск команды внутри контейнера

Иногда бывает нужно что-то сделать в рамках контейнера, выполнить какую-то операцию или, к примеру, запустить оболочку mongodb. Это можно сделать при помощи команды exec.

docker exec -it a7bec3375bdc mongo

• -i интерактивный режим, оставляет STDIN открытым, таким образом, контейнер остаётся доступным на получение данных.
• -t выделяет псевдо-TTY (иными словами, некий инстанс текстового терминала).

Ключи -i и -t выглядят несколько непонятными, не находите? Вообще, если говорить человеческим языком, оба эти ключа позволяют обеспечить интерактивность оболочки mongo. То есть, мы можем писать в ней команды, а она, соответственно, может отдавать нам результат.

Когда -i и -t будут лишними? Например, когда нам не нужно «общаться» с командой докера: docker exec a7bec3375bdc ls /var/log В данном случае нам интересен только ответ в виде списка файлов, мы не планируем что-то делать интерактивно.

Совершенно аналогично можно запустить оболочку bash внутри контейнера и что-то в нём поделать:

docker exec -it a7bec3375bdc bash

Вроде бы самое полезное я теперь упомянул. Полагаю, этих базовых команд будет достаточно для того, чтобы пользоваться сервером mongodb. На этом буду завершать свою заметку. Буду рад, если она поможет вам начать использовать docker.

Ссылки

1. Официальная документация Docker
2. Сайт mongodb

Итак, не буду долго томить, рецепт довольно прост (ну, если учесть, что у вас уже есть под руками NPM).

Сначала ставим себе в глобальные зависимости пакет mime:

npm i -g mime

Затем для ваших любимых шеллов добавляем себе функции.

fish

Просто вставляем это в файл ~/.config/fish/functions/base64urldata.fish:

function base64urldata
  set filename $argv[1]
  echo "data:"(mime $filename)";base64,"(cat $filename | openssl enc -base64 | tr -d '\n')
end

zsh/bash

В конец ~/.zshrc или в конец ~/.bashrc, соответственно:

base64urldata() {
    FILENAME=$1
    echo "data:$(mime $FILENAME);base64,$(cat $FILENAME | openssl enc -base64 | tr -d '\n')"
}

Пользоваться всем этим добром везде одинаково просто:

base64urldata ~/path/to/file.svg

Собственно, на этом всё, гладкой вам вёрстки!

Ссылки

1. Если ещё не приходилось, обязательно уделите время знакомству с SVGO

Бегло заглянув на сайт этого замечательного проекта с бесплатными сертификатами, я отыскал нужный себе раздел и примерно понял, что нужно делать. Год развития проекта дал о себе знать, теперь существует прокачанная утилита, распространяемая через deb-пакет. Ставим её.

sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install letsencrypt

Да, приходится подключать отдельный PPA, так как в Ubuntu 16.04 (которая у меня) этот пакет довольно старый, и в нём нет поддержки ключа --post-hook, который нам понадобится ниже.

Судя по всему, написано там всё на питоне. Итак, поставив certbot, я сделал для проверки успешности своих намерений dry-run запуск (так называемый запуск вхолостую, который по факту ничего не делает, а только показывает отчёт), как это предлагалось в документации certbot.

sudo letsencrypt renew --dry-run --agree-tos

Processing /etc/letsencrypt/renewal/spaceismine.org.conf
** DRY RUN: simulating 'letsencrypt renew' close to cert expiry
**          (The test certificates below have not been saved.)

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/spaceismine.org/fullchain.pem (success)
** DRY RUN: simulating 'letsencrypt renew' close to cert expiry
**          (The test certificates above have not been saved.)

Success-success, успех-успех! Ну, дальше можно было уже запустить и полноценное обновление сертификата.

sudo letsencrypt renew

Processing /etc/letsencrypt/renewal/spaceismine.org.conf
new certificate deployed without reload, fullchain is /etc/letsencrypt/live/spaceismine.org/fullchain.pem

Congratulations, all renewals succeeded. The following certs have been renewed:
  /etc/letsencrypt/live/spaceismine.org/fullchain.pem (success)

Замечательно, он говорит, что всё нам обновил. Делаем релоад нашему nginx.

sudo service nginx reload

И вот всё, сертификат обновлён, всё замечательно. Но, не буду же я раз в 3 месяца заходить обновлять его руками, поэтому я поискал информацию, как лучше всего это прикрутить на cron. Оказывается, ничего особо сложного с этим тоже не было.

sudo crontab -e

и добавляем там

42 0,12 * * * letsencrypt renew --post-hook "service nginx reload"

“Зачем делать два раза в день?” спросите вы. Да, это довольно часто, но я столкнулся с мнениями, что в этом нет ничего такого, так как certbot ничего не делает, если сертификат по факту пока обновлять не требуется. Момент необходимости обновления сертификата наступает за 30 дней до его истечения.

Убеждаемся напоследок, что команда cron работает. Многие годы работы с cron научили меня это делать в обязательном порядке.

sudo letsencrypt renew --post-hook "service nginx reload"

Saving debug log to /var/log/letsencrypt/letsencrypt.log

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/spaceismine.org.conf
-------------------------------------------------------------------------------
Cert not yet due for renewal

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/spaceismine.org/fullchain.pem (skipped)
No renewals were attempted.
No hooks were run.

Итак, похоже всё хорошо и всё работает. На этом завершаю свою заметку про автоматическое обновление сертификатов Let’s Ecnrypt.

Ссылки

1. Моя прошлогодняя статья про первоначальную настройку Let’s Encrypt
2. Сайт certbot
3. Сайт проекта Let’s Encrypt

Да, я и правда давно сюда не заглядывал, а меж тем, шёл уже 3-й месяц 2017-го. Просто тут у меня появилась причина поведать возможно что-то интересное. У меня наконец-то дошли руки до моей затеи открыть исходники телеграм-бота Upfox. Он предназначен для людей, вроде меня, у которых шило в ж которым не терпится узнавать о свежих версиях программ как можно быстрее. Нет, не как в RSS-лентах, а прямо-вот-сейчас-сразу-же! Поэтому и пришла в голову такая мысль: “А было бы круто слать себе нотификации, как только появляется что-то новенькое”. Так и пришла идея написать бота, принцип работы которого крайне прост: каждые N минут он стучится на целевые страницы (на которых можно найти информацию о версии), регуляркой вытаскивает самую свежую версию и, если она обновилась, уведомляет своих пользователей об этом.

Это всё просто и банально, само собой, но основной интерес, как мне кажется, представляет простота добавления новых программ на отслеживание. Достаточно небольшого конфига, описывающего мета-данные и регулярное выражение для поиска версии. На текущий момент список приложений невелик, но, если у проекта появятся пользователи, расти этому перечню будет довольно просто. Хотя конечно, с большим количеством пользователей появятся и другие проблемы, но о них пока рано.

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

Ссылки

1. Ссылка на бота
2. Ссылка на GitHub-репозиторий

sudo add-apt-repository ppa:nginx/development

В ppa:nginx/stable всё ещё версия 1.8.0. Но, как я всегда говорю, жизнь меня ничему не учит мои пет-проекты вовсе никакие не супер-важные, поэтому я решил обновиться. Почему нет. Итак, поддержка HTTP/2 у меня была в кармане.

Немного проглядев информацию про сам протокол, стало понятно, что он может работать только в шифрованном режиме. Получать через пень-колоду бесплатный долгосрочный сертификат через китайцев, как я это делал прошлой весной, вовсе не хотелось. Хотелось попробовать что-то новое. И тут очень кстати мне вспомнился проект Let’s Encrypt.

Let’s Encrypt и бесплатный HTTPS всем

Этот амбициозный проект был начат двумя сотрудниками Mozilla, но теперь он уже существенно вырос и обзавёлся поддержкой многих гигантов (таких как Akamai, Cisco, Facebook). Центр сертификации Let’s Encrypt вошёл в стадию открытой беты в начале декабря 2015 года и с тех пор раздаёт бесплатные сертификаты. Сертификаты выдаются всего на 3 месяца, но процесс их получения заключается в запуске всего лишь одного скрипта с указанием e-mail’а и доменов. Мне сходу понравилась эта простота после китайцев, да и бесплатность была тоже очень кстати.

Этот скрипт, который вам придётся поставить на сервер, проверяет, что вы являетесь владельцем домена. Это возможно в нескольких режимах:

• apache – его я не пробовал, у меня же nginx, но, поговаривают, этот режим весь такой красивый и полностью автоматизированный
• standalone – через запуск встроенного веб-сервера на 80-м порту, что мне тоже не подошло, у меня же nginx на нём висит и работает в любой момент времени
• webroot – выбрал именно этот вариант, проверка осуществляется созданием специального файла в корневой директории сайта, которую вы укажете в параметре --webroot

Я склонировал репозиторий себе:

git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt

Разобравшись с параметрами, у меня в итоге получилась примерно такая команда для получения сертификата:

./letsencrypt-auto certonly --webroot -w /var/www/spaceismine/html/ --email xlz@ya.ru -d spaceismine.org -d www.spaceismine.org

Вероятно, понадобится sudo-пароль, потому что скрипт будет записывать сертификаты в /etc. Но у меня sudo уже торчал в сессии, не помню, чтобы мне приходилось вводить пароль. После того, как команда успешно отработала, в директории /etc/letsencrypt/live/spaceismine.org аккуратным образом появились симлинки на ключ, сертификат, цепочки.

nginx ~ HTTP/2 ~ HTTPS

Далее нужно было настроить nginx. Прикладываю свой конфиг:

server {
    listen 80;
    server_name spaceismine.org www.spaceismine.org;
    rewrite ^(.*) https://spaceismine.org$1 permanent;
}

server {
    listen 443 ssl http2;

    server_name spaceismine.org;
    root /var/www/spaceismine/html;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/spaceismine.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/spaceismine.org/privkey.pem;
    add_header Strict-Transport-Security 'max-age=604800';
}

Суть первых строк в том, что мы HTTP будем всегда кидать на HTTPS. Ну и для верности добавим хидер add_header Strict-Transport-Security 'max-age=604800';, чтобы браузерам было попроще и попонятнее перекидывать пользователя на нужный вариант протокола. Как видите, конфиг вышел на удивление простой, что не может не радовать.

Подвохи и рейтинг A на ssllabs

Затем у меня были некоторые проблемы с тем, что сайт открывался только в Safari. Я долго пытался понять, с чем это может быть связано. Но в итоге вспомнил, что слабые алгоритмы в последнее время активно выпиливаются браузерами, поэтому нашёл способ, как можно было настроить более “качественный” HTTPS в nginx.

Прикладываю конфиг секции http главного конфига nginx.conf, который позволил добиться мне A на тесте ssllabs:

ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_stapling on;
ssl_dhparam ssl/dhparam.pem;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

Здесь один важный момент ssl_dhparam ssl/dhparam.pem;. Да, пришлось сгенерить свой dhparam на 2048 бит:

openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

Учтите, что директория /etc/nginx/ssl должна существовать, иначе openssl ничего не сделает.

Далее service nginx restart и всё стало хорошо во всех браузерах, а в ssllabs начала красоваться A:

Что ж, на этом всё, таков был мой опыт настройки HTTP/2 на своём проекте. Так что если вам это интересно, конечно берите и пробуйте, всё можно использовать уже сейчас.

Ссылки

1. Хорошее пояснение/обзор/бенчмарк на тему HTTP/2 на хабре
2. Проект Let’s Encrypt на github
3. Неплохая статья о конфигурировании HTTPS на сайте nginx

Когда такое бывает полезно, спросите вы? Например, когда вы коннектитесь к удаленной машине по SSH, с мультиплексором можно вполне так эмулировать многозадачность, утилизируя только одно SSH-соединение.

Но, это еще не все. tmux внутри каждого своего терминала полностью помнит состояние. И если у вас вдруг произошел разрыв с ноября прошлого года, то с tmux вам не придется подключаться снова к серверу в 10 вкладках и в 10 вкладках снова запускать прибитые процессы, вроде mc, less, какого-нибудь консольного клиента mongo… да что угодно. При разрыве все так и останется крутиться в tmux.

Особо матерые батьки вспомнят тут screen, да, была такая штука. Но tmux посовременнее и обладает более богатой функциональностью, поэтому лучше трогать будем его.

Ставим-пробуем

Давайте сходим на свой любимый сервер и поставим там tmux:

ssh detr.us
sudo apt-get install tmux

Далее для тренировки давайте запустим tmux, сделаем в нем что-то, просимулируем разрыв, перезайдем на сервер и подцепимся к tmux обратно. Начнем:

tmux

Мы видим нечто, что называется tmux. Давайте запустим что-то бесполезное.

watch date

Итак, мы смотрим время (бред какой). Теперь закроем терминал, будто у нас все пропало, открываем новый терминал и делаем следующее:

ssh detr.us
tmux attach

И вот, мы подцепились к своей существующей tmux-сессии и снова наблюдаем время… То есть буквально полностью восстановили свое рабочее окружение, бесцеремонно закрытое нами же выше.

В общем, самым простым вещам мы научились. Добавлю лишь, что детач от текущего tmux можно еще делать комбинацией Ctrl + b, d. Дальше – больше.

Оооо, iTerm2, великий!

Да, iTerm2 в этой заметке неспроста. Дело в том, что iTerm2 умеет просто ну очень круто интегрироваться с tmux. Чем же это поможет? Тем, что окна (в терминологии мультиплексора) tmux можно отображать как вкладки в iTerm2. Помимо этого у вас пропадают проблемы со скроллом и появляется очень легкая возможность создавать новые окна tmux простым нажатием Cmd + t (то есть как вкладки).

Предварительно я бы рекомендовал настроить iTerm2 следующим образом (обратите внимание на раздел tmux справа внизу):

Итак, пробуем интеграцию iTerm2 с tmux командой:

tmux -CC attach

И вот мы снова видим нашу пресловутую дату. Нажмем Cmd + t и откроем какой-нибудь мануал в другом tmux-окне.

man find

Повторяем симуляцию разрыва: безжалостно закрываем iTerm2. Снова идем на сервер и коннектимся к существующей сессии tmux:

ssh detr.us
tmux -CC attach

Символ стрелочки, расположенный на вкладках iTerm2 говорит нам о том, что эти вкладки – окна tmux.

И видим, что наша рабочая сессия на удаленном сервере полностью восстановлена. По-моему, это просто прекрасно!

tmux cheat sheet и горячие клавиши

На случай, если у вас все же нет под рукой iTerm2 и вам приходится довольствоваться обычным терминалом, прикладываю шпаргалку для tmux

Сессии

Окна

Также хотел бы отметить, что в tmux имеются еще и панели, но, насколько я понял, у них нет интеграции с iTerm2. Да и управлять ими через горячие клавиши – сущий ад. Поэтому рассказ про панели я опущу.

На этом, наверное, все. Дай бог вам ни единого разрыва!

Ссылки

1. Сайт tmux
2. Сайт iTerm2
3. Страница о состоянии интеграции iTerm с tmux

Стоит наверное начать с небольшого введения, что же такое BaaS и зачем вот это вота все. BaaS (Backend as a Service, как гласит Википедия) отчасти можно назвать очередным баззвордом, но тем не менее небольшая ниша у таких сервисов все же есть. Довольно тяжело сходу въехать, как можно написать полноценное мобильное приложение с аккаунтами, регистрацией, профилями и прочими плюшками, не пользуясь при этом услугами разработчиков серверных приложений (будь то PHP, Python, Ruby, Node.js и так далее и тому подобное). На самом деле BaaS именно для этого и был придуман. То есть, имея свое мобильное приложение, вы можете управлять различными данными с клиентской стороны, все производится через API и (как правило) готовые SDK.

Одним из наиболее популярных (и к тому же, допускающим неплохие лимиты на API-запросы при бесплатном аккаунте) BaaS является Parse.com. Именно об интеграции с ним я буду сегодня говорить.

Динамика в статике, опять?!

Да, мне кажется я о подобном уже говорил. Что-то подобное вы уже слышали, но тем не менее, факт остается фактом. Добавить динамичности статическому контенту можно, благодаря именно BaaS. Что же тут хорошего, почему бы не взять в таком случае нормальный язык и не написать на нем адекватный бэкенд, спросите вы. Ответ у меня будет довольно простой: скорость работы статического сайта даже на сервере за $5 в месяц (в том же DigitalOcean) будет очень и очень хорошей. Иными словами, это все обусловлено развитием облачных сервисов, предоставляющих VPS буквально за копейки. В итоге BaaS дает нам возможность иметь неплохой информационный сайт с минимальными денежными затратами на содержание. По-моему, это довольно круто и стоит того, чтобы повозиться и разобраться с этим.

Особо пытливые умы в этом месте уже смекнут, что если в этом подходе все задачи ложатся на плечи клиентской стороны, то это будет не так уж и безопасно. Ну то есть, никто не помешает злоумышленнику стащить у вас API-ключ и подпортить вам жизнь. Это вполне реально, если данные не привязаны к аккаунту, будь то количество просмотров или лайки. Против такого Parse.com может противопоставить хранимые на их сервере функции (хотя это уже попахивает тем же полноценным бэкендом), испортить данные с помощью которых будет несколько сложнее. В общем, все это не супер-надежно при некоторых сценариях взаимодействия, это правда. И если вам нужно действительно что-то серьезное, BaaS я бы вам рекомендовать не стал. По крайней мере тот, который существует на нынешнем этапе развития технологий.

Пробуем, интегрируемся, ловим грабли

В роли подопытного кролика я выбрал проект Space is Mine, который не так давно перешел на статику. В качестве динамики я реализовал там счетчик просмотров на страницах статей. Вообще, с Parse.com все оказалось довольно просто и сложно одновременно. Я добавил себе инициализационную строчку в проект, написал сохранение объекта и встрял. Дело в том, что само собой мне хотелось бы иметь upsert, как это сделано, например, в MongoDB, с атомарным инкрементом. Проблема была в том, что в Parse.com не предусмотрена поддержка upsert. Это нонсенс! Бэкенд-сервис, который по сути-то должен экономить количество запросов, насколько это возможно (так как расположен довольно далеко от клиента), не позволяет делать upsert. Ну что ж, ладно, терпим.

На самом деле, в этот момент я задумался, поглядел вокруг повнимательнее, но так понял, что Parse.com – пожалуй, лучшее, что можно найти в этом сегменте (вспоминаем особую лояльность к бесплатным аккаунтам). Делать было нечего, пришлось немного разветвить и написать немного больше кода:

var ArticleObject = Parse.Object.extend("Article");
var path = '{{ this.path }}';
var query = new Parse.Query(ArticleObject);
query.equalTo('code', path).first().then(function(object) {
    if (!object) {
        var articleObject = new ArticleObject();
        articleObject.save({code: path, viewsAmount: 1});
    } else {
        object.increment('viewsAmount', 1);
        object.save();
    }
});

Здесь path – полный путь до страницы, то есть что-то вроде своеобразного id. Тем не менее, согласитесь, кода было добавлено совсем не много, и это здорово!

На деле браузеру потребуется сделать два запроса, один на получение записи, второй – на добавление/обновление. Ах да, передать свой собственный id в Parse.com для сохранения новой записи нельзя. Поэтому даже такой хак не прошел. Тем не менее, как показала практика, эти два запроса выполняются довольно быстро и на клиентской стороне все выглядит довольно таки неплохо.

Итак, что мы имеем. Сайт, способный выдавать порядка 120 rps на железе за $10, подсчет просмотров и вообще все очень вкусно. При этом не стоит забывать, что подсчет просмотров – это самый банальный сценарий применения, само собой, можно сделать что-то и посложнее.

Ссылки

Пожалуй, доброй традицией будет приложить несколько ссылок для читателей, которые хотели бы посмотреть на эту тему поподробнее.

1. Быстрый старт на Parse.com
2. Подробная JavaScript API документация Parse.com
3. Довольно свежая статья о выборе правильного BaaS

WoSign бесплатный сертификат на 3 года

Началось все с того, что я узнал про возможность получения бесплатного сертификата на WoSign на 3 года. Меня это заинтересовало, потому что раньше я слышал только про платные и достаточно дорогие сертификаты. Пришлось столкнуться с трудностями в лице китайского языка, но за халяву можно было и потерпеть, правда? Какое-то время поковырявшись, я смог оставить заявку на получение. На следующий день мне на почту пришло письмо, что я могу его забирать. Пройдя по ссылке в письме, мне предоставили возможность загрузить сертификат в запароленном архиве (пароль вы вводите в момент создания заявки). В общем, все отлично сертификат был на руках.

nginx и небольшие подвохи

Естественно нужно было загрузить сертификаты на сервер и что-то с ними сделать. Перечитав немного информации в Интернете, действия сложными не были. Прикладываю вырезки конфигурации nginx-сервера:

http {
    ...
    ##
    # SSL Settings
    ##
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_stapling on;
    resolver 8.8.8.8 8.8.4.4;
    ...
    server {
        listen 80;
        listen 443 ssl;
        server_name audiocoding.ru;
        ssl_certificate path/to/cretificate.crt;
        ssl_certificate_key path/to/key.key;

        # Этот заголовок заставляет браузер использовать HTTPS принудительно в течении недели,
        # но чтобы это сработало, пользователь хоть раз должен зайти на HTTPS-версию сайта.
        add_header Strict-Transport-Security 'max-age=604800';
        ...
    }
    ...
}

Собственно, все казалось бы хорошо, configtest показывает [ OK ], сервер рестартится успешно, но сайт не открывается. Я уже было начал ломать голову, как вдруг какой-то ответ на stackoverflow.com заставил меня сделать фейспалм. Дело в том, что в какие-то времена фанатичности я закрыл все порты в iptables, кроме 80 и 22. Ну так, недолго думая, открыл еще и 443. Все заработало, сертификат всеми браузерами воспринимается как доверенный. Что ж, поживем – увидим. Быть может, позднее будут какие-то проблемы с Chrome. Китайский сертификат и Google все таки вещи слабосовместимые.

add_header я все же закомментарил после этих размышлений…

Производительность HTTP против HTTPS

Ну конечно же, мне не могло не прийти в голову, что наверное HTTPS теперь будет медленнее HTTP. Решил прогнать свою главную страницу через siege, команду выбрал достаточно простую:

siege -b -t10s -c50 http://audiocoding.ru/

Для HTTPS аналогично.

Итак, тесты для HTTP показали:

Transactions:                823 hits
Availability:             100.00 %
Elapsed time:               9.57 secs
Data transferred:          15.18 MB
Response time:              0.56 secs
Transaction rate:          86.00 trans/sec
Throughput:                 1.59 MB/sec
Concurrency:               48.56
Successful transactions:     823
Failed transactions:           0
Longest transaction:        1.01
Shortest transaction:       0.17

Для HTTPS:

Transactions:                622 hits
Availability:             100.00 %
Elapsed time:               9.68 secs
Data transferred:          11.47 MB
Response time:              0.75 secs
Transaction rate:          64.26 trans/sec
Throughput:                 1.19 MB/sec
Concurrency:               48.24
Successful transactions:     622
Failed transactions:           0
Longest transaction:        1.26
Shortest transaction:       0.29

Таким образом, делаем вывод, что HTTPS замедлил работу сайта на 25%. Да, это на самом деле много в относительном значении. В абсолюнтых показателях, взяв кратчайшее время, 170 мс против 290 мс – разница вроде бы и не велика, но все равно ощутима. В общем-то отчасти еще и поэтому, поддержку HTTPS я оставлю опциональной.

Ах да, чуть не забыл, тесты выполнялись на виртуальной машине за $10 в облаке DigitalOcean (1GB RAM, 1 ядро CPU, 30GB SSD). Географически siege запускался в Москве, сервер при этом находился в Амстердаме.

Ссылки

Как и обещал, прикладываю несколько тематических ссылок, чтобы вам было проще разобраться с материалом:

1. Официальная страница по настройке HTTPS в nginx
2. Неплохая статья на хабре по той же теме
3. Статья на хабре о том, как осилить WoSign

Чуть философии

Вряд ли я кого-то удивлю, что нынче в тренде всякие статические движки для блогов. А где блоги, там и простейшие сайты. Вообще, философски, я считаю, что все имеет спиралевидное развитие. И зачастую так и происходит, например, давайте обратимся к базам данных. Как все было раньше? Все писали в файлики, и всем было хорошо. Что произошло дальше? Дальше люди захотели работать с файлами немного умнее, чем просто с массивами данных. Появились реляционные базы данных. Да, сложные, да, мощные. Но затем реалии современного мира продиктовали свои условия. Объемы данных возросли настолько, что пришлось экономить на логичности представления данных и мы вновь вернулись к более простым структурам, вроде документоориентированных баз данных. Да, все улучшилось, все стало умнее, но просто замкнулся один из витков спирали.

Вебсайты

Что же происходило с вебом все это время? Вспомните, начиналось все с простых HTML-страниц, которые практически ничего не умели, которые были просто файлы, отдававшиеся серверами по HTTP-протоколу. Потом люди сказали “это не круто”. Ну нет, не совсем так конечно. Они сказали, что HTML почти ничего не умеет, а хотелось бы уметь хранить какие-то данные о пользователе, чтобы он мог логиниться и у него был свой аккаунт. Так появились динамические языки вроде PHP, заточенные под эти цели.

И вроде бы все шло хорошо, мощности компьютеров росли, и сайты на PHP начинали работать все лучше и лучше. Тем не менее, все это оставалось уделом избранных, которым не жалко было платить по 1000 и более рублей за сервер в месяц. Параллельно развивались и технологии, в частности виртуализация. С этим росло предложение приватных виртуальных серверов со стороны всяких сервисов, которые со временем буквально за копейки начали предлагать услуги по предоставлению слабых, но тем не менее полностью выделенных серверов (это не те сервера, когда вы сидите в разных папочках с другими людьми на одной ОС, про этот ужас я даже упоминать не хочу). Так появилось желание платить поменьше и при этом иметь свои сайты, которые быстро открываются. PHP здесь и прочие языки плохо подходили, так как требовали гораздо больше ресурсов, чем просто отдача HTML-файликов. В этот момент и начали активно развиваться движки для генерации статического контента (именно таким и сгенерирован этот сайт). Благодаря современным языкам и технологиям, внезапно стало удобно генерировать статику и раздавать ее с невероятной скоростью на слабых машинах.

Audiocoding.ru

Думаю, уже примерно понятно, что сайт audiocoding.ru за свою вот уже почти 10-летнюю историю прошел примерно такой путь, как и было рассказано выше. Да, кстати, летом будет юбилей, и мы обязательно с вами это отметим. Теперь audiocoding.ru представляет собой статически сгенерированные HTML-страницы. Но, как показала практика, этого оказалось недостаточно. Например, раньше у меня был поиск по сайту и довольно богатый файловый архив, который хотелось бы представить в новом представлении, более удобном, более быстром. Что же было решено сделать в этом месте? Это было с одной стороны странное и неожиданное решение. Я предпочел оставить статику, добавив при этом динамику на стороне браузера. Иными словами, весь поиск выполняется без участия серверной стороны, на браузере. Возможным это стало благодаря развитию JavaScript в браузерах. Сказать, что за все это время он стал быстрым – ничего не сказать. Он стал просто молниеносным! Можете сами попробовать, поиск выполняется быстро даже на мобильных устройствах. И да, вот так все внезапно преображается. То, что раньше казалось полным бредом, преобретает вполне адекватные очертания.

Заключение

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

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

Скажите, вы любите слушать музыку? Я вот очень, я слушаю ее весьма часто, если не сказать постоянно. В разные моменты своего жизненного пути я пользовался разными сервисами. Пока что я остановился на Яндекс.Музыке и довольно часто мне бывает нужно поставить ее на паузу или переключиться на следующий трек. На клавиатуре красуются клавиши “Previous”, “Play/Pause” и “Next”, но использовать мы не их можем. Ах, беда, печаль, огорчение. Так, куда это меня понесло… Давайте попорядку.

Alfred

Как правило, современные сервисы не имеют нативных клиентов и плохо дружат с системными фишками. Все они работают в браузерах, и это немного усложняет задачу. Сразу обмолвлюсь, что для таких целей я использую браузер Safari, он является пожалуй наиболее быстрым и ресурсоэкономным браузером для системы OS X. Собственно, именно в нем мы и будем учиться эмулировать нажатия на элементы интерфейса, отвечающие за остановку воспроизведения и переключение треков. Итак, как можно выполнять что-то “свое” в браузере, да при этом повесив это “свое” на горячие клавиши? Тут сразу на ум приходит прекрасный инструмент автоматизации Alfred, в некотором роде являющийся стандартом де факто для такого рода задач.

Какое-то время назад я написал для Alfred свой workflow, который позволяет взаимодействовать с Яндекс.Музыкой в браузере Safari. Я не буду скромничать и порекомендую вам воспользоваться именно им: https://github.com/alexey-detr/yandex-music-hotkeys.

Установив его в свой Alfred (должен сразу предупредить, что для этого нужна именно платная версия) и, попробовав навесить горячие клавиши на основные действия, вы столкнетесь с небольшой неприятностью. Дело в том, что Alfred не умеет вешать медиа-клавиши на действия.

Здравой идеей было бы предположить, что медиа-клавиши являются некими системными клавишами и для их “отлова” у Alfred просто не хватает привелегий. Ну не очень верится, что разработчик Alfred за столь долгий срок разработки ни разу не догадался, что медиа-клавиши тоже можно было бы навешивать на действия.

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

Shift + Control + Alt + Command + F7 => Previous track
Shift + Control + Alt + Command + F8 => Play/pause
Shift + Control + Alt + Command + F9 => Next track

Итак, ладно, у нас есть теперь такие извращенные комбинации на действия в Alfred. Но хотелось бы как-то изловить именно медиа-клавиши. Далее повествование переключается на довольно низкоуровневый инструмент, который умеет переназначать клавиши и называется он…

Karabiner

Итак, Karabiner можно скачать и установить с официального сайта https://pqrs.org/osx/karabiner/. Не буду вас долго мучать и объяснять его конфигурирование, тем более вы и сами можете почитать мануалы к нему. Сразу открою все карты:

{% highlight xml %} <?xml version=”1.0”?>

‘Media Prev,Play,Pause’ to ‘All modifiers + F7,F8,F9’ private.modify_media KeyToKey ConsumerKeyCode::MUSIC_PREV, KeyCode::F7, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L | ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L KeyToKey ConsumerKeyCode::MUSIC_PLAY, KeyCode::F8, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L | ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L KeyToKey ConsumerKeyCode::MUSIC_NEXT, KeyCode::F9, ModifierFlag::CONTROL_L | ModifierFlag::SHIFT_L | ModifierFlag::OPTION_L | ModifierFlag::COMMAND_L {% endhighlight %}

Что мы здесь можем видеть? А здесь как раз и есть заветное переназначение медиа-клавиш на комбинации, которые мы навесили в Alfred на действия.

Собственно, вы можете включить это у себя, скопировав узел <item> в свой файл private.xml. Последний вы можете обнаружить в настройках во вкладке Misc & Uninstall в пункте Custom setting. После этого важно будет зайти на вкладку Change Key и нажать Reload XML, затем у вас в списке remapping появится пункт 'Media Prev,Play,Pause' to 'All modifiers + F7,F8,F9', смело ставим напротив него галочку.

Что же дальше?

А вы знаете, это все. Теперь ваши медиа-клавиши будут эмулировать те, с которыми может работать Alfred, а он в свою очередь уже будет выполнять действия в Safari, таким вот немного костыльным образом можно заставить работать медиа-клавиши в Яндекс.Музыке.

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

В последнее время я периодически разбираюсь с Ansible, и руки дошли до написания модуля для процессного менеджера PM2. Нужны были максимально мягкие старт- и стоп-действия для рабочего node.js приложения, реализующего HTTP API. Я решил отслеживать отзывчивость API с помощью довольно популярной библиотеки для Python requests. Все казалось бы замечательно, но при тестировании модуля у меня постоянно вылетала эта ошибка:

Traceback (most recent call last):
  File "/Users/alexey_detr/.ansible_module_generated", line 4, in <module>
    import requests
ImportError: No module named requests

Несмотря на все это, пакет requests у меня был установлен:

$ pip install requests
Requirement already satisfied (use --upgrade to upgrade): requests in /usr/local/lib/python2.7/site-packages

Причина крылась в следующем: мой .py файл Ansible-модуля содержал в первой строке путь до интерпретатора #!/usr/bin/python (стандартный Python в поставке OS X)

$ /usr/bin/python -V
Python 2.7.6

А pip в свою очередь ставил модули для интерпретатора из #!/usr/local/bin/python (это уже brew-версия)

$ /usr/local/bin/python -V
Python 2.7.9

Таким образом понадобилось всего лишь поменять интерпретатор в .py файле на тот, что был установлен с brew и все стало хорошо. Мораль: быть более внимательным.

Заметка будет о контейнеризации и о том, как начать с ней работать на OS X.

Начну сначала. Итак, что-то дернуло меня попробовать Haskell, но, прежде чем его пробовать, я подумал, что наверное плохо будет захламлять систему всякими платформами, компиляторами и прочим. Тут, возможно, я не прав, и ничего там не захламляется, но тем не менее, появилось желание начать свои эксперименты именно в контейнере.

Установка Docker

Так как я люблю brew, устанавливал я через него.

brew install docker
brew install boot2docker

Вообще, сначала я не сразу понял как работает Docker у себя в потрохах, поэтому осознание, что нужен еще и boot2docker пришло далеко не сразу.

В двух словах, Docker – это тоже виртуализация, но контейнерная. Она легче, чем традиционные VM (гипервизоры), в которых эмулируется все, от процессора до памяти.

Имеем следующее, boot2docker – это виртуальная машина, под которой работают контейнеры, а docker – это клиент для нее.

Инициализируем и запускаем boot2docker:

boot2docker init
boot2docker up
$(boot2docker shellinit)

В последней строке boot2docker установит переменные окружения, необходимые для работы docker. В принципе, можно вполне подсмотреть эти переменные (с префиксом DOCKER_) командой env и добавить их в какой-нибудь .zshrc или в .bashrc, чтобы не запускать $(boot2docker shellinit) для каждой открытой оболочки. У меня в .zshrc эти строки выглядят так:

export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/alexey_detr/.boot2docker/certs/boot2docker-vm
export DOCKER_TLS_VERIFY=1

Небольшая справка: контейнерами называются непосредственно запущенные инстансы. А образами – отправная точная для старта контейнера.

Запускаем и пользуемся Ubuntu

Чтобы таки пощупать что-то в контейнере, давайте возьмем Ubuntu. Это официальный готовый образ с Ubuntu. Чтобы его установить и запустить, делаем следующее

docker run -it ubuntu

Тут придется немного подождать, когда контейнер скачается и будет готов к использованию. Когда процедура завершится, вы попадете в терминал докеризированной системы, там можно выполнить например apt-get update && apt-get install mc.

Тут нужно иметь ввиду, что состояние контейнера само по себе не сохранится. Как только вы выйдете из него командой exit, его изменения потеряются. Чтобы сохранить изменение контейнера, нужно сделать следующее. Для начала смотрим список текущих запущенных контейнеров командой

docker ps

Находим наш контейнер, смотрим его NAME и выполняем следующую команду:

docker commit <name>

Таким образом у нас сохранится новый готовый образ Ubuntu с mc для запуска под Docker в любом окружении. Далее этот образ можно довольно просто поднимать с сохраненной отметки, достаточно открыть список образов

docker images

найти в нем необходимый образ и воспользоваться например IMAGE ID (намеренно не стал рассказывать о repository или tag, чтобы сократить объем заметки) для запуска

docker run -it 01dbf62fda7b

В этом случае вы уже обнаружите установленный mc.

Рассматривать то, как переносить образы и вдаваться в другие детали, я в этой заметке не планировал, поэтому на этом закончу. В конце-то концов основной целью было опробовать Haskell.

Создание новой БД (в данном случае amarok) с кодировкой UTF-8, создание нового пользователя и выдача ему новых прав на базу данных делается всего в 4 команды:

CREATE DATABASE amarokdb CHARACTER SET utf8 COLLATE utf8_unicode_ci;
GRANT USAGE ON *.* TO amarokuser@localhost IDENTIFIED BY 'amarokpasswd';
GRANT ALL PRIVILEGES ON amarokdb.* TO amarokuser@localhost;
FLUSH PRIVILEGES;

Надеюсь, что благодаря этой заметке у вас не возникнет больше проблем с развертыванием новых проектов из консоли. Приятного кодинга!

В этом году я освоил следующие программные / серверные / девелоперские вещи: PhpStorm, Membase, MongoDB, Gearman, nginx, реализовал свой первый RESTful API, начал использовать различные веб-сервисы Amazon (чудные облачные технологии, должен признаться), попробовал разработку под Android… Что ж, перечислять можно долго, но это уже весьма малозначимые вещи.

Что же случилось с миром веба в 2011 году? Постараюсь бегло взглянуть на события уходящего года.

Вспоминается начало 2011. Не знаю, кто как, но я почему-то ждал тогда IE9. Надежда умирает последней? Да, оказалось так. Да, он стал лучше, да, он стал чертовски быстрым, но некоторые проблемы как были, так и остались. Ныне ходят слухи, да и не только слухи про IE10. Любой желающий уже может взглянуть на превью версию. Но как-то верится в него с трудом, если честно.

Mozilla перевела свои продукты Firefox и Thunderbird на крайне короткие итерации разработки (как я понял, чуть больше месяца), последовав примеру Google. Теперь как у Firefox, так и у Thunderbird версии обновляются синхронно. К тому же Firefox теперь обновляется довольно тихо и обыватель этого даже и не замечает. Считаю этот шаг для Mozilla крайне правильным. Так браузер будет развиваться динамичнее и различные новые фишки будут доходить до пользователя куда быстрее, пусть и маленькими порциями. Хочется также отметить, что Mozilla, как бы то ни было парадоксально, продолжает жить за счет своего главного конкурента на браузерном рынке Google. Не так давно был продлен весьма дорогостоящий контракт на то, что в Firefox поиском по умолчанию будет оставаться Google.

Opera Labs продолжают экспериментировать с различными новейшими технологиями, которые позволяет стандарт HTML5. Если мне не изменяет память, то недавно они выпустили первую 64-битную версию браузера. Хочется пожелать команде Opera великих свершений в их ожиданиях с экспериментами.

Chrome. Не могу говорить не предвзято об этом браузере лишь потому, что я его недолюбливаю. Но попробую. В 2011 этот браузер как всегда продолжает радовать своих пользователей скоростью. Ближе к концу года он даже обогнал Firefox по популярности. Теперь это самый популярный браузер в мире. Что в нем стало серьезно лучше? Хм, навскидку и не скажешь. Хотя да, в нем появились приложения (так называемые hosted apps). Но пожалуй это все.

А что Safari? Наверное, это один из самых консервативных браузеров в этом году. Честно говоря, Safari обновляю на своем десктопе регулярно, но каких-либо серьезных изменений я не заметил. Хотя наверняка Apple продолжает обновлять внутренний движок Webkit до последней версии перед каждым релизом Safari. И это не может не радовать.

PHP 5.4? Пожалуй вторая вещь которую я очень ждал и которую так и не дождался. Будем надеяться. В конце концов, 25 декабря уже вышла RC4, так что ждать осталось совсем недолго. Нам обещают еще больше производительности, mb_string вшитый по умолчанию, traits (aka mixins) и много других здоровских мелочей.

Очень многое еще хочется написать, но уже день 31-го числа и просто физически не остается времени на это. На этом все.

Желаю всем счастливого Нового Года!

Exception
    LogicException
        BadFunctionCallException
            BadMethodCallException
        DomainException
        InvalidArgumentException
        LengthException
        OutOfRangeException
    RuntimeException
        OutOfBoundsException
        OverflowException
        RangeException
        UnderflowException
        UnexpectedValueException

Кидайте SPL-исключения, наиболее подходящие по контексту причины потенциальной ошибки или неверных входных данных. Этим вы помогаете людям, которые будут в будущем разбираться в вашем коде или использовать его.

Проблема возникает в случае, когда вы загружаете Windows после Ubuntu. Время получается смещенным на 7 часов назад. Это очень раздражает, не так ли? Очень долго я жил с этим.

Но, оказалось, от этого естественно есть лекарство. Лезем в /etc/default/rcS и меняем опцию UTC на no. Это решает все проблемы, описанные выше.

Приятного всем кодинга на выходных дома! :)

/**
 * Indents a flat JSON string to make it more human-readable.
 * @param string $json The original JSON string to process.
 * @return string Indented version of the original JSON string.
 */
function indent($json)
{

    $result = '';
    $pos = 0;
    $strLen = strlen($json);
    $indentStr = '  ';
    $newLine = "\n";
    $prevChar = '';
    $outOfQuotes = true;

    for ($i = 0; $i <= $strLen; $i++) {

        // Grab the next character in the string.
        $char = substr($json, $i, 1);

        // Are we inside a quoted string?
        if ($char == '"' && $prevChar != '\\') {
            $outOfQuotes = !$outOfQuotes;

            // If this character is the end of an element,
            // output a new line and indent the next line.
        } else if (($char == '}' || $char == ']') && $outOfQuotes) {
            $result .= $newLine;
            $pos--;
            for ($j = 0; $j < $pos; $j++) {
                $result .= $indentStr;
            }
        }

        // Add the character to the result string.
        $result .= $char;

        // If the last character was the beginning of an element,
        // output a new line and indent the next line.
        if (($char == ',' || $char == '{' || $char == '[') && $outOfQuotes) {
            $result .= $newLine;
            if ($char == '{' || $char == '[') {
                $pos++;
            }

            for ($j = 0; $j < $pos; $j++) {
                $result .= $indentStr;
            }
        }

        $prevChar = $char;
    }

    return $result;
}

Эта функция сразу же была внедрена в проект и теперь коллегам разбирать JSON куда более удобно. :)