mayton2019

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

У багов есть разный impact. Или степень влияния на качество продукта. Вот какое влияние сдвинутых иконок?
Я думаю их увидели только жители стран которые используют перевод с английского и этот перевод оказался на несколько символов длинее оригинала из-за чего произошел развал дизайна. Можно сказать что аудитория некоторых стран ощутила легкое неудобство.

Тоесть impact - так себе.

А что будет если программист 3Д графики допустил ошибку, которая приводит к крашу игры? Тут влияние посильнее. Я-бы сказал что это провал релиза. Как такое пропустили тестировщики (автоматизаторы или ручники) неважно) - ХЗ. Но тут важно срочно бежать в студию и выкладывать на steam экстренное обновление игры. И счет идет не на недели а на считанные дни. Кое-кому из отдела разработки и тестирования придется провести несколько безсонных ночей перед багфиксом.

Вот в этом и есть практический смыл тестирования. Тестировать важные части логики.

DVI-D - это морально устаревший стандарт. И его стоит брать только для железа которое уже не будет модернизироваться. Кроме того у DVI-D есть ограничения по разрешению видео. Посмотрие в технических описаниях стандарта.

Вам надо в git складывать не бэкапы Sqlite а текстовое представление wiki по состоянию на сегодняшний день. Насколько я помню там есть
свой язык форматирования типа markup. Так что все будет норм.

Нашел информацию, что sqlite не поддерживает многопоточность.

Это не проблема для твоего приложения. Обеспечивай синхронизацию на уровне python и работай короткими
операциями (OLTP). insert/update по одной строчке.

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

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

В Scala есть object - это уже готовый синглтон из коробки поэтому необходимости в следовании паттерну уже вроде как нет.

Как BLOB.

Есть простейший запрос SELECT * from Table.
...
Реально ли как-то ускорить в этом случае?

Есть много мест в application где может что-то замедлятся . И это не обязательно SQL. Это может
быть веб-приложение, которое медленно отрисовывает таблицу. Или это может быть сетевой канал
который медленно отдает данные. Чтоб заниматься оптимизацией - нужно точно-точно знать где
оптимизировать. Или это будут зря потраченные усилия. Кроме того для UI например важно
получение 1 page вместо того чтобы загружать миллиард строк. Поэтому нужно знать какой %
результата выборки вы хотите использовать сразу (сию секунду) после получения и что
можно отложить на потом. Мой опыт подсказывает что пользователь вообще не воспринимает
информацию больше чем 1 абзац текста. Поэтому разгонять UI для отдачи миллиарда строк
нет никакого смысла.

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

Держи всегда файл открытым. Если это для Windows - то пользователю не запрещается открывать его на ЧТЕНИЕ в текстовом редакторе в этот момент.

И не забудь добавить ротацию логов там по минутам или часам или суткам. Чтоб не было 1 файла в петабайт.
Такой точно нигде не откроешь.

может вырасти вычислительная нагрузка

Какие-то непонятные страхи. Что там куда вырастет? Я не вижу в работе логгера вычислительной нагрузки.
Давай чтоб-не было в вопросе всяких метафор типа "безболезненно", "прелестно".... и так далее - дай
цифры. Сколько будет записей в день. Сколько на пике в секунду. Как часто пользователь будет лог
открывать. Что он будет с ним делать? Будет ли редактировать(!) ?

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

id name     path  parent
-----------------------
1  Беларусь 1     null
2  Россия   2     null
3  Минск    1.3   1
4  Москва   2.4   2
5  СПБ      2.5   2
6  Невский  2.5.6 5

Ну а дальше - select... connect prior и получим ранжированый курсор по дереву. Там-же будет
доступно виртуальное поле level. И обходом этого курсора можно сделать JSON документ.
Если level растет - то увеличиваем indentation и открываем вложенный элемент соотв.

Если go-lang поддерживает stremable json writers то даже лучше.

Смотрю ролики по программированию. Заинтересовали ролики Немчинского (хотя некоторые вещи он объясняет крайне непонятно для новичка).

Немчинский - популист и популяризатор своей собственной it-школы. Обычно в каждом видосе - реклама.

У него есть контр-образовательная позиция. Он например считает что после 1 курса универа надо сразу идти работать и наплевать на диплом вообще.

Во многих роликах Немчинский говорит, что надо использовать классы через интерфейсы.
....
У меня есть класс 1, в нем есть методы. Класс 1 используется в классе 2. Зачем интерфейс?

Не смотрел видео. Но в этом вобщем-то есть смысл для создания слабой зацепленности и InversionOfConrol.
Новичку такое объяснить нельзя. Нужны месяцы и годы чтобы понять. Желательно не на синтетических
уроках а на реальных боевых проектах где МНОГО кода. Именно обилие кода и требование проводить
сложны рефакторинги, замены движков одни на другие и цикл постоянной доработки - мотивируют к
внедрению базовых интерфейсов вместо классов.

То что ты не понял с 1 раза - это нормально. Я тоже когда изучал ооп и полиморфизм на примере Borland Pascal
тоже подумал что это туфта и я это использовать никогда не буду ибо незачем.

Можно привести пример на php и показать выгоду такого подхода?

Тут я не уверен. Вроде в PHP OOP есть с 5 версии. А есть ли там механики полиморфизма - ХЗ.
Пускай знающие прокоментируют. Но если есть - то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.
В идеале у вас переключение должно произойти в 1 строчке кода. Если удалось - значит
метод работает.

Тут Spark не имеет никаких преимуществ перед обычным приложением. Скорее всего чтение из json не распараллелится. Такой он вредный json.

Попробуй просто выкачать json через hdfs tools и толкнуть его в кликхаус обычным java или python ротложннием. И jdbc лучше не использовать. Если у кликхауса есть другой API то бери его. Будет быстрее чем jdbc.

Делать его бином тоже как-то не хочется

Не совсем понятно почему не хочется. Экономишь память? Или время иниализации бина?

У тебя проблема вовсе не в Spring. Здесь если убрать Spring за скобки - то ты также будешь ломать
голову над тем как разложить твои данные по методам.

Попробуй реши эту задачу вообще без Spring. Будет простое ООП-решение. Вот затащи его потом
в Spring и вопрос сам собой решится.

Рекурсия нужна при обработке иерархических данных. Например - обойти файлы и каталоги
в файловой системе и выполнить какое-то действие. Или действие с условием. Например если
в текущем фолдере есть фолдер .git - то выполнить какой-то git script.

Рекурсия может понадобиться при работе с документами XML/JSon (шаблон composer). И хотя
в некоторых API рекурсия может быть частично скрыта за языками XPath/JSonPath тем не меннее
ее рекурсивная природа остается налицо. Кроме того если вам достался узкий API типа DomDocument
без поисковых диалектов - то обойти его можно на любом ЯП с рекурсивной функцией.

Рекурсия нужна при парсинге сайтов. Это вобщем просто более расширенная трактовка работы с файловой
системой. Если Url-s это как-бы файлы в web пространстве и они имеют ссылки друг на друга - то вы
можете рекурсией это все обходить.

Рекурсия почти всегда нужна при работе с графами. Берите любой алгорим на теорию графов и я готов
спорить что 99% он будет содержать рекурсию.

Все настольные игры (шахматы-шашки) в основе своего алгоритма альфа-бета поиска с отсечениями и
BWF базируются на рекурсии.

Tar и gzip это очень старые утилиты. Им по 30-40 лет. И создавались они в те времена когда симметричное шифрование еще не было так развито.

Но архивчик можно после упаковки зашифровать другими утилитами например openssl.

openssl enc -in file.txt -out encypted_file.txt -e -aes256

Я так делал когда шифровал бекапы oracle dbms.

Если переписать чуть лучше скрипт - то можно объединить операции tar->gzip->openssl в один пайплайн
без воздания промежуточных файлов.

Попробуй замени any на bytes.
map<string,bytes> property = 1;

Это скорее всего неправильно.

SELECT  name, number_plate, violation
FROM fine
GROUP BY name, number_plate, violation
HAVING count(*) > 1

если используется GROUP BY то в выражении SELECT должна стоять функция агрегации (count в данном случае)

Среди недостатков литий-ионных аккумуляторов также есть чувствительность к холоду. Возможно ноутбук промерзал.

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

И на качество самого аккумулятора влияет качество лития. Тут надо смотреть что за завод его делал. Из чего. Но тут я не спец. Нужны химики.

Здесь правда подходит любой алгоритм генерации лабиринтов с одним условием. Беря во внимание полярные координаты, ширина проходов в центральной части лабиринта должна быть примерно соизмерима с шириной проходов у края круга. Этого нельзя добиться просто заменив один прямоугольник на боковую поверхность цилиндра (бублика). Нужна коррекция. Корреция с учотом дистанции к центру этого бублика.

Это мне кажется интересная часть задачи которую можно обсудить. Остальное - уже решено.