Alex Plotnikov

Генерация такого рода картинок основана на том, что от имени / почты / еще какого-то параметра считается хэш, а потом на основании него по какому-то (зачастую подобранному на глазок) алгоритму уже генерируется картинка. На javascript это удобно делать на canvas, благо его можно легко крутить и симметричную картинку сделать не сложно. Останется только при необходимости сохранить ее в файл, но этот вопрос легко гуглится.

Для иллюстрации приложу свой пример на codepen (писался на скорую руку, так что за ***код не пинайте)

Bind-переменные могут использоваться только для передачи данных, но не для построения самого запроса. После подставления значений исходный запрос будет иметь вид `SELECT 'fieldname' from table group by 'fieldname'` (обратите внимание на кавычки вокруг `fieldname`).
Если нужно динамически строить состав запроса (колонки, group by, order by, и т.д.), от конкатенации его на стороне приложения никуда не деться. Главное не использовать в этой конкатенации пользовательский ввод (либо, если это таки нужно - предварительно проверять, что нужная колонка действительно существует и разрешена для подобного использования).

Полагаю, что библиотека libstdc++ на ЦентОС другой версии, из-за чего в ней отсутствуют необходимые API.

Неплохой набор операций над слайсами: https://github.com/golang/go/wiki/SliceTricks

В данной задаче нужен "Filtering without allocating"

b := a[:0]
for _, x := range a {
	if x != "html_2222" && x != "css_2134234" {
		b = append(b, x)
	}
}

https://habr.com/post/348206/

1. Вначале будет искаться равенство (=). Оно имеет высший приоритет.
   
2. Потом будет искаться максимальный по длине префиксный location ((   ) или (^~)), после чего будет проверено, есть ли на найденном location модификатор приоритета (^~), и если он есть, то будет возвращён этот location.
   
3. Потом будут проверяться регулярные выражения ((~) и (~*)) сверху вниз. При совпадении будет возвращён первый location из них.
   
4. Потом вернётся тот префиксный location, который мы нашли до этого.
   

В вашем случае возможно так:

location ~* ".*" {
     proxy_pass http://127.0.0.1:port; //тут висит сервис на go который по hash должен проверять доступ и редиректить на  mp4 с заголовком X-Accel-Redirect
}

Я бы сделал так.
1. Есть канал куда попадают все задачи.
2. Есть горутина, которая разгребает канал и на каждоее сообщение из канала запускает горутину для обработки сообщения.
3. При необходимости эта горутина ставит сообщения в тот же канал.
4. При запуске горутины-обработчика добавлять в wait group и не забыть 'defer wg.Done()'

Вот как-то так: https://play.golang.org/p/z0fS5O8ynSI
Не уверен, что это хороший код, но общую идею показть должен.
Размер буфера - то максимально возможное количество задач, которые могут прийти в качестве подзадач (с учетом вложенности, если у подзадачи могут быть свои подзадачи + 1 (на текущую задачу)

ИМХО, делайте так как написали
В базе отдельное поле varchar 32 для хэша, туда MD5 от title и на это поле вешаете индекс в БД
Поиск будет очень быстрый

Как оказалось все просто:

\Test - это php class

namespace Zephir;

class App
{
    public function execute()
    {
        var test;

        let test = <\Test> new \Test();
    }
}

Там простой текстовый протокол
Открываете сокет, чуток разговоров, и вот вы знаете, хотят ли с вами общаться. Затем закрываете сокет.