mayton2019

Так не делается. Языки не учат для комплекта.

В конце стоит цель - трудоустроится в какую-то компанию. У компании есть свой техностек. Свои вакансии. Вот берите сайт местных объявлений и смотрте какие ключевые слова там пишут. Например Python-Kubernetes-DevOps-Ansible. Или Databricks-Oracle-SQL-Python.

Попробуйте для всех объектов сцены изменить масштаб. Например у вас было в метрах. Сделайте в километрах.

Вот
rsync .... --delete

Очень странно конечно ставить такую задачу как "наковырять хоть что нибудь". Как из говна собрать сливки. Прошу прощения за мой французский.

По делу.

Мне кажется что в таком виде как написано

В последующем посещала

данные не годятся для обучения.

А чтобы они годились - нужно сеть и вручную проанализировать какие признаки (features вообще у нас есть).
Например если есть температура - это вещественное значение. Если есть болезнь - и всего возможно 300 болезней то мы заводим 300 полей вещественного типа и заполняем их 1.0 если выявлен признак. А для всех других 299 ставим 0.0.

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

По поводу умного авто-дополнения я вообще не могу ничего сказать. Непонятно.

Приведите пример хотя-бы на эти данных.

Функция CreateProcess

Если ты используешь Windows и С++ то тебе в первую очередь надо изучить какой API предоставляет ОС а уже потом язык.

Вот пример как вызвать внешний процесс и ожидать завершения.

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

Кроме того. Ты должен не просто ждать завершения процесса но и взять код возврата. По нему определяется был ли успех или ошибка. Кроме того процесс возрващает 2 стрима. STDOUT, STDERR для детализации ошибок. Почитаешь сам по этому.

А вот отсюда ты должен был начать поиски

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

Насчет system не уверен. Это функция ОС Unix/Linux и ее вызов в Винде скорее всего будет просто обёрткой над CreateProcess. И какой там контроль над параметрами - чорт его знает. Наверное лучше брать native.

Можно в таблице пользователей (users) завести поле счетчика. Только работать с ним в транзакции обязательно.

Вывод на экран через print(..) может нарушить временнУю картину мира.
Вредная штука этот экран. Блокирующий. Тоже добавит свои погрешности.

Особенно когда 100 потоков что-то пишут в экран может оказаться что все они только
и ждут экрана.

По поводу Java int.

Java создавалась до 1996 года. Это было абсолютное царство 32х разрядных машин. Даже первые Pentium адресовали мало. И никто не думал о том что когда-то разрядная сетка адреса будет удвоена. Тем более что основная целевая архитектура для JVM была микроволновками, кофеварками пультами ДУ и банковскими карточками. Поэтому выбор индекса массива в 32 бита со знаком был норм. Представте что всю память 4G занимает массив целых чисел. И в этом случае достаточно максимального индекса элемента равного 1 073 741 823, больше нет смысла.

По поводу беззнаковости. На битовых операциях signed int ведет себя также как и беззнаковый. Это декларировано на уровне стандарта JVM. Лишь только два логических сдвига различают знаковый бит.

Хотя скажу честно что для меня до сих пор странно иметь компаратор который неверно работает при переполнениях. Конечно хотелось в JVM иметь семантику uint, ulong e.t.c. Есть много величин которые принципиально неотрицательные. Время. Вес. И прочие величины из физики.

раскидал запись в каждую таблицу по функциям

Подобного рода рефакторинги надо сопровождать кодом. Наиболее вероятный вариант - ты создаешь отдельный connection в каждой функции. Так делать не надо. Второй вариант - ты играешся с коллекциями там где нужны курсоры. Третий вариант - транзакции и блокировки но все это надо смотреть в твой код.

Не мучай пожалуйста нас эпистолярным жанром. Давай код в студию едрён-батон...

Да вы просто напишите ее сначала в txt файле. Потом когда будет - не сложно будет посмотреть ее в MarkDown
или PostScript.

Можно посмотреть curses. Там по идее должны быть функции определения размера окна терминала.

Но если пользователь возьмет и мышкой потаскает терминал туда-сюда - то надо как-то обновить ширину и обновить view.

Обычно сборщик обладает свойством генерации архе-типов. Например типичное Scala-akka приложение создается так.
$ sbt new akka/akka-quickstart-scala.g8

Вот вам надо создать такое. Сборщик там или просто генератор - не суть важно. Ваш шаблон - это архе-тип.

Да можно. Но что ты напишешь в резюме? Обычно выделяется какой-то ключевой тег. Например С++ разработчик для геймдева. Это понятно. Или фронт-енд со знанием Angular/React/Node. И рекрутер точно понимает что человек профилирован.

Если распыляться 50 на 50 то на собеседовании ты так и не сможешь ответить все таки на какую позицию идешь. В 2000-е когда я оканчивал универ было модно писать в резюме все подряд. Писали чертовщину. C++/Photoshop/3Dmax/CorelDraw/Сисадмин Unix и еще и паяльником умелец. Тоесть складывалось ощущение что нанимают разнорабочего который и мусор убирает и гипсокартон и плитку...

И ещё хотелось бы понять, почему каждый такой указатель является константой?

Это - тяжелое наследие старых систем. В данном примере ты разбираешся с ASCIIZ-строками. С массивами символов которые завершаются нулем. Такая организация позволяет хранить строки компактно. Маркер const защищает строку от случайного изменения. И правильно делает. От этого больше проблем. Тот формат и тот способ хранения строки вообще не предполагает активных изменений. Особенно с размером. Максимум что можно делать - только читать.

С точки зрения современного бизнес-программирования ASCIIZ строки устарели. Но поскольку этот формат является единственным транспортом который понимает ядро ОС - то его часто можно встретить в исходниках.

Для С++ более удобной строкой является std::string. Его использовать приятнее. И с размерами там веселее.
В легаси исходниках можно встретить причудливые CString (MFC), TString (Borland). Это все разные реализации строк.

Для Qt есть тоже свой тип строк.

Непонятно. Если это одноразовое действие - то можно написать наверное софт который просто вызывает imagemagic и все сделает. Но у вас - сайт. И это должно работать на основе некого процесса верстки контента.
Дизайнер закинул картинку. Дальше она сжалась и создалось штук 5 уровней thumnails для preview. Вот второй сценарий - более интересен к разработке.

Смотри. Обычно реляционная алгебра рассматривает коллекции внутри ячеек как потенциальную проблему. Проблему денормализации. Если скин у тебя это сложный объект с другими свойствами и эти свойства вдруг (!) внезапно обрастают связями с другими сущностями БД - то тогда считается что БД плохо спроектирована. Невозможно отслеживать целостность. Или представь что какой-то скин ты решил удалить из системы. Тебе придется сделать поиск всех коллекций всех плееров и поискать его и удалить. И те-же проблемы с вставкой и обновлением.

Но если ты никогда этого не будешь делать и тебе плевать на реляционные связи от скинов к другим элементам системы - то тогда можешь хранить в JSON. MySQL его поддерживает в угоду современным трендами на NoSQL.

Хотя тема NoSQL - гораздо более обширная и сложная чем просто денормализация. Про нее можно говорить часами.

Немного бухгалтерии. Если взять по максимуму.

Размер одной записи должен быть порядка 60 + 32 +8 = 100 символов (байт для простоты)

При 50 млрд записей объем хранимых данных должен быть порядка

50 000 000 000 * 100 = 5 000 000 000 000 = 5 триллионов байт.

В дисковом хранении это будет примерно 4.5 терабайта. Задачка для in-memory неподъемная. Нужен диск + мемори.

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

Вобщем нужна дисковая БД которая встраивается в приложение. На требование менеджеров которые запретили использовать БД забейте. Они ничего не понимают. Делайте БД встраиваемую в приложение. В качестве таких (встраиваемых систем можно поробовать) LevelDb, BerkeleyDb, RocksDb. Они поддерживают индекс класса B+Tree и это даст возможность искать группы записей по одному ID. Для этого класса систем любую запись можно найти за 4-5 дисковых IOPS. Если какдый IOPS стоит 15 мс (это я так мерял свой собственный магнитный HDD) то любой поиск группы ключей для TTFB будет порядка 15 * 5 = 75 милисекунд. Ну если вы поставите SSD - то быстрее.

По поводу предложений хранить в файлах. До того как обсуждать это - надо уяснить требования по времени отклика. Сколько секунд вы согласны ждать - насколько можно и партицировать (или шардировать ваш файл).
В простейшем случае мы делим большой CSV файл на 512 partitions по хешу от ID и получаем соотв время фулл-скана всего файла поделенное на 512. Дальше - играйтесь с этим параметром партишенинга выводя его на доступный уровень отклика. Из недостатков - будет россыпь файлов. Надо почиать документацию на вашу файловую систему (ext4?) и тюнить ее так чтоб она не сдохла от такого числа inodes.

Я поддержу оба сценария. И с встраиваемой БД и с файлами. Но с БД надежнее т.к. есть транзакции а файлы у вас могут быть в крешнутом состоянии долго. И вы об этом ничего знать не будете.

По поводу Parquet. Не взлетит. Скорее всего индекс по данному типу файла - это совсем не то что вкладывают туда релационные системы. Обычно Parquet/Orc/Delta вкладывают в индекс смысл - отбрасывания тех полосок данных (stripes) которые бесполезны при чтении всего файла. Такой индес - обычно просто либо range-признак либо карта Блума. И в случае с range - дает эффект на сортированных данных. Для прочих - будет бесполезно т.к. фулл-скан все равно обеспечен. А если фулл-скан то зачем тогда вообще индекс.

Вобщем для дизайна архитектуры нам нужны цифры. Средние длины по колонкам. И я-бы еще запросил кардинальность по полю ID.

С 2005 года достигнут инженерный предел наращивания тактовой частоты. Грубо говоря, современные инфосистемы отказались от движения в ту сторону. Поэтому вопрос поставлен некорректно.

Не что важно. А что мы вообще можем сделать в этой ситуации.