webandphp-logoKaut kad sen jau Twitter dalījos ar informāciju par “Web & PHP magazine“. Šķiet ka tas bija tad, kad iznāca tā pirmais numurs. Tagad jau pieejams 11. žurnāls. Nolēmu ka arī blogā jāpadalās ar info. Tātad, ja gribi bez maksas lasīt žurnālu par Web un PHP lietām, tad noteikti ieskaties http://webandphp.com/. Lejupielādes pieejamas pēc autorizēšanās (turklāt var tikt klāt arī vecajiem numuriem). Neskatoties uz to ka žurnāls ir bezmaksas, tajā var izlasīt noderīgu informāciju. Ja nu tomēr ir vēlme lasīt kādu maksas žurnālu, tad ir alternatīva: PHP Architect .

Atgriežamies pie “Web & PHP magazine”. Jaunākā numura saturs:

  • PHP In The Cloud By Frédéric Harper
  • Start Searching With Solr By Tyler Harms
  • Develop Your Agile Mindset By Steffan Surdek
  • Database Indexing Part 2 By Cory Isaacson
  • PHP UK Conference Preview By Ciarán Rooney
  • Presenting For Geeks EBook Teaser By Dirk Haun
  • Level Crossings And Traffic Jams By Stefan Priebsch


laravelIetvaru (framework) izmantošana programmēšanā krietni paātrina programmēšanas ātrumu. Tādēļ daudzu projektu pamatakmens ir nekas cits kā ietvars. Reizēm tas ir kāds Open Source projekts, reizēm programmētāja (vai uzņēmuma) paša dzejots. Es uzskatu, ka individuāliem programmētājiem paša rakstīts ietvars ir lieka greznība un ir jāizmanto kāds Open Source ietvars. Protams, to atbilstoši pielāgojot. Uzņēmumos resursu vairāk un var ietvarus rakstīt paši, bet arī šajā gadījumā nedrīkst ignorēt dažādas komponentes, kuras var izmantot jau no esošiem ietvariem (reizēm nekas cits neatliek kā rakstīt ietvaru pašiem, ja ir kādas ļoti specifiskas prasības).

Kādu laiku atpakaļ es izmantoju Zend Framework. Gāja laiks un pienāca tas brīdis kad jāizvēlas jaunu. Bija jau parādījies Zend Framework 2, Symfony 2, arī Yii piesaistīja uzmanību. Nekādi nevarēju izvēlēties kuru izmantot. Tad uztrāpīju tādam veidojumam kā Laravel. Dažas video pamācības vēlāk sapratu, ka tas ir tas ko gribēšu pamēģināt. Iemesls vienkāršs – Laravel ir vidusceļš starp tādiem monstriem kā Zend Framework/Symfony un mikro ietvariem. Pagāja kāds laiks (mērāms pāris mēnešos, ja atmiņa mani neviļ) un pienāca diena, kurā nolēmu – šodien mācīšos Laravel. Ķēros pie viņu dokumentācijas studēšanas, paralēli taisot nelielu Web lapu. Nepilnas dienas laikā biju no 0 apguvis ietvaru, kā arī uztaisījis lapu. Tas liecina par to, ka ietvaru var ātri apgūt, kā arī taisīt lapas ar viņu ir ātri. Protams, neesmu šobrīd Laravel eksperts, kā arī lapa bija vienkārša, taču ar šo dienu man pietika lai saprastu, ka vairākus nākamos projektus taisīšu ar Laravel. Iespējams, ka pēc tam pārdomāšu un pamēģināšu kādu citu ietvaru, bet šobrīd Laravel būs izvēle numur viens.

Pie Laravel notiek aktīva izstrāde. Lietotājiem pieejama 3.versija, bet drīz jau vajadzētu būt pieejamai arī 4.versijai, kurā būs vairāki uzlabojumi. Ja tev ir vēlme, vari piedalīties Laravel izstrādē, dodies uz Github un taisi fork.

Dažas no lietām, kuras man patīk Laravel:

  • Tajā tiek izmantotas daudzas lietas no jau esošiem projektiem. Piemēram, Symfony. Un pareizi vien ir. Kādēļ lai taisītu no 0 kaut ko tādu, pie kā cilvēki pavadījuši daudzas stundas un izveidojuši labus risinājumus. Runājot par Symfony, ar vienu komandu ir iespējams Laravel ieimportēt visas Symfony komponentes.
  • Ir visas pamatlietas, kuras ietvarā vajag: datu bāzu abstrakcijas līmenis, kešošana, CLI interfeiss, ērta uzstādīšana, filtri, validēšana, templeiti, spēcīgs routings, DI, šifrēšana, UT, datu bāzu migrēšana un citas lietas.
  • Netiek uzspiests konkrēts lapu veidošanas vieds. Vari veidot lapas izmantojot kontrolierus, vari tos neizmantot, vari izmantot RESTful kontrolierus utt.
  • Bieži tiek izmantotas anonīmās funkcijas, kā funkcijai nododams parametrs.

Tā īsti nevaru šobrīd uzskaitīt lietas kuras nepatīk. Varbūt stils pašam ietvaram ir nedaudz netipisks, jo tiek daudz izmantotas statiskās metodes, bet no otras puses, reizēm tas ir ļoti ērti no lietošanas viedokļa. Domāju, ka “nepatīk” sadaļa uzaugs laika gaitā.

Ja vēlies apgūt Laravel, tad lūk daži resursi:

  • Oficiālā dokumentācija
  • Ir vismaz 2 grāmatas. “Laravel: Code Happy“.  Šo neesmu lasījis. Kā arī “Laravel Starter“. Esmu lasījis. Pirkt neiesaku. Šī grāmata ir starter grāmatu starteris
  • Vimeo var redzēt dažus video par Laravel 4. Un šeit var redzēt dažus oficiālos video par Laravel 3. 
  • TutsPlus ir “Laravel Essentials“. Laba video sērija. Ja ir pieeja TutsPlus iesaku noskatīties. Ja pieejas nav, bet Laravel ļoti, ļoti interesē, padod ziņu, varbūt ka sarunāsim. 


Nospriedu ka pienācis laiks sākt spēlēties ar PHP 5.4. Ir gan viņam vēl viens otrs nelabs bugs, bet gan jau drīz atrisinās.

Linux lietotājiem DLL medīšana ir sveša lieta, bet tiem kas mēdz PHP darbināt Windows vidē, DLL medības ir neatliekama dzīves sastāvdaļa. Turklāt jo svaigāka PHP versija, jo trakāk viņai sadabūt normālus DLL failus. Nedaudz parakājos pa tīmekli un atradu 4 sev vajadzīgos (ja vajadzēs vēl – pievienošu sarakstam). Šis ieraksts ir gan kā arhīvs sev, gan laika ietaupīšanai citiem.

Zemāk dotie DLL faili strādā ar PHP 5.4.4 TS (MSVC9).

APC Version 3.1.12 (beta) => php_apc.dll
Imagick Version 3.1.0RC2 => php_imagick.dll
Memcache Version 2.2.6 => php_memcache.dll
Xdebug Version 2.2.0 => php_xdebug.dll


Beidzot taču jāsāk rakstīt par grāmatām kuras esmu izlasījis. Tad nu pēdējā bija “Pro PHP refactoring”. Uz vāka vēl rakstīts “Learn the principles and patterns and tools to improve your PHP code”. Par to arī ir grāmata. Grāmata ir vidēja biezuma, 360lpp, daudz koda gabalu, tāpēc lasās ātri. Tiek teikts, ka ar grāmatas palīdzību varēsim iemācīties (gribēju tulkot, bet sapratu, ka tulkotu versiju grūtāk uztvert kā angļu):

  • What refactoring is and why you need to refactor code
  • What test-driven design is and why you need to test your code
  • How to write unit and functional tests with PHPUnit and Selenium Remote Control (RC)
  • How to detect “bad smells” in PHP code, and refactor them using test-driven design
  • How to refactor a large procedural application affected by many bad smells

Grūti pateikt vai to visu varēja iemācīties. Jā – ieskats tiek dots pietiekošs, bet nevar izlasot grāmatu uzreiz to visu aptvert. Normāla strādāšana TDD režīmā prasa pamatīgu domāšanas maiņu, ja iepriekš tas nav darīts. Turklāt rakstīt testus tādiem piemēriem kādi ir grāmatā doti ir viena lieta, bet reāliem kodiem ir grūtāk. Lai nu kā, nenoliegšu, TDD garšu var sajust un pareizu pieeju arī var manīt.

Visa grāmata sastāv no aptuveni šāda scenārija: dota problēma, dots risinājums vienā teikumā, dots pamatojums, solis pa solim kā to izdarīt, koda piemērs. Ļoti laba pieeja. Varētu gan nedaudz šur tur piesieties autoru valodai vai izvēlētajiem piemēriem, kā arī gala rezultātam, bet bez tā jau laikam neiztikt katrā grāmatā. Lielākā daļa no grāmtas (~300lpp no 360lpp) nav tieši par PHP, bet ir pielietojams jebkurai OO valodai. Pēdējās 60lpp gan var sajust pamatīgu PHP garšu tā sliktākajā izpausmē. Tur ir dots vecs, nejauks PHP kods. Tāds kurš spēcināts ar SQL injekcijām, HTML nav nodalīts, viss funkcijās un izmētāts pa failiem. Autori dod piemēru kā šo murgu var pārtaisīt relatīvi smukā OO kodā, kurš turklāt tiek automātiski testēts. Sadaļa noderīga, jo labi ilustrē cik ļoti, ļoti liels darbs ir jāveic lai kaut ko tādu kvalitatīvi izdarītu. Kā arī parāda ka tas nav neiespējami.

Vēl piebilde, ja ir lasītas Refactoring: Improving the Design of Existing Code vai Clean Code: A Handbook of Agile Software Craftsmanship tad šī grāmata būs lieka (nu varbūt tikai pēdējās 60lpp noderēs, kur parādīts kā tikt galā ar PHP ķezu). Var just ka autori no abām grāmatām ir krietni ietekmējušies. Ja šīs grāmatas nav lasītas, tad nu tā ir nākamā lasāmviela pēc Pro PHP refactoring.

Padoms – kad grāmata izlasīta, nevajag to likt plauktā. Turi uz galda un pamēģini pielietot dzīvē. T.i. – skaties savu kodu, pamēģini izdomāt kuru no refactoring metodēm tu izmantotu, atšķir grāmatu pārliecinies vai tāda tiešām der, tad ievērojot tur dotos soļus mēģini īstenot. Bez pamatīgas pielietošanas praksē nav jēgas lasīt, pretējā gadījumā ātri vien aizmirsīsies.

Nevaru saprast cik daudz punktus grāmatai dot. Nu labi – lai iet 7 no 10.


Tie, kuri mēdz lasīt manus tweetus iespējams pamanīja, ka iepriekšējā nedēļā biju devies uz Veronu, Itālijā, lai apmeklētu PHP veltītu konferenci – phpDay 2012. Vairāk par pašu konferenci var izlasīt http://2012.phpday.it

Šī bija pirmā PHP veltītā konference, kuru līdz šim sanācis apmeklēt. Šī gan nav vienīgā, kura tiek organizēta, to ir daudz. Nākamā, piemēram, būs Dutch PHP Conference jau pēc pāris nedēļām. Līdz šim konferences vienmēr man ir bijušas pārāk dārgas (piemēram, Dutch PHP izmaksas būtu 630EUR + tikpat, lai tur nokļūtu un kādā miteklī naktis pārlaistu). Veronas gadījumā konference maksāja kādus 150EUR un arī nokļūšana/dzīvošana bija krietni lētāk kā citos gadījumos, tādēļ nolēmu nelaist pasākumu garām.

Uzreiz jāsaka, ka biju patīkami pārsteigts par to, kādā kvalitātē viss pasākums noorganizēts. Gan laba vieta, gan daudz pārtikas un dzērienu, gan Social night, gan bezmaksas krekli utt. Vispār varu nosaukt tikai divus trūkumus – ļoti slikts WiFi un viena no telpām bija pārāk maza (līdz ar to populārākajās prezentācijās tautai bija jāstāv kājās). Bet nākošajā gadā tas tikšot novērsts. Domāju, ka pārtikā vien varēja noēst krietnu daļu no summas, kas samaksāta par konferenci. Verona pati par sevi ir skaista pilsēta, līdz ar to garlaicīgi nebija arī brīvajos brīžos. Bet ne jau pārtika vai pilsētas arhitektūra ir tas, kādēļ tur braucu.

Es ikdienā sekoju PHP top cilvēkiem viņu blogos, Twitter utt. Līdz ar to bija patīkami redzēt un dzirdēt vismaz daļu no viņiem dzīvajā. Jā, slavenību nebija gluži tik daudz kā lielākās konferencēs, bet bija OK.

Pašas prezentācijas/runas/uzstāšanās arī bija interesantas. Ne jau viss, bet lielākā daļa. Piemēram, man īsti neinteresē Symfony vai kaut kas tik sarežģīts, kā paplašinājumu programmēšana, kā arī nesaprotu itāļu valodu, tāpēc automātiski atkrita kāda 1/3 daļa no visām prezentācijām. Bet atlikušajās 2/3 atradu sevi interesējošas lietas. Par dažām no tām:

  • Bija patīkami dzirdēt to, ko teica Rasmus (PHP tēvs) par PHP pirmsākumiem, par to, kā tas tika attīstīts, cik izplatīts PHP ir, kā arī, kas jauns ieviests PHP 5.4, kā attiecīgās lietas izmantot, kā arī, kā tās labāk neizmantot.
  • Konferencē uzstājās vairaki cilvēki no Etsy. Viņi piekopj ekstrēmu Agile darbu plūsmu. Vidēji katru dienu tiek publicētas 36 jaunas Etsy versijas. Varēja iepazīties ar to, kādus rīkus viņi izmanto, kā viņi koordinē komandas, kā tik trakā jaunu versiju daudzumā viņi saprot kur un ko skatīties, lai neiekristu kādās drošības problēmās. Vērtīga pieredze visiem Agile piekritējiem.
  • Tiku iepazīstināts ar DataSift arhitektūru. Kā viņi spēj noprocesēt nenormālo datu apjomu (jauni 2TB katru dienu) un piedāvāt analīzi reālā laikā.
  • Biju uz pāris prezentācijām par API – galvenokārt REST un HTTP servisiem kā tādiem. Viena no prezentācijām bija vairāk par ideju, kas ir labi un kas nav labi, otra krietni tehniskāka ar piemēriem, kā taisīt lietas un kā netaisīt. Pat tie, kam REST bija svešvārds, varēja iegūt pietiekami daudz informācijas, lai justos komfortabli runājot par REST.
  • Biju aizgājis paklausīties par Phing (build sistēma PHP). Tā kā man nav svešs Ant piegājiens šai lietai, tad arī Phing likās visai sakarīgs. Iespējams, ka pat pamēģināšu dzīvē.
  • Bija vairākas prezentācijas par tādām lietām, par kurām ikdienā neaizdomājos. Piemēram, par datu struktūrām (PHP pierasts visu mest masīvos, bet tā nav maģiska lode visiem gadījumiem), par to kā rakstīt optimizētāku kodu, par nedaudz netipiskākām lietām (kā, piemēram, par Streams), par darbu Agile vidē utt.

Pēdējās dienās vairākas reizes esmu saņēmis jautājumu – kāda jēga apmeklēt konfereneces, ja grāmatās/internetā var izlasīt to pašu, ko konferencē dzirdēt. Mana atbilde būtu – konference jau nav tikai prezentācija, tas ir sociāls pasākums. Tā ir iespēja būt to cilvēku vidū, kuriem ir tādas pašas intereses, kuri risina tādas pašas problēmas. Ja ir kas jautājams, tad var pajautāt tādiem cilvēkiem, kurus ikdienā neaizsniegt. Ja konference būtu plika prezentācija, tad tā būtu lekcija. Turklāt tie, kas prezentē lietas, māk (lielākajā daļā gadījumu) savu sakāmo pateikt tā, ka tas ātri vien kļūst skaidrs un pelēkajās šūnās aizķerās uz ilgāku laiku. Konferences ir laba lieta. Taču jāizvērtē ir to, vai cena ir saprātīga. Veronas gadījumā (man šķiet), ka tā tas ir un es noteikti nenožēloju, ka tur devos. Visticamāk, ka došos arī nākamajā gadā. Varētu nedoties tikai gadījumā, ja viņiem neizdosies piesaistīt interesantus runātājus. Bet esmu pārliecināts, ka nākamajā reizē būs vēl interesantāk.


Ik pa laikam interneta plašumos uzvirmo sarunas par to vai PHP ir slikts vai labs. Parasti gan vairāk par to cik PHP ir slikts. Kā arī PHP programmētāji tiek uzskatīti par iesācējiem, tirliņiem skriptu bērnu līmenī, pati valoda tiek uzskatīta par kaut kādu aizvēsturisku šablonu salipināšanas valodu. Un visbiežāk pretī tiek celti tādi zvēri kā Python un citi. Varētu iesaitēt uz n-tajām diskusijām, bet gan jau tie, kuriem šis jautājums interesē, tāpat zinās kur informāciju meklēt. Nedaudz novēloti, bet arī es gribu izteikt savu viedokli šajā jautājumā. Tomēr 7 gadus programmēju ar PHP un uzskatu, ka pa šiem gadiem ir izveidojies visai objektīvs viedoklis par valodu kā tādu.

Uzreiz gribu pateikt, ka es tagad nesākšu pelt vai cildināt citas valodas – nav man tādu zināšanu, lai varētu izvērtēt kas ir labs un kas nav labs.

Jā – savulaik mēs varējām uztvert PHP kā līmi, lai salipinātu dažādus HTML gabalus kopā, kā arī nedaudz apstrādātu lietotāja pieprasijumus un šo to padarīt ar datu bāzēm/failiem. Ja paskatīsimies vecākas PHP grāmatas redzēsim ka PHP savulaik pat tika mācīts nepareizi (no šodienas skatpunkta). Bet tās bija tā laika prasības pret valodu, kuras šī valoda arī apmierināja.

Gāja laiks, prasības mainījās. PHP kļuva iespējām bagātāks. Kas šajā laikā radās kā blakusprodukts? Nekonsistence funkciju parametros, dažādas backward compability lietas (t.i. – saderības vārdā ilgi jo ilgi tiek atbalstītas nejēdzības) un citi brīnumi. Turklāt tas kā PHP ir veidots (piemēram, brīva lēkāšana starp dažādiem datu tipiem utt.) dod iespēju taisīt dažādas nejēdzības tur, kur tām nevajadzētu būt. Kā arī PHP aizņemās dažādas lietas no citām programmēšanas valodām, kas rada visai izteiktu PHP specifisku – lieta X, kas izskatās pēc Y no valodas Z īsti neuzvedās kā Y, bet kā Y līdzinieks ar piedevu K. Bet tas nav nedz labi, nedz slikti – tāds ir PHP.

Un tādu – kā augstāk aprakstīts – PHP redz daudzi jo daudzi pārbēdzēji, daudzi iesācēji, daudzi tie, kas vispār ar PHP īsti nav tā kārtīgi strādājuši. Es nesen parakņājos pa PHP forumiem un jautājumu dēļiem (lasi SO) – tur ir kaudzēm PHP jautājumu. Turklāt no iesācēju tēmas. Un kā jums šķiet, kā izskatās viņu kods? Gluži tā kā pirms 6 gadiem mācīts grāmatās, kuras jau sen vajadzēja sadedzināt. Pamatīgs spageti, vienā failā kopā pieprasījumi datu bāzei, datu apstrāde, kurā pa vidu iemiksēti HTML fragmenti utt. utml. Protams, kaut ko tādu redzot, nevar rasties labs viedoklis par PHP. Un problēma ir tāda, ka daudzi PHP programmētāji tā arī nekad pāri šim līmenim netiek. Viņi ikdienā strādā/uztur tādu spageti un tādu paši arī ražo. Ja es būtu palicis šādā līmenī vai arī ja man ikdienā būtu jāstrādā ar kaut ko tādu, gan jau arī aizmuktu un lamātu PHP.

Bet. Ziniet ko – tā ir tīri programmētāja vaina. PHP ir ērts, labs, funkcionāls rīks, ja to māk pareizi lietot. Gluži tāpat kā C4. Ērta un stabila sprāgstviela, bet nepareizi lietota var uzlaist gaisā arī ne to ko plānots. Un ja kāds darbojoties ar C4 sevi uzlaistu gaisā, ko vainotu – C4 vai personu? Te arī mana atbilde. Vajag izaugt pietiekoši tālu un tad PHP vairs nebūs kā skabarga vienā vietā, bet kārtīgs rīks.

Es ar PHP esmu taisījis gan lapas ar dažām koda rindām, gan tādas kuras strādā uz daudziem serveriem un tās darbina miljoniem lietotāju. Ir iespējams ar PHP taisīt lielus projektus. Ir iespējams nodalīt atbildības sfēras. Ir iespējams taisīt testējamu kodu (testē pēc tam kaut vai ar PHPUnit vai Selenium). Ja šķiet, ka PHP dod parāk lielu brīvību un ir bail ka pats vai komandas biedri novirzīsies no kāda standarta – uzliekam CodeSniffer, sadefinējam noteikumus un nebūs nepareizu konstrukciju kodā. Ar snifferi kods var būt ļoti strikti konstruēts. Un ar laiku dažādi PHP stiķi un niķi jau kļūst zināmi. Gadās pa kādam WTF momentam, bet atļaušos uzskatīt ka tas tā ir katrā valodā. Ja kāds atļaujās teikt, ka ar PHP nevar taisīt kvalitatīvu produktu, tad, piedodiet, bet šis cilvēks vienkārši nav tik tālu izaudzis, lai saprastu ka kļūdās. Iespējams, ka citās valodās var visu vēl smukāk uztaisīt, neesmu eksperts, lai to zinātu. Bet ir skaidrs, ka arī ar PHP to var izdarīt. Turklāt ātri. Turklāt gala produkts ir viegli piemērojams lietošanai pie lielām slodzēm. Ja kāds uzskata citādāk, satiksimies pie alus vai kafijas un pastāstīšu kāpēc tu kļūdies.

Par sevi varu teikt, ka savulaik par PHP esmu lamājies, bet sen jau ir skaidrs, ka no PHP atteikties nedomāju. Protams, zināšanu paplašināšanai gan jau nedaudz apgūšu arī Python un citas valodas. Taču neredzu nevienu iemeslu kādēļ lai es tuvākajos gados atteiktos no PHP. Turklāt lieli projekti jau nav vairs tikai PHP. Tas komplekss pasākums – PHP, datu bāzes (relāciju un NoSQL), JS (klienta un servera pusē) utt., utjp. Un PHP kā starpnieks starp visiem šiem ir labs.

Kopsavilkums: Ar PHP viegli taisīt drazu; daudzi drazu ir taisījuši, taisa un taisīs; PHP ir piemērots lieliem projektiem un tie kas uzskata ka nav piemērots, jūs maldāties (viss ko jūs varat apgalvot ir tas, ka jūs vai jūsu komandas biedri nemācēja PHP pareizi pielietot); iespējams ka valoda X ir elegantāka par PHP, bet tas nenozīmē ka pareizi pielietots PHP ir slikts.

P.S. Ja kāds komentāros sāks ielaisties bezjēdzīgā trololo, es neiesaistīšos.


Kad pamanīju, ka top grāmata par Google Maps API 3, tad ļoti nopriecājos, jo nav daudz grāmatu par šo tēmu. Situācija izveidojās pat tāda, ka saņēmu vienu grāmatas eksemplāru, lai uzrakstītu apskatu. Beidzot esmu saņēmies pavēstīt par to, kāda grāmata sanākusi.

Grāmatas nosaukums ir “Beginning Google Maps API 3” un tās autors ir Zviedrijā dzīvojošais Gabriel Svennerberg. Nav no tiem biezākajiem darbiem – pavisam nedaudz virs 300lpp.

Grāmatā apskatītas sekojošas tēmas:

  • Kas vispār ir Google Maps API
  • Ar ko Google Maps API V3 atšķiras no iepriekšējās versijas (v2)
  • Kā uztaisīt pašu elementārāko karti (līdz ar to arī kas ir HTML, CSS, JS)
  • Sarežģītākas kartes izveide (dažādu opciju apskate)
  • Marķieri
  • Ikonas
  • Info logi
  • Poligoni (daudzstūri) un līnijas
  • Kā apstrādāt lielu skaitu marķieru
  • GEO lietas (IP, atrašanās vieta utml).

Uzreiz jāsaka, ka šī grāmata tiešām atbilst tam, par ko liecina vārds “Beginning”. Tātad – iemācīties darboties ar kartēm var pat tādi, kuri no programmēšanas nesaprot teju neko. Ne velti ir doti pat HTML un JavaScript paši pamati. Protams, programmēšanas pieredze (un vēl jo vairāk, ja ir pieredze ar Google Maps API v2) palīdz visu saprast daudz ātrāk. Tiem, kam ir pieredze pietiks ar vienu dienu, lai tiktu galā ar grāmatu. Tiem kam nav, protams, vajadzēs vairāk laika, taču autora rakstīšanas stils ir tik vienkāršs, ka neparedzu nekādas īpašas grūtības tēmas apguvei. Visi piemēri ir doti soli pa solim, līdz ar to nevienā brīdī nevajadzētu rasties jautājumam – kā nokļuvām līdz “šim”?

Ļoti vērtīga nodaļa ir par to, kā atšķiras v2 no v3. Lai gan teju visu jau zināju, tomēr patīkami izlasīt stukturētu skaidrojumu kas, kā un kāpēc. Ja esat strādājuši tikai ar v2 un domājat par v3 – noteikti iesaku, jo aiztaupīsiet sev vairākus izmisuma brīžus. Visas problēmas, ar kurām pirms tam biju saskāries pašmācībā apgūstot v3 šeit jau bija apstāstītas un doti risinājumi.

Vēl viena lieta, kas ļoti patika ir saites uz dažādiem resursiem. Piemēram, brīdī kad autors stāsta par to kā tikt galā ar līnijām (vai jebkuru citu tēmu, kur būtu nepieciešams palasīt papildus) ir dota saite uz dažādiem ārējiem resursiem. Kopā ar ‘Warning’ un ‘Tip’ sadaļām – nenovērtējami.

Ir lietas, kuras bija liekas. Piemēram, doti piemēri tam, ka izskatās marķieri dažādās krāsās… bet grāmata melnbalta. Aptuveni 50lpp ir veltītas API reference. Būtībā tas ir teju pārkopēts Google Maps API Reference . Kāpēc ‘teju’? Tāpēc, ka pie vairākām funkcijām ir autora paša skaidrojums (Google var vispār nebūt skaidrojums vai arī autors pārfrāzējis tā, lai vieglāk saprast). It kā jau tas ir noderīgi, taču manā skatījumā lieki, jo: API mainās, līdz ar to šī sadaļa visai drīz būs veca; pārāk daudz vietas iztērēts uz šo – labāk būtu vēl kāda tēma apskatīta.

Kopsvalikumā ir šādi:
* Ja neesat ar Google Maps API strādājuši pavisam , tad šī grāmata ir ļoti, ļoti laba. Droši visi 5 punkti no 5.
* Ja jums jau ir pieredze darbā ar Google Maps API v3, tad iegūsiet visai maz jaunas informācijas vai vispār nemaz. Ja esat strādājis tikai ar v2, tad grāmata ir ļoti ieteicama, jo palīdzēs tikt skaidrībā ar dažiem atslēgas konceptiem, tādā veidā ieekonomēs laiku, kad mēģināsiet apgūt v3 (jā – no 300lpp jums būs adresētas 100, bet tik un tā tas ir tā vērts).

Ceru, ka autors uzrakstīs arī nākamo daļu – ‘Pro Google Maps API 3′. Ja tā notiks – noteikti to grāmatu izlasīšu, jo autors ir pārliecinošs un labi māk pasniegt informāciju.


Šis raksts ir kā pārdomas uz php|a izlasītu rakstu “Programming: you’re doing it wrong“. Izlasīju un aizdomājos, ka pamatdoma ir ļoti precīza – lai kā mēs programmētu, mēs to darām nepareizi. T.i. – programmējot mēs izvēlamies kādu konkrētu pieeju, bet vēlāk izrādās, ka tā nav bijusi pareiza. Lai gan brīdī kad darbs tapa, pieejai nebija ne vainas. Reizām mēs paši sakām, ka mūsu iepriekšēji darbi ir uztaisīti nepareizi, bet visbiežāk citi to saka par mūsu darbiem vai mēs par citu darbiem.

Klasika. Programmētājs A pārņem programmētāja B kodus tālākai izstrādei. Ko A teiks pēc 30min, kuru laikā būs pētījis kodus? Tas !@#$% B visu tik nejēdzīgi (nepareizi) uztaisījis, ka neko te nevar glābt – viss jāmet ārā un jātaisa pareizā veidā. Ja C pārņems darbu no A, ir liela iespējamība dzirdēt tieši to pašu, ko teica A.

Bet lieta jau ir tāda, ka pats programmēšanas stils bieži vien ir sekundārs. Galvenais ir lai kods dara to, ko tam ir jādara. Nav OOP sliktāks vai labāks par funkcionālo programmēšanu. Nav viens patterns labāks par citu. Ja izmantotā lieta dara to kas jādara, tad uztaisīts ir pareizi – neskatoties uz to kā tieši tas ir izdarīts.

Protams, ir jau arī galējības. Piemēram, produkts strādā, bet tā, ka kaut ko pielikt klāt ir problēmas. Bet arī šie gadījumi nav (stipri lielākajā daļā gadījumu) tāpēc, ka izmantota viena vai otra pieeja programmēšanai. Gluži vienkārši programmētājs (vai pasūtītājs) nav ņēmuši vērā potenciālo produkta attīstību. Savukārt ja kods nestrādā (ir kļūdas izpildē, drošības problēmas utt.), tad tur jau nav runas par to ir vai nav pareizi izdarīts.

Ar visu šo es gribēju teikt, ka bieži vien aizraujamies ar viena ideālā programmēšanas veida meklēšanu. Lasām jaunākās teorijas koda strukturēšanā utt. Bet ar to nevajag aizrauties. Protams, ir jāmācās un jāiet laikam līdzi. Vienīgi der atcerēties, ka pat pēc jaunākā modes kliedziena programmētā lieta būs nepareiza, ja vien viņa nestrādās tā, kā paredzēts.