Поправил формулировки. Я честно говоря думал, что если статья уже давно опубликована и опубликована в хабе компании и там есть плюсы – значит редачить нельзя.
Это не ортолинейная клава, - это - колстаг - колумн стаггеред.
Полностью согласен, каюсь. Я здесь больше имел ввиду по поводу сдвигов рядов имел ввиду. Мне друг, который меня и погрузил в этот мир, уже напинал в день выхода статьи). Это просто неточность формулировки, за это извиняюсь.
Это не верно. А верно то что на механике возможно выбрать тактильность по вкусу. В том числе можно выбрать еще более мягкие и неинформативные нажатия.
С этим тоже можно согласиться, но всё-таки на любой механике клавиатура нажимается более приятно и понятно, чем на мембранке.
С тем, что маковские клавиатуры шикарные - полностью согласен. Ножничные клавы это одно из лучших, что придумывали в мире мембранок. На них действительно приятно нажимать, они в целом довольно близки по комфорту работы к механике.
Но самый большой минус - это то, что они до сих пор пытаются поддерживать legacy решение, которому более 100 лет. Нет ни одной нормальной причины, почему в 2026 году клавиатуры должны иметь смещение кнопок. Это было сделано, чтобы работали печатные машинки, а потом, чтобы было проще переходить с печатных машинок. Если бы на дефолтных клавиатурах кнопки хотя бы были ортолинейные - это бы уже решило очень много проблем.
вам не столько эти механические клавы нравятся сколько раздражать окружающих их скрипом и шумом
Я в статье уделяю большое внимание смазки свичей, а также, приложил видео с саунд тестом - вы в видео действительно слышите громкие нажатия на клавиатуру?
А остальные плюсы, которые рассмотрены в статье вы просто пропустили? А как же:
Удобные программируемые возможности
Комфорт при печати
Эргономичность
Второе - это форма! Форма при которой ни один человек знакомый ранее с клавиатурами не сможет воспользоваться вашим рабочим местом
А зачем кому-то пользоваться моим рабочим местом?
привыкнув к своей шарообразной клавиатуре в форме бублика вы просто не сможете найти ентер на обычной и все другие компы (и все ноутбуки) для вас превращаются в тыкву.
Да нет, я буквально сейчас вам отвечаю со своего ноутбука, никаких проблем с тем, чтобы забыть, как пользоваться стандартной клавиатурой у меня нет. Мышечная память довольно долгосрочная. Да и в крайнем случае, на обычных клавах все кнопочки подписаны)
Подытожим - вот это вот всё не про эргономику и удобство, а про латентную тягу к мучениям и какой то категории БДСМ, название которой не смогли выдумать даже на порнохабе.
А вы прежде чем такие выводы делать, пробовали пользоваться подобным? Чем же я вас таким обидел в своей статье, что мы скатились к оскорблениям?
П.С. Я сам фанат эргономики, как только смог заработать на первое пиво стал копить на свен ергономик или как там её звали
А выше вы пишите, что моя клавиатура не про эргономику и удобство, а про латентную тягу к мучениям).
Но тут больше дело в том, что если каждый день по 8 (а на самом деле как правило, все 12) часов сидеть за клавиатурой, то ты быстро начинаешь понимать разницу между правильной и эргономичной посадкой, правильной клавиатурой и прочему, когда у тебя к концу дня не болят пальцы, запястья и локти. По-сути, всё что я в статье рассказываю, именно про решение этой проблемы.
Ну и допом получаешь клавиатуру, которой приятно пользоваться за счёт механики плюс много фичей с точки зрения настраиваемости софта и кастомизации, из-за чего клавиатурой становится очень удобно пользоваться и сильно вырастает скорость печати. А это в свою очередь приводит к тому, что можно дольше сохранять концентрацию и находится в состоянии потока. Думаю, не стоит объяснять, как это важно для разработчика.
Я с хотсвапами тоже намучался, в статье про это особо не рассказал, но да - они имеют тенденцию отваливаться от платы, даже если там прямо очень много припоя наливаешь. При сильных нажатиях или при долгом нажатии на кнопки. Хотя, справедливости ради - уже пару месяцев как ничего не отваливалось наконец-то. Но я уже привык - отвалился хотсвап, сразу берёшь паяльник, пару минут и всё на месте. Но иногда даже кажется, что проще было жёстко припаять свичи в плату.
Open source прошивка (qmk)
Да, для меня тоже одна из самых важных фич в клаве - это настраиваемость и слои, а также кнопки под большими пальцами, которые позволяют делать много действий, чтобы печать действительно была 10-ти пальцевая, а не только 8-ми пальцевая.
Ну и ремонтопригодность, это, конечно, точно большой плюс, особенно когда ты понимаешь, что и как работает, починить дело 5-ти минут.
1. Звукоизоляция. Причём хорошая шумка должна быть ещё и тяжёлой. Бряка намного меньше, а тяжёлую приятнее брать в руки.
Согласен, смотрю в эту сторону, но сам текущий корпус lily не предполагает возможности шумки. Но я уже двигаюсь в сторону проектирования и печати другого корпуса, чтобы можно было сделать шумку. Но на низкопрофильных шумка не так важна, т.к. сами по себе кнопки в разы тише, чем со стандартными
Смазка свичей. Не всех и не всегда, но часто снижает шум и делает ход более мягким и тактильно приятным.
Это да, у меня все свитчи во всех клавиатурах смазаны.
Шумно, высоко над столом (заставляет изгибать запястье),
Вот именно поэтому, я и собрал клаву на низком профиле
У меня есть специальные подушечки, но текущая высота lily с низкопрофильными выключателями как раз даёт возможность пользоваться клавой без них - так удобнее.
Вот я бы советовал хотя бы попробовать сплит и понять, что это такое. Особенно, их возможности с настройкой слоёв, это супер удобно, особенно в программировании, когда спецсимволы можно переместить на отдельный слой и до них не нужно будет на цифровой ряд тянуться постоянно
То есть, вы настраивали под VIA? У меня сейчас под VIAL. Покупал на Али. Есть некоторые проблемы с прошивкой. Раньше делал под QMK , но там меньше возможности по настройке. Покупал низкопрофильную под ZMK. Механика там была блестящая. Но микроконтроллер практически не работал.
Вы про какую клавиатуру имеете ввиду? У меня для каждой из клавиатур в статье свой софт был). Dactyl от ergohaven - VIA Чёрная низкопрофильная с Авито - VIAL Моя lily58 - ZMK
Вы много пишите про doubleClick. Причина тут может быть не только в плохих контактах, но и в некачественном микропрограммном обеспечении. Если хорошо обрабатывать дребезг контактов, то можно сделать так, что будет работать даже на плохих свичах.
doubleclick - это точно проблема с самими свитчами, тут выше подсказали, что это известная проблема. С другими свитчами сами клавиатуры работают без проблем. И дребезг контактов на ZMK я пытался править как раз параметрами самой прошивки - это не помогало.
Проблема в том, что при произвольном перемещении половинок клавиатуры происходит неконтролируемый разворот.
Произвольное перемещение - это когда у вас половинки елозят по столу? Это же фиксится резиновыми ножками снизу. У меня они не двигаются особо никуда, если на резиновых ножках и снизу коврик.
У меня клавиатура по ширине меньше, чем две ваших половинки, сдвинутые вместе. Она занимает мало места по ширине. Она находится у меня в центре. А мышь находится справа от клавиатуры. При этом позиция руки на мыши у меня более естественая, чем, если бы мышь была в центре.
Если вам удобно - то это замечательно. Но приведу тут такую картинку, которую нашёл в статье из комментария ниже:
Это именно то, от чего я пытался избавиться разделённой клавиатурой. Можно разнести половинки на удобное тебе расстояние, чтобы руки в плечах и локтях были прямыми и не согнутыми.
Это отлично, что вы нашли вариант себе по душе. Клавиатура действительно выглядит хорошо - убрали сдвиг, сделали её почти ортолинейной. Но минус я у неё все равно вижу, из-за чего она не подойдёт мне - под большими пальцами всё также только один пробел, нет дополнительных кнопок. В итоге большой палец может только пробел нажимать, а модификаторы нужно чтобы нажимал более слабый мизинец.
Полностью согласен, я вроде и не говорю об этом в статье
Да, именно поэтому, в моей lily 58pro у колонок есть также небольшие смещения, которые учитывают разную длину пальцев. А также, на 3д принтере напечатанные кейкапы, которые дополнительно образуют более удобный 3д рельеф, максимально повторяющие движения пальцев
У меня опыт ровно противоположный. Мне наоборот удобнее на сплите ставить руки. Я прямо вот почти никогда не промахиваюсь с нахождением home row, всё благодаря кейкапам с засечками.
А как же игры? Я 4-ый ряд делал ровно потому, что отдельные цифры нужны в играх, без этого почти невозможно. Мне лично вот тот вариант, про который говорю в статье кажется самым удобным.
Понимаю вашу позицию про 99% статей, но моя статья — это скорее личная история поиска удобной клавиатуры, а не обзор или гайд. Все решения, о которых я пишу, подкреплены моим конкретным опытом: ошибками со сборкой, даблкликами, перепайкой сокетов, сравнением разных форм-факторов. Принципы слоёв я тоже затрагиваю, хотя, конечно, тему можно раскрыть глубже. Было бы интересно услышать ваш подход — вы явно глубоко в теме.
Готов с вами подискутировать более подробно здесь, комментарии порой бывают даже ценнее, чем сама статья.
Не видел этой клавиатуры, спасибо за ссылку. Вижу, что это по-сути dactyl с низкопрофильными свитчами. Если всё устраивает - то смазывать и не нужно. Я смазывал по тому, что моя низкопрофильная противно звенькала, и это известная проблема у kailh choc переключателей, кто-то даже скотчем!!! заклеивает некоторые места в свитчах, чтобы избавиться полностью от звяканья. Я этим не страдал, конечно.
Пу пу пу... А это была моя первая клавиатура и я на тот момент не находил этой информации. Ну чтож, хотя бы спустя время я об этом узнал, что проблема была не во мне, спасибо за инфу
1. С этим проблемы имеются ввиду обширности архитектуры авито. У нас миллионы запросов в минуту и соответственно ОЧЕНЬ много серверов, которые орекстрируются при помощи kubernetes, поверх которого наш PaaS. Но тем не мене, оверхед в необходимости закодировать/декодировать данные перед отправкой в Redis остается, хоть и минимизируются сетевые издержки.
2. Не подойдет, но тем не менее, его мы используем в других задачах. Не подойдет потому, что нас придется тогда обучать всех разработчиков работе с tarantool, когда у нас все разработчики уже знают Go. Это первый момент. Второй момент — опять же загрузка сети.
Ну в случае любой встраиваемой БД (ровно как и sqlite) как правило будет все равно оверхед. В моем же случае, мы просто храним в оперативной памяти данные, которые не надо никуда преобразовывать и RT сервиса в этом случае будет равняться RT получению нужных данных из оперативной памяти и декодированию/кодированию запроса, что в общем то и надо на высоких нагрузках.
Благодарю за замечание! Действительно, в go чаще используется термин slice для массивов, которые не имеют заданной длины и в терминологии go array и slice действительно отличаются. Но я в статье имел ввиду массив как более общий для программирования термин, просто не очень хотелось использовать слово «срез» или англицизм «слайс» и именно поэтому я использовал слово «массив». В статью внес правку, чтобы не вводить никого в заблуждение.
Неееет! Первое что должно приходить в голову — какого этот сервис не может за 300мс выполнить свою работу? И только после ответа на этот вопрос — кеши и ещё ещё что-то.
Это было известно с самого начала, но специально не упомянуто тут, т.к. выходит за рамки статьи. Сервис медленный, т.к. сделан на php и работает с внешними сервисами, которые выделяют номера. За тот сервис отвечала другая команда, но в процессе оптимизации phones-gateway, о котором и рассказано в статье, наша команда также оптимизировала тот сервис, но переписывать его на Go было не в рамках нашего пула задач, и сильно оптимизировать мы не смогли, сейчас ситуация с ним значительно лучше, т.к. его переписали и оптимизировали.
Вообще непонятно зачем все эти сложности? Есть юзер, у него есть верифицированный номер телефона. Есть объявление, у него тоже есть номер телефона, который либо anonymous, либо call tracking, либо берётся из данных юзера. Система решает этот вопрос в момент создания объявления. Есть отдельный сервис — пул телефонов, который связан с АТС и выдаёт номер нужного типа, в момент создания объявления.
Тут у нас уже появляются требования Роскомнадзора и других органов. Номер телефона пользователя является персональными данными пользователя и хранится в отдельной таблице от объявления в виде зашифрованных данных и получение этих данных происходит через специальный сервис-хранитель перс. данных. Более того, в вашей модели не учтен момент, что пользователь может захотеть поменять номер телефона и поменять его так, чтобы он поменялся сразу на всех объявлениях.
Больше к нему никто не обращается, нагрузки особой на него нет. Кажется все. И тут не видно всех тех сложностей, о которых пишут в статье, типа сервисы работы с телефонами тормозят, а их ещё и несколько штук…
Тут еще дело в том, что этими сервисами заведуют разные команды, которые решают разные бизнес задачи, поэтому есть дифференциация на разные типы номеров для переадресации, и они преследуют разные цели. Также, реальный номер телефона может потребоваться получить в админке или еще в каких-то сервисах, по рассылке СМС к примеру. Поэтому архитектура на деле оправдана и обусловлена требованиями бизнеса.
Ожидал подобного вопроса. В данном случае я специально применил in-memory cache, т.к. если использовать Redis и Memcached у нас появляется сразу большое количество ошибок с сетью, которые регулярно происходят при использовании Redis и подобных решений. Помимо этого, у нас появляется оверхед в виде кодирования данных для отправки в Redis, отправки данных через сеть, получения ответа от Redis, раскодирования и так далее. Это сильно аффектит response time сервиса и нагружает и без того нагруженную сеть у нас. При этом, оперативной памяти у нас довольно много свободной, поэтому мы можем пожертвовать дублированием в данном случае ради большей стабильности и производительности.
Поправил формулировки. Я честно говоря думал, что если статья уже давно опубликована и опубликована в хабе компании и там есть плюсы – значит редачить нельзя.
Полностью согласен, каюсь. Я здесь больше имел ввиду по поводу сдвигов рядов имел ввиду. Мне друг, который меня и погрузил в этот мир, уже напинал в день выхода статьи). Это просто неточность формулировки, за это извиняюсь.
С этим тоже можно согласиться, но всё-таки на любой механике клавиатура нажимается более приятно и понятно, чем на мембранке.
С тем, что маковские клавиатуры шикарные - полностью согласен. Ножничные клавы это одно из лучших, что придумывали в мире мембранок. На них действительно приятно нажимать, они в целом довольно близки по комфорту работы к механике.
Но самый большой минус - это то, что они до сих пор пытаются поддерживать legacy решение, которому более 100 лет. Нет ни одной нормальной причины, почему в 2026 году клавиатуры должны иметь смещение кнопок. Это было сделано, чтобы работали печатные машинки, а потом, чтобы было проще переходить с печатных машинок. Если бы на дефолтных клавиатурах кнопки хотя бы были ортолинейные - это бы уже решило очень много проблем.
Я в статье уделяю большое внимание смазки свичей, а также, приложил видео с саунд тестом - вы в видео действительно слышите громкие нажатия на клавиатуру?
А остальные плюсы, которые рассмотрены в статье вы просто пропустили? А как же:
Удобные программируемые возможности
Комфорт при печати
Эргономичность
А зачем кому-то пользоваться моим рабочим местом?
Да нет, я буквально сейчас вам отвечаю со своего ноутбука, никаких проблем с тем, чтобы забыть, как пользоваться стандартной клавиатурой у меня нет. Мышечная память довольно долгосрочная. Да и в крайнем случае, на обычных клавах все кнопочки подписаны)
А вы прежде чем такие выводы делать, пробовали пользоваться подобным? Чем же я вас таким обидел в своей статье, что мы скатились к оскорблениям?
А выше вы пишите, что моя клавиатура не про эргономику и удобство, а про латентную тягу к мучениям).
Но тут больше дело в том, что если каждый день по 8 (а на самом деле как правило, все 12) часов сидеть за клавиатурой, то ты быстро начинаешь понимать разницу между правильной и эргономичной посадкой, правильной клавиатурой и прочему, когда у тебя к концу дня не болят пальцы, запястья и локти. По-сути, всё что я в статье рассказываю, именно про решение этой проблемы.
Ну и допом получаешь клавиатуру, которой приятно пользоваться за счёт механики плюс много фичей с точки зрения настраиваемости софта и кастомизации, из-за чего клавиатурой становится очень удобно пользоваться и сильно вырастает скорость печати. А это в свою очередь приводит к тому, что можно дольше сохранять концентрацию и находится в состоянии потока. Думаю, не стоит объяснять, как это важно для разработчика.
Я с хотсвапами тоже намучался, в статье про это особо не рассказал, но да - они имеют тенденцию отваливаться от платы, даже если там прямо очень много припоя наливаешь. При сильных нажатиях или при долгом нажатии на кнопки. Хотя, справедливости ради - уже пару месяцев как ничего не отваливалось наконец-то. Но я уже привык - отвалился хотсвап, сразу берёшь паяльник, пару минут и всё на месте. Но иногда даже кажется, что проще было жёстко припаять свичи в плату.
Да, для меня тоже одна из самых важных фич в клаве - это настраиваемость и слои, а также кнопки под большими пальцами, которые позволяют делать много действий, чтобы печать действительно была 10-ти пальцевая, а не только 8-ми пальцевая.
Ну и ремонтопригодность, это, конечно, точно большой плюс, особенно когда ты понимаешь, что и как работает, починить дело 5-ти минут.
Согласен, смотрю в эту сторону, но сам текущий корпус lily не предполагает возможности шумки. Но я уже двигаюсь в сторону проектирования и печати другого корпуса, чтобы можно было сделать шумку. Но на низкопрофильных шумка не так важна, т.к. сами по себе кнопки в разы тише, чем со стандартными
Это да, у меня все свитчи во всех клавиатурах смазаны.
Вот именно поэтому, я и собрал клаву на низком профиле
Вы проиграли). А почему такой вывод, просто любопытно?
У меня есть специальные подушечки, но текущая высота lily с низкопрофильными выключателями как раз даёт возможность пользоваться клавой без них - так удобнее.
Вот я бы советовал хотя бы попробовать сплит и понять, что это такое. Особенно, их возможности с настройкой слоёв, это супер удобно, особенно в программировании, когда спецсимволы можно переместить на отдельный слой и до них не нужно будет на цифровой ряд тянуться постоянно
Kinesis хорошие, но проблема с доступностью и ценой, при этом, они не дают такой большой возможности по кастомизации с точки зрения слоёв и т.д.
Но при этом, по-сути он очень похож на dactyl manuform, который у меня есть, и он мне меньше, чем lily заходит.
Вы про какую клавиатуру имеете ввиду? У меня для каждой из клавиатур в статье свой софт был).
Dactyl от ergohaven - VIA
Чёрная низкопрофильная с Авито - VIAL
Моя lily58 - ZMK
doubleclick - это точно проблема с самими свитчами, тут выше подсказали, что это известная проблема. С другими свитчами сами клавиатуры работают без проблем. И дребезг контактов на ZMK я пытался править как раз параметрами самой прошивки - это не помогало.
Произвольное перемещение - это когда у вас половинки елозят по столу? Это же фиксится резиновыми ножками снизу. У меня они не двигаются особо никуда, если на резиновых ножках и снизу коврик.
Если вам удобно - то это замечательно. Но приведу тут такую картинку, которую нашёл в статье из комментария ниже:
Это именно то, от чего я пытался избавиться разделённой клавиатурой. Можно разнести половинки на удобное тебе расстояние, чтобы руки в плечах и локтях были прямыми и не согнутыми.
Это отлично, что вы нашли вариант себе по душе. Клавиатура действительно выглядит хорошо - убрали сдвиг, сделали её почти ортолинейной. Но минус я у неё все равно вижу, из-за чего она не подойдёт мне - под большими пальцами всё также только один пробел, нет дополнительных кнопок. В итоге большой палец может только пробел нажимать, а модификаторы нужно чтобы нажимал более слабый мизинец.
Полностью согласен, я вроде и не говорю об этом в статье
Да, именно поэтому, в моей lily 58pro у колонок есть также небольшие смещения, которые учитывают разную длину пальцев. А также, на 3д принтере напечатанные кейкапы, которые дополнительно образуют более удобный 3д рельеф, максимально повторяющие движения пальцев
У меня опыт ровно противоположный. Мне наоборот удобнее на сплите ставить руки. Я прямо вот почти никогда не промахиваюсь с нахождением home row, всё благодаря кейкапам с засечками.
А как же игры? Я 4-ый ряд делал ровно потому, что отдельные цифры нужны в играх, без этого почти невозможно. Мне лично вот тот вариант, про который говорю в статье кажется самым удобным.
Понимаю вашу позицию про 99% статей, но моя статья — это скорее личная история поиска удобной клавиатуры, а не обзор или гайд. Все решения, о которых я пишу, подкреплены моим конкретным опытом: ошибками со сборкой, даблкликами, перепайкой сокетов, сравнением разных форм-факторов. Принципы слоёв я тоже затрагиваю, хотя, конечно, тему можно раскрыть глубже. Было бы интересно услышать ваш подход — вы явно глубоко в теме.
Готов с вами подискутировать более подробно здесь, комментарии порой бывают даже ценнее, чем сама статья.
Не видел этой клавиатуры, спасибо за ссылку. Вижу, что это по-сути dactyl с низкопрофильными свитчами. Если всё устраивает - то смазывать и не нужно. Я смазывал по тому, что моя низкопрофильная противно звенькала, и это известная проблема у kailh choc переключателей, кто-то даже скотчем!!! заклеивает некоторые места в свитчах, чтобы избавиться полностью от звяканья. Я этим не страдал, конечно.
Пу пу пу... А это была моя первая клавиатура и я на тот момент не находил этой информации. Ну чтож, хотя бы спустя время я об этом узнал, что проблема была не во мне, спасибо за инфу
2. Не подойдет, но тем не менее, его мы используем в других задачах. Не подойдет потому, что нас придется тогда обучать всех разработчиков работе с tarantool, когда у нас все разработчики уже знают Go. Это первый момент. Второй момент — опять же загрузка сети.
Это было известно с самого начала, но специально не упомянуто тут, т.к. выходит за рамки статьи. Сервис медленный, т.к. сделан на php и работает с внешними сервисами, которые выделяют номера. За тот сервис отвечала другая команда, но в процессе оптимизации phones-gateway, о котором и рассказано в статье, наша команда также оптимизировала тот сервис, но переписывать его на Go было не в рамках нашего пула задач, и сильно оптимизировать мы не смогли, сейчас ситуация с ним значительно лучше, т.к. его переписали и оптимизировали.
Тут у нас уже появляются требования Роскомнадзора и других органов. Номер телефона пользователя является персональными данными пользователя и хранится в отдельной таблице от объявления в виде зашифрованных данных и получение этих данных происходит через специальный сервис-хранитель перс. данных. Более того, в вашей модели не учтен момент, что пользователь может захотеть поменять номер телефона и поменять его так, чтобы он поменялся сразу на всех объявлениях.
Тут еще дело в том, что этими сервисами заведуют разные команды, которые решают разные бизнес задачи, поэтому есть дифференциация на разные типы номеров для переадресации, и они преследуют разные цели. Также, реальный номер телефона может потребоваться получить в админке или еще в каких-то сервисах, по рассылке СМС к примеру. Поэтому архитектура на деле оправдана и обусловлена требованиями бизнеса.