Acho que a maioria dos leitores não tem problemas de visão, mas imagina o que acontecerá se a visão deles falhar. Deveria haver uma imagem, mas eu não a vejo; portanto, aqueles interessados em codificar sem olhar para a tela, peço um gato.
Aconteceu que desde a infância eu tenho uma acuidade visual muito baixa. Parece que eu vejo a foto grande sem nenhum foco com muito ruído.
Sou formado pelo Instituto de Matemática, Mecânica e Ciência da Computação. Agora estou desenvolvendo um aplicativo para reconhecimento de dispositivos médicos.
No final da escola, decidi estudar como programador, gostei muito e ainda gosto de brincar com um computador. Eu queria não apenas usar o artesanato de outras pessoas, mas também aprender como fazer aplicativos.
Naquela época, eu já era um usuário experiente do Windows. Do ponto de vista de um usuário cego, eu controlei o computador com confiança usando os dois leitores de tela, que serão discutidos abaixo. Do ponto de vista do usuário que enxerga, eu sabia o que e onde eu poderia ajustar o sistema para que funcionasse novamente e até obtivesse a primeira receita disso.
Para pontuação de texto na tela do computador, são utilizados aplicativos especiais (leitores de tela) . No Windows, os mais populares são o Jaws da Freedom Scientific e o NVDA de código aberto . . O sistema Windows, mesmo naquela época, já estava organizado, de modo que era possível usá-lo totalmente apenas com os dois leitores de tela.
Obviamente, quando se tratava de escolher bios ou reinstalar o sistema, você precisava da ajuda de pessoas com visão.
No desenvolvimento, o círculo de problemas parece um pouco diferente.
Escrita de código
O código, é claro, pode ser escrito em um bloco de notas no Windows, pois é muito bem dublado tanto pelo Jaws quanto pelo NVDA. Mas além da estrutura de Pascal, na qual, em regra, aprendemos o básico da programação sem a conclusão automática.
Todas as tarefas que eu executei apenas no meu computador, porque eu não queria atormentar os administradores nos laboratórios com a instalação do NVDA, e fiquei em silêncio sobre o preço do Jaws.
O ambiente de Pascal ABC foi suficientemente expresso para a teoria que nos foi ensinada. O foco do leitor de tela é um ponto abstrato que indica a área da GUI que agora é dublada pelo leitor de tela, ela se encaixa bem no campo do editor de texto e, quando foi compilada e iniciada com sucesso, foi movida para o console. Se malsucedido, os milagres começaram a usar vários truques do leitor de tela, com os quais não sobrecarregarei o leitor neste artigo.
No final do estudo deste tópico, meu laptop foi dividido em uma capa e o resto, e nisso todo o meu desenvolvimento no Windows parou. A única coisa que posso dizer pelo que tentei usar para o desenvolvimento do Windows a partir de IDEs sérios é que apenas o Visual Studio normalmente é dublado desde a versão 2015. E todos os recursos convenientes, como o preenchimento automático, estão disponíveis apenas com o Jaws pago.
Então O laptop fiel é derrotado, é necessário um novo cavalo de guerra.
A próxima máquina que eu tinha era um MacBook. Eu sei que é caro, mas primeiro foram os anos em que foram dados cerca de 30 Yaroslavl por um McKinley e, segundo, simplesmente não é mais conveniente para os cegos.
Desde então, até hoje que desenvolvo o Xcode, ele foi excelente em voz alta usando o VoiceOver , embora seja muito limitado na escolha da linguagem de desenvolvimento: C, C ++, Objective-C e Swift. Não importa o quanto eu sonhava em escrever merda em Python, simplesmente não funciona. No Visual Studio para Mac, o Python ainda não foi entregue, e o VSCode, não importa o quanto os desenvolvedores cantem, é exibido de uma maneira que seria melhor não ser exibido. T.E. Se o aplicativo não for exibido, o leitor de tela ouve campos ou botões vazios ou fica completamente silencioso. No VSCode, a interface parece uma mistura de elementos incompreensíveis, completamente independentes, metade não clica, metade traz novos quadros quase a outra extremidade da janela.
Processo de desenvolvimento
O início do desenvolvimento não difere em nada do que todos fazem: criar um projeto, criar um repositório, se necessário, especialmente porque o Xcode GIT cria o próprio repositório.
Como eu disse acima, o Xcode é limitado em sua escolha de idioma; portanto, como regra, uso C ++ ou Swift.
O próprio Xcode cria o arquivo principal e descreve a própria função principal.
Como todo mundo, adiciono arquivos conforme necessário, mas aqueles que, infelizmente, não podem ser evitados no desenvolvimento de projetos complexos, são de preenchimento automático, iniciando a partir de trechos de várias partes do código, como descrições de classes ou loops que simplesmente aceleram o desenvolvimento e terminam com métodos ou funções de classe com nomes longos e atraentes que são simplesmente muito difíceis de manter em mente, sem acesso à memória visual.
Depuração
O código escrito precisa ser depurado. Bem, quando, depois de escrever o projeto, o programa começou e imediatamente funcionou corretamente, mas quando foi?
Primeiramente, erros sintáticos, semânticos e de pontuação. O navegador de erros no Xcode está disponível e, ao realçar um erro específico, move o cursor de edição para a linha desejada, mas é ruim que ele não mostre o número do caractere em que ele viu esse erro ou não pronuncie seu VO e permanece apenas .
Eu quero dizer separadamente para os colchetes, até onde eu sei, os que sofrem de visão também sofrem com colchetes extras abertos ou fechados, mas se a pessoa com visão puder tentar identificá-los visualmente, se ainda aprendeu alguma coisa e não mexeu, mas o código escreve, ele descobrirá a confusão da órtese . Sem olhos - isso é ruim, parcialmente ajudando é que os trechos geralmente incluem o número necessário de colchetes, e um IDE cuidadoso fecha os colchetes se o usuário os abrir, mas aqui são possíveis erros.
A única maneira é cortar o corpo da função desde o início, iniciar, se for, retornar o corpo e assim por diante com cada bloco de código, até que o colchete seja detectado.
O projeto foi montado, o programa foi iniciado e o [LLDB] apareceu no console abaixo, em vez do esperado e desejado "programa terminou com o código de saída: 0", não consigo usar o depurador de baixo nível, então percebo essa inscrição para que exista algo na lógica do programa deu errado.
As mensagens do depurador raramente são entendidas. Portanto, você pode cutucar o programa inteiro com pontos de interrupção, mas sem ser avistado, é muito difícil entender em que ponto você parou ou em que local o programa trava. Portanto, eu organizo pessoalmente conclusões como "teste #" em diferentes partes do Main, se o aplicativo não exibir nada, se for exibido, organizarei conclusões nas quais o aplicativo trava, por exemplo, iniciando na entrada de uma função suspeita e ver qual saída o programa alcança. , após o que resta apenas detectar o erro entre a conclusão alcançada e a não alcançada.
Ao executar uma tarefa de teste para uma empresa, eu dominei o painel Variable View, este é um painel na área do depurador, que exibe variáveis ativas se um ponto de interrupção for definido, graças a isso eu analisei json serializado em um dicionário, com uma matriz incorporada de dicionários.
Controle de versão
O próprio Xcode pode funcionar com o GIT, mas há coisas que devem ser feitas melhor através do terminal.
Terminal
O terminal no Mac é dublado, quero dizer padrão. Obviamente, não é conveniente quando o VO fala todo o texto exibido, mas usando os recursos do VO você pode ouvir a saída por palavras, linhas e até caracteres. Assim, você pode usar o terminal e até mesmo um dos editores de texto do console, o nano dublado de maneira brilhante. Além disso, o terminal com voz permite que o programador cego use gerenciadores de pacotes, como Home brew ou cocoapods.
Conclusão
Tendo problemas de visão, você pode se tornar ou permanecer um desenvolvedor. Há um número suficiente de programas de acesso à tela diferentes para plataformas diferentes: Jaws, NVDA e Narrator para Windows, orca no GNOME para Linux, VoiceOver no Mac e editores de código que são dublados, como: Visual Studio no Windows e Xcode no Mac. Especialmente porque há relatos de que eles adicionam acessibilidade a algum editor, e tenho certeza de que, com o tempo, o VSCode e outras idéias podem ser usados por desenvolvedores cegos.
Portanto, é claro, cuide da sua visão de todas as maneiras possíveis, mas se isso acontecer, você não precisará abandonar a profissão, basta se adaptar aos programas de acesso à tela e seguir minha abordagem ou inventar a sua própria.
Se você estiver interessado, escreva nos comentários em quais áreas do desenvolvimento você está cegamente interessado, e eu os abordarei em artigos futuros. Estou pensando em escrever sobre como desenvolvo uma GUI, mas estou aberto a suas sugestões.