Наконец-то заполучил M9N — клавиатуру, которую присмотрел еще в 2024, но не смог тогда приобрести.
В мире кастомных клавиатур многие проекты запускаются через краудфандинг (group buy):
‣ Дизайнер готовит концепт, запускает рекламу (вот пример c M9N) и продает обещания экземпляров тем, кто успеет.
‣ Партия поставляется спустя несколько лунных месяцев, а иногда и лет.
‣ Покупатель получает кит — корпус, плату и прочие составляющие, но переключатели и клавиши докупает самостоятельно, иногда через отдельный group buy.
‣ Покупатель собирает клавиатуру. Можно посмотреть на youtube пример с M9N.
‣ Устраивает фотосессию и... продаёт клавиатуру на классифайде вроде авито или китайского goofish.
На последнем я и нашел M9N. Надо сказать, редкая была птица: group buy ограничился всего 35 экземплярами.
Откуда название M9N?
К объяснению логичнее всего подойти с форм-фактора. В 40% клавиатурах нет ряда с цифрами, поэтому цифры обычно размещают на дополнительном слове поверх QWERTY-ряда:
Q — 1
W — 2
...
O — 9
У меня цифры расположены иначе, но девятка всё равно оказалась на “О” (см. картинку в dotfiles/README).
M9N превращается в MON, то есть Monday. Этимологически Monday — это Moon day, день луны, а M9N — первая клавиатура в серии дней недели, Seven Luminaries, от дизайнера Jio.
Jio обыграл лунную тему в нескольких деталях. Один из вариантов корпуса идет в цвете moonlight. Именно он на фото. А внутри корпуса, словно в “лунном дворце”, изображен Юйту — лунный зайчик из китайской мифологии. В Истории стрелка И и его жены Чан-э так и говорится:
Больше всего мне понравилась идея воплощения двойственности луны. Jio пишет про неустойчивое состояние в визуальном восприятии и устойчивое — в тактильном, сравнивая это с противоположными интерпретациями луны с материнским началом и со смертью. Клавиатура выглядит такой элегантной и утонченной из-за искривлённого дна (видно на первой фотографии).
Я решил продолжить лунную тему и поставил переключатели HMX Moonlight, и сейчас набираю этот текст на них, а клавиши KBS Moonlight уже идут с goofish.
В общем, понедельник, которого я ждал два года, наступил. Фотосессию устроил, шаг с перепродажей сознательно пропускаю.
В мире кастомных клавиатур многие проекты запускаются через краудфандинг (group buy):
‣ Дизайнер готовит концепт, запускает рекламу (вот пример c M9N) и продает обещания экземпляров тем, кто успеет.
‣ Партия поставляется спустя несколько лунных месяцев, а иногда и лет.
‣ Покупатель получает кит — корпус, плату и прочие составляющие, но переключатели и клавиши докупает самостоятельно, иногда через отдельный group buy.
‣ Покупатель собирает клавиатуру. Можно посмотреть на youtube пример с M9N.
‣ Устраивает фотосессию и... продаёт клавиатуру на классифайде вроде авито или китайского goofish.
На последнем я и нашел M9N. Надо сказать, редкая была птица: group buy ограничился всего 35 экземплярами.
Откуда название M9N?
К объяснению логичнее всего подойти с форм-фактора. В 40% клавиатурах нет ряда с цифрами, поэтому цифры обычно размещают на дополнительном слове поверх QWERTY-ряда:
Q — 1
W — 2
...
O — 9
У меня цифры расположены иначе, но девятка всё равно оказалась на “О” (см. картинку в dotfiles/README).
M9N превращается в MON, то есть Monday. Этимологически Monday — это Moon day, день луны, а M9N — первая клавиатура в серии дней недели, Seven Luminaries, от дизайнера Jio.
Jio обыграл лунную тему в нескольких деталях. Один из вариантов корпуса идет в цвете moonlight. Именно он на фото. А внутри корпуса, словно в “лунном дворце”, изображен Юйту — лунный зайчик из китайской мифологии. В Истории стрелка И и его жены Чан-э так и говорится:
она не знала, что в лунном дворце окажется так пусто и безлюдно. Там был только белый заяц, который круглый год толок в ступке лекарство бессмертия.
Больше всего мне понравилась идея воплощения двойственности луны. Jio пишет про неустойчивое состояние в визуальном восприятии и устойчивое — в тактильном, сравнивая это с противоположными интерпретациями луны с материнским началом и со смертью. Клавиатура выглядит такой элегантной и утонченной из-за искривлённого дна (видно на первой фотографии).
Я решил продолжить лунную тему и поставил переключатели HMX Moonlight, и сейчас набираю этот текст на них, а клавиши KBS Moonlight уже идут с goofish.
В общем, понедельник, которого я ждал два года, наступил. Фотосессию устроил, шаг с перепродажей сознательно пропускаю.
🔥9❤8👾5👍2🤯2
Новый подход к code review в эру агентов
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.
В далекие времена, где-то 1-2 месяца назад, когда приходил PR, я ревьюил код сам. Ревьюил агентами. Оставляя комментарии. Потом возвращался, смотрел на правки, ревьюил еще раз. И так несколько итераций. Вот пример, понадобилось 70 сообщений и 9 дней, прежде чем получилось влить.
Но кажется, что есть вариант получше: дать агенту готовый ПР и попросить переписать. Я использовал простой промпт на Astra XHigh:
Let's implement the <task description> in <PR link>.
But simpler. Try to avoid unnecessary abstractions, get rid of bloated tests, simplify the logic where possible, remove code duplication, etc.
Первый эксперимент, большой ПР, задача про интеграцию VK (меньше на 51% кода):
‣ Было +3200 -60
‣ Стало +1632 -105
Второй эксперимент, средний ПР, задача про композицию тулов в скиллах (меньше на 60% кода):
‣ Было +1353 -13
‣ Стало +624 -91
Третий эксперимент, маленький ПР, фикс блокирующих друг друга Tg/VK polling (меньше на 93% кода):
‣ Было +87 -10
‣ Стало +98 -93
Все три переписанных ПР-а лучше во всех важных для меня аспектах: безопаснее, идиоматичнее, проще для понимания, исправляют review findings из основного ПР-а, значительно меньше кода.
Качество оценивал сам и просил коллегу. Экспериментов всё еще мало, но очень хотелось поделиться опытом.
Итак, резюмируя: если использовать изначальный ПР как спецификацию для нового ПР, получается и быстрее, и токенов тратится меньше в сравнении с обычным code review.
GitHub
OAuth skill service for obtaining, storing, refreshing, and using OAuth tokens by jilees · Pull Request #615 · D00mch/souz
…ic core)
Lets skills call third-party APIs that require OAuth (Yandex to start, others via the same standard authorization-code flow later) without a raw access token ever reaching a skill'...
Lets skills call third-party APIs that require OAuth (Yandex to start, others via the same standard authorization-code flow later) without a raw access token ever reaching a skill'...
🔥14👍9🤔5❤2😁1
Подход, когда модель переписывает PR, — это альтернатива Spec Driven Development (SDD).
Если бы вместо PR была спека, результат был бы настолько же плох, как изначальный PR — во всяком случае, это продемонстрировал опыт коллеги из кейса выше.
Почему так?
В коде меньше неопределенности, чем в тексте на естественном языке. PR может быть перегружен абстракциями и дублированием, но код в нем уже работает. LM получает имеющуюся реализацию как отправную точку и может сосредоточиться на её улучшении.
О том, как несколько строчек кода превращаются в параграфы спек, и почему Codespeak вызывает большой скепсис, писал тут.
И еще забавное совпадение: обнаружил, что бывший коллега из Яндекса сформулировал практически то же самое параллельно со мной.
Если бы вместо PR была спека, результат был бы настолько же плох, как изначальный PR — во всяком случае, это продемонстрировал опыт коллеги из кейса выше.
Почему так?
В коде меньше неопределенности, чем в тексте на естественном языке. PR может быть перегружен абстракциями и дублированием, но код в нем уже работает. LM получает имеющуюся реализацию как отправную точку и может сосредоточиться на её улучшении.
О том, как несколько строчек кода превращаются в параграфы спек, и почему Codespeak вызывает большой скепсис, писал тут.
И еще забавное совпадение: обнаружил, что бывший коллега из Яндекса сформулировал практически то же самое параллельно со мной.
👍6❤3🔥3👾1