Navigacija

Vartotojų tinkle

Prisijungusių svečių: 115
Prisijungusių narių: 0
Prisijungusių narių nėra

Registruoti nariai: 25,956
Naujausias narys: saulyzas

Naujausi straipsniai

Paskutiniai nariai

saulyzas 4 dienos
MaFetas 6 dienos
TOMIJUS 1 savaitė
ozzWANTED 1 savaitė
Reikalas10 savaitės
Jaunelis17 savaitės
lanis17 savaitės
And2s18 savaitės
Memento Mori23 savaitės
Quwqkibor25 savaitės
asirija29 savaitės
tomeem31 savaitės
weberiz34 savaitės
mRokass37 savaitės
kartoonas38 savaitės
grunskiz40 savaitės
Bruksnys41 savaitės
illusion41 savaitės
ordo42 savaitės
Jurgaila43 savaitės

Informacija:


OS: Unknown
Naršyklė: Nežinoma
IP: 3.17.75.138
Naujienų: 529
Straipsnių: 235
Temų: 52,588
Postų: 522,537
Postų pask. parą: 0
Shout'ų pask. parą: 0
P.S.C. pask. parą: 0
Nuorodų kataloge: 13

Lankomumo Statistika

Peržiūrų šiandien: 22

Iš viso peržiūrų: 22948724

Prisijungti

REGISTRUOTIS
Nario vardas

Slaptažodis



Pamiršai slaptažodį?
Paprašyk naujo

Aktyvuoti save

Šaukykla

Jei norite rašyti žinutes, turite prisijungti.

MaFetas
2024 Lap. 13 22:11:57
hey how, geras dar veikiantis saitas?

Jaunelis
2024 Lie. 25 11:07:43
Oho vis dar veikia svetainė akinanti šypsen Šimtas metų, matau Šaukykloje nuostalgija. Smagu panaršyt po forumą ir pažiūrėt senas temas šypsosi

And2s
2024 Lie. 17 19:07:04
2008 pirmą kart čia patekau, man buvo 10m ir čia pramokau programavimo.. smagu skaityti senas žinutes, tokia nostalgija akinanti šypsen ačiū Ozz kad saugoji šitą kultūrinį reliktą šypsosi

ozzWANTED
2024 Sau. 17 01:01:00
Desperatiškus komentarus šaukykloje su accountu po mėnesio prasibuvimo, ištryniau. Pasaulis ir taip juodas. Įjungiam šviesą, prašviesės. šypsosi

Majakas
2023 Gru. 10 19:12:39
Negaliu patikėti jog žinutės/pranešimai visi yra nuo 2008 m akinanti šypsen

Šaukyklos archyvas

Apklausa

Ar esate patenkinti lietuviško vertimo kokybe?

Taip!

Taip, bet yra ką taisyti (parašysiu komentaruose)

Ne

Norėdamas balsuoti turite prisijungti.
Archyvas
Reklama 400x60
PHP-Fusion ateitis
Forumas | PHP-Fusion, WordPress, Shopify, PHP ir MySQL (PROGRAMAVIMAS) | Bendri PHP-F klausimai

Autorius: mirkus Peržiūrų: 13208      Spausdinti temą
2017 Spa. 21 00:10:54          1 žinutė iš 21
Spausdinti pranešimą
Parašiau chat'e tokią žinutėlę, bet atrodo, jog simbolių limitas užsimetė. Sakyčiau, čia yra bug'as šitame saite. Jeigu limituojate žinutės ilgį, turėtų būti aiškiai tas nurodyta. Tą galima padaryti metant error'ą arba tiesiog nukerpant tekstą, t.y. neleidžiant daugiau rašyti. Kaip patogiau, bet iš UI/UX pusės tai gaunasi visiškas fail'as šioje vietoje.

O šiaip man įdomu, kaip PHP-Fusion gali turėti kažkokią ateitį apskritai. Ar yra vizija kažkokia? Jeigu taip, tai kokia? Kiek suprantu, dabar fusion'as skirtas paprastiems user'iams, kurie nenori vargti kurdamiesi saitą. Tai tas neblogai yra visai. Susimeti failus į servą, paleidi 'install.php' (anksčiau, kiek pamenu, buvo 'setup.php', bet principas tai tas pats) ir viskas įsirašo. Bet va yra toks dalykas - jeigu user'is yra visiškai neišmanantis, kaip naudotis hostingo teikiamais privalumais, jis iki susimetimo step'o net neprieis. Bet jis nori turėti saitą. Ir samdys kažką, kas jam įmes tą saitą ir suinstalins.

Tai va šioje vietoje galima eiti toliau. Sakykime, sukurti kokį nors apps'ą (kad ir ant Qt parašytą, jog būtų cross-platform), kuris automatiškai prisijungia prie user'io nurodyto FTP servo, sumeta fusion'ą ir jį įrašo. Tai yra, user'is labiau nori viską pasidaryti vienu click'u be ėjimo per krūvą step'o. O po to jau turėti saitą ir jį pasikonfiginti per adminkę be jokių error'ų.

Tačiau situacija apie PHPF dabar. Deja deja, bet jį developina visiški lameriai arba žmonės, kurie šiaip mėgsta užsiimti opensourceingu, bet nėra tikrieji pro developeriai. Tikėtina, pastarieji turbūt ir palaiko šitą TVS.

Tada kyla kitas klausimas. O kas lems, jog, augant user'io, norinčio saito, verslui, jis ir toliau liks su fusionu? Kodėl jam nebus geriau investuoti pinigus į kitą sistemą, kuri būtų patikimesnė? Va čia PHP-Fusion ir fail'ina, nes visiškai ignoruoja verslo logiką, scale'inimąsi.

Tada apibendrinant viską. Fusion'as, atrodo sugeba atsitiktinai eiti gera linkme. Bet reikėtų daugiau aiškumo, tikslingumo ir konkretumo. Jeigu tas būtų, tai tada fusion'as turbūt ir nemirs. Kitaip sakant, trūksta šių dalykų dabar fusion'e:
1. Abstraktaus duomenų bazės sluoksnio. Net ir dabar PHP-Fusion sugeba palaikyti tik MySQL. Tai yra riba, kurią reikėtų apeiti. Rimtas CMS'as turi sugebėti palaikyti bent kelias labiausiai naudojamas šiuo metu duomenų bazes.
2. Resursų kūrimo ir nuskaitymo variklis. Dabar atrodo, kad vienintelis išorinis resursas fusion'e - paveiksliukai. Bet realiasi tai gali būti bet kas, tad nereikėtų apsiriboti vien tik image'ais.
3. Migracijos variklis. O čia rimtai svarbu. Sakykime, naudoju Wordpress ir svarstau pereiti prie fusion'o. Ką man daryti, kad visus duomenis iš wordpress'o permesčiau į fusion'ą? Na rankutėmis viską perkelti turbūt... O kodėl to neina automatizuoti?

Taip kad fusion'as turi kur tobulėti, ir kryptys tobulėjimui aiškios. Jeigu tos kryptis bus įgyvendintos, fusion'as ateitį turės. Kitu atveju bus mirtis.

2017 Spa. 22 22:10:19          2 žinutė iš 21
Spausdinti pranešimą
mirkus parašė:
Net ir dabar PHP-Fusion sugeba palaikyti tik MySQL.


Nuo v9 palaiko PDO ir MySQLi.
2017 Spa. 22 22:10:35          3 žinutė iš 21
Spausdinti pranešimą
ewl parašė:
<...>

Nuo v9 palaiko PDO ir MySQLi.

Tas vis tiek nekeičia situacijos. PDO yra tik PHP lib'as kaip abstrakcija naudoti duomenų bazę. Kaip tai buvo "mysql_* and friends", taip vietoje to atsirado aukštesnio lygio abstrakcija. Ir gerai, kad PHP-Fusion tą ėmė naudoti. O va MySQLi support'as nėra kažkas wow, nes tai yra tas pats MySQL veikiantis kaip extension'as, skirtas quer'inti... MySQL'ą... Kita vertus, žiūrint iš kodo, tai chebra ten tiesiog sumetė tą abstrakciją, bet paliko tas pačias užklausas nepasirūpinę, jog atsirastų kažkoks tai interfeisas ORM'ui, kas jau įgalintų bent jau pradėti rašyti ORM'o implementacijos engine'us ir plėsti PHP-Fusion galimybes palaikyti ne tik MySQL, bet ir ką nors daugiau. šypsosi

Va tarkim būtų pasikeitimas, jeigu PHP-Fusion turėtų tokį core'ą, jog būtų įmanoma parašyti driver'į, pavyzdžiui, kokiam Raven DB. Tiesiog tai yra NoSQL'inė DB, kuri yra greita ir paprastam saitui nėra problemos to naudoti. Bet Raven DB turi kitų privalumų, susijusių su tam tikrų užduočių vykdymu. O dar geriau būtų, jeigu apskritai būtų įmanoma vienu metu naudoti kelias duomenų bazes. Sakykime, man niekas nedraudžia pakurti MySQL, Raven DB ir dar kokį Postgre SQL ant to paties servo. Ir gal aš matau prasmę visas šis DB naudoti skirtingoms užduotims atlikti? Ir va norėčiau, jog man užtektų PHP-Fusion utilizuoti visam tam funkcionalumui.

Tad iš esmės kryptis fusion'ui, kurią matau, tai jam reikėtų tapti framework'u, kuris dalinai implementina ką reikia, jog būtų galima pasileisti saitą. Va, licencija padori yra, trūksta tik turbūt vizijos jiems iš šito reikalo išspausti totalų maksimumą.
2017 Spa. 23 01:10:57          4 žinutė iš 21
Spausdinti pranešimą
Per gyliai mastai.
2017 Spa. 23 20:10:20          5 žinutė iš 21
Spausdinti pranešimą
Labas vakaras
aišku mirkus gera kritikuoti kitus, php-fusion sistema yra tai kas nestovi vietoje ir kiek vienas gali dirbti juk tai atviro kodo kūrinys. O tobulumui ribų nėra... tikiu, kad ką čia aprašei yra šios sistemos ateitis.

Pagarbiai: riomasmerkia akį

senas nikas riomas
2017 Spa. 26 14:10:39          6 žinutė iš 21
Spausdinti pranešimą
MySQL'as yra puiki duomenų bazė su savo MariaDB alternatyva. WordPress'as labai puikiai argumentavo, kodėl visokie heavy-weight ORM'ai iš esmės neturi prasmės, o dar ir nesaugūs yra:
https://codex.wordpress.org/Usin..._Databases
Tas pats ir Fusion'ui galioja. Į šį tinklapį aš žiūriu pirmiausia kaip į programuotojų ir dizainerių bendruomenę. Ir viskas galiausiai susiveda į finansus, t.y. norėjimą investuoti bent jau 20,000 EUR į tai, kuo tiki. Aš tikiu šiuo portalu. Kaip tikiu, kad ir Fusion'as su tinkamomis investicijomis turi parako ir potencialo. Ir aš tikrai turiu planų investuoti į tai. Aš netikiu Facebook'u (kuris dabar jau net Food Ordering'o servisą pristatė), netikiu ir Google'u. Ir manau yra labai daug žmonių pasaulyje, kurie nori tam priešintis. Tad tikrai yra perspektyvų. O kalbant apie Licenziją, kaip ir minėjau, Php-Fusion licencija yra kur kas geresnė ir tinkamesnė komercijai, nei kokio WordPress'o. Ir WordPress'as savo GPLv2 tikrai nekeis, nes licencija, iš esmės yra visko pamatas, pradmuo.

BR#1, Most Wanted
2017 Spa. 31 21:10:00          7 žinutė iš 21
Spausdinti pranešimą
ozzWANTED parašė:
MySQL'as yra puiki duomenų bazė su savo MariaDB alternatyva. WordPress'as labai puikiai argumentavo, kodėl visokie heavy-weight ORM'ai iš esmės neturi prasmės, o dar ir nesaugūs yra:
https://codex.wordpress.org/Usin..._Databases
Tas pats ir Fusion'ui galioja. Į šį tinklapį aš žiūriu pirmiausia kaip į programuotojų ir dizainerių bendruomenę. Ir viskas galiausiai susiveda į finansus, t.y. norėjimą investuoti bent jau 20,000 EUR į tai, kuo tiki. Aš tikiu šiuo portalu. Kaip tikiu, kad ir Fusion'as su tinkamomis investicijomis turi parako ir potencialo. Ir aš tikrai turiu planų investuoti į tai. Aš netikiu Facebook'u (kuris dabar jau net Food Ordering'o servisą pristatė), netikiu ir Google'u. Ir manau yra labai daug žmonių pasaulyje, kurie nori tam priešintis. Tad tikrai yra perspektyvų. O kalbant apie Licenziją, kaip ir minėjau, Php-Fusion licencija yra kur kas geresnė ir tinkamesnė komercijai, nei kokio WordPress'o. Ir WordPress'as savo GPLv2 tikrai nekeis, nes licencija, iš esmės yra visko pamatas, pradmuo.


Gal galima plačiau dėl tos licenzijos? Koki jinai čia vaidmenį atlieka?

Kas dėl ateities. Tai tiesiog pavėlavo smarkiai su ta nauja versija. Kaip konkurentai jau pralenkė, net pats WP pristatė visiškai naują platformą: https://developer.wordpress.com/... o ką fusionas per ta laiką padarė? iš MySQL* perėjo į PDO? Pasižiūrai į https://github.com/php-fusion/PH...incore.php arba https://github.com/php-fusion/PH.../print.php tai net šiurpas nukrečia, dabar dauguma nauji CMS, sukasi ant frameworkų, kas yra visiškai suprantama. Kodas tvarkigas, daug lengviau maintaininti ir pnš. O čia gauni spagheti code. Ir poto stumia, kad PHP prasta programavimo kalba, nes visur aplinkui visokie bad practises. Smagu, kad ji dar maintainina (PHP-Fusion), bet manau reiktu jau jį apleisti po mažu arba daryti kažką visiškai naujo, bet čia daug darbo ir neverta gaišti laiko tam, vis tiek kažko naujo ir revoliucingo nepasiūlys..

Kas dėl portalo tai biški gaila, kad apmirė, nes čia tikrai nebloga būtų programuotojų ir dizainerių bendruomenė, bet reiktu keistis iš esmės, perdaryti į forumą.


Redagavo Žmogus 2017 Spa. 31 21:10:24
2017 Lap. 1 03:11:52          8 žinutė iš 21
Spausdinti pranešimą
Dėl licenzijos. Esmė ta, kad WP yra išleistas ant GPL. O GPL sako, kad taip, tu gali sukurti kitam asmeniui komercinį produktą / tinklapį, ir neprivalai dalintis su visais tuo (EXCEPT if you are going to distribute it). Vat būtent ta EXCEPT yra ir yra didžiausia bėda. Jeigu nori savo sukurtą produktą ar whatever platinti (ne parduoti vienam klientui) už pinigus pvz. 1000-ančiui, tu to daryti pagal GPL negali, t.y. privalai į WordPress.org įkelti pvz. tą savo THEME. Kai tuo tarpu Php-Fusion'as V9 net ir pats "Native" turi mokamus pluginus / themes savo tinklapyje, papildomai prie nemokamų. Ir tai galbūt dabar nėra tokia didelė bėda, kol į šitą faktą yra žiūrimą pro pirštus, bet apie tai yra kalbama, ir licenzijos bėdos, kaip žinia ištinka kai tampi labai populiarus, top-selling, tada kažkas gali pradėti rašyti straipsnius, ir pradėti daryti spaudimą, tada kokia ES agentūra imtųsi didelio tyrimo ir t.t., ir gali paliepti open-sourcint'i. Kaip va neseniai JAV teisėja liepė vienai IT įmonei, kuri daro DNR tyrimus. Tiesa, ten dėl pačio DNR algoritmo tikrumo, bet precedentas yra. Todėl tu gerai pagalvoti turi apie savo verslo modelį prieš priimant sprendimus. Ar 'problemos' atveju ruošiesi PATS parašyti naują CMS'ą ar Framework'ą (t.y. 'Version without WordPress' ir spręsti visokius autentifikacijos, o svarbiausiai rinkos patikimumo klausimus), ar pasiimsi kokį CMS'ą su tinkama licencija, kuris maitaininamas, žinomas jau 15 metų, turėjęs šlovingų dienų praeityje, ir savo paskirtimi iš esmės panašus (WP+bbPress+BuddyPress = Php-Fusion). Fusion'o, nežinau, neigiamas ar teigiamas dalykas yra tai, kad forumas ir user-messaging nėra kaip pluginai. Jeigu būtų, tai galbūt blogai tuo, kad visad turėtum tikrinti ar tokia funkcija įjungta, būtų sudėtinga kitką kabinti ir t.t.
Bet, kaip ir minėjau, šitas Forumas dar 2007 metais išėjo už Php-Fusion'o, ir net už programavo ribų, ir apima visą e-commerce stack'ą - programavimą, interneto verslus, web-dizainą, reklamą. Akcentas programavimas be abejonės, jaunųjų programuotojų mokymas. Ir pats portalas savo realizacija (naujienos, straipsniai, forumas, chat'as) ir visa kita yra tikrai geri sprendimai ir jie puikiai tinka ir šiomis dienomis, tik jie parašyti 10-11 metų senumo technologijomis, o user-interaction šiuo metu kiek inovatyvesnis. StackOverflow'as labai gerai daugelį klausimų išsprendė, ypač su Ajax'u. O ir dalykai skiriasi - pabandyt įtakoti WordPress raidą vienas žmogus nelabai jau gali, tai kaip korporacija kokia, tik kad opensource. O štai Php-Fusion'ą gali net ir labai smarkiai. Tik turi žinoti ko jis siekia.

BR#1, Most Wanted
2017 Lap. 4 14:11:39          9 žinutė iš 21
Spausdinti pranešimą
Sutinku ,kad si bendruomene buvo pradejusi plestis uz php-fusion ribu, kas man labai patiko. Tai koks dabar planas laukia sio projekto? Noreciau kazkaip prisidet prie atgaivinimo šypsosi
2017 Lap. 4 21:11:45          10 žinutė iš 21
Spausdinti pranešimą
Tie laikai, kai investuotojai dalina pinigus praėjo. Jeigu jie išvis kada buvo, nors gal ir buvo kurį laiką, kokiam Silicon Valley. O visur kitur tai ką gali gauti lengviau tai banko paskolą verslui, kurią reikės grąžinti. Tai tikrai nėra gera idėja, tai ne lizingas automobilio ar ofiso patalpų pirkimas. Tad vienintelis logiškas sprendimas yra dėti savo lėšas, nepaisant to ar programuosi kažką ar neprogramuosi. Be 20,000 EUR'ų šiais laikais nieko nepadarysi. Tad tuos pinigus reikės įdėti bet kuriuo atveju. Jeigu esi sukaupęs santaupų, tiki šiuo projektu, gali padaryti savo bent 5,000 EUR įmoką, kaip savo dalį, tada parašyk į gamespot TŠK ltu GMAIL'ą. Jeigu nori programuoti metus - irgi gali parašyti, bet turi suprasti, kad bet kuriuo atveju vis vien kažkas turės įnešti pinigus - kitu atveju tai tik vaikų fantazijos. Dar kitas dalykas, prisidėdamas prie komandos turi atsisakyti per didelių ambicijų, ir nerealių vizijų. Aš, Creatium, ar kuris kitas co-founderis visad išklausys į protingas mintis ar pasiūlymus, bet turi suvokti, kad toks projektas pirmiausia yra filantropija, kurio esminė nauda yra politika, reputacija, pažinčių tinklas, o ne finansinė grąža.
Kitiems metams turime įvairių idėjų. Bet jokių pažadų čia nedalinsiu. Beje, investavimas liečia visus be išimties. Vadinasi savo laiku ir man savo lėšas taip pat reikės įdėti. Dėl to, kad aš tikiu šiuo projektu, ir jo vizija. Ir kiekvieną dieną matydamas pyktį kylantį žmonių prieš Facebook, prieš Microsoft'ą, kuris dabar dar ir Linked'ą su Outlook'u apjungė, tikrai žmonės vis labiau pradeda rūpintis savo gyvenimo kokybe ir gerbti privatumą. Žmonės nebenori, kad korporacijos joms diegtų į galvas, už ką balsuoti, su kuo susiconnectinti, kas geras o kas blogas. Stackoverflow'as irgi nudegė. Užvakar buvo straipsnis TC'e, kad jie 20% layoffiną darbuotojų, iš esmės visus 3rd party hiringo servisus, nes vos nepaklydo, kas jie yra - ar dev community, ar hiring'o platform'a pilna reklamos, tad jie grįžta prie savo ištakų.

Ir man labai nepatinka tas žodis 'gaivinimas'. Gaivina tuos kurie negali egzistuoti be pinigų, užsidaro ir pan. Su bendruomenėmis, yra kiek kitaip - tai iš esmės labiau žengimas su tų dienų technologijomis, inovacijomis ir poreikiais.

Ir kai kalbu ten apie 20,000 EUR'ų, tai kalbu apie mažiausiai, kad apskritai kažkas pasikeistų. Tikrai galima ir 100,000 EURų sudėti be jokių didesnių problemų. Tad visad reikia suvokti savo ambicijų dydį, kas realu, o kas ne. Mačiau ne vieną projektą, kur ir 30 milijonų ES lėšų sudegino pilotiniams projektams. O čia veikianti, egzistuojanti ir žinoma bendruomenė su daugiau nei 10 metų istorija. Tad žengti žingsnį ten, kur 10 metų kapitalas yra, yra daug lengviau nei pakeisti pasaulį su pilotu.

BR#1, Most Wanted
2017 Lap. 7 15:11:46          11 žinutė iš 21
Spausdinti pranešimą
Tokiam CMS'ui kaip fusion'as geriausia licencija būtų "The Unlicense ". šypsosi
2019 Rugs. 20 17:09:06          12 žinutė iš 21
Spausdinti pranešimą
Tai kas pasikeitė per 2 metus php-fusion pasaulyje?
2019 Spa. 14 18:10:17          13 žinutė iš 21
Spausdinti pranešimą
Seni geri php-f laikaišypsosi)

2020 Vas. 9 10:02:55          14 žinutė iš 21
Spausdinti pranešimą
Tikriausiai niekas akinanti šypsen sena gera tvs bet d4ja 6iomis dienomis jau pasenusi ir nepasi8lo to ko reikia 6iomis dienomis

Uždarbis internete: https://uzdarbisinternete.lt
2021 Vas. 2 14:02:17          15 žinutė iš 21
Spausdinti pranešimą
Gal ir pavėluotai, bet pastebėjimai ir dabar aktualūs.

Dėl ORM argumentai, sakyčiau, silpnoki. Jeigu netinka esami abstrakciniai layeriai, tą galima pasirašyti ir patiems (WP, kiek suprantu, kažkokį layer'į ir naudoja, tik kur kas paprastesnį, kas nebūtinai yra blogai). Jeigu pasiūlys kažką light-weight, paprastesnio, bet saugaus ir veikiančio, tai tą daug kas ir naudos. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas.

ORM layerio paskirtis yra tiesiog užsitikrinti pakankamą abstrakcijos layer'į, kuriame būtų galima kurti entities klases su tipizuotais laukais, taip pat pateikti savo custom filtrus, pritaikytus būtent dalykinei sričiai. Iš jų po to gauname entities klases, repozitorijas, dar controllerius. Patiems visa tai apsirašyti užtruktų nemažai laiko, todėl tas mums padeda sutaupyti laiko. Jeigu layeris failina paprastuose dalykuose, tai čia yra ne idėjos problema, o tiesiog "poor implementation details". Pavyzdžiui, Doctrine tikrai galėtų suimplementinti protingesnį insert'ą SQL'ui su didesniu kiekiu duomenų apart šaudyti po vieną insert'ą, dėl ko skundžiasi beveik visi per stackoverflow, kas su tuo susidūrė.

Gal su ORM problema, kurią galima būtų pastebėti, yra tai, kad jie bando sukurti abstrakciją tiek užklausoms, tiek migracijoms, t.y. bando būti šveicarišku peiliu. Bet čia jau problema kaip ir visur. "Kas tinka viskam, tas netinka niekam". Galbūt protingiau būtų atskirti visus ORM'us į tris dalis - duomenų logikos sukūrimas, duomenų logikos naudojimas ir duomenų logikos migracija. Bet klausimas, ar tai patiks programuotojams.

Pats PHP eina labai geru keliu išties. Turi Composer, patys 3rd party libai daugumoje yra labai "lousely coupled", gal net labiau nei kokiame C#. Ir tas yra puiku, nes tai rodo, kad didelę dalį problemų galima išspręsti rašant geresnius libus. Man su PHP kas patinka, tai kad užtenka susikurti Composer projektą ir jau gali susibuildinti norimą frameworką vien iš libų. Retai kur tokį dalyką pamatysi - ten iškart turi pasiimi "core boilerplate" kodą ir ant jo mėginti kažką lipdyti.

Galutinis klausimas. Pamenu, šis puslapis turėjo krūvas lankytojų kažkada. Ir nemaža dalis jų buvo norintys prisidėti prie bendruomenės plėtros savo lygyje. Kur jie visi dingo dabar?
2021 Vas. 18 18:02:51          16 žinutė iš 21
Spausdinti pranešimą
programuotuvas parašė:
Gal ir pavėluotai, bet pastebėjimai ir dabar aktualūs.

Dėl ORM argumentai, sakyčiau, silpnoki. Jeigu netinka esami abstrakciniai layeriai, tą galima pasirašyti ir patiems (WP, kiek suprantu, kažkokį layer'į ir naudoja, tik kur kas paprastesnį, kas nebūtinai yra blogai). Jeigu pasiūlys kažką light-weight, paprastesnio, bet saugaus ir veikiančio, tai tą daug kas ir naudos. Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas.

ORM layerio paskirtis yra tiesiog užsitikrinti pakankamą abstrakcijos layer'į, kuriame būtų galima kurti entities klases su tipizuotais laukais, taip pat pateikti savo custom filtrus, pritaikytus būtent dalykinei sričiai. Iš jų po to gauname entities klases, repozitorijas, dar controllerius. Patiems visa tai apsirašyti užtruktų nemažai laiko, todėl tas mums padeda sutaupyti laiko. Jeigu layeris failina paprastuose dalykuose, tai čia yra ne idėjos problema, o tiesiog "poor implementation details". Pavyzdžiui, Doctrine tikrai galėtų suimplementinti protingesnį insert'ą SQL'ui su didesniu kiekiu duomenų apart šaudyti po vieną insert'ą, dėl ko skundžiasi beveik visi per stackoverflow, kas su tuo susidūrė.

Gal su ORM problema, kurią galima būtų pastebėti, yra tai, kad jie bando sukurti abstrakciją tiek užklausoms, tiek migracijoms, t.y. bando būti šveicarišku peiliu. Bet čia jau problema kaip ir visur. "Kas tinka viskam, tas netinka niekam". Galbūt protingiau būtų atskirti visus ORM'us į tris dalis - duomenų logikos sukūrimas, duomenų logikos naudojimas ir duomenų logikos migracija. Bet klausimas, ar tai patiks programuotojams.

Pats PHP eina labai geru keliu išties. Turi Composer, patys 3rd party libai daugumoje yra labai "lousely coupled", gal net labiau nei kokiame C#. Ir tas yra puiku, nes tai rodo, kad didelę dalį problemų galima išspręsti rašant geresnius libus. Man su PHP kas patinka, tai kad užtenka susikurti Composer projektą ir jau gali susibuildinti norimą frameworką vien iš libų. Retai kur tokį dalyką pamatysi - ten iškart turi pasiimi "core boilerplate" kodą ir ant jo mėginti kažką lipdyti.

Galutinis klausimas. Pamenu, šis puslapis turėjo krūvas lankytojų kažkada. Ir nemaža dalis jų buvo norintys prisidėti prie bendruomenės plėtros savo lygyje. Kur jie visi dingo dabar?


Kažką, kolega, maišot su ORM ir dideliai insertais, ORM ne tam skirtasmerkia akį
2021 Bal. 9 23:04:23          17 žinutė iš 21
Spausdinti pranešimą
Žmogus parašė:
<...>

Kažką, kolega, maišot su ORM ir dideliai insertais, ORM ne tam skirtasmerkia akį

Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai.
2021 Spa. 2 08:10:15          18 žinutė iš 21
Spausdinti pranešimą
Tai kas gero nutiko su php-fusion per tiek laiko? Matau, kad githube yra branch "Andromeda", galvojau, kad bus kažkas įdomaus. Bet still spagheti code... https://github.com/PHPFusion/PHP.../print.php

P.S. kas čia? Konkurentai šito portalo? http://www.phpfusion.lt/news.php

programuotuvas parašė:
<...>
Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai.


Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas.


Norėčiau šaltinio apie ORM ir mass insert

2021 Spa. 29 20:10:23          19 žinutė iš 21
Spausdinti pranešimą
Žmogus parašė:Tai kas gero nutiko su php-fusion per tiek laiko? Matau, kad githube yra branch "Andromeda", galvojau, kad bus kažkas įdomaus. Bet still spagheti code... https://github.com/PHPFusion/PHP...

Jie net branch'ams pavadinimus teikia kažkokius keistokus, o ne pagal nusistovėjusius standartus. Tad ar galima tikėtis normalaus kodo ten? Visgi čia tik vienas failas, ar ne? Gal jie kitur ten šaudo nerealius refactoring commit'us? Nelabai: https://github.com/PHPFusion/PHP...6329b7ee27 . Tiesiog jie išsitraukia kažkokius singleton'us, po to juos naudoja, kad parašytų utility funkcijas, kurias patys po to naudoja. Ir taip lipto antipattern'us ant antipattern'ų. Visgi gal tik čia taip negražiai? Na ne, panašu, tai yra tendencinga. Pvz čia maišomi concern'ai: https://github.com/PHPFusion/PHP...91ff06b194 . Ne paprasčiau būtų tiesiog naudoti kokį views'ą, kuris neturėtų jokių sąlygų, o po to jau logikoje atfiltruoti duomenis, kuriems tas views'as būtų pritaikytas (t.y. MVC, MVP, MVVM pattern'ai).

programuotuvas parašė:
<...>
Siūlau dar kartą paskaityti. Kažko apie ORM ir didelius insertus aš nieko kaip ir neakcentavau konkrečiai.


Pvz man nepatinka Doctrine, jog, norint padaryti didelį insert'ą į DB, reikia arba rašytis savo užklausą, arba šaudyti po vieną insert'ą, kas yra tiesiog neefektyvu ir neatitinka tos idealogijos, kuriam šis persistence layeris ir sukurtas.


Norėčiau šaltinio apie ORM ir mass insert

Na ten nieko ypatingo nerašiau, tiesiog manau, kad Doctrine kūrėjai labiau galėjo pasistengti su transakcijų optimizacija. Nes ką reiškia transakcija? Iš esmės išeina, kad tu pirma suformuoji užklausų paketą, o po to jį commit'ini, t.y. nurodai vykdyti. Tai Doctrine bent tuo metu, kai teko juo naudotis (tas buvo kažkur prieš 6mėn, nes mano stack'as kiek kitoks yra, tad galiu ir klysti), tai multiple insert'us tiesiog šaudo po vieną, o ne sudeda, pavyzdžiui, optimizuojant pagal duomenų bazės tipą. Pvz MySQL galima taip daryti:
INSERT A1
INSERT A2
arba, jeigu A1 ir A2 toje pat lentelėje randasi ir naudojami stulpeliai sutampa: INSERT A1, A2.




Aišku, galima stumti ant to fusion'o, kiek tik norime, galima tam ir galo nematyti, bet siūlyčiau pastebėti kelis dalykus. Ir jie labai paprasti:
1. PHP-Fusion pirmą versiją parašė žmogus, kuris pasivadino Nick Jones, Digitanium jo slapyvardis buvo. Tuo metu tai buvo tikrai fenomenalus programuotojas, iš kurio ir pats daug išmokau. Deja, jis mirė. Tad neliko pagrindinio šios idėjos kūrėjo dar tuomet, kai jis nebuvo perdavęs šios idėjos kažkam kitam. O ir fenomenalumas yra labai reliatyvus dalykas. Dabar tai vadiname spaghetti code, tada tai buvo superinis kodas, nes kiti rašė dar tragiškiau. Tas žmogus sugebėjo vos per kelias dienas perrašyti bug'ovą messages.php faile esantį kodą, kai pamatė, kad yra beviltiška ten lopyti visas spragas. Ir ne tik perrašė, bet ir išreleas'ino. Tai, mano manymu, yra neblogo developer'io bruožas. Kitas ten burtų apie mėnesio projektus, darytų krūvas meeting'ų, o tas tiesiog padarė darbą ir ramu buvo.

2. PHP-Fusion atsirado dar 2003 metais, jeigu ne dar anksčiau, nes aš pamenu, kad 2004 metais tai jau buvo kokia 5 ar 6 versija. Ir kiek matau github'e, yra kodo dar dabar iš 2003 metų. O to kodo ir tada buvo tūkstančiai eilučių. Nejau realu tikėtis, kad tokį kodą, kuriam beveik 20 metų, įmanoma vien open source iniciatyva išrefactor'inti? Aš tai abejočiau tuo, nes refactor'inimas yra juodas darbas, neretai ir ten, kur mokami pinigai, renkamasi geriau viską rašyti nuo nulio negu taisyti kodą, kuris jau kaip giltinė reikalauja grąžinti visas gyvenimo skolas.

3. https://github.com/PHPFusion/PHP...ntributors - kiek žmonių PHP-Fusion develop'ina. 38. Tai nėra daug, bet ir nemažai. Ar jie kažką tarpusavy derinasi, turi kassavaitinius meeting'us? Na ne. Ir kas tie žmonės? Kiek matau, tai nėra high level developer'iai. Didžioji dalis net nepraeitų atrankos ten, kur pats dabar dirbu, jeigu ne visi iš jų.

Tad, kaip ir minėjau, galima stumti kiek nori, bet PHP-Fusion tiesiog dabar neturi jokių sąlygų būti išgelbėtas. Norint išgelbėti tokį framework'ą reikėtų monstriškų pastangų. O visi rimti developer'iai šiandien, deja, to laiko turi labai mažai. Kaip ir aš pvz. Kada čia galiu prisijungti? Vos kartą per pusmetį ar rečiau netgi. ir taip yra, nes darbų belekiek. Atrodo, renkiesi tuos darbus, esi išrankus, bet vis tiek jie tave vejasi ir tik retkarčiais atsiranda daugiau laisvumo.

2023 Geg. 26 20:05:29          20 žinutė iš 21
Spausdinti pranešimą
Susitvarkytum kapitalą asmeninį, pasyvias investicijas, tai ir to laiko atsirastų. Jeigu neatsiranda, vadinasi yra viduje problemų tavo gyvenime (nesakau, kad man geriau). Bet jeigu gyvenime esi patyręs, laisvo laiko tikrai turėtum.

BR#1, Most Wanted
Peršokti į forumą: