Codificação cega – Comunidade de dev

Eu quero falar sobre como é codificar principalmente cegos. Isso é especialmente verdadeiro para mim, pois minha visão continua a piorar e minhas chances de qualquer cirurgia corretiva continuam a recuar e, de qualquer maneira, se mostraram agora impossivelmente caras. É claro que o que constitui cego, com deficiência visual, etc., é uma faixa muito ampla. Ser incapaz de distinguir n de m pode ser um problema muito menor, mas acho que não ser mais capaz de atravessar uma rua com segurança, porque não consigo ver os carros que se aproximam estão mais próximos dos cegos. Primeiro, embora eu queira escrever sobre isso separadamente, esqueça a própria ideia que alguém vai querer que você trabalhe para eles. Mesmo com deficiência modesta, se eles descobrirem durante uma entrevista, também o tratarão horrivelmente. Se eles descobrirem mais tarde, serão rápidos em demiti -lo, por mais eficaz que você seja. Nos EUA, o ódio dos deficientes só cresceu recentemente. Atualmente, pedir acomodações como dizer “não quero trabalhar aqui”, e eles estão muito conscientes das leis trabalhistas federais não estão mais efetivamente aplicadas. As empresas de tecnologia também parecem algumas das piores. Acho que trabalho com mais eficácia, visualizando o código em minha mente. Isso é fácil com idiomas que se representam corretamente. Eu posso fazer isso com C/C ++ e, especialmente, ir, como idiomas imperativos, e Haskell como uma linguagem funcional declarativa. É por isso que continuo enfatizando a sintaxe e a representação correta é muito importante, seja escrevendo, lendo outro código ou tentando depurar erros lógicos. O maior problema para mim é digitar. Tendo uma idéia clara do que está em minha mente, agora tenho que transferi -lo para um editor com visão muito marginal, onde tudo o que vejo, mesmo com o monocromático, ainda está agora embaçado. Toque ajuda, mas quando você comete erros simples, eles são tão difíceis de ver. Os editores que verificam ao vivo apenas criam interrupções e pop -ups que também podem estar embaçados e distrair esse fluxo de trabalho. Ao corrigir o código posterior, o VSC pode realmente ser mais útil para mim, mas, para diminuir a maior parte da maior parte, tenho que ir da mente para o editor com o mínimo de interferência possível. O que eu descobri que funciona para mim é realmente ter a leitura de prova de IA e corrigir meus erros de digitação para mim, ou mesmo explicar os erros estranhos do compilador que não consigo ver corretamente. E com C ++, especialmente, você pode obter alguns erros enormes e estranhos. Às vezes, ele quer refatorar o que eu escrevo ou “sugerir alterações” que geralmente estão realmente erradas, mas descobri como solicitá -lo a me dar um texto corrigido, mas de outra forma inalterado. Trabalhando dessa maneira, entre visualizações e prova, agora codio mais rápido e de maneira mais confiável do que com a visão mais normal. Esse desejo de editores monocromáticos simples é o motivo pelo qual costumo escolher Vim. Mas direi que o código do Visual Studio também pode ser uma dádiva de Deus para o comprometimento visual depois de desativar alguns dos recursos mais perturbadores. Às vezes, ter o Typeahead Smart também é útil. Ele sabe como dimensionar sua interface do usuário e tem um modo de alto contraste que realmente funciona razoavelmente bem para mim. Até atrai as linhas de fronteira que os designers modernos de interface do usuário parecem ter decidido remover, porque tons de impossível distinguir cinzas são toda a raiva. Outra ótima ferramenta que funcionou para mim é LibreOffice. Sou capaz de desenhar efetivamente diagramas de design no modo de alto contraste. No entanto, como deixa tudo em preto e branco, nem sempre fica claro como o que você está desenhando realmente parecerá até terminar e exportá -lo para outra coisa, como um PNG. Eu também desejo no modo de alto contraste, ele também fez as setas para linhas; De alguma forma, perdi corrigi -las no modo de alto contraste, e notei muito que, ao fazer um documento de design. Em relação ao design adequado da interface do usuário, uma plataforma que funciona muito bem é uma área de trabalho X11 antiga. Naquela época, eles faziam bordas adequadas e o preto era realmente preto, não apenas cinza escuro, tornando o texto ainda mais embaçado. Splashes de imagens gráficas como o X11 costumavam fazer são boas para mim, mas os sites que têm imagens na frente e na sua cara são realmente cegos para mim, e não consigo ler qualquer texto sobre isso agora. O formato X11 XPM também é texto! Eu posso fazer uma interface do usuário da área de trabalho assim novamente. O Windows oferece uma experiência de acessibilidade bem, mas inconsistente. Existem diferentes peças que parecem escritas com diferentes kits de ferramentas, algumas das quais conhecem e usam temas, configurações de alto contraste e seleções de tamanho de fonte, e outras (como o Explorer File Manager) que não o fazem. Mas quando e foram as configurações de acessibilidade são suportadas, esses aplicativos funcionam muito bem. É por isso que mudei do NSIS para o Innostup para minhas compilações do Mingw32 Installer. Alguns afirmam que o MacOS é o “padrão -ouro” para a acessibilidade do computador. Não sei, porque quando você é cego, a última coisa que você pode pagar é algo caro, para começar, e menos de tudo, algo que deve ser recompensado a cada cinco anos. Embora os desktops X11 mais antigos e até o Gnome 2 fossem ótimos para acessibilidade e, há 25 anos, usuários cegos da American Foundation for the Blind puderam trabalhar em computadores pela primeira vez usando o GNOME 2, o Modern Linux / Wayland Desktops é absolutamente péssimo. Alguns anos atrás, ao lidar com o fato de que a Orca não funcionou mais em Wayland e que o modo de “acessibilidade” do Gnome com o tema que quebra a biblioteca para colorir Adwaita, quando o alto contraste é ativado, substituiu temas escuros por um texto escuro sobre os brancos puro que, para mim, para mim, e efetivamente, um reconfortável e simplificado. É claro que isso é como a acessibilidade ficou quebrada no Ubuntu 24.04. Ao contrário do GNOME, o KDE se preocupa com a acessibilidade, mas eles têm desafios especiais. O núcleo qml QT nunca foi projetado corretamente para aplicativos que poderiam oferecer modos de acessibilidade, a menos que você reescreva uma interface de interface do QML alternativa do zero para cada estojo de uso. Em vez disso, a KDE tem trabalhado na acessibilidade em Kirigami, que fica acima do QML, e em outros lugares como esse. Isso também requer acessibilidade para ser implementado em cada aplicativo. Mas pelo menos eles realmente se importam!

Fonte