Sledovanie zmien v obstaravaniach

[jsuchal]

K #2 by bolo idealne keby uvobot vedel potom do topicu posielat aj updaty (kto vyhral alebo zmeny). Toto je tricky, kedze si to uz asi vyzaduje drzat databazu u seba.

[quatermain]

Moze byt idea Rails + HTTParty + Sidekiq + Whenever ?
Som sa nudil dnes tak som som premigroval code z master do railsov a httparty. Ak vyhovuje spravim fork a hodim to do branch 'rails'. Moze byt?

[jsuchal]

Hmm, Rails by sme tam naco tahali? Som rozmyslal, ze ActiveRecord by mal stacit nie? Inak prave sa mergol refactor, kukni.

Bezime na heroku, tam by sme vosli do free planu s tymto setupom?

[quatermain]

Rails preto lebo som rozmyslal nad nejakymi stats ako kolko zmien sa urobilo za nejake obdobie a tak, pripadne nejake primitivne api. Ale kludne len AC pripadne ROM ale to je uz komplikovanejsie.

Sidekiq preto lebo nepaci sa mi a tiez nie je dobre parsovat vsetko naraz, pekne to rozdelit a tak. A da sa to v pohode spustit aj na herokou free, mensi hack ale funguje to.

No aj hej ked sa to spravi dobre, hlavne kvoli obmadzenej ramke pri parsovani to dakedy vyskoci ale hadam bude vsetko ok.

[jsuchal]

@martinsabo teraz maka na #2 cize sa neposekajte.

Sidekiq je fajn / resp akakolvek ina queue.

Ten hack na Heroku je aky?

[martinsabo]

@quatermain Pockaj este ak mozes, nech sa trocha usadi trocha core. V mojom forku cakaju nejake signifikantne zmeny (nie vsetky su pushnute na github). O par dni by to uz mohlo byt.

Httparty pouzivam v inych projektoch, ale tuto mi fakt zatial nechyba. Requesty su zatial trivialne.

Queue je dobry napad, ale to ma cas. Zatial to scrapuje aj tak vzdy len prvu stranku.

Rails IMHO zatial netreba a ked uz, tak to nebude uvobot, ale nejake rozhranie co bude pracovat nad tou istou DB. V ramci uvobota riesme len "job/worker" ci ako to nazvat co ziska/ulozi data a rozposle notifikacie.

Takze by som navrhoval zacat skor s tym ukladanim do DB a detekciou zmeny. Do interfacu notifiera sa potom prida novy event popisujuci zmenu.

[jsuchal]

@quatermain je to mergnute, tato issue ma teraz prioritu. Treba upravit DiscourseNotifier tak, aby tie oznamenia rozlisoval a posielal updaty do topicov. Treba na to tabulku kde bude mapovanie id zakazky -> id topicu. Ides do toho?

Skusme nejaky high level nanecisto navrh (aj tu) a potom implementaciu.

[quatermain]

@jsuchal cez vikend sa na to pozriem. Len trochu som sa zamotal a nevidim ich identifikator. Resp. ako to robia.
Mame napriklad tento vestnik https://www2.uvo.gov.sk/evestnik/-/vestnik/326079.
Ten ma nejake ID 326079 a tiez cislo oznamenia 2049.

1. Ked urobia zmenu, ktore ID zostava? Kedze content sa bude brat z daneho html exportu, ktoreho meno oznamenie_326079.html tak predpokladam, ze 2049 je ID daneho oznamenia, ci? Alebo len na drzaka prepisu dany vestnik a my musime porovnavat vsetky, ktore mame ulozene v DB?
2. Zmenu robia asi komplet, cize do topicu pridat novy post s novym obsahom.
3. Porovnanie: ulozi sa komplet html daneho exportu a to sa porovna s novym exportom?
4. Chcete aj zanechavat historiu v nasej DB kde bude mozne pozerat historiu zmien?
5. Postnut aj nieco ako diff?
6. Nie upravit DiscourseNotifier ale dat "vrstvu", ktora rozlisuje ci je to create alebo update a nasledne zavola metodu notifiera, ktora tomu prislucha. Teda takto si myslim, ze by to bolo lepsie.

[jsuchal]

@quatermain este inak, musis skrollnut dole a tam hladat zakazka. https://www2.uvo.gov.sk/profily/-/profil/zdokumenty/2371/156914 To je to id. Su tam dokonca dve - jedno je obstaravatel druhe cislo zakazky.

inak bacha, novy vestnik je tu http://www.uvo.gov.sk/vestnik/oznamenie/detail/327585, ale ten pull request uz @martinsabo uz caka len na mergnutie. Cize tam sa nic velmi nemeni.

[jsuchal]

1. vid hore.
2. Ono to funguje tak, ze mas zakazku a k nej rozne oznamenia. Ziadne diffy robit netreba, staci sledovat to co sa k zakazkam pridava.
3. Nie, staci ti mapa id zakazky -> id topicu na fore.
4. Nie.
5. Nie.
6. Ten notifier ma metodu matching_annoucements_found
   https://github.com/slovensko-digital/uvobot/blob/master/lib/uvobot/notifications/discourse_notifier.rb#L20
   Kde treba vymenit len clienta, aby nevytvaral topic ak ho treba updatnut. Cize skor treba zmenit trosku parser (aby vytiahol id zakazky) a spravit lepsieho @client, ktory postne co treba do spravneho topicu. Predstavujem si to tak, ze ak existuje uz topic k zakazke, tak tam napise, ze "ohlaseny vitaz xyz" alebo nieco take. Su tam rozne typy oznameni, treba kuknut co ma zmysel. Ak topic neexistuje, tak ho vytvori so zakladnou info, aby sme vedeli co to je. Dava zmysel?

[quatermain]

Mierne som pokrocil, este to chce vela uprav kym to bude pouzitelne, svihnem si s tym. Prvy nahlad je tento commit quatermain@ea77651
Netestoval som to, len cez moj debugging styl. Vas styl kodenie je trosku iny tak mi to troska trvalo sa prisposobit ;-)
Kricte ak uvidite daco co sa Vam nepaci ale nie je to este final.

[jsuchal]

@quatermain ako vyzerame? @martinsabo nechces do toho pichnut aj ty?

[martinsabo]

@jsuchal ja sa "chystám" skôr na #9, ale keby @quatermain nestíhal môžem sa eventuálne pozrieť aj sem.

[quatermain]

@jsuchal po vikende poviem, ledva zijem tento tyzden. Ale to co uz mam len staci doladit a odstranit blbosti

[jsuchal]

@quatermain ping? Ci prenechavas stafetu @martinsabo ? :)

[quatermain]

najskor v sobotu sa mozem na to pozriet, to dokoncit ak ma @martinsabo tak kludne pis a hodim ti pristup do mojho forku

[martinsabo]

@jsuchal @quatermain nemam na to momentalne kapacitu