Vlákno názorů k článku Sčítání.cz: jak to příště zvládnout lépe aneb úvahy o dnešním IT od anonym - No a vydali teda nejake post mortem, nebo...

No a vydali teda nejake post mortem, nebo ne?
Je verifikovatelne, ze slo opravdu pouze o ten naseptavac?

Pokud slo pouze o ten naseptavac, pak takove navrhnuti naseptavace bez toho aniz by nekdo v tymu rekl "hele kluci a tady by davalo smysl pouzit technologie pro full text search, kdyz se jedna o typicky full text search problem" mi zavani spise neznalosti.

Toto by melo napadnout bezneho programatora od webu s 2 lety praxe, ktery nekdy neco cetl o search algoritmech a vi co je google, na to nepotrebujete 30 let praxe v oboru ani zadnou multiodbornost.

Takova vec se uci na normalnich skolach v predmetech jako data structures and algorithms 101.

Tady se trochu dostavame k takovemu ceskemu problemu, kdy drtiva vetsina lidi od pocitacu jsou v cr samouci, a nemaji "dobre" formalni vzdelani.

Typicky samouk jede po ose 1) user 2) power user 3) sysadmin basic networking 4) "web developer" (whatever that means)

Drtiva vetsina lidi, ktere jsem za svou praxi potkal, tak proste neumeli programovat. Neumeli ani algo/data a neumeli ani architekturu OO etc. Umeli pouze nejake pseudo-structured programovani. Nejhorsi bylo, ze jim nebylo mozne vysvetlit ze programovat neumi, ze treba umi velmi dobre sysadminovani, ze umi slusne sitovani, ale ze programovani je jina disciplina.

V nasledne praxi vas vetsinou programovat nauci a kdyz uz, tak jen to high level architecture programovani (SOLID OO a jine), ale rozhodne vas nenauci nejakou analyzu problemu na spravne urovni abstrakce s ohledem na algo a datove struktury. Takovi lide pak nechapou co to opravdu je databaze, jak realne funguje, na jakych algo myslenkach je postavena. Z logiky veci je pak reseni na urovni "pouzijeme sql nebo se tady bude hodit specializovany fts software?" ani vubec nenapadne.

Nemůžete čekat post mortem, když to celé ještě běží a zároveň je to pod NDA.

Našeptávač je pravděpodobně zástupný problém (přidání bouncingu na frontendu nevedlo k zlepšení a stejně na tom ještě pár dní pracovali; první výpadky se objevily v nočních hodinách, kde nelze čekat masivní počet lidí).

Proč na načeptávač chceš používat fulltext? Není to právě ten nevhodný návrh z neznalosti problému, který kritizuješ? Fulltext je hledání malého vzroku textu ve velkém, pracuje s jazykem, naopak našeptávač adres je filtrování podle zadání z velké množiny, kdy ta množina je relativně statická. I elasticSearch na to používá extra algoritmy (suggesters) a nastavit elasticSearch, aby ustál špičkově stovky tisíc požadavků za sekundu není také sranda, naopak použití SQL databáze s indexy pro našeptávač nemusí být automaticky špatné řešení.

Vychazim z toho co je psane v textu clanku. Tezi mimojine i proto zacinam slovem "pokud".

Adresa neni, nikdy nebyla, a nikdy nebude staticky unikatni "diskretni" text, na ktery byste v databazi jednoduse/ska­lovatelne/sprav­ne udelal indexy.

Adresa je v praktickem(!) svete naprosto fluidni, casto se menici text, ktery nema pevne dane poradi, tech moznosti a variant v tom retezci je priserne mnoho. Kdyz si k tomu pripoctete uskali zemi, jazyku, morfologickych zmen, mozne unicode issues etc, tak vam vyjde, ze v sql bude obrovska bolest to navrhnout alespon trochu soudne a robustne.

Toto tedy neni problem hledani unikatni jehly v uzasne strukturovane klubce sena (sql).

Toto je problem hledani nejakeho vagniho ne uplne presne identifikovatelneho retezce (typicky fulltext search)

O tom jake fulltext search technologie a jak pouzit, o tom se muze vest debata.

Ale pouziti sql by default je tak nejak klasicke reseni problemu s daty. Velmi by mne tedy prekvapilo, ze se udelala nejaka hluboka uvaha, a doslo se k sql. Realisticky by museli dojit k fulltext search sw.

Kdyby to chteli mermomoci naroubovat na sql, urcite by sla ta adresni pole do nekolika fieldu, z nichz alespon nektere fieldy by jednoduse unikatne identifikovatelne byly - osobne si nemyslim ze toto reseni by byl zazrak, ale urcite by davalo vetsi smysl pokud by bylo podminkou pouziti sql (z jednoho radku to nikdy v prakticke realite nerozparsujete, obrovsky prostor pro komplexitu a chyby).

Pokud tedy zadani bylo jeden radek s adresou a vypadlo z toho tohle, tak fulltext.

No víte, pokud jste se již sečetl, tak jste asi viděl o co jde, ta chyba tam víceméně zůstala a dělá problémy dosud, při rychlejším vyplňování.
Je to vyhledávání s našeptávačem. Jinak řečeno, dejme tomu, když chcete najít ulici Nová, děje se tohle:
- napíšete z klávesnice písmeno N, aplikace pošle dotaz do databáze adres sql dotaz vyhledat ty začínající N a zobrazí je pod řádek jako nápovědu
-- napíšete z klávesnice další písmeno o, aplikace pošle ihned další dotaz do databáze adres, vyhledávájíc "No" - jestli píšete rychleji, tak ještě dřív než se dokončil ten předešlý
- a teď si představte co to udělá, když se upíšete, napíšete místo "o", "p", načež rychle zmáčnete Bsp a opravíte to na "o"...Co to udělá, když se pokusíte vrátit kurzorem a nějaký znak tam vložite, atd. .Tyhle kombinace nelze odhadnout a vychytat.

A asi co je hlavní, proč se vyhledávalo v sql - protože samotná databáze adres je v relační databázi, je to zkrátka externí zdroj dat, který měli použít. Navíc je to tedy státní registr, do kterého se ani moc hrabat nemůžou, než tam posílat povolené sql dotazy. Nemohli si tam tedy vytvářet další samostatné změny, jako třeba indexy, nebo pomocná identifikační pole.

Tento registr je "volně" ke stažení ve formě xml nebo sql. Můžete si ji stánout (po nějaké registraci a možná malém paušálním poplatku) a data si ztransformovat jak potřebujete. Jmenuje se to UIR-ADR. "Nedělat si v tom samostatné změny ve formě indexu" je jen lenost/odfláknutá práce.

To o čem mluvíte platí až když je napsaná podstatná část fráze (adresy) a výsledková množina je malá. Problém s sql databází je, když posíláte dotazy, které mají velkou výsledkovou množinu a tu ještě necháváte řadit, abyste vypsali nejlepší výsledky na začátku. To jsou dotazy kdy je napsáno málo písmen - těch je z principu hodně, a přitom se hodně opakují. Jednou z variant je mít predpočítaný index pro našeptávání. Tím je to podobné fulltextu (jen se používá jiný index - indexují se prefixy a ne pouze celá slova).
Pokud chcete používat sql databázi tak to asi také jde, ale musíte umět dotazy cachovat, abyste právě těmi krátkými a stejnými dotazy nezatěžovali databázi. Obzvlášť, když jsou zdrojová data neměnná, tak se vyplatí mít velkou cache nebo právě předpočítané indexy.

Jinak zrovna adresy málokdo skloňuje, takže morfologie problém není. unicode issues a podobně se dají řešit normalizací vstupu. Obzvlášť když našeptáváte jen české (a případně slovenské) adresy, a zahraniční necháváte bez našeptání. Takže bohatě stačí vzít adresu jako neutříděnou množinu slov, a našeptávat podle nalezených prefixů v této množině. Lidé často pochopí, že jim stačí z každého slova napsat prvních několik písmen. Horší je to s našeptávačem povolání, protože tam člověk často neví co se od něj očekává - jaký je "oficiální" název jeho povolání. Tam by se naopak hodil fulltext který by matchoval nějak obecněji. (Něco ve stylu "zadam to do googlu a pár prvních odkazů mi prozradí jak se tomu běžně říká".)

Vicemene s vami souhlasim.

Ja jsem neobhajoval sql pristup, naopak.

Ano, samozrejme se da v sql vymyslet pristup, ktery muze byt vhodnejsi, nebo ktery se bude myslenkou vice podobat principum fulltext search vyhledavani.

Chcete to ale v sql delat? Tot otazka. Za me ne.

K morfologii - kdybych bohuzel v minulosti neimplementoval zadavani adres pro spoustu zemi, tak bych s vami souhlasil. Nicmene lidi jsou schopni do adres napsat naprosto vse, az to cloveka zarazi. V podstate lze ocekavat ze ten clovek zada od prazdneho stringu po cokoliv. Ale ano, je to jen jeden z x ruznych problemu na ktere clovek narazi.

Adresy jsou presne ta vec, kde si kazdy nepolibeny rekne ze to je prece uplna brnkacka. A kazdy kdo si v tom vymachal zadek vam rekne, ze to uz nikdy nechce videt.

To ale není vyhledávač adres zapsaných v libovolném formátu.
Je to jen našptávač, který uživatele průběžně vede nabídkou cca 3 milonů adres, kde každá je zapsaná v jediném úředním formátu (nebo možná v několika málo variantách).

a uplne nejlepsi je spolehat se google

Co je podle Vás architektura OO?

Upřímně řečeno, to Vámi proklamované formální vzdělání, kterého mám já a kolegové skutečně kupu nás nedovedlo k nějakému valnému mínění o objektově orientovaném programování obecně. Typicky se tam vyučují věci (dědičnost), které jinde (třeba v Googlu) už radši zakázali, protože to byl typický zdroj chyb/ problematického kódu.
Obecně OO svádí k tomu, psát vlastně takový pseudojazyk jen pro ten konkrétní problém a zatemňovat tím řešení, kde jde v podstatě o relativně přímočarou transformaci strukturovaných dat.
Neřekl bych to lépe: https://www.youtube.com/watch?v=aSEQfqNYNAc

Jinak můj kolega udělal docela užitečnou OrgStránku o Clojure, kde je podobných postřehů více: https://www.orgpad.com/o/D6TrZny7tNhYqWygzax7Wx

Problém programování fakt není, že by někdo neuměl napsat algoritmus na vyhledávání, který už mnohem lépe a robustněji naimplementoval někdo jiný a já to můžu využít. Problém je, že máte fakt debilní API, které je naimplementované typicky chybně a v dokumentaci, pokud existuje, tohle není. Spousta věcí je zbytečně složitá. Třeba history API v prohlížeči už lže v podstatě v názvu. S historií to nemá nic společného, protože na seznam navštívených stránek se tím fakt nedostanete, můžete ale upravovat současnost (přidávat nový záznam nebo měnit ten současný) nebo přidat reakce na nějakou změnu - obojí z mého hlediska není historie. Kdyby Vám prohlížeč radši dal upravitelný (JSON) array popisujících stavy historie, které se třeba aspoň vztahují k současné doméně (kvůli soukromí), tak by se s tím pracovalo mnohem lépe. Nikdo by nemusel programovat a udržovat v podstatě žádné API. Byl by to efektivně jen get/ set, když teda přemýšlíme v OO. (Nebo třeba @/ reset!/ swap! v Clojure - kde by se tohle řešilo nejspíš přes atom, který by obsahoval vektor map, tedy posloupnost stavů.)
Na backendu jsou zase jiné špeky, třeba jenom úžasná komplexita TLS/ X.509 a neustálý příval chyb jenom v implementacích ne-li použitích. (Mimochodem M.W.Lucasovi vyšla nová praktická kniha TLS Mastery: https://mwl.io/nonfiction/networking#tls která by toto téma mohla stravitelně osvětlit do hloubky.)

No prostě programování v reálu je fakt mnohem méně o algoritmech a strukturách než jak se to prezentuje. Ve spoustě případů je to spíše takové sado maso v trpění různých rozhraní a protokolů, které zůstaly na půl cesty a nebo se radši neměly nikdy vytvořit. Váš příklad "pouzijeme sql nebo se tady bude hodit specializovany fts software?" je přesně to, co už není programování podle Vašeho popisu "algo/data a neumeli ani architekturu OO", ale návrh/ architektura systému.

Mimochodem, řešení našeptávače tak, aby obsloužilo současných např. 200 000 spojení fakt není typický příklad z datových struktur a algoritmů na vysoké škole ani nikde jinde. Typicky totiž ani sám vyučující neví (možná ale tuší), jak by tohle řešil.

To, ze sa niekto nedokaze naucit 4 pravidla pre OOP naozaj nie je problem OOP. Ale viem, dnes je velmi modrne programovat proceduralne a vytesovat s ake je to funkcionalne.

Jaká 4 pravidla máte na mysli? Co je OOP se dost diametrálně liší mezi jazyky. Jestli máte na mysli zapouzdření, abstrakci, dědičnost a polymorfismus, pak úplně míjíte OOP v jazycích jako Smalltalk, JavaScript nebo Lua.
Navíc tohle nejsou pravidla, podle kterých by se dalo jet, ale podstatně vágnější principy. Pokud se je pokusíte interpretovat jako pravidla, tak skončíte leda tak v průseru.

Tak dedicnost je pravidlo, tak to podedim, ne? :-D Teda pokud nejsem v Selfu, takze ten jasne nemuze byt OO :-D