zeks / flipper Goto Github PK

sometimes you get really weird ones and perhaps there is a need to finetune

Would be interesting to explore. Give the user an ability to get results from one-of-the/last search by a random other user.

iunno if needed

1. Shared memory
   Pros: init once
   Cons: boost.interprocess will take at least 3 days to implement

2. File serialization(Multiprocess Read)
   Pros: easier to setup
   Cons: it's still BS even as multiprocess

3. Limiting dataset
   Pros: easiest to implement
   Cons: can't debug anything even relatively complex

4. Log stuff
   Pros: perhaps the simpliest
   Cons: can't see stuff in real time.
   Will either have not enough info or horribly noisy logs.

make an option to show fics that two ffn urls have in common

Fetching query sizes takes too long because DB needs to match too much tables to work properly.
Need to denormalize slash and fandoms at least
Slash data needs to move directly into the fanfic table.
Fandom data could probably be merged as numbers and queried with LIKE

Some strange shit is going on with fandoms of new fics, the fandoms seem to be multiplying endlessly.
Also, I really need a merged fandoms list with one main fandom and records for all the possible splittings between ff, ff/crossover. ao3... etc

would be interesting to see which fics figure in large amounts of heterogenous lists

Now that fics from authors is a thing, there needs to be a button to display all fics DB has from the same author.
Optionally need to be a button to tag them all quickly.

Either I will need to disable this combination or improve word search perfomance

make sure I am at least semi protected before releasing

need to investigate why is it so slow on the server
reccount could also use speedup but that's likely unavoidable
revtofav is horrendously slow, probably error in the query

I think I can make one.
Will read user fav url and output fics in individual posts
Tracking should be done by emoji, then users will be able to rotate and clean up the list the same way they can now even if they wont be able to filter.

will need to show how much has been added and updated instead of how much was processed from webpages

need to derive some dependency between the duration the fic has been running, amount of chapters, wordcount, favourites, fandom active years and max favourites per category

I can check the percentage of slash the author has written to detect teh false flagging of the original algo.

Idea for the future. ESRB is trash, there needs to be a writing style maturity rating

should not save themselves and should not enter the reclist branch on the server

Only ever important for fir passes.
When a cat is unavailable and a fandom is parsed, the next incremental parse will likely miss a lot of fics.
It means the old question of "what to consider a dandom update date" still applies
Not very urgent but something to consider.

I should probably make it a priority. Even over the backend update mechanisms.

Needs a fandom ignore button and fic hide button (outside of tagging UI)

a legit use case would be when making a list and making sure there is no two fics from the same person

Unless I explicitly cache the sequence, forming it on the server side for default parameters per user request is completely unrealistic

shit's broken since client refactor. needs fixing

it needs to be a part of the UI, not a side effect of another function

Ideally I want to migrate to a proper in memory database

More ways to slice fandoms would be nice.
Could calculate what average fic sheet looks like and work from there

It seems there are legit cases where it's the fastest way to go

needs to be fixed asap

so that user doesn't have to move the mouse a lot after tagging evrying

will improve usability but require treeview