Ce reprezinta “for modern web developers”? exista un articol si “for passé web developers”
AFAIK in momentul in care nu mai esti up to date with the web (si ma refer la its pillars nu urmatoarea clona de React) automat nu mai esti un web developer.
2 Likes
Eu as zice ca inca mai esti web developer, dar ca unul obsolete. (Invechit? Expirat? You get the point…)
Fiindca nu mai esti up to date with all the pillars, dar totusi nu cu toti. Iar in cazul in care vrei sa te re-intorci la web.dev, iti va fi mai usor decat in cazul in care doar ai trece de la alt domeniu de soft.dev, fara a fi la curent cu majoritatea pilonilor.
13 . Aceeasi e situatia si cu codul tau propriu, daca nu intelegi perfect cum functioneaza.
Cât despre a pregăti alți programatori, încă aștept să vină unul. Până acum toți cu care am vorbit (și nu în sensul că tot ce zic eu e aur curat, discuții în care și eu vroiam să învăț de la ei), ei bine, atitudinea a fost: Hai, lasă-mă. (Sunt plătit, asta e tot ce contează. Că fac ceva într-o oră sau două zile e complet irelevant).
Problemele enumerate sunt legate de situații unde trebuie să petreci timp pentru a te documenta legat de ceva unde nu e nevoie de a te documenta dacă faci lucrurile prin PHP pur și simplu.
De exemplu, suprascriere vs generare. Nu semnificația cuvintelor e problema. Ci faptul că trebuie să consum timp pentru a scrie codul pentru a „genera” un query, când pot pur și simplu să scriu query-ul. De ce trebuie să definești relații de genul $this->hasMany([…]), când pot să scriu direct codul? Ah, că deleg responsabilitatea unui terț și e mai „sigur”. Well, până acuma am scris zeci de mii de query-uri, nu pot să identific vreunul care a avut vreo problemă. Dar, noh, probabil fiind începător am avut parte de noroc.
Din nou, accentul văd că e pus pe a demonstra că eu aș fi într-un fel sau altul, în loc de a discuta subiectul central: Presupunerea este că un framework simplifică munca, eu afirma că o îngreunează.
Înveți un limbaj de programare, îți faci treaba foarte bine în el, și apoi te trezești că trebuie să faci exact același lucru într-un framework. Și stai să tot pierzi timpul să rezolvi tot felul de lucruri când mintea îți urlă cât e de simplu ce vrei să realizezi. Da, există php://input. Și cum ajungi la $this->request->input(‘json_decode’, true);? Oh, da, sigur, este un framework și trebuie să aibă un wrapper pentru asta. Și pentru asta mai pierzi niște timp să te documentezi care e funcția și care e lista de parametri când poți foarte bine să iei datele din php://input. Dar să o faci așa nu va fi văzut bine că nu e „din framework”.
După cum zicea Uncle Bob, aceste complicări ale unui limbaj de programare sunt făcute (și) pentru a ajuta oamenii să se angajeze. Eu unul am fost refuzat la un interviu fiindcă nu am lucrat cu Symphony (lucrasem cu CodeIgniter, Laravel și CakePHP) și tipul era complet inflexibil la orice argument că totul e o apă și-un pământ (MVC).
Din nou, lucrurile expuse nu sunt chestiuni despre care trebuie cineva să vină să mă învețe, sunt pur și simplu chestiuni care consumă timp extra.
Dacă e să vorbesc despre problemele mele, ele nu țin de programare cât țin de:
- Am un plugin în CakePHP care merge pe două mașini dar pe a 3-a nu merge nici într-un fel. E ca și cum nu l-am instalat/incărcat.
- Sesiunile sunt configurate în Cake să fie gestionate de PHP. Dar din ceva motiv încă nedeterminat, directorul are un nod în plus față de locația reală.
- Cu Varnish instalat (și fără să știu exact cum e configurat), nu știu niciodată dacă o pagină are o eroare și e din cache sau eroarea aia este reală. Nu că nu știu cum să trec peste, dar, nah, iarăși timp pierdut.
- Cea mai mare problemă este un tabel de câteva zeci de milioane de intrări unde știu 100% că jumătate din ele nu sunt folosite niciodată. Dar nu am permisiunea de la proprietar să modific procesul de importare a datelor. De asemenea tabelul are vreo 30 - 40 de indecși și eu aș vrea să reduc numărul lor la câți indecși e nevoie în funcție de ce query-uri am. Again, the answer is no.
- Am un API care o dată pe zi/o dată la două zile se blochează. Rulează pe o mașină Windows ca serviciu și mereu trebuie să-l repornesc. Altfel el rapoartează că „se actualizează” - adică merge. Doar că nu e făcut de novici ca mine, dat fiind că e în Java (deci nu PHP - limbaj facil carevasăzică). Probabil că eu nu știu suficientă programare și de aia se blochează.
- Am o grămadă de nume de utilizator și parole. În funcție de director, trebuie să lucrez cu altul. Dacă lucrez cu root, trebuie apoi să modific proprietarul de fiecare dată după ce termin. Dacă ar există vreun mod (chmod via cron) să fie schimbate acestea automat la fiecare x minute… (Mă întreb câți o să sară că e chown)
2 Likes
Nu sunt PHP-ist, dar nu pot sa nu remarc ca problemele tale nu sunt despre frameworkuri in sine, ci mai degraba sunt despre oamenii cu care lucrezi. E o vorba: “daca esti cel mai bun dintr-o incapere, esti in incaperea gresita”.
Nu stiu cum e cu frameworkurile MVC sau ORM in PHP, dar eu am lucrat intotdeauna cu ORMs (in .NET) si nu m-as intoarce ever la sql chior. De ce? Pentru ca lucrez OOP si DDD (Domain Driven Design). Fie ca as scrie eu sql-ul sau il genereaza un ORM pentru mine, in final tot de obiecte hidratate am nevoie. Sa nu mai zic ca un ORM folosit corect poate fi chiar mai performant decat sql pur, in unele situatiii. In altele este mai lent, evident, datorita unui nivel de abstractizare in plus. Mai degraba as imbratisa un nosql capabil sa-mi dea json direct, decat sql.
Despre MVC la fel, nu vad unde este buba atat de mare. Nu cred ca mai zice nimeni “MVC ftw”, dar este totusi o paradigma care a avut succes in multe limbaje de programare si inca mai are.
In .NET, de exemplu, desi aproape nimeni nu mai face proiecte MVC pure (html generat server-side), framework-ul s-a adaptat astfel incat poate fi folosit si doar pentru REST API si este extrem de capabil.
1 Like
Vorba ca vorba. Uite, mai e una: Nu da vrabia din mână pe cioara de pe gard.
Până la urmă banii primează. De ce aș părăsi un colectiv prost doar pentru a găsi unul mai bun în idea în care nicăieri nu mi s-a oferit mai mult de jumătate din cât fac în prezent?
Again, problema este că în facultate înveți SQL, iar apoi în fiecare framework ai un alt nivel de abstractizare pe care trebuie să-l stăpânești să scrii aceleași query-uri. Și dacă lucrezi cu 3 - 4 framework-uri… Adică eu am uitat cum se făcea toată treaba asta în Laravel în care nu am mai lucrat de vreun an, deși pot scrie query-uri de mână foarte bine.
M-am uitat peste Symphony. Nu am lucrat deloc cu el, însă am priceput că este exact aceeași situație cu celelalte. Nici nu știu de ce avem atâtea cadre de lucru de îndată ce fiecare definește rutele ușor diferit, idem template-urile, toate folosesc acest ORM dar o fac folosind metode marginal (doar cât să nu poți aplica instantaneu ce ai învățat într-un alt framework) neasămănătoare.
Care e avantajul înafară de faptul că ăla mi-a zis: Nah, mie-mi trebuie pe Symphony (adică dă de muncă unor oameni care au cuvântul-cheie în CV)? E chiar așa de puțin de muncă în domeniul dezvoltării web încât trebuie să avem 20+ de astfel de inițiative și fiecare să fie la fel, dar diferit, de fiecare alta?
1 Like
In acest caz poate ca chiar asta este problema: din cand in cand se gaseste cate unul mai destept (fara ironie) care descopera ca toate frameworkurile sunt la fel (de proaste) si ce-si zice? “Ia sa-mi fac eu propriul framework!”. Il face si il mai da si la altii, care-l adopta si uite-asa a mai aparut un framework. Asa e in lumea open-source, limita e cerul.
In orice echipa software sunt unii care impun anumite frameworkuri si altii care trebuie sa le foloseasca, chiar daca nu le place. Daca toti sunt pe picior de egalitate, atunci se discuta rational la inceputul unui proiect si se alege un framework de comun acord. Insa daca proiectul este mai vechi sau unii membri ai echipei sunt mai vechi sau mai “impunatori”, se intampla sa ai un framework care poate nu-ti convine. Nu vad ce poti sa faci in acest caz, doar sa incerci sa-i convingi pe ceilalti ca e mai bine o alta abordare sau sa accepti situatia.
Oricum, tot nu e frameworkul de vina, chiar daca este un framework prost. De vina sunt oamenii care l-au ales si il folosesc in continuare :).
Inca o data, nu stiu cum e in lumea PHP. Poate tocmai pentru ca e open-source, exista atat de multe frameworkuri MVC sau ORM. In .NET e un singur MVC si doua ORM-uri mari si late. Da, din cand in cand apar versiuni noi care aduc multe modificari, dar nu schimba total macazul.
1 Like
I always though of it as strange that Python or Ruby had, to my knowledge, only one framework. And now C# (as that’s the language I assume .NET refers to. Mostly)
Pentru că lucrăm într-o industrie unde nu (doar) banii sunt criteriul de alegere pentru un job?
1 Like
Ti-am mai lasat si mai sus un comentariu, dar nu cred ca ai inteles.
Ce legatura are un HTTP proxy pt cache cu framework-urile?
Probabil nu te-au angajat pentru ca nu te-ai obosit nici macar sa vezi cum se scrie corect numele frameworkului pentru care dadeai inverviu.
PSR-4: Autoloader - PHP-FIG + https://getcomposer.org/ si iti poti face propriul framework - Create your own PHP Framework (Symfony Docs)
Sunt de acord ca folosirea unui framework poate incetini viteza de dezvoltare (ca developer) a unui developer. Fiindca in loc sa treci direct la chestii mai complicate, “pierzi timpul” (dupa cum zice @RedGuard) cu framwork-ul, cu a-l intelege, cu a-l invata, a stii cum se foloseste.
Iar aici ajungem la aceeasi situatie ca si cu frameworks vs. architecture si, mai ales, vendor lock-in.
iti pot scrie o aplicatie simpla (sa spunem un blog) in cateva minute. cu tot cu admin. in 2-3h o fac chiar prezentabila si gata de pus in productie. deci da, un framework incetineste enorm. mai ales cand e vb de aplicatii mai mari.
1 Like