Code development without looking

I think that most readers do not have vision problems, but wonder what will happen if their vision fails. There should be a picture, but I don’t see it, so those interested in how to code without looking at the screen, I ask for a cat.

It so happened that since childhood I have a very low visual acuity. It looks as if I see the big picture without any focus with a lot of noise.

I am a graduate of the Institute of Mathematics, Mechanics and Computer Science. Now I’m developing an application for recognition of medical devices.

At the end of the school, I decided to go to study as a programmer, I really liked, and still like, messing around with a computer. I wanted not only to use other people's crafts, but also to learn how to make applications myself.

By that time, I was already an experienced Windows user. From the point of view of a blind user, I confidently controlled the computer using both screen readers, which will be discussed below. From the point of view of the sighted user, I knew what and where I could tweak in the system so that it worked again, and even had the first income from this.

For scoring text from a computer screen, special applications (screen readers) are used . Under Windows, the most popular are Jaws from Freedom Scientific and open source NVDA. . The Windows system even at that time was already arranged so that it was possible to use it fully only using both screen readers.

Of course, when it came to tinkering with bios or reinstalling the system, you had to get help from sighted people.

In development, the circle of problems looks a little different.

Code writing

The code, of course, can be written in notepad on Windows, since it is very well voiced by both Jaws and NVDA. But beyond the framework of Pascal, on which we, as a rule, are taught the basics of programming without auto-completion at all.

All the tasks I performed only on my computer, because I did not want to torment the admins in the laboratories with the NVDA installation, and I just am silent about the price of Jaws.

The Pascal ABC environment was voiced sufficiently for the theory that we were taught. The focus of the screen reader is such an abstract point that indicates the area of ​​the GUI that is now voiced by the screen reader, it itself fit well in the text editor field, and when it was successfully compiled and launched, it moved to the console. If unsuccessful, miracles began using various tricks of the screen reader, which I will not overload the reader with in this article.

Just at the end of studying this topic, my laptop divided into a cover and the rest of it, and on this all my development on Windows stopped. The only thing I can say, from what I have ever tried to use for development on Windows from serious IDEs, only Visual Studio is normally voiced since the 2015th version. And all the convenient features, such as auto-completion, are only available using paid Jaws.

So. The faithful laptop is defeated, a new war horse is needed.

The next machine I had was a MacBook. I know it’s expensive, but firstly it was those years when about 30 Yaroslavl were given for one McKinley, and secondly, it’s simply not more convenient for the blind.

Since then, to this day I have been developing in Xcode, it has been excellently voiced using VoiceOver , though it is very limited in the choice of the development language: C, C ++, Objective-C and Swift. No matter how much I dreamed of starting shit-writing in Python, it just doesn't work. In Visual Studio for Mac, Python has not yet been delivered, and VSCode, no matter how much developers sing, is voiced in such a way that it would be better not to be voiced. THOSE. If the application is not voiced, the screen reader either voices empty fields or buttons, or is completely silent, in VSCode the interface looks like a mishmash of elements that are incomprehensible, completely unrelated, half do not click, half brings up some new frames almost in the other end of the window.

Development process

The beginning of development does not differ at all from what everyone does: creating a project, creating a repository, if required, especially since the Xcode GIT creates the repository itself.

As I said above, Xcode is limited in its choice of language, so as a rule I use either C ++ or Swift.

Xcode itself creates the Main file and describes the Main function itself.

Like everyone else, I add files as needed, but those, unfortunately, can not do without the development of complex projects, these are auto-completion, starting from snippets of various parts of the code, such as descriptions of classes, or loops that just speed up development, and ending with class methods or functions with long catchy names that are simply very difficult to keep in your head without access to visual memory.

Debugging

Written code needs to be debugged. Well, when after writing the project got together, the program started and immediately worked correctly, but when was it?

Firstly, syntactic, semantic and punctuation errors. The error navigator in Xcode is available, and while highlighting a specific error, it moves the editing cursor to the desired line, but it’s bad that it either does not show the number of the symbol where it saw this error, or does not pronounce its VO, and only remains .

I want to say separately for the brackets, as far as I know, the sighted also suffer from extra open or closed brackets, but if the sighted person can try to visually identify them, if he still learned something and not mess, but the code writes, he will figure out the brace confusion . Without eyes - this is bad, partially helping out is that snippets usually include the required number of brackets, and a caring IDE closes the brackets if the user opens them, but here errors are possible.

The only way is to cut out the body of the function from the beginning, start, if it is, return the body, and so on with each block of code, until the bracket is detected.

The project was assembled, the program started, and [LLDB] appeared in the console below instead of the expected and desired "program ended with exit code: 0", I can’t use the low level debugger, so I perceive this inscription so that there is something in the program logic gone wrong.

Debugger messages are rarely understood. Therefore, you can poke the entire program with breakpoints, but without being sighted, it is very difficult to understand at what point you stopped, or at what place the program crashes. Therefore, I personally arrange conclusions like "test #" in different parts of Main, if the application does not display anything, if it displays, I arrange conclusions where the application crashes, for example, starting from the entrance to a suspicious function, and see what output the program reaches , after which it remains only to catch the error between the conclusion reached and not reached.

Performing a test task for one company, I mastered the Variable View panel, this is such a panel in the debugger area, in which live variables are displayed if a breakpoint is set, thanks to it I parsed serialized json into a dictionary, with an embedded array of dictionaries.

Version control

Xcode itself can work with GIT, but there are things that are best done through the terminal.

Terminal

The terminal on Mac is voiced, I mean standard. Of course, it’s not convenient when VO speaks all the displayed text, but using the capabilities of VO you can listen to the output by words, lines and even by characters. So you can use the terminal, and even one of the console text editors, nano is voiced simply brilliantly. In addition, the voiced terminal allows the blind programmer to use package managers such as Home brew or cocoapods.

Conclusion

Having vision problems, you can become or remain a developer. There are a sufficient number of different screen access programs for different platforms: Jaws, NVDA and Narrator for Windows, orca in GNOME for Linux, VoiceOver on Mac, and code editors that are voiced, such as: Visual Studio on windows and Xcode on Mac. Especially since there are reports that they add accessibility to some editor, and I'm sure that over time, VSCode and other Ideas can be used by blind developers.

So, of course, take care of your eyesight in every possible way, but if everything happened, you won’t have to leave the profession, you just need to adapt to screen access programs and take my approach or invent your own.

If you are interested, write in the comments which areas of development you are blindly interested in, and I will cover them in future articles. I’m thinking of writing about how I develop a GUI, but I am open to your suggestions.