Hoću da budem programerka

[djeneralche]

15 minutes ago, chandra said:

 

To vam resava probleme sa razlitiim OS-ovima i hardverima? Nesto kao simulator tako da razvijas kod i ne mislis o platformi na kojoj ce da trci? Jesam dobro razumeo?

 

Kod mene nema mnogo potrebe za tim - platforme su ili prakticno identicne ili toliko razlicite da zahtevaju fundamentalno drugaciji pristup (CPU/GPU).

Lightweight virtuelne masine na linuxu koje komuniciraju medjusobno. Generalno projekti se mogu podeliti tako da svaki tim bira svoje alate preko koji ce da realizuje svoj posao, zapakuje to u docker i to je to. Ovo naravno uvodi potrebe za devopsima, konfiguracije i ostalo. 

[shamotnapec]

3 hours ago, bags said:

Nadam se ipak da nece otici u tom pravcu. Callback hell kao iz JS mi bas nije potreban.

Recimo ovaj Spring Weblux sam probao pre neku godinu i nije bio nikakav benefit u perfomansama a citljivost koda je otisla u PM.

 

2 hours ago, djeneralche said:

Mi smo na projektu imali slucaj gde smo iskoristili WebFlux i to je bilo ok, ali to je 1% gde smo imali potrebu za tim.

 

Callback hell je zaista hell i ne želim ga nikom .

 

Sa druge strane, WebFlux je, što bi se reklo, acquired taste. Kada naučiš da razmišljaš na taj način, lepo napisan rekativni kod postaje veoma čitljiv, rekao bih čak i čitljiviji nego imperativni. Najveći problem sa WebFluxom je to što je ekosistem još uvek mlad i ne još ne postoji sve što be se očekivalo da postoji (npr full-fledged ORM framework), ali se brzo razvija, i cenim da će u dogledno vreme to doći na svoje mesto.

[bags]

Dzaba tebi bilo kakav non-blocking UI i servisa kad na bazi izblokira. hehe

 

 

[braca]

1 hour ago, chandra said:

 

To vam resava probleme sa razlitiim OS-ovima i hardverima? Nesto kao simulator tako da razvijas kod i ne mislis o platformi na kojoj ce da trci? Jesam dobro razumeo?

 

Kod mene nema mnogo potrebe za tim - platforme su ili prakticno identicne ili toliko razlicite da zahtevaju fundamentalno drugaciji pristup (CPU/GPU).

 

Otprilike. Dokerizacija i varijante su najnoviji trend u velikim kompanijama da uštede resurse tamo gde se može, sve gledano sa server strane. 

 

U početku beše praistorija : svaka aplikacija ima svoj server, na njega instaliraš sve što ti treba (bazu, web server, aplikaciju...) i teraš. Ako si malo ozbiljnija firma, treba ti ista konfiguracija za razvoj, pa onda jedna za testiranje... znači imaš 1000 aplikacija, treba ti... najmanje 3000 servera !  Onda to sve treba konfigurisati, nadgledati, za to treba još koja mašina... i dobiješ veliki data center koji troši mnogo struje, mnogo ljudi...  a dosta puta (da ne kažem u većini slučajeva) ti mašine zvrje na prazno, jer uvek postavljaš malo jaču konfiguraciju za svaki slučaj itd...   I naravno kad crkne nešto, nema aplikacije... (kao ppp juče).

 

Onda su izmislili klastere : isto ovo gore, samo x2, x3 itd, pa ako jedna mašina rikne, ostale nastavljaju posao.  

 

U medjuvremenu su smislili blade servere, isto sve kao ovo gore, samo potrpaš što više server kartica u jednu kutiju, štediš na prostoru i malo struje... 

 

E onda su se neke čike zamislile i izmislile virtualizaciju : umesto 1000 "malih" servera, hajde da napravimo jedan (ili više) veeeeliki(h), sa puno puno memorije, procesora i sve što treba, pa ga podelimo na virtuelne mašine koje rade posao isto kao ove gore, samo virutelno. Ušteda postoji, ali opet nije optimalna : svaki uzima svoj deo CPU, memorije, prostora na disku itd. Softver koje sve to pilotira obično sve to dodeljuje po potrebi, ali svaki virtuelni server treba dadiljati isto kao i one prave, instalirati OS, komponente, konfigurisati, nadgledati...  

 

I tako smo došli do dokerizacije, kubernetes i ostalih djakonija : nekoliko ogromnih servera (najmanje 3) na koje instaliraš sistem (Linux), Docker (ili  openshift ili nešto slično) i barataš sa "slikama" (image) : kad praviš aplikaciju, definišeš šta ti od resursa treba, na primer baza podataka MySQL, Apache, Java... docker ti svaku komponentu lepo spakuje u jedan image koji sadrži samo ono nepohodno za taj resurs (binarni kod, sve potrebne libraries i ostale fajlove), startuje instancu (koja troši samo onoliko memorije, CPU koliko joj stvarno treba) i tvoja aplikacija radi... ako treba nečega više (na primer više korisnika odjednom počne da koristi), softver dodaje šta treba u hodu, oduzima kad je manje opterećenje, balansira izmedju fizičkih servera da rasporedi opterećenje... ako aplikacija tj resurs ne radi iz bilo kog razloga, to se detektuje i izbacuje iz igre, ubacuje nova instanca... ako hardver zariba, ti to ni ne primetiš, sve se rasporedi u hodu na drugi koji radi...  kako potrebe/opterećenje raste, ti samo dodaješ nove fizičke servere, uključiš ih u kolo i teraš, neprimetno za korisnike, bez prekida...

 

To je otprilike (jako šematizovano) princip na kojem sad rade svi veliki Big Tech, Google, Amazon, FB, Twitter itd... 

 

[djeneralche]

8 minutes ago, bags said:

Dzaba tebi bilo kakav non-blocking UI i servisa kad na bazi izblokira. hehe

 

 

Mi smo ovo vrteli za proces koji je radio dosta obrade u memoriji a zatim upis/citanje na fajlsistem(neblokirajuca obrada slika).

[bags]

16 minutes ago, braca said:

To je otprilike (jako šematizovano) princip na kojem sad rade svi veliki Big Tech, Google, Amazon, FB, Twitter itd... 

 

Ujedno je ovo i najveci problem. Kad firme pocnu korisiti k8 a nemaju ni 200 servera. 

 

Mi smo na proslom poslu imali dobru ponudu za uvodjenje OpenShift-a (ogroman broj sati Red Hat TM-a), odradili pilot projekat i videli da nam donosi mongo vise problema nego korisiti.

 

[shamotnapec]

58 minutes ago, bags said:

Dzaba tebi bilo kakav non-blocking UI i servisa kad na bazi izblokira. hehe

 

 

Nisam rekao da ne postoji reaktivni interfejs ka bazi, već full-fledged ORM (tipa JPA/Hibernate). Reaktivni drajveri postoje za SQL (Microsoft, Postgres, MySql/MariaDB, Oracle) sa sve podrškom za transakcije, NoSQL (MongoDB, Redis, Cassandra, Elasticsearch).

Zapravo, sad sam pogledao, ORM ne postoji (još) na nivou Spring Data JPA, ali izgleda da je reaktivni Hibernate API u razvoju - http://hibernate.org/reactive doduše na Vert.x a ne na Reactor-u, ali s obzirom da postoje Vert.x ekstenzije za WebFlux, verovatno je već i upotrebljiv.

To je ono što sam rekao da se jako brzo razvija.

Edited September 17, 2021 by shamotnapec

[bags]

Nisam mislio da si nesto pogresno napisao.

 

Samo sam konstatovao da dzaba sav non-blocking na UI i servisima kad te doceka na bazi blocking. Nije bio ovaj R2DBC prije dve godine kad sam zadnji put gledao sta je moguce.

 

 

 

[אַף אֶחָד]

1 hour ago, braca said:

 

Otprilike. Dokerizacija i varijante su najnoviji trend u velikim kompanijama da uštede resurse tamo gde se može, sve gledano sa server strane.

 

Thanks, mislim da kapiram. U mom svetu imas masinu sa ~200k cpuo's i 14 petaflops, ali masina mora da se deli i uvek mora sve da bude dostupno svakom potencijalnom korisniku jer ne znas ko ce sta da pusti i gde (distribucija poslova odradjena kroz neki slurm, tako da isti procesor moze da dobije najrazlicitije zadatke). U ovom svetu koji ti opisujes deluje da su masine bile mnogo vise dedicated za odredjene poslove, pa je otuda nastajao problem optimizacije i sl.

[braca]

Ti verovanto nemaš osamsto petsto miliona korisnika kao Google, Instagram & co...  Raja mala, ali odabrana, pa koristi petaflopse za ozbiljne stvari, a ne za lolcats i napućene usne...

 

Ovo je smišljeno najviše zbog tog skaliranja, kreneš sa malo korisnika za malo para, pa ako te usere, nebo je granica, a ti dodaješ resurse po potrebi, ne moraš da seliš aplikacije na jači hardver... 

Edited September 17, 2021 by braca

[אַף אֶחָד]

10 minutes ago, braca said:

Ti verovanto nemaš osamsto petsto miliona korisnika kao Google, Instagram & co...  Raja mala, ali odabrana, pa koristi petaflopse za ozbiljne stvari, a ne za lolcats i napućene usne...

 

Ovo je smišljeno najviše zbog tog skaliranja, kreneš sa malo korisnika za malo para, pa ako te usere, nebo je granica, a ti dodaješ resurse po potrebi, ne moraš da seliš aplikacije na jači hardver... 

 

Da, da, razumem. Jeste druga vrsta aplikacija u pitanju i drugi nacin koriscenja. Dal program radi lolcats ili usne i nije toliko bitno, ali kod mene svi procesori rade prakticno identicnu stvar istovremeno, tako da svaki mora da ima jednak pristup svim potrebnim alatima i bibliotekama.

 

Za mnoge stvari koje ste ovde pominjali nisam nikad cuo. Kod nas je, eto, i dalje najveca dilema fortran ili c. Pisao sam ranije, cak ima i dalje neverovatan broj kodova koji su sustinski Fortran 77 umetnut u nekakvu paralelizaciju (OpenMP ili MPI). Jebiga, dinosaurusi. Samo cekamo da izumremo.

 

Hvala vam za ovu diskusiju. Svasta sam novo cuo. Moracu malo da se obrazujem u tom pravcu.

[laser lotus]

8 hours ago, shamotnapec said:

On 15.9.2021. at 16:27, bags said:

 

Mislim da se mnooogo precenjuje značaj Loom-a. Loom će (ako ispuni ono što je obećao) verovatno doneti revoluciju u slučajevima gde je konkurentnost prirodna, tipa omogućiće da aplikacioni serveri mogu da podrže mnogo više konkurentih korisnika. Van takvih use case-ova, ne verujem da će od njega biti mnogo koristi. Koliko često se dolazi u situaciju da je režijsko vreme thread context switch-a bottleneck? To što ću moći da podignem milion fibre-ova, ne znači da ću to i želeti (tj da ću želeti da managujem njihovu interakciju).

 

Po meni, budućnost (Jave) je u reaktivnom programiranju.

Hm, ne bih se baš složio. Što se tiče podrške za gomilu konkurentnih korisnika odavno si mogao da žongliraš sa recimo thread poolovima i NIO. Loom bi trebalo da ti omogući isto to ali bez žongliranja. Nažalost Loom neće riješiti sve probleme (backpressure recimo) ali bi trebalo da prorjedi situacije u kojima moraš da posegneš za stvarima koje znatno komplikuju kod.

 

Bar se ja nadam da ću u budućnosti manje vremena provoditi na javadocu za Flux

 

btw postoji li uopšte veća javadoc strana od ove https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html

[bags]

Ja sam imao prosle godine prvi kontakt sa Fortranom. Namestao kolegi HYSPLIT  https://www.ready.noaa.gov/HYSPLIT.php i pokusavao naci neki bridge za .NET i Fortran.

Tada sam video kako moze Fortran moze biti performantan uz veoma citljiv kod.

 

 

[bags]

8 minutes ago, laser lotus said:

btw postoji li uopšte veća javadoc strana od ove https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html

 

 

Sta je bilo sa onim Quasarom uopste. Firma iza njega (paralleluniverse) je dosta obecavala ai izgleda da su propali.

[Singer]

Nisam dugo zalazio u ovu temu pa ako ne zamerate samo da pitam - postade li Mau programerka?