Příspěvky

1126

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 16. 06. 2018, 15:24:26 »

Čili index jakožto struktura je uložena na disku. Jaká data jsou uložena v té RAM? To jsou ta data, ke kterým se odkazujeme přes ty indexy nebo přímo ty indexy?

Vy si nedáte pokoj, dokud se nepustíme pod kapotu, žejo? Zkusím to nakousnout. Sám znám jenom obrysy. Možná vytrollím pár dalších, kteří doplní chybějící kousky, únavné podrobnosti, vyvrátí nepravdy atd.

No z velmi vysokého nadhledu potřebujete data v RAMce, aby s nimi kód běžící na CPU mohl pracovat, a potřebujete je i ukládat na disk - kvůli perzistenci (aby se počítač směl někdy vypnout) a taky proto, že se Vám celá databáze do RAMky často ani náhodou nevejde. Takže potřebujete mít převodní mechanismy mezi formátem v RAMce a na disku, a potřebujete algoritmy které si dokážou dotahovat z disku do RAM jenom nezbytné minimum, které momentálně potřebují k práci (a případně využití dostupné RAM nějak optimalizovat). A konkrétně u databází to znamená, že jak indexy tak "užitečná data tabulek" potřebujete na disku i v RAMce. (Byl by k něčemu užitečný index, který by se musel vejít do RAMky, a konstruoval by se vždy při startu RDBMS procesu?) Což nevylučuje možnost, že v RAMce budou nějaké pracovní, efemérní indexy a další struktury "navíc", které se na disk neukládají (po restartu se vytvoří znova).

V širším úhlu pohledu se opět jedná o obecný programátorský problém :-) Jiné datové struktury jsou vhodné pro manipulaci s daty v RAM, jiné pro uložení dat na disku. RAMka používá jiné alokační strategie a organizaci dat než diskový prostor, a jiné způsoby odkazování/adresace. V RAMce je výhodné (rychlé) používat přímé pointery na strojové adresy v paměťovém prostoru CPU, kde je alokován nějaký struct nebo jeho member, [ i ]tá položka v poli apod.  Přímo nad těmito strukturami pracují algoritmy zkompilované do binárního strojového kódu, běžícího na CPU = přímo s nativními pointery pracují instrukce CPU. Samozřejmě by šlo i v RAMce letmo dohledávat nepřímé odkazy přes "lidské" identifikátory... možná to tak zrovna databáze dělají, nevím. (Teď bych sem nepletl interpretované jazyky a varianty jejich "vm" - v zásadě je tam tlustá vrstva abstrakce navíc.) Naproti tomu na disku je bloková vrstva adresace, nad ní oddíly, v nich souborový systém, a v rámci souboru ofsety po bajtech od začátku... a formát pro uložení v souboru může vypadat velmi různě. Každopádně "přímo na disku" nemůže nic běžet, protože v datech na disku se CPU přehrabuje hodně dlouhým klacíkem... Err... v dnes obvyklých architekturách :-)

Obecně čím víc má být formát na disku lidsky čitelný, tím víc bude tíhnout k využití lidsky čitelné znakové sady (ASCII, Unicode apod.), řádky a pole uvnitř řádků budou členěny "čitelnými" znaky (čárky, středníky, tabulátory, konce řádku apod.), formát může tolerovat volné místo, komentáře apod. Viz třeba CVS, YAML, XML apod. Zároveň "lidsky čitelné" formáty souborů vyžadují nejvíc zpracování při převodu mezi runtime podobou dat v RAMce a formátem souborů. Proto se často používají jako exportní/importní formáty.

Naopak "těžce binární" formáty umožňují přesouvat data mezi RAM a diskem s menší mírou letmého přežvykování. Binární formáty čísel a řetězců, odkazy na bajtové ofsety spíš než na "lidské" identifikátory / čísla řádek/záznamů, implicitní velikosti uložených "structů" apod. Dovedl bych si třeba představit, že v on-disk formátu s pevnou délkou "DB řádku" zůstanou volná místa pro machine-level pointery (pokud jsou potřeba) ale to si cucám z prstu. Binární formáty jsou obvyklejší jako "nativní pracovní formát" všelijakého softwaru.  (Radši nebudu odbočovat, co je to relokovatelný executable kód, dynamické linkování sdílených knihoven apod.)

Přiznám bez mučení, že netuším, jak vypadá on-disk formát dnešních reálných RDBMS. Našel jsem nějaká hesla na wikipedii 1 2 , ale přijde mi to čtení stále dost abstraktní. Mohu jenom doporučit zdrojáky nějaké open-source DB.

Traduje se, že RDBMS nefungují příliš rády skrz souborový systém. Raději fungují přímo na vyhrazený diskový oddíl. Odpadne tím magie souborového systému, která může zpomalovat, násobit počet seeků apod. Ze stejného důvodu se tradovalo, že velikost stránky virtuální paměti hostitelského CPU (na x86 tradičně 4 kB) je pro RDBMS optimální alokační jednotkou na disku (sektor tradičně 512B, u nových disků točivých i SSD převažuje 4 kB).  Ale celé to má další zádrhele, třeba huge pages apod. Chtěl jsem říct, že takovéto souznění velikosti stránek by nasvědčovalo přímočarému kopírování dat 1:1 mezi RAM a diskem, bez složitého přežvykování = on-disk formát velmi podobný pracovnímu formátu v RAM. Ale jestli je to tak doopravdy...

Jinak je asi vcelku známá věc, jak funguje swapování. RAMka je "overbooked". Virtuální paměťové prostory user-space procesů jsou v součtu větší než skutečná fyzická RAM. User-space proces alokuje paměť podle potřeby. Stránky přidělené user-space procesům v kernelu eviduje memory management subsystém a pomocí LRU a spol si mezi stránkami vybírá ty "nejuleželejsí" - které v případě nedostatku RAM odkládá do swapu na disk. V tom případě se ovšem může snadno stát, že konkrétní user-space proces později sáhne "do prázdna" = chce stránku, která není v RAMce, protože byla odložena na disk. Tím vyvolá na procesoru výjimku zvanou page fault - vlastně obsluhu IRQ a přepnutí kontextu do kernelu. Kernel si nějakou tu stránku v paměti uvolní (podle LRU), přimapuje ji procesu který zrovna způsobil page fault, loadne do ní příslušnou stránku ze swapu a proces může pokračovat v práci (je v plánovači vrácen mezi "běžící"). Proč to tady vytahuju? Hned to bude.

Se soubory se totiž dá pracovat dvěma způsoby:

• Jednak známějším open()/seek()/read()/write()/close() = soubor v programu otevřete a nějak ho žužláte, třeba do něj po jednom sekvenčně zapisujete ASCII řádky nebo nějaké binární "záznamy". Tzn. data podáváte syscallům skrz nějaký buffer v user space, a data se následně kopírují do kernelu.
• No a druhý způsob je, že se soubor dá namapovat do paměti. Tuhle fintu umí syscall mmap(). Přesněji řečeno, mmap() je třeba zavolat na otevřený file descriptor (tzn. napřed proběhne open()) a jsou tam nějaké nuance jaké flagy mmap()u předat. Tímto způsobem není potřeba data kopírovat mezi kernelem a user space - prostě se do user space namapuje pár stránek přímo z bufferu blokové vrstvy. A tento mechanismus funguje prakticky stejně jako paging podložený swapem (nuance/flagy stranou) tzn. dá se zařídit, aby se ze souboru dotahovaly stránky až když jsou potřeba (díky page faults). V těch heslech na wikipedii se dá dočíst, že page faultů je vlastně několik stupňů, a že se může stát, že bloková vrstva díky read-aheadu načte do bufferů pár stránek navíc, nepřimapují se všechny hned, ale příští page-fault třeba sáhne jenom po další stránce v bufferu (nemusí čekat na diskovou operaci).

 

Čili opravdu líný RDBMS engine (= user-space démon) by mohl třeba jenom namapovat z disku celý extent / table-space do svého adresního prostoru a těžkou práci s ládováním z disku do RAM (a naopak odkládáním na disk) nechat na memory-managementu hostitelského OS :-)  = na jeho LRU, page-faultech, blokové vrstvě, managementu disk IO bufferů a tak. Nicméně pokud jsem měl možnost pozorovat, RDBMS si naopak tyhle věci rády spravují samy... naalokují si ze systému co nejvíc RAMky a pak si s ní interně hospodaří po svém.

Tohle jsou opravdu jenom velmi hrubé obrysy. Na rootu bacha, "kdo se moc ptá, moc se dozví." Jestli se návnady chytí někdo od fochu, budu nakonec se svým tapetováním vypadat jako břídil.

1127

Odkladiště / Re:Výroba plošných spojů laserem a leptáním

« kdy: 15. 06. 2018, 13:24:29 »

- vlastní osvitka postavená z UV LED pásků (cca 60W, expozice 2 minuty)

Potkal jsem borce co si postavil osvitku ze starého A4 flatbed skeneru.
Jakási stará kráva tlustá asi 8 cm.
Vykuchal vnitřnosti a na dno položil plošák posázený UV LEDkami.
Výkon nevím. Je to už pár let, měl tam jednotlivé nohaté LEDky
v klasickém 5mm pouzdru.

1128

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 15. 06. 2018, 13:13:22 »

Vy to ale pořád píšete opačně. Index primárně slouží pro vyhledávání (a tudíž není unikátní). A s pomocí toho indexu se dá nastavit omezení na sloupci, aby byl unikátní, pro což se pak používá zkratka „unikátní index“. Samozřejmě, že pro vyhledávání je lepší mít index než ho nemít. A různé typy indexů mohou být pro určitý typ dat lepší než jiné – a unikátní index může být o něco efektivnější, než neunikátní. Což je ale jedno, protože unikátní index se nastavuje především kvůli tomu omezení unikátnosti dat.

Myslím, že jsem konečně pochopil, o co Vám jde. Děkuji za vysvětlení, že kočár patří za koně :-)

1129

Odkladiště / Re:Vyroba plosnych spoju laser+leptani

« kdy: 15. 06. 2018, 11:08:30 »

V domácích podmínkách je problém právě v reprodukovatelnosti procesu. A vůbec mít na tu chemii prostor a čas.

Zkoušel jsem přenos nažehlováním a podle mých zkušeností závisí výsledek na použitém toneru. Jestli na mědi drží nebo nedrží. Pokud nedrží, tak Vám nepomůže ani svěcená - můžete odmašťovat desku jak dlouho chcet, nebrat výtisk do ruky, používat "samolepový" nepřilnavý papír nebo vodou namáčecí samolepící papír apod. S dobrým přilnavým tonerem to funguje i na kancelářský papír. Na nepřilnavý toner nepomůže nic. A bohužel jsem nezjistil způsob, jak předem zjistit, který toner bude držet a který nikoli. Potkal jsem lasery Canon a HP které "držely fest", ale po výměně tonerové patrony najednou nikoli. A nehrálo roli, jestli je nový toner originál nebo neoriginál. Vliv má taky teplota žehličky nebo laminovačky, pomocí které toner obtiskáváte na měď. Laminovačky mají většinou příliš nízkou teplotu a termostat co nejde hacknout. Na tiskárnách jde málokdy nastavit sytost výtisku atd.

Zkoušel jsem i fotocestu... včetně fint s natavením laserového výtisku acetonovými parami apod. Překrytí více výtisků je fajn, ale problém je, že výtisk laserem na fólii je vždycky trochu deformovaný, takže překryv není dokonalý. Takže překryv dvou výtisků jenom pro maličké motivy. Výtisk inkoustem na fólii není dostatečně sytý / neděravý. Vytisknout na pauzák a prolít ho "zprůhledňovacím lakem"... ach jo a tak dál. A nakonec se mi taky stalo, že jsem měl parádně kontrastní předlohu, a stejně se kus plošáku nevyleptal a jiný kus měl děravé plochy, co měly zůstat. Přímo na kalibračním obrazci, kde jsem si testoval dobu osvitu s postupným odkrýváním ve 4 krocích. Při manipulaci jsem si svítil 20W červenou žárovkou pro fotokomory a osvit horským sluncem, a ten proces jsem měl předtím už vyzkoušený.
Používal jsem materiál s již naneseným fotorezistem (prodáváno zabaleno v černé fólii). Asi to byl šmejd, ve zpětném pohledu mě to u dotyčného dodavatele nepřekvapuje. Pokud bych se o to snažil dneska, asi bych zkusil tisk na pauzák, nacucat vodou ředěným čirým akrylem, a fotorezist si na desku nastříkat sám. K tomu zas člověk musí být trochu šikovný jako lakýrník. Nebo někde sehnat tu "fotorezistivní samolepu" od DuPontu, jak tu někdo dával video...

A nakonec souhlas: jednovrstvý plošák se dá levně nechat vyrobit i tady, a maličké dvouvrstvé desky s prokovem bez speciálních požadavků dělají v AllPCB (a jinde v Číně) tuším 5 ks za 5 USD. Dodací lhůta cca do týdne. U Allpcb spočívá obchodní model (cenotvorba) zřejmě v tom, že maličkými jednoduchými plošáky "vycpou volná místa" na velké desce, kterou pak vcelku vyrobí. V podstatě si tím redukují odpad/odřezky. Jakmile chce člověk něco většího, nebo na tom nějaké speciality, tak cena rychle roste. Ale není problém říct si třeba o prokovené oválné díry, nebo frézované mezery s "mouse bites", od určitého minimálního rozměru V-grooves apod. - akorát to stojí peníze navrch. Nemá cenu např. naschvál "panelizovat" menší různé plošáky, pokud jich nepotřebujete fakt hodně - protože větší formát "panelu" stojí víc, než několik maličkých jednotlivých destiček (které si číňan rozhází do zbytků volného místa).

1130

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 15. 06. 2018, 10:32:03 »

Pokud by bylo více Danů v tabulce, tak bude ukazovat na všechny Dany.

Tak. V tom případě se nejedná o index unikátní. I tak má příznivý vliv na rychlost selectů apod., které nad pojednaným sloupcem budete provádět.

Ono je to opačně – index se vytváří kvůli rychlému vyhledání určitého záznamu v tabulce, a když je potřeba zajistit unikátnost nějaké hodnoty, vytvoří se nad daným sloupcem index, protože vyhledávat danou hodnotu bude nutné při každém insertu a updatu.

Já bych řekl, že naše tvrzení nejsou ve sporu :-)

Index v SQL lze vytvořit i bez požadavku na unikátnost. Proto souhlasím s tazatelem, že pak záznam v takovém indexu (např. btree koncový list) odkazuje na množinu/kolekci záznamů v "hostitelské" tabulce. A příznivě se projeví na rychlosti selectů / joinů apod. nad takto indexovaným sloupcem = neunikátní index je lepší než žádný index. A že není unikátní, to vyplývá z reality = z dat, která ten sloupec uchovává.

Teď mluvím na abstraktní úrovni - jak to vidí "uživatel DBMS" = SQL programátor. Jak je to implementováno pod kapotou by určitě vydalo na zajímavou další debatu. Sám občas v c++ takové "hybridní grafy" vytvářím, a to se pohybuju obvykle jenom na heapu, o perzistenci se nesnažím.

1131

Software / Re:Tisk PDF vytiskne testovací stránku tiskárny

« kdy: 14. 06. 2018, 21:52:18 »

A není to spíš "košilka jobu" než testovací stránka? Anglicky banner.
A hele. Záložka "policies".

1132

Odkladiště / Re:Vyroba plosnych spoju laser+leptani

« kdy: 14. 06. 2018, 21:44:30 »

Já mám trochu strach, že to laser nevezme úplně dočista. Takže se na některých místech leptací roztok nedostane do kontaktu s mědí.

Taky jsem leptával. Dávno jsem přešel z FeCl3 na HCl+H2O2. Tam je zase potřeba trochu trefit koncentrace, jinak to celé zmodrá a šumí a neleptá... kyselina s peroxidem je taky dost exotermní, ale to vadí spíš při větších plochách leptané mědi. A není špatné při leptání lázní trochu "kejvat", aby se lázeň promíchávala, protože jinak vzniknou zóny s nižší koncentrací žíraviny a vyšší koncentrací produktů (asi hlavně CuCl2) a prostě kus je vyleptaný rychleji, kus pomaleji.

Nedávno mě šéf naučil na allpcb.com a asi už sám leptat nebudu. Už jsem asi starej na to dejchat chlorovodík a řešit likvidaci použitého roztoku. A ono to zabere i dost času, "mít kde" apod. Nechat si to vyrobit od číňanů je sice nesportovní a dopravné je nejspíš dotované jejich vládou, ale je to rychlé a výsledek proti domácím pokusům vypadá jak mimozemská technologie. V základní ceně pokovení cínem, prokovené díry, z obou stran nepájivá maska a košilka... Přijde mi užitečné spíš si pilovat designérské řemeslo, než si špinit ruce a životní prostředí domácím leptáním.

1133

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 14. 06. 2018, 20:26:51 »

Takže třeba když budu hledat Dan - tak index Dan bude ukazovat na ten řádek (s id=3) v tabulce.

Ano. Terminologická poznámka: index je celý ten strom zkonstruovaný nad sloupcem "jméno". Položka "Dan" je jenom jeden záznam v indexu, koncový "list" stromu. A ano, záznam v indexu obsahuje nějaký low-level odkaz na záznam v "hostitelské" tabulce. (Tedy pokud se jedná o index unikátní. Jak jste sám správně poznamenal.)

Pokud by bylo více Danů v tabulce, tak bude ukazovat na všechny Dany.

Tak. V tom případě se nejedná o index unikátní. I tak má příznivý vliv na rychlost selectů apod., které nad pojednaným sloupcem budete provádět.

Mimochodem index se dá definovat i nad více sloupci - tzn. můžete si třeba oindexovat "složený klíč", třeba jméno+příjmení. Kombinací více sloupců dosáhnete unikátnosti záznamů v indexu (nebo téměř).

1134

Server / Re:Vysvětlete mi indexování v databázi

« kdy: 14. 06. 2018, 09:47:08 »

Když nemám index, tak pokud zadám dotaz, tak se musí projet všechna data po jednom, pokud mám index, tak systém ví, kam má přesně jít a nemusí procházet všechna data. Index je datová struktura uložená v paměti a používá B+ stromy.

Zaklínadlo je právě B-tree. SELECT potom nemusí procházet (porovnávat) N záznamů, ale stačí mu log2(N) porovnání. Což znamená rozdíl 1000 vs. 10 nebo 1 000 000 vs 20. Ona údržba toho indexu taky něco stojí, ale odehrává se při vkládání záznamů (a i tak vložení záznamu opět NEznamená projít celou tabulku). Takže index má smysl pro velký počet záznamů a zejména pro tabulky (sloupce?) kde se často hledá (čte) a málo vkládá (zapisuje). Nebo nad sloupci, na které se provádí join mezi tabulkami!

B-tree má jeden obecný vtipný aspekt, přítomný v různých implementacích - pokud zkusíte používat nějaké B-tree knihovny v jazyce nízké úrovně, třeba v Cčku: samotná stromová struktura nijak těsně nezávisí na datovém typu, který stromem třídíte. Tzn. kostra stromu je prakticky stejná, ať se jedná o integer, nebo třeba o řetězec znaků o proměnlivé délce. (Nebo o Váš vlastní bizardní objekt se svéráznou sémantikou porovnávání.) Finta je v tom, že B-tree knihovně při vytvoření stromu předáte odkaz na "porovnávací funkci". V zásadě se jedná o funkci "je větší než", která bere dva argumenty "konkrétního cílového" datového typu. A pak už do stromu jenom sypete položky (resp. v našem případě odkazy na záznamy v DB) a on si porovnávací funkci úkoluje po svém. Vám při vyhledávání vypadnou hotové výsledky. Zdejší věrozvěsti funkcionálního programování zajisté pobaveně kroutí hlavou jak přednáším o vynálezu kola.

Nicméně... Jak je ten index uložený v paměti? Nedovedu si to prostě představit... to se vytvoří nová tabulka? Jak ta tabulka bude vypadat? Jak probíhá to "propojení"? Jak si zvolím ty hodnoty indexové? Když budu mít index na id nějakých zaměstnanců, tak z těch id se vytvoří ten b+ strom? Když budu chtít index na příjmení zaměstnanců a třeba budu hledat "Novák" - tak jak to bude konkrétně vypadat? To se projede ten index a index odkazuje na ty data přímo a projde se mnohem méně těch datových položek?

Jak je index uložený v paměti. Jak je binární strom uložený v paměti. Zkoušel jste programovat v Cčku, Pascalu, Perlu, nebo nějakém jiném jazyku, kde lze dynamicky alokovat "kompozitní" datové typy jako struct/record a odkazovat se na ně pointery/referencemi apod.? Většinou je tahle látka vyučována cca v pořadí pointer, struct, linked list, strom. Plus na to navazuje téma o "alokátorech" paměti = jak se z té "společné hromady" parcelují kousky RAMky pro jednotlivé structy = uzly stromu, tzn. co se skrývá za funkcemi jako malloc()/free(). To se pořád bavíme o RAMce / heapu. On se ale index nemusí do RAMky celý vejít, nebo není potřeba aby místo v RAMce trvale zabíral. A rozhodně potřebuje mít zajištěnu "perzistenci". Takže ano, ukládá se i na disk. Vlastně se dá i přímo na disku procházet, aniž by se celý do RAMky natáhl. Opět platí výše zmíněné "poměry akcelerace" - jenom už se nebavíme o porovnávacích operacích co operují čistě v RAMce, ale latence každého kroku bude určena latencí seeku na disk. (Nebo něco mezi, protože několik uzlů B-stromu bude na disku pohromadě v jedné alokační jednotce.) Navazuje problematika alokace místa na discích - a nebudu odkazovat striktně na souborové systémy, protože mnohé databáze rády fungují přímo na diskový oddíl (blokové zařízení) a spravují si alokaci "po svém". To je myslím už poměrně dost buzzwordů do googlu, co říkáte :-) Samozřejmě je index s tabulkou provázaný odkazy, jak v RAMce, tak na disku. Skutečné interní algoritmy indexování, alokování souvisejících datových struktur v RAMce a na disku, to je "sladké tajemství" každého DB enginu. U komerčních DB se jedná o obchodní tajemství / klíčové intelektuální vlastnictví, u open-source DBMS Vám nic nebrání ponořit se do zdrojáků a číst. V souvislosti s indexováním se zkuste mrknout vedle b-trees také na "hash" algoritmy, které k problému přistupují trochu jinak a mohou urychlit prohledávání indexu jiným způsobem.

Pro Vás jako uživatele RDBMS  = programátora aplikace a SQL dotazů je důležité, že tohle všechno se děje "pod kapotou", kam v zájmu svého duševního zdraví nechcete moc nahlížet. Od toho Vám pánbůh seslal DB engine, aby se postaral o Vaše pohodlí. Takže na úrovni SQL není index sám o sobě moc vidět. Vy ho vytvoříte příkazem cca CREATE INDEX ON TABLE, čili vznikne tam jakýsi objekt ve "jmenném prostoru věcí co jste si v databázi vytvořil", ale je pevně přivázaný ke konkrétní tabulce, a při SELECT/INSERT/UPDATE/DELETE se každopádně bavíte pomocí SQL příkazů explicitně s _tabulkou_, nikoli s indexem. Čili Index je v tomto smyslu občanem nižší kategorie než třeba "view". Nebo jinak, Index je za provozu spíš jenom takový "astrální duch v pozadí", který na Vaši tabulku potichu dohlíží. Existuje také explicitní "DROP INDEX", v různých dialektech SQL buď samostatný, nebo v rámci "ALTER TABLE".

A ještě jedna poznámka: snad všechny DBMS vytvoří impliticní index, pokud zmíníte klauzulku PRIMARY KEY v rámci SQL příkazu CREATE TABLE. Prostě primární klíč bývá implicitně indexovaný, aniž byste si o index musel ještě nějak extra říct pomocí CREATE INDEX. Stačí že si řeknete o PRIMARY KEY.

1135

Hardware / Re:TouchScreen na Linuxu

« kdy: 13. 06. 2018, 23:26:59 »

Náhodou jsem v googlu zakopl o tohle vlákno na rootu a domnívám se, že to téma je nadále aktuální. Svůj aktuální pohled na věc jsem popsal zde. A možná ho budu zanedlouho aktualizovat ;-)

1136

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 12. 06. 2018, 19:55:59 »

Učebicové OOP říká, že máme dát metodu save() přímo do User. Na první pohled to zní logicky a elegantně, ale je to v principu kravina. Ten User bude mít vazby na další třídy, třeba na Company a Address atp. Co bude v metodě save(), když byl vytvořen rovněž i Company a Address objekt a User na to má návazovnost, tzn. nemá smysl vytvořit Usera bez nové Company a Address? Jenže v modetě save() v Userovi se přece nemůže zpracovávat i Company a Address, to je kravina.
(...)

Omlouvám se přítomným, že nejsem v oboru formálně vzdělán - a proto téma chápu do značné míry jako laik, naivní umělec, perpeťák - nepolíbený gramatikami, náročnou krásou funkcionálního programování apod. Kdo četl Neználka, a pamatuje si kuchaře, který vynalézal suchou vodu? Zároveň jsem dostatečně stár na to, abych chápal, že obvykle tu coderskou dřinu mi nakonec stejně nikdo neodpáře, ať se s vrstvením abstrakce trápím sebevíc a ať obracím sémantickou konstrukci naruby kterýmkoli z pěti způsobů.

Svého času někdy začátkem století mě podobné úvahy dohnaly jednak k tomu, abych si trochu prořezal zoubky o g++ v Linuxu a o vnitřnosti Perlu... a taky abych se zamyslel nad společnými rysy dnes (dodnes!) dostupných programovacích jazyků a DBMS.

Zrovna problém perzistence dat v běžných jazycích je hodně zajímavý. A přijde mi, že dědit nebo komponovat "invazivně" nějakou infrastrukturu pro perzistenci přímo do "mých" objektů je případem snahy, řešit něco na nesprávné vrstvě abstrakce. Správný postup podle mého: ve svém programu bych perzistenci neměl explicitně řešit! Perzistenci by měla zajišťovat nějaká "ODBMS mezivrstva", cudně skrytá za "metamodel" jazyka, ve kterém programuji. Řekněme, že by šmahem všechny objekty, které ve svém jazyce vytvořím, měly automagicky zajištěno perzistentní ukládání do nějakého "backendu pro zajištění perzistence". Takže jednou vytvořený objekt by nikam nezmizel, a třeba po vypnutí a zapnutí programu by ve "jmenném prostoru" jednoduše dál existoval.

Ta "perzistenční mezivrstva" spolupracující s metamodelem by mohla mít štelovatelné čudlíky: v zásadě by bylo na výběr write-back vs. write-through, a pokud write-back, tak třeba ještě dodržet aspoň pořadí transakcí, nebo se v zájmu průchodnosti vykašlat i na pořadí (logicky s rizikem nekonzistence dat v permanentním úložišti při pádu nebo ztrátě napájení).

Tzn. žádné user.save().  Volání konstruktoru 'new user()' by podle nastavení znamenalo buď: že v okamžiku návratu z konstruktoru je objekt již perzistentní, nebo třeba zatím není na disku ale brzy bude (a ve správném pořadí dle fronty s předchozími transakcemi), nebo na disku "zatím není a bude časem, až se to bude hodit" - každopádně při práci s objekty "user", firma, poštovní adresa apod. by se programátor nad nějakým save() vůbec neměl zamýšlet.

Referenční integrita mezi instancemi je další velice zajímavé téma. Dnešní jazyky mají "vztah mezi instancemi" zařízen objekty typu pointer, reference apod. Prostě jednosměrný ukazatel, u kterého v principu hrozí, že bude ukazovat kamsi do propasti. Jasně - pokud bude mít povinnou inicializaci zavěšením na existující cílový objekt, tak zrovna inicializace už je ošetřená. Ale co když ten cílový objekt časem zanikne, nebo bude potřebovat zaniknout? atd. Prostě mě tyhle úvahy dovedly k následující fintě:

Uvažme vztah mezi instancemi jako dvousměrný objekt. Speciální druh objektu v metamodelu programovacího jazyka. Měli bychom instance, a vztahy mezi nimi. Vztah mezi instancemi by mohl existovat jenom ve chvíli, kdy by existovaly obě "koncové" instance. Pokud by jedna z obou instancí zanikla, zanikl by vztah. Přesněji řečeno, dalo by se pravidly pro "vztahovou integritu" předem jasně určit (třeba v programátorem deklarovaných třídách), které vztahy jsou povinné, které nikoli, zda smí "protějšek ve vztahu" prostě svévolně umřít, nebo zda mu má být v úmrtí zabráněno, nebo zda se mají instance mazat v kaskádě apod. Užitečným speciálním druhem vztahu by mohlo být "vlastnictví"= vztah nadřízenosti a podřízenosti mezi instancemi. A samozřejmě stojí za úvahu, jak takové vztahy, které instance může mít ale nemusí, jak je implementovat v "jmenných tabulkách symbolů" v našem hypotetickém jazyce. V tradičních jazycích jako je kompilované Céčko, jakmile je deklarována proměnná, lze se na její jméno trvale odkazovat. Pokud se odkážu na jméno, které neexistuje, tak je to jasná compile-time chyba, protože existence/neexistence jména se nemůže měnit za běhu. V jazyce, kde vztahy průběžně vznikají a zanikají, by toto muselo být nějak ošetřeno. Výjimkou při pokusu o přístup ke vztahu s nenalezeným jménem, případně nějakým explicitním opatrným testem jako exists() apod.

Podle mého to vede na interpretovaný jazyk integrovaný s triviálním ODBMS enginem. Jaký back-end by se použil pro ukládání na disk, to je vcelku vedlejší. Já jsem tehdy před 15-18 lety sáhl po MySQL, ale zřejmě by to šlo naroubovat stejně dobře na libovolný key-value store, pokud bych nechtěl psát svůj vlastní backend nad holými soubory. Důležité je, že do storage back-endu by to ukládalo data v poměrně primitivním "datovém metamodelu". Datový model uživatelského programu by NEBYL součástí low-level datového modelu používaného na back-end databázi. Back-end DB by odpovídala "metamodelu", uživatelský datový model by žil "o vrstvu výš". Potažmo otěže referenční integrity na úrovni back-endové SQL DB nebo KV-storu by držel pevně v ruce primitivní ODBMS engine mého jazyka - a jak již řečeno, referenční integrita v metamodelu mého jazyka by byla řešena "obchvatem od lesa" :-) přes obousměrné vztahy mezi instancemi a jejich definovatelná "integritní omezení".

Plus je zajímavé se zamyslet, že by ta věc mohla být vícevláknová, jak tam udělat systémově nějaké jemnější zamykání mezi více uživatelskými vlákny apod. Uživatelské účty a uživatelská práva... tohle je zrovna dost nuda.

Pokud se týče back-endu, je třeba se zamyslet, jak řešit fungování jazyka v situaci, kdy nemůže držet všechny třídy a instance trvale v RAM. Že by se měl snažit, nechávat nějaká data na disku, a ládovat je až podle potřeby. Což znamená, implementovat v "ODBMS mezivrstvě" (ano tam to patří!) generický mechanismus, jak třeba při enumeraci vztahů nějaké instance natáhnout jenom "minimální kostru" sousedících vztažených instancí, a teprve on demand dotahovat celý jejich datový obsah. Nebo nedotahovat kostry sousedních instancí, ale jenom proto-vztahy? Toto jsem částečně rozpracoval (ošidil jsem to, zkrátil jsem si cestu v zájmu rychlejšího postupu.)

Další zajímavé téma je jmenný systém a na něj navázaný interní systém klíčů a odkazů v metamodelu a ODBMS.

Jak říkám, kdysi jsem si s tou myšlenkou trochu hrál, ale na vlastní programovací jazyk nikdy nedošlo. Ten školácký prototyp, na kterém dnes vidím spoustu chybných rozhodnutí a dost divný coding style, vykazoval základní životní funkce objektově-hierarchické databáze. Šlo vkládat jednoduché třídy a podle nich potom instance. Povedlo se mi i zhruba embednout Perl, ale bylo mi jasné, že nevím jak dál. Jednak Perl při každé chybě shodil celý můj engine :-) a druhak jeho stávající metamodel byl s mým vybájeným metamodelem dost neslučitelný. Dalo dost sebekázně, napsat tam aspoň jednu-dvě primitivní "vložené procedury", které by nepadaly na perlovou syntaktickou chybu. Čili pokud jde o nějaký jazyk, který bych s tou svojí "databází" bezešvě integroval, musel bych začít s čistým listem papíru. A zhruba v tom okamžiku mi taky definitivně došel volný čas na blbosti :-) Rád bych se k tomu ještě někdy vrátil, ale uvidím, jestli to stihnu, než mi moje šedá kůra zdřevění natolik, že už to nedám.

1137

Odkladiště / Re:Roky starý megabotnet bez povšimnutí

« kdy: 06. 06. 2018, 09:19:21 »

a nemoze to byt napriklad browser extension AdNauseam?

Za mě +1. Trochu čtení: 1 2

1138

Odkladiště / Re:Roky starý megabotnet bez povšimnutí

« kdy: 06. 06. 2018, 07:45:28 »

děkuji za zajímavou debatu :-) si zas jednou připadám starej a mimo... Chtěl jsem navrhnout "a co na to sám Google" ale nakonec to nenavrhnu :-) Vidím k věci spoustu debat, např. 1 , 2 . Jsou tam i zmínky o nějakých komerčních "filtrovacích službách" nebo co.

Dochází mi, že existují nejmíň tři-čtyři různé motivy a druhy "AdSense click fraud" útoků:  ...anebo ne, jenom bych poskytl inspiraci spoustě blbečků, kteří nejsou ani na úrovni script kids, protože tenhle opruz se na černém trhu zřejmě prodává jako placená služba. Takže vlastně už jsem návod poskytl :-(

Sumárum: to je peklo...

Napadá mě, jestli ta "několik let stará IP adresa" není spíš sirotek / troska nějakého botnetu, který třeba už dávno přišel o hlavu, ale nepovedení osiřelí pavoučí zombíci dál šmejdí po webu a pseudonáhodně klikají na AdSense, jak je kdysi někdo v rozmaru experimentování stvořil...

1139

Software / Re:Pomoc sekretářkám - automatizované zpracování faktur

« kdy: 31. 05. 2018, 11:40:14 »

Co mě fascinuje je, jak si všechny faktury vedou v tištěné podobě a využívají českou poštu. Proboha proč si to neposílají elektronicky? Musí všechno pak přepisovat z papírů do PC, tak zase z PC do papírů. Teď ke všemu každý jejich zákazník má ty faktury udělané jinak.

Chtělo by to rozjet informační systém, který bude sloužit k zadávání faktur mezi firmami, které si ho zaplatí, tím vznikne unifikovaný interface pro jejich obchodní vztahy. Každá firma, která do něj vstoupí, z toho bude mít přirozeně velké výhody.

Jedna věc je, že ve kšeftě je čím dál běžnější, posílat faktury v PDFkách bez doprovodu papírovou kopií. Faktura je nakonec jenom "výzva k úhradě" (ano a daňový doklad) - tzn. nic co by bylo třeba předávat proti podpisu z ruky do ruky. Pokud příjemce fakturu neobdrží, on se odesilatel ještě rád znovu ozve. Přesněji pokud příjemce potřebuje zboží dál prodat, má ve firmě pořádek (ISO, informační systém) a dostane zboží bez faktury, tak se obvykle rád a důrazně přihlásí odesilateli s požadavkem "kde je faktura" :-)

Bohužel prosté "poslání PDF mailem" snad trochu ušetří naše lesy, ale nezbaví to lidi v kanclu nebo ve skladu ruční práce s přepisováním cen do "svého systému".

Pro skutečnou automatizaci oběhu standardních "obchodních dokumentů" (hlavně objednávka/faktra) už aspoň dvacet let existuje EDI. Bohužel je to spíš obecná kategorie datových formátů, API a organizačních uspořádání, než nějaký jednotný standard. Nějaké skutečné standardy v rámci EDI samozřejmě dávno existují. A různé "podnikové informační systémy" = klasické ERP a menší "alternativní taky ERP" až po "účta" je nejspíš i podporují, minimálně pomocí optional modulů. Ale že bych toto viděl někdy nasazeno v praxi... neviděl. Možná proto, že dělám v malé firmě. Dodavatelů mraky a objem objednávek od jednotlivého dodavatele není velký. Ještě daleko víc nadrobené je to vůči zákazníkům. Nepátral jsem jestli třeba Cybersoft má tuhle možnost v i6 (třeba i nějak proprietárně), když dokáže mezi firmami které jedou na i6 navzájem kopírovat aktuální ceníky.

Když si vezmu naše relativně velké dodavatele a zákazníky, a jak by se asi proti nim provozovalo EDI, vidím třeba problém i v různých "specialitách", které různé firmy mají ve svých objednávkách (a snaží se nás přimět, abychom je zrcadlili, což někdy jde a jindy ne) tzn. datový model různých ERP systémů se navzájem liší a pak jsou ještě zakázkově customizované... Třeba jenom jednopatrový model "položky per objednávka", vs. vícepatrové systémy s "konfigurovatelnými sestavami pod jednou položkou per objednávka" (SAP) apod. Schopná pečlivá sekretářka se v tom po nastavení nějakých organizačních pravidel vyzná, ale automat... no nevím.

1140

Software / Re:Co je Git?

« kdy: 31. 05. 2018, 11:15:42 »

Pokud sem to teda dobre pochopil, tak kdyz budu chtit nejakou starsi/jinou verzi nejaky apky/softu z nejekych duvodu, tak si prave na tom gitu stahnu dejme tomu zdrojak, od nejakeho autora, ktery tam udelal zmeny, ktere mne vyhovuji k potrebam. Skompiluju a mam to, co mi vyhovuje. Tak nejak, laicky?

Myslím že míříte k jádru pudla.

Třeba já osobně jsem do žádného projektu nikdy nic necommitnul (ne v tom smyslu že bych si kvůli tomu zřizoval account s právem commitu), ale prakticky denně z GITu tahám zdrojáky věcí, které se mi hodí. Proč: v Linuxových distribucích bývají binární balíčky v různě uleželé starší verzi. O pár měsíců až let pozadu za aktuální verzí od autora dané "appky" jak píšete. Často mi v "distro-balíčku" schází nějaká novější fičura, která už je ale v upstreamu v novější verzi programu. Z druhé strany mnohé menší open-source projekty se moc nenamáhají pravidelně releasovat, tzn. nehrají na nějaké "milníkové" oficiálně svěcené verze. Důležité je, že jednotlivé open-source projekty potřebují mít svoje zdrojáky někde "uskladněné", i pro svou pracovní potřebu. Ty nejlepší je mají trvale vystavené volně na webu, v té nejčerstvější verzi. A to nejlíp jak? V GITu. Dříve v CVS nebo SVN apod. Tzn. na internetu není jenom bleeding edge verze, ale tato včetně celé historie, hezky přehledně. Kdokoli může přijít a vybrat si buď nejčerstvější stav, nebo libovolný commit v historii. Pro autory/maintainery projektu tenhle "veřejný" read-only provoz včetně kompletní historie neznamená žádnou práci navíc (pokud beztak musí používat verzovací systém interně pro kooperativní vývoj). A já nemusím tahat z webu nějaký releasnutý tarball s kulatou verzí, stáhnu si z GIT repa poslední vývojovou verzi. Nebo nějakou předchozí, pokud bleeding edge není stabilní. Spousta OSS projektů má ale čerstvé vývojové verze natolik dobře testované, že prakticky nenarážím na bugy ani ve skutečně živém posledním vývojovém kódu. Přinejhorším stáhnu poslední nightly, pokud je projekt nebezpečně živý (mění se pod rukama). Jasně - musím si to pak ze zdrojáků u sebe zkompilovat. Jsme na linuxu ne... potažmo čerstvou verzi různých projektíků nejsnáz zkompiluju na čerstvém populárním distru blízkém vanilce (nějaký poslední Debian nebo ještě Ubuntu - nevím jak Klobouk/Fedora, poslední dobou je moc často nedostanu do ruky).

Vynikající věc je Gitweb = webový obličej do GITu. Když se chci podívat, jak je něco udělaného v kernelu (a vím kam přesně se chci podívat), nebo mi nějakou periferii nebere driver ve starším distribučním kernelu, a chci se mrknout, jestli PCI IDčka už přibyla do vanilky, podívám se skrz Gitweb - aniž bych musel stahovat tarball k sobě na disk, rozbalit ho, CD do adresáře apod. Z Gitwebu i poměrně snadno zjistím, jakou má daný soubor historii, kdy se na něj sahalo, a často už z popisu commitů vidím, ve které verzi Kernelu a cca kdy časově přibyla podpora pro můj hardware. Bohužel jsem se zatím nenaučil v gitwebu rychle grepovat nebo dohledávat deklarace datových typů, maker apod. napříč mezi soubory (cross-referencing) - možná jsem jenom nešikovný, že tuhle grepovací práci páchám stále na lokále v shellu (komfortnější by asi bylo nějaké IDE, ale to jsme pořád na lokálu. Zjišťuju že ve spoustě "best practices" jsem dost zakrnělý.)