Názory k článku Tvorba sešitů pro tabulkové procesory v programovacím jazyku Go

Opravdu zajimave, ze si nekdo dal praci s vytvorenim pomerne mocnych knihoven na praci se spreadsheety do tak omezeneho jazyka, jako je GO

Examply jsou pekne, ale v realnem svete bude potreba mit komplexni model dat, se kterym budu manipulovat a pak ho finalne vyleju do excelu.
Takze neco ve stylu Java Collections naplnene beanama, transformace bean dat z Hibernatu do excel friendly formatu pomoci stream api apod.
Nebo C# LINQ.

jj určitě, tato knihovna zajišťuje jen a pouze exporty dat, navíc na dost nízké úrovni (což mě osobně vyhovuje, protože si nad tím abstrakci můžu i nemusím postavit, jak potřebuji). Není to komplexní řešení, už jen proto, že by snaha o obecné řešení asi vedla k používání interface{} :)

Trošku OT: zrovna u jedné aplikace psané v Javě (konkrétně v JIŘE) bych export do xlsx nebo aspoň do CSV uvítal. Něco takového tam mají (CSV omezené na 1000 řádků), ale jen u seznamu issues, nikde jinde, což je takové ... dost nedomyšlené.

V Jave je na praci s Excelem nejpouzivanejsi asi Apache POI

https://www.codejava.net/coding/how-to-write-excel-files-in-java-using-apache-poi

Co se tyce Jira, mam dobre zkusenosti s jeho REST API, minimalne co se inventory modulu tyce, zatim jsem pri praci s Jira nikdy nemel potrebu exportovat fyzicky soubor. Zatim mi postacuje pro podobne ucely za sebou zretezit curl a jq s raw outputem.

ano znam (tedy znal jsem kdysi, jeste kdyz existoval jen binarni .doc a .xls, urcite to ted znacne vylepsili).

Ono jde o to, ze JIRu dneska pouziva spousta lidi na ruznych pozicich, takze me jako devel leadovi staci REST API + nejaky tooly nad tim, ale nekdy po me chteji i pekne grafy vytvorene ze slozitejsich dotazu. Samozrejme by to slo naskriptovat v Python+Matplotlibu, ale spreadsheet je na tyto jednorazove veci IMHO uzitecnejsi kvuli okamzite zpetne vazbe.

> Takze neco ve stylu Java Collections naplnene beanama, transformace bean dat z Hibernatu do excel friendly formatu pomoci stream api apod.

dost low-level pristup. Jednodussi rovnou pouzit knihovnu na praci s tabulkovymi daty, nebudete muset vynalezat kolo.

Osobně jsem před půlrokem udělala dobrou zkušenost s čínskou github.com/360En­tSecGroup-Skylar/excelize a protože to ovládání je úplně stejné, od koho že všichni forkovali? ;-)

26. 8. 2020, 14:09 editováno autorem komentáře

Autori tech rep se tim kupodivu nechlubi, tak holt zkusim historii gitu :)

Používáte to někde na produkci? Já teď budu dělat nějaké denní a týdenní reporty z celkem velkého množství dat (cca 220000 záznamů), tak jsem zvědavý, jak to ta knihovna zvládne.

My sme to nasadili do produkcie, ale s väčším množstvom riadkov to malo problém. Myslím, že už niekde medzi 10-20 tis nám to trvalo hodne dlho. Nakoniec sme tú jednu agendu prerobili na CSV.

Ale ak budete robiť testy na veľkých dátach, výsledok by ma zaujímal. Ten export som nerobil ja, takže neviem povedať, či to bol problém na úrovni knižnice, alebo inde ;-)

27. 8. 2020, 09:34 editováno autorem komentáře

Díky moc za info. Příští týden dokončím první verzi, tak se uvidí, jestli má tato cesta smysl nebo ne.

U CSV je největší bolest práce s datumy. I moderní spreadsheety se prostě ve sloupci s daty někdy (třeba u každé 20 buňky) rozhodnou, že toto datum není a vrazí tam nějaké desetinné číslo.

A popravdě je dost na pováženou, že rozumný přenositelný formát pro tabulky vznikl až tak pozdě. My to kdysi řešili formátem Lotusu - sice nikdo Lotus nepoužíval ani neznal, ale byl to formát načitatelný všemi Excely (od 2000 po moderní) i LO/OO.

CVS mi přijde jako formát vhodnější spíš pro relační databáze, kde metadata jsou striktně oddělená od vlastních dat.

V případě špatného importu datumů bych spíš tipoval na špatný formát vstupních dat - na desetiné číslo se to převede až tehdy, když se nepodaří konverze. Už tyhle konverze nedělám, nicméně v dobách, kdy jsme dostávali data v excelovských tabulkách, tak to bylo docela peklo. Některé datumové hodnoty byly vlastně text, atd. Jedním z prokletí této doby je, že firmy používají Excel místo databáze.

To je ještě děje, že nekdo používá Excel skutečně jako (doslova) "bázi dat"? Tak to je skutečně něco hodně špatně u jejich IT oddělení.

Trošku OT: kdysi jsem zažil, jak firma dodala SW, který nějakým způsobem z tlf. ústředen agregoval hovory, lokální, meziměstské, mezinárodní, do mobilní sítě atd. a potom jednotlivým oddělením dokázal posílat účty. To vše postaveno na bázi Excelu. Asi to i fungovalo pro menší organizace, ale potom to nasadili na univerzitu, kde počet hovorů za měsíc bez problémů přesáhl 65535 (nebo 65536?) a tehdejší Excel se sesypal.

Je to minimalne velmi oblibeny intermediate format v pripadech, ze byznys chce "poloautomatizaci", protoze je to levny zpusob, jak se vyporadat s ruznymi "corner cases", ktere nastavaji kvuli casto se menicim obchodnim podminkam, cenove a produktove politice a plneni individualnich prani. A udrzovat toto vsechno zcela automatizovane by znamenalo platit neustale programatory za upravy te automatizace.

(Ne, nejsem architektka, takze me neblamujte za spatny design. Nejsem ani ten byznys. Jenom vidim, co se kolem me deje.)

Jj taky jsem něco podobného zažil. Paradoxně to bylo u firem, které vůbec neměly problém s nasazením SAPu - takže peníze na IT byly. Potom se to ze SAPu exportovalo do Excelu, tam se udělaly sestavy a ty zase šly někam do dalšího drahého systému.

Za poslední rok jsem slyšel minimálně o dvou případech ze dvou různých českých korporátů. Jsou to interní systémy, interní databáze - něco, co si napíší lidi na koleně, a ono to funguje. Používá se to pár let, když to dost naroste, tak se nechá nacenit přepis do skutečné aplikace, a když jim vyjde několik set tisíc (za korporátní ceny), tak to nechají žít dál, dokud to Excel dává.

Slyšel jsem o českém providerovi internet telefonie, který několik let provozoval biling v Excelu - cca před 15 roky.

27. 8. 2020, 14:51 editováno autorem komentáře

Jj člověk někdy narazí na zajímavé věci, co přežívají všechno. V jedné nejmenované firmě pracující pro nejmenovaného národního železničního dopravce kvůli jedné takové "aplikaci" udržovali starobylý počítač s Windows 95 a Office 97, prototože ta appka byla napsána v nepřenositelných makrech (resp. se do toho nikomu nechtělo to portovat).

Narazil jsem kdysi na ještě zajímavější problém - firmy si mezi sebou posílaly CSVčka se stanoveným formátem, takže jedna firma vyexportovala, druhá naimportovala a vše ok. Ale někdy to naimportovat nešlo, takže jsem to zkoušel ručně a v tom CSV byly naplněné buňky, které měly být prázdné. No ... nakonec se zjistilo, že to někdo na straně první firmy otevřel v Excelu a ty buňky "smazal" tak, že prostě nastavil bílou barvu písma a tvrdil nám, že on to vidí v pohodě a chyba je na druhé straně (asi nějaký odborník na Excel).

mate nazor na sqlite format?

https://www.sqlite.org/appfileformat.html

pouziva to treba firefox

1. SQLite bohuzel nema typ pro datum a cas, takze neresi jeden z nejcastejsich problemu, jak uz bylo videt v predchozi diskusi.
2. SQLite browser je sice hezky nastroj pro me, ale zkuste nutit takovou vec nekomu jinemu pro "poloautomaticke" zpracovani, jak jsem ho popsala.

To uz mi prijde jako stastnejsi pouzit jako intermediate format ITU ASN.1, to ma UTCTime , GeneralizedTime .

(Ocekavam flamewar na tema "ASN.1 je neco tak priserneho, ze kvuli tomu lidi odesli od H.323 k SIPu" ;-) )

ASN.1 je v pohodě. Vždyť to Google znovuvynalezl jako Protobuf :)