Я как-раз таки очень близок к мобильной разработке, и говорю из практического опыта.
Чтобы поддержать accessibility для чего-то вот такого нестандартного, надо как минимум об этом знать и задуматься. До этого шага обычно и не доходит. Я это связываю с тем, что если об этом знать и задумываться, то само желание заниматься вот такой вот кастомизацией сразу угасает.
Почему тогда на хабрахабре (и вообще почти нигде) нет ни одного кнопко-слайдера? Это какая-то уникальная запатентованная accessibility разработка гениев дизайна?
И что теперь? Каждое приложение и каждый сайт должно теперь быть устойчивым к инпуту от чьей-то ноги? Это всё личные проблемы каждого пользователя, решённые один раз блокировщиком экрана на телефоне.
Упоротый телефон? Ну кто виноват, выбери себе не упоротый, выбор очень богатый, на любой цвет, размер, и цену. Почему из-за чьего-то упоротого телефона всё остальное тоже должно становиться чёрт знает чем?
Хотя нажатие казалось привычным и простым, мы опасались случайных нажатий из-за слепоты к кнопкам. С другой стороны, скольжение обеспечивало более целенаправленное взаимодействие, чтобы избавить пользователя от привычки нажимать вслепую.
Земля пухом тем, кто случайно или вслепую нажимает на кнопки.
Скорость печатания здесь действительно не главное, по крайней мере для меня. Сильно быстрее я печатать наверное не стал, и цели такой у меня не было. Но с раздельной клавиатурой мне заметно комфортнее печатать, рукам удобнее. Это всё личные предпочтения, но пока не попробуешь – не поймёшь, нравится так печатать или же нет.
Суть, которую я хотел донести, состоит в том, что Великолепный Инструмент не обратил внимание на подозрительные части, а безропотно помог лишь ещё сильнее ухудшить и без того стремноватую функцию.
Имхо функция сначала была просто плохой и непонятной, а после этого "патча", она стала совсем плохой и ещё менее понятной для программиста. И проблема не в квалификации читающего. Я изо всех сил пытался удержаться от комментария по поводу "15 лет программирования", но не смог. Мне кажется, за 15 лет такие функции должны начать вызывать неприятные чувства.
Более того, тот "голос", который говорит в моей голове при чтении и осмыслении кода, использует другие "слова", другой порядок, совершенно другой подход. Для меня чтение вот таких объяснений это как слушать лекцию человека с неприятным тебе голосом, или с некомфортным темпом рассказа, или с фокусом совершенно не на то, что тебе интересно.
И в чём польза этого текстового описания для кода? Его всё равно надо осмыслить и загрузить себе в мозг, чтобы потом произвести нужное изменение. Так может проще прочитать код?
Зачем в работающем приложении на горячую обновлять локализацию? Никто не умрёт, если новая локализация применится при следующем перезапуске. Зато сколько жизни можно сэкономить не поддерживая такую маргинальную фичу.
Я как-раз таки очень близок к мобильной разработке, и говорю из практического опыта.
Чтобы поддержать accessibility для чего-то вот такого нестандартного, надо как минимум об этом знать и задуматься. До этого шага обычно и не доходит. Я это связываю с тем, что если об этом знать и задумываться, то само желание заниматься вот такой вот кастомизацией сразу угасает.
Почему тогда на хабрахабре (и вообще почти нигде) нет ни одного кнопко-слайдера? Это какая-то уникальная запатентованная accessibility разработка гениев дизайна?
Я очень сомневаюсь, что например слепой человек сможет понять, что же надо сделать, чтобы оплатить покупку тем слайдером.
И что теперь? Каждое приложение и каждый сайт должно теперь быть устойчивым к инпуту от чьей-то ноги? Это всё личные проблемы каждого пользователя, решённые один раз блокировщиком экрана на телефоне.
Упоротый телефон? Ну кто виноват, выбери себе не упоротый, выбор очень богатый, на любой цвет, размер, и цену. Почему из-за чьего-то упоротого телефона всё остальное тоже должно становиться чёрт знает чем?
Земля пухом тем, кто случайно или вслепую нажимает на кнопки.
Вон из профессии.
Скорость печатания здесь действительно не главное, по крайней мере для меня. Сильно быстрее я печатать наверное не стал, и цели такой у меня не было. Но с раздельной клавиатурой мне заметно комфортнее печатать, рукам удобнее. Это всё личные предпочтения, но пока не попробуешь – не поймёшь, нравится так печатать или же нет.
А что делает эта функция? Ну чёт умножает, чёт сдвигает, чёт отнимает. Но это не ответ.
Суть, которую я хотел донести, состоит в том, что Великолепный Инструмент не обратил внимание на подозрительные части, а безропотно помог лишь ещё сильнее ухудшить и без того стремноватую функцию.
Имхо функция сначала была просто плохой и непонятной, а после этого "патча", она стала совсем плохой и ещё менее понятной для программиста. И проблема не в квалификации читающего. Я изо всех сил пытался удержаться от комментария по поводу "15 лет программирования", но не смог. Мне кажется, за 15 лет такие функции должны начать вызывать неприятные чувства.
Более того, тот "голос", который говорит в моей голове при чтении и осмыслении кода, использует другие "слова", другой порядок, совершенно другой подход. Для меня чтение вот таких объяснений это как слушать лекцию человека с неприятным тебе голосом, или с некомфортным темпом рассказа, или с фокусом совершенно не на то, что тебе интересно.
Как по мне, так функция показывает признаки некоторых более глобальных изъянов, и вот один из них:
"enrich", похоже, сильно зависит от порядка вызова.
ответ наверное должен бы быть
{ a: 21, b: 8, c: 16 }
а этот пример "сломается" на переменной "a", т.к. "c" ещё не определена, хотя будет определена "попозже".
И в чём польза этого текстового описания для кода? Его всё равно надо осмыслить и загрузить себе в мозг, чтобы потом произвести нужное изменение. Так может проще прочитать код?
Global Talent бывает двух типов: "Exceptional" и "Promising". Для пооучения ILR На Promising надо прожить 5 лет, на Exceptional – 3 года.
Про быстродействие чушь какая-то, и вообще в статье много сомнительных заявлений
вроде нужны будут какие-то хаки для нажатия шифта на одной половине, и буквы на другой
Recourse ?
мне в google stadia было очень дискомфортно в гонки играть из-за задержки, а тут настоящую машину по улице везти
Зачем в работающем приложении на горячую обновлять локализацию? Никто не умрёт, если новая локализация применится при следующем перезапуске. Зато сколько жизни можно сэкономить не поддерживая такую маргинальную фичу.
Итак, вот мой вариант:
мы вроде согласились, что отдельный файл не нужен, поэтому обновляется только Info.plist;
Info.plist по дефолту ищется в текущей рабочей директории, или его можно передать аргументом
-infoPlist
;json с данными может читаться из трёх источников:
updater -from https://....
– URL в интернете;updater -from /local/path/on/disk
– файл на диске;updater -from -
(dash) или же без аргументов – прочитается из stdin.curl url | updater
;cat file | updater
;updater < file
;updater
и ввод с завершающим Ctrd+D;команда для удаления тоже не нужна, т.к. это просто "записать пустой массив", и это можно сделать как
echo "[]" | updater
;сохраняет тот же формат файла Info.plist (xml или бинарный).
Разве что это проблема для тех, кто парсит такие файлы регулярками, но это исправимо.