Пусть пишет все в словарь а в конце работы скидывает в БД.
Я-бы отдавал предпочтение максимально простым решениям. А мультипоточка здесь просто автора похоронит своей сложностью. Ее кстати реально сложно тестировать.
Тут нечего обсуждать. Напиши хотя-бы 3-4 тестовых кейса где есть точно решение - берем или не берем это имя.
А код написать уже будет дело техники. И регулярки здесь не очень нужны. Диапазоны символов для языков - будут более удобны.
Иван Четчасов, ну чел. Тут тебе никто не поможет. Во первых только ты знаешь какая часть back-buffer обновляется. Во вторых зачем тебе фрейм-рейт если ты не делаешь игру? Для классического оконного пользователя в вакууме достаточно периода в 100 мс. Вот именно так люди воспринимают информацию.
Dmitrii, мы сейчас додумываем задачу за автора. Я-бы хотел чтобы он в комменатриях прояснил на примере как он себе это видит. Я тоже любитель погрузиться в пучину технических деталей но пока - мало оснований.
За плечами приличный опыт разработки бекенда python.
На счет практик - не знаю. Но тут интересно просто сопоставить разницу между былым опытом и новым.
Во первых Go-Lang это такой гугловый "С++ на минималках" который школьники должны освоить за 14 дней.
Тоесть по идее с освоением инфы не будет проблем. Language я имею в виду. Он - простой.
Из хорошего - есть строгая типизация. Тоесть компиллятор делает чекинг вашего кода глубже чем Пайтон.
И на выходе есть настоящий бинарь. Можно вирусы писать и своей бабушке на ноутбук подкидывать.
Что еще хорошего мне понравилось. Каналы. Как способ коммуникации асинк-функций. Кажется что
в других языках это реализовано через прикладные либы. А в Go - хопа! фича языка.
Роми, честно не помню. Уж лет 20 прошло. Тогда еще в ходу "Амфитон" были. Тоже громкие.
А на импортную технику тогда денег не хватало.
Да. По поводу звукового давления. Вобщем из всех преобразований энергии, звук - это самый тухляк.
Тоесть низкий КПД на выходе. Грубо говоря тратишь много. А если попробуешь обратно собрать звуковые
волны в механический колбеательный процесс (соберешь 10000 микрофонов вокруг) то вряд-ли сможешь
выработать хотя-бы несколько процентов от электрической потраченной. Электрическая кстати еще
в тепло и магнит уходит. И это потери вникуда.
Это разрешение? SCREEN_SIZE = (2560, 1080)
Для экспериментов я-бы сделал пока поменьше. Ну хотя-бы в 2 раза поделить размеры по вертикали и горизонтали.
Иван Четчасов, насколько я помню устройство шариковой мышки, она передавала не абсолютные координаты а относительные. Тоесть сигналы можно было делить на целое число и получать замедление мышки пропорционально.
Как работает современная оптическая мышь - я не знаю. Но надо поискать именно тот старый API который толкает относительные координаты.
Это разные системы.