O víkendu probíhá v Bostonu, a také virtuálně, konference LibrePlanet 2024 organizovaná nadací Free Software Foundation (FSF).
Nová vývojová verze Wine 9.8 řeší mimo jiné chybu #3689 při instalaci Microsoft Office 97 nahlášenou v roce 2005.
Coppwr, tj. GUI nástroj pro nízkoúrovňové ovládání PipeWire, byl vydán v nové verzi 1.6.0. Zdrojové kódy jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
Byla vydána dubnová aktualizace aneb nová verze 1.89 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Vypíchnout lze, že v terminálu lze nově povolit vkládání kopírovaného textu stisknutím středního tlačítka myši. Ve verzi 1.89 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Proton, tj. fork Wine integrovaný v Steam Play a umožňující v Linuxu přímo ze Steamu hrát hry určené pouze pro Windows, byl vydán ve verzi 9.0-1 (𝕏). Přehled novinek se seznamem nově podporovaných her na GitHubu. Aktuální přehled her pro Windows běžících díky Protonu také na Linuxu na stránkách ProtonDB.
Byla vydána verze 1.78.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Služba Dropbox Sign (původně HelloSign) pro elektronické podepisování smluv byla hacknuta.
Byla vydána nová major verze 8.0 textového editoru GNU nano (Wikipedie). Podrobný přehled novinek a oprav v oznámení v diskusním listu info-nano nebo v souboru ChangeLog na Savannah. Volbou --modernbindings (-/) lze povolit "moderní" klávesové zkratky: ^C kopírování, ^V vložení, ^Z vrácení zpět, … Tato volba je aktivována také pokud binárka s nano nebo link na ni začíná písmenem "e".
Před 60 lety, 1. května 1964, byl představen programovací jazyk BASIC (Beginners' All-purpose Symbolic Instruction Code).
Byla vydána nová verze 12.0 minimalistické linuxové distribuce (JeOS, Just enough Operating System) pro Kodi (dříve XBMC) a multimediálního centra LibreELEC (Libre Embedded Linux Entertainment Center). Jedná se o fork linuxové distribuce OpenELEC (Open Embedded Linux Entertainment Center). LibreELEC 12.0 přichází s Kodi 21.0 "Omega".
Současné firmy, stejně tak jako ty dřívější, dokáží generovat velké objemy dat o svých aktivitách a více či méně je podrobují zkoumání. To vše proto, aby zachytily trendy nebo hrozby v tržních segmentech jejich zájmu. Co se však mění, je způsob, jakým chtějí svá data zkoumat. Stále více je zájem zaměřen na porovnání stavů v určitých okamžicích jejich historie, přičemž starší data jsou typicky zajímavá v delších intervalech, řádu měsíců, nová data jsou zajímavá v intervalech dnů.
ROLAP team společnosti GoodData proto začal hledat v současných datově orientovaných enginech způsob, jak uchovávat historická data a současně umožnit nahlížet na jejich stav v libovolném historickém okamžiku s ohledem na možnost tyto okamžiky porovnávat. Ačkoli se od začátku jevil ověřený přístup implementace pomalu se měnících dimenzí v konvenční relační databázi jako optimální, ukázalo se, že akceptovatelný výkon takovéhoto řešení je spojen s neakceptovatelnými náklady. Když bylo zřejmé, že žádná dostupná technologie nesplňuje požadavky v masovém měřítku, zaměřil se ROLAP team na hledání vlastního řešení.
Zákaznická data často představují tzv. "snapshot", tedy otisk stavu uživatelem sledovaných aktivit k určitému času. Jednotlivé snapshoty jsou svázané unikátní entitou, jež je platná přes vybrané snapshoty. Zákazník pak typicky potřebuje znát stav svého systému v určitém okamžiku, který porovnává s jiným. Zatímco data starší více než rok nejčastěji porovnává v kvartálním intervalu, data starší tří měsíců pak v měsíčním intervalu a data do tří měsíců po týdnech.
Velmi často poslední (neúplný) týden chce zákazník vidět po dnech. Použití konvenčního databázového serveru vede na tvorbu ohromného množství záznamů na úrovni jednotlivých dnů, které jsou často identické v po sobě následujících snapshotech. Namísto toho zaznamenání pouhých změn mezi jednotlivými snapshoty představuje malé množství dat. Z pohledu dat je vlastně zapotřebí jen přehrávat změny tak, jak se staly v čase, a v patřičný okamžik uživatelům data poskytnout. Tato jednoduchá věta pak popisuje myšlenku na jejímž konci je datové úložiště známé v GoodData jako EventStore.
Vše co se děje uvnitř EventStore se zcela vymyká klasickému světu SQL. Data na vstupu do EventStoru jsou rozbita na sloupce, ze sloupců jsou vybrány změněné hodnoty entity a jen ty jsou uložené společně s okamžikem jejich platnosti. Přečtení dat pak připomíná přehrávač, který do výstupní matice dat zapisuje změny. Na konci čtení je kompletní matice s hodnotami platnými v rozhodném časovém okamžiku. Přehrávač přitom na začátku přehrává rychle po kvartálech, na konci pomalu po dnech.
Zatímco princip NoSQL úložiště byl dostatečně zřejmý, programovací jazyk nikoliv. Implementace, ve které by toto unikátní řešení mohlo fungovat, potřebovalo neméně unikátní jazyk. Perl se v tomto ohledu ukázal jako velice mocný programovací jazyk. Zejména jeho práce s asociativními poli (hashes) zcela přesně vyhovovala potřebám úložiště. Identifikace změn v nově nahrávaných datech, stejně tak přehrávání změn a získávání požadovaných snapshotů, jsou v Perlu neuvěřitelně přímočaré.
Použití uzávěrů (closures) vede k rychlému a přitom stále dostatečně čitelnému kódu. Pro každou transformaci či agregaci dat, zadanou strukturovaným předpisem AST (Abstract syntax tree), je za běhu vygenerován kód, který “eval” zkompiluje do anonymní funkce (zde do “closure”). Přímo za běhu tak využíváme interpret jazyka Perl pro kompilaci dynamicky sestaveného kódu. S podobným řešením se ve statických jazycích potkáte jen výjimečně. Perl také umožnil velice efektivně implementovat podporu pro generování historických relací. Nyní je možné výstup EventStoru nahrát přímo do klasické relační databáze, včetně pomalu se měnících dimenzí a v ní provádět klasickou ROLAP analýzu.
Úspěch celého řešení byl završen nasazením EventStoru v cloudovém prostředí Amazonu. Bylo tak dotaženo k dokonalosti webové řešení pro analýzu dat, od sběru, přes uchování, přepočítání až po vizualizaci. “Webovost” řešení je umocněna skutečností, že většina dat od zákazníků pochází z jejich webových systémů. Dá se říci, že data jsou na webu uložena a zákazníci si je nakonec přes web i zobrazí a analyzují. Co dodat závěrem? Snad jen, že ROLAP team GoodData stále hledá inovátory, kteří se nebojí opustit klasická řešení.
Jiří Schmid pracuje v oblasti BI od roku 2003, postupně prošel pozicemi od analytika a implementátora BI projektů až k vývoji klíčových komponent BI software GoodData, kde v současnosti pracuje jako vedoucí ROLAP teamu.
Nástroje: Tisk bez diskuse
Tiskni Sdílej:
S podobným řešením se ve statických jazycích potkáte jen výjimečně.Pokud tomu dobře rozumím, tak tohle by neměl být problém v jazycích, jenž podporují tzv. quotations (například C#, F#, OCaml nebo Haskell)?
Navic jsem 100% presvedcen, ze vetsina lidi (vcetne mne) nepochopila zcela o co jde.Není to tak složité. ROLAP (kde R znamená Relational) tým GoodData seznal, že relační databáze se na spoustu věcí nehodí, a tak vymyslel MOLAP (kde M znamená Multidimensional). A protože dneska je v módě všechno, co není SQL, označit za NoSQL, i když je to třeba postaveno nad SQL, tak tomu taky řekli NoSQL.