danforth

Тут два способа.
1. Ты изменяешь нужные тебе селекторы непосредственно в самом файле фреймворка.
2. Ты смотришь селекторы в файле фреймворка, которые влияют на нужные тебе свойства и прописываешь их у себя с нужными тебе атрибутами, если нужно дописываешь important.
з.ы я сейчас тоже работаю с bulma и scss, мой вк указан в профиле, можешь попробовать написать туда, если есть ещё вопросы.

shouldBeFiltered
isFilteringNeeded

Индекс возможно повесить функциональный:

create index on tablename using btree(((features ->> 'capacity'::text)::integer));

Соответственно предикат по этому же самому выражению получит возможность использовать этот индекс.

Больше возможностей внятно индексировать jsonb для запросов на числовые диапазоны мне как-то не вспоминается. Сортировку по полю-то только btree и умеет из всех актуальных access method.

Т.е. индекс используется, хотя в данном случае index срабатывает на price столбце? Тогда почему запрос отрабатывает быстро?

Да, индекс используется - индекс по price. Потому что вы по нему сортируете. И планировщик опираясь на свою статистику надеется, что сможет быстро найти 25 строк читая строки в порядке требуемой сортировки по индексу и по пути проверять выкидывать неподходящие.

// рекурсивно создать варианты для каждого корневого ключа
function create_variants($arr)
{
    $items = [];
    foreach ($arr as $key => $value) {
        $vars = [$key];
        if (!is_array($value)) {
            $items[] = implode(';', $vars);
            continue;
        }

        $variants = create_variants($value);
        foreach ($variants as $variantValue) {
            $items[] = implode(';', array_merge($vars, [$variantValue]));
        }
    }

    return $items;
}

/**
 * объединить варианты корневых ключей
 * @param $partsCount количество объединяемых в одно вариантов
 */
function join_variants($items, $partsCount)
{
    $result = [];
    $joinable = array_chunk($items, ceil(count($items)/$partsCount));

    foreach ($joinable as $chunk) {
        foreach ($chunk as $index => $item) {
            if (isset($result[$index])) {
                $result[$index] .= ';'.$item;
            } else {
                $result[$index] = $item;
            }
        }
    }

    return array_map(function ($v) {
        return $v.';';
    }, $result);
}

var_dump(join_variants(
    create_variants($features),
    count($features)
));

в cron по событию @reboot должен запускаться ваш скрипт.
в скрипте
mkdir /var/run/redis и нужный chown/chmod на эту папку.

собирать бинарник на продакшене - идея так себе.
даже образ 1.9-alpine занимает 83 метра + будут зависимости в GOPATH

Я делал следующим образом
В GitLab CI создавалась задача на тесты проекта, сборку его в бинарник и создания docker образа FROM: SCRATCH, где находится ТОЛЬКО этот бинарник.
На входе я получал образ размером с бинарник - без зависимостей в GOPATH и среды сборки - около 15 мб.

Есть ньюансы для сборки такого бинарника, но в большинстве случаев ИМХО они не существенны.
+ недостатком такого подхода является то, что просто так в контейнер не залезешь и не выполнишь какую-то bash команду, т.к. там ничего нет вообще, кроме бинарника.

вот статья. https://blog.codeship.com/building-minimal-docker-...

В Го есть такая системная переменная как $GOMAXPROCS, по-умолчанию она равна количеству процессорных ядер. Её значение определяет, сколько процессов будет запущено планировщиком го. Горутины распределяются между этими процессами. Если одна горутина заняла все вычислительное время одного процесса (как в вашем случае бесконечный цикл for, ибо он не прерывается операциями ввода/вывода или другими случаями ожидания ресурсов), то если $GOMAXPROCS=1, другие горутины будут ждать освобождения единственного процесса.
Когда вы меняете цикл на таймер, в момент вызова time.Wait процесс освобождается и может выполнить другую горутину.

Фактически вам дают выделенный сервер (который просто не является железным, на то он и виртуальный). Если говорить про digitalocean - там у вас действительно всё своё выделенное (память не шарится, а аллоцируется при старте виртуалки, ядро процессора для вас личное на тарифах от $10, lvm-том с только вашей виртуалкой (фактически - выделенный для вас раздел raid-массива)).

Всеми настройками внутри системы занимаетесь вы. Более того, хостер даже не отвечает за то, что у вас система запустилась. Если виртуалка грузится до биоса - то свою работу по обеспечению работы сервера хостер выполнил (опустим в этом контексте вопросы про сеть). Если сломали ОС и она не загружается - у вас есть кнопка "переустановить чистую систему". За бэкапы, опять же, отвечаете вы (digitalocean предоставляет платные бэкапы, но они не очень удобны). За безопасность - вы.
В случае с digitalocean у вас есть доступ к "монитору" виртуалки и загрузочный rescue-livecd. В общем-то всё.

По поводу того, как настраивать (если речь про стандартный стек LAMP), то:
1) debian 7 x64
2) отключение авторизации рута по паролю, использование ssh-ключей
3) для диагностики установить snoopy, настроить логгирование sftp.
4) не использовать ftp, использовать только sftp. Желательно, по ключам. В sftp-клиенте ни в коем случае не хранить пароли от аккаунта или ssh ключа.
5) nginx+apache-mpm-itk + php 5.3 и выше + percona-server вместо mysql
6) в конфигах виртуалхостов включите open basedir, если сайт будет с этой настройкой работать (эта опция запрещает php-скриптам при обращении к ним по http выходить за пределы указанных в basedir каталогов)
7) не забудьте включить MatchUser/MatchGroup для виртуалхостов
8) обязательно настроить default host для apache и nginx, чтобы исключить неконтролируемую конфигами обработку каких либо запросов по http. Обычно вешают 403 или 404 ошибку в качестве дефолта.
9) не ставить лишний софт, не вводить бездумно команды из случайно найденных в гугле мануалов, если не понимаете что именно эта команда делает.
10) не ставить софт из исходников, особенно из недоверенных источников.
11) если на сервере нужна исходящая почта, то корректно настроить ограничения для неё. Например, для exim4 (он предпочтителен в Debian) - раз, два.
12) убрать за http-auth все лишние административные скрипты - phpmyadmin, админки сайтов, графики, мониторинг и так далее.

Это исключит почти все возможности атаки на сервер снаружи. В такой конфигурации если вас и взломают, то либо из-за украденного пароля/ключа, либо поломают сам сайт и зальют вредоносные файлы через php-скрипты непосредственно сайта.
Более того, у меня в такой конфигурации пока не сломали ни одну виртуалку целиком (были проблемы с заражением отдельных сайтов, конечно - но это было сделано явно через php), несмотря на разрешающий всё firewall и стандартный ssh-порт.

А вообще за настройку всего этого добра под 2-3 сайта админы берут около 500 рублей.

Можно воспользоваться неким костылём, но может быть он вам подойдёт:

1. Оборачиваем нужный контент с динамической высотой в контейнер
2. Устанавливаем контейнеру максимальную высоту и overflow:hidden
3. Получаем реальную высоту внутреннего контента, даже если она превышает высоту обёртки

Пример тут: https://jsfiddle.net/Lsybva53/
Клацните по серому блоку и смотрите в консоль.