Вадим Маткаримов

https://medium.com/@rajaraodv/using-preact-instead...
ответы на многие вопросы

Четвёртое действие (перемещение master на C3'', когда HEAD->caption)
git branch -f master HEAD
Я бы и не знал, если бы не одно из заданий, и использовал связку git checkout master && git reset --hard caption.

По поводу git rebase caption (когда находимся в master). Там срабатывает fast-forward, поэтому ветка автоматически продвигается вперёд. Чтобы удать этот эффект, пишем git rebaes --no-ff. Интерактивный режим по умолчанию отключает ff.

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

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

Webhook — механизм оповещения системы о событиях.

Допустим есть определённый сервис который должен оповещать о событиях когда они происходят.
Как вариант постоянно запрашивать новые данные на сервере, минус будет скорее в скорости получения данных если на сервере например стоит задержка на получения новых оповещений.
А вот webhook исправляет этот недочёт, когда происходит событие он запрашивает адрес сайта с параметрами, например example.com/webhook/notification и передаёт в теле POST запроса JSON (зачастую) и там будут свежие данные.

Простой пример можно посмотреть: создание бота для telegram на webhooks.

Есть программа для выполнения HTTP запросов. Называется Postman. В ней можно наглядно сформировать запрос и сгенерировать код.
Вот пример curl запроса:

curl -X POST \
  'https://pu.vk.com/<ссылка загрузки>' \
  -H 'content-type: multipart/form-data;' \
  -F photo=@/private/tmp/f.png

Или на Python:

import http.client

conn = http.client.HTTPConnection("pu,vk,com")

payload = "------WebKitFormBoundary7MA4YWxkTrZu0gW\r\nContent-Disposition: form-data; name=\"photo\"; filename=\"f.png\"\r\nContent-Type: image/png\r\n\r\n\r\n------WebKitFormBoundary7MA4YWxkTrZu0gW--"

headers = {
    'content-type': "multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW",
    'Cache-Control': "no-cache",
    'Postman-Token': "78ca70c7-7da5-45c7-8a79-67d79d09761c"
    }

conn.request("POST", "", payload, headers)

res = conn.getresponse()
data = res.read()

print(data.decode("utf-8"))

Тут ставят Youtrack на слабый ВПС
maxmikheev.ru/blog/2016/05/05/how-to-selfhost-yout...

вторая часть статьи про оптимизацию под маленькую оперативку

Самый верный способ - с помощью Visual Studio Uninstaller

Посмотрите данные темы:
Длинная арифметика
Динамическое программирование
Теория графов
Рекурсия, перебор
Сортировка и последовательности
Комбинаторика
Простая математика
Геометрия
Целочисленная арифметика
Математическое моделирование
Жадный алгоритм
Структуры данных
Двумерные массивы

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

Архив задач и тренировка здесь:
acmp.ru
acm.timus.ru
Codeforces
Это очень полезные ресурсы (системы проверки), в которые входят очень интересные и трудные задачи, как раз предназначенные для олимпиадного программирования.
Ознакомьтесь здесь:
Олимпиадное программирование для новичков

Набор языков программирования в каждой системе разный. Вот некоторые из них:
Набор яп для тимуса
Для acmp.ru

Но для начала почитайте и разберите эти ресурсы/книги про алгоритмы:
algolist.manual.ru
Кормен Т., Лейзерсон Ч., Ривест Р., Штайн K. - Алг...

Ну и конечно, подтяните математику. Без математики далеко не уйдете.

Ответ на Ваш вопрос: для длинной арифметики подошел бы Java.

Основной посыл использования RESTful API - применение основной идеи Паутины для взаимодействия автоматических агентов (приложений), а не только людей.
Основная идея Паутины - построение распределенной информационной системы путем публикации неких абстрактных ресурсов, выдачи им идентификаторов (в сегодняшнем вебе - иерархических), определения ряда простых и широко известных операций над ними, не зависящих от содержимого ресурса (те самые GET, POST, PUT и т.д.), и связывания этих ресурсов ссылками (это называется гипермедиа, и в частности, гипертекст, если речь идет о текстовой информации).
Как люди с появления Веба публикуют информацию в нем для потребления другими людьми, так и RESTful веб-сервисы публикуют иерархически структурированные ресурсы для потребления клиентами. Разница только в представлении - для людей это plaintext/HTML, для автоматических агентов - это JSON/XML/прочие форматы, которые удобно обрабатывать.
Таким образом, если вы хотите какую-то информацию опубликовать как RESTful API, вам необходимо представить ее как набор ресурсов, а все операции над этой информацией выразить через набор предопределенных операций. Фишка в том, что во многих задачах этих предпопределенных операций вполне достаточно, главное правильно определить ресурсы.
Важно понимать, что "ресурс" это обычно некоторая сущность, "существительное". Как правильно заметил Антон Жуков , ресурс /getItems хоть и может существовать в принципе, говорит о неудачно спроектированном API (действие представлено как ресурс).

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

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

Сама архитектура REST не привязана к конкретным технологиям и протоколам, но в реалиях современного Веб, построение RESTful API почти всегда подразумевает использование HTTP и каких-либо распространенных форматов представления ресурсов, например JSON, или, менее популярного сегодня, XML.

Смысл использования REST в том, что принципы, хорошо показавшие себя в "человеческом" веб и позволившие построить самую большую распределенную ИС, применяют и для "веба машин".

Ответ длинноват, но как короче объяснить, чтобы не исказить понимание, не представляю. Если что непонятно - спрашивайте.