My Luck with Makahiki: Unfortunately Me

Once again, I dive into the world of Makahiki to attempt to add on some functionality to the system. I am often weary of the way I approach these endeavors, as I find my bad luck follows me especially well when it comes to instances I cannot easily undo, but with the need to attempt new things I give into the next task: Making a widget for the Makahiki system.

This will be more a cautionary tale than most would suspect. Though I am, what I would want to believe is a capable and competent computer programmer, there are times when I fall into a series of pitfalls, which make me wish I had the ability to undo moments in reality. Unlike what I would like to think my other entries provide, this one will more or less be about how many mistakes one person can make on the job.

Starting off I was fairly cautious about the endeavor. This time in order to prevent myself from possibly doing something awkward I read up about the necessary things we were required to do as stated on the class website (see here). The development requirements seem simple enough, after following the provided tutorial about making a widget for the Makahiki system, we were to construct our own widgets displaying group scores (groups are a collection of teams which make up the players in the Makahiki system), group resource usage, group prizes, and some comparable statistics.

It does not sound too difficult on the surface, but as steadily going into it trouble rise to the surface. Starting off with minor issues, the tutorial for creating a widget contains minor nuisances which prove to stifle my flow. The first instance of commands incorrectly does not include the "./" necessary for running a command, rather minor but something to be aware of. Explanations of the system and the importance of the widget's view.py help to provide practice and confidence in use. The inconvenience continues as the required section on Page Info has not been updated to the lastest version of the system, this creates a disconnect in terms of usage and location that takes extra time to, noting that "Page Infos" is located under "internal Admin" when that division no longer exists. The "'Settings' page" now contains an extra selection area, which is not mentioned. The minor issues create a certain need to double check actions, combine that with the sometimes similarly named areas, and that the provided screenshot also names areas differently. The screenshot provided for the Profile page settings did not mention that this screenshot was not from a lower section of the page, which might be a problem for users running unmaximized windows.

On the topic of filling in help topics, I found it rather fascinating that the help topic was so far away from structurally from the widget itself. Especially since the system requires a use of matching slugs, having the help topic system designed in one location appears to be designed more towards mass topic writing rather than developing help systems besides components.

At this point is where we diverge into slight madness. Upon reaching 3.9.10 in the development of a widget I had come to the off realization that I wasn't sure how one would safely commit changes to the system once it's on heroku. In addition, how to change the json files which even at the time of this writing I have no knowledge of where it would be located. Thinking that I'd have to tackle this in the near future in order to upload the finished widgets to Heroku, I considered my options while moving into development of the first of the requested widgets, the group score system.

As it stands, groups in Makahiki are an interesting structure, they are made to hold teams and nothing else. As of this version of Makahiki assignment of Teams and Groups are done at the precious level (Team settings allow group assignments and user settings allow for team assignment). The mentality that places groups into teams, also presents itself in the way that groups are worked into the management system. Since groups are attached to teams, the mentality to trying to work out a widget for group scores was to work off its existence as part of teams.

Initial attempts at writing the widget took the perspective of adapting the pre-existing code for team scoring and changing over the call to groups. This change would require adding an extra method to the  score manager (as suggested by our assignment briefing). Adding in a variation of teams_points_leaders (which puts together the top scoring teams) called group_point_leaders, resulted in a series of faults to the system. The results of this problem originate from the fact that administrator by default is not given a group, meaning that attempting to use it will malfunction. While attempting to alleviate this problem by providing a group to the administrator account resulted in another fault, this time coming from the fact that the administrator by default does not have a name either.

(screenshot: Errors are common in development, but sometimes they feel like they are targeting you)

Providing both name and group will allow the administrator to see the widget, though the previous suggested step did not result in it working functionally. Analysis proved that there needed to be more defined beyond the score_mgr.  Extra processing is done in the team_mgr which helps set up the process and arrays to display scores properly on the widget, so a very of group_points_leaders was created in team_mgr to provide the extra processing needed, this is done simply by modifying team_points_leaders to work with group. It is not uncommon for there to be multiple items with the same name in code, but it without knowing the value of the going through both, my original code was returning empty sets. Correcting for that, soon created a functional widget for group score display.

We once again return to the trouble we faced before, how do we properly upload this newly completed widget? The initial thought would be to simply run an update instance. As describe in older tutorials, I at first attempted "scripts/update_instance.py --heroku makahiki-samplekd" from my Makahiki directory. Update appeared to run, but my widget was nowhere to be found. The frustration begins.

Since Heroku uses git as a means of project management, the thought occurred to me to try to commit my changes that way. Unfortunately this is where my own unluckiness strikes, as somehow trying to commit my file does not process correctly. Group_score, my widget, is visible now, but my commit comment is weird and my widget is causing errors which prevent users from seeing both the home and profile screen. Several attempts at accessing rollbacks (though never actually trying to run a checkout, under the confusion between git checkout and svn checkout), including attempting to modify the files back to an older version, resulted in git thinking all the files were up to date and would not initiate push or pull to the repository. Several hours pasted trying to figure out the problem but to no avail. The eventual solution was unfortunately to create a new system to more carefully move over the widget and properly commit the files. This time with success.

(Group widget seen in upper left corner of the widget space. As Seen from a test students view)

It is worth noting that in this current set up, I had left in the existing error regarding the administrator being denied access. While I feel this could be avoided by possibly coding in a dummy name in the event that a user has no group (or making a "no group" group in the system itself), the fragility of the system and my waning awareness makes me all the more afraid of stalling another system.

With so many hours spent looking over the code before hand, yet still making the fearful hard to undo mistakes and spending hours to fix that, I was unable to proceed beyond this first widget. It surprised me that either the updating instance file was not working properly, or I misunderstood its usage. At the same time, the instructions lack of specification when it came to pushing and updating the files including the still unknown location of the json files, leads me to feel like even for someone who is more cautious than I, this guide could use more specifics, and updating to adhere to changes in the program.

After a long several hours trying to untangle the malfunction I created for myself, I can do nothing but present it as I have, a tale which points out some factors of concern I have with the existing Makahiki documentation, while providing a cautionary tale. The lesson, one should check the use of everything to ensure you aren't cutting too many corners, and that one must be especially careful when things cannot be fixed with a simple undo.