mayton2019

Что-то ты не то делаешь. Сделай
docker run .....
с указанием правильного image и все заработает.

В базисе RGB тоже можно посчитать. Сначала выбирай центр кластера. Эталонный синий с которым хочешь сравнивать. Дальше для всех цветов считай просто декартово расстояние. И если допустим оно будет меньше какой-то величины- то близко к эталону. Вот неполный пример на другом языке. Можно как-то дописать на Python.

public double getDistance(int color1,int color2) {
        double rv = 0.299 * (getRPixel(color1) - getRPixel(color2));
        double gv = 0.587 * (getGPixel(color1) - getGPixel(color2));
        double bv = 0.114 * (getBPixel(color1) - getBPixel(color2));
        return sqrt(rv * rv + gv * gv + bv * bv);
}

Можно выбрать базис HSV, тогда для похожести брать измерение H (Hue) как эталон.
Но цветовой тон - вращается. Тоесть надо учитывать его как часовую стрелку например без 5 минут 12
близко к без 15 минут и к 12:05 одинаково.

Посмотри чистым взглядом на то что ты скачиваешь

$ wget https://api.bittrex.com/api/v1.1/public/getticker?market=USD-BTC

может там сайт вообще не работает. Короче учись видеть исходные данные глазами.

Макросы - это рудимент. Пережиток прошлого. Во многих современных языках их нету принципиально. Хотя в C/C++ они выполняют функцию такого себе прозрачного преобразования исходника перед сборкой. С помощью М. можно например принять решение о платформенной компилляции WIN32/LINUX/MAC. Напихать ассемблера с вариантами.

В gcc кажется есть ключи которые позволяют увидеть код программы после макро-подстановки.

Вообще с помощью М. можно делать разные веселые вещи например переименовать TRUE в FALSE. Такая себе тема троллинга на собеседовании.

Вот это предложение - хорошее.

compiled{
   if(something){
   }
}

Но я думаю что комитет его уже обсуждал. Надо найти только протоколы.

Почитайте еще спецификацию ZigLang. Там были реализованы какие-то фичи с compile time.

Вот эта колбаса - по смыслу - group-by с фильтрацией. Попробуй сделать из 3 запросов 1.

,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='qqq' AND item_id = ebids.id) AS has_qqq_comment 
  ,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='www' AND item_id = ebids.id) AS has_www_comment 
  ,(SELECT COUNT(comment_system.id) FROM comment_system WHERE itemtype='eee' AND item_id = ebids.id) AS has_eee_comment

Поскольку ты тегнул вопрос "JAVA" то имеет смысл просто начать изучение сразу по книгам Брюса Эккеля и Хостмана.
Вот в разрезе того как они описывают ООП - тебе будет достаточно. Еще посмотри на книгу Шаблонов проектирования (от Банды четырех) и Рефакторинг с шаблонами от Джоша Кериевски.

Читать чистую ООП - теорию я тебе не советую. Там нет того что тебе понадобиться.

Мне вспоминается мульсериал Футурама. Там когда профессора спросили - на каком принципе летает его космическая ракета - он ответил что она на самом деле не летает. Она стоит на месте. Просто она двигает вокруг себя всю вселенную.

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

SELECT 
 `user_id`, `username`, `first_name`,`last_name`, `title` 
FROM 
 `userdata` 
WHERE 
 `type` LIKE '%group'

Мне кажется что JavaScript/TypeScript - это плохой старт для изучения ООП. Дело в том что JavaScript исполняющая среда изначально была разработана с слишком вольной интерпретацией объекта. Грубо говоря она настолько flexible что те строгие законы и правила которые навязывает ООП в JavaScript могут быть слишком легко нарушены.

Поэтому чтобы почувстоввать нужность ООП, как дисциплины. Я-бы предложил Java или C#. Это как в музыке. Нельзя начать сразу ипровизировать джаз на музыкальном инструменте в 5 лет. Надо пойти в музыкальную школу где преподаватели тебе поставят руку правильно. А потом уже после семилетки - муз-училища - консерватории - иди в импровизации. Или даже иди раньше. Но какая-то дисциплина должна быть. ООП - это дисциплина. Не волюнтаризм.

Несколько мыслей. Не претендует на правильность. Особенностей Котлин не знаю но подозреваю что он под капотом просто использует Java Threads.

1) Java используют модель потоков при коророй 1 поток ОС не равен потоку JVM. Обычно 1 поток ОС может обслуживать много Java threads. В состоянии покоя threads мало потребляют ресурсов.

2) Я пока не вижу проблем до тех пор пока у вас нет нехватки Heap. 1 Thread по умолчанию аллоцирует 1Мб поэтому 1000 тредов могут у вас скушать гигабайт. Есть опция командной строки которая это регулирует. Ее надо трогать аккуратно чтоб не получить другую ошибку типа Stackoverflow.

3) По поводу того чем заняты threads. Сделайте дамп стека потоков как один чел тут пишет https://www.baeldung.com/java-thread-dump

И посмотрите на вершине стека какую функцию каждый поток выполняет. Если например они друг друга блокируют или ждут I/O - это будет повод поговорить с программистом. Может код написан неоптимально.

4) Кроме того программист должен был заложить в конфиги регулятор числа рабочик потоков в пуле. Это может быть нечто вроде

Executors.newFixedThreadPool(....);

короче поищите в сорцах. Если не заложил - попросите пускай сделает это property.

Тут нужно акцент не на С++ делать а на то что разработка ведется для Windows. Тегнул топик.

Вот ссылочка на DLL-linked ordering. Может будет полезна

https://docs.microsoft.com/en-us/windows/win32/dll...

У нас как-то Windows-NT простояла в работе аж до 2010 года. И ничего.
Главное чтоб МС не заложил туда никакоую тайм-бобмочку. А так - хоть 100 лет
пускай работает. Я-бы больше смотрел в бюлетень уязвимостей SMB-протокола.
Если ОС не поддерживается то тогда и фиксы не доставляются. А про SMB уязвимости
как-то в youtube говорил один дед по имени КиберДед. Хотя я ему не верю если чесно.

Соревнования и Олимпиады помогают для поступления в университет. Но они они не способствуют поступлению на работу в большую корпорацию. Скорее наоборот. Олимпиадник - опасен и создает проблемы для проектов которые работают по 20-30 лет. Олимпиадник также будет раздражать других командных игроков. Его оценки (эстимации) задач будут слишком отличаться от других. Олимпиадник плохо понимает необходимость эстетики программного кода и SOLID-философии. Дай бох что за 5 лет учебы в университете этот гений слегка поостынет и начнет думать как team-player.

В принципе имеет. Почему нет? Но есть нюансы.

Вот самое слабое утверждение .

"регулярно" пересчитываем хэш найденных сущностей и сравниваем с хэшем сохраннённой sqlite

Регулярно это как? Каждую секунду? Или минуту. Вобщем тут нет единого правильного ответа. Нужно разговаривать с бизнесом и понимать где можне чем пожертвовать. Или точно знать что работаем с архивными данными. Следовательно кеш - вечен. Или работаем со справочником товаров которые обновляются раз в сутки. Тогда обновление или переасчет кеша можно просто привязать к старту системы. И каждый день перегружать ее.
Короче инвалидация кеша - это главная проблема в любых инициативах с кешом.

Далее объем. Надо быть очень удачливым или иметь очень строгое ТЗ чтобы гарантировать что кеш будет иметь разумный объем. Если кеша будет не хватать или он будет в ротации в памяти с другими кешами то вреда от него будет больше чем пользы.

Далее идеология. Может ваша система уже давно переросла реляционку (EAV как признак) и ей просто нужно волевое архитектурное решение. Затащите документную БД. Mongo, CouchDb. Может вам с ней будет проще работать. EAV никогда не была эффективной в смысле скорости.

Лет 10 назад у меня в БД Oracle была такая проблема. Медленно чистились исторические partitions.
Ничего нельзя было придумать. Потом мы заметили что удаляется 99% datarows. После этого пришла
идея - вообще ничего не удалять а просто пересоздавать историчесекий parition с теми datarows
которые НАДО ОСТАВИТЬ. И грохать оригинальный. После такой оптимизации мы ускорились в 1000 раз. Надо было только сделать exchange partitions (ораклоиды поймут).

Вот так вот.

var token = jsMain["data"][i];
                if (!unique.Contains(token))
                {
                    token.Remove();
                }

Попробуй другую стратегию. Пересоздай новый JSON. С учетом удаленных токенов.

Если это - бизнес факты и таблица - PARTITION BY RANGE по дате - то можно суммировать только за последний день. Ну и предыдущие - просто хранить как результат суммы.

Вот как-то так. Возможно некрасиво.

>>> dict = {
  ...   "a": "1",
  ...   "b": "2",
  ...   "dict2": {
  ...     "c": "3",
  ...     "d": "4",
  ...   }
  ... }
  >>> 
  >>> for i in dict:
  ...   print(type(dict[i]))
  ... 
  <class 'str'>
  <class 'str'>
  <class 'dict'>