Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Death Walker

Stran: 1 ... 13 14 [15] 16 17 ... 31
211
Priklady su priamo v repozitari https://github.com/jordansissel/xdotool/tree/master/examples k tomu staci shell.

Ak chces pouzit C tak su tam zdrojaky, ktore mozes pouzit ako priklady.

Ak chces nejaky iny jazyk tak staci do google hodit napr. "xdo examples nodejs", za nodejs si das jazyk ktory chces...

212
Server / Re:Zvětšení disku u Forpsi
« kdy: 28. 09. 2021, 08:42:05 »
Je stale mozne zvecsit to 4 particiu napr takto https://www.redhat.com/sysadmin/resize-lvm-simple ale aj ked je to jednoduche, tak by to mal robit niekto kto vie presne co robi.

213
Server / Re:Zvětšení disku u Forpsi
« kdy: 28. 09. 2021, 08:33:23 »
Riesenim by bolo to delegovat na specialistu uz pri vytvarani 3 partition, ten by 3 partition nevytvaral ale zvecsil 2 partition...

214
Podla dotazu je zrejme ze uz ma nieco v c++ co vola api widli a rad by to prtoval pre linux...

215
Alebo volaj kniznicu libxdo, tak ako ju vola xdotool...

216
Kamarát a toto je podľa teba chyba programátorov? S tým XML, JSON, fajn, beriem, ale to SQL a ORM nie. Boli doby, že existovala pozícia odborníka alebo aspoň niekoho kto má trochu poňatie o fungovaní databáz. Bejvavalo. Dnes je úplne každému jedno, že ty si senior C++ alebo Java programátor, proste úplne suverénne ti natrepú na hlavu aj prácu s databázou, inokedy aj frontend upraviť (však je to všetko programovanie nie?) potom písať dockerfily a kubernetes deploymenty a nikomu toto nepríde ani trochu čudné, že od jedného človeka sa očakáva expertíza v niekoľkých extrémne rozsiahlých oblastiach ktoré sa NEDAJÚ poctivo robiť všetky naraz resp. dokáže to zlomok ľudí zo všetkých. Tento obor sa mi tak neskutočne zhnusil, že nebyť tých peňazí, tak ma tam nedotiahne ani pod hrozbou smrti, fakt radšej zomrieť ako toto robiť, takže keď by chceli začať špekulovať o tom, že sú ľudia v IT preplácaný, tak ja okamžite končím, lebo aj kydanie hnoja je viac zaujímavé a človek sa zďaleka tak nezošrotuje ako v IT. A niečo mi hovorí, že nie som jediný čo už ma toho plné zuby.
Najdu sa. Skor ako programovanie konzultacie, atchitektura a podobne. I ked sem tam aj programuju, v dnesnej dobe zohnat niekoho kto to da s databazou, ktora ma nejako vypadat, je dost unreal. Hlavne ti odkojeny myslq to hrozne patlaju.

Potom su este fullstack developeri, ale ti su schopny celu aplikaciu spachat v jednon jazyku, zvedsa v php alebo v C# + nosql db, pretoze rdbms je pomala (co ale nie je chybou tej db) + dalsie veci co su aktualne cool a daju  sa k tomu pozliepat nejake scripty z stackoverflow...

A k tej db? Ked das dnesnym deckam hotovu db tak sa ti v tom hned zacnu vrtat lebo na to nevedia napasovat orm a spravidla to dojepikazia...

217
Kolki z dnesnych programatorov daju xml validovane proti scheme, alebo binarny protokol, kde tu istu definiciu zdielaju obe strany komunikacie.

Myslíš GraphQL? ;)
Nie, ja myslim xsd + wsdl... GraphQL pouziva xml schemu? Asi by som sa stavil ze bude generovana a v kvalite asi ako swager...

218
Můj aktuální problém jsou tupé chyby (copy/paste překlepy) v boilerplate kódu, to je obzvlášť hnusná a v ideálním světě zbytečná kategorie. ... boilerplate
Můžeš to rozvést?
Viz výše, jen doplním, že před bratru třiceti lety už tato technologie existovala (akorát se jí neříkalo mikroslužby) a technické řešení bylo mnohem příčetnější, než dnešní splácanec RPC, ORMu a RESTu. Koukám, že většina dnešních vývojářů tuhle část SW historie vůbec nezná a místo poměrně jednoduchého kola vymýšlí robotickou stonožku.
Kolki z dnesnych programatorov daju xml validovane proti scheme, alebo binarny protokol, kde tu istu definiciu zdielaju obe strany komunikacie. Dnes je v mode json, vygenerovany swagger a podla potreby dopatlany klient. A ORM? K comu sa ucit SQL, ked je v mode jednym prikazom zavolat z ORM 50 krat databazu, miesto jedneho volania rekurzivneho dotazu. Dnes staci aby "odbornik" vedel namiesat lepidlo ktore mu zlepi prevodovku z tatry s kosackou na travu tak aby to spolu nejako drzalo dokopy...

219
Vývoj / Re:Agregace velkého množství streamovaných dat
« kdy: 27. 09. 2021, 02:59:06 »
Osobne mam pocit, ze custom bastl prosazuje "stara skola", tj ti co si umi predstavit data a pametovy/souborovy format a vi jak efektivne napsat praci s daty.
to jsou ti co radi znovuvynalezaji kolo.
A tiez su tu ti, ktori sa snazia pouzit koleso z v3s na trojkolku, je jedno ci preto ze nemaju vhodne koleso alebo preto ze maju s kolesom z v3s takmer intimny vztah...

220
Tak já jsem zatím vždy Windows zmenšil na v podstatě minimum a tak daleko jsem nezašel. Připadne mě škoda to vymazat když mám na to licenci a nedostatkem místa rozhodně netrpím, spíš nedostatkem flešek jak jsem dneska zjistil.

Tak jasom pred tymi vela rokmi tiez nedostatkom miesta netrpel. Som mal v sasi 4 disky, celkovo 1.5 tera (cca 15 rokov dozadu).

Lenze nebudem v hangare nechavat trojkolku, ked na nej vobec nejazdim, hoci mam na nu licenciu a miesta habadej.

221
Studium a uplatnění / Re:Unicorn University - dojíždění
« kdy: 22. 09. 2021, 22:34:43 »
Nově založený účet "studenta" a hned naběhla odpovídat i nová čtenářka Rootu Karolína z Unicornu. Jsem tu jediný, komu to přijde jako svérázná propagace?

Technicky je mi fuk, co si myslíte nebo nemyslíte o té škole (já se mimochodem na základě diskuze tady rozhodl, že se jí pokusím spíše vyhnout), ale jestli mi pošlete svůj email, tak Vám rád zašlu odkaz na svůj profil na LinkedInu, abyste mohl sebe i ostatní zde ujistit, že z mé strany to není nějaký špatný marketing  ;D
Staci kliknut na ikonu obalky a poste mail, ikona komixovej bubliny sluzi pre sukromnu spravu. Tiez si inak myslim ze ide len o naivny pokus o reklamu :D

222
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 21:56:16 »
ten vami odkazovany clanek je z blogu timescale, srovnava pouze s influx, nesrovnavaji spotrebu mista na disku, metrika ve ktere timescale prohrava na cele care.

https://severalnines.com/database-blog/which-time-series-database-better-timescaledb-vs-influxdb chcete dalsie ale si vygooglite sam?

A ak si to neviete najst tak:
  • For workloads with very low cardinality (e.g., 100 devices), InfluxDB outperforms TimescaleDB.
  • As cardinality increases, InfluxDB insert performance drops off faster than on TimescaleDB.
  • For workloads with moderate to high cardinality (e.g., 100 devices sending 10 metrics), TimescaleDB outperforms InfluxDB.

Ad miesto na disku, timescaledb je OLAP pre postgres, podporuje transakcie, referencnu integritu a podobne. Influx je nosql, len tak volne pohodena halda dat.

223
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 21:45:17 »
Ale jako prvni pokus zkusim ten MapDB projekt.

nejhorsi mozna volba, kdyz uz chcete ukladat json, tak je efektivnejsi Mongo.

Ok, na ten se taky podivam.
Popravde me efektivita ukladani moc nezajima, chci do toho nacpat hodinu metric dat, pak to poslu do sveta, pak to cely smazu a dalsi hodinu dat.

Tak pozrite este na https://github.com/rrd4j/rrd4j

je to v jave, ak by nestacila pamat tak si ako backend mozete dat subor na disku, mongodb a funguje to ako klasicke rrdtool.

224
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 20:58:22 »
Ked uz tam mas niekde postgres tak ta asi bude zaujimat toto: https://www.timescale.com/

Robi to presne to co pozadujes. Naviac ti to poskytne efektivnejsie a bezpecnejsie ulozisko ako kafka...

timescale zrovna moc efektivni ve vyuziti mista na disku neni, ma spatnou kompresi, pokud nepotrebujete delat nejake fancy dotazy, tak bych se mu vyhnul.

a nemusi stihat zapis, 1 mld za hodinu je celkem dost dat.

tady jsou nejake benchmarky

https://altinity.com/blog/clickhouse-for-time-series

https://github.com/timescale/tsbs

rozdil celkem vyrazny 26GB timescale vs 0.5GB influx vs 1.2GB clickhouse

neverte vsetkemu co citate na internete... Podla tohoto vychadza Timescale proti Influx vyrazne lepsie: https://blog.timescale.com/blog/how-to-benchmark-iot-time-series-workloads-in-a-production-environment/

Co sa tyka velkosti. Postgres tam uklada aj data, nie len medzivysledky. Naviac by bolo zaujimave kolko by ostalo z tych 26gb po vacuum, pripadne pri zapnutom autovacuum.

Co sa tyka "fancy" dotazov, tak je fajn ze funkcie mozete pisat aj v R, pripadne v pythone a vyuzit numpy. Priklad: https://docs.timescale.com/timescaledb/latest/tutorials/time-series-forecast/#seasonal-arima-with-r


225
Vývoj / Re:Agregace velkeho mnzstvi stream dat
« kdy: 22. 09. 2021, 19:46:58 »
Jj, ze mas velky pocet dopredu neurcenych klucov, ktorych hodnoty chces agregovat... To by malo ist aj v timescale.

Alternativou by bola PipelineDB, ta bola tiez ako extension pre postgres, nieco ako rrdtool pre velke objemy dat. Neviem ako je to s nimi teraz, po tom co ich kupila confluent tak pre aktualny postgres asi nebude.

Stran: 1 ... 13 14 [15] 16 17 ... 31