Guest User

Quota Supervisor, detailed

a guest
Jan 27th, 2018
214
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 7.04 KB | None | 0 0
  1. DETAILS below:
  2. Last month as I saw Tim's post on Medium while searching for another Instagram automation software, rolled out to try this amazing piece of pycode in which features like interaction with users is super duper innovation compared to similar bots, and it being up-to-date, entirely free came out as a windfall! (hope it be free for future too :-)
  3. But since the start one thing was missing: quota supervisioning that made me work on my own.
  4. With no knowledge of Python, at first, I used pickling method #797 from @sionking and modified it to work with all activities including, likes-follows-comments and once I was gonna add unfollows, the code was so bulked inside InstaPy class and another InstaStorage class top of it was getting huge and huge after every feature..at that time met another more sophisticated approach from @ugurozturk and @converge #1034 which made me switch project to work with update_activity as converge recommended, compiling the ideas from sionking about working with datetime. I was just combining ideas into more universal project into another method inside InstaPy. It was pretty neat in thoery but once finished code part, it failed in practice cos I misunderstood 'import' in python :'D
  5. The rest was pain! Had to redesign** particularly to provide data access mainly from SQL queries, because of the we want full control over activities we must import method from InstaPy class into every single utility. That's why I used another database table inside instapy.db to store the realtime data and get accessed anytime needed from anywhere. After this, I moved quota_supervisor from InstaPy class to util.py where it could be less bloated. And then every separate utility can import quota_supervisor standalone function rather than entire InstaPy class (or even it import only one instance, it will not be synchronious, not helpful).
  6. As of current finished design, I have added several needful paramaters: availability of full control of every activity in both hourly and daily basis. Also sleep_after is also available in same basis. Whilst having randomized peak values (generate from user's peaks) with stochastic probablity from stochastic_flow and sleepyhead=True for waking up after some randomly fixed time (rather than calculated accurate remaining time) and one more cool feature of toast notifications from Plyer package supported in (Windows, Linux and Mac) in just few lines.
  7. Rephrasing again, because of the complexity of the duty of supervisioning, I have followed the minimalistic design to offer service fast and yet easily mainatinable once needed. The structure is simple.
  8. added in Instapy class :
  9. set_quota_supervisor ()
  10. added in util.py :
  11. quota_supervisor()
  12. quota_supervisor_stochastic()
  13. quota_sueprvisor_sleeper()
  14. quota_supervisor_notifier()
  15. ..then imported supervisor into all target utilities (like_util, comment_util and unfollow_util)
  16. from util import quota_supervisor
  17. Because of Quota Supervisor is called to inspect activity state right from it's root (this is important) in (comment_image, like_image, follow_through_dialog.. etc), the InstaPy class has not been edited much with this design!
  18. The only places I modified in InstaPy class is: adding break points to some loopable features (e.g. like_by_feed will not leave until amount is filled,. etc) by adding jumped variable, and in for a few features added states else than True and False as, if liked == 'jump' (e.g. like by feed will still continue to see images if like quotient is reached, at this time, it will only follow or unfollow and once amount filled (liked_img+jumped), will leave).
  19. And the only place I modified in like_util, comment_util and unfollow_util is simply adding:
  20. if quota_supervisor(inspect='likes') == 'jump' :
  21. return 'jumped'
  22. update_activity('jumps')
  23. else:
  24. #.... _original code here continued_....
  25. that's it! adding this inspection check just before every single like, comment, follow, unfollow process.
  26. Like (like_image) and comments (comment_image) are easy with only one inspection per each, but in unfollow_util there is 7 total inspection points (for follow and unfollows).
  27. For future maintenance, if a new feature added, easily adding quota_supervisor(inspect) before taking last step action will be fine. And yes if there is a sort of while loop, considering break points for jumped actions..
  28. Also added set_quota_supervisor() to the start of login(). This is required bcos of redesign, using DB approach I must set supervisor state to NULL and then if user initializes session.set_quota_supervisor any time, it will write 1 (means enabled) into supervisor state.
  29. To save space, initially, and for faster querying I used 1, None or 0 for feature states in database. (1 is enabled state, 0 or None is disabled).
  30. Through tests, querying time is super fast that i was not expecting from databases, basically, in each quota_supervisor(inspect) call, it will find it's state (if 1 continue else return back), if enabled, will check stochastic_flow state (if 1, last epoch_time - real_epoch_time and renew peaks per hour/day), then e.g. if inspect is server_calls, check its hourly (compare peaks vs realtime fetched data) then daily (compare peaks vs realtime daily summed up data) state. That's it! takes less than a second ;) Of course if quotient filled and sleep enabled, will go forth and calculate sleep time then fall asleep some..
  31. BTW I have edited update_activity to store values according to the hour else than day (24 records per day)
  32. If user restarts set_quota_supervisor() with new peak values, it will read those instead of last ones, that's where I have added tact mechanism to provide latest records (max 2 tacts per day, 1 initial, 2 stochastic values if any)
  33. Possible errors are:
  34. Icons I made for notify_me arg may not work for your OS (e.g. in some Linux distros not supported by Plyer package)
  35. Recently, realized that Quota Supervisor is written fully for **one accaunt** users, which means if you use multiple accaunts of same database in use (instapy.db), supervisor will sum up all records if enabled. To prevent, just disable quota supervisor for multiaccaunt scripts or add another database for each of the accaunts (e.g. copy paste instapy.db to instapy1.py, instapy2.db) and specfiy those databases in util.py and instapy.py files, otherwise supervisor will misbehave with peak quotients.
  36. Well, this is done in week for coding structure, another week merging it with InstaPy (turned out to redesign off SQL queries) and these latest days solving conflicts. At last 2 weeks I learned basic Python and amazing SQLite (thanks to converge's update_activity work), at some point @timgrossmann is right "People learn programming while wanting to modify code by using InstaPy :'D" (said in a podcast to some python channel)..
  37. #alongside supervisor content, I also added some missing logfolders from latest pull inside this commit.
  38. I have tested almost every aspect and solved any problem encountered, for now I am using Quota Supervisor for my needs. Hope it works for you too! Feel free to ask anything regarding design.
  39. Thanks to all contributors for making the project available!
Add Comment
Please, Sign In to add comment