Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store answer IDs #1

Open
sean-duffy opened this issue May 5, 2015 · 1 comment
Open

Store answer IDs #1

sean-duffy opened this issue May 5, 2015 · 1 comment

Comments

@sean-duffy
Copy link
Contributor

First of all great job with this library, it does a very good job of getting the data and putting it into a convenient structure. I do have a few small fixes which I'll submit pull requests for when I've pushed them to my fork.

On to the matter at hand, I noticed you don't store any kind of unique identifier or timestamp for the answers at the moment. The timestamps are tricky since all ask.fm gives us is an interval, not a timestamp for when the question is posted. However, there is an ID associated with each answer which I think increases with each question, so it can be used to put a user's answers into the correct order.

This ID is found in the id attribute of each questionBox div, for example:
<div class="questionBox" id="question_box_127193741364">

Let me know what you think, and keep up the good work!

@theycallmeloki
Copy link
Owner

Thanks a ton about the appreciation,

I've never personally had any reason to put a user's answers into the correct order, in my head, as long as the answers are present, it's all well and good. But I do realize now how that might help, and I agree, I'll add the ID into each answer, in the immediate future.

I'm not sure if you've noticed something, but if you google any user, the search results points back to ask.fm/username/best. The /best sorts the user's answers based on how many likes it's gathered. My original notion was to pick up answers through this, that's kind of why I didn't bother with the id attribute.

The unicode support is not terribly high on my priority list, but I must admit I wish I had it sooner, when you start scraping non-english speaking users it begins to really show why it is terribly important to have unicode support. I honestly know gracefully little about encoding and would love to learn how to fix this. Right now, you're right, I just gracefully ignore unicode.

Thanks for your interest in the library :)

Repository owner deleted a comment from leojin Feb 23, 2024
Repository owner deleted a comment from GloWE3 Mar 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@sean-duffy @theycallmeloki and others