As the final full sprint comes to a close, I find myself wishing for just a bit more time to work. With the testing issues resolved, we were able to work much better than we have in the past, and with a newfound grasp of the technologies at hand. Had we begun the semester with this kind of understanding of what we were working with, I think we would have had a vastly different product than what we currently do. During this sprint, we corrected what was left of the sync/async issues we were having, made a switch over to a singleton pattern for our service (with a bizarre development), and got as much of the service in minimum working order as we were able.
Having redone the tests to be compatible with Promise objects, I spent the first bit of the sprint trying to convert the offline storage service into a singleton pattern. The primary difficulty in this turned out to be that Ampath had its own tslint.json file for enforcing the organization’s style guide. When coupled with the fact that WebStorm regards conflicts with the tslint file in the same way it regards syntax errors, it meant that the code wouldn’t compile, and I had no clue what was wrong with it. Only after reordering my field and static method declarations would the tslint stop holding my code hostage. After going through this whole ordeal, I think it would be nice if at the start of future semesters, Ampath provided capstone sections with a style guide to avoid headaches like this one. After the conversion to singleton, I moved to the tests to rewrite them to interact with the singleton object. In the middle of this process, however, something very non-intuitive and very obnoxious became visible.
First, a recap of the purpose of Singleton Pattern: by making the default constructor for a class private, one can disable willful instantiation of that class. Then, a static method which returns the single instance of the class allowed to exist is written. With this structure, you can guarantee that only one instance of a class exists, and there is an easily available mechanism to grab a reference to that class.
“Not in my house,” says Angular. It turns out that making the default constructor private doesn’t actually give it any kind of private visibility; you can still instantiate the class with “new.” I only realized this when halfway through writing my test cases, I accidentally wrote “= new OfflineStorageService();” and was not told that it was a problem. Rather, the tests all ran and passed, even though – and I triple checked myself on this one – the default constructor in OfflineStorageService was most definitely declared private. I shared this information with my group at the next meeting, and we each agreed that it was one of the most baffling things we’d ever seen in programming.
In spite of my shock, things proceeded smoothly and steadily for the rest of the sprint. Our communication was spot-on, as we were giving each other daily, sometimes hourly updates in our group text message. The code, while sometimes strange and alien, was actually starting to behave like we wanted it to behave. We were in consistent communication with one of the other groups, and occasionally communicating with the other two. Really, this felt like a culmination of what we’d learned from the last five sprints – as it ought to have. Perhaps we could have done something better; I probably could’ve been better about standup meetings and asking questions about Ampath, but I think in general, each of us feels far more comfortable with this entire process. With only the documentation left to do, along with our final presentation, I think I can say I’m beginning to feel what it means to be this thing called a “software developer.”