Розробка на швидкості 450 слів на хвилину

«Чогось тут не вистачає». Сперечаємося, така думка першою прийде у вашу голову, якщо побачите моє робоче місце в офісі. Тут немає монітора і миші. Є тільки хлопець, який молотить по клавіатурі, дивлячись немов у порожнечу.

Це всього лише я, і мої колеги гарантують вам, що я зазвичай не небезпечний. Я програміст в офісі компанії Vincit в Тампере (Фінляндія). І ще я сліпий. У цій статті хочу трохи розповісти, як я працюю.

Ти сліпий в тому сенсі що насправді сліпий?

Правильно. Я можу сприймати сонячне світло і деякі дуже яскраві лампи, але це все. По суті, нічого корисного для роботи.

Що ти там робиш?

Те саме, що й усі: роблю софт і жартую над колегами, якщо час дозволяє. Я працював над full-stack веб-проектами з фокусом на бекенді. Я також взяв на себе роль консультанта щодо загальної доступності проектів для людей з обмеженими можливостями - або роль поліції; залежно від того, як подивитися.

Як ти використовуєш комп'ютер?

У мене абсолютно звичайний ноутбук під Windows 10. Вся «магія» в софті. Для доступу до комп'ютера я використовую програму, яка називається скрінрідер. Він перехоплює картинку з екрану і представляє інформацію в азбуці Брайля (через окремий брайлівський дисплей) або синтез мови. І це не та синтетична мова, яку ви чуєте від нинішніх цифрових помічників. Я використовую роботизований голос, який вимовляє приблизно 450 слів на хвилину. Для порівняння, носії англійської мови зазвичай вимовляють 120-150 слів на хвилину. У моїй системі є одна особливість: оскільки мені потрібно регулярно читати і фінською, і англійською, то я читаю англійську з фінським синтезатором мови. У попередні часи скрінрідери були недостатньо розумні, щоб автоматично перемикатися між мовами, так що я звик до такого читання. Ось приклад цього параграфа так, як я його чую. А ось той же текст через англомовний синтезатор мови.

Природно, миша не особливо мені корисна, так що я працюю тільки з клавіатурою. Мої клавіатурні команди повинні бути знайомі кожному, хто читає цю статтю: стрілки, клавіша Tab для навігації всередині вікна, Alt + Tab для перемикання між вікнами тощо. Ще у скрінрідерів є багато власних «гарячих клавіш», наприклад, для читання різних частин активного вікна, включення/вимикання деяких власних функцій.

Все стає трохи цікавіше при читанні веб-сторінок та інших форматованих документів. Скрінідер дає цю інформацію шматками. Цей шматок найчастіше буває рядком, але може бути словом, символом або іншим довільним фрагментом тексту. Наприклад, якщо я натисну вниз на веб-сторінці, то почую наступний рядок тексту: Такий тип читання означає, що я не можу просто просканувати вміст екрану таким же способом, як це робить зрячий. Мені доводиться читати все шматок за шматком або пропускати шматки, які мені не потрібні.

Одні лише промову або Брайль не дозволяють точно передати, як виглядає сторінка. Вся інформація видається мені лінійним чином. Якщо ви скопіюєте веб-сторінку і вставите її в «Блокнот», то отримаєте загальне враження, як вона виглядає для мене. Це просто купа рядків один на одному майже без форматування. Однак скрінрідер може підібрати семантику з HTML, так що посилання, заголовки, поля форм та інше коректно мені оголошується. Це так: я не знаю, що чекбокс є чекбоксом, якщо його стиль не прописаний таким чином. Однак детальніше про це поговоримо пізніше; я присвячу цілу статтю цій темі. Просто пам'ятайте, що наведений мною приклад - це злочин проти людства.

Значну частину свого часу я проводжу в командному рядку. Насправді я рідко використовую якісь графічні програми, крім веб-браузера і редактора. Я виявив, що часто набагато швидше виконати завдання вручну в командному рядку, ніж використовувати інтерфейс, який спроектовано з думкою про користувачів миші.

Отже, враховуючи мою любов до командного рядка, чому я застряг на Windows, операційній системі, яка не славиться своїми інструментами командного рядка? Відповідь проста: Windows - найдоступніша система [для людей з обмеженими можливостями - прим. пер.]. Мій улюблений скрінідер NVDA - це вільний софт, він підтримується більш активно, ніж будь-який інший скрінрідер. Якби у мене б вибір, я б використовував Mac OS, по-моєму, там акуратний баланс між зручністю і функціональністю. На жаль, скрінідер для цієї системи VoceOver страждає від довгих релізів і загальної занедбаності, а його моделі навігації не дуже сумісна з моїм конкретним стилем роботи. Є також скрінрідер для десктопу Gnome і хоча він чудово підтримується для такої малої аудиторії користувачів, там все ще залишилися гострі кути, через що він не підходить мені для постійного використання. Так що тільки Windows. Я компенсую властиві недоліки цієї ОС тим, що живу всередині Git Bash, який поставляється з відмінним набором GNU та інших утиліт командного рядка відразу з коробки.

Як ти можеш кодувати?

Мені знадобилося досить багато часу, щоб зрозуміти, чому це питання настільки важливе для багатьох людей. Пам'ятаєте, що я раніше говорив про читання тексту рядок за рядком? Так я читаю код. Я пропускаю непотрібні рядки або може прослуховую тільки половину заради контексту, але якщо мені дійсно потрібно розібратися, то я читаю все як роман. Природно, я не можу прочитати таким способом гігантську кодову базу. У цих випадках доводиться абстрагувати частини коду в розумі: цей компонент приймає x на вході і повертає y, неважливо, що він реально робить.

Такий тип читання змушує мене виконувати деякі завдання інакше, ніж мої зрячі колеги. Наприклад, у процесі інспекції коду я вважаю за краще дивитися на видачу raw diff по можливості. Діффи side-by-side не дуже корисні для мене, насправді, вони навіть відволікають. Знаки «плюса» і «мінуса» теж набагато кращий індикатор змінених рядків, ніж виділення кольором. Не тому що я не можу прочитати назви кольорів. Просто «плюс» вимовляється швидше, ніж назва якогось хитромудрого відтінку червоного, який використовується для доданого рядка. (Я дивлюся на тебе, Герріт).

Ви можете подумати, що відступи та інше форматування залишиться повністю непомітним для мене, оскільки це візуальне виділення. Неправильно: правильні відступи допомагають мені точно так само, як зрячому програмісту. Якщо я читаю код у Брайлі (до речі, це набагато ефективніше, ніж мова), то це дає хороший візуальний ключ, де я перебуваю, точно так само, як і зрячому програмісту. Я також отримую голосові повідомлення, якщо входжу в блок тексту з відступом або без. Ця інформація допомагає розмалювати карту коду в голові. Насправді першою справжньою мовою програмування у мене був Python (PHP не вважається), з тих пір відступи ніколи не були проблемою. Я наполегливо виступаю за чистий і послідовний стиль програмування з багатьох причин, але головним чином тому що це не ускладнює до межі моє життя.

Який редактор ти віддаєш перевагу?

Спойлер: відповідь на це питання не починається ні з літери V, ні з E. (Само собою, я використовую Vim для складання повідомлень про комміти git та інших швидких позначок в командному рядку. Я дотримуюся нейтралітету на цьому конкретному мінному полі). Рік тому серед усіх редакторів я б вибрав Notepad++. Це легкий, добре спроектований текстовий редактор, який робить свою справу. Однак рік тому я ще не працював над великомасштабним Java-проектом. Коли це все-таки сталося, прийшов час вибирати між Notepad++ і здоровим глуздом. У підсумку я схилився до другого (на той час, який зможу) і кинув Notepad++ заради IntelliJ IDEA. Відтоді це мій обраний редактор. У мене глибоко вкорінена огида до всіх IDE, тому що більшістю з них або неможливо, або неефективно користуватися тільки з клавіатури. Швидше за все, я б перейшов на IDE набагато раніше, якби був зрячим.

Ви можете запитати, чому я вибрав Notepad++. Є ж більш просунуті легковагові редактори, такі як Sublime Text або Atom. Відповідь проста: жоден з них не доступний для скрінрідерів. Текстові редактори на кшталт Vim теж не варіант, тому що у мого скрінідера деякі проблеми з підтримкою консольних додатків, через які ці редактори неможливо використовувати для чогось більшого, ніж повідомлення про комміт. На жаль, доступність [для незрячих - прим. пер.] - це головний фактор для моїх інструментів. Якщо я не можу використовувати інструмент ефективно, то він вже не розглядається.

Ти коли-небудь працював з кодом фронтенду?

Ви можете подумати, що фронтенд-розробка настільки візуальна за своєю природою, що тут немає місця сліпому розробнику, і здебільшого так і є. Я сам не створюю базові концепти, тому що в цих проектах потрібно, в основному, створити правильний вигляд, а функціональність додається пізніше.

Однак у мене теж є шматок роботи в Angular і React. Як так? У багатьох сучасних веб-додатках значна частина роботи виконується під капотом у браузері. Наприклад, одного разу я пару тижнів впроваджував підтримку інтернаціоналізації в досить складний додаток Angular. Там не було взагалі ніякої візуальної роботи.

Я виявив, що бібліотеки на зразок Bootstrap - справжня знахідка для мене. Завдяки грід-системі я можу сам зробити базову версію користувацького інтерфейсу. Незважаючи на це, всі підготовлені мною зміни інтерфейсу проходять через пару очей, перш ніж поставлятися в продакшн. Отже, підбиваючи підсумок: я можу працювати з фронтендом до певної міри, принаймні, не особливо чіпаючи рівень уявлення.

Що щодо речей, про які ти не розповів?

Безумовно, багато речей довелося залишити за рамками цієї статті. Як і обіцяв, я присвячу статтю мистецтву робити веб-сторінки більш доступними, оскільки відсутність правильної семантики - моя улюблена мозоль. Але є велика ймовірність, що я на цьому не зупинюся. Будемо на зв'язку!