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 - szdcf1sd561cas5c

Stran: [1] 2
1
Vývoj / Tip na novy projekt...
« kdy: 09. 02. 2020, 16:58:51 »
Mam momentalne volno a rad by som sa pustil do nejakeho noveho komercneho projektu. Mate nejaku inspiraciu ze co by stalo za to skusit poriesit?

Nechcem sa vsak pustat do SaaS ani nic centralizovane(komplexna infrastruktura) co stoji na vysokom pocte uzivatelov. Skor ma laka nieco co zakaznik moze hostovat u seba, pripadne nejaky centralizovany projekt s mensim poctom platiacich zakaznikov ktoreho existencia nestoji na tom ze vyzaduje obrovsky balik na reklamu a na ziskani velkeho poctu uzivatelov.
Taktiez sa nechcem pustat to nejakeho obrovseko projektu ktory je na viac nez rok prace, skor nieco specializovanejsie co sa da zbuchat do pol roka.

2
Vývoj / Návrh služby s AOL zápisem
« kdy: 01. 12. 2019, 10:24:08 »
Mam sluzbu "writer" ktora loguje spravy z roznych producentov. Kazdy producent ma sekvencne uint64 id pre svoje spravy. Ked sprava dorazi do tejto logovacej sluzby tak sa musi skontrolovat ze dana sekvencia pre daneho producenta uz nebola zapisana a je konsekutivna voci uz zapsianymi spravam, nasledne sa sprava zapise a prideli sa jej globalne sekvencne id.

Cize v praxi by to vyzeralo ako:
1:foo:1
2:foo:2
3:baz:1
4:bar:1
5:foo:3
6:bar:2
7:baz:2
8:bar:3

Aktualne to zapisujem do kdvdb, avsak do budnca sa obavam toho ze ta db, ako jeden subor, bude prilis velka. Je to b+tree a vyuziva mmap ale i tak nechcem skoncit s TB/PB suborom.

Preto by som chcel prejst na "manualne" logovanie do AOL suborov ktore by rotovali ked dosiahnu urcitu velkost. Tym znizim riziko poskodenia jedneho velkeho suboru a zalohovanie sa tak taktiez znacne ulahci.

Teraz ide o to ze tato sluzba je len na zapis sprav, avsak spravy sa budu aj citat(vo vysokom objeme) a na to su ine sluzby ktore sluzia prave na tento ucel(princip CQRS). Takze z tejto zapisovacej sluzby musim aj vediet citat spravy a synchronizovat ich do "readerov" aby ich mohli servirovat klientom.

"Reader" si len uchovava id globalnej sekvencie ktoru naposledy prijal takze z "masteru" si stiahne iba nove spravy. Cize ked budem pouzivat novy system zapisu do tychto mensich suborov tak musim aj vediet otvorit subor ktory obsahuje spravy ktore reader este nezosynchronizoval.

Cize "master" si musi sledovat lokalne sekvencie pre kazdeho producenta aby zapisoval iba nove spravy a ignoroval opakovane spravy a taktiez aby nepreskocil nejaku spravu(tzn. 1,2,3,6) a taktiez musi uchovavat globalnu sekvenciu.

Realne ide o malo dat, prakticky iba:
8 bytov pre uint64 globalnej sekvencie a mapa [string]uint64 pre sledovanie "lokalnych" sekvencii pre jednotlivych producentov.

Teraz ide o to, kde a ako uchovavat tieto indexy a ako sa dostat ku spravam ktore "reader" este nesynchronizoval.
Napada ze by som mohol pouzivat kvdb kde by som si uchovaval vyssie spomenute + byte index a nazov suboru pre kazdu spravu, podla coho viem potom pre readera otvorit konkretny subor a naseekovat na konkretny bajt so spravami ktore este nema a poslat mu ich. Problem tohto riesenia je ze mi takto vznikaju dve oddelene transakcie. Jedna je zapis samotnych sprav do suborov, druha je ukladanie tychto indexov. Ak by sa stalo ze jedna operacia neprejde, tak mi vznikne inkonzistentny stav.

Dalsia varianta je len zapisovat na koniec aktivneho suboru metadata(globalny index + lokalne sekvencie) a drzat ich v pameti pre rychle vyhodnotenie. Problem je ze nemozem uchovavat pointery pre jednotlive spravy nakolko by slo o privela dat pre taketo uchovanie v aktivnom subore a musel by som vediet ktory subor otvorit pre synchronizovanie readerov podla globalnej sekvencie, cize nazvy suborov by museli byt presne rozsahy sprav(napr 0-5000.dat, 5001-10000.dat, ..) a uz nie podla velkosti dat samotnych co by sposobilo inkonzistentne velkosti tychto suborov. Avsak ak viem podla sekvencie identifikovat subor tak potom ho len preskenovat a najst prvu spravu na sycnhrzonizovanie nie je az tak narocne.

Takze by ma zaujimalo ako by ste navrhli riesenie pre takuto situaciu?

3
Software / Re:Sledování statistik jednotlivých procesů
« kdy: 20. 11. 2019, 12:39:30 »
nagios?

pripadne si mozes napisat nejaky jednoduchy program ktory si spusti nejaky top v pravidlenych intervaloch, naparsuje ho a zapise data do nejakej sqlite alebo kvdb pre jednoduchost.

4
Vývoj / Re:Protokoly pro živý video stream
« kdy: 13. 11. 2019, 22:18:53 »
h264 je kodek, nie protokol.
anyhow, z "vyzkumu" to zatial vyzera ze na upload stale bezi rtmp s tym ze webrtc uz je podporovany v roznych programoch na streamovanie. na download bud hls alebo dash s tym ze dash je open source a standardizovany, a taktiez nezavysli na kodeku.

5
Vývoj / Protokoly pro živý video stream
« kdy: 13. 11. 2019, 21:24:42 »
Hladam informacie o tom, aky protokol sa dnes najbeznejsie pouziva na zivy webovy prenos(youtube, dlive, twitch, fb, twitter...). Konkretne ma zaujima protokol na upload(tzn od producenta na sluzbu, napr z OBS, Xsplit, ...) a download(tzn. zo sluzby do klientskych web prehliadacov). Nasiel som dost protokolov a "technik" ale nic co by jasne hovorilo ze prootkol XY je dnes najpouzivanejsi a pouzivaju ho sluzby x, y, z.

6
/dev/null / Linux na upadku?
« kdy: 09. 11. 2019, 11:42:00 »
Kto ma cas sledovat tak vie co sa "deje" vo svete...no nevedel som ze samotny Linux bol uz infiltrovany do takej hlbky a ze je na tom tak zle...

https://www.youtube.com/watch?v=wIa1ItmVz40

Minuta 3:30 ma tiez znacne prekvapila - vsetky financne prispevky pre Linux Foundation idu uplne inam nez maju ist.

7
Vývoj / Re:UX - aktualizacia json dokumentu
« kdy: 05. 11. 2019, 16:02:00 »
Preberal som to na slacku a v konecnom dosledku to bude najlepsie nechat ako je - tzn. na aktualizaciu dokumentu sa skrata posle cely dokument. Nejde o velky dokument takze az taky problem to nie je ako by to bolo v pripade par megoveho, pripadne vecsieho dokumentu.

8
Vývoj / UX - aktualizacia json dokumentu
« kdy: 05. 11. 2019, 14:09:28 »
Mam api server kam klienti posielaju json dokument. Aktualne sa tento dokument moze aktualizovat iba ked sa posle ako celok. Ja chcem implementovat jednoduche patchovanie aby klient nemusel tahat najprv cely dokument ku sebe, spravit zmeny a znova ho cely poslat na server.

Otazka je ake api je dobre pre takyto ucel. Mozem mat moznost poslat json dokument ktory obsahuje iba zmeny a na servery sa spravi merge. Pripadne mozem pouzit json patch ktory je standardizovany. Pripadne pouzivam kniznicu ktora pouziva zapis "foo.bar.0.baz" ak ide o pole, pripadne "foo.bar.:25.baz" ak ide o objekty resp "foo.bar-1.baz" ak ide o pridanie polozky do pola. je to velmi jednoduche avsak nie je to ziaden znamy standard. Takze neviem ze co je pre uzivatelov dobra metoda - nadiktovat syntax ktora vyhovuje mne, alebo pouzit json patch ktory som moc vo svete nevidel, cely dokment...alebo co skratka? Neviem popravde ze co sa dnes na toto pouziva kedze som sa s tym nikdy nestretol(nerobim s nosql) a nemam prehlad + neviem co preferuju uzivatelia skratka.

9
Studium a uplatnění / Re:Dohoda o pracovní činnosti a daně
« kdy: 26. 10. 2019, 00:10:38 »
popravde neviem ako je to s dohodarmi(ale myslim ze dohodari uz musia riesit aj socialku), ale pri zivnostnikoch/firmach sa PRED dodanim sluzieb/tovaru do kajin EU musi dana entita stat identifikovanou osobou pre dph a na faktury davat dph(ak uz nie je doma platca dph), pokial protistrana nie je platca dph kedy sa da fakutrovat bez. anyhow, treba vsak robit pravidelne vypisy na danovy zo vsetkych cehrnaicnych faktur + registracia do moss na platenie dani pre dodavatelov do ich krajin, ak to clovek nechce riesit priamou registraciou v danej krajine. z hladiska byrokracie je najlepsie robit biznis doma + mimo EU alebo v eu elke na cierno ak nejde o nejaky seriozny biznis :)

10
Desktop / Re:Po aktualizaci Ubuntu mi přestal fungovat háček
« kdy: 24. 10. 2019, 00:49:12 »
paradoxne mi toto robil windows 10 isty cas, potom sa to nejak samo vyriesilo(najskor aktualizacia), lebo som neprisiel na riesenie. sranda.

11
Hardware / Rada: bare metal s dobrou cenou a spolahlivostou?
« kdy: 13. 10. 2019, 14:51:25 »
Pozeram po nejakych bare metal serveroch na prenajom. Cena je priorita ale aj celkova hodnota(priepustnost a limit siete, disky, ...) a spolahlivost zeleza ale aj datacentra. Okrem Hetzneru a OVH sa oplati pozriet aj nieco ine? Viem ze Hetzner nemal uplne dobru povest v minulosti ale myslim ze to je uz je pasé. OVH je skor zname v nizkonakladovych VPS ale ceny serverov nema uplne zle, i ked znacne drahsie nez porovnatelne u Hetznera.

12
inak nebude pre teba lepsie pouzit skor etcd+confd namiesto ansiblu?

13
s ansible uz par rokov nerobim, takze bohuzial ti neporadim. ale tie nervy s LE poznam a preto som presiel na CloudFlare kde mas 10 rocny wildcart certifikat zdarma nemusis riesit tieto LE hovadiny s certifikatmi ktorych zivotnost je naprosto smiesna.

14
Studium a uplatnění / Re:Práce v zahraničí - vyplatí se?
« kdy: 16. 08. 2019, 18:19:28 »
Ziju v Irsku, plat 170 000 eur brutto po dvoulete praxi fulltime po skole


15
Studium a uplatnění / Re:Zkusenost s estonskym e-residency
« kdy: 07. 08. 2019, 08:51:01 »
Jedina vyhoda Estonskej srocky je v tom ze sa dan z prijmu neplati na konci zdanovacieho obdobia, tak ako je tomu v nasich koncinach, ale az pri vyplacani podielu. Prakticky ide o to ze ak chce clovek nechat peniaze vo firme a "preinvestovat" ich tak nemusi statu ihned platit dan kazdy rok. Toto je idealne pre startupy kde sa kazda koruna pocita.

Co sa uctovnictva tyka, asi najpopularnejsia sluzba na zalozenie a spravu bola Leapin, vyzera ze teraz sa volaju XOLO.

Ak ti ide o danovu optimalizaciu tak by som skor pozeral po zalozeni v Gibraltare.  Po tom co spravili na Cypre banky par rokov dozadu uz sa im neda verit. GBR zatial ano.

A pametam si tak 2-3 rokoy dozadu ked som cital blogy o zakladani v Estonsku a viem ze si ludia stazovali na Banky ktore stale na to neboli pripravene, takze neboli dostupne tlaciva v anglickom jazyku, alebo tlaciva nepocitali s adresou mimo Estonska, a taktiez nemoznost vybavit veci na jednu navstevu. Takze v konencom dosledku to cele absolutne nemalo ziaden zmysel.

Stran: [1] 2