mayton2019

Во первых хочу заметить что отладка и оптимизация это разные вещи. Отладка - debugging это когда мы step-by-step исполняем императивный код и наблюдаем состояние переменных. Режим отлалки был в PL/SQL но им пользоваться было настолько неудобно что никто из моих коллег никогда его не включал.

Оптимизация производительности - это целая сложная тема. По ней написаны толстые книги. Для каждой БД своя. И вобщем Дмитрий верно сказал. Команда explain - это просто первый шаг к оптимизации. И дальше 100 дорог в 100 направлений. Сис-парамтеры. Индексы. Партишенинг. Хинты. И много много прочего.

Насколько я помню - это использовалось в Hadoop/BigData. Это когда вам надо посчитать допустим среднее значение поля по тера-байтному файлу - вы не скачиваете все данные к себе а вы транслируете логику туда, ближе к нодам-воркерам и они уже расчитывают среднее значение локально в своей сверх-быстрой сети и уже вам отдают результат.

Во фреймворке Spark это скрипт spark-submit. И он как раз это и делает. Передает jar файл с логикой (или python-файл) на узел-координатор.

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

По поводу пикселей и прочее. Их ценность определяется просто зрительской симпатией. Их должно это радовать. Покажите ваши пиксельские работы аудитории.

В современных БД практически нет ограничения на длину строк varchar. А для блобов (BLOB) там специально созданы условия чтоб аттачить толстые файлы произвольного размера.

Когда-то давно реляционные БД ограничивали длину строки varchar. Это было связано с блочной организацией дисковой памяти. Например в Oracle varchar2 был максимум 4000 байт. Потом где-то с 12 релиза его можно растянуть до 32к. Ну а для XML/JSON типов там создается специальное поле которое является просто подтипом BLOB но имеет в виду что лежит например JSON. Констрейнт короче.

Есть специальные dbms такие как Mongo, CouchDb, Tarantool. Они специально создавались под JSON. Обратите на них внимание.

Эта неадекватная транзакция называется "выбросом".

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

Но это не точная методика. Она может случайно убить и нужные транзакции. Поэтому надо внимательно смотреть на данные и проверять.

Есть коробочное решение. Работа только на удаленных десктопах. 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. Есть много величин которые принципиально неотрицательные. Время. Вес. И прочие величины из физики.