Судя по всему, вы просто недостаточно познакомились с ресурсом. Особенно с учётом "решить за 5 минут", да ещё и на бумаге. Для лёгкого уровня – конечно, так и должно быть, если подход понятен. Но для прочих – даже стабильные многократные лидеры турниров не всегда показывают такой результат.
Дело вкуса, выбирайте, что больше нравится.
Вопрос, полагаю, к комментаторам. Свой взгляд я обозначил в начале поста.
Спасибо, актуальное уточнение, как раз жду от представителей сайта разъяснение по нему. А у вас информация из опыта, или это уже где-то обсуждалось? Официальный пост с "for ? more than 300 days" однозначного ответа не даёт, его по-разному трактовать можно.
Харды это, в основном, применение сразу нескольких подходов. В этом и сложность – понять, какая связка требуется для нужного результата, ну и правильно её реализовать, конечно.
Упоминал этот подход, и что я с ним не согласен. Можно-то, конечно, но это для уже хорошо разбирающихся в теме, и которым не нужны все эти планы, учебники, соревнования. Зайти на пару дней, решить десяток хардов и закрыть на год. Но таким пользователям этот материал тогда и не нужен. А для всех остальных этот подход только во вред – либо бросят в раздражении от задач не по силам, либо начнут бездумно копипастить готовые решения. Поэтому я за подход – структурно, последовательно, стабильно, тогда будет и толк.
Среднее даже условно не назову, слишком много факторов. Скажем так: минимально – до 10 минут на все, если задачи совсем не вызывают сложности, но и не однострочники; максимально, соглашусь с позицией сайта, – по 30 минут на задачу + время на разобраться с решением, если самостоятельно так и не вышло, при учёте, что готовое решение понятно. Если нет, тогда стоит отложить такую задачу на потом. Ну а там уже стоит отталкиваться от собственного среднего – увеличивать количество или сложность хотя бы до получаса, если каждый день за 10 минут решается; снижать сложность и читать дополнительные источники по теме, если каждый день на максимуме.
Про аналоги лучше перенаправлю. А в целом, айти-то большой, на одном ресурсе всего, даже пусть только вводного уровня, никогда не найдёте. Тут только про АиСД, и то далеко не весь. По каждой теме ищите специальный ресурс, а лучше несколько.
CamelCase по pep8 не используется ни для переменных, ни для функций. Только для классов. Есть оговорка про mixedCase для поддержки кода, который уже так написан, но это совсем не рекомендация к использованию.
Подчёркивание допустимо не только в качестве префикса, для обозначения приватности, но и как постфикс, в случае, если используется зарезервированное слово (да, лучше выбрать другое наименование, но если сильно нужно, то class_ лучше чем clss).
Константы – в верхнем регистре с подчёркиваниями. Об этом случае тоже стоит упомянуть.
Surround top-level function and class definitions with two blank lines. Method definitions inside a class are surrounded by a single blank line.
// Откуда же "4 пустых строки" в посте?
Длина строки это вообще отдельный холивар. Но стоит сделать скидку на время. Всё-таки в 2001 80 символов – необходимость.
Docstring это не совсем комментарий. Для блока комментариев pep8 говорит о "# " на каждой строке.
When catching exceptions, mention specific exceptions whenever possible instead of using a bare except: clause
"Конфликт имён класса и подкласса", это совсем не про чистый код. Тут одними префиксами не обойтись. Тем более, что ведущие подчёркивания используются не для разрешения конфликта имён.
Извиняюсь за поздний ответ, не пришло сообщение об одобрении комментария.
Да, конечно можно. Можете сгрузить любые данные. Для ваших целей вам нужен лишь метод count_symbols(). Вызываете его на каждый e-mail, сплитнутый по @, выводите результат, или просто смотрите в .db.
Но, возможно, вам и не нужен данный пакет. Он, всё же, предназначен для крупных выборок и корпусов, с наглядным выводом, частными настройками и возможностью дополнения. Для задач обычного подсчёта это всё будет излишним.
Бегло ознакомился, но, как я понял, пока что это относительная новинка для конкретных геймерских клавиатур (или просто они выше в ранжировании выбрались).
Было бы интересно совместить подобные свитчи с разными эргономическими клавиатурами. Ну и, конечно, нужно пробовать, как это ощущается. Хотя звучит отлично.
Всё перечисленное вами доступно. Моё упущение, что не смог правильно описать.
В начале раздела мультиязычности я разделил языковые символы, отличные от базовой письменности, на две категории:
уникальные символы, доступные ко вводу только посредством специального символа;
символы, эквивалентные базовым, дополненным комбинируемой диакритикой. разумеется, нас интересует исключительно графическое отображение
Раздел описывается в два этапа, в которых рассматриваются две ступени поддержки:
базовая возможность ввода;
упрощённая возможность ввода.
В рамках рассмотрения предоставления базовой возможности нас интересуют исключительно графически уникальные символы, так как символы второй категории уже доступны ко вводу посредством комбинируемой диакритики, которая в описываемом проекте покрывает все минимально используемые языки мира. Из подобных уникальных символов и была составлена основа латинских языковых наборов. В основу вошли символы из первых 30 языков, по используемости в интернете. Соответственно, использование данной основы во всех наборах открывает именно базовую возможность ввода для всех этих языков.
Уточнение: Уникальные символы, относящиеся к языкам на более низких позициях, пришлось вынести в отдельные языковые наборы, которые я честно обозначил как "позволяющие", т.к. только они, в рамках проекта, предоставляют доступ к полноценному набору текста на данных языках. К этой категории поддержки относятся только лишь азербайджанский, исландский (в наборе с древнеанглийским) и некоторые африканские языки. В посте я также причислял к этой категории текущий пересмотр казахской латиницы, но сейчас обнаружил, что в апреле текущего года ŋ была заменена на ñ, что меняет категорию поддержки данного языка на "упрощающую", а сам набор требует пересмотра.
–––
Во второй части раздела я рассматривал оптимизацию ввода алфавитных символов, эквивалентных базовым символам с комбинируемой диакритикой, для чего и были составлены все языковые наборы. В них, в части оставшейся после "основы", я расположил подобные "комбинированные" символы в их цельном виде, для упрощённого ввода.
Уточнение: Для некоторых языков, с богатой диакритикой в алфавитных символах, попросту не хватило места, потому пришлось выбрать для их поддержки наиболее используемые и уникальные символы. К этим языкам относится затронутый вами польский, вместе с венгерским, латышским, литовским, чешским и словацким. Сейчас это решение мне не кажется правильным, и стоит пересмотреть поддержку таких языков, пожертвовав охватом "основы" в пользу данных языков.
Но даже на текущий момент польский язык доступен к базовому вводу на 24/31 наборах, благодаря łŁ в "основе", а также имеет собственный частично-упрощающий набор с ąężó, оставляющий на комбинированный ввод только наименее используемые символы, с единственным комбинируемым акутом – ćńśź.
–––
ıİ, также относящийся к "основе", поддерживается во всех наборах, и в базовом виде присутствует именно в виде, противоположном ISO basic Latin. На базовой письменности у нас iI, в языковом блоке ıİ, что покрывает базовую возможность ввода. Дополнительные языковые наборы, относящиеся к языкам, основанным на турецком варианте латиницы, помимо возможностей упрощённого ввода также содержат опциональный переключатель, доступный на данных наборах, который выполняет небольшое перепозиционирование – iİ в буквенной части клавиатуры, ıI в языковом блоке. Работает для наборов турецкого, азербайджанского и казахской латиницы. Таким образом "основа" предоставляет базовую возможность ввода из любого набора, а специальный упрощающий набор оптимизирует ввод, с дополнительным перепозиционированием для большего удобства и согласованности символов разных регистров.
Да, это одна из основных проблем, даже между раскладками одной письменности, не говоря уже о разных, где базовое количество буквенных символов разнится на 20%+ (в случае сравнения кириллица-латиница), из-за чего "нужно" или освобождать позиции в одной, или заполнять пустующие места во второй.
Некоторые буквенно-символьные раскладки подходят к этой проблеме как раз с той позиции, что вы описали в конце – убирают "редкие" буквы из основной части, в угоду вспомогательным символам, по примеру обделённой «ё» в стандартном «йцукене». А в отдельных случаях даже разносят прописные и строчные варианты одной буквы на разные клавиши. Совсем не разделяю этот подход, и вполне понимаю, почему опробованные вами позиционирования не прижились.
Наверное, располагая небуквенные символы в буквенной части, решить эту проблему и не представляется возможным, потому я и пошёл другим путём, который позволяет унифицировать небуквенный ввод.
Дело в том, что из 24 диакритических символов желаемого охвата, лишь немногие представляют интерес как отдельные символы. Седиль ç, диэрезис ӧ, гачек ǒ, и прочие потенциально востребованные диакритические символы в некомбинированном виде будут просто лежать мёртвым грузом. Также возникнет вопрос с расположением – либо переносить все «мёртвые» клавиши в цифровой ряд текущей диакритики, что усложнит доступ к их базовому представлению, по сравнению с текущим видом, особенно к таким как точка или кома, либо располагать их хаотично по всему символьному слою, что совсем не радует. К тому же, комбинируемые символы с вариантами надстрочного и подстрочного написания будут предполагать три варианта охвата – "символ, sup, sub", в то время как символы с единственным вариантом будут вносить сумятицу в это правило.
Конечно, я не предполагал, что кто-либо, кроме профильных специалистов, будет запоминать весь набор диакритики. Она тут расположена "по требованию". К примеру, потенциальному пользователю со знанием эсперанто понадобятся лишь бревис и циркумфлекс, со знанием французского – диэрезис, седиль и циркумфлекс, и так далее. В запоминании позиций 1-3 (крайне редко – 4) диакритических символов, когда они действительно востребованы для конкретного пользователя, нет ничего сложного.
Но я ещё обдумаю, как иначе можно будет удобно применить «мёртвые» клавиши к символьной части.
Кажется, я не так вас понял. Вы говорите об использовании обычной тильды для функции мёртвой клавиши, не комбинируемого символа? В таком виде получится реализовать только часть от всей желаемой диакритики, а разбивать её на две части не хотелось бы. Я изначально подумал просто об опциональном инвертировании функции диакритических "нажатий" с добавления к предыдущему символу на модификацию следующего, это бы добавило вариативности использования.
Отдельное спасибо за комментарий к небуквенной части.
Идея с мёртвыми клавишами отличная, добавлю её к текущей реализации.
На цифровой ряд я изначально поглядывал с сомнением, не слишком он удобен для слепой печати, на мой взгляд, но создавать ещё один слой пока не решился, да и не нашёл, под каким модификатором его можно расположить, не прибегая к идее полноценного переключения слоёв.
Из эргономичных клавиатур присматриваюсь для себя к компактной готовой «ZSA Moonlander», но пока только в планах.
Расположение групп цифр/f-клавиш/... в виде блоков, а не ряда, как я понимаю, обусловлено разделением «зон ответственности» рук, а были другие предпосылки?
У нас с вами несколько разные подходы. Вы говорите о пост-показателях, которых у меня пока нет, по понятным причинам. Я же, в теле поста, описывал процесс создания, и критерии к оному. Оба пункта важны, и первый следует из второго, на чём я всё же настаиваю, но ни один из этих наборов не заменяет второй. У них собственное применение в своих частях – изначальные критерии и результирующие показатели. Скорость набора, бесспорно, один из очень интересных пост-показателей, но никак не критерий. Как я уже писал в этой ветке комментариев, я сам буду рад взглянуть на показатели скорости набора на этой раскладке, и считаю их наглядными и значимыми, но этот показатель должен быть средним от многих, а пока я единственный пользователь данной раскладки, насколько мне известно, хотя буду очень рад ошибиться, взять какое-либо "среднее" не представляется возможным.
Скорость обучения – показатель в себе, совершенно не связанный ни с чем из упомянутого. Он зависит только от предшествующего опыта и прочих личных факторов, связанных непосредственно с обучением. К примеру, переход с «qwerty» на «qwpr» довольно прост и быстр, но абсолютно ничего не говорит об удобстве этих раскладок.
В целом по целесообразности перехода – я всё же хотел бы представлять эту раскладку со всеми особенностями, буквенное позиционирование в которой только один из этапов. Бесспорно, основополагающий и наиболее важный, но всё же это комплексная структура.
Ваша впечатляющая скорость набора следствие не удобства, а привычки, о чём вы сами говорили в начале комментария, и с этой, первой частью, я соглашусь – привыкнуть действительно можно к чему-угодно, и впоследствии это будет казаться удобным, но это говорит лишь о личной привычке, но никак не об объективном среднем удобстве. Для последнего я и постарался вывести независимые от предшествующего опыта и времени критерии.
Как раз сейчас на неё смотрю, по наводке @Spectrum-Hyena – отличные показатели буквенной части. Удивлён, как она прошла мимо меня. 74.75% чередования рук, 3.14% повторения нажатия. Немного хуже с использованием домашней группы (52.6%), и нагрузка на пальцы слишком напирает на указательные (43.4% в сумме). Разница нагрузки рук 8.88%.
Присмотрюсь к замечанию и озвученным раскладкам. Действительно, снижение нагрузки на мизинцы имеет место, и этот отдельный критерий можно улучшить.
Но про «йцукен» совсем не соглашусь, так как усиленная нагрузка на центр попросту превращает десятипальцевый набор в двупальцевый для 2/3 набора, а это уж совсем крайность.
Очень неоднозначный вопрос. Комментатор над вами, к примеру, считает иначе, и я с ним солидарен. Как я ответил выше, я считаю скорость прямым следствием удобства набора. Грубо говоря, вы не можете быстро и эффективно набирать текст, ради которого нужно ломать пальцы, или, вспоминая критерии "удобства", постоянно совершать несколько последовательных нажатий одним пальцем.
Тут вы немного смешиваете скорость обучения слепой печати и скорость перехода с одной раскладки на другую. Первая никоим образом не зависит от выбранной вами раскладки. Вторая же величина эфемерная, так как зависит от массы личных факторов, и в принципе, не обладает какой-либо "завершённостью". Разве что имеет место быть личный критерий – "набирать так же, как и на предыдущей" (по скорости и точности), но он, опять же, личный.
Полностью с вами согласен, и даже в основном тексте, несмотря на немалый объём, я ни разу не упомянул этот параметр. Я делал упор на удобство набора, так как считаю этот параметр важным для производительности, когда сам процесс набора не является звеном между вами и результирующим текстом, будь то код, сообщение в мессенджере, али ещё что. А скорость является приятным следствием удобства, во всяком случае, как я вижу. Набрать текст не за 5с, а за, условные, 3с – безусловно приятнее, и продуктивнее на дистанции, но это не было самоцелью.
Понятно. Как же у них, однако, всё запутано.
Судя по всему, вы просто недостаточно познакомились с ресурсом. Особенно с учётом "решить за 5 минут", да ещё и на бумаге. Для лёгкого уровня – конечно, так и должно быть, если подход понятен. Но для прочих – даже стабильные многократные лидеры турниров не всегда показывают такой результат.
Дело вкуса, выбирайте, что больше нравится.
Вопрос, полагаю, к комментаторам. Свой взгляд я обозначил в начале поста.
Спасибо, актуальное уточнение, как раз жду от представителей сайта разъяснение по нему. А у вас информация из опыта, или это уже где-то обсуждалось? Официальный пост с "for ? more than 300 days" однозначного ответа не даёт, его по-разному трактовать можно.
Харды это, в основном, применение сразу нескольких подходов. В этом и сложность – понять, какая связка требуется для нужного результата, ну и правильно её реализовать, конечно.
Новый год уже начался?)
Вы говорите так, будто получение подписки это конечная цель, а движение к ней – пустая трата, будь то денег или времени.
Цель в том, чтобы лучше овладеть темой, и она и достигается "тратой" времени. Как и всё остальное.
А подписка – просто дополнение к движению, можно и без неё, как будет угодно.
Упоминал этот подход, и что я с ним не согласен. Можно-то, конечно, но это для уже хорошо разбирающихся в теме, и которым не нужны все эти планы, учебники, соревнования. Зайти на пару дней, решить десяток хардов и закрыть на год. Но таким пользователям этот материал тогда и не нужен. А для всех остальных этот подход только во вред – либо бросят в раздражении от задач не по силам, либо начнут бездумно копипастить готовые решения. Поэтому я за подход – структурно, последовательно, стабильно, тогда будет и толк.
Среднее даже условно не назову, слишком много факторов. Скажем так: минимально – до 10 минут на все, если задачи совсем не вызывают сложности, но и не однострочники; максимально, соглашусь с позицией сайта, – по 30 минут на задачу + время на разобраться с решением, если самостоятельно так и не вышло, при учёте, что готовое решение понятно. Если нет, тогда стоит отложить такую задачу на потом.
Ну а там уже стоит отталкиваться от собственного среднего – увеличивать количество или сложность хотя бы до получаса, если каждый день за 10 минут решается; снижать сложность и читать дополнительные источники по теме, если каждый день на максимуме.
Про аналоги лучше перенаправлю.
А в целом, айти-то большой, на одном ресурсе всего, даже пусть только вводного уровня, никогда не найдёте. Тут только про АиСД, и то далеко не весь. По каждой теме ищите специальный ресурс, а лучше несколько.
CamelCase по pep8 не используется ни для переменных, ни для функций. Только для классов. Есть оговорка про mixedCase для поддержки кода, который уже так написан, но это совсем не рекомендация к использованию.
Подчёркивание допустимо не только в качестве префикса, для обозначения приватности, но и как постфикс, в случае, если используется зарезервированное слово (да, лучше выбрать другое наименование, но если сильно нужно, то class_ лучше чем clss).
Константы – в верхнем регистре с подчёркиваниями. Об этом случае тоже стоит упомянуть.
Длина строки это вообще отдельный холивар. Но стоит сделать скидку на время. Всё-таки в 2001 80 символов – необходимость.
Docstring это не совсем комментарий. Для блока комментариев pep8 говорит о "# " на каждой строке.
"Конфликт имён класса и подкласса", это совсем не про чистый код. Тут одними префиксами не обойтись. Тем более, что ведущие подчёркивания используются не для разрешения конфликта имён.
Извиняюсь за поздний ответ, не пришло сообщение об одобрении комментария.
Да, конечно можно. Можете сгрузить любые данные. Для ваших целей вам нужен лишь метод
count_symbols().Вызываете его на каждый e-mail, сплитнутый по@, выводите результат, или просто смотрите в.db.Но, возможно, вам и не нужен данный пакет. Он, всё же, предназначен для крупных выборок и корпусов, с наглядным выводом, частными настройками и возможностью дополнения. Для задач обычного подсчёта это всё будет излишним.
Спасибо за наводку, очень интересная вещь.
Бегло ознакомился, но, как я понял, пока что это относительная новинка для конкретных геймерских клавиатур (или просто они выше в ранжировании выбрались).
Было бы интересно совместить подобные свитчи с разными эргономическими клавиатурами. Ну и, конечно, нужно пробовать, как это ощущается. Хотя звучит отлично.
Всё перечисленное вами доступно. Моё упущение, что не смог правильно описать.
В начале раздела мультиязычности я разделил языковые символы, отличные от базовой письменности, на две категории:
уникальные символы, доступные ко вводу только посредством специального символа;
символы, эквивалентные базовым, дополненным комбинируемой диакритикой.
разумеется, нас интересует исключительно графическое отображение
Раздел описывается в два этапа, в которых рассматриваются две ступени поддержки:
базовая возможность ввода;
упрощённая возможность ввода.
В рамках рассмотрения предоставления базовой возможности нас интересуют исключительно графически уникальные символы, так как символы второй категории уже доступны ко вводу посредством комбинируемой диакритики, которая в описываемом проекте покрывает все минимально используемые языки мира.
Из подобных уникальных символов и была составлена основа латинских языковых наборов. В основу вошли символы из первых 30 языков, по используемости в интернете.
Соответственно, использование данной основы во всех наборах открывает именно базовую возможность ввода для всех этих языков.
Уточнение:
Уникальные символы, относящиеся к языкам на более низких позициях, пришлось вынести в отдельные языковые наборы, которые я честно обозначил как "позволяющие", т.к. только они, в рамках проекта, предоставляют доступ к полноценному набору текста на данных языках.
К этой категории поддержки относятся только лишь азербайджанский, исландский (в наборе с древнеанглийским) и некоторые африканские языки. В посте я также причислял к этой категории текущий пересмотр казахской латиницы, но сейчас обнаружил, что в апреле текущего года
ŋбыла заменена наñ, что меняет категорию поддержки данного языка на "упрощающую", а сам набор требует пересмотра.–––
Во второй части раздела я рассматривал оптимизацию ввода алфавитных символов, эквивалентных базовым символам с комбинируемой диакритикой, для чего и были составлены все языковые наборы.
В них, в части оставшейся после "основы", я расположил подобные "комбинированные" символы в их цельном виде, для упрощённого ввода.
Уточнение:
Для некоторых языков, с богатой диакритикой в алфавитных символах, попросту не хватило места, потому пришлось выбрать для их поддержки наиболее используемые и уникальные символы. К этим языкам относится затронутый вами польский, вместе с венгерским, латышским, литовским, чешским и словацким.
Сейчас это решение мне не кажется правильным, и стоит пересмотреть поддержку таких языков, пожертвовав охватом "основы" в пользу данных языков.
Но даже на текущий момент польский язык доступен к базовому вводу на 24/31 наборах, благодаря
łŁв "основе", а также имеет собственный частично-упрощающий набор сąężó, оставляющий на комбинированный ввод только наименее используемые символы, с единственным комбинируемым акутом –ćńśź.–––
ıİ, также относящийся к "основе", поддерживается во всех наборах, и в базовом виде присутствует именно в виде, противоположном ISO basic Latin. На базовой письменности у насiI, в языковом блокеıİ, что покрывает базовую возможность ввода.Дополнительные языковые наборы, относящиеся к языкам, основанным на турецком варианте латиницы, помимо возможностей упрощённого ввода также содержат опциональный переключатель, доступный на данных наборах, который выполняет небольшое перепозиционирование –
iİв буквенной части клавиатуры,ıIв языковом блоке. Работает для наборов турецкого, азербайджанского и казахской латиницы. Таким образом "основа" предоставляет базовую возможность ввода из любого набора, а специальный упрощающий набор оптимизирует ввод, с дополнительным перепозиционированием для большего удобства и согласованности символов разных регистров.Надеюсь, смог корректно прояснить эти моменты.
Да, это одна из основных проблем, даже между раскладками одной письменности, не говоря уже о разных, где базовое количество буквенных символов разнится на 20%+ (в случае сравнения кириллица-латиница), из-за чего "нужно" или освобождать позиции в одной, или заполнять пустующие места во второй.
Некоторые буквенно-символьные раскладки подходят к этой проблеме как раз с той позиции, что вы описали в конце – убирают "редкие" буквы из основной части, в угоду вспомогательным символам, по примеру обделённой «ё» в стандартном «йцукене». А в отдельных случаях даже разносят прописные и строчные варианты одной буквы на разные клавиши.
Совсем не разделяю этот подход, и вполне понимаю, почему опробованные вами позиционирования не прижились.
Наверное, располагая небуквенные символы в буквенной части, решить эту проблему и не представляется возможным, потому я и пошёл другим путём, который позволяет унифицировать небуквенный ввод.
Дело в том, что из 24 диакритических символов желаемого охвата, лишь немногие представляют интерес как отдельные символы. Седиль ç, диэрезис ӧ, гачек ǒ, и прочие потенциально востребованные диакритические символы в некомбинированном виде будут просто лежать мёртвым грузом. Также возникнет вопрос с расположением – либо переносить все «мёртвые» клавиши в цифровой ряд текущей диакритики, что усложнит доступ к их базовому представлению, по сравнению с текущим видом, особенно к таким как точка или кома, либо располагать их хаотично по всему символьному слою, что совсем не радует. К тому же, комбинируемые символы с вариантами надстрочного и подстрочного написания будут предполагать три варианта охвата – "символ, sup, sub", в то время как символы с единственным вариантом будут вносить сумятицу в это правило.
Конечно, я не предполагал, что кто-либо, кроме профильных специалистов, будет запоминать весь набор диакритики. Она тут расположена "по требованию". К примеру, потенциальному пользователю со знанием эсперанто понадобятся лишь бревис и циркумфлекс, со знанием французского – диэрезис, седиль и циркумфлекс, и так далее. В запоминании позиций 1-3 (крайне редко – 4) диакритических символов, когда они действительно востребованы для конкретного пользователя, нет ничего сложного.
Но я ещё обдумаю, как иначе можно будет удобно применить «мёртвые» клавиши к символьной части.
Кажется, я не так вас понял. Вы говорите об использовании обычной тильды для функции мёртвой клавиши, не комбинируемого символа? В таком виде получится реализовать только часть от всей желаемой диакритики, а разбивать её на две части не хотелось бы. Я изначально подумал просто об опциональном инвертировании функции диакритических "нажатий" с добавления к предыдущему символу на модификацию следующего, это бы добавило вариативности использования.
Отдельное спасибо за комментарий к небуквенной части.
Идея с мёртвыми клавишами отличная, добавлю её к текущей реализации.
На цифровой ряд я изначально поглядывал с сомнением, не слишком он удобен для слепой печати, на мой взгляд, но создавать ещё один слой пока не решился, да и не нашёл, под каким модификатором его можно расположить, не прибегая к идее полноценного переключения слоёв.
Из эргономичных клавиатур присматриваюсь для себя к компактной готовой «ZSA Moonlander», но пока только в планах.
Расположение групп цифр/f-клавиш/... в виде блоков, а не ряда, как я понимаю, обусловлено разделением «зон ответственности» рук, а были другие предпосылки?
У нас с вами несколько разные подходы. Вы говорите о пост-показателях, которых у меня пока нет, по понятным причинам. Я же, в теле поста, описывал процесс создания, и критерии к оному. Оба пункта важны, и первый следует из второго, на чём я всё же настаиваю, но ни один из этих наборов не заменяет второй. У них собственное применение в своих частях – изначальные критерии и результирующие показатели. Скорость набора, бесспорно, один из очень интересных пост-показателей, но никак не критерий. Как я уже писал в этой ветке комментариев, я сам буду рад взглянуть на показатели скорости набора на этой раскладке, и считаю их наглядными и значимыми, но этот показатель должен быть средним от многих, а пока я единственный пользователь данной раскладки, насколько мне известно, хотя буду очень рад ошибиться, взять какое-либо "среднее" не представляется возможным.
Скорость обучения – показатель в себе, совершенно не связанный ни с чем из упомянутого. Он зависит только от предшествующего опыта и прочих личных факторов, связанных непосредственно с обучением.
К примеру, переход с «qwerty» на «qwpr» довольно прост и быстр, но абсолютно ничего не говорит об удобстве этих раскладок.
В целом по целесообразности перехода – я всё же хотел бы представлять эту раскладку со всеми особенностями, буквенное позиционирование в которой только один из этапов. Бесспорно, основополагающий и наиболее важный, но всё же это комплексная структура.
Ваша впечатляющая скорость набора следствие не удобства, а привычки, о чём вы сами говорили в начале комментария, и с этой, первой частью, я соглашусь – привыкнуть действительно можно к чему-угодно, и впоследствии это будет казаться удобным, но это говорит лишь о личной привычке, но никак не об объективном среднем удобстве. Для последнего я и постарался вывести независимые от предшествующего опыта и времени критерии.
Как раз сейчас на неё смотрю, по наводке @Spectrum-Hyena – отличные показатели буквенной части. Удивлён, как она прошла мимо меня. 74.75% чередования рук, 3.14% повторения нажатия. Немного хуже с использованием домашней группы (52.6%), и нагрузка на пальцы слишком напирает на указательные (43.4% в сумме). Разница нагрузки рук 8.88%.
Исключительно буквенная часть, конечно же.
Присмотрюсь к замечанию и озвученным раскладкам. Действительно, снижение нагрузки на мизинцы имеет место, и этот отдельный критерий можно улучшить.
Но про «йцукен» совсем не соглашусь, так как усиленная нагрузка на центр попросту превращает десятипальцевый набор в двупальцевый для 2/3 набора, а это уж совсем крайность.
Очень неоднозначный вопрос. Комментатор над вами, к примеру, считает иначе, и я с ним солидарен. Как я ответил выше, я считаю скорость прямым следствием удобства набора. Грубо говоря, вы не можете быстро и эффективно набирать текст, ради которого нужно ломать пальцы, или, вспоминая критерии "удобства", постоянно совершать несколько последовательных нажатий одним пальцем.
Тут вы немного смешиваете скорость обучения слепой печати и скорость перехода с одной раскладки на другую. Первая никоим образом не зависит от выбранной вами раскладки. Вторая же величина эфемерная, так как зависит от массы личных факторов, и в принципе, не обладает какой-либо "завершённостью". Разве что имеет место быть личный критерий – "набирать так же, как и на предыдущей" (по скорости и точности), но он, опять же, личный.
Полностью с вами согласен, и даже в основном тексте, несмотря на немалый объём, я ни разу не упомянул этот параметр. Я делал упор на удобство набора, так как считаю этот параметр важным для производительности, когда сам процесс набора не является звеном между вами и результирующим текстом, будь то код, сообщение в мессенджере, али ещё что. А скорость является приятным следствием удобства, во всяком случае, как я вижу. Набрать текст не за 5с, а за, условные, 3с – безусловно приятнее, и продуктивнее на дистанции, но это не было самоцелью.