New to swift and just wondering if anyone could give me some insight on the best way to create questions for a true or false quiz app I am working on.
I saw another thread about making questions non-random but as my expertise isn`t that great yet I am still struggling to understand the concepts.
Would I create a dictionary with a key value pair with a String being a question and Int being the answers?
Any insight would be greatly appreciated.
Thank you!
That would be the basic setup. You might also consider using a Bool instead of an Int for the answer, and other fields for difficulty level, number of times used, etc. The true power of dictionaries is that you can add as many key:value pairs as you like, thus being able to track all sorts of metrics over time.
Related
I've been looking through some of the NEAR demos and came across the one regarding posting quizzes that can be answered for a reward.
Source code here: https://github.com/Learn-NEAR/NCD-02--riddles
Video here: https://www.youtube.com/watch?v=u4jP2a2mbiI
My question is related to how secure the answer hash is. In the current implementation, the answer hash is returned with the quizzes, but I imagine it would be better if that wasn't the case. Even then, if the hash was stored on the NEAR network without it being returned by any view functions, how secure would that be? If there was code in this contract to only give a certain number of guesses per account before denying additional attempts, would someone be able to get the hash through some other means and then have as many chances to answer as they want by locally hashing answers with sha256 and seeing if one matches?
Thanks,
Christopher
for sure all data on chain is public so storing anything means sharing it with the world
one reasonable way to handle something like this would be to store the hash but accept the raw string and then hash it to compare the two for a possible win
if you choose a secure hashing algorithm then it would be nearly impossible to guess the required input string based on seeing the hash
update: it was poined out to me that this answer is in incomplete or misleading because if the set of possible answers is small then this would still be a bad design because you could just quickly hash all the possible answers (eg. in a multiple choice question) and compare those hashes with the answer
heads up!
everything in that GitHub org that starts with NCD is a student project submitted after just a week of learning about NEAR
so there is a huge pile of mistakes there just waiting to be refactored and commented on by experts in the community
the projects that are presented for study all start with the prefix sample
those are the ones we generated to help students explore the possibilities of contracts on the NEAR platform along with all our core contracts, Sputnik contracts and others
sign up to learn more about NEAR Certified Developer Programs here: https://near.training
I am working on an app where users can create posts that uses Amazon DynamoDB. One of the attributes of a post item in the database is postId. I am searching for the best practice to set this value upon creation. So far, I have thought of:
Counting the current items in the DB and then assigning the value as postId = dbcount + 1. I cannot find a count method for DynamoDB using Swift, and the ways I have found (scan & description) are either inefficient or accurate. Also, I thought of the scenario of 2 users posting at the same time.
I could create a UUID with Swift and set the postId to this value.
Upon these 2 options, which route is better? Is there a preferred industry standard? Option 2 seems to be the better choice, but I am not sure. Are there any other potential alternatives? Thank you!
I would definitely stay away from option 1 - as you said the potential for a race condition is too high and it could be expensive to implement too.
A UUID would certain work and is likely to be the least painful. However, there are other options too. An atomic counter would work. A bit more complicated but you could even use a conditional write. But the logic for that would be a pain.
The advantage of the UUID is that you generate it so that it can be used for, as an example, a row of data in a child table.
After quite a few Google searches, I have finally found my way here for this question. If this is something that could be better asked elsewhere, any direction that could be provided would be greatly appreciated.
I have made some HTML forms in the past, but I am trying to do some validation, of which, I have never done before.
What I would like to do is have a form that has two drop down lists that are sort of tied together, the first being one of two choices (say A and B) and the other being a list of the numbers 1 through 30.
What I need to do is have 30 of such "questions" and I need to validate that each number (1 through 30) are used in the form and only used once.
As stated I am a novice at any type of the programming required to make such a form from scratch. I can read some code and understand what is going on sometimes, but I don't have the knowledge to be 100% sure.
Any help, or direction to where I could get this answered is greatly appreciated.
Thank you
I am receiving incomplete SecurityLists from a venue. Here is the message I am receiving:
8=FIXT.1.1|9=112|35=y|34=9|49=xxx|52=20130913-11:17:37.418|56=xxx|146=1|020001=20130913-11:17:37.402|10=108
(I have deleted the COMPID's)
I have tried reordering the repeating groups fields in our data dictionary to match the order of the repeating group fields in the venues data dictionary.
Still having no luck!
Advice would be appreciated.
You're using QuickFIX, right?
If yes, I'm guessing that you are missing UseDataDictionary=Y and/or DataDictionary=path/to/your/dd. It's a common newbie mistake.
This is just a guess, though. You really haven't given much to go on.
I just wanted to validate my data structure.
It seems a bit convoluted to me, maybe it can be simplified?
Questions are grouped into chapters.
For each question, only one answer per session is possible.
The purpose is to be able to compare / analyze answers to the same questions (by different users or by the same users at different times, i.e. with different sessions).
A template, being a collection of chapters & questions, should not have to be replicated, if chapters and questions are the same.
(That would be necessary if Answer did not have a relationship to Session.)
Is the relationship from Answer back to Session the right strategy?
What else would you improve to simplify the model?
Thank you!
EDIT
Follow-up clarification:
The Answer is not static (e.g. "right" answer, "solution"), but some text the user inputs. It is more like a "questionnaire" than a "quiz". The answer has quantitative attributes that can be analyzed.
As stated, one question can have only one answer within a session. Because questions can indirectly belong to more than one session (via (NSSet*) question.chapter.template.sessions), they could have more than one answers and thus need a to-many relationship.
The typical scenario: User starts a new session with a certain template and fills out the answers. Then he can look at the analysis of the results and compare those with the results of other sessions that use the same template.
EDIT 2
The snapshot of the data model including attributes
honestly, this is what I would do instead of your structure, but I don't know what the purpose of the each entity because I'm not able to find out from their simple names.
this is just an idea to resolve the loop.
you can still reach all templates and all answers from the session, not directly but it does not make your life much harder.
UPDATE:
at the first and second sight, for me, it seems the Session entity is just an extra entity only here. honestly you would not need it, if you concatenate with the Template (aka Questionnaire) entity.
you have to add a many-to-many relationship between the Template and User (you can do it, don't worry about it). using this way, from each template you can reach all answers as well, and you won't have any loop.
Despite the really helpful effort by the part of #holex - the best way still seems to be to stick with my design. The simplifications I had hoped for have not materialized.