[ Zlatni_bg @ 03.05.2018. 18:57 ] @
Pozdrav,

Vec dugi niz godina se bavim profesionalnom izradom PHP aplikacija. Pored IT diplome, samouk sam i imam 10 godina iskustva u radu u istom. Imam 26 godina. Nemojte da vas uvod zavara, nece se tema pretvoriti u "sta sad" i slicno, samo sam hteo da objasnim svoju situaciju. Imam gomilu enterprajz resenja iza sebe i odradjeno bukvalno sve sto je moglo da se odradi u istom.

E sad, na stranu sve ostalo cime se bavim u ITu, u ovoj temi bih se fokusirao na PHP i samo PHP.

Interesuje me, posle 10 godina, kako treba da izgleda rad PHP programera, i kako on (i dalje radim freelance, planiram u narednih par meseci da se bacim u "drustveno" okruzenje u nekoj firmi) treba da radi razvoj svojih aplikacija.

Dakle ovako:

1. Nacin razvijanja aplikacija. Vidim da se tu dosta razlikuju pristupi. Ja naprimer imam svoj development server, na svom racunaru koristim Notepad++, ponekad PHPStorm koji mi nije preko potreban (al' ajde, bio je nahvaljen silno pa sam resio da ga isprobam i dam sansu), kacim se preko SFTP i SSH na devserver gde radim sav editing, to sve commitujem na git i guram na privatni github repo.

2. Kontejneri, tipa Doker. Dosta ljudi koje upoznam me pitaju da li ih koristim. Nikad nisam osetio potrebu za istim niti ih koristio, ideja mi je da sve aplikacije svedem na nivo da rade na minimalnom broju potrebnih resursa servera, ukoliko imam potrebu za daemonom ili necim slicnim, isti odradim u C++ ili Pythonu. Uz svako parce softvera koje prodam dam potpunu dokumentaciju i source naravno, i instalacionu skriptu. Uz to, pruzam i tehnicku podrsku i odrzavanje na dogovorenom vremenskom periodu, po potrebi i obucavanje za rad.

3. Framework-si i slicno. Licno imam svoj razvijen framework, razvijan godinama, za licne potrebe pravljenja aplikacija, iz kog koristim potrebne funkcije/klase/itd umesto laravela i slicno. Radio sam u Symfony-ju i slicno, ali mi je uvek brze bilo da radim u svom fw-u, s obzirom da ipak sam razvijam aplikacije.

4. Placam dizajnera da mi odradi izgled kompletne aplikacije da ne gubim vreme za to, posle sam peglam frontend po potrebi. Imam odlicno poznavanje HTMLa, BSa, JScripta, AJAXa... pa mi nije problem. Perfekcionista sam i volim i frontend da "zavrsim" do kraja sam.

Interesuje me da li pravim greske posle svih ovih 10 godina takvog pristupa i da li bi me neko od iskusnijih kolega ispravio u svom razmisljanju. Da li treba da radim sve na devserveru, da li gresim sto ne koristim Docker i sl, da li gresim sto jos uvek nisam poceo da koristim frejmvrke poput laravela i sl, i da li bih potpuno trebalo da odvojim svoj postao back-enda od front-enda, da pruzim potpunu kontrolu preko AJAXa nekom drugom da zavrsi taj deo.

Hvala vam, i otvoren sam za sve kritike, savete, vredjanja i sve ostalo jer ne vidim kako bi negativno to moglo da utice na mene, s obzirom da zelim samo da popravim svoj "best practices".
[ anon334571 @ 03.05.2018. 19:20 ] @
Ja imam samostalnog iskustva ali ne i radnog. Nekako me poslovi obilaze, a po nekad obilazim i ja njih. Solidno znam php i sve oko web i uvek nešto zafali. Freelance je zahtevan posao ako sve imaš zelju da sam radis, uvek je bolje u društvu, da imaš nekog ko ti šeruje poslove, da poslove ti šeruješ niže itd. A ako neko misli da može sve da postigne od menadzmenta do pisanja koda, onda je u gadnom problemu. Ja sam mozda kasno shvatio, ali ipak sam shvatio, da mora postojati podela rada :)
[ Zlatni_bg @ 03.05.2018. 20:17 ] @
Nemoj da se ljutis, ali to bas nema veze s mojim pitanjem :) Sa 10 godina radnog iskustva sa freelancingom i zivotom od toga, nemam bas problem da posao bezi od mene, ima ga na pretek :)

Ono o cemu sam pisao su propusti i greske u mom radu a ne to kakav je freelancing.
[ nkrgovic @ 03.05.2018. 20:33 ] @
- Kako bildas assets za front end? Kako bildas za back end? (Uvlacenje paketa i sl). Tvoj pristup je OK za jedan server, ali da treba da se to deploy-uje na 10+ masina, razmisli kako bi se to radilo... :) Treba da razmislis o nekom bild serveru tipa jenkins. Nije obavezno, ne treba ti, sve stoji, pitao si kako ide enterprise, pa ti zato spominjem.

- Kako radis testove? Imas li unit testove? Integration? Mock pozive? Realno, bilo kako automatsko testiranje? Razmisli i o tome.

- Kako resavas sve ono za sta koriste framework: Sanitizacija inputa? Tear-down konekcija? De-alokacija memorije?

- Kako skaliras? Da li ti je app stateless? Gde drzis state (session makar)? Sta bi radio da treba da primis 50,000 requestova sa rate-om od recimo 1000 u sekundi?

- Kako kesiras? Kako radis invalidaciju kesa?

- Kako hendlas eksterne servise? Dokument storage? Full text search?

Ovo su stvari koje ja kao sysadmin vidim na prvu loptu.
[ Nemanja Avramović @ 03.05.2018. 20:52 ] @
Praviš greške, ali ko radi taj i greši, tako da nije strašno

1) Prouči termine continuous integration, continuous delivery i continuous deployment. Sva tri su slični ali ima razlike, koje u ovom stadijumu nisu toilko ni bitne. U principu sve se svodi na to da ti odradiš git push na remote repository, to okine webhook koji kontaktira CI server koji dovuče kod koji si komitovao, pusti testove i ako prođu javi ti, a može i da odradi odradi deploy na (dev ili prod) server. Kad sam ih već pomenuo - piši testove! Ovo je često jako dosadan posao ali kod velikih sistema jedna mala izmena može da poremeti funkcionisanje ko-zna-kog dela aplikacije i zato je lepo imati automatizovane testove koji isproveravaju sve pre deploy-a. Hint: phpunit

2) Nisam koristio kontejnere osim nešto malo igranja sa njima tako da ne mogu da komentarišem opširnije. Sakako fin i zanimljiv način distribucije aplikacija / deljenja resursa servera.

3) Framework-e treba koristiti, ono bar da vidiš kako neke stvari treba odraditi. Pritom mislim na Laravel, Symfony i Zend, ostali nisu vredni pomena Doduše Symfony je malo specifičan framework, više je skup korisnih paketa nego framework, odnosno mnogo toga ti ostavlja da ti sam organizuješ, što može biti i dobro i loše mada, ako ikad budeš radio na zaista ozbiljnim aplikacijama, teško da ćeš moći sam da postigneš sve, a ako radiš u timu bolje je koristiti nešto što svi u timu već poznaju nego da gubiš vreme da im objašnjavaš kako tvoj custom framework radi

Takođe, ne znam da li koristiš composer, ali trebalo bi - composer ti otvara prostor da koristiš ~200.000 gotovih paketa za PHP koji mogu zajedno da se koriste na istom projektu bez da smetaju jedan drugom. Pored toga ti omogućava autoloading klasa, upravljanje "zavisnostima" (dependency management, tj svaki paket koji koristiš može da zahteva neki drugi dabude instaliran i composer će sam instalirati sve koji su potrebni) i može znatno da ti smanji količinu koda u git repository-ju (zato što se biblioteke sa composera ne čuvaju u git repository-ju već se pri deploy-u dovlače sa njihovih repository-ja)

4) To je skroz ok ako se više fokusiraš na backend nego na frontend; tako i ja uglavnom radim
[ svepomalo @ 03.05.2018. 22:04 ] @
Citat:
nkrgovic: Sta bi radio da treba da primis 50,000 requestova sa rate-om od recimo 1000 u sekundi?

Jel mozes da objasnis? Zar nije bitan samo broj requestova u sekundi? Ovih 50K ce mu dodje za 50 sekundi?
[ nkrgovic @ 03.05.2018. 22:10 ] @
Citat:
svepomalo: Jel mozes da objasnis? Zar nije bitan samo broj requestova u sekundi? Ovih 50K ce mu dodje za 50 sekundi?

Bitno je i koliko ti traje jedan request ;) . A sustina je bila samo da ih ima toliko da nije u pitanju prosto burst nego da to traje ajde, bar minut.... Znaci nije isto 1000/s za 3s, ili za minut - to je sve. Ako imas 3000 ukupno, to moze da malo saceka, ako imas 50,000 onda moras da ih resavas osetno brze - jer ce ti se prepuniti svi queue-ovi i onda vec moras da skaliras, horizontalno - nadam se.
[ nkrgovic @ 03.05.2018. 22:13 ] @
Citat:
Nemanja Avramović:
Praviš greške, ali ko radi taj i greši, tako da nije strašno :)

1) Prouči termine continuous integration, continuous delivery i continuous deployment. Sva tri su slični ali ima razlike, koje u ovom stadijumu nisu toilko ni bitne. U principu sve se svodi na to da ti odradiš git push na remote repository, to okine webhook koji kontaktira CI server koji dovuče kod koji si komitovao, pusti testove i ako prođu javi ti, a može i da odradi odradi deploy na (dev ili prod) server. Kad sam ih već pomenuo - piši testove! Ovo je često jako dosadan posao ali kod velikih sistema jedna mala izmena može da poremeti funkcionisanje ko-zna-kog dela aplikacije i zato je lepo imati automatizovane testove koji isproveravaju sve pre deploy-a. Hint: phpunit

Ali samo kao POCETAK.

https://twitter.com/thepracticaldev/status/687672086152753152

Samo unit testovi nisu dovoljni!

Takodje, ali najlepse molim hvala lepo, moze push da odradi deploy na dev, ali ne moze na prod. Ali stvarno ne moze. Ne bez da ziv covek negde ne pritisne neko dugme.
[ Nemanja Avramović @ 03.05.2018. 22:24 ] @
Naravno da može, ali push (merge) na production branch, ne na onaj na kom radiš development ja godinama tako radim i nikad nisam imao problema. Uostalom taj merge mu dođe taj pritisak na dugme koji pominješ

Za testove se slažem u potpunosti
[ dakipro @ 03.05.2018. 23:07 ] @
Sve ovo sto su nkrgovic i Nemanja rekli je ono sto bi posle 10 godina bila tema za razmisljanje. Posle toga sledeci korak mozda neki novi jezik. Ako nista drugo, sto kaze Nemanja da vidis kako to drugi rade. Ja sam sad tu negde, posle uf... oko 12 god placanja racuna od php-a (majko mila vreme leti...) sad se u slobodno vreme bavim nekim elektronikama i arduino i cuda. I onda su tu C, python, pa neki Lua skript, na poslu nema ko pa mora i Java, Angular u TypeScriptu, pa neki hibrid cega vec, pa tek onda vidi covek da ne zna bas ni php-a da pise valjano.

Automatski testovi su nesto sto je meni bila ogromna prekretnica posle dosta godina F5-pisanja, pa ako se opredelis za samo jednu stvar da unapredis svoje vestine, po mom misljenju kreni sa testovima. Tu ces i sam videti koliko "gresis" odnosno koliko ima potencijala za poboljsanje dizajna koda i SingleResponsibility principa (gde najvise nas gresi u programiranje).

Drugo je framework, ja sam kao i ti koristio svoj framework dugi niz godina i bio uvek ultra efikasan sa njim, ali je ogromna prednost kad je nesto mnogo bolje testirano a cesto je i sam kod/arhitektura mnogo kvalitetnija jer obicno barem 2+ ljudi ucestvuje u razvoju i diskusiji i doprinosi nekom resenju. Plus sto mozes da zaposlis/zamolis nekog za pomoc kad ne mozes da stignes ili ne zelis vise da se bavis nekom fizikalijom. Makar i sa elance.com (ili koji su vec sad sajtovi aktuelni)
To isto moze bude neki sledeci korak, da zaposlis omladinu da ti odradi neki skript/modul/funkcionalnost pa i projekat, a ti da se bavis produktivnijim taskovima i tu naplacujes malo vise svoje iskustvo. Posto vec imas dovoljno posla, to bi po meni bio jedan od narednih koraka, ako ti se naravno svidja ta zamisao. Ne da zaposlis nekog ono u fullu da sedi kod tebe u kancelariji, ali po projektu/ugovoru. Posto vec imas naviku da dokumentujes projekte, onda ti ovo ne bi bilo previse tesko.

Mogu da ti savetujem da probas recimo Laravel i vidi dal ti odgovara (ne odgovara svakom), ali ti ovaj kurs toplo savetujem ako stvarno hoces da podignes kvalitet koda https://course.testdrivenlaravel.com/ - iako obradjuje Laravel, principi mogu da se primenjuju na ostale frameworke pa i na obican php (cak i ostale jezike). Lik ovde pise konkretnu aplikaciju za booking sistem, od planiranja do realizacije, uz detaljno objasnjen refaktoring zasto su neki patterni prakticniji u datoj situaciji. Prvi put da sam naisao na Test Driven Development video/kurs a da mi nije bio dosadan i nelogican, sta vise sad se blago iritiram kad moram da testiram na F5.
Pogledaj i neke podcaste (autora) Adam Wathan-a, recimo Chasing Perfect https://www.youtube.com/watch?v=5DVDewOReoY
Po meni odlicno i na veoma uproscen nacin opisuje kako da se uprostiti dizajn i kod, sto u vecini situacija dovodi do lakse odrzivog i kvalitetnijeg koda.
Isto pogledaj mozda FullStackRadio podcaste ako nadjes neku temu koja te zanima, recimo korisna diskusija na temu refactoringa http://www.fullstackradio.com/78

Pa jos malo pa penzija...
[ jablan @ 03.05.2018. 23:27 ] @
Ako već radiš sam svoj FW i koristiš ga na više projekata, plati nekom da ti uradi profi security audit. Plus naravno potpisujem sve što nkrgovic piše.
[ Deunan @ 04.05.2018. 12:24 ] @

Pricalo se dugo da ne treba mesati HTML i JavaScript, pa se pojavi reactjs i napravi revoluciju. Ponovo sam zavoleo front end. Hocu da kazem, tesko da neko moze da ti kaze da je nesto pogresno, mozda samo da uskladis neke protokole dok se ne pojave bolji...

Par mojih saveta:

1. Ako bih radio samo php, verovatno bih mogao da prodjem sa nekim wamp-om, xamp-om, easyphp... Ali neke stvari (recimo pisanje modula za ejabberd) bez Vagrant-a bi mi prakticno bilo nemoguce. Valjalo bi da poznajes linux server (centos, ubuntu...). Da znas da instaliras php, mysql, nginx, varnish, redis, load balancer... pa ces bez problema koristiti vagrant i docker.

2. Pisanje koda mozes u cemu hoces (prouci malo S.O.L.I.D. principe). Smatram da je phpStorm daleko najbolji, al' nisam isprobao sve sto postoji tako da... Git je verovatno obavezan za sve firme sad.

3. Ja sam za obavezno koriscenje framework-a. Samim tim i composer je obavezan. Jednostavno, ne vidim kako mozes da napises i istestiras neke komponente bolje od necega na cemu radi gomila ljudi (svi smo mi imali svoje framework-e). A i lako mozes svoj kod da spakujes u pakete i ponovo koristis po potrebi.
https://laracasts.com/series/laravel-from-scratch-2017

4. Ako hoces da radis front-end, mislim da su node.js i webpack trenutno standard (reactjs polako osvaja ceo front-end, nemoj da ga zaobidjes) Nikad se ne zna, mozes lako da se prebacis

5. Ako radis za android, molim te predji na Kotlin. (znam da si pitao samo za php, ali ako povremeno radis i javu... pa ako se sretnemo, a ne znas Kotlin :)

6. Mozda najveci savet: pokusaj da ne zaostajes za novim tehnologijama. Previse je programera koje je vreme "pregazilo" zato sto zele da ostanu u sigurnim vodama. A nisu ni svesni toga. Nemoj se plasiti da nesto novo naucis samo zato sto dobro baratas starim alatom.


Nemoj da panicis ako ne znas nesto sto traze u firmi. Niko ne moze sve da poznaje, a i vecina ovih alata se nauci za par dana. Eh, kol'ko ja stvari ne znam...


[ gost12 @ 04.05.2018. 20:25 ] @
Čim čujem koristim svoj vlastiti framework odmah mi to jako smrdi :) Potpisujem većinu stvari što su drugi naveli od unit testinga do CI-a. Stavio bih veliki naglasak na SOLID, posebno na DI.
Dodao bih da se iz tvojeg posta vidi da su to većinom bili manji projekti, koje si odradio i nisi morao nešto previše održavati, sve ovo je ok, ako su projekti jednostavni i nema održavanja. Ipak kad se radi enterprise projekt, onda tvoj vlastiti framework ne dolazi u obzir, isto kao niti notepad++, već to u 90% slučajeva bude onda PHPStorm, eventualno neki drugi IDE tipa netbeans... Ali bez pravog IDE-a sigurno nećeš razvijati enterprise projekt. Najviše o pristupu projektu ovisi kolika je trajnost razvijanja projekta, dali je to mjesec dana (onda ti ne treba ništa), godinu dana, 10+ godina. Još jedna stvar koju PHP devovi mrze. Tipiziraj sve što možeš. Obavezno minimalno PHP7.1 i svaka funkcija mora imati return type i svi parametri moraju imati jasno definirati tip podataka, bilo kakve multidimenzionalne arraye zaobiđi u širokom luku i jasno definiraj objekt koji ti funkcija vraća sa svime tipiziranime.
Isto tako vidim da drugi nisu spomenuli obavezno pogledaj code sniffer, mess detector, PHPStan i postaviš da CI build faila ako nešto od toga faila.
O tome da se treba koristiti composer neću ni pričati, to smatram očitim danas :)

Nažalost 90+% PHP devova su na jako niskoj razini, zbog se svi i sprdaju s PHP-om, ali isto tako je žalosno da PHP u 2018 još uvijek nema genericse, ali PHP7, pogotovo 7.1 daje nadu da PHP ide u jako dobrom smjeru.
[ Zlatni_bg @ 17.05.2018. 04:33 ] @
Momci, izvinjavam se na kasnom odgovoru, porodicne obaveze zadnjih 15 dana me udavise. Pred spavanje pustim EON i utonem u san, u toku dana zavrsim nesto malo posla sto treba.

Zelim samo da vam kazem da sam sve komentare procitao, maksimalno razumeo, izguglao sve sto nisam u pocetku, procitao literaturu, da znam sve o cemu mi pricate, i to isti dan kad ste postove i pisali.

Izvinio bih se svima koji misle da sam izignorisao postove - daleko od toga, to nikad ne radim. Jednostavno mi je za neke stvari stala knedla u grlu kada sam citao i shvatio gde jos imam rupe u znanju. Smatrao sam da je potrebno da se edukujem o svemu sto ste spomenuli da bih nastavio ovu konverzaciju.

Nisam na forumu ovoliko dugo da bih glumio nekog "doktora PHPa" vec smatram da biste mi pomogli na najbolji nacin, moram da budem skroz iskren sa vama, i zahvalan sam vam na svemu sto ste pisali. Hvala vam neizmerno na svim komentarima.

Istina je da je ono sto sam nazvao "enterprise" projektima koje sam radio verovatno "enterprise" za mene i mozda one koji koriste aplikaciju ali ne i po vasim standardima. Najvise mogu da se pohvalim sa par web shopova na nivou Gigatronovog sajta, MMORPG igricom poput popularne Omerte (s obzirom da je projekat bio "kloniranje" aplikacije ne smem da spominjem konkretno ime), ~10 upravljackih alata za linux softver koji ima CLI (graficki interfejs sa monitoringom, svim opcijama koje softver pruza...), dve instant messaging aplikacije sa upotrebom jakih frontend alata i backendom uradjenim u C++, jednu sa BE u Pythonu, dve aplikacije sa neuronskim mrezama uz pomoc backenda opet u Pythonu (radio sam sa AIMA svojevremeno), i jednom igrom koja je "slican fazon" Traviana, koja je bila pravi izazov sa kolicinom informacija koje treba da se obrade u realnom vremenu, a one koje nisu hitne, da se bar prikazu "u realnom vremenu" uz pomoc frontenda. Tu je i jedan forum CMS tipa phpBB. Ima tu jos stvari, 5 ujutru je, budan sam od 8 jutros, oprostite ako sam nesto preskocio, zadnjih 15 dana bas slabo balansiram vreme.

Posle svega sto ste napisali, mislim da sa sadasnjih 26 godina treba da izguram jos bar do 36 sa PHP-om kao glavnim jezikom. Tu naravno odgovara dobra slicnost sa C++ koja pomaze pri izradi daemona i slicnih stvari.

Ono na sta bih se sad fokusirao, sto sam kod vecih aplikacija peglao preko kvalitetno pisanog softvera u C++, je alokacija memorije. Iskreno nigde sem u online igrama nisam imao problem jer je vecinu aplikacija koristilo nekih 5.000 do 100.000 ljudi dnevno, na istom serveru. Gledam da upiti ka bazi budu sto konkretniji i da nema puno nepotrebnog peglanja. Radio sam testiranje aplikacija sa licno pisanim skriptama za izvrsavanje u isto vreme sa random validnim upitima (opet moram da kazem, ovo sto sam radio je verovatno unit testing, ali na svoj nacin...) i trazio uska grla, uglavnom sa par hiljada upita u isto vreme (ne sa petljama vec sa threadovima bukvalno, znaci u isto vreme kreiranje mikroprocesa sa zahtevima). Nisam nailazio na probleme.

Pored alokacije memorije, ucenja unit testinga na pravi nacin kako se radi, ostaje mi ucenje popularnog frameworka. Jos uvek ne znam sta cu s tim, da li Laravel, da li Symfony, da li Zend. U vreme kada sam se interesovao za ovo, Zend je iz nekog razloga bio najpopularniji, vidim da danas nije takva situacija i da su prva dva definitivno bolji izbor.

Sto se tice usputnih stvari (oprostite opet, mozda nije po redu), za android dev sam presao na Kotlin pre nekog vremena po savetu i mogu reci da je totalno drugaciji dozivljaj nego ranije kada sam se cimao sa Android Studiom. Tu sam trenutno u fazi ucenja, U isto vreme sam u potpunosti proucio Docker, isprobao ga na par nacina i aplikacija koje sam radio, svidja mi se koncept. Teska srca priznajem da mi "cloud" koji sam pre par godina pljuvao prirasta za srca sa stvarima koje donosi. Imam ideju da jednu aplikaciju koju koristi cca ~2000 ljudi u isto vreme isprobam sa load balancingom na 2-3 servera, cisto da se poigram malo i sa efektima u realnoj primeni. Daleko od toga da je zasicena ali me zanima kakve cu rezultate postici.

Znaci neki plan:

- Symfony/Laravel
- Unit testing * na pravi nacin :)
- Rad sa velikom kolicinom "tezih" upita, kesiranje i alokacija
- Prelazak u potpunosti na PHPStorm
- Vece fokusiranje na backend u PHPu

Plan je da ovome posvetim neka 3 meseca rada po 5-9 sati dnevno. U isto vreme, voleo bih da mogu ovde da napisem kako teku stvari, pa da me po potrebi dalje posavetujete i ispravite. Posle ta 3 meseca, ideja je da apliciram za posao PHP developera u nekoj firmi, koja ne mora da mi da najvecu platu, ne mora da mi da najbolje uslove, ali treba da mi pruzi iskustvo kako se NA PRAVI NACIN radi timski projekat, da mi usavrsi znanje koje imam, nacine o kojima vi pricate, pokaze stvari koje nisam ni poznavao i samo izgradi to samopouzdanje u meni, i da znanje o svim tim stvarima koje su mi trenutno nepoznanica. A posle toga... videcemo. Iskreno trenutno bih se u takvom radnom okruzenju jedino fokusirao na novo znanje i ispravljanje losih navika. Plata koja ce preci pet cifara moze da saceka godinu i kusur. Prioritet mi je znanje i u ovim godinama usmeravanje na pravi smer, a mislim da je posao u dobroj dev firmi jedino sto moze da mi pruzi to trenutno.

Jos jednom,

Veliko vam hvala svima od srca.

Nikola
[ Branimir Maksimovic @ 17.05.2018. 07:06 ] @
Ako imas 10 godina programiranja iza sebe, nece ti biti problem da radis u firmi. Pregledaj oglase vidi koji se framewor-ci traze to nauci pa se javljaj na oglase. Firme uglavnom daju test sa rokom od dva dana da uradis nesto, nakon pitalica, sve na isti kalup, tako da
ako se ne prijavis odmah za neki posao, neces pre steci iskutsva da vidis kakav je kalup ;p
A verovatno negde mozda prodjes i bez laravela ;p
Nekako imam utisak da potcenjujes sebe, a ne bi trebalo.
[ gost12 @ 17.05.2018. 08:59 ] @
Slažem se s Branimirom, ovo sve što si naveo, nisu to teške stvari, imaš dobru osnovu bilo gdje da počneš u firmi raditi (rijetki čak koriste taj nivo) jako brzo se ove stvari pohvataju, iskustvo je sve.
[ Zlatni_bg @ 23.05.2018. 02:16 ] @
Verovatno je da me je uhvatila frka, a poslednjih 2-3 godine sam radio dosta manje projekata nego ranije, i da me je uplasilo to sto nisam cepao Laravel koji je sada obavezan (ili bar Symfony). Stabilizujem se psihicki manje vise :D Poenta je sto je doslo vreme da krenem sa radnim stazom, knjizicom, sve crno na belo, i da me je izgleda to uplasilo, koliko god da imam dobre komunikativne sposobnosti i sve ostalo, 'bem li ga, nekako se sve mislim da nisam u toku s novim tehnologijama, tipa zaobilazenje cele "cloud" fame do pre nekih godinu i po-dve kada sam skapirao da je vreme da batalim dedicated/vps i shared kao jedine opcije.

Najveca greska je verovatno sto sam ignorisao frameworke i forsirao svoj, sto ste mi i rekli. Razumeo bih u startu i za phpunit sve, i kesiranje i testove... zao mi je sto sam tek sad uzeo da radim u Laravelu po prvi put. Za manje stvari ume da smara prilicno, zato sam uzeo nesto malo jace da radim (test projekat) da se uhodam i skapiram sve sto mi pruza.

Tako da, iako bi me verovatno negde primili na radno mesto bez poznavanja nekog poznatijeg fwa, ipak imam luksuz da potrosim malo vremena na ovo. Sada cepam neki "forum style" cms, necu se previse igrati sa frontendom sem sa malo ajaxa, sve u PHPStormu, pa da vidimo kako to ide :) Nekad se osecam kao da "varam" sa svime sto mi laravel pruza :)
[ Branimir Maksimovic @ 23.05.2018. 03:05 ] @
Pazi JS programeri su cini se sad na velikoj ceni i izgleda da ih placaju zlatom ;p
Kad vec radis PHP upotpunio malo i sa JS (react ili angular) sto je sada in.
[ VladaSu @ 23.05.2018. 07:51 ] @
Ja se ne bih slozio sa nekim komentarima tj ne mogu da skontam sta je trebalo postici sa pitanjem "kako radis invalidaciju kesa?"
Radis onako kako treba da se radi, ne vidim tu puno mogucnosti. Mislim, onda da te pitam, kako radis if petlju?
Sta 50.000 upita u sekundi?....
Vidi ovako.
Ako se zaposlis ili ces biti samostalni programer koji ce raditi na manjim projektima u nekom CMS-u.
Nikoga nece biti briga kakav je kod i slicno vec samo kakav je dizajn i da ima ono sto je klijent trazio, uglavnom manje komplikovano.
To su projekti od par dana do 6 meseci. Mozda vas bude par vas.
Druga mogucnost je da radis na nekom velikom projektu. Tu neces ti kao novi clan projekta razmisljati o kesiranju, bazama, broju requestova vec je to tim ljudi koji
su uglavnom iskusniji od tebe na tako velikim projektima i ti ces morati da se prilagodis njihovom fw, nacinu kodiranja i razmisljanja i internim pravilima.
To neces ti smisljati. To prilagodjavanje je vrlo brzo i jednostavno za nekoga ko kodira 10 godina. Recice ti da koristis Git. Sednes i za sat vremena pocnes da ga koristis.
Ti ces najverovatniji brinuti o jednom delu koda koji ce drugi pregledati i skrenuce ti paznju na greske.
Polako ces da skontas sve detalje.
Mislim da si se bezveze uspanicio.
Jedino sto treba da naucis neki FW ali to nije obavezno Laravel.
Mala je verovatnoca da ce te neko zaposliti da bi ti uvodio neka nova pravila i iskustva u firmu vec ces ti morati da se prilagodjavas.
[ nkrgovic @ 23.05.2018. 08:58 ] @
Pitanje kako radis invalidaciju kesa je pitanje "da li radis invalidaciju kesa, da li si je dobro osmislio i da li je efikasna". Nemas pojma koliko sam puta video :

- Sistem koji nema kesiranje
- Sistem koji ima kesiranje ail nema invalidaciju
- Sistem koji invalidaciju radi tako sto flushne SVE.

Neko ko ima 10 godina iskustva se nece zaposliti kao junior.

Ako krene u agenciji, OK. Radice 6 meseci projekte, sve lagano, sve si u pravu. Ali ako predje u veliki sistem nece mu dati sve osmisljeno, ne primaju juniora sa 10 godina iskustva. Dace mu neki ceo modul da osmisli i realizuje. Nije lose da zna kako radi logika ;)
[ djoka_l @ 23.05.2018. 09:15 ] @
Citat:
2. Kontejneri, tipa Doker. Dosta ljudi koje upoznam me pitaju da li ih koristim. Nikad nisam osetio potrebu za istim niti ih koristio, ideja mi je da sve aplikacije svedem na nivo da rade na minimalnom broju potrebnih resursa servera, ukoliko imam potrebu za daemonom ili necim slicnim, isti odradim u C++ ili Pythonu. Uz svako parce softvera koje prodam dam potpunu dokumentaciju i source naravno, i instalacionu skriptu. Uz to, pruzam i tehnicku podrsku i odrzavanje na dogovorenom vremenskom periodu, po potrebi i obucavanje za rad.


Koliko sam shvatio, ti si do sada uglavnom radio samostalno. Zato ti ni ne treba da mnogo znaš o kontejnerima.
Za rad u grupi, mora da postoji način na koji se sinhronizuje rad grupe. Najčešće imaš neki build server (ako je PHP, onda i nema neki build, nego samo server za integraciju koji povuče iz repozitorijuma poslednje komitovane module i uradi automatski test), pa posle toga deployment server. Kontejner se pravi u procesu bildovanja projekta i to, najčešće zna samo jedna osoba u timu kako se radi. Jednostavno, ne baviš se instalacijom i pravljenjem instalacionih skriptova, to se sve radi u CI/CD serveru i dobiješ kontejner, upakovan i sa sve mašnicom koji se samo spusti na mašinu klijenta.
[ dejanet @ 23.05.2018. 10:12 ] @
Invalidacija cache-a skoro uvek zahteva ozbiljan fokus i ne postoji univerzalno resenje.

Da, za rad u timu neki SVN ili GitHub, plus integration server. Frameworks, lepo su objasnili iskusni likovi ovde na es-u(procitaj postove mislim Avramovic-a ili tako neko ime).
Onda ti nece biti tesko da to procitas/isprobas.

Nije lako preci sa samostalne sljake na "idem na posao". Svaka firma/tim ima male specificnosti u dev okruzenju, organizaciji tima, nacinima kako se neke stvari rade itd..
[ CoyoteKG @ 23.05.2018. 12:35 ] @
Citat:
Branimir Maksimovic:
Nekako imam utisak da potcenjujes sebe, a ne bi trebalo.

Da, citajuci njegovo iskustvo na cemu je radio, i nacin na koji razmislja, petocifrenu cifru ce svako da mu ponudi.
Mi smo do skora trazili nekog PHPovca, gde 1000E plata je bila vrlo lako ostvariva, pogotovo za njegovo znanje.
Kad se samo setim ko se sve javljao, i sa idejama o kojim ciframa...

Odustali smo na kraju od toga, pa eksterno unajmljujemo po projektu.

[ dakipro @ 23.05.2018. 13:06 ] @
On i ne trazi petocifrenu platu (odmah) vec pita sta da uci i radi dalje i kako moze da napreduje.
Ne vidim kako mu tvoj komentar pomaze (sigurno ne motivaciono), odrzimo komunikaciju na (konstruktivnom) nivou
[ VladaSu @ 23.05.2018. 13:06 ] @
@nkrgovic Slazem se sa tim sto si rekao u vezi kesiranja ali tako nesto ne bi smeo ni junior da radi. Mozda ako je poludebil.
Stvarno ne razumem kako kesiranje zahteva ozbiljan fokus.
Kesiras sa odredjenim key ili tag ili nesto trece Stavis timeout. Inavlidiras kes pri promeni ili brisanju. Pazis na limite. Mislim da ako se PHP programer zadrzava na tome kako ce nesto kesirati i invalidirati onda je bolje da menja posao.
Ne iskljucujem mogucnost loseg kesiranja kada se kasnije o ogroman projekat pokusao ubaciti a nije planirano.
To mi je kao da dizajnere koji radi u Photoshopu i Corelu pitas da li zna da radi u Paint-u. On treba da zna Paint u detalje cak iako sada ulazi u taj program prvi put jer je njegovo znanje i logika mnogo veca od jednog Paint-a.
[ CoyoteKG @ 23.05.2018. 13:40 ] @
Citat:
dakipro:
...(sigurno ne motivaciono)

Jeste motivaciono,
Ne mora da brine da će morati godinama da radi za manje od petocifrene cifre da bi stekao uslov za tu cifru. Jer sa svojim iskustvom i znanjem koje je napisao, sigurno je lako ostvariva i ta petocifrena cifra odmah.
Dakle motivaciono u smislu, da ga finansije ne sputavaju, nego da krene da trazi posao odmah.
[ dakipro @ 23.05.2018. 13:56 ] @
Izvinjavam se ondaK, moja greska... citao sam komentar sa naocarima za ironiju, sad vidim da si mislio bas to sto si i napisao. My bad
[ CoyoteKG @ 23.05.2018. 14:30 ] @
Ne znam odakle ta ideja...
Možda zbog EMZ, tamo znam da budem ironičan, ali zato što su takve teme, i diskusija sa takvim tipom ljudi, da ne kažem trolovima.
ES je za mene potpuno drugi forum, tu sam oduvek korektan.
[ Zlatni_bg @ 23.05.2018. 16:27 ] @
Hehe :)

Ljudi, radite bas ono sto sam i napisao da bi mi bilo drago da cujem. I napadanje, i spustanje, i saveti, i ohrabrivanje. Ne treba niko pod zlatnim zvonom vise da me cuva :)

Ima posla i nudjen mi je posao, cak na univerzitetu singidunum, ali nisam na tom radnom mestu (racunarski centar konkretno, odmah posle zavrsetka studija) osetio neku mogucnost za daljim usavrsavanjem. Jednostavno sam zeleo da se bavim developmentom. Onda mi je mentor rekao da ukoliko budem ikad trazio posao duze od mesec dana, da mu se javim i naci ce mi posao.

Opet, nisam zeleo da ulazim u bilo kakvu dalju pricu sa poslom dok nisam pregledao sta jedan PHP developer danas treba da zna. Citajuci opise radnih mesta i uslove, naisao sam na te neke barijere i rupe u svom znanju, koje sam zeleo da popunim pre nego sto krenem da radim. I dalje je ostalo novca od projekata, pa mi se ne zuri i gledam da dovedem sebe na nivo da bar mogu da pricam o svim tim stvarima sa ljudima koji ce mi sutra biti kolege. Ako neko radi u Laravelu, bilo bi malo glupo da ga nikad nisam taknuo, a da zelim da radim u toj firmi. Bar je to moje misljenje. Radije bih potcenio sebe nego precenio, i stvarno sam preveliki perfekcionista.

Zato su mi mnogo, mnogo znacajna iskustva svih vas koji ste radili u firmama, radili na velikim projektima i u timu. Najveci tim koji sam ja imao je da ubacim sebi u projekat dizajnera i front end developera ponekad koji bi mi peglali izgled onoga sto moja aplikacija treba da izbaci ili zatrazi. S obzirom da sam od osnovne skole isao na takmicenja, ostala mi je navika da pisem dobru dokumentaciju, pa se sve lako zavrsi. Ali opet sam ja bio lead u celom projektu, a u firmi necu biti.

Mogu li da pitam, u kojim slucajevima cu se susresti sa problemima sa kesiranjem? Mozete li da mi date konkretan problem?
[ VladaSu @ 23.05.2018. 17:06 ] @
Ako mozes procitaj dokumentaciju o kesiranju i napisi kako bi ti to uradio. Ja prosto ne mogu da poverujem da bi tu bilo nekih problema ako radis u PHP 10 godina.

Konkretno mislim da je najveci problem kada programer ne rasclani dovoljno kesiranje. Npr ima podatke A, B i C koji se najcesce prikazuju zajedno kao podatak D. Znaci D = A + B + C.
I onda programer kesira D podatak, tj rezultat. Problem nastaje kada se promeni A podatak. Koji sada kes da brises? Kako mozes biti siguran da je u D rezultatu?
Moras da pravis skript da vidis gde se sve koristi A podatak i da vidis da je to u D kesu i onda brises D kes. Ili brises ceo kes.
To se radi tako sto ne kesiras u D i ne koristis D vec koristis A + B + C bez D jer operacija A + B + C nije skupa operacija vec je vadjenja podataka za A,B i C skupo.
Postoji mogucnost kod nekih FW da rezultatu dodelis tagove kojima indentifukujes A, B i C i onda kada promenis A podataka kazes da brises sve keseve gde je tag idendifikovan sa A.
Sam FW ce skontati da treba da brise D.

Sledeci problem je dosta vezan ovo sa D = A + B + C. Desi se da D = A+B+C + ... 100x pa da je kes D prevelik i iznad programskih limita. Opet se to resi tako sto ne postoji D.

Ovo se resava tako sto svaki model je zaduzen za svoje kesiranje, upis, brisanje itd, a drugi modeli koriste kes kroz taj model koji je i vlasnik podataka i ne kesiraju podatke od drugih modela.
Jednostavno ako nesto treba da procitas iz B tabele a nalazis se u A modelu neces pisati sql u A modelu vec ces pozvati metodu iz B modela koji cita podatak iz B tabele.
Tako i kesiranje.
[ Branimir Maksimovic @ 23.05.2018. 17:38 ] @
Zlatni:"Mogu li da pitam, u kojim slucajevima cu se susresti sa problemima sa kesiranjem? Mozete li da mi date konkretan problem? "

Pa ne znam koliko je kesiranje problematika PHP-a, to vise pripada nekom middleware-u koji ce biti recimo u C++ ;)
Ono sto sam ja radio je da serijalizujem upise u bazu kako bi se smanjio pritisak, a sto se tice citanja imas LRU algoritam koji se vecinom koristi.
U principu kad je upit jako dug onda sam kesirao na neki vremenski period, pa upit koji dodje nakon tog perioda prebrise taj entry.
Ali kazem, sa obzirom da se php ne vrti kao serverski proces ne vidim kako bi cache-irao osim da smestas na disk, pa je tu dara veca nego mera
sa obzirom da onda postoji citava problematika oko konkuretnog pristupa toj bazi ;)
[ VladaSu @ 23.05.2018. 18:30 ] @
@Branimire Ne znam o cemu pricas? Deluje mi kao da nikada nisi radio kesiranje u PHP-u i da si pokusao da napravis neko svoje kesiranje od nule sto niko ne radi.
Za kesiranje podataka se koriste kes serveri. Memcached, Redis, APC i slicno.
U svakom FW postoji sloj koda koji su drajveri za odredjeni kes server i postoji kod koji komunicira sa kes serverom preko drajvera.
Tvoj kod se svede na to da odredis koji ces software koristiti, podesis drajver i to je to. Kod preko kojeg se komunicira pareko drajvera treba da je skoro pa 100% isti nezavisno koji je server upitanju.
Ti bi trebao da mozes u jednoj liniji koda da samo promenis drajver i da ceo kod radi bez problema. Tako je u teoriji, a cesto i u praksi.
Naravno da razliciti cache serveri imaju neki svoj feature koji ne moze da se koristi na drugim serverima.

Nema bas nikakve veze sa C++. Da li ce se kesirati na disku, bazi, memoriji... to ne brine PHP programer tj ne zanima ga. To u pozadini radi server. Naravno PHP programer ga jednom podesi i to najcesce u memoriji jer drugi nacin bas i nema smisla i to je default podesavanje.
Kes koji je iskljucivo vremenski odgranicen se retko koristi u praksi.
Sada vidim o kojim problemima je Krgovic pisao i nisam mogao da zamislim da neko tako radi.
Za kesiranje postoji par jednostavnih principa koje sam opisao i nema tu sta da se puno uci ili izmislja topla voda. Mozda sam nesto preskocio jer ne mogu da se setim ali to je uglavnom to.
Koristis par naredbi kao sto koristis npr za citanje, pisanje i brisanje iz jedne mysql tabele samo sto je jos mnogo jednostavnije.
[ Branimir Maksimovic @ 23.05.2018. 18:46 ] @
"@Branimire Ne znam o cemu pricas? Deluje mi kao da nikada nisi radio kesiranje u PHP-u i da si pokusao da napravis neko svoje kesiranje od nule sto niko ne radi.
Za kesiranje podataka se koriste kes serveri. Memcached, Redis, APC i slicno."

Pricam o tome kako sam radio middleware u C++.

edit :
Samo da ti odgovorim na ovo:
"Kes koji je iskljucivo vremenski odgranicen se retko koristi u praksi."
Rekoh ako je upit jako dug. Znaci to su statistike, recimo presek necega u zadnja 3 meseca, sto moze da potraje i pola sata.
Sama baza se menja real time pa onda ne mozes nikako za tako nesto primeniti neku drugu strategiju niti ima smisla.


[Ovu poruku je menjao Branimir Maksimovic dana 23.05.2018. u 20:04 GMT+1]
[ dejanet @ 23.05.2018. 19:38 ] @
Citat:
VladaSu: Stvarno ne razumem kako kesiranje zahteva ozbiljan fokus.

Pa evo, kako pises tako odmotavas scenarije koji nisu maciji kasalj, takodje da timeout nije najbolja praksa itd..

Ono gde generalna/instant cache resenja ne rade posao, po mom skromnom misljenju, jesu veliki broj konkurentnih pristupa.
[ Branimir Maksimovic @ 23.05.2018. 19:44 ] @
dejanet: "takodje da timeout nije najbolja praksa itd.."

Koja je bolja praksa za statistike ?

"Ono gde generalna/instant cache resenja ne rade posao, po mom skromnom misljenju, jesu veliki broj konkurentnih pristupa. "

Zbog konkuretnih pristupa i pravis cache... resenja za specificni upit su sigurno bolja od generickih resenja.


[ dejanet @ 23.05.2018. 19:59 ] @
Citat:
Branimir Maksimovic: Koja je bolja praksa za statistike ?

Pa ako nema veliki broj konkurentnih citanja moze da prodje, ali ako imas par desetina konkurentnih citanja u trenutku invalidacije(timed out) i ponovog generisanja, ode Vinca u vazduh.
Citat:
Branimir Maksimovic: Zbog konkuretnih pristupa i pravis cache... resenja za specificni upit su sigurno bolja od generickih resenja.

Obicno napravim nesto kao graph sa operacijama i data objektima,zatim implementiram graph kao klasu, odnosno ne koristim cache.
Ali ajde da ne trujem ovde, jer nisam php programer.
[ Branimir Maksimovic @ 23.05.2018. 20:04 ] @
dejanet: "Pa ako nema veliki broj konkurentnih citanja moze da prodje, ali ako imas par desetina konkurentnih citanja u trenutku invalidacije(timed out) i ponovog generisanja, ode Vinca u vazduh."

Sta onda predlazes kao bolju strategiju? Ja recimo dok traje generisanje ne pustam dva konkuretnna ista upita...

"Obicno napravim nesto kao graph sa operacijama i data objektima,zatim implementiram graph kao klasu, odnosno ne koristim cache.
Ali ajde da ne trujem ovde, jer nisam php programer. "

Kako to pomaze kod konkuretnih upita i zasto je to bolje od cache-a i kako se to upste razlikuje od cache-a.
Meni se cini da ti poisujes data strukturu koju koristis kao cache ili se varam?
Ni ja nisam PHP programer, a kao sto gore pre par postova navedoh nije ovo problematika za PHP ;)

[ VladaSu @ 23.05.2018. 20:10 ] @
Nisam razumeo termin "upit jako dug". Ja bih to rekao tezak ili spor. Statistike su dosta dobar primer ali su takvi primeri u manjini.
Takvi primeri su jos jednostavniji primeri i bas kod takvih primera ne vidim da bi trebao biti neki problem.
Jedini veci problem moze biti kada se moraju pratiti podaci u realnom vremenu i to je nesto komplikovanije ali stvarno nedovoljno komplikovano da bi o tome trebali pricati..


Dejane. Sta podrazumevas pod "Ono gde generalna/instant cache resenja ne rade posao, po mom skromnom misljenju, jesu veliki broj konkurentnih pristupa." ?

Nisam rekao da timeout nije najbolja praksa vec se dosta redje koristi u praksi. To je super praksa za statistike koje nisu realtime.
Naveo sam jedan princip kojeg se treba drzati kod kesiranja i to nije tesko preneti u kod.

Ustvari citavu ovu pricu oko toga da li znas da kesiras ili ne znas sveo bih na to da li znas da programiras ili ne znas jer probleme koji vi navoditi su problemi arhitekture aplikacije a ne samog kesiranja.

[ Branimir Maksimovic @ 23.05.2018. 20:17 ] @
Vlada:"Nisam razumeo termin "upit jako dug". Ja bih to rekao tezak ili spor. Statistike su dosta dobar primer ali su takvi primeri u manjini.
Takvi primeri su jos jednostavniji primeri i bas kod takvih primera ne vidim da bi trebao biti neki problem.
Jedini veci problem moze biti kada se moraju pratiti podaci u realnom vremenu i to je nesto komplikovanije ali stvarno nedovoljno komplikovano da bi o tome trebali pricati.."

Dugi upiti se ne mogu odraditi u realnom vremenu, cim cekas na rezultat neko vreme. Ono sto mozes je da vracas rezultat u realnom vremenu, a to ne mozes nikako
na drugi nacin nego da kesiras neki rezultat pa na timeout da osvezavas podatke.

[ VladaSu @ 23.05.2018. 20:19 ] @
Pod dugim upitom sam mislio dugacko napisan a ne vremenski da dugo traje tj da je spor. Zbunilo me tamo serializacija i to..
Nisam jos cuo da neko kaze da je dug vec spor ili heavy..

Dejane. Sada vidim sta si mislio pod konkurentim pristupom.
Sajt na kojem sam radio ima preko milion online korisnika u svakom trenutku. Ne registrovanih nego online. Nema nikakvih problema sa konkurentnim pristupom. I taj konkurentni pristpu je mnogo bezbolnije resenje nego svaki put drljati po bazi.
Ima problema koje Krgovic navodi ali ti problem su nastali uglavnom zato sto postoji neki zahtev da se nesto napravi, pa onda dodaj ovo, oduzmi ono, pa cemo ovo lako resiti. Onda se taj krug jos par puta ponovi i imas 5 tabela a ne jednu.
Da je zahtev do kraja bio unapred razradjen onda bi i kod bio bolje razradjen.

I da, itekako je ovo problematika za PHP. To je kao da bi rekao je pogresno napisan SQL u PHP-u problem MySQL, a ne PHP koda. Zasto bi se neki PHP programer brinuo o tome kako MySQL skladisti podatke, kako cita i kako izvrsava naredbe?
Saljes MySQL naredbe i cao.
[ Branimir Maksimovic @ 23.05.2018. 20:24 ] @
Vlada:"Sajt na kojem sam radio ima preko milion online korisnika u svakom trenutku"

Koliko requesta u sekundi? quad core moze da vrati do 60k requesta u sekundi hello world stranica. Znaci ako iza ide PHP sa jos nekim procesiranjem i bazom
onda je to znatno manje.

"I da, itekako je ovo problematika za PHP"

Problematika u smislu kako ces resiti problem, koristeci neko gotovo resenje ili sam pisati server u nekom drugom jeziku ;p


[ dejanet @ 23.05.2018. 20:32 ] @
Citat:
Branimir Maksimovic: Sta onda predlazes kao bolju strategiju? Ja recimo dok traje generisanje ne pustam dva konkuretnna ista upita...

Pustio bi background proces koji generise data, a zatim kada zavrsi, podmetnuo kao cache objekat. To bi ujedno bila i invalidacija old data-e.
Obicno za ove tipove report-a postoje postoje razne opcije u db serverima.

Citat:
Branimir Maksimovic: Kako to pomaze kod konkuretnih upita i zasto je to bolje od cache-a i kako se to upste razlikuje od cache-a.

Pa instanca klase i memory cache objekat stoje u meoriji, ali nisi ogranicen cache implementacijom koja je mnogo sira od implementacije klase za konkretan slucaj. Koristis prave array tipove za konkretan slucaj, menjas property values koje moras u thread safe maniru, a ne ceo cache objekat, imas puno slobode i mogucnosti da optimzujes metode u klasi itd.. Kada imas definisan "graph" sa svim desavanjima i zavisnostima, onda imas sanse da uradis citanje i promene data koliko toliko optimalno.
[ Branimir Maksimovic @ 23.05.2018. 20:37 ] @
Deja: "Pustio bi background proces koji generise data, a zatim kada zavrsi, podmetnuo kao cache objekat. To bi ujedno bila i invalidacija old data-e.
Obicno za ove tipove report-a postoje postoje razne opcije u db serverima."

To mozes tako ako je upit unapred poznat i ako ih ima ograniceno malo. U mom slucaju upit je unapred nepoznat i ne zna se koliko ih razlicitih ima.
Dakle recimo vremenski period presek, konkretno, ne mozes tako resiti.

"
Pa instanca klase i memory cache objekat stoje u meoriji, ali nisi ogranicen cache implementacijom koja je mnogo sira od implementacije klase za konkretan slucaj. Koristis prave array tipove za konkretan slucaj, menjas property values koje moras u thread safe maniru, a ne ceo cache objekat, imas puno slobode i mogucnosti da optimzujes metode u klasi itd.. Kada imas definisan "graph" sa svim desavanjima i zavisnostima, onda imas sanse da uradis citanje i promene data koliko toliko optimalno. '

Mislim da se u ovom slucaju radi o terminologiji. Ti pravis custom cache resenje koje je svakako bolje od generickog resenja. Mislim da se ovde slazemo.

[ VladaSu @ 23.05.2018. 21:15 ] @
Podmetanje kesa iz background-a kod statistika ima smisla ali kod realtime podataka bas i ne.
PHP ima gotovo resenje za kesiranje a tvoje je da mislis o tome kada i gde da pises, citas i brises kes u PHP kodu.
Ovde ne pricamo o programu koji kes server vec koriscenju kes servera preko PHP-a.
[ dejanet @ 23.05.2018. 21:38 ] @
Citat:
Branimir Maksimovic: To mozes tako ako je upit unapred poznat i ako ih ima ograniceno malo. U mom slucaju upit je unapred nepoznat i ne zna se koliko ih razlicitih ima. Dakle recimo vremenski period presek, konkretno, ne mozes tako resiti.

Da kapiram, cache varijante odpadaju.
U tim slucajevim kada podataka ima ober "puno" a query traje, uveo bih nesto kao fifo queue, tj. red cekanja, pa koliko traje traje(puci nece) ili scheduled reporting ako se report moze generisati kao neki dokument, a moze i kao serijalizovan report object. Ne znam koji je db server u pitanju , ali ako i nema, mozda moze da se nabudzi materialized view tabela i deo posla gurne u db server.
[ dejanet @ 23.05.2018. 22:03 ] @
Citat:
VladaSu: Podmetanje kesa iz background-a kod statistika ima smisla ali kod realtime podataka bas i ne.

Slazem se da za real time data mora postojati neka varijanta cache-a, odakle web server putem websocket-a ili signalr-a broadcast-je datu web klijentima ili pak old fashion preko ajax poziva. U taj cache mogu npr. dolaziti real time data i drugih delova sistema putem nekom service bus-a ili tcp-a.
Ovde bi takodje izbegao genericki cache u korist "speijalizovane" implementacije.
[ Zlatni_bg @ 23.05.2018. 23:17 ] @
Ja sam zapocinjao temu, reci cu samo da sam ovakve stvari sretao u MMORPG projektima na netu, Omerta klon i Travian klon (ne bukvalni klonovi naravno, neke stvari su izmenjene ali je ideja igre zadrzana, omerta je nesto kao "mafia wars" sa fejsbuka). Kako bih rasteretio sistem, neke stvari mi je C++ brze izvrsavao, i ono sto je moralo da se radi u realnom vremenu se vrtelo u C++. Projekat je bio mesavina C++/PHP/MySQL/AJAX/ostale frontend tehnologije. Jednostavno mi je bio neophodan daemon, mogao sam da koristim mozda PHP CLI za to, ili cist PHP, ali C++ je po meni bio bolji izbor. Konkretno u travian klonu sam imao mnogo izazova - imao sam mapu 400x400 polja, svaka je imala neke svoje podatke o resursima, svaki igrac je imao vlasnistvo nad 1+ polja mape, svako polje mape je imalo 20+ resursnih polja. Nesto je moglo da se pegla u frontendu, tipa trenutna kolicina resursa koje igrac ima u svom polju (selu), bilo bi malo glupo svaki cas ajaxom da zovem bazu i da je apdejtujem vise puta u sekundi. Problem je bio kako u realnom vremenu racunati da li korisnik ima dovoljno resursa za izgradnju nove zgrade u tom selu a da pritom ne moram da cesto menjam podatke o resursima korisnika. Znaci imamo recimo, glinu, kamen, zito, drvo, to su sve resursi kojih se dobija promenljivo, 10-50000/h, po selu koje jedan igrac ima, a sela je moglo da bude 400x400. PHP mi nije bio pogodan za to, C++ je bio mnogo bolje resenje, i tu sam koristio C++ za kesiranje mnoooogo podataka. Iskreno nisam siguran da PHP u bekendu i moze da izadje na kraj sa tim.

Ono sto sam radio je apdejt svih sela koje igraci imaju na nivou jednog sata, jedno po jedno kako ne bi dolazilo do zagusenja. Upisivalo se vreme poslednje promene i nivo proizvodnje resursa svakog polja u selu - kojih je 20. Kada korisnik unapredi resursno bolje, i to se apdejtuje u bazi. Potom pri izgradnji nove zgrade se racuna koliko je korisnik potencijalno imao resursa naknadno posle poslednjeg apdejta. Takodje, morala je da se apdejtuje i proizvodnja kad god se unapredi resursno polje, i podatak proizvodnje resursa na sat.

Generalno, ne znam puno o kesiranju da budem iskren, zato sam i pitao. Ali nikad nisam dostigao limit u normalnim PHP aplikacijama da imam neki problem sa brzinom, zanimalo me je o kakvom kesiranju, i tipa podataka koji se kesiraju je rec. Sada mi je dosta jasnije.

Moje misljenje je samo da ne treba prelaziti granice nekih tehnologija. PHP sigurno nije bio zamisljen da ikad radi ovo sto je meni trebalo, zato sam se odlucio za C++ u bekendu, PHP je bio veza i neki srednji "bekend" i dalje, a ajax i javascript u frontendu su mi zavrsavali posao. O dizajnu nema sta da se prica, BS i ostalo je korisceno, to nije vezano za temu.

Cepam Laravel, iskreno jos nisam dosao do dela sa kesiranjem i njegovog "posrednistva" u istom. Ne znam koliko ce mi to kao trenutno samostalnom programeru i znaciti, verovatno bi me tim obucio ako radimo na vecoj aplikaciji sta da radim u kom slucaju. Kada sam procitao "kesiranje, validacija" itd, mislio sam da se radi o protoku raznih tipova fajlova preko HTTP headera i tu sam zastucao dok nisam shvatio o cemu se radi :)
[ VladaSu @ 24.05.2018. 07:33 ] @
Pod realtime nisam mislio na chat aplikaciju da se prikazuju realtime podaci. Mislio sam da mnogo redje citas iz baze tako sto ces kesirati neki podatak iz neke tabele. Kada dodje do promene tog podatka onda se i kes vezan za taj podatak brise.
Primer je recimo ovde na ES kada ja odem na tvoj profil nema potrebe da se svi ti podaci uvek citaju iz baze.
1 . Prvi put kada neko ode na tvoj profil kod ce pokusati sa kes servera da procita da li ima nesto pod key "profile-dejanet".
Ako nema onda ce da procita iz baze i procitane podatke da stavi u kes pod key "profile-dejanet".
2. Sledeci put kada neko dodje na tvoj profil ide opet provera da li ima nesto pod key "profile-dejanet" i sada ce biti i uzecemo podatke sa kes servera a ne iz baze.
Rasteretirili smo bazu i dobili mnogo brze ucitavanje stranice.
3 .Problem je kada ti editujes svoj profil onda program mora da brise key "profile-dejanet" i onda ce sledeci dolazak biti opet pod 1. Ako je lose organizovan kod onda je ovo problem a ako nije onda je stvarno lako.

E sada na tvom profilu ima i lista tema gde si ti nesto pisao. To bi bilo recimo u kesu "theme-dejanet" i svaki put kada nesto napises treba da se resetuje kes pod ovim key.
Medjutim tu nastaje problem kada neko izbrise temu. To znaci da ce neko na tvom profilu videti da si pisao u nekoj temi koja vise ne postoji.
Resenje je da se to ignorise. Neko klikne tamo na link teme koja ne postoji i dobije obavestenje da je tema izbrisana.
U ovom slucaju svi "theme-*" key-evi treba da imaju timeout od recimo 1 sat ili 1 dan. To znaci da ce posle 1 sata ili 1 dana lista biti osvezene.
Takodje lista ce biti osvezena ako ti napises nesto novo jer se i tada brise key.
I postoji mogucnost da pri brisanju teme pogleda se ko je sve ucestvovao u toj temi i onda da se izbrisu "theme-*" key svih ucesnika teme.
Postoji i mogucnost preko tagova gde ces reci da se brise svaki kes koji ima odredjeni tag ali onda moras da vodis racuna o tagovanju kes key-a.

Znaci ovde ne pricamo o pravljenju kes servera vec o tome kada i kako slati naredbe i podatke kes serveru, o organizaciji php koda. To je iskljucivo do logike php programera.
[ Zlatni_bg @ 19.06.2018. 15:05 ] @
Jasno. Usao u fazon kesiranja sa Laravelom, malo je otvorio oci :)

Nego, jedno blic pitanje.

Chat aplikacija sa logovanjem. Koju bazu koristiti? Mongo? Sta se preporucuje za takve projekte?

Razmisljam se da u periodu "odmora" napravim neki lightweight chat sistem u Laravelu, zadao sebi danas zadatak. Pitam se da li da pravim server u C++ ili koristim gotov DB za to?
[ Deunan @ 19.06.2018. 23:55 ] @
Kakav chat ti treba? Neki forum? Youtube komentari?
Mislim da je najbolji mysql za to. Najbrzi je za pretragu velikog broja redova.

Ako zelis neki chat kao Viber, Facebook...
Ne radi se to HTTP nego XMPP protokolom. Ne moras da pravis svoj server, imas dosta gotovih.
Najpopularniji je Ejabberd (Viber i Whatsapp su poceli na njemu), pisan u Erlang-u. Ako znas javu, imas i Openfire, bolji je za pocetnike, ali nije bas za production. Imas i Tigase, Prosody...

A imas i google-ov Firebase servis ako ne zelis sam da instaliras i konfigurises.
[ Miljan_X @ 04.07.2018. 21:02 ] @
Ukoliko planiras da radis u drustvenom okruzenju primetit ces da dosta poslodavaca trazi sledece:

- Pozavanje framework (Laravel, Symfony ili neki drugi)
- Pozavanje Node JS
- Poznavanje bar jednog Javascript frameworka (po mom iskustvu Angular je jako trazen!)
- Rad preko Gita i repositoria
- "Just do your biz" sto bi u prevodu znacilo samo gledaj svoj posao pusti ostale da rade svoj deo

to su neke osnovne stvari koje bi trebao znati pre nego sto udes u timski rad.
Ukoliko dobro pozaes materiju vrlo lagano ces da oskocis od ostali i mogucnost napredka u svemu tome ce da se poveca.

[ balavi @ 04.07.2018. 22:04 ] @
@Miljan_X

po tvom iskustvu , koliko je vremena potrebno savladati Laravel i Angular?
[ svepomalo @ 04.07.2018. 22:12 ] @
Citat:
balavi: @Miljan_X

po tvom iskustvu , koliko je vremena potrebno savladati Laravel i Angular?


sve zavisi kakvo ti je iskustvo... moze i za 2 godine a moze i mesec dana
[ Zlatni_bg @ 04.07.2018. 23:03 ] @
Jos nisam video da je ijedan poslodavac za PHP inzenjera trazio poznavanje JS frameworka. Pogotovu ne da zna i node.js, koja je poenta PHPa onda?
[ Branimir Maksimovic @ 05.07.2018. 05:27 ] @
Mislim da sto znas vise to bolje, ali naravno nije obavezno sad i pod moranje. Nekako php i js idu zajedno, ako znas js to je plus, zato sto te web stranice koje pravis tesko da ce biti bez js ;)
[ Zlatni_bg @ 05.07.2018. 07:44 ] @
JS nije frka, ali rad u fwu? Mozda jquery :) I node.js? Sta cu da radim sa pho i nodejs?
[ brux002 @ 05.07.2018. 10:30 ] @
^

Ja sam imao projekat gde smo imali dinosaurus PHP aplikaciju pisanu u Yii 1.X frameworku, dok su hteli da novi featuri bude pisani u nodejs-u i dodati na app kao mikroservisi. Ovo je dosta cesta praksa da se udahne nov zivot starim aplikacijama bez prepisivanja cele app u nodejs. Tu recimo odlicno dodje poznavanje oba jezika. Takodje mislim da su jezici alati i da seniori moraju znati bar nekoliko da bi upotrebili pravi alat za pravi posao (ako sve sto znas da koristis je cekic - svaki problem ce ti liciti na ekser :) )
[ CoyoteKG @ 05.07.2018. 22:26 ] @
Citat:
ako sve sto znas da koristis je cekic - svaki problem ce ti liciti na ekser :)


vrh. Odavno nisam cuo neku bolju metaforu.