Дмитрий Гавриленко

Моё понимание такое.
Декларативное программирование - это когда в коде описано что должно получиться, а императивное - когда написано как это сделать. Т.е. в первом случае мы совершенно не интересуемся, каким именно образом машина сделает работу, какие инструкции в каком порядке выполнятся и так далее, мы просто объясняем ей, что хотим увидеть в результате. Примеры декларативных языков - html, css, sql, конфиг nginx. Ещё тут стоит упомянуть функциональные языки (lisp, haskell), программы на них тоже, как правило, являются описанием (декларацией) того "что должно получиться". Ну, короче говоря, мы говорим компьютеру: вот смотри, мне надо чтобы было так, а как ты это сделаешь, мне не интересно. Аналогия такая: у меня есть чертёж бани, я даю его бригаде строителей и уезжаю. Как именно они там будут таскать брёвна, пилить доски и прочее - я не в курсе.
Программируя императивно, мы описываем конкретные шаги, действия и точный порядок, в котором их нужно исполнять. Напрямую руководим процессом, непосредственно отдаём приказания. Примеров масса, большинство популярных языков императивны, в том числе и javascript. Ты пишешь: вот, сделай-ка переменную myVar, потом запиши туда число 5, повторяй это до тех пор, пока что-то не случится... и так далее. Возвращаясь к примеру с баней, ты теперь - начальник бригады, именно говоришь какое бревно куда класть.
Что касается процедурного и объектно ориентированного стилей, это немного о другом. Я бы сказал, что это два разных способа писать императивные программы. В процедурном случае мы организуем код, наши команды (приказы машине) в виде процедур. Процедура - набор команд. Это довольно простой способ организации кода и исторически более ранний. ООП - это чуть более сложный подход к организации кода, когда мы группируем инструкции и данные, которыми они манипулируют, вместе. Объект - это состояние (данные) плюс поведение (набор методов). Но это уже немного другая история.

10 лет это 3 класс

Отстаньте лучше от ребёнка. Ему всего лишь 10 лет - какое программирование? Пусть он сначала насладится детством. А уже после - сам начнёт ковыряться в том, что ему понравится

await только подписывается на результат awaitable (в нашем случае Task). И то будет ли выполнятся этот не зависит от await т.е. от тех кто его может ждать. т.е. ответ - Да, Notify() будет себе часами молотить. Если внутри будет ошибка, то лучше подписаться на результат и скипнуть ошибку. Notify().ContinueWith(t=> { var x = t.Exception; ... });

Task.Run(async () =>
Так делать не стоит, это ошибка, которую часто совершают. 'async => ()' это уже стейт-машина которая запускается вызовом, ее не надо шедулить через таски.
Правильный пример:

new Func<Task>(async =>  {
    try
    {
        await _notification.Notify();
    } catch(Exception ex) {
        // TODO: Логируем исключение
    }
}).Invoke();

Но опять же это всё не нужно в текущей задаче, можно вызвать ContinueWith.

1. В Redis лучше представлена работа с коллекциями. Простой пример — инкрементальный счётчик. Вы делаете incrby/hincrby для любого ключа, не заботясь о его наличие в хранилище. В Postgres аналогичная функциональность на основе последовательностей (nextval('foo')) подразумевает, что вы уже создали последовательность 'foo' ранее. Это подталкивает вас на написание процедур, которые перед попыткой изменить счётчик, сначала проверяют его наличие, при необходимости создают его и только потом изменяют. Больше ручной работы.

2. Структуры данных в Redis оптимизированы либо под быстрый поик О(1), либо под компактность и приемлемую произволительность O(N), O(log(N)). Практически всегда получается обходиться простыми или вложенными хеш-таблицами с О(1) или О(n). В Postgres вы практически всегда пользуетесь той или иной разновидностью B/R-tree, GiST/GIN индексов со сложностью O(log(N)(+N)). До версии 8.4, индексы типа HASH в Postgres имели практически схожую с B-tree скорость поиска, поэтому их применение не имело никакого смысла. Сейчас, в версии 9.1, смысла стало больше, но не намного — HASH индексы не поддерживают Write-Ahead Log и при сбоях требуют ручной переиндексации:
"Hash index operations are not presently WAL-logged, so hash indexes might need to be rebuilt with REINDEX after a database crash. They are also not replicated over streaming or file-based replication. For these reasons, hash index use is presently discouraged." http://www.postgresql.org/docs/9.1/static/indexes-types.html

У себя в проектах, я использую и Redis, и Postgres. Первый — как эффективную систему для сбора онлайн-статистики (счетчики-лайки, различные метрики), а второй — как хранилище для пользовательских аккаунтов и контента с его мета-информацией. При этом, наметилась тенденция переносить контент на HBase, оставляя для Postgres только задачи по ACID-обслуживанию операций с пользовательскими аккаунтами.

Потому что у вас при рекурсивном вызове обратно ничего не возвращается.
https://jsfiddle.net/x4gyg9qp/10/

Разобрался.
Необходимо использовать localhost:8080 , а не домен, как пишут в гайдах

При увеличении - видно, что контуры снимка над полосой влияют на изменение цвета в этой полосе. Могу предположить, что неисправность в матрице/контроллере камеры на 2 цветовых канала: RED и BLUE, их сумма сбрасывается в GREEN-канал, образуя зеленую полосу с разной интенсивностью зеленого, который зависит от изображения.

С учётом вашего комментария к ответу x67:
В этом случае можно попробовать проверять только каждый пятый байт. Если там ноль - от него шагаем по одному символу влево до тех пор пока не наткнёмся на не ноль. После чего отходим ещё на пару символов влево и уже с этого символа проверяем вхождение паттерна.
Теоретически можно получить экономию почти в пять раз.
Но это будет хорошо работать только если в массиве мало нулей, не являющихся частью паттерна. Если же в массиве много посторонних нулей - то может получится даже хуже, чем при линейном поиске.
И всё-таки рекомендую попробовать реализовать этот вариант и замерить время работы по сравнению с линейным поиском.

Ну в общем-то, как заметил Александр, вы хотите чуда, но алгоритм можно оптимизировать, если есть какая-либо закономерность, которая позволяет предсказать, в каких областях может быть искомый паттерн.
Также если местоположение начала паттерна не может быть произвольным (то есть паттерн может начинаться в 1, 11, 21 байте, но не может начинаться в 37 к примеру), то время поиска можно сократить менее, чем в 10 раз, сначала поискав все первые байты, а потом проверив эти места уже полностью.
Также можно поискать закономерность в этом паттерне.
Но в целом, если это будет регулярной задачей, прикрутите что-нибудь для первоначальной обработки массива.