log.txt

04/01/16
/approval/index.php
Feel like the mysql query to select all achievements that have been rejected may be faulty.

/php/ajax.php
Create a log of all AJAX calls.

/js/ajax.js
Be able to handle JSON references.


I'm beginning to think that the entire format of RLA is wrong. I don't believe this is just perfectionism. This site started as something for myself that I jury-rigged into a platform. I'm starting to think this was the wrong way to go about things.


03/28/16
So for like the four or fifth time I'm building a children-oriented version of a function to iterate through an achievement's ascendants. I'm starting to think it might be more effective to just create a top record to indicate the shared hierarchy and indicate which level they're at to allow for ascendant functionions that start midway instead of at the top of the hierarchy. 

Probably won't do that though. Why do shit properly in two hours when you can hack a solution in five minutes? (Maybe in the refactor though.)

On a similar note, creating a function that returns the child ids of the achievement and going through each individual on and running a mysql statement on each one is far less efficient than just running one mysql statement per function.

Conversely though, I just started to do this for this function I'm working on right now, change_documentation_status_of_children and it's actually not the ideal way of doing it. Because only certain children need to be worked on, it becomes more complex if I create a mysql statement because I do the updates in mysql but I also have to update change log for each individual id. Some will be changed and some won't. 

03-25-16
My scheduled release date is July, so I'd like to schedule out how the release would go. 

March
Finish the most basic version of the product and upload it to the web.

April
Polish - All of the things that need to be fixed should be fixed.

May
Security - Implement all security precautions.

June
UI - Polish just the user interface.

13:25
There's a slight hiccup. If the publisher of an achievement deletes it, what happens to the users that still own that achievement?

If no one is currently working on it then it probably could just be deleted, otherwise, just disown it.

If I make it to where a publisher can not delete achievements but can abandon it, that seems like the most ideal situation, but then there becomes an issue where abandoned achievements stack up and become trash. (Maybe users can hide published achievements to prevent them from being seen.)

03/24/16
In the approval process for documented achievements, the original design was that users -need- to explain when they voted against an achievement. The idea was that this would prevent trolls from disrupting the system. It's certainly possible to implement this, but now I'm reconsidering it. At the core of the idea is that I can't trust "the community" to not engage in trolling, but I think that if there are so many trolls that submissions are constantly getting rejected, that's another problem entirely.

Also, for now, I'm not going to extend the approval vote with every swing vote just to see if it's really necessary to implement.

03/21/16
I'm having an issue now about how to pursue publishing achievements. Should it be an entirely new achievement or should I merely update the achievement?

A separate one. That way if the user wants to uncomplete their achievement and work on a new aspect of it, they can do that without messing up their published achievement.

03/16/16
While working on the code to complete documented achievements, I realized I've made a bit of a blunder. I've written the code to complete an undocumented achievement, but I forgot to include the code to confirm whether the children and requirement achievements have also been completed.

03/11/16


I'm at a crossroads now. Working on making this RESTful means that I basically have to rewrite the entire program. So as of right now, I can either choose to go back to the drawing board and restart all over again. Or continue to push through with what I have now. It took me roughly three months to get where I'm at now. I'm assuming it would take me two months to get back to this point. To be clear, the main reasons why I think I should switch over to REST is: 
-It will make mobile development easier and third party development possible.
-It will make the overall structure of the site clearer.

For now, I'm going to stick with finishing this, but I still have to change the format of the code.



03/10/16
So I've abandoned the idea of using a pre-made authentication system or an existing framework. I've started work on the user system and I'm really regretting not doing it sooner, because it is a major pain in the ass to integrate this into the current system. 

But now I've been dreading seems to be coming to pass. It seems like I'm going to have to create a REST API, because it's getting too unwieldy to do things the way that I've currently been doing it. So I'll be working on the design for that.

03/03/16
Removed actions, because I'm trying to make the first public release as simple as possible.

I came up with this idea that I feel is important. Remove ranks as this static ordering thing. Remove them all together. There are no "ranks", no arbitrary sorting. Merely a list. Instead of ranking and merge/creation as I've originally imagined it, have those aspects be an extension of a point system. When a user wishes to make a specific achievement more valuable, they add points to it from their point collection. The specifics of accruing points will be left for another day, but they idea is that if they want to make an achievement more important or less important they add points to it. This could be integrated with merging. For example, when a user creates an achievement, the default value would be 1 so that would take a point from their collection. That way it limits their ability to create new achievements by doing so at the expense of valuing their current achievements.

Now that I think about it, ranking should probably stay, but it needs to be less static and more dynamic. (ALA Trello's card sorting mechanic) But the point system is pretty important, because it has implications into later social interactions between users. For example, when the user publishes an achievement for other people to complete, the system could require the user to spend ten points to create an achievement with 1 value. Or maybe even a 100. And if people wanted to vote it up or down, it would require more. Though, that inherently makes social interactions more expensive. (Penalizing) Which may be the wrong path. But the point system idea is solid, I think.

I should probably be working more on the overall design of the progam, because I've been extending the program using the original spreadsheet as an example arbitrarily.  

One important thing that I'm realizing is that if achievements are published with a point system, it would be important that only DOCUMENTED achievements give points from publishing. For example, if a user publishes an achievement with one point and another user completes the achievement to receive one point. If the achievement is undocumented, there's nothing preventing users from completing them over and over again to dupe points.

This also leads to a concern about completion of achievements. If a user completes an achievement they've created themselves that they've valued at 5, do they receive 5 points? What's to prevent a user from duping points in a similar manner described previously? Oh, wait...Never mind, they wouldn't be duping anything, because once it's completed, they'd be receiving their own points back.


12/20/15
I've been thinking that maybe actions aren't really necessary. I feel like they 
might be too micromanaging in the scheme of things. When I finish this refactor,
I'll sit down and fully design everything that's in Trello.