Dec 22 2008
projekts
Ar šo tekstu ir doma uzsākt jaunu sadaļu šajā resursā. Nākamgad uzsākšu darbu pie jauna, apjomīga web projekta un tēmas, kas šajā sakarā te varētu atspoguļoties – šī projekta tapšanas gaitā radušies risinājumi, atziņas, secinājumi.
Tātad par visu pēc kārtas – sīkākas detaļas gan neatklāšu, taču projekta novirziens ir ar spēcīgu sociālu piesitienu papildinot to ar mobilajām tehnoloģijām un gps. Tā kā manā pārziņā ir pats izstrādes process, tad jau tagad esmu pietiekami rūpīgi tam sācis gatavoties:) Protams, šeit lielu lomu spēlē tā pieredze, kas ir gūta strādājot “draugos”, bet ir arī šādas tādas atkāpes. Galvenokārt dēļ tām kompetencēm, kas sniedzas mazliet tālāk par pliku izstrādi – arī dzelži nav sveša lieta.
OS. Viennozīmīgi linux vai kaut kas no bsd saimes. No windows esmu aizgājis jau labu laiku atpakaļ un nejūtos tur vairs pietiekami spēcīgs.
Webserveris. Nē, nebūs apache, to nu pavisam noteikti varu garantēt. Daudz lielāku efektu pie paredzētajiem lietojumiem var panākt ar Lighttpd vai Nginx, nevis smagnējo Apache. Lighttpd + FastCGI PHP performē vismaz uz pusi labāk. Iespējams, ka apache tiktu lietots java vai python risinājumā, bet tā kā izstrāde paredzēta php, tad ir iespēja izvēlēties. Kapēc php? Domāju, ka personīgi man nebūtu liela problēma iebraukt arī python vai ruby, bet pie projekta paplašināšanās varētu parādīties speciālistu iztrūkuma problēma. Patiesībā es sākumā diezgan nopietni metu acis arī python virzienā – īpaši jau advancētā python freimworka Django sakarā. Php nekā līdzvērtīga īsti nav, jo pašos pamatos jau php ir interpretators.. Ja tam visam vēl uzsēdina pa virsu vēl vienu loģikas slāni – zaudējam performanci vēl vairāk. Nē, dīvainā kārtā šoreiz es neatteikšos no framework, bet izmantošu īpaši vieglu risinājumu – codeIgniter, pie kura esmu nonācis izveicot diezgan plašus pētījumus un šis konkrētais ir tāds, kas iespējami tuvu stāv paša php funkcionalitātei. Iemesli framework lietošanai divi – izstrādes ātrums un kaut kāda nebūt koda sakārtošana/standartizēšana. Principā savos projektos esmu mēģinājis pieturēties pie MVC principa, bet nu ne vienmēr izdodas tā 100%. Tapēc arī ir doma pieturēties pie kaut kādiem rāmjiem, kurus uzliek framework. Ja nu kādam interesē dziļāka MVC un citu aplikāciju izstrādes principu analīze, tad skatīt šeit.
Jautāsiet kāpēc MVC, kāpēc vispār nodalīt funkcionalitāti no vizuālās daļas, jeb triviālākā līmenī php no html? Patiesībā viens pietiekami saprotams iemesls varētu būt datu izmantošana citā vizuālajā paskatā – kaut vai padošanai uz mobilo, jeb arī API gadījumā – vispār bez vizuālās daļas.
Dati. Pamatā mysql. Tiesa gan izmantojot palielu spektru no tām iespējām, ko šobrīd piedāvā mysql – gan procedūras/funkcijas, gan partīcijas un vēl šo to. Kā papildinājums, bet vairāk atslogs mysql un php – talkā nāks arī memcached un sphinx. Memcached vairāk bieži pieprasīto datu procesēšanai, sphinx – meklēšanai, atslēgas vārdiem (tagiem), kā arī geo funkcionalitātes nodrošināšanai (objektu atrašanai uzdotā rādiusā). Šajā sakarā – 2 jaukas prezentācijas par tēmu - Geo Distance Search with MySQL un fulltext search engine Sphinx.
Storage. Kas attiecas uz apjomīgiem datu masīviem, tad šobrīd vēl meklēju kaut ko pietiekami līdzvērtīgu Sun Solaris ZFS. Tā failu sistēma patiesi ir labi pārdomāta un neprasa lieku darbu tās apkalpošanā. Var jau būt, ka būs jāizmanto tā pati. Patiesībā šai tēmai vēl neesmu pievērsis īpaši daudz uzmanības. Modelis tuvu ideālajam būtu storage + vairāki proxy statiskajām lietām, bet nu tad jau redzēs.
Darbu plānošana. Nenoliedzami šādam apjomīgam projektam nepietiks ar N mēnešu dead-line – iespējami sīki jāsadala un jāuzrauga (arī pašam sevi) darbu plāni pietiekami nopietni. Ir apskatīti virkne webisku rsinājumu un izskatās, ka derēs praktiski jebkurš no tiem. Patiesībā šajā sakarā pietiekami konspektīvs, bet tajā pašā laikā arī informatīvs tekstiņš varētu būt šis.
Izstrādes process. Vairākas reizes neveiksmīgi esmu mēģinājis sadzīvot ar kādu nebūt IDE – Zend, Komodo, Aptana, bet kaut kā nav sanācis. Nezinu kapēc – nesanāk un viss:) Neliekas ērti, noderīgi un procesu paātrinoši. Es tad labāk apmierinos ar koda redaktoru, kas nodrošina man aktuālās prasības.
Kas attiecas uz client side risinājumiem – visam vajadzētu notikt pēc labākajiem web 2.0 standartiem – ajax, autocomplete, jQuery, multiple file upload ir tikai daži no atslēgas vārdiem:) Patiesībā jaunu velosipēdu grūti izdomāt – liela daļa risinājumu visticamāk tiks brutāli noskatīti no labākajiem industrijas piemēriem.
Nu iesākumam kaut kā tā. Nezinu, vai turpmāka iedziļināšanās projekta tapšanas gaitā būs interesanta, taču es vismaz būšu mēģinājis ko darīt lietas labā:)
