rdallman / flaming-wookie Goto Github PK

This is really simple we just need to do it. just need to define something like:

wookie://MYSTUDENTID@MYCLASSID

just something we can parse easily in the android client and include in the email for students to be able to add a class with one click instead of typing in a bunch of random chars.

see #13 for the how, but need to validate this on each answer.

also probably good to send the list of a quiz's expected students into the session as a map just to check for membership O(1) and not have to read from DB each time.

Pages for viewing/creating classes and quizzes

So Michelle has been refactoring the add students functionality. The current design is that in the http handler for adding a class, it creates the class with an empty list of students and then for each student, it creates a go routine for a new addStudent function.

func addStudent(cid int, student map[string]string) {
...
}

This function handles the logic for generating the hash for the student, adds them to list of students in the db, and then calls an email function sends the email to that single student. Here's where the issue lies... Follow me down this dark alley...

So in order to add the student obj to the list of students in the db for a class, it has to query, unmarshall, append, etc. Well since we're doing these in separate go routines, they're each grabbing an empty list from the db and then updating it with their single student.

There are a couple of ways to fix this:
Option 1: change the addStudent function to accept a slice of map[string]string, add the hash to each student, and then update the db record once with the single list of students and then send an email for each student in separate go routines. This option allows for quick change on the backend.

Option 2: change the interface on the front-end, only allow the teacher to create a class initially with no students, they have edit the class to add students where we have the "Add Student" button bound to an AJAX call that calls an addStudent http handler that adds that single student and sends the email. This option just requires to change the interface, but the interface design seems a bit more intuitive. Consider that a teacher wants to have the class "Created" beforehand and don't have the list of students to add.

mostly a reminder for myself

see file wookie_test.go for how to go about doing so, and migrate all curl tests in tests.sh into go tests as well as adding more. Test for failures, weird inputs, etc.

status quo: ugly and not DRY.

There should be comments for most of the expected inputs for the API (all the JSON stuff). If there aren't, it should be easy enough to figure out from the struct within that method what is to be expected. See URL's in server.go for what needs to be documented that we have finished and is to some degree in "staging" to be stable.

Outputs can be determined mostly from the writeErr() and writeSuccess() methods within session.go along with comments for certain functions. Document as if you were parsing. There is a critical step for simply figuring out whether the request was successful or not that should be rather evident, then info can be parsed (if any). Certain methods don't return any information. Maybe we should. Maybe you should figure that out. If you can't determine the output, go write a test and get the output. Most of the methods work (if they're commented out in server.go, they don't work).

not so much the js as the HTML/CSS...

move icons w/ text to only show text on hover.
get rid of that massive .min.css (re: not so .min) and make our own
make it play nice w/ firefox
general web designy stuffs...
remove Star Wars branding :(
think of cool panel graphs and stuff

this will be long and arduous and most likely not worth it, but it's about all we have left!

need to implement "flash messages" for redirects. They look pretty cool if anybody is curious. Right now our redirects work but they are janky and ask you questions and they need to be gotten rid of.

also see: redirect policy in net/http
other useful things: revel, google "golang flash redirect"

So the culprit for "Users" is the upper case U. postgres is picky about capitalization and expects lower case things I guess unless specified strongly (with quotes). I think this should be easy enough to just redrop the tables with different names?

need to generate and parse.

custom URI schemes look cool for clients to launch app.

this may be built into HTML and I'm missing something, but check that the password fields match and probably will have to check to see if the email is already in use. In theory, the password could be done with javascript but since we'll have to hit the server to check that the email isn't already in use it could all just be done there. this is loosely tied to flash messages, but if the functionality is there it's easy to translate to flash.

helps differentiate between actual issues and just the issue of us trying not to step on each other's toes. Thanks.

making functions for handleQuizGet, handleAnswer, handleQuizEdit, handleQuizCreate

some kind of registration for a class for students that teachers can open on the first day. needs to be defined and then implemented.

option 1: teacher adds student ID
option 2: open "registration" period for students to send in their ID/PIN (this will have to be done to get PIN anyway for option 1, so maybe best option)

we could probably afford to have another technical debt mitigation stage. maybe after this cycle is over or towards the end of this one if we finish everything up.

http://blog.golang.org/godoc-documenting-go-code is a good start.

fun fact: you can run godoc on your local machine (with our godocs):

godoc -http :6060 &

That might need some kind of installation... I forget. But it's not hard.

We also could re order files and such again. Maybe splitting quiz and class would be a good idea. There are more ways to skin the cat

power goes off in the middle of a quiz:

currently, teacher has to redo entire quiz.

this is bad. fix this.

P != NP

need to separate file structure, we just haven't had much that needed separating to date. logical things like: db.go, handlers.go, structs.go or can take a more OO approach if you'd like, e.g. quiz.go, class.go

open for discussion and this is an RFP of sorts.

find edge cases and kill them. and their parents. and siblings. and children. Actually, everything they ever have loved or ever will love.

Consider checking for/deleting a student from the list for a class. Right now we would have to loop through the entire list to find that specific person and then delete them. If it were a map with the student email as the key, we could easily check/delete the student from the list.
I think this is an issue that should be addressed eventually...

Need to secure cookies instead of just having data in plain text. Also storing of cookies in database. Right now we just check that the cookie exists as a form of authentication.

Need to delete cookies on log out too.

think we need something like javascript flash messages, which could be a fun little modular component to implement if you have some free time and somebody is hugging all of the fun stuff.

need to make sure that quizzes have a class, a title, >0 questions, >0 answers, 1 correct answer, probably a few other things, too.

Currently, on the main dashboard page, you see a list of all classes and quizzes. I do not think we should show the list of quizzes here. Logically, you should see the list of quizzes for a class when you view that class. A teacher is going to go to a class to manage the quizzes for that class, they don't need a huge list of all quizzes for every class.

I have a pull request waiting to be merged right now that includes the list of quizzes for a class on the class's page. (I have not taken anything out, I wanted to get the groups input first)

With that said, how does everyone else feel about this? I think we should remove the list of quizzes from the main dashboard page and remove the quizzes dashboard page. Then the teachers will manage quizzes from the class page.