Creo que la mayoría de los lectores no tienen problemas de visión, pero me pregunto qué sucederá si su visión falla. Debería haber una imagen, pero no la veo, así que aquellos interesados en cómo codificar sin mirar la pantalla, les pido un gato.
Sucedió que desde la infancia tengo una agudeza visual muy baja. Parece que veo el panorama general sin ningún foco con mucho ruido.
Soy graduado del Instituto de Matemáticas, Mecánica y Ciencias de la Computación. Ahora estoy desarrollando una aplicación para el reconocimiento de dispositivos médicos.
Al final de la escuela, decidí ir a estudiar como programador, realmente me gustó, y todavía me gusta, jugar con una computadora. No solo quería usar las manualidades de otras personas, sino también aprender a hacer aplicaciones yo mismo.
Para entonces, ya era un usuario experimentado de Windows. Desde el punto de vista de un usuario ciego, controlé con confianza la computadora usando ambos lectores de pantalla, que se analizarán a continuación. Desde el punto de vista del usuario vidente, sabía qué y dónde podía ajustar el sistema para que volviera a funcionar, e incluso obtuve los primeros ingresos de esto.
Para calificar texto desde una pantalla de computadora, se utilizan aplicaciones especiales (lectores de pantalla) . En Windows, los más populares son Jaws de Freedom Scientific y NVDA de código abierto . . El sistema de Windows, incluso en ese momento, ya estaba arreglado para que fuera posible usarlo completamente solo con ambos lectores de pantalla.
Por supuesto, cuando se trataba de elegir biografías o reinstalar el sistema, tenía que obtener la ayuda de personas videntes.
En desarrollo, el círculo de problemas se ve un poco diferente.
Escritura de código
El código, por supuesto, se puede escribir en el bloc de notas en Windows, ya que Jaws y NVDA lo expresan muy bien. Pero más allá del marco de Pascal, en el que, como regla, se nos enseñan los conceptos básicos de la programación sin autocompletar en absoluto.
Todas las tareas las realicé solo en mi computadora, porque no quería atormentar a los administradores en los laboratorios con la instalación de NVDA, y simplemente no dije nada sobre el precio de Jaws.
El ambiente ABC de Pascal se expresó lo suficiente para la teoría que nos enseñaron. El foco del lector de pantalla es un punto tan abstracto que indica el área de la GUI que el lector de pantalla ahora expresa, encaja bien en el campo del editor de texto, y cuando se compiló e inició con éxito, se trasladó a la consola. Si no tiene éxito, los milagros comenzaron a usar varios trucos del lector de pantalla, que no sobrecargaré al lector en este artículo.
Justo al final de estudiar este tema, mi computadora portátil se dividió en una cubierta y el resto, y en esto se detuvo todo mi desarrollo en Windows. Lo único que puedo decir de lo que he intentado usar para el desarrollo desde Windows desde IDEs serios es que solo Visual Studio normalmente se expresa desde la versión 2015. Y todas las funciones convenientes, como la finalización automática, solo están disponibles con mandíbulas pagas.
Entonces La computadora portátil fiel es derrotada, se necesita un nuevo caballo de guerra.
La siguiente máquina que tuve fue una MacBook. Sé que es costoso, pero en primer lugar fueron aquellos años en que se dieron unos 30 Yaroslavl por un McKinley, y en segundo lugar, simplemente no es más conveniente para los ciegos.
Desde entonces, hasta el día de hoy que he estado desarrollando en Xcode, se ha expresado excelentemente con VoiceOver , aunque es muy limitado en la elección del lenguaje de desarrollo: C, C ++, Objective-C y Swift. No importa cuánto soñé con comenzar a escribir mierda en Python, simplemente no funciona. En Visual Studio para Mac, Python aún no se ha entregado, y VSCode, sin importar cuánto canten los desarrolladores, se expresa de tal manera que sería mejor no hacerlo. T.E. Si la aplicación no se expresa, el lector de pantalla expresa campos o botones vacíos, o es completamente silencioso, en VSCode la interfaz se ve como una mezcla de elementos que son incomprensibles, completamente no relacionados, la mitad no hace clic, la mitad muestra algunos marcos nuevos casi en El otro extremo de la ventana.
Proceso de desarrollo
El comienzo del desarrollo no difiere en absoluto de lo que todos hacen: crear un proyecto, crear un repositorio, si es necesario, especialmente porque el Xcode GIT crea el repositorio en sí.
Como dije anteriormente, Xcode está limitado en su elección de lenguaje, por lo que, por regla general, uso C ++ o Swift.
Xcode crea el archivo Main y describe la función Main en sí.
Al igual que todos los demás, agrego archivos según sea necesario, pero aquellos que, desafortunadamente, no se pueden evitar en el desarrollo de proyectos complejos, son autocompletados, comenzando por fragmentos de varias partes del código, como descripciones de clases o bucles que simplemente aceleran el desarrollo y terminan con métodos o funciones de clase con nombres largos y pegadizos que son muy difíciles de mantener en tu cabeza sin acceso a la memoria visual.
Depuración
El código escrito debe ser depurado. Bueno, cuando después de escribir el proyecto se reunieron, el programa comenzó e inmediatamente funcionó correctamente, pero ¿cuándo fue?
En primer lugar, los errores sintácticos, semánticos y de puntuación. El navegador de errores en Xcode está disponible, y al resaltar un error específico, mueve el cursor de edición a la línea deseada, pero es malo que no muestre el número del carácter donde vio este error o no pronuncie su VO, y solo permanezca .
Quiero decir por separado para los corchetes, por lo que sé, los videntes también sufren corchetes adicionales abiertos o cerrados, pero si la persona vidente puede tratar de identificarlos visualmente, si aún aprendió algo y no ensucia, pero el código escribe, descubrirá la confusión del corsé . Sin ojos: esto es malo, ayudar parcialmente es que los fragmentos generalmente incluyen la cantidad necesaria de corchetes, y un IDE atento los cierra si el usuario los abre, pero aquí son posibles los errores.
La única forma es cortar el cuerpo de la función desde el principio, para comenzar, si es así, devolver el cuerpo, y así sucesivamente con cada bloque de código, hasta que se detecte el paréntesis.
El proyecto se ensambló, el programa se inició y [LLDB] apareció en la consola a continuación en lugar del "programa finalizado con el código de salida: 0" esperado y deseado, no puedo usar el depurador de bajo nivel, por lo que percibo esta inscripción para que haya algo en la lógica del programa salió mal
Los mensajes del depurador rara vez se entienden. Por lo tanto, puede pinchar todo el programa con puntos de interrupción, pero sin ser visto, es muy difícil entender en qué punto se detuvo o en qué lugar se bloquea el programa. Por lo tanto, personalmente organizo conclusiones como "prueba #" en diferentes partes de Main, si la aplicación no muestra nada, si se muestra, organizo conclusiones donde la aplicación se bloquea, por ejemplo, comenzando desde la entrada a una función sospechosa, y veo a qué salida llega el programa , después de lo cual solo queda detectar el error entre la conclusión alcanzada y la no alcanzada.
Al realizar una tarea de prueba para una compañía, dominé el panel Vista de variables, este es un panel de este tipo en el área del depurador, que muestra variables en vivo si se establece un punto de interrupción, gracias a él analicé el json serializado en un diccionario, con una matriz integrada de diccionarios.
Control de versiones
Xcode en sí mismo puede funcionar con GIT, pero hay cosas que se hacen mejor a través del terminal.
Terminal
La terminal en Mac tiene voz, quiero decir estándar. Por supuesto, no es conveniente cuando VO dice todo el texto que se muestra, pero usando las capacidades de VO puedes escuchar la salida por palabras, líneas e incluso por caracteres. Por lo tanto, puede usar el terminal, e incluso uno de los editores de texto de la consola, nano expresado de manera brillante. Además, el terminal sonoro permite que el programador ciego use administradores de paquetes como Home brew o cocoapods.
Conclusión
Al tener problemas de visión, puede convertirse o seguir siendo un desarrollador. Hay un número suficiente de diferentes programas de acceso a la pantalla para diferentes plataformas: Jaws, NVDA y Narrator para Windows, orca en GNOME para Linux, VoiceOver en Mac y editores de código con voz, como: Visual Studio en Windows y Xcode en Mac. Especialmente porque hay informes de que agregan accesibilidad a algún editor, y estoy seguro de que con el tiempo, VSCode y otras Ideas pueden ser utilizadas por desarrolladores ciegos.
Entonces, por supuesto, cuide su vista de todas las maneras posibles, pero si sucedió, no tendrá que abandonar la profesión, solo tendrá que adaptarse a los programas de acceso a la pantalla y adoptar mi enfoque o inventar el suyo.
Si está interesado, escriba en los comentarios qué áreas de desarrollo le interesan ciegamente y las cubriré en futuros artículos. Estoy pensando en escribir sobre cómo desarrollo una GUI, pero estoy abierto a sus sugerencias.