I first became interested in the MongoDB database because I was asked to develop a single page browser application that could display selected photographs for a group of 15 deaf individuals who may not have internet access, or at best very slow, limited internet access. These individuals would be living outside of the USA. They would see photos of things like: houses, animals, plants, foods. They were to record, in the sign language of their country, the subject of each photo. For example, suppose the deaf individual lives in Ethiopia, and he or she sees a photograph of a wooden table. The person would record the sign for this table, in Ethiopian sign language. Similarly, a deaf individual in Hong Kong would record the sign for this same photograph of a table, in the sign language of his cultural group. Signed languages used by deaf people are of interest to linguists.
How should I design and develop this application? The end user who might not have internet access and who might well be quite unsophisticated with computers. I'm personally unable to sign, write, or speak in any of the languages of the proposed users. This would hamper my ability to communicate instructions to them. How do I record and save the vocabulary that the project is asking the user to build? How should that recorded vocabulary be returned to the customer, one of a team of linguists? It might not be an option to transmit the data over the internet. The recorded vocabulary would be a video record, not a text-based one. It had to be recorded and stored and later given to the project sponsors in some way.
The first goal was to develop a set of photographs that could be displayed on a single-page web application. I wanted to install the entire application myself, onto 15 laptops running a Linux distribution such as Ubuntu. The physical laptops would be shipped to each of the 15 users. I did not want the user to have to do anything other than know how to turn on the computer and start the application. For example, I did not want the user to have to install the application. That would imply a graphical installer with text and buttons. I would have to tell the user, in his or her written language, the name of the installer file, and give textual instructions on how to start it. The very thought sent chills of fear through me.
When first starting out on the project, I was a conventional developer in at least one respect. I thought I would need a relational database that would join several tables to extract the information to be displayed for the user. Principally, this would be photographs, with a few words in that person's native language. I wanted a relational database with a small footprint, that could handle binary images, and also be locale-specific. The database engine has to be open sourced, since the project could not afford 15 licenses for the users. I started out with SQLite. However, using SQLite posed many programming problems when accessed through Node.js. It did not seem worthwhile to continue with SQLite as a database engine. It could have been that as a developer, I was inexperienced with relational databases as used with JavaScript. Frustrated, I wondered if there was a better database engine.
I learned of a database named MongoDB. I saw some example JSON documents. The document format was interesting. I took a beginning course in MongoDB for JavaScript developers, the "M101JS" course offered by MongoDB University. That was back in the days of MongoDB version 2.4. Shortly after the course started, I believe MongoDB 2.6 was released. I was quite daring and installed that on my server and used it to complete the M101JS course. This initial experience with MongoDB started me eagerly learning Node.js, JavaScript and using MongoDB for a database.
I also work with a blind developer. This person, John, is very smart and he really works to maintain his production applications -- all written in IBM high level assembler language -- to a high standard of excellence. I know his code works, and he keeps each of his batch programs up-to-date and correct.
And yet, being blind, John is constantly challenged by the data formats used in IBM System Z file systems. Textual representations of these formats work best for John, so that his JAWS screen reader software can voice the data to him. But there are problems. For example, JAWS hits trouble when it tries to voice the exact content of an 8 byte packed decimal field. Since many mainframe software applications work with record-oriented flat files that are not key/value stores, JAWS doesn't "know" the record layout of a given data record. It just tries to voice the values encountered in the data record, byte-by-byte, to John. It is up to John to somehow know the names of possibly hundreds of fields within each data record, and which one the screen reader is currently reading, and what the characteristics of that field ought to be, and what the field before this one was and what the field after this one should be. This gives John a data comprehension challenge that most of us never think about.
MongoDB offers a key/value store format that would seem to be much more accessible to John. I thought a field coded like "tags" : "data" or "tags" : [ "text", "html" ] would make much more sense to a blind developer because the key preceding the value would be voiced for the developer and the value would be voiced immediately after the key. In other words, John would automatically know the field name and its' value or values. So I ran a few sample MongoDB documents by John, and questioned him about their content, and he quickly gave me accurate answers to my questions. He appeared to find the JSONified key/value format to be very helpful. It is such an easy to understand format, that any developer, regardless of background, should be able to rapidly develop and deploy a single-page application with help from MongoDB.
So I hoped that MongoDB would be a much easier database engine to work with in the sign language project described above. And so it turned out to be. There were problems, of which I was the worst. Being a great assembly language programmer doesn't mean I'm a great JavaScript programmer. I had sneered at JavaScript for years...until I realized I needed it for this project.
I'll discuss the project more in future posts.
