Profesionalni rad u PHPu

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.

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

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.

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

Potpis

http://norway.dakipro.com/

@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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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.

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

Potpis

http://norway.dakipro.com/

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.

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?

Potpis

THE ONLY EASY DAY WAS YESTERDAY

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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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 ;)

@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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

"@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.

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.

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.

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.

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.

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 ;)

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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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.

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.

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}