mayton2019

Минусы:
1. Вам самим придётся все свои доходы декларировать, чтобы потом не жаловаться, что вам заблокировали счета и начислили пени за неуплаченный налог в лучшем случае
2. Закон тебя никак не защищает (могут уволить одним днём, например, и вполне законно могут недоплатить, списав на волатильность курса)
3. Работодатель, который такое предлагает - в 99% случаев занимается чем-то серым, а то и незаконным => тебя ещё могут как соучастника накрыть, если очень сильно не повезёт.
4. Курс волатильный и могут быть проблемы при попытке перевода в фиат (начиная с комиссий и невыгодного курса, заканчивая обвалом курса и отсутствием покупателей. Про возможность объявления крипты вне закона или блокировки счёта на бирже или в банке я молчу)

Законно ли это(живу в России)?

То что ты делаешь уже не законно, даже без привлечения крипты, тк в России запрещено иметь трудовые отношения (регулярные работы на полный рабочий день с фиксированной ежемесячной оплатой) между самозанятым (исполнителем в статусе самозанятого) и заказчиком, ибо это очевидное уклонение от налогов (со стороны исполнителя, ибо так ты уклоняешься от НФДЛ) и нарушение трудового кодекса (со стороны заказчика, тк он уклоняется от уплаты взносов в ФСС и ПФР, и не обеспечивает тебя-работника социальными гарантиями)

Законно ли это(живу в России)?

Крипта в России не является законным средством платежей. Так что если не хочется проблем с законом - нужно оформлять две операции:
1. Оказание услуг (с ценой рублях).
2. Продажа/покупка крипты на эту сумму.
Причём по времени сначала ты должен оказать услугу, а уже потом "купить" крипту, после чего её продать, и уже тогда деньги с продажи крипты должны поступить на твой счёт в банке. Иначе рискуешь словить блокировку (в лучшем случае - временную, пока не объяснишь банку, что это вообще произошло)

Иначе потом будут вопросы "а откуда крипта" и "а где деньги, которые ты должен был получить за оказание услуг".

Много ли уходит на комиссиях?

Это уже зависит от того, как будешь выводить и как тебе будет твой "работодатель" деньги присылать.

В самую первую очередь - это будет документация языка. Ее очень удобно использовать как справочник. Это - твой самый первый источник информации по любому вопросу.
isocpp поддерживается создателем языка и содержит море полезной информации.
C++ Core Guidelines является манифестом пользователя C++. Его знать обязательно. Документ регулярно дополняется.

More C++ Idioms. Шаблоны проектирования имеют свою собственную многомерную классификацию. Идиомы - это функциональные шаблоны проектирования, применимые, как правило, или для конкретного языка, или для некоторого семейства языков. Эта открытая книга помогает ориентироваться в некотором начальном наборе идиом конкретно для языка C++.
C++ Patterns - еще один полезный ресурс для изучения применимых к C++ шаблонов проектирования.
С Fluent C++ ты уже знаком.
Безусловно, блог создателей PVS-Studio.
Habr, конечно же.
Блогов очень много, их можно просто найти по релевантной фразе "C++ blog".

Помимо этого есть большое количество каналов от разных конференций, доклады на которых всегда помогают понять язык лучше.
С++Russia,
C++Now,
Pacific C++,
CppCon,
code::dive,
Meeting C++.

Так же будет полезно изучить книги авторов:
Андрея Александреску,
Герба Саттера,
Девида Вандервуда,
Скотта Мейерса,
Роберта Мартина.
Есть и другие очень полезные авторы. Тут у меня, пожалуй, только самый основной список.

Последим, и самым важным, источником будет текущая рабочая версия стандарта языка, а так же пара лабораторий для практики: Compiler Explorer и C++ Insights.

Никогда не используй сжатие с потерями jpeg для таких целей. Используй PNG.

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

Если удобного идентификатора нет, то обычно самое простое, - формировать из сравниваемых данных строку одинаковым способом, и получать из нее хеш сумму (md5 более чем подходит, если данных не 16-значное количество, т.е. не нужно заботиться о коллизиях), его и используй как идентификатор и храни где-то списком как предыдущие значения и сравнивай с ново загруженной, прямо во время анализа. Записи, хеш сумма которых, не была найдена в записях, помещай в базу данных (ну или обновляй значения, если речь идет о модификации а не добавлении новых).

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

UPDATE:
Надо же, с 2019-го многое поменялось в интересную сторону. Для PyQt и PySide есть qasync, который активно развивается, а для Tk вообще не нужны сторонние библиотеки:

import tkinter as tk
from tkinter import ttk
import asyncio


class App:
    async def exec(self):
        self.window = Window(asyncio.get_event_loop())
        await self.window.show();


class Window(tk.Tk):
    def __init__(self, loop):
        self.loop = loop
        self.root = tk.Tk()
        self.animation = "░▒▒▒▒▒"
        self.label = tk.Label(text="")
        self.label.grid(row=0, columnspan=2, padx=(8, 8), pady=(16, 0))
        self.progressbar = ttk.Progressbar(length=280)
        self.progressbar.grid(row=1, columnspan=2, padx=(8, 8), pady=(16, 0))
        button_block = tk.Button(text="Calculate Sync", width=10, command=self.calculate_sync)
        button_block.grid(row=2, column=0, sticky=tk.W, padx=8, pady=8)
        button_non_block = tk.Button(text="Calculate Async", width=10, command=lambda: self.loop.create_task(self.calculate_async()))
        button_non_block.grid(row=2, column=1, sticky=tk.W, padx=8, pady=8)

    async def show(self):
        while True:
            self.label["text"] = self.animation
            self.animation = self.animation[1:] + self.animation[0]
            self.root.update()
            await asyncio.sleep(.1)

    def calculate_sync(self):
        max = 3000000
        for i in range(1, max):
            self.progressbar["value"] = i / max * 100

    async def calculate_async(self):
        max = 3000000
        for i in range(1, max):
            self.progressbar["value"] = i / max * 100
            if i % 1000 == 0:
                await asyncio.sleep(0)


asyncio.run(App().exec())

Если я правильно понял суть вопроса, вам подойдёт любая KV СУБД. Вынесите только эту таблицу в какой-нибудь Tarantool или Redis (я имею в виду использовать хранимые процедуры для вашей задачи). 1-3 млн записей - относительно немного. Даже если одна запись весит 4 КБ, все данные займут 4-12 ГБ ОЗУ, что не так уж и много. Если использовать батчинг, что Redis, что Tarantool дадут вам на 16 ядрах свыше 100к RPS на такие сложные запросы.

Можете так же глянуть AerospikeDB (хранит данные на диске, но с индексами в памяти, где один индекс стоит 64 байт), но я не уверен, что вам хватит его функционала. Если вы дадите больше контекста, возможно, я смогу предложить вам другие идеи.

UPD: AerospikeDB тоже позволяет сохранить готовые процедуры, так что его функционала хватит для вышеуказанной задачи.

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

Лидер опрашивает остальные сервера по очереди (включая себя), и справшивает их, есть ли у них еще непокрашенные вершины. Если есть, инструктирует их запустить волну. Когда волна закончится, справшивает опять. Когда сервер говорит, что больше непокрашенных вершин нет - лидер переходит к следующему серверу.

Когда сервер запускает волну - он обходит все вершины у себя, если встречает призрачное ребро, то посылает сообщение другому серверу запустить обход у себя с присоеденненной вершины.
Чтобы отследить конец волны, перед запуском обхода в другом сервере, каждый сервер отслывает лидеру сообщение, что вот тот сервер теперь будет работать. Когда волна в каком-то сервере заканчивается, он присылает лидеру сообщение, что все закончилось. Лидер поддерживает счетчик - сколько еще серверов работает. Когда счетчик достигает 0, надо еще подождать немного (скажем, пол секунды), на случай реордеринга сообщений. Если в течении этой пол секунды никаких сообщений не пришло, можно запускать новую волну.

Более сложный вариант - когда у вас сразу запускаются все волны. Опять же, без лидера совсем сложно будет.
Тут, наверно стоит сначала в каждом отдельном параграфе найти все компоненты связности отдельно. Это будут промежуточные варианты.

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

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

Чтобы определить, что все закончилось, можно разбить процесс на фазы. В первой фазе все рассылают свои номера. Во второй фазе только те, у кого номера обновились. И т.д. Фаза на сервере начинается после сообщения от лидера. Каждый сервер отправляет на лидер сообщение, когда он закончил рассылать свои номера и были ли там вообще обновления. Сообщения надо делать по tcp с подтверждением. Когда лидер заметит, что никто никаких сообщений больше не рассылал в предыдущей фазе - все сошлось.

Напрягает требование, что нельзя использовать контейнеры. Так-то ваш подход правильный: Заводим поле для вывода, рекурсивной функцией, которой передаются порядок кривой, и где ее рисовать (квадрат и его поворот). Функция рекурсивно вызывает 4 кусокчка в каждом из 4 квадратов и рисует 3 соединительных кусочка. Но поле для вывода это так или иначе массив. Можно и самому его завести, но почему нульзя использовать контейнеры - не понятно.

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

А потом циклом выводим результат работы функции для всех координат. Это работает в логарифм раз медленее, но зато не требует выделения памяти под все поле вывода.

edit: Да, еще есть трюк - считайте, что кривая не замкнута. Левый верхний угол - пустота. И надо отдельно в самом конце замкнуть ее в этом углу через "/".

Как я понял, вы хотите в одном и том же репозитории хранить два енвайрнмента, на одной и той же машине.
Но это неверный подход. Ветки это не разные версии софта, ветки это разные состояния исходников.
Сделайте ваш код, чтобы там был prod.config, dev.config и все

Тут в коментах понакидали, я немного разложу для понимания.
Сегодня программирование это не 1 область, типа " - хочу в программирование - вам вот в эту дверь".
Условно ее можно разделить на несколько подвидов, переход из которых в смежную будет сопровождаться некоторыми трудностями, особенно для новичка, по этому с направлением нужно определиться на берегу, или по крайней мере вовремя остановиться если увидели что это направление - не ваше.

1) Веб разработка. В свою очередь делится на 2 поднаправления: фронтенд - все что отрисовывается и обрабатывается на клиенте (то есть проще говоря в браузере), и бэкенд - все что относится к работе со стороны сервера. Фронтенд, как это ни странно, ограничен в языках более всего, тут только яваскрипт или что-то типа тайпскрипта, которое по итогоу в яваскрипт "компилируется". Бэк в этом плане более разношерстный, тут можно практически все использовать, но мэйнстрим это пхп, питон, ява, сишарп, руби-рельсы. Первые два в основном используют студии вебразработки, вторые два - в основном энтерпрайз, последний уже больше экзотика.
2) Геймдев. Как ни странно, тоже делится на 2 поднаправления: казуалки/мобилы и большие триплА проекты. В первом случае это сишарп + юнити (да, это не язык, а инструмент, но без него стек не полный), в редком случае что-то экзотическое. Во втором это скорее всего си++ и какой-то фреймворк, а-ля анриал или вулкан.
3) Энтерпрайз. Тут стандарт де факто - ява. Как вариант Сишарп, но гораздо реже.
4) Десктоп приложения. Простенькие консольные можно писать практически на чем угодно, более-менее обладающее интерфейсом тербует соответствующих gui библиотек, по типу Qt, gtk, ну и соответственно языков типа ява, си++, сишарп... Хочу заметить, что направление это весьма дохлое, в плане того что именно приложения для широких масс в последнее время практически не выпускаются, уступая место вебсервисам или мобильным приложениям, которые тоже не ахти какие рынки занимают...
5) Мобильная разработка. Зверь редкий, так как под мобилы больше игры делают. Именно разработка приложений достаточно узкий сегмент, ну и опять же - делится на разработку под андроид и под айфон. В первом случае языком разработки будет Котлин(в девичестве Ява), под айфон соответственно будет Свифт. Есть решения кроссплатформенные, по типу флаттера, но это не всегда подходит, так как некоторые функции под конкретную платформу будут недоступны.

Короче, определяетесь с направлением, пробуете, не нравится - берете следующее, с языками так же. По тому "в чем писать" определяться стоит по запросу "среда разработки для %языкнейм%"