• 7 September 2015Plans, plans... what plans?

    One thing that often puts me off writing updates is that I'll just stare at the screen and draw a blank. Come to think of it, it is closely related with the absence of planning and clarity as to what I'm working on.

    First, I planned some changes to the SRS described earlier. Then came surgery for my deviated septum (difficulty breathing through the nose) and lost track of my goal as my sleep quality has only slightly improved since. I now breathe more consistently but the air flow is only 50% of what I consider comfortable so I'm still breathing through the mouth and I never really know how I'll feel when I wake up. Heck I just had two days of decent sleep in a row which is almost a blessing. I'm told it can take months for this surgery to show its final results.

    Someone got in touch about creating an Android app that connects to the site. Since I put off making an API for so long, I thought I'd finally get down to it. We have a very simple API working, and you may hear soon about an Android app that allows to do SRS reviews synced with your Kanji Koohii account. Unfortunately since I was struggling with my sleep and overall energy... I just couldn't wrap my mind around all the abstraction in OAuth and the API doesn't have a proper authentication for the consumer (the app, not the user). I couldn't come up with a simple alternative myself either. Currently the app takes your Kanji Koohii login credentials. It's not ideal since in theory the app author can store those credentials and mess with your account. But then again there is always some level of trust required when using an app that handles your data. Many apps do this (take your login and password), and all things considered.. nothing too nefarious will happen with a Kanji Koohii account. When you login, your email is not shared by the API. The API currently only deals with the SRS status and flashcards. So private stories aren't a concern either. However if I want to make the API available for general consumption, and expand it I will have to implement OAuth or something similar.

    While working on this I also realized the website's MVC (Model-View-Controller) framework is really out of date. Incredibly.. the site has been running on a very trimmed down version of symfony 1.2 for the past ten years. Symfony is actually a great framework, but I have been using a hacked version of my own rather than the full framework. It was a great experience for learning php: I used the symfony API as a tutorial, sort of, and implemented all the core MVC components by copying much of the code, leaving out a lot of complexity. Thus, I was learning both php and MVC from the inside out. The reasoning was that at some later date, if I wanted to I could refactor the site with the full framework since the API is relatively similar. So now I am finally doing this.

    This is the kind of updates that frustrating to work on because I have nothing to show. However I think it will be well worth it because I've noticed at certain times of day the website can become slow, and this change will finally bring some much needed caching. I think the Study section is the most expensive on the server side. It includes a handful of queries per page. Caching of course is complicated on a site like this since a lot of the presentation is dynamic content, meaning every user sees different things. I think the shared stories list is a great candidate for caching, since that list is more or less static for each kanji, and it's not critical for the the votes/reports to be updated in realtime. So I am excited to see how this will improve the responsiveness of the site.

    Upgrading the framework also could help me with the API. I may be able to plug in OAuth support from an already made library for symfony.

    Finally, I will have a proper internationalization and localization support with I18N. I have no idea what that thing is, but hey.. it means the likelyhood of translating the site to other languages will be much more feasible. It's just one of those things that I never added to my "trimmed down" version of the MVC framework.