Archive for August, 2008

Tie, kas seko šim blogam būs pamanījuši, ka es pirms kāda laika sāku pastiprināti interesēties par Zend Framework. Nu jau būs pagājuši kādi pāris mēneši kopš aktīvi esmu sācis izmantot Zend Framework viena Web projekta izstrādē. Tas ir pirmais projekts, kuru veidoju izmantojot kādu ietvaru, tāpēc gribētu pastāstīt par to, kādi secinājumi man ir radušies izstrādes laikā. Es domāju, ka lielākā daļa no secinājumiem būtu tādi paši izmantojot arī citus ietvarus, nevis tikai specifiski Zend Framework.

Pirmais un pats svarīgākais – vai es arī nākamo projektu taisīšu izmantojot ietvarus? Jā – noteikti! Tas tāpēc, ka ietvari palīdz izstrādē krietni vairāk, kā rada problēmas.

Lielākās problēmas ir:

• laiks, kurš jātērē, lai ietvaru apgūtu
• neviennozīmība ātrdarbības novērtējumā

Varētu jau likties, ka ietvaru apgūstam vienu reizi – pēc tam tikai to izmantojam, jo visu jau zinām. Tā gan īsti nav. No sākuma ir jāapgūst ietvaru kā tādu. Savukārt vēlāk ir regulāri jāseko līdzi ietvara attīstīšanas gaitai – tam kāda papildus funkcionalitāte tiek pielikta, kāda ir labā prakse izmantošanā, optimizācijas iespējas utt. Tas ir nepārtraukts izglītošanās process.

Savukārt par ātrdarbību ir tā, ka neviens nestrīdās par to, ka uz ietvariem veidota Web lapa būs lēnāka no koda izpildes viedokļa par Web lapu, kura tiktu būvēta uz ne tik sarežģītiem/universāliem skriptiem. Diskusijas notiek par to, kurš ietvars ir lēnāks/ātrāks un cik liela ir šī atšķirība. Mans viedoklis ir tāds, ka skriptu izpildes ātrdarbība nav tik svarīga šajā gadījumā (par to kādēļ – pastāstīšu turpinājumā). Tāpēc šādas diskusijas ir tīri tikai tāpēc, lai pamērītos, kura izmantotais ietvars ir pārāks kādā parametrā.

Kādi tad ir ieguvumi? Vismaz es jau tagad varu uzskaitīt sekojošus:

• jauna pieredze un zināšanas
• plaša funkcionalitāte, kuru pašam nav jāraksta – līdz ar to izmantojama out of the box
• izstrādes ātrums
• pārskatāmība un kārtība

Lai gan iepriekš minēju, ka viena no problēmām ir laika veltīšana ietvara apgūšanai, šoreiz ir jāsaka, ka ja var atļauties šo laiku ziedot, tad var iegūt nenovērtējamu pieredzi un zināšanas. Es šo divu mēnešu laikā esmu apguvis vairāk kā pēdējos pāris gados kopā. Esmu apguvis vairākus design patterns, jaunas valodas konstrukcijas, programmēšanas stilus utt. Ja iepriekš es dzīvoju uz tādām zināšanām, kādas biju ieguvis pirms vairākiem gadiem vai arī tās papildināju ļoti lēnām, tad tagad jaunu lietu apguve notiek tik strauji, ka pēc kāda gada varēšu uzskatīt, ka esmu zinošs PHP programmētājs.

Ietvaros ir realizētas daudzas tādas funkcijas, kuras parasti nāktos rakstīt pašam. Šo funkciju izmantošana ieekonomē ļoti daudz laika. Turklāt, ja tiktu izmantotas savi skripti attiecīgajām lietām, tad šādi skripti savā kvalitātē un funkcionalitātē progresētu daudz lēnāk, kā tie, kurus izstrādā kā ietvaru sastāvdaļu. Nav jēgas izgudrot riteni vēlreiz! Protams, neviens neliedz aizvietot kādu ietvara funkcionalitāti ar tādu, kas pašam šķiet ātrāka/labāka/ērtāka. Ņemam to, kas šķiet svarīgs un ērts.

Tā kā daudzas lietas pašam nav jāprogrammē, tad krietni pieaug izstrādes ātrums. Protams, sākotnēji nākas zudēt laiku, jo nav īsti zināms, kā strādā katra komponente ietvarā, bet kad tas tiek apgūts, tad izstrādes ātrums pieaug ļoti strauji.

Ietvari visbiežāk uzspiež kaut kādu programmēšanas stilu. Piemēram, MVC patternu, noteiktu metožu nosaukumu veidu utt. Varbūt sākotnēji tas šķiet ļoti ierobežojoši, bet kad pēc kāda laika ir jāveic papildinājumi un labojumi, tad šāda standartizēta pieeja ļoti atmaksājas. Protams, neviens neliedz izmantot kādus nosacījumus koda organizēšanā arī tad, ja netiek izmantoti ietvari. Bet zinot cik brīvi PHP pacieš dažādas izvirtības kodos, var viegli prognozēt, ka ja PHP programmēšanas stils netiek uzspiests, tad agri vai vēlu, bet sāks kodā parādīties dažādi brīnumi, par kuru eksistenci īpaši priecāties nevajadzētu.

Augstāk biju minējis, ka manuprāt uz ietvariem bāzēto skriptu izpildes ātruma problēmas nav būtiskas. Tas tāpēc, ka ne jau vienmēr visu var mērīt tikai tajā, cik ātri izpildās viens kaut kāds skripts. Pieņemsim, ka Web lapa ir samērā apmeklēta. Uz ko tiks likts uzsvars Web lapai, lai nebūtu problēmu ar ātrdarbību. Pareizi – uz kešošanu. Savukārt, cik ātri serveris var parādīt iekešotu lapu viena vai otra ietvara gadījumā? Pieļauju, ka ātruma starpība būs nenozīmīga. Tas pats attiecas uz ietvaru izmantojošas Web lapas salīdzinājumu ar tādu, kura neizmanto ietvarus. Ja abas izmanto kešošanu, starpība nevar būt būtiska. Bet izmaksas, lai izveidotu lapu uz ietvara bāzes būs krietni mazākas, kā tādu, kura ietvarus neizmanto. Tad kāpēc maksāt vairāk?

Ja vēl neizmantojat ietvarus, iesaku pamēģināt. Varbūt, ka iepatīkas. Galvenais atrast tādu ietvaru, kurš patīk un šķiet piemērots. Tā kā ietvaru ir samērā daudz, novēlu, lai meklēšana vainagojas panākumiem.

Tie, kas seko šim blogam būs pamanījuši, ka es pirms kāda laika sāku pastiprināti interesēties par Zend Framework. Nu jau būs pagājuši kādi pāris mēneši kopš aktīvi esmu sācis izmantot Zend Framework viena Web projekta izstrādē. Tas ir pirmais projekts, kuru veidoju izmantojot kādu ietvaru, tāpēc gribētu pastāstīt par to, kādi secinājumi man ir radušies izstrādes laikā. Es domāju, ka lielākā daļa no secinājumiem būtu tādi paši izmantojot arī citus ietvarus, nevis tikai specifiski Zend Framework. Pirmais un pats svarīgākais - vai es arī nākamo projektu taisīšu izmantojot ietvarus? Jā - noteikti! Tas tāpēc, ka ietvari palīdz izstrādē krietni vairāk, kā rada problēmas. Lielākās problēmas ir: laiks, kurš jātērē, lai ietvaru apgūtu neviennozīmība ātrdarbības novērtējumā Varētu jau likties, ka ietvaru apgūstam vienu reizi - pēc tam tikai to izmantojam, jo visu jau zinām. Tā gan īsti nav. No sākuma ir jāapgūst ietvaru kā tādu. Savukārt vēlāk ir regulāri jāseko līdzi ietvara attīstīšanas gaitai - tam kāda papildus funkcionalitāte tiek pielikta, kāda ir labā prakse izmantošanā, optimizācijas iespējas utt. Tas ir nepārtraukts izglītošanās process. Savukārt par ātrdarbību ir tā, ka neviens nestrīdās par to, ka uz ietvariem veidota Web lapa būs lēnāka no koda izpildes viedokļa par Web lapu, kura tiktu būvēta uz ne tik sarežģītiem/universāliem skriptiem. Diskusijas notiek par to, kurš ietvars ir lēnāks/ātrāks un cik liela ir šī atšķirība. Mans viedoklis ir tāds, ka skriptu izpildes ātrdarbība nav tik svarīga šajā gadījumā (par to kādēļ - pastāstīšu turpinājumā). Tāpēc šādas diskusijas ir tīri tikai tāpēc, lai pamērītos, kura izmantotais ietvars ir pārāks kādā parametrā. Kādi tad ir ieguvumi? Vismaz es jau tagad varu uzskaitīt sekojošus: jauna pieredze un zināšanas plaša funkcionalitāte, kuru pašam nav jāraksta - līdz ar to izmantojama out of the box izstrādes ātrums pārskatāmība un kārtība Lai gan iepriekš minēju, ka viena no problēmām ir laika veltīšana ietvara apgūšanai, šoreiz ir jāsaka, ka ja var atļauties šo laiku ziedot, tad var iegūt nenovērtējamu pieredzi un zināšanas. Es šo divu mēnešu laikā esmu apguvis vairāk kā pēdējos pāris gados kopā. Esmu apguvis vairākus design patterns, jaunas valodas konstrukcijas, programmēšanas stilus utt. Ja iepriekš es dzīvoju uz tādām zināšanām, kādas biju ieguvis pirms vairākiem gadiem vai arī tās papildināju ļoti lēnām, tad tagad jaunu lietu apguve notiek tik strauji, ka pēc kāda gada varēšu uzskatīt, ka esmu zinošs PHP programmētājs. Ietvaros ir realizētas daudzas tādas funkcijas, kuras parasti nāktos rakstīt pašam. Šo funkciju izmantošana ieekonomē ļoti daudz laika. Turklāt, ja tiktu izmantotas savi skripti attiecīgajām lietām, tad šādi skripti savā kvalitātē un funkcionalitātē progresētu daudz lēnāk, kā tie, kurus izstrādā kā ietvaru sastāvdaļu. Nav jēgas izgudrot riteni vēlreiz! Protams, neviens neliedz aizvietot kādu ietvara funkcionalitāti ar tādu, kas pašam šķiet ātrāka/labāka/ērtāka. Ņemam to, kas šķiet svarīgs un ērts. Tā kā daudzas lietas pašam nav jāprogrammē, tad krietni pieaug izstrādes ātrums. Protams, sākotnēji nākas zudēt laiku, jo nav īsti zināms, kā strādā katra komponente ietvarā, bet kad tas tiek apgūts, tad izstrādes ātrums pieaug ļoti strauji. Ietvari visbiežāk uzspiež kaut kādu programmēšanas stilu. Piemēram, MVC patternu, noteiktu metožu nosaukumu veidu utt. Varbūt sākotnēji tas šķiet ļoti ierobežojoši, bet kad pēc kāda laika ir jāveic papildinājumi un labojumi, tad šāda standartizēta pieeja ļoti atmaksājas. Protams, neviens neliedz izmantot kādus nosacījumus koda organizēšanā arī tad, ja netiek izmantoti ietvari. Bet zinot cik brīvi PHP pacieš dažādas izvirtības kodos, var viegli prognozēt, ka ja PHP programmēšanas stils netiek uzspiests, tad agri vai vēlu, bet sāks kodā parādīties dažādi brīnumi, par kuru eksistenci īpaši priecāties nevajadzētu. Augstāk biju minējis, ka manuprāt uz ietvariem bāzēto skriptu izpildes ātruma problēmas nav būtiskas. Tas tāpēc, ka ne jau vienmēr visu var mērīt tikai tajā, cik ātri izpildās viens kaut kāds skripts. Pieņemsim, ka Web lapa ir samērā apmeklēta. Uz ko tiks likts uzsvars Web lapai, lai nebūtu problēmu ar ātrdarbību. Pareizi - uz kešošanu. Savukārt, cik ātri serveris var parādīt iekešotu lapu viena vai otra ietvara gadījumā? Pieļauju, ka ātruma starpība būs nenozīmīga. Tas pats attiecas uz ietvaru izmantojošas Web lapas salīdzinājumu ar tādu, kura neizmanto ietvarus. Ja abas izmanto kešošanu, starpība nevar būt būtiska. Bet izmaksas, lai izveidotu lapu uz ietvara bāzes būs krietni mazākas, kā tādu, kura ietvarus neizmanto. Tad kāpēc maksāt vairāk? Ja vēl neizmantojat ietvarus, iesaku pamēģināt. Varbūt, ka iepatīkas. Galvenais atrast tādu ietvaru, kurš patīk un šķiet piemērots. Tā kā ietvaru ir samērā daudz, novēlu, lai meklēšana vainagojas panākumiem.