Everyone knows how to use a spreadsheet. As we wrestled with the messy work of how to create a dictionary for an unwritten tribal language I realized that I'd be reinventing the wheel to create some kind of data entry UI. Why not use something familiar and flexible for data entry? Especially since at the beginning of learning the Kovol language we didn't know what exactly we needed. What would the language do? Where is the complexity?
I also didn't want to rail road my team of non programmers down a particular way of doing things, forcing them to use a tool because I'd spent lots of time on it.
I had a think, created a spreadsheet and then wrote code to read the spreadsheet to generate a static HTML page where the data could be presented in a user friendly and searchable way. A simple cron job runs the script once a day now all the data we're putting into the spreadsheet is available, even on mobile devices.
I'd just finished reading code craft and was keen to put some of the lessons into practice. I'm all too quick to start bashing away at a keyboard and churning out code without properly thinking it through first. Code craft helped me realize how important it is to slow down, plan well and actually craft code - not just string together a jumble of things that sort of works.
The main lesson I tried to implement was using a layered architecture.
My Lexicon program has 3 layers. One that reads the data from the spreadsheet, one that processes it, and one that renders it to display (and creates other files like a .dic for a spellcheck). Each layer can call on the functions of the one underneath it, no hopping back and forth, tangling everything up.
Writing comprehensive tests was also important. I tried to take care that the tests didn't end up in a tight ball I was afraid to touch as it did with CLAHub.
The result is something that our team has gone on to use - we still need to agree on how to spell some of these words though!