nothing special @ alx.f1.lv

Šo varētu uztvert kā turpinājumu bloga ierakstam “Projekts“. Tagad, pēc aptuveni pusgada reāla izstrādes darba un tuvojoties kaut kādam rādāmam rezultātam, varu izdarīt secinājumus un varbūt arī lietas, ko varbūt bija labāk darīt savādāk.

OS. Linux. Nav nozīmes kāds distributīvs, pa lielam visi viņi savu funkciju pilda. Šobrīd, izstrādes vidē, darbojas CentOS, bet tas ir tikai tāpēc, ka viņš tur jau bija:) Ar visu savu saimniecību, kas man absolūti nav vajadzīga. Tāpēc man patīk BSD sistēmas, kurām sākotnēji nav nekā vispār un var salikt tikai to, kas tiešām nepieciešams.

Webserveris. Lighttpd. Nekādu problēmu. PHP FastCGI modē un visas lietas. Patiesībā viena lieta mani mazliet pārsteidz saistībā ar manis izmantojamo gettext. Protams ir izstrādāts normāls web interfeiss tulkošanas lietām, sajūgts arī ar mysql, bet ne par to stāsts. Stāsts par to, ka biju lasījis, ka pēc jebkurām gettext izmaiņām jārestartē webserveris lai izmaiņas stātos spēkā. Manā gadījumā ir tā, ka tas notiek pats no sevis. Patiesībā ar kļūdu – pirmais php requests pēc gettext update beidzas ar 500. kļūdu, bet pēc tam viss notiek it kā nekas nebūtu bijis un arī izmainītie, jaunie teksti strādā.
Turpinot par PHP – CodeIgniter framework kā MVC “groži” tika atstāts. Tiesa gan reāli sākot darbināt diezgan drīz uzradās lietas, ko gribējās savādāk, kā arī situācijas, kad bija vajadzība mazliet izkāpt no CI uzliktajiem rāmjiem. Pirmais, kas cieta, bija sesiju apstrādes library. Oriģinālais tika nonests, vietā uzlikts “native session“, papildināts ar memcache. Iemesls diezgan triviāls – šis CI oriģinālais sesiju handleris arī datus storēja pa savam, bet es orientējos uz izstrādi, kur paredzēta vieta serveriem, uz kuriem nu nekādi nav vēlmes stutēt augšā CI. Piemēram bilžu/failu upload. Tā kā man nebija cilvēcīgas iespējas no šiem serveriem tikt klāt pie sesijas datiem, tad vieglākais ceļš bija nonest šo neparocīgo risinājumu:)
Vēl CI tika papildināts ar pāris pašrakstītiem libraries memcache un gettext supportam. Mamcache gadījumā jauns CI library, kā arī papildnāts sesiju library. Gettext gadījumā updeitots language library.
CI uzliktie izstrādes rāmji (MVC), gan dažreiz mazliet samazina izstrādes ātrumu, taču vairumā gadījumu tomēr palīdz noturēt kodu saprotamu un viegli updeitojamu. Nestandarta situācjās, kad ir vēlme izdarīt to, ko it kā neparedz CI, tas ir elementāri izdarāms griežoties pie CI instances pa tiešo ($CI = & get_instance();) un kā tika novērots, tad šis paņēmiens arī nerada kādas vērā ņemamas problēmas noslodzes vai ātrdarbības ziņā.

Dati. Trijotne – mysql, memcache, sphinx. Ar memcache viss bija skaidrs, tiesa gan pie nepietiekoša atmiņas daudzuma sāka rasties ievērojama CPU noslodze, bet tas vairāk bija dēļ tā, ka uz 1GB RAM tika mēģināts palaist visu, visu – webserveri, mysql, sphinx, memcache utt. Protams, ka tas dzelzis nīka ārā, jo 2Gb bija swapā:)
Ar mysql pagaidām cīnos, jo performance salīdzinājumā ar pārējiem datu handleriem ir nožēlojama un man pagaidām nekādi neizdodas to panākt ciešamu. Taisnības labad gan jāsaka, ka neesmu vēl īpaši mēģinājis tur kaut ko optimizēt. Īpaši vērā ņemams lēnums ir attiecībā uz kombināciju “insert on duplicate key update ”.  Atsevišķās vietās nācās arī nomainīt insertus ar “delayed insert” un sekojošu innodb -> myisam pāreju attiecgajām tabulām. Frontend galā tīru select uz mysql gandrīz nav nemaz – tiešajiem datu selektiem starpā memcache, datu atlasēm – sphinx.
Attiecībā uz mysql, nākamais pētāmo lietu sarakstā ir Falcon storage engine, bet par to man pagaidām komentāru nav.
Ar sphinx bija dažas nianses attiecībā uz datu indeksēšanu un patiesībā vairāk uztveramas kā sphinx bugs, bet par to tagad sīkākos iztirzājumos neizplūdīšu. Galarezultātā un arī pateicoties mysql lēnumam, sphinx tiek izmantots krietni plašāk, nekā biju plānojis sākumā. Plānots bija tikai geo lietām, bet tagad tas darbina arī visādas datu relāciju lietas, kā arī indeksētus filtrus, keywordus, fulltext search utt. Vienīgā problēma ir neliela datu izmaiņu aizture, bet ar dažādiem paņēmieniem to ir izdevies samazināt līdz minimumam (1-2sec). Patiesībā ir doma kaut kad tās sphinx lietas tīri no praktiskā viedokļa iztirzāt atsevišķā bloga ierakstā.

Client side , UI risinājumi. Ļoti daudzveidīgi. It kā vairums gatavu risinājumu – jqueryUI, ajax forms, jcrop, swfupload,  utt, bet lielu daļu nākas stipri pielāgot gan vizuāli, gan funkcionāli. Atsevišķs stāsts varētu būt par Google Maps API, priekš kā pat sākotnēji tika uztaisīta tāda lieta kā marķeru nepārklāšanās princips – čekojot marķeru atrašanās rādiusus, jeb poligonus. Diemžēl pagaidām šo principu esmu atslēdzis, jo Internet Explorer javascript renderēšanas ātrums ir vismaz 10x mazāks, nekā jebkuram citam browserim un nekas nav mainījies arī IE8. Iespējams, ka nāksies atteikties arī no ajax json datu saņemšanas principa – arī šī paša iemesla pēc. Par IE runājot – arī IE6 vizuālā renderēšanas īpatnības hvz cik papildus izstrādes laika prasošas un droši vien ir saprotama problēma jebkuram web izstrādātājam:)

Nobeigumā, jeb secinājums. Ir sajūta, ka aptuveni mēnesis pirmsizstrādes izpētes un plānošanas laika ir bijis gana noderīgs, jo ir izdevies izvairīties no nopietnām problēmām pašos izstrādes principos un lietojamajos rīkos. Lielākā problēma patiesībā bija koncepcijas iztrūkums pašam projektam – tikai tādas vīzijas skiču un mutiskā veidā. Attiecīgi neiespējami kaut ko pietiekami precīzi izplānot laiku un resursu ziņā. Tas, protams, aiz sevis pavelk arī tādas lietas kā prasību maiņas, redizainu utt. It kā jau visu paši arī daram – paši domājam kā labāk, paši pēc tam pārtaisam, bet manuprāt ir ļoti lietderīgi vienreiz pasēdēt un patiešām padomāt, nevis ķert karstu un sākt taisīt pat īsti neapjaušot ko:) Tas tā – it kā mācība priekšdienām, kura tomēr vienmēr atkārtojas no jauna:)

Mazliet paturpinot php gettext lietas. Šovakar tā padomāju, a kā būtu iebarot gettext binārā faila veidotājam “msgfmt” iebarot datus no stdin. Paskatījos help, jā ir tāda iespēja – parametrs “-”. Domāts, darīts – 10min un man ir gatavs mysql->gettext exports.

mysql tabula “transl” ar laukiem lng, id un str.

php:

#!/alx/php5-fcgi/bin/php -q
msgid ""
msgstr ""

"Content-Type: text/plain; charset=utf-8\n"

<?
$sql = new mysqli("host", "username", "password", "database");
$res = $sql->query("select id,str from transl where lng='lv_LV'");
while($obj = $res->fetch_object()){
echo "msgid \"".$obj->id."\"\nmsgstr \"".$obj->str."\"\n\n";
}
?>

un konsolē

$ ./export_strings.php |msgfmt - -olang.mo

un viss… man ir gatavs strādājošs lang.mo fails
Ja nu vienīgi vēl vajadzēs paskatīties, kas notiek ar “sliktajiem” simboliem msgid un msgstr virknēs, bet tas jau sekundāri.

Principā, lai viss neizvērstos par tukšu teorētisku pļāpāšanu, pieņemšu, ka man ir projekts ar web interfeisu, bāzēts uz php, mysql, memcache – šobrīd populārākajām lietām. Latvijas mērogiem pa lielam tas viss vēl būtu salikts uz viena fiziska dzelža. Labākā gadījumā atsevišķi nodalīts mysql.

Turpināt lasīt »

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ā:)

Šodien atkal saskāros ar vajadzību sqlā iekļaut vecuma filtru, bet db lauks ir date. Protams no performances viedokļa labāk būtu šīs konvertācijas atstāt php pusē, bet tā kā man vajadzēja tikai uzzināt reģistrēto useru skaitu konkrētā vecumu grupā, tad šoreiz ērtāk bija to ļaut darīt mysql.
Īstenībā pastāv daudz veidi kā piespiest mysql izdabūt vecumu no date, bet ne visi diemžēl ir precīzi – pie vainas pārsvarā garie gadi.
Pieminēšu populārākos:

ROUND((CURDATE() - birthday)/10000) AS age

Uzreiz brīdinu – nav precīzs, bet šo variantu var izmantot, ja būtiski ir ātri uzzināt aptuveno vecumu dalījumu.
Precīzāks veids un labs ar to, ka neizmanto lēnās DATE_FORMAT f-jas:

YEAR(NOW()) - YEAR(birthday) - (DAYOFYEAR(NOW()) < DAYOFYEAR(birthday)) as age

Birthday, protams, ir lauka nosaukums mysql tabulā. Tips – date.
Īstenībā arī otrs variants performē ļoti labi – vismaz uz 3 ļimonu tabulu rezultāts tiek sasniegts jau 0.0x sec.