Удобство - дело очень индивидуальное! Но мышь Razer Naga V2 Pro интересна именно тем - что у неё эта боковая панель сменная - и в комплекте из 3 штуки - с разным количеством и расположением кнопок!
Ошибочные нажатия - при чётком разделении положения кнопок - это скорее дело практики - наработки механической памяти (особенно если ещё и кнопки будут на ощупь заметно отличаться)! Ну и если и будут ошибочные нажатия - то если на этих кнопках будут команды, которые не будут вести к прямому изменению ключевого состояния управляемой системы и не будут необратимыми - желательно "исправление ошибки" - просто нажатием правильной кнопки - то это вообще не шибко большая проблема!
Но лично я бы предложил размещать кнопки сверху мышки - либо сенсорными - либо полусенсорыными - углублёнными - либо вообще делать спинку мышки тачскрин экраном (привет Артём Лебедев - правда у него это были клавиши на клавиатуре) в виде изогнутого дисплея (привет Самсунг и Лыжа).
И класть руку ладонью на эти кнопки - а чтобы они не нажимались - сделать 4-5 сенсоров нахождения ладони на мышки + программную настройку чувствительных зон! То есть - для пользованиям этими кнопками - ладонь нудно будет либо снимать, либо приподымать - чтобы датчики зафиксировали отсутствие ладони на кнопках - и разблокировали их. Но кисть руки убирать не нужно - и можно достаточно быстро нажать нужную кнопку пальцем! После чего можно быстро вернуть ладонь на мышь - и кнопки тут же заблокируются!
Это не супер идеальное решение - скорее на любителя - но оно оригинальное!
С тачскрин экраном ну или просто с тачпадом на спинке мышки - идея очень хорошо могла бы зайти компании Эппл - с ей однокнопочными мышками! Ведь тут можно не просто кнопки нажимать - тут можно и работать именно с тачпадом - а так же распознавать разные жесты, щелчки и постукивания! В общем - идея 100% тянет на патент!
С Вами соглашусь в том, что будущее за декларативными языками программирования! Но... вот визуализациям им, средство ввода исходника, нафиг не нужна будет - хотя... как некоторое подспорье в ряде случаев - будет полезно - но только как вспомогательный инструмент - условно когда надо глянуть на итоговую схему, прогнать тесты и отладку, быстро переключить какие-то оптации!
Но, всё же - основной код буду набирать и редактировать в текстовом представлении! Причём декларативность тут позволяет писать его очень абстрактно, разбрасывать по куче мест - и потом всё это будет собираться вместе - а итоговый код строиться на основе статической интерпретации всего этого декларативного и макро описания!
Этот пункт - дополнение к 1. Более менее простую визуальную схему нарисовать достаточно легко. Но - как только начнёт расти количество элементов - первое с чем все сталкиваются - это как размещать это всё на плоскости и как размещать связи между бллками. Это реально очень большая проблема - когда рисуются комплексные схемы - банально - как это всё структурировать на 2D, квази 3D, настоящем 3D. Спросите любого схемотехника - для него это головная боль. Да, для рисования, условно, электрических схем есть продвинутые IDE - помогающие с эффективным расположением элементов - но не решающие эту проблему. А схемы чертят уже очень давно... Но даже если Вы всё эффективно разместите - и тут нате... нужен рефакторинг, ну или просто изменения в логике алгоритма - и даже пусть продвинутая IDE вам позволит технически (это уже другая проблема - см. п.1) быстро изменить логику - но свою красивую визуализацию Вы тут же поломаете - и всё придётся ровнять заново! С текстами всё проще - есть несколько прямых рекомендаций и правил а-ля "чистый код" - но даже если их соблюдать - условно тексты просто структурируются сверху вниз - иногда немного вправо - и всё. Да тут тоже есть свои нюансы и недостатки восприятия 0 но современные IDE активно пытаются их решать! И здесь есть ещё что совершенствовать и куда развиваться!
Повторное использование кода, сборка комплексных элементов из отдельных модулей, файлов, да и просто разных частей - расположенных в разных местах - это всё реалии современности - код перестал быть строго линейным - он может быть разбросан по проекту, по библиотекам проекта - и собираться по кусакам (пример - да хоть частичные классы, или методы, вынесенные за пределы определения структуры класса), а изначальна описываться очень абстрактно. Текстовое представление отлично к этому приспособлено. А вот у графического тут явно будут большие проблемы именно на стадии исходника - конечно представить уже собранное решение графически будет уж "не так сложно" (но см. пункт 8.), Так же и обратное - декомпозировать сложный текст - не так уж сложно - декомпозировать сложное визуальное представление - это кошмар...
Сейчас разработкой рулит Git ну или в общем случае - версионирование кода - со всеми инструментами сравнения, объединения, пул-реквестов и веток. И для текстового представления всё это подходит отлично! А вот с графическим представлением будет большая жоп.... Особенно кода решение в итоге собирается из нескольких источников и так же из нескольких источников обновляется... Я не говорю о том, что для графической визуализации проводить сравнение и мердж невозможно - тут могут быть и свою интересные фишки - но проблем, всё-равно, будет куда больше, чем с текстами...
Поэтому сейчас наоборот - в разработке есть обратная тенденция - там где раньше рисовали схемы визуальными средствами - сейчас переходят на текстовый кодинг. Начиная от UML XML и до DocHub. Да хоть посмотрите и формат векторных изображений SCV.
И я сейчас, порисовав некоторое время кучу схем визуальными средствами - уже видеть все этм редакторы не могу - это просто убожество - и хочу далее рисовать схемы только текстом! То же и про векторную графику - дайте мне лучше редактор с командами для рисования графических элементов!
То же и про UI формы: XAML, Jet compose, Swift UI, Flatter - Это всё прекрасно (хотя синтаксис я бы ещё существенно доработал бы - и с текстами провести такие доработки, в т.ч. переписав компиляторы, будет провернуть куда проще, чем с графическими системами)!
Отдельно замечу про... устный ввод! Вроде бы есть тенденция к возможности реализации ввода программного устным набором - начитка! Лично я не сторонник такого подхода (хотя устный ввод может быть хорошим подспорьем для рефакторинга и управления прочим инструментарием IDE). Но я считаю так - что при устном вводе (и тем более при вводе силой мысли) грань между способом текстового кодирования и визуального рисования уже сильно стирается (с учётом конечно несколько разных техник команд общения и очень продвинутой IDE, которая эффективно будет решать проблемы восприятия и авто визуализации). При этом со стороны наблюдать за графическим представление отчасти может быть даже удобнее чем за текстовым! Но... до этого ещё очень далеко - и, лично мой мнение, что бы так не вводилось - текст или визуальные схемы - это всё-равно будет менее эффективно - чем прямою ввод руками с клавиатуры (или как-то ещё иначе - но с точным преобразование механики нервных импульсов к текстовый поток); и тем более - если такой символьный поток ещё и параллельно дополнить вербальными командами лица, для управление IDE и интеллектуальным помощником ввода!
Визуальное программирование как полностью самостоятельное направление вряд ли когда-нибудь взлетит. На то есть несколько причин:
Так уже исторически сложилось, что людям проще работать с текстами и под это активно затачивались все текстовые процессоры и IDE - читать и вводить буквы просто проще, как и выполнять разные операции над текстами. Да - визуализация как бы считается более лёгкой для восприятии - но об этом ниже. Да - можно попробовать создать удобную и очень продвинутую IDE и натаскать на неё человека - но уверен сложность такой среды будет куда выше чем у текстового процессора! Хотя, может и удастся с ней работать хорошо натасканному специалисту достаточно просто!
Компьютерным алгоритмам так же куда проще работать именно с текстовым преставлением - и тут вообще ничего не изменится. Кроме того - роль автоматизированной обработки текстов с каждым десятилетием будет расти и расти!
С текущими средствами ввода и манипулирования данными - человеку куда проще вводить данные (алгоритмы) с клавиатуры, чем, скажем, мышью. Вот когда разработают что-то более продвинутое для ввода - может что-то и изменится. Но даже силой мысли или в VR оперировать текстами, мне кажется, по-прежнему будет проще...
Действительно, визуализация очень хорошо может восприниматься человеком... но.... только до определённого уровня сложности - затем происходит перелом и обратный процесс - восприятие резко падает. И все попытки разбивать визуализацию на кластеры детализации только усложняют детальный анализ. Да - сложные тексты тоже бывает очень непросто анализировать и воспринимать. Но тут есть методики по их написанию и средства упрощения их преставления и анализа, и ориентирования по таким текстам - и они хорошо работают!
Визуализация алгоритмов только может стать хорошим подспорьем в стандартных текстовых IDE как отдельный инструмент - либо для простых алгоритмов и новичков, либо как дополнительное средство анализа кода - например при поиске ошибок - т.к. позволяет эффективно визуализировать движение по коду в динамике, в т.ч. в виде активной схемы в реальном времени выполнения!
Так же визуализация может быть удобна для ряд узких задач программирования или для представления данных: это нейросети и какой-либо кластерный анализ
Ну или... простите код писать лень. Только общая идея:
Имеем таблицу со свободными номерами некоторого количества (не принципиально, но заведомо больше чем максимум потребляется за период её обновления), номера упорядочены по кластерному индексу (по возрастанию для определённости).
Когда нужен номер - берём первый меньший номер и удаляем строку с ним. Тут есть нюанс - мы должны делать такое чтение с уровне изоляции READ_UNCOMMITTED - чтобы не блокироваться на незавершённых транзакциях. Возможно для этого потребуется отельное соединение с СУБД для организации отдельного уровня изоляции транзакции (но PostreeSQL такой уровень изоляции не поддерживает - но там есть обходные пути)
Периодически добавляем в таблицу новые строки с новыми номерами от максимально до заданного количества
Я как раз пометил - что только для случая когда не требуется строгая упорядоченность, а только уникальность, ну или ещё не строгая, но общая упорядоченность - это большинство случаев
Отстёгивать батарею имеет смысл только если под ней есть резервуар с водой.... прочем в движении в этом некоторый смысл тоже есть - всё-таки машина сзади тоже под батарее не остановится - а потом все уже объезжать будут горящую хреновину!
Нет смысла всю машину погружать - это очень сложно - достаточно - чтобы в погребок падала только одна батарея из под днища машины - и прим на ранней стадии возгорания - тут автоматика должна работать (ну ручной режим тоже надо предусмотреть). А саму обесточенную машину уже тушить огнетушителем - кстати, в идеале, тоже встроенным - из под "земли" снизу вверх направлять струю - прямо в туда - где ранее загорелась батарея!
Вот поэтому я написал - что процесс внешнего тушения электричек сложный - но это не значит, что его не надо решать - это инженерная задача! Как вариант - нужен способ быстро изъять батарею от автомобиля - и да - быстро поместить её в резервуар с водой - в изъятом виде это будет проще - скорее резервуар с водой надо сразу обустраивать под автомобилем - а батарея должна легко отстёгиваться - и падать в этот резервуар из под днища - вместе с защитой днища!
Само собой надо решать и задачу предотвращения возгорания или самотушения - когда батарею будет тушить сам автомобиль или сама де батарея - кстати, недавно прочитал про такой материал из которого предлагается изготавливать корпус батареи - который при высоком нагреве высвобождает воду которая сразу тушит батарею - на ранней стадии возгорания!
Это это всё лишь варианты - тут думать надо - а пока все болт на это забили!
Закажите себе на днюху такой необычный подарок (если для одного дорого такой подарок делать - то можно подарок и в складчину сделать - в этом преимущество подарков от гостей) - идею все оценят
Кстати клавы у Penguin Ambidextrous - тоже очень прикольные!
Как замена клавиатуре - решение вообще никакое - вернее очень специфическое - только под узкий перечень задач подойдёт.
Как мышь - оценить не пробуя очень сложно.... может и прокатило бы - но только если есть ещё и полноценная клава - для тех, кому данного обрезка будет маловато. И не понятно - если обе половники управляют мышью - одним и тем же курсором - просто параллельно передавая смещения и устраняя конфликты - когда двигаются обе половники - как просто два манипулятора мыши?
Но стрелочек управления курсором будет очень нахватать при любом использовании!
Нет я такого не предлагал - когда получать XID решать только алгоритму
Удобство - дело очень индивидуальное! Но мышь Razer Naga V2 Pro интересна именно тем - что у неё эта боковая панель сменная - и в комплекте из 3 штуки - с разным количеством и расположением кнопок!
Ошибочные нажатия - при чётком разделении положения кнопок - это скорее дело практики - наработки механической памяти (особенно если ещё и кнопки будут на ощупь заметно отличаться)! Ну и если и будут ошибочные нажатия - то если на этих кнопках будут команды, которые не будут вести к прямому изменению ключевого состояния управляемой системы и не будут необратимыми - желательно "исправление ошибки" - просто нажатием правильной кнопки - то это вообще не шибко большая проблема!
Но лично я бы предложил размещать кнопки сверху мышки - либо сенсорными - либо полусенсорыными - углублёнными - либо вообще делать спинку мышки тачскрин экраном (привет Артём Лебедев - правда у него это были клавиши на клавиатуре) в виде изогнутого дисплея (привет Самсунг и Лыжа).
И класть руку ладонью на эти кнопки - а чтобы они не нажимались - сделать 4-5 сенсоров нахождения ладони на мышки + программную настройку чувствительных зон! То есть - для пользованиям этими кнопками - ладонь нудно будет либо снимать, либо приподымать - чтобы датчики зафиксировали отсутствие ладони на кнопках - и разблокировали их. Но кисть руки убирать не нужно - и можно достаточно быстро нажать нужную кнопку пальцем! После чего можно быстро вернуть ладонь на мышь - и кнопки тут же заблокируются!
Это не супер идеальное решение - скорее на любителя - но оно оригинальное!
С тачскрин экраном ну или просто с тачпадом на спинке мышки - идея очень хорошо могла бы зайти компании Эппл - с ей однокнопочными мышками! Ведь тут можно не просто кнопки нажимать - тут можно и работать именно с тачпадом - а так же распознавать разные жесты, щелчки и постукивания! В общем - идея 100% тянет на патент!
С Вами соглашусь в том, что будущее за декларативными языками программирования! Но... вот визуализациям им, средство ввода исходника, нафиг не нужна будет - хотя... как некоторое подспорье в ряде случаев - будет полезно - но только как вспомогательный инструмент - условно когда надо глянуть на итоговую схему, прогнать тесты и отладку, быстро переключить какие-то оптации!
Но, всё же - основной код буду набирать и редактировать в текстовом представлении! Причём декларативность тут позволяет писать его очень абстрактно, разбрасывать по куче мест - и потом всё это будет собираться вместе - а итоговый код строиться на основе статической интерпретации всего этого декларативного и макро описания!
Забыл добавить ещё три очень важных пункта:
Этот пункт - дополнение к 1. Более менее простую визуальную схему нарисовать достаточно легко. Но - как только начнёт расти количество элементов - первое с чем все сталкиваются - это как размещать это всё на плоскости и как размещать связи между бллками. Это реально очень большая проблема - когда рисуются комплексные схемы - банально - как это всё структурировать на 2D, квази 3D, настоящем 3D. Спросите любого схемотехника - для него это головная боль. Да, для рисования, условно, электрических схем есть продвинутые IDE - помогающие с эффективным расположением элементов - но не решающие эту проблему. А схемы чертят уже очень давно...
Но даже если Вы всё эффективно разместите - и тут нате... нужен рефакторинг, ну или просто изменения в логике алгоритма - и даже пусть продвинутая IDE вам позволит технически (это уже другая проблема - см. п.1) быстро изменить логику - но свою красивую визуализацию Вы тут же поломаете - и всё придётся ровнять заново!
С текстами всё проще - есть несколько прямых рекомендаций и правил а-ля "чистый код" - но даже если их соблюдать - условно тексты просто структурируются сверху вниз - иногда немного вправо - и всё. Да тут тоже есть свои нюансы и недостатки восприятия 0 но современные IDE активно пытаются их решать! И здесь есть ещё что совершенствовать и куда развиваться!
Повторное использование кода, сборка комплексных элементов из отдельных модулей, файлов, да и просто разных частей - расположенных в разных местах - это всё реалии современности - код перестал быть строго линейным - он может быть разбросан по проекту, по библиотекам проекта - и собираться по кусакам (пример - да хоть частичные классы, или методы, вынесенные за пределы определения структуры класса), а изначальна описываться очень абстрактно. Текстовое представление отлично к этому приспособлено. А вот у графического тут явно будут большие проблемы именно на стадии исходника - конечно представить уже собранное решение графически будет уж "не так сложно" (но см. пункт 8.),
Так же и обратное - декомпозировать сложный текст - не так уж сложно - декомпозировать сложное визуальное представление - это кошмар...
Сейчас разработкой рулит Git ну или в общем случае - версионирование кода - со всеми инструментами сравнения, объединения, пул-реквестов и веток. И для текстового представления всё это подходит отлично! А вот с графическим представлением будет большая жоп.... Особенно кода решение в итоге собирается из нескольких источников и так же из нескольких источников обновляется... Я не говорю о том, что для графической визуализации проводить сравнение и мердж невозможно - тут могут быть и свою интересные фишки - но проблем, всё-равно, будет куда больше, чем с текстами...
Поэтому сейчас наоборот - в разработке есть обратная тенденция - там где раньше рисовали схемы визуальными средствами - сейчас переходят на текстовый кодинг. Начиная от UML XML и до DocHub. Да хоть посмотрите и формат векторных изображений SCV.
И я сейчас, порисовав некоторое время кучу схем визуальными средствами - уже видеть все этм редакторы не могу - это просто убожество - и хочу далее рисовать схемы только текстом! То же и про векторную графику - дайте мне лучше редактор с командами для рисования графических элементов!
То же и про UI формы: XAML, Jet compose, Swift UI, Flatter - Это всё прекрасно (хотя синтаксис я бы ещё существенно доработал бы - и с текстами провести такие доработки, в т.ч. переписав компиляторы, будет провернуть куда проще, чем с графическими системами)!
Отдельно замечу про... устный ввод! Вроде бы есть тенденция к возможности реализации ввода программного устным набором - начитка! Лично я не сторонник такого подхода (хотя устный ввод может быть хорошим подспорьем для рефакторинга и управления прочим инструментарием IDE). Но я считаю так - что при устном вводе (и тем более при вводе силой мысли) грань между способом текстового кодирования и визуального рисования уже сильно стирается (с учётом конечно несколько разных техник команд общения и очень продвинутой IDE, которая эффективно будет решать проблемы восприятия и авто визуализации). При этом со стороны наблюдать за графическим представление отчасти может быть даже удобнее чем за текстовым! Но... до этого ещё очень далеко - и, лично мой мнение, что бы так не вводилось - текст или визуальные схемы - это всё-равно будет менее эффективно - чем прямою ввод руками с клавиатуры (или как-то ещё иначе - но с точным преобразование механики нервных импульсов к текстовый поток); и тем более - если такой символьный поток ещё и параллельно дополнить вербальными командами лица, для управление IDE и интеллектуальным помощником ввода!
Визуальное программирование как полностью самостоятельное направление вряд ли когда-нибудь взлетит. На то есть несколько причин:
Так уже исторически сложилось, что людям проще работать с текстами и под это активно затачивались все текстовые процессоры и IDE - читать и вводить буквы просто проще, как и выполнять разные операции над текстами. Да - визуализация как бы считается более лёгкой для восприятии - но об этом ниже. Да - можно попробовать создать удобную и очень продвинутую IDE и натаскать на неё человека - но уверен сложность такой среды будет куда выше чем у текстового процессора! Хотя, может и удастся с ней работать хорошо натасканному специалисту достаточно просто!
Компьютерным алгоритмам так же куда проще работать именно с текстовым преставлением - и тут вообще ничего не изменится. Кроме того - роль автоматизированной обработки текстов с каждым десятилетием будет расти и расти!
С текущими средствами ввода и манипулирования данными - человеку куда проще вводить данные (алгоритмы) с клавиатуры, чем, скажем, мышью. Вот когда разработают что-то более продвинутое для ввода - может что-то и изменится. Но даже силой мысли или в VR оперировать текстами, мне кажется, по-прежнему будет проще...
Действительно, визуализация очень хорошо может восприниматься человеком... но.... только до определённого уровня сложности - затем происходит перелом и обратный процесс - восприятие резко падает. И все попытки разбивать визуализацию на кластеры детализации только усложняют детальный анализ. Да - сложные тексты тоже бывает очень непросто анализировать и воспринимать. Но тут есть методики по их написанию и средства упрощения их преставления и анализа, и ориентирования по таким текстам - и они хорошо работают!
Визуализация алгоритмов только может стать хорошим подспорьем в стандартных текстовых IDE как отдельный инструмент - либо для простых алгоритмов и новичков, либо как дополнительное средство анализа кода - например при поиске ошибок - т.к. позволяет эффективно визуализировать движение по коду в динамике, в т.ч. в виде активной схемы в реальном времени выполнения!
Так же визуализация может быть удобна для ряд узких задач программирования или для представления данных: это нейросети и какой-либо кластерный анализ
Последовательности не катят?
Или тип SERIAL?
Ну или... простите код писать лень. Только общая идея:
Имеем таблицу со свободными номерами некоторого количества (не принципиально, но заведомо больше чем максимум потребляется за период её обновления), номера упорядочены по кластерному индексу (по возрастанию для определённости).
Когда нужен номер - берём первый меньший номер и удаляем строку с ним. Тут есть нюанс - мы должны делать такое чтение с уровне изоляции READ_UNCOMMITTED - чтобы не блокироваться на незавершённых транзакциях. Возможно для этого потребуется отельное соединение с СУБД для организации отдельного уровня изоляции транзакции (но PostreeSQL такой уровень изоляции не поддерживает - но там есть обходные пути)
Периодически добавляем в таблицу новые строки с новыми номерами от максимально до заданного количества
Но хлопнул там как раз-таки газ - привет газпрому!
Нужно больше кнопок - Razer Naga V2 Pro
Я как раз пометил - что только для случая когда не требуется строгая упорядоченность, а только уникальность, ну или ещё не строгая, но общая упорядоченность - это большинство случаев
Как слегка передержанный - оттого и подгоревший
Все ваши примеры понятно - но это всё уже из "другой оперы" - условно не рядовой процесс или неизбежность для всех случаев!
Тем что ключевые клавиши все вкучу - тяжело не промахиваться по соседним - но привыкнуть ко всему можно
Да - в Махачкале не так давно знатно так хлопнуло!
Это всё чисто инженерные проблемы - всё решаемо
Отстёгивать батарею имеет смысл только если под ней есть резервуар с водой.... прочем в движении в этом некоторый смысл тоже есть - всё-таки машина сзади тоже под батарее не остановится - а потом все уже объезжать будут горящую хреновину!
Нет смысла автоматически отстёгивать - если нет внизу резервуара с водой!
Нет смысла всю машину погружать - это очень сложно - достаточно - чтобы в погребок падала только одна батарея из под днища машины - и прим на ранней стадии возгорания - тут автоматика должна работать (ну ручной режим тоже надо предусмотреть). А саму обесточенную машину уже тушить огнетушителем - кстати, в идеале, тоже встроенным - из под "земли" снизу вверх направлять струю - прямо в туда - где ранее загорелась батарея!
Вот поэтому я написал - что процесс внешнего тушения электричек сложный - но это не значит, что его не надо решать - это инженерная задача! Как вариант - нужен способ быстро изъять батарею от автомобиля - и да - быстро поместить её в резервуар с водой - в изъятом виде это будет проще - скорее резервуар с водой надо сразу обустраивать под автомобилем - а батарея должна легко отстёгиваться - и падать в этот резервуар из под днища - вместе с защитой днища!
Само собой надо решать и задачу предотвращения возгорания или самотушения - когда батарею будет тушить сам автомобиль или сама де батарея - кстати, недавно прочитал про такой материал из которого предлагается изготавливать корпус батареи - который при высоком нагреве высвобождает воду которая сразу тушит батарею - на ранней стадии возгорания!
Это это всё лишь варианты - тут думать надо - а пока все болт на это забили!
Выдвижная подставка - зло!
Закажите себе на днюху такой необычный подарок (если для одного дорого такой подарок делать - то можно подарок и в складчину сделать - в этом преимущество подарков от гостей) - идею все оценят
Кстати клавы у Penguin Ambidextrous - тоже очень прикольные!
Как замена клавиатуре - решение вообще никакое - вернее очень специфическое - только под узкий перечень задач подойдёт.
Как мышь - оценить не пробуя очень сложно.... может и прокатило бы - но только если есть ещё и полноценная клава - для тех, кому данного обрезка будет маловато. И не понятно - если обе половники управляют мышью - одним и тем же курсором - просто параллельно передавая смещения и устраняя конфликты - когда двигаются обе половники - как просто два манипулятора мыши?
Но стрелочек управления курсором будет очень нахватать при любом использовании!