Jump to content
php.lv forumi

16 PHP Frameworku īss apskats


Aleksejs

Recommended Posts

Šobrīd ņemos ar Zend Framework.

 

Jo vairāk ņemos, jo vairāk tas patīk. Priekš tam gan taisu arī atbilstoša līmeņa projektu ar vīziju ilgam laikam uz priekšu.

 

Uzskatu, ka ir ļoti muļķīgi norobežoties no freimworkiem tikai dēļ tā, ka sarežģīti, vai smagi, vai cik tur inclūdes.. katrs freimworks risina noteiktu problēmu loku, kādam Symphony būs tieši laikā, kādam vajadzēs kaut ko radikāli citu. Taču visiem piemīt īpašība, ka izplatīto problēmu risināšanai tiek piedāvāts ļoti pārdomāts risinājums, kas ir sistematizēts freimworka ietvaros. Ja plaši izplatīts freimworks nepatīk vai izsauc riebumu, tad visdrīzāk, tas nav piemērots risināmajai problēmai. Ļoti cerams, ka tas nav dēļ aizkavēšanās novecojušos stereotipos vai sīkklientiem, kuri nomoka ar mikrowebiem, vai, nedod dievs, bailēm no OOP..

 

Un paldies par sarakstu, interesanti!

Link to comment
Share on other sites

  • Replies 48
  • Created
  • Last Reply

Top Posters In This Topic

Šoriez jautājumā tieši par ZF piekritīšu Java teiktajam. ZF ir mēģināts nospiest no visa kā - sākot no 'enterprise valodām' un beidzot ar rails (kas būtībā ir diametrāli pretējas pieejas), bet tajā pašā laikā tajā brīnumā nav nekā unikāla, jauna, vienīgi ZF esoša fēča. Tāda visam kam domātu, no visa kā salasītu bibliotēku glabātuve php jau ir(bija), saucas pear, bet pear ir apaudzis ar depenzijām tā, ka tagad skaitās slikti izmantot. Izskatās ka ZF iet tieši pear pēdās. rip.

Link to comment
Share on other sites

Šobrīd ņemos ar Zend Framework.

 

Jo vairāk ņemos, jo vairāk tas patīk. Priekš tam gan taisu arī atbilstoša līmeņa projektu ar vīziju ilgam laikam uz priekšu.

Nu ļoti interesanti, ko tu, piemēram, tādu taisi uz to ZendFramework? Kas ir tāds, ko taisīt uz ZendFramework būtu ja ne labākais risinājums, tad vismaz viens no labākajiem? Vari to paskaidrot, protams, ar abstrakcijām, bet lai būtu tomēr kāds konkrēts pamats no reālās dzīves.

 

Uzskatu, ka ir ļoti muļķīgi norobežoties no freimworkiem tikai dēļ tā, ka sarežģīti, vai smagi, vai cik tur inclūdes.. katrs freimworks risina noteiktu problēmu loku, kādam Symphony būs tieši laikā, kādam vajadzēs kaut ko radikāli citu. Taču visiem piemīt īpašība, ka izplatīto problēmu risināšanai tiek piedāvāts ļoti pārdomāts risinājums, kas ir sistematizēts freimworka ietvaros. Ja plaši izplatīts freimworks nepatīk vai izsauc riebumu, tad visdrīzāk, tas nav piemērots risināmajai problēmai.

Protams, viena problēma ir tos frameworkus mācīties. Tāpēc pirms kādu frameworku apgūt, vēlams veikt rūpīgu tā izvērtējumu, diemžēl "googlējot" ir atrodamas pārāk maz nopietnas, padziļinātas, daudzpusējas "frameworku" analīzes kā jau te izteicās, nevis "linkuliste"...

Bet principā, piekrītu, ka "frameworki" ir profesionāla pieeja - izmantot to, ko sagatavojuši ir citi profesionāļi, kas savā specifiskajā lauciņā ir krietni spēcīgāki. Tāpēc tikai normāli ir, ja "web frameworku" ir radījušas veselas profesionāļu komandas, kur katrs ir padziļināties specializējies savā lauciņā un vairāki vispārīgāki "arhitekti".

 

Ļoti cerams, ka tas nav dēļ aizkavēšanās novecojušos stereotipos vai sīkklientiem, kuri nomoka ar mikrowebiem, vai, nedod dievs, bailēm no OOP..

Lai arī php ir objektorientēta valoda, tomēr, manā uztverē, ne īsti pilnībā. Nepatīk fakti, ka OOP pamatiespējas tur ir iekļautas tikai sākot ar 5. versiju. Nedaudz kaitina arī absolūts "type safety" trūkums un neprecīzā (case-insensitive) sintakse, ieskaitot dolāru likšanu pirms katra mainīgā. Arī "error messaging" ir tāds, manuprāt, vairāk piemērots interpretējamai skripta valodai, nevis OOP valodai. Pārāk daudz "atvieglojumu" un arī vairums integrētās bibliotēkas nav "OOP bāzētas". PHP ir daudz fanu, bet neesmu daudz redzējis tādu nopietnu un objektīvu šīs valodas analīzi, jo interesanti, ka nopietnās programmēšanas valodu salīdzinošajās analīzēs PHP bieži vien pat nav iekļauts! ;) Protams, OOP ir iekļauts php valodā, bet tas izskatās tāds "pieaudzēts klāt", nevis nostādīts kā pamatprincips visai valodai (kā tam normāli vajadzētu būt OOP valodās).

Bet saku - pagaidām nepretendēju uz izcili objektīvi konstruktīvu PHP valodas analīzi.

Link to comment
Share on other sites

Šobrīd strādājot ar ZF, redzu, ka pie tā ir strādājusi komanda, kas labi apzinās risināmos jautājumus. Un tie ir labi atrisināti. Labi dokumentēti. Tik labi, ka 90% mana laika aiziet, izpētot to, kas jau ir, lai netērētu laiku, veidojot dublikātu. Ja tā nebūtu, izmantotu citu risinājumu. Ar to gribēju teikt, ka manā gadījumā risinājumam, kuru veidoju, ZF atbilst lieliski. Patiesībā es sākotnēji to vēlējos izmantot kā validātoru, maila un lokalizācijas bibliotēku, bet kad ķēros klāt menu u.c. standarta jautājumiem, vietā jau ir risinājums. Piemēram, abstrakcija - nodefinējot lapas struktūru, automātiski var ģenerēt menu listes, breadcrumbs, u.c. navigācijas elementus, kur jau ir integrēts translate un ACL. (Te es biju sarakstījis vairāk, bet ko nu daudz plātīšos...)

 

Man ir aizdoma, ka nozīmīgu devu ZF izveidē ir ielikuši Magento CMS veidotāji, spriežu pēc oficiālā paziņojuma par sadarbību.

 

Par pārējo varu tikai mazliet iesaistīties diskusijā par PHP OOP un mainīgo sintaksi. Man ZF kļuva daudz saprotamāks pēc tam, kad pastrādāju ar .NET frameworku. Pirms tam pat nesapratu, kā darbojas exceptions, bet tagad paradigma ir lauzta un sagaidu, ka ar 6 versiju PHP būs vēl labāk.

 

Pasaulē daudzas lietas ir ne pārāk racionālas, man pietiek ar to, ka tas ir Zend. Man nav dibena sildītāja, lai varētu mēnesi veltīt freimworku salīdzināšanai, risinu lietas no koncepcijas un dizaina līdz datubāzes optimizācijai, tāpēc īpaši nedomājot, ņēmu to, kam aizmugurē ir "strong advocacy". Mani neinteresē tas, vai valoda (vai datubāze) ir perfekta no teorijas viedokļa, mani piesaista tas, ka PHP ir veidots reālu jautājumu risināšanai. Droši ka izmantošu arī Java u.c. valodas, un datubāzes.

 

Piemēram, paturpinot tēmu par to, kādu problēmu risina katrs freimworks, bibliotēka utt. Smarty. Manuprāt, daudz apspriests un bieži nopelts, atzīts par pārāk smagnēju utt., taču tas ir ideāls priekš templeitiem, kurus var definēt lietotājs (HMTL dizaineris).. Protams, Smarty nav vajadzīgs programmai, kuras templeitus nekad neaiztiks dizaineris.. taču arī tad var izmantot pluginu u.c. priekšrocības. Bieži var novērot grūtības saskatīt saiti starp konkrētu vajadzību un konkrētu risinājumu, un notiek konkrēta risinājuma apspriešana no nekonkrētu vajadzību skatu punkta.. pie kam izvēloties izteikti nepiemērotas vajadzības un tad tīksminoties, cik slikts ir konkrētais risinājums.

 

Pastāstiet par savu konkrēto risinājumu konkrētai vajadzībai (kaut vai abstrahētai), tad varēs spriest, vai freimworks ir slikts, norakstāms, vai varbūt kļūda ir pašā saknē, nepareizi izprotot risināmo jautājumu.

Edited by Mr.Key
Link to comment
Share on other sites

Runājot par ZF vēl - tur papētot visas tās bibliotēkas, pirmkārt, fakts, ka viss ir sataisīts pēc iespējas OOP un pie tam "enterprise" stilā. Bet pateikšu vēlreiz, ka php tomēr nav tāds pārāk tīrs OOP un tā stipri neoptimālā php sintakse traucē arī to loģiski un precīzi un "OOPiski" uztvert. Protams, ZendFramework būtībā ir, līdzīgi kā jau šeit v3rb0 teica, apjomīgas bibliotēkas, kas nedaudz atgādina PEAR - visai neveiksmīgs tomēr ir tas PEAR, domāju, ka vairums tam piekritīs. Bet ZF tomēr šķiet labāks par PEAR. Es teiktu tā - ZF principā atmaksātos tā nopietni pielietot (lai būtu vispār vērts aktīvi studēt) tikai web aplikācijām, nevis kā vienkāršu standarta "CMS tūli". Iemesls tam varētu būt tas, ka ZF ir jāmācās diezgan nopietni un ilgi (neatkarīgi no "pielekšanas spējām"), jo tas vienkārši ir apjomīgs frameworks un nav diža jēga izmantot visas tās bibliotēkas un klases tur, ja nezin kā tās izmantot iespējami pareizi un optimāli. Un enterprise frameworka apgūšana pat normāli spējīgiem cilvēkiem līdz līmenim "eksperts", šķiet, prasīs vismaz gadu... Jo "sāls" ir nevis izlasīt dokumentāciju, bet arī iemācīties visu praktiski pareizi pielietot. Bet tomēr, rodas iespaids, ka ZendFramework mēģina risināt problēmas, kas patiesībā ir ārpus php "lauciņa" - vajadzības, kuras prasītu gandrīz vai .NET vai Java izmantošanu... PHP tak tomēr ir un paliek web valoda dinamiskajām weblapām. Nevar tak interpretējama valoda risināt pārāk dziļi un sarežģīti problēmas, jo nenotiek nekāda koda optimizēšana un kompilēšana, tas tiek lasīts tāds, kādu programmeris uzrakstījis un tajā varbūt daudz principiālas kļūdas, kuras atļaus iebūvētais "striktais errorreportings", bet kas nav varbūt optimālākais risinājums. Lai gan "bugainu" softu var uztaisīt jebkurā valodā. Runājot par "bugiem", pārsteidz ārkārtīgi biežie ZF "subversiju izlaidumi" - vai tad tiešām bugi tiek laboti tik bieži, vai arī notiek vienkārši nepārtrauktas jaunu "fīču" izstrādes... Lai gan neapgalvoju, ka ZF nebūtu izmantojams, tāpēc jau prasīju - kādiem softiem to izmanto un kā veicas ar izstrādi kopumā - bugi, jaunu fīču izstrādes ātrums un to kvalitāte, dizainu nomaiņas, jaunu servisu pievienošanas, trešo aplikāciju datu apmaiņa, servera OS nomaiņa, webservisi, ajax...? (sevišķi lietderīgi būtu tādu cilvēku komentāri, kas ar ZF nodarbojas jau vismaz gadu...)

Runājot par Smarty - ir strādāts arī ar to. Pateikšu godīgi - Smarty izmantošana man šķiet diezgan bezjēdzīga, jo tā ir bezmazvai skriptu valoda iekš skriptu valodas. Ko tas Smarty atvieglo? Dizainerim darbu ar šabloniem un "layoutiem"? Neticu! Vajag dizainerim iemācīt php pamatu pamatus (nebūs viņam tas grūtāk kā iemācīties Smarty) un pateikt - mainot "views" ar visu, kas tur iekšā, skaties, lai saglabājas tur iebūvētā datu atrādīšanas loģika (biznesa loģikai tur nevajadzētu būt, tikai attēlošanas loģikai) un viss. Kaut kādi dīvaini "dizaineri", ja vēlas ar to strādāt, bet negrib to visu lieliski un ātri apgūt! ;) Starp citu, ir gadījies sastapt tādus pāris kadrus, kas sevi dēvēja par "smarty programmētājiem". Protams, sākumā bija interesanti paklausīties kā viņi uzskata sevi par dižiem speciālistiem, kas ir spēcīgi specializējušies uz vienu lietu - "smarty programmēšanu" un html, javascript. Pēc tam jau, protams, par to nācās tikai pasmaidīt! :) Nav tā web sfēra tik šausmīgi komplicēta, ka varētu specializēties tikai uz "smarty programmēšanu" vai jquery izpratni utt. Ja specializējas uz JavaScript, HTML un CSS piemēram, tad specializējas tādā līmenī, ka spēj uzrakstīt savu Dojo, jQuery vai TinyMCE - jā tādu specializēšanos uz šauru sfēru es saprotu - tur ir spēcīgas zināšanas par "browser scripting" apakšā, bet ne jau čaļi, kas iemācījušies izmantot jquery un smarty sauks sevi par dižiem "speciem", kas lāga neprotot ne php, ne zinot ko par serveriem, server puses programmēšanu un datubāzēm (šķita, ka viņi pat OOP kā tādu nezin un nesaprot) - nu tas arī, manuprāt, ir "ceļš uz nekurieni". Latvijas mērogā tādu īsti specializētu specu ir ļoti maz vai arī nav gandrīz vispār, jo gluži vienkārši - reti kurš var atļauties nolīgt vienas web aplikācijas izstrādei 5 cilvēku profesionāļu komandu teiksim, kur katrs atbild tikai par savu specifisko sfēru un viss. Ja var sadalīt 3 daļās kaut vai - viens serverists/admins/operētājsistēmists vienā personā, viens spēcīgs tieši OOP un bāzes programmēšanā, arī db nepieciešamajā skriptēšanā, tad viens atbild tīri par dizainu, klienta puses skriptiem, stiliem un piedalās arī server pusē moduļu izstrādē un db tabulu modificēšanā papildināšanā, tas jau ir labi! Nav kaut kā dzirdēts šeit Latvijā par spēcīgiem Javascript speciālistiem, kas uz Javascript spēj realizēt bezmaz jebko, kas korekti rādītos uz 7 populārāko pārlūku pēdējo 3 gadu laikā izlaistajām versijām. CSS neskaitiet pie programmēšanas, tur ir hakošana, bet pārsvarā tā ir "stilošana". Gari gan te atkal skaidroju, bet pamatdoma ir tāda - arī klienta skriptēšanas pusē var izmantot tos Javascript frameworkus (Dojo, jQuery utt.) un tajās lietās spēj iebraukt arī kārtīgs zvērināts server puses OOP programmētājs. Un HTML spēj iebraukt arī iesācēji - par to vispār nav pat runa - valīds html un xml nav nekāda programmēšana (nejaukt ar XSLT) - tās lietas ir jāzin jebkuram, kurš izlēmis strādā šai sfērā (jā, pat tehniskajam projektu vadītājam)... Tāpēc es nesaprotu, ar ko nodarbojas šādi "dizaineri" un "smarty programmētāji", ja viņiem neatliek laiks izlasīt PHP manuāli un iemācīties pamatlietas uz PHP (vai Python vai citu valodu, kuru viņi izmanto), lai varētu skaisti ķerties klāt "viewiem", ko sataisījuši "serveristi"? Manuprāt, nav vajadzīgi nekādi "smarty" un vispār nekādi "template dzinēji", visu view daļu var realizēt, vienkārši turot tos atsevišķos php failos (piemēram, kā ZF ir tiem .phtml paplašinājums) un tur arī tad iet kopā gan html, gan php - tīri tikai līmenī, kas vajadzīgs, lai izveidotu attēlošanas loģiku - cikls atrādot vienādas daļas, vēršanās pie metodēm, kas veic atrādīšanu, view funkcijām, helperiem utml. Tas ir kopējā "frameworka" uzdevums, nevis kaut kādas atsevišķi izveidotas skriptu valodas iekš skriptu valodas, kur galvenā atšķirība no "mātes skriptu valodas" (šai gadījumā php kā "mātes skriptu valoda" Smarty) ir nedaudz savādā sintakse un pieraksts.

Starp citu, Java arī ir visādi brīnumi, piemēram JSF - Java Server Faces, arī paredzēti "viewiem", bet tur es neredzu gandrīz neko kopīgu ar tādu "Smarty" vai template endžines pieeju... Jo pati Java nav īsti skriptu valoda, tur viss ir objekts un "sejas jeb faces" pilda "viewu" funkcijas, ko nebūtu optimāli uzticēt Javas klasēm...

Link to comment
Share on other sites

Daži punkti:

 

IT speciālistam ir plašas iespējas orientēties uz tirgu ārpus LV, tas nav nekas slikts specializēties Smarty, JS un XHTMLā.

 

Jā, ZF pamatā esošais PHP ir dinamiski interpretēta valoda. No vienas puses, man pašam tas šķiet diezgan būtisks faktors, ātrdarbība un tā. No otras puses, to var risināt ar labi pārdomātu izvada kešošanu un arī bytecode kešošanu, jeb php optimizātoru.

 

Protams, ka ZF ir priekš web aplikācijām, piemēram, web servisu veidošanai var izmantot citu pieeju (bet var arī ZF izmantot tam, gan kā MVC ietvaru, gan kā tikai library), integrējot tos web aplikācijā.

 

Tavs piemērs ar Smarty ir tas, par ko jau teicu - konkrētai vajadzībai tiek pretnostatīts risinājums, kas ir domāts citu vajadzību risināšanai. Ja tavas vajadzības nav templeita valoda, nodalīts php kods un, piemēram, iespēja templeitus definēt CMSā, tad ir lieki spriedelēt par to, kāpēc dizaineriem jāapgūst php un kāpēc Smarty, kas nav domāts šādai pieejai, ir slikts ar to, ka nav tiešām nav domāts tādiem gadījumiem. Vienkārši neizmanto to. Kur problēma?

 

Konkrētu aplikāciju un projektējuma idejas nav vēlme izklāstīt detaļās šobrīd. Varu tikai piebilst, ka virzība ir virzienā, uz kuru pasaule jau labu laiku virzās. Nav jau arī nekāds kosmoss, vnk. gribās uzbūvēt to, kas pašam šķiet interesants. Ja viss labi veiksies Laiks rādīs, apsveru iespēju uzrakstīt blogu, kur apkopot savas pārdomas, bet tas tāds jautājums ar lielu varbūtības koeficientu, jo latviski kaut kā negribas rakstīt dēļ profesijas specifikas, bet angliski vēl tik labi neprotu.

 

Par minor versijām - nu es to saprotu, kā labi organizētu izstrādes darbu. Projekts attīstās. Varbūt interesanti, kā gāja ar devZone ZF updeitu no 1.0.1 uz 1.9.5. versiju: http://devzone.zend.com/article/11364-DevZone-updated-to-Zend-Framework-v1.9.5

Edited by Mr.Key
Link to comment
Share on other sites

Nesitiet pārāk stipri, bet jautājums Java'i - ko Tu vispār dari/meklē šajā forumā un kāda no tā ir jēga? Paldies.

To, ko parasti cilvēki dara forumos - diskutē, apmainās ar viedokļiem un izsaka savus viedokļus par attiecīgajām tēmām. Šī tēma ir par php frameworkiem, par to arī ir pamatā runa manos ziņojumos, kas attiecās uz šo tēmu. Jēga - uzzinu citus viedokļus, meklēju atbildes uz sev interesējošiem jautājumiem.

 

IT speciālistam ir plašas iespējas orientēties uz tirgu ārpus LV, tas nav nekas slikts specializēties Smarty, JS un XHTMLā.

Man jau līdz šim ir licies, ka ārzemēs (vismaz Rietumeiropā, ASV, Austrālijā, Jaunzēlandē, Kanādā, Japānā un citās attīstītās valstīs) līmenis ir augstāks. Iespējams, tieši tāpēc tur izmanto Smarty, jo ir pārspīlēta darba dalīšana un tiek meklēti tirgū "dizaineri ar smarty zināšanām".

 

Tavs piemērs ar Smarty ir tas, par ko jau teicu - konkrētai vajadzībai tiek pretnostatīts risinājums, kas ir domāts citu vajadzību risināšanai. Ja tavas vajadzības nav templeita valoda, nodalīts php kods un, piemēram, iespēja templeitus definēt CMSā, tad ir lieki spriedelēt par to, kāpēc dizaineriem jāapgūst php un kāpēc Smarty, kas nav domāts šādai pieejai, ir slikts ar to, ka nav tiešām nav domāts tādiem gadījumiem. Vienkārši neizmanto to. Kur problēma?

Runāju tieši par tām pašām vajadzībām. Smarty "funkcijas" lieliski veiks tas pats php un ja dizainerim nav problēmu ar smarty, tad viņš tiks tikpat labi galā arī ar php.

 

Ja viss labi veiksies Laiks rādīs, apsveru iespēju uzrakstīt blogu, kur apkopot savas pārdomas, bet tas tāds jautājums ar lielu varbūtības koeficientu, jo latviski kaut kā negribas rakstīt dēļ profesijas specifikas, bet angliski vēl tik labi neprotu.

 

Par minor versijām - nu es to saprotu, kā labi organizētu izstrādes darbu. Projekts attīstās. Varbūt interesanti, kā gāja ar devZone ZF updeitu no 1.0.1 uz 1.9.5. versiju: http://devzone.zend.com/article/11364-DevZone-updated-to-Zend-Framework-v1.9.5

Par ZF runājot - tieši tā - vajag rakstīt! Vajag pēc iespējas vairāk rakstīt cilvēkiem, kā viņiem iet, lietojot savu izvēlēto frameworku. Performances jautājums ir svarīgs, uz ko visi pārsvarā iespringst, bet vēl svarīgāki ir BUGI un vai viss notiek visos gadījumos tieši tā kā Framework izstrādātāji paši iecerējuši un aprakstījuši!

 

Atvaino, bet šajā gadījumā "trollis" esi tu pats, jo jaucies pa vidu ar "beztēmu". ;)

Link to comment
Share on other sites

Ārzemēs freimwork'i ir ļoti populāri. Man pat liekas, ka reti kur izmanto pliku PHP (vai jebko citu). PHP gan tur nav vispopulārāk izmantotais, toties ASP.NET ir visur (es šobrīd pa Lielbritāniju runāju) pieprasīts - es gan īsti nesaprotu kādēļ, jo man viņš neliekas īpaši ērts.

 

Ja skatamies darba piedāvājumus par PHP, populārākie freimwork'i ir Code Igniter un Zend. Esmu papētījis Code Igniter, taču ja ir lietots Rails, kuram viņi cenšas līdzināties, tad viņš liekas tāds nedaudz saspīlēts un ne-tik-tīrs.

 

Runājot par Smarty templeitiem - es arī īsti neizprotu kādēļ vajag veidot vēl savu valodu, valodā. Manuprāt nav liela starpībā ko izprast - nedaudz PHP sintakses, vai Smarty sintaksi. Tas pats vien būs.

 

Bet nu lai vai kā nedomāju, ka php freimwork'i ir kaut kas slikts - varbūt nevajag tik ļoti censties līdzināties ekvivalentiem uz citām valodām, taču visādi citādi tas ir ērtāk kā lietot pliku php.

Link to comment
Share on other sites

Ārzemēs freimwork'i ir ļoti populāri. Man pat liekas, ka reti kur izmanto pliku PHP (vai jebko citu). PHP gan tur nav vispopulārāk izmantotais, toties ASP.NET ir visur (es šobrīd pa Lielbritāniju runāju) pieprasīts - es gan īsti nesaprotu kādēļ, jo man viņš neliekas īpaši ērts.

 

Ja skatamies darba piedāvājumus par PHP, populārākie freimwork'i ir Code Igniter un Zend. Esmu papētījis Code Igniter, taču ja ir lietots Rails, kuram viņi cenšas līdzināties, tad viņš liekas tāds nedaudz saspīlēts un ne-tik-tīrs.

Lielbritānija, lai nu ko par viņiem teiktu, ekonomiski ir augsti attīstīta valsts, protams, un tur darbojās gandrīz visas "industrijas", diemžēl, neesmu labi informēts tieši par IT un software industriju tur.

Kas attiecas uz ASP.NET - tas tomēr ir MS risinājums un patiesībā izskatās, ka Eiropas mēroga Microsoft lobijs ietekmē programmatūras izvēli tieši šādās rietumeiropas valstīs, kur ļaudis mēdz dažkārt naudu vairāk taupīt nekā šeit, bet tai pat laikā pāris simti eiro tur ir sīknauda.

 

Runājot par Smarty templeitiem - es arī īsti neizprotu kādēļ vajag veidot vēl savu valodu, valodā. Manuprāt nav liela starpībā ko izprast - nedaudz PHP sintakses, vai Smarty sintaksi. Tas pats vien būs.

Precīzi!

 

Bet nu lai vai kā nedomāju, ka php freimwork'i ir kaut kas slikts - varbūt nevajag tik ļoti censties līdzināties ekvivalentiem uz citām valodām, taču visādi citādi tas ir ērtāk kā lietot pliku php.

Tieši tā - frameworki ir profesionālu programmētāju darbarīki. Nav jāizgudro ritenis, nav jātērē laiks un nauda, jo klients vēlas maksāt pēc iespējas mazāk, bet saņemt augstu kvalitāti, jo to spēj piedāvāt konkurenti. Attiecīgi atvērtā koda ietvarrāmji (jeb "freimvorki") kļūst ļoti izdevīgi gan to izstrādātājiem, gan arī izmantotājiem - programmētājiem! Izstrādātāji iegūst stabilus "supporta" pasūtījumus, jo no frameworkiem galu galā ir atkarīgi daudzi biznesi, savukārt izstrādātāji - atvieglotus jaunu projektu izstrādes nosacījumus, līdz ar to zemākas izmaksas un konkurētspējīgākus piedāvājumus klientiem.

 

Bet galvenais jautājums tomēr paliek atklāts - kādi frameworki "web softu" izstrādes mērķiem ir vislabākā izvēle? Man šķiet, vajadzētu izveidot augstas klases profesionāļiem tādu organizāciju, kas nodarbojas ar salīdzināšanu - gan frameworku, gan softu un savus rezultātus viņi varētu pārdot kaut vai IT mēdijiem un mēs - par brīvu izlasīt! :)

Link to comment
Share on other sites

Manā lekcijā (LU) pagājušonedēļ pasniedzējs teica, ka mūsdienās tieši ir vairāk tā, ka programmētājs vien pārsvarā tikai saliek dažādus koda gabalus (kas nemaz nav slikti lielākoties) un paša programmētāja radītie koda gabali laika gaitā ir samazinājušies. Manuprāt, tieši tāpēc arī ir saradušās visādas metavalodas, jo tā ir dabiska evolūcija programmēšanā. mašinkods --> asemblers --> pirmas gudraas prog. valodas --> OOP-->....

 

Tagad programmēšana ir pilna ar freimvorkiem, to papildinājumiem utt. Un programmēšanas valodas ir kļuvušas sarežģītākas funkcionalitātes un skaita ziņā, bet sarežģītību kompensē šie papildinājumi...

 

Tas pats ar PHP. Man šķiet, ka PHP sākumā taisīja kā draudzīgu prog. valodu web izstrādei, bet laika gaitā PHP apauga ar PEARiem, moduļiem, taalaak ar freimvorkiem, kas tagadnē spēlē ļoti lielu lomu, tapēc par 100% piekrītu, ka ir ļoti nepieciešami visādu freimvorku apskati, freimvorku salīdzināsanas lapas, jo viens pats programmētājs nevar iztestēt visus freimvorkus...

Edited by torrentz
Link to comment
Share on other sites

Manā lekcijā (LU) pagājušonedēļ pasniedzējs teica, ka mūsdienās tieši ir vairāk tā, ka programmētājs vien pārsvarā tikai saliek dažādus koda gabalus (kas nemaz nav slikti lielākoties) un paša programmētāja radītie koda gabali laika gaitā ir samazinājušies.

Tieši par šo man ir jautājums, iespējams, diezgan netaktisks:

Vai tavs pasniedzējs mēdz intensīvi pasniegt lekcijas vai ik pa laikam novirzīties no pamattēmas ar šim līdzīgiem spriedelējumiem? ;) Izklausās, ka LU (kas tomēr ir Latvijas augstākās izglītības "zieds") tomēr pasniedz arī diezgan ierobežotām zināšanām apveltīti pasniedzēji. Es, nebūdams ne maģistrs, ne profesors nevienā sfērā, varu pamatot, ka tā ir "tukša liekvārdība", ar argumentiem!

1. tas, ko programmētājs liek kopā vai neliek kopā no gataviem gabaliem, ir atkarīgs no veicamā uzdevuma specifikas - vai tas ir komerciāls projekts ar miljoniem līdzinieku, kur nekas jauns vairs nav jāizdomā (vismaz - neatmaksājas to darīt), tāpēc pietiek "salipināt" esošus gabalus kopā (gandrīz jebkurā gadījumā - tomēr pašam kaut kas jāpaprogrammē būs). Vai arī uzdevums var būt specifisks un tad, ļoti iespējams, vajadzēs programmētājam nodemonstrēt gan savas "algoritmizācijas zināšanas un arī spējas", gan valodas pamatu pamatu zināšanas.

2. ja programmētājs arī netaisa komerciālu gabalu, bet teiksim, nodarbojas ar entuziasmu (īsts programmētājs IR nodarbojies ar entuziasmu programmēšanā, jo viņam šis darbs vienmēr ir interesējis), tad viņš nemaz nav ieinteresēts "gatavu kodu lipināšanā" kaut arī šie gatavie kodi ir pieejami. Viņš tieši ir ieinteresēts algoritmizācijas problēmu risināšanā, matemātikā, informātikas fundamentu risinājumos, jaunradē utt. Un tur vairs nav nekādu "gatavu kodu lipināšana", vienīgais, ko tur interesanti ir ņemt gatavu - informāciju un fundamentālas idejas jeb studēšanas process. :)

 

Secinājumi jautājumu formā:

1. Iespējams neesi uztvēris vissvarīgāko sava pasniedzēja lekcijas daļu vai arī iespējams, viņš visu lekciju "dzina sviestu"?

2. Vai LU visi pasniedzēji nodarbojās ar šāda veida "mācīšanu" vai arī tās ir tikai atkāpes, lai kaut kā kompensētu 10 minūtes no 1.5 stundu ilgās lekcijas, par kurām nav īsti sagatavota viela?

Link to comment
Share on other sites

Paklau, lekccija notiek pusotru stundu un vienkaarshi diskuteejot par kaut ko ar auditoriju, pasniedzeejs apmeeram taa pateica (un tas neaiznjeema nekaadas 10 minuutes). Protams, ka mums nemaaca lipinaat koda gabalus un nekaadu luni pasniedzeeji nedzen lekcijaas. Ja godiigi, es jau aizmirsu to kontekstu, kaapeec vinjsh piemineeja koda lipinaashanu. Es nekur neesmu teicis, ka programee tikai lipinot koda gabalus, bet tie koda gabali programmeetaaju darbaa ir ljoti biezhi izmantoti. Piemeeram, domaaju, ka gandriiz katrs PHP programmeetaajs ir pieregjistreejies phpclasses.org un izmantojis tur esoshaas klases, jo nav jeegas katru reizi no jauna izgudrot riteni...

Edited by torrentz
Link to comment
Share on other sites

torrentz - pirms jautājuma jau brīdināju, ka tas varētu šķist nektaktisks. Man vienmēr ir interesējis, ko tad tajos LU datoriķos tieši māca! Varbūt tev ir kāds links uz lekciju sarakstu vai konspekti kaut kādi?

 

Kas attiecas uz "lipināšanu kopā" - "frameworka" sākotnējā izmantošana un aplikācijas konfigurēšana ar to principā arī ir tāda koda gabalu lipināšana kopā, jo pat ja tur nav kods iekšā sākumā, programmētājs paņem kaut ko jau no gataviem piemēriem. Bet ja tas tavs pasniedzējs gribēja ar to pateikt, ka mūsdienās daudzi programmētāji attiecīgi nav profesionāli vai "necērt" lietas no pašām saknēm, tad šādā kontekstā es viņam nekādi negribu piekrist!

Jo gluži vienkārši - programmētājs dara to, ko viņam pasūtītājs liek, to arī viņš veido un nav viņam jātērē mēnešiem ilgs laiks, taisīt aplikācijas pamatus, ja to jau var gatavu lejupielādēt framework formā pāris minūtēs un tad, zinot pamatprincipus - valodu, arhitektūru - izstudēt līdz spējai "varu sākt izmantot" dažu nedēļu laikā. Tas, cik programmētājs ir labs vai profesionāls, atklāsies gan tajā KĀ viņš raksta to kodu - kāda ir koda kvalitāte, loģika, tīrība, kā arī tas atklāsies, kad vajadzēs risināt nebijušas problēmas - kā viņš ar tām tiks galā un cik ātri aptvers, kur "vajag rakt", jo zinot fundamentu un esot apveltītam ar abstraktu domāšanu, to visu var izdomāt.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...