0djek

nuo log'ų kokių nebus užsikimšę viskas? arba kad ir tų pačių cache pluginų duomenys gal išaugę ir suletėjo?

gal koks encoding pasikeite?

Prieš 30 minučių, brogrammer parašė:

Nepraignoravau, sutinku su Tuo ką ten parašei. Socketų aišku kad nerašysiu pats(nors kiek teko su socket API žaist, tai jis paprastesnis negu šiuolaikiniai OOP frameworkai). Pastebėjimas, kad ne frameworko kaltė, o programerio šeip įdomus - motyvuoja geriau išmokti tai ką naudoju, kad būtų tikslesnė kritika arba didesnis vertinimas tiem kas parašė man įrankius. Dėkui už linkus. PHP turi savo ORM native palaikomą viduje.

paprastesnis tai gal va kai ne daug endpoint'u, bet kai prisides daug daugiau visokiu papildomu detaliu sone (auth, middlewares, etc), tada ir bedos prasides. As pavydziui naudoju ASP.Net core framework'a API kurti, tai jis man issprendzia tokius dalykus:

1. Middlewares
2. Dependency injection
3. Swagger docs
4. Authentication
5. Authorization
6. Auto request and response parsing
7. Tikrai tikiu kad dar daugiau yra, kurios nuo manes pasleptos

Jeigu kalba turi ORM, kuri patogu naudoti: why not. C# man rodos patogaus by default neturi, tai kazka naudoti tenka. ORM patogu naudoti, nes man uztenka nurodyti is kokio context'o pasirinkti kokia lentele, ideti filtrus, prijungti papildomas lenteles ir man automatiskai viska padaro, nereikia nieko paciam stengtis. Jeigu pasikeite DB scheme, uztenka pergeneruot modelius ir klaidas sutvarkytos del pakeistu pavadinimu (jeigu tokiu yra).

prieš 6 valandas, brogrammer parašė:

Blogai nes jis tiesiog pasakė tai kas ir taip aišku, jog frameworkai yra templeitai, turintys palengvint darbus, nu ir aišku tipinis lietuvis su tipine replika ant galo dėjo. Klientų ir serverio gaila, nes kartais gali nukentėti kokybė, kai aklai paimamas frameworkas, darbui, kuriam pakanka savo kodo. Turiu omeny serverio apkrovas.

Beje čia keli žmonės paminėjo, jog db api gali išgelbėt jeigu ateity norėsiu migruoti kodą iš mysql į postogre, man įdomu kiek Jūsų pačių praktikoje pasitaikė tokių dalykų?

Jeigu sugebi ant tiek blogai pasinaudoti framework'u, kad visur darbas stoja: cia jau ne template'o problema. Plius dauguma framework'u yra tikrai geriau optimizuoti, negu kad galetum rankomis pasidaryti. Arba naudoji toki framework'a, kuris jau letas yra ir visi skundziasi, kad letas yra.

Nori pasakyt, kad jeigu darysi API, kur yra 2 endpoint'ai ir lieps daryti tau su Python pvz, pats ranka rasyti socketus, juos priziuresi, paskirstysi pagal uzklausos URL i teisingus metodus ir pns? Nes naudojant koki Flask arba FastAPI butu per "leta" bei "uzkrausi serveri"? Ka darysi, kai reikes ta API isplesti iki 10 endpoint'u? O puses metu iki 20? Nori pasakyt, kad tavo homemade veiks geriau, greiciau, patikimiau, patogiau prisiziures ir bus galima lengviau isplesti negu naudojant framework'a? Tikrai taip nebus ir sau paciam nemeluok, kad taip padaryt galetum. As darydamas su framework'u galesiu business logic daryti, kol tu toliau prakaituosi ir bandysi optimizuot. Ir vistiek tokio pat gero rezultato nepasieksi, koki biblioteka duoda.

Mano sita arba praignoravai, arba tiesiog neatsakei: 

Man paciam del DB dar tokio nebuvo, kad reiketu duombazes keisti (per maza imone ir per mazai migruojam, kad ta daryti). Bet buvau uni projektui pasidares, kad in production naudojju MySql, o local'iai su SqlLite . Kadangi naudojau DB API, man tarp environments kodo keisti nereikejo, uztekdavo pakeisti prisijungimo duomenis, visus skirtumus tarp duombaziu (jeigu tokiu net buvo, neisivaizduoju) sutvarke biblioteka. Dar va reddit'o link'as del DB: 

Beje, kaip atrodo pas tave tas PHP ir DataBase duomenu pasiimamas? Pamenu kazkoki rasei, bet nenaudoju PHP, nezinau kaip veikia. Kiek maciau doc'se, tai ranka turi rasyti uzklausas bei tarp puslapiu vaiksciot ir pns?

prieš 4 valandas, brogrammer parašė:

Kaip matau ne vistiem duota mastyti out of the box. Gaila biškį. Tavo klientų ir serverio.

Kurioj vietoj pas jį kas blogai? Nelabai supratau, dėl ko ji puoli, kai jis tiesa sako 😄

ir priciom čia klientų ir serverio gaila? Paaiškino biski

Prieš valandą, brogrammer parašė:

Esmė, kad ne žalias, teko girdėti senioro pasakojimų, kaip į interviu atėję programeriai nesugeba 2+2 sudėti be frameworko pagalbos. Tiesiog atrodo, jog kartais tenka naudoti sprendimus pilnai nesuprantant jų naudos, tai kyla klausimas ar visi aplinkui mane tiesiog apsimetinėja, jog supranta ką ir dėl ko naudoja, kad jų nekompetencija neišlystų?
Ar visą likusią savo karjeros dalį turiu save pasmerkt nežinojimui naudojant abstrakcijas, kurios neaišku man reikalingos ir ką daro?

Tai čia jau ne frameworko kaltę, o pačio programerio. Mikrokontrelius pvz programuojant irgi gali naudoti abstrakcijas, tačiau jeigu reikia greičio, tikslumo ar dar kažko, ko negali pasiekti naudojant abstrakcijas, tada tenka dirbti be jų. VSCode frontend'as su plain JavaScript (arba typescript, nlb pamenu) padarytas, nes jiems greičio reikėjo ir tikslumo. Patys pasidarydami FE framework'a, jie valdo, kaip elementus sukuria, kada juos sukuria, patys gali susitvarkyti bug'us vietoj to, kad laukti, kol kažkas kitas tą padarys.

Dėl to daug kas ir pataria pasimokyti, kelis paprastus projektus pasidaryti be įrankių, kad zinotum, kaip kas ir kodėl. Abstrakcijas naudoji, nes žinai kas būtų be jų ir tiesiog pasilengvini gyvenimą.

Kažkas aukščiau rase, kad frameworkai taip pat struktūros suteikia, padeda komandoje dirbti bei išplėsti, jeigu kada to prireikia. 

Prieš 25 minutes, brogrammer parašė:

Tau trūksta patirties, suvokiant savo įrankius, bei paprasta kalba paaiškinant jų reikalingumą.

del sql'o: ka darysi, kai (kaip pries tai minejo), dirbsi su viena DB, o paskui ja pakeisti turesi? Begsi per visus SQL ir ranka kaitaliosi? Ka daryti, jeigu projektas didelis? Kiek laiko sugaisi tam? Naudojant lib'a tam, vienintelis tavo pakeitimas butu prisijungimo pakeitimas (yra atvejais, kai koks DB kazko nepalaiko, ka kitas palaiko, bet pakankamai retas).

O kai nauja projekta kuri, ar neimi is seno projekto nieko? Viska nuo 0 darai? 

Daugiau: 

Prieš valandą, gabber parašė:

Galim pradet nuo paprastu dalyku, kaip tu renderinsi html template's? Savo twig arba blade rasysi? Tas pats su db api, irgi savo rasysi? Naudosi sql tiesiogiai, o jeigu veliau reikes pereiti nuo mysql i koki postgre sql? Kiek laiko tada sugaisi? Yra dar daug visokiu lib'u kuriu nepaminejau, tu juos irgi pats pasirasysi?

Papildant @gabber, jeigu girdejes apie StackOverflow, tai jis naudojant .Net padarytas (source: https://en.wikipedia.org/wiki/Stack_Overflow#Technology).

Jeigu butu kure viska nuo 0, jiems butu reikeje patiems pasidaryti:

• autentifikacijos flow
• autorizacijos flow
• kontrolerius (i koki url kreipiantis, kas turetu ivykti)
• middlewares infrastructure
• SQL rasymas ir priziurejimas (daug patogiau dirbti su SQL, kai gauni type safety)
• HTML generator
• dar daug kas

Gali but, kad paklydau vietomis, tai del to sorry (gal kazkas istaisys, irgi nesupyksiu), bet kiek matyt gali, tai naudojant jau sukurta framework'a, labai daug laiko susitaupo ir saugiau viskas, nes populiarus framework'us kuria daug ivairiu zmoniu, o ne 20 zmoniu is tavo imones

Prieš 4 minutes, gabber parašė:

Is originalaus klausimo buvo galima suprasti, kad ten kazkieno mintis buvo ta, kad svetaine su PHP bus tik su server-side renderingu, tai as ir atsakiau kad nebutinai.

Apie dinamiskuma. Kazkas pasiklydo savokose. As dabar matau cia kalba buvo ne apie dinamiskuma, o universaluma. Labai skirtingos savokos. Jeigu plestis toliau galiu teigti, kad PHP, ar bet kuri kita kalba, gali renderinti ir client-side per WebAssembly.

Jeigu tik php, tai pagrinde ir bus server side rendering. Kaip sakei gali naudoti php per wasm ir gauti client side rendering, bet ar nebūtų tada paprasčiau naudoti tinkamą įrankį darbui (tiesiog JavaScript)?

Dėl dinamiškumo: kaip paaiskintum tada dinamiškumą ir universaliskuma?

Prieš 7 minutes, gabber parašė:

Tai ir tavo supratimu PHP maziau dinaminis nes narsykles naudoja Javascript? Atsakymo nereikia, jus abu profesoriai 😂

Už JavaScript php mažiau dinaminis, nes jau ką jis atidavė į naršykle: nebepakeis. Be JavaScript patogiai nepadarysi, kad paspaudus mygtuką, keli papildomai formos laukai atsiranda. 

Pametem tema: kuom blogai apsišvietęs buvau, kad php client side rendering yra?

prieš 1 valandą, gabber parašė:

Prastai esi apsisvietes. Client-side (reiskia narsykleje) rendering'ui atlikti dazniausiai naudojami tam skirti JS lib'ai: vuejs, react, angular, etc. etc.

Cia reikes API REST serverio / back-end'o. Kad ir su PHP FW ji gali pasidaryti.

Bet ar php client side rendering atliks? :D nelabai, dėl to ir sakau, kad php client side rendering nepadarysi :D O su kuo tu tuos duomenis paduosi I naršyklė skirtumo nėra, nes renderins juos vistiek jau javascript

Prieš valandą, gabber parašė:

Bus ir toks, ir toks, kokio tik nori renderingo.

jeigu Php naudoji, labai abejoju kad client side rendering gausi. Php juk server sided language yra 😄