Sender | Message | Time |
---|---|---|
19 Apr 2024 | ||
bkil | Az oldaladat be tudjuk könnyen linkelni az OSM szerszámzat oldalra (vagy akár egyesével a tooljaid mélyebb linkeit) Viszont azt nem tartom praktikusnak, hogy a mátrix eldobható kitűzési funkciójában elvesszen az ilyesmi, vagy akár hogy neked kelljen a forrást az OSM wiki-n karbantartani például (onnan amúgy sem tudja húzd és viddel telepíteni a felhasználó, mert tisztítja a hivatkozásokat) | 20:42:53 |
bkil | Még egy praktikus funkció amit néha belerakok, hogy indításkor megnézni, hogy azon az oldalon vagyunk-e amelyikre volt írva a bookmarklet. Ha nem, odamegy. Következő kattintásra fut. És akkor bookmark + bookmarklet egyben. Ezekből egyszer összerakhatnánk egy OSM/FOSS UserScript store-t is akár ha lesz elég. | 20:51:04 |
22 Apr 2024 | ||
urbalazs | https://codeberg.org/urbalazs/osm-poi-hintmaker
| 16:32:01 |
itineris | In reply to @urbalazs:grin.huFelveszed a Wikibe is? | 19:03:06 |
urbalazs | Igen | 19:03:43 |
23 Apr 2024 | ||
bkil | Fixme elektronikai hulladék gyűjtőpontok listája https://www.janegoodall.hu/programjaink/passzold-vissza-teso-mobil-ujrahasznositas | 11:48:52 |
bkil | https://kovet.hu/passzold-vissza-teso-kampany/ | 11:50:36 |
24 Apr 2024 | ||
urbalazs | In reply to @urbalazs:grin.hu Átírtam, hogy legyen benne 300 ms várakozás a hívások között. Az volt a baj, hogy egyszerre dobta oda a NAV API-nak az összes számot, és ezért nem kapott választ az összesre. Most üzembiztosan működik:
| 12:04:29 |
itineris | Script kiddie. | 12:08:14 |
dnet | Download sd-osm.jpg | 12:12:31 |
dnet | már a második oldalt kezdtem meg gombokkal feltölteni :) | 12:12:41 |
urbalazs | A NAV captcha token 1 percig él, ez alatt kb. 200 kérést lehet elküldeni. Átlagosan 906 távolságra kell lenniük a számoknak. Ha a captcha megfejtését nem számolom (ami egyre szemetebb, van, hogy 5-6 megfejtés kell, hogy elhiggye, nem vagyok robot), akkor kb 4 perc alatt lehet 1 számot kipörgetni. Ez 300 nap, ha éjjel-nappal nyomom. | 13:03:48 |
urbalazs | * A NAV captcha token 1 percig él, ez alatt kb. 200 kérést lehet elküldeni. Átlagosan 906 távolságra kell lenniük a számoknak. Ha a captcha megfejtését nem számolom (ami egyre szemetebb, van, hogy 5-6 megfejtés kell, hogy elhiggye, nem vagyok robot), akkor kb 5 perc alatt lehet 1 számot kipörgetni. Ez 380 nap, ha éjjel-nappal nyomom. | 13:04:26 |
urbalazs | Az eddigi legfurább szám: U00000883 Ez az egyetlen eddig, amely 0-val kezdődik. Minden, amit találtunk, 1-9 az első számjegye. | 13:06:55 |
bkil | Probléma a snippetben: az osztott állapottér miatt fura dolgok történhetnek ha benyomod újra a gombot miközben fut egy lekérés. Kellene egy clearInterval és vendingTimer=undefined ha benyomják újra a gombot például. Illetve hasznos lenne megnézni, hogy be van-e már szúrva még mielőtt beszúrja, mert ha többször bemásolod akkor is lehetnek érdekességek. Valószínűleg érdemes lehet mindig kipurgálni gombnyomások között az előző eredményét, esetleg a textarea-t is. | 13:15:54 |
bkil | Többet tudna teljesíteni a script, ha 0 várakozást raknál bele, viszont lenne az ajax hívásodon ontimeout, amire ugyanazt bepróbálná exponenciális várakozás után (max. ötször például) | 13:16:53 |
urbalazs | Nem a felhasználóbarát működés volt a cél :) Én tudom használni, és tisztában vagyok ezekkel, ezért nem nyomkodok futás közben. | 13:17:05 |
bkil | Várakozás nélkül amúgy kb. hány százalék volt a veszteség? | 13:17:56 |
urbalazs | Lehet próbálgatni, a 0 szerintem kevés. Emlékeim szerint 40 alá nem érdemes menni a setTimeout() értékével, én ezt tapasztaltam. | 13:17:58 |
urbalazs | Várakozás nélkül volt olyan, hogy 10 számra csak 3-at adott vissza. Ha újra megnyomtam, akkor 7-et. Aztán 5-öt. --> nemdeterminisztikus | 13:18:39 |
itineris | Mindjárt megy rátok a TEK a NAV DoS-olása miatt... | 13:19:04 |
bkil | Itt van egy olyan sejtésem, hogy 300ms várakozás után már új socketet nyit a böngésző amit lehet, hogy másik gépre route-ol a load balancer. Míg kisebb értékeknél ugyanazon keep-alive kapcsolaton pipeline-szerűen betolja mind (ami hatékonyabb mind a szerver, mind a kliens szempontjából). | 13:19:36 |
bkil | In reply to@urbalazs:grin.huNem kell determinisztikusnak lennie. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/timeout https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/timeout_event | 13:20:38 |
urbalazs | Az adózás rendjéről szóló 2017. évi CL. törvény 266. § h. pontja írja elő, hogy az adatbázist a NAV-nak elérhetővé kell tennie a honlapján. Igazából én panaszolhatnám be amiatt, hogy egy amerikai szolgáltató ÁSZF-ét el kell fogadnom ahhoz, hogy hozzáférjek egy magyar jogszabályok által előírt adatokhoz. | 13:21:14 |
bkil | A térképwidgetem is így működik: lekéri az egyik csempekiszolgálótól és ha az nem válaszol párszázon belül már küldi is a kérést a következőhöz a listában. | 13:21:23 |
bkil | Vagy lehetne adaptívan TCP-által inspirálva nyilvántartani egy ablakot az utolsó in-flight lekérdezésről amit folyamatosan növelsz ahogy jönnek vissza a válaszok. Eleinte például 8-at küldesz be egyszerre, aztán 9, 10, stb | 13:23:18 |
bkil | Ugyanúgy ahogy nő a veszteség vagy a mért válaszidő, úgy lehet csökkenteni a párhuzamosságot visszafelé. | 13:23:53 |
urbalazs | Lehet méregetni, próbálkozni, gyorsítani a futást, de szerintem a 300 ms elég jó kompromisszumos megoldás 0 utánajárással. Nyilván, az összes szám kipörgetéséhez nem elegendő, de a jelenleg ismert kb. 600 számot 3 munkamenet alatt le tudom kérni, a captcha megfejtéssel együtt is 5 perc alatt megvan. Erre írtam a szkriptet. | 13:24:40 |
vasony | Redacted or Malformed Event | 18:17:06 |
vasony | * @bkil be tudod tenni ezt egy bookmarkletbe, nekedmégis nagyobb rutinod ban benne, ne én kinlódjak már. | 18:18:21 |