mayton2019

Есть коробочное решение. Работа только на удаленных десктопах. Clean room. Ограниченный десктоп. Там только одно приложение. Это собственно клиент к удалённому. На десктопах демонтированы все usb слоты.

Для мультипоточных систем самый лучший дизайн concurrency - это уменьшение concurrency. Есть разные способы уменьшения этого. Простое правило - это хеширование. Вычисляем хеш от урла. И берем остаток от деления на количество workers. Число в результате - сообщит нам номер воркера который будет эти линки обрабатывать. Другие воркеры будут чужие линки игнорировать.

Самое главное - разбираться в проекте. Читать его баг-трекер и понимать потребности и над чем работает сообщество. Я как-то пытался стать контрибутором apache ignite но не вышло. Времени не хватало. А потребности были со стороны нашего проекта.

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

Техническая сторона не особо важна. Главное что у вас есть ценный merge-request который нечто исправляет и это НЕЧТО очень нужно в мире.

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

В конце стоит цель - трудоустроится в какую-то компанию. У компании есть свой техностек. Свои вакансии. Вот берите сайт местных объявлений и смотрте какие ключевые слова там пишут. Например 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 есть тоже свой тип строк.