In my previous blog A Process for Minimum Viable Prototype I outlined what I had hoped this project would become. Unfortunately, I did not hit my goal of including motion tracking, but everything else was mostly accomplished. The project, Wordmazing, is a game that allows parents to select words which then get parsed into their composite letters. The kids are then prompted to click on the correct letters, and once enough letters have been marked correct, words will be activated. The biggest challenge of this project was making it Object Oriented. In hindsight, while I wish I had worked harder to build it object oriented from the start, I’m uncertain if I would’ve been able to build at all. To put it differently, I find that getting something done and getting it right are two very different things. AND, that getting something done is best done quickly, but to get something done quickly? That often means sacrificing best practices in order to keep complexity to a minimum. As a beginning coder, this makes for messy code, but as I get better, I suspect my syntax and code-vocabulary will eventually catch up with what I want to say.
PROCESS
I had coded out a switchboard in index.js to match my index.html. I had all the selectors setup in a CSS file, and basically… I thought I would just work through the switchboard, coding each “switch” as if it were a checklist. Using the switchboard made it easier to see how the final product would look. I had buttons and inputs that I used in place of writing tests which helped me see how the backend API was working. If I had known how to write tests, that would’ve been a nice option… however, having it done it this way, I see greate benefit to writing experiments that prove larger ideas. My impression is that tests are probably best written once you have some idea, some hypothesis of how the code should work. On the other hand, if you only know the overall functionality, then writing experiments to test features seems like a decent way to uncover the what and the how.
To give a specific example, I didn’t know that sessions were not included with the Rails API. I spent days chasing a glitch that made it seem as if sessions were working. Ultimately, another student (thank you Oliver Feher!!) pointed out that sessions weren’t included, and I’d either have to put them back in, or come up with another solution. As I slogged through tutorials, I began to feel that there must be an easier fix that altering half a dozen files. I solved it the wrong way… with a global variable on the back end. Interestingly, the thing I was most frustrated about after the entire experience was that I had not thought to use a global variable in the beginning. While I realize it’s technically bad code, I think I now have a better idea of how sessions actually work, and perhaps more importantly, less anxiety about using global variables to solve problems.
Another pleasant reflection on the switchboard experience is that it’s pretty similar to “coding to an interface”, even though the interface is only a skeleton of what ought to be there; just the functionality. A “good” side effect of knowing all the functionality (and seeing it) made it impossible for me to sacrifice/abandon goals that seemed too difficult. Also, knowing what came next, not in terms of a test, but in terms of the next-most-reasonable-functon, forced me to constantly be aware of what I needed to code next. By the time I was halfway through the switchboard, I had achieved all my coding objectives.
Using the switchboard also helped me test front end with the back end, so I was using user-generated data as opposed to seed data. This helped me to gain a more thorough understanding of what was happening behind the scenes, and ultimately gain a more robust understanding of how it worked.
MISTAKES
The biggest mistake I made, other than not starting with an OO mindset was that I coded the project horizontally. Weirdly, if I had to do it all over again, I would probably still code it horizontally, but less sloppily, as the combination of quick/sloppy code made the refactoring a nightmare. Had I coded vertically, I would’ve been forced to confront my misunderstanding/lack of understanding of OO principles early on. On the flipside, I wonder if coding vertically and getting stuck in a silo (as I most definitely would’ve) would have made me give up on the project and aim to do something easier. As a type this, I wonder if the switchboard served as a subsitute for coding vertically, by allowing me to be focused on whatever I needed at the moment. Ultimately, the only duplicate/unnecessary code I wrote was on the switchboard. (Of course, I’m sure there’s lots of unnecessary code in the project, but I think that’s more from me being unfamiliar with JS than a result of poor planning).
Back to OO. I was stuck for about a week, maybe 10 days trying to figure out how to proceed. It wasn’t until a Flatiron Grad, Daniel Dawson, helped me understand how and why objects are important. Having fully coded the project, and having it working, made refactoring to Object Orientation probably more difficult than had I started refactoring earlier on. I was mentally blocked because I didn’t want to do the work. Anyways, Daniel made me see the light, and once I understood the rationale, it was much easier to embrace OO in JS. NOTE: While I write this blog, there is still much that needs to be refactored, but fortunately, there seems to be enough to submit for review.
Another thing I did wrong, but enjoyed was using try and catch. When dealing with promises and hits on the database, the most common issue I found was that data would be: returned, AND RESOLVED, and yet it would populate as undefined. When dealing with undefined data, the if/else control flow situation proved suboptimal, because it was often hard to pin down what value ought to be expected… I had great difficulty getting the if/else statements to work robustly. Sometimes I’d get null, sometimes undefined, sometimes an error. When I realized I could use try to test if the data at least ‘worked’ it got me thinking as to whether or not I could pass something into the catch block other than an error message. When I realized that you could put anything into a catch statement, I found a quick fix that allowed me to write semi-vague if/else statements. Long story short, I went crazy writing nested try/catch statements, mostly because I was surprised that it worked. Yes, I know that it’s not how to do things, but perhaps it was that satisfying for that very reason.
RANDOM
Async function and await … I probably went as crazy using async functions as I did with try and catch, often together, often unnecessarily nested, though at the time of coding, I was unable to see a better way.
CONCLUSION
Despite all the craziness, I actually like JS much better than Ruby or Rails. Partly because JS seems like it can be any programming paradigm you like, procedural, object oriented or whatever. I also liked that you could do things that seemed like they wouldn’t or shouldn’t work, but did.