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.

Citi raksti par šo tēmu

• 26.05.2008 -- “Zend Framework in Action” review (1)

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.

Citi raksti par šo tēmu

• Nav citu rakstu par šo tēmu.

Tad nu lūk. Ir tāda Web lapa – http://www.zendcasts.com, kurā apkopoti vairāki screencāsti (šim vārdam latviskojums vispār ir?) par un Zend Framework. Autors par lapu saka šādi:

Zendcasts is a weekly podcast in screencast format covering different parts of the Zend Framework, a PHP framework designed for developing enterprise application development. The site was launched at the beginning of 2009 and is managed by Jon Lebensold.

Nu jau video skaits ir ~ 30 un regulāri tiek pievienoti jauni. Apskatītās tēmas ir ļoti dažādas. Sākot no pavisam elementārām, beidzot ar tēmām, kuras būs interesantas jau pieredzējušākiem Zend Framework lietotājiem.

Turklāt šiem screencastiem ir vairākas ļoti labas īpašības:

• Runātājam ir laba izteiksmes forma. Visu var labi saprast. Nav čarkstoša skaņa vai murmināšana zem deguna.
• Video ir liela izšķirtspēja – nav nepieciešams samiegt acis, lai kaut ko redzētu, turklāt viss rādāmais ielien kadrā.
• Video ir svaigi. Tas nozīmē, ka nebūs šajās pamācībās novecojusi informācija.
• Video var ne tikai skatīties Web pārlūkā, bet lejupielādēt arī iTunes.

Citi raksti par šo tēmu

• 28.04.2009 -- Scienta ZF Debug bar – eleganta lieta (0)
• 23.08.2008 -- Pārdomas par ietvaru izmantošanu Web programmēšanā (2)
• 22.07.2008 -- Pieejams Zend Framework 1.6 RC1 (0)
• 26.05.2008 -- “Zend Framework in Action” review (1)
• 15.05.2008 -- Drīzumā grāmatas Zend Framework in Action recenzija (0)

Izskatās tas šādi:

Šāda rīkjosla tiek parādīta apakšējā kreisajā stūrī pa virsu web lapai. Līdz ar to nekādi neietekmē web lapas izkārtojumu/dizainu.

Kā jau pēc bildes noprotams – ir iespējams redzēt kāda Zend Framework versija tiek izmantota, kādi mainīgie piesaistīti skatam (View variables, Cookies, Request), cik pieprasījumi veikti datu bāzei (kā arī redzēt pilnīgi visus pieprasījumus SQL pierakstā, papildinātus ar katra izpildes laiku), cik daudz atmiņas izmantoja skripti, PHP kļūdas, cik pavisam laiks bija nepieciešams (kādi tieši faili no visa lielā ietvara tika ielādēti utt.). Uz katra no mazajiem lodziņiem uzklikšķinot parādās lielāks logs, kurā redzama detalizētāka informācija.

Jāsaka kā ir – ļoti ērts un glīts rīks. Izmantoju tikai vienu dienu, bet jau esmu jutis no viņa reālu jēgu. Līdz ar to šis nu būs neatņemama sastāvdaļa tālākajā izstrādē, kur izmantošu Zend Framework.

Pats Scienta ZF Debug bar lejupielādējams http://jokke.dk/software/scientadebugbar . Tur ir arī atrodama sīkāka informācija par to kā rīks konfigurējams un uzstādāms (izdarāms ar dažu rindiņu palīdzību). Taču ja rodas problēmas uzstādīšanā – jautā – palīdzēšu.

Citi raksti par šo tēmu

• 09.08.2009 -- ZendCasts.com – lielisks resurss ZendFramework apguvei (1)
• 23.08.2008 -- Pārdomas par ietvaru izmantošanu Web programmēšanā (2)
• 22.07.2008 -- Pieejams Zend Framework 1.6 RC1 (0)
• 26.05.2008 -- “Zend Framework in Action” review (1)
• 15.05.2008 -- Drīzumā grāmatas Zend Framework in Action recenzija (0)

Visu, kā jau parasti, var sadalīt divās kopās: labās (pozitīvās) un nelabās (negatīvās) lietas. Negatīvās lietas:

• Bieži (ja ne vienmēr) sanāk strādāt ar slikti vai vispār nedokumentētu kodu. Līdz ar to grūti saprātīgos termiņos izprast to kā īsti viss strādā.
• Lai pieliktu kādu papildus funkcionalitāti visai bieži nākas pārtaisīt kaut ko no vecajām lietām.
• Par Web projektu uzturēšanas izmaksām ir daudz grūtāk vienoties ar pasūtītāju kā gadījumos, ja kāds projekts tik taisīts no 0. Tas tāpēc, ka pasūtītājs nelabprāt pieņem to, ka nākas veltīt ievērojamu laiku sistēmas izpētei, kā arī veco lietu pārtaisīšanai, lai pieliktu kādu papildus funkcionalitāti.
• Papildinot/labojot jau iepriekš iesāktus projektus izpildītājs bieži ir limitēts izmantoto rīku/paņēmienu izmantošanā. T.i. – nākas izmantot tos paņēmienus, kuri izmantoti projektam, pat ja tie nav tie pareizākie. Protams, ne vienmēr, bet bieži. Tas tāpēc, ka pasūtītājs visbiežāk nevēlas tērēt resursus uz kaut kādu lietu maiņu arhitektūrā, jo “viss tak tāpat strādā”.

Pāris pozitīvās lietas:

• Tas ir izaicinājums (bet šis nav attiecināms uz visiem programmētājiem). Taču pārāk bieži sevi izaicināt nevajag. Manuprāt ideālā variantā vajag miksēt. Viens projekts no “uzturēšanas” lauciņa, nākamais veidots no 0.
• Pati interesantākā un noderīgākā lieta ir iespēja mācīties. Pat neskatoties uz to, ka projektos var kādas lietas būt ne tā saprogrammētas (vai izmantoti kādi novecojuši paņēmieni), tajā var būt arī kādi iepriekš neredzēti un noderīgi problēmu risināšanas paņēmieni. Taču šeit ir jāuzmanās. Ne no visiem projektiem varēs kaut ko mācīties. Bet man līdz šim ir sanācis tā, ka visos pārņemtajos projektos esmu atradis kādu interesantu piegājienu noteiktu problēmu risināšanai. Ja nebūtu šis punkts, tad Web projektu uzturēšana būtu daudz, daudz neinteresantāka.

Kādas ir tavas domas par šo tematu?

Citi raksti par šo tēmu

• Nav citu rakstu par šo tēmu.

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.

Citi raksti par šo tēmu

• 09.08.2009 -- ZendCasts.com – lielisks resurss ZendFramework apguvei (1)
• 28.04.2009 -- Scienta ZF Debug bar – eleganta lieta (0)
• 22.07.2008 -- Pieejams Zend Framework 1.6 RC1 (0)
• 26.05.2008 -- “Zend Framework in Action” review (1)
• 15.05.2008 -- Drīzumā grāmatas Zend Framework in Action recenzija (0)

Pats izmantoju sekojošus spraudņus:

• PDT 2.0 – Lai gan jaunākā stabilā PHP Development Tools versija ir ar numuru 1.3, šoreiz nolēmu uzlikt 2.0. Pagaidām strādā bez problēmām.
• JSEclipse - JavaScript rediģēšanai.
• Subclipse - Lai būtu iespēja mijiedarboties ar SVN.
• Target Management – Lai būtu iespēja saslēgt Eclipse ar kādiem ārējiem resursiem izmantojot(FTP, SSH.

Šķiet, ka tas arī viss. Iespējams, ka esmu kaut ko piemirsis. Tas, kas mani vairāk interesē ir: varbūt kaut ko īpašu izmantojat SQL lietām, varbūt kaut kādus modelēšanas rīkus arī izmantojat?

Papildināts Secinājums pēc mēģinājuma pastrādāt – PDT 2.0 ir ļoti nestabils. Ja iespējams – nelietojiet 2.0, bet palieciet pie 1.3!

Citi raksti par šo tēmu

• 25.06.2008 -- Svētki un Eclipse screencasti (0)
• 03.04.2008 -- Kāpēc zaļā gaisma EclipsePDT? (6)

Pilns saraksts ar jaunievedumiem:
* Dojo Integration
- JSON-RPC
- Dojo Data packing
- Dojo View Helper
- Dijit integration with Zend_Form & Zend_View
- Dojo Library Distribution
* SOAP
- SOAP Server
- SOAP Client
- Autodiscovery
- WSDL access
- WSDL Generation
* Preview of Tooling Project in Laborator (see /laboratory folder)
- Command Line Interface
- Project Asset Management
* Unit Testing Harness for Controllers
* Lucene 2.3 Index File Format Support
* Zend_Session save handler for Database Tables
* Paginator Component
* Text/Figlet Support
* ReCaptcha Service
* Zend_Config_Xml Attribute Support
* Character Set Option for DB Adapters
* Zend File Transfer Component
* New Media View Helpers (Flash, Quicktime, Object, and Page)
* Support in Zend_Translate for INI File Format

Interesanta šķiet Zend File Transfer komponente. Lai gan tā ir vēl tikai savas funkcionālās attīstības sākumā, var redzēt, ka šī komponente būs noderīga. Pamatideja ir līdzīga kā formu apstrādē. Varam sadefinēt dažādus nosacījumus. Augšupielādētās lietas tiek pārbaudītas – vai tās atbilst nosacījumiem utt. Tā kā failu augšupielāde ir viena no nedrošākajām vietām dažādās Web aplikācijās, tad ir patīkami, ka būs komponente, kura varētu novērst lielu daļu no potenciālajām problēmām. Vairāk par šo komponenti var palasīt šajā rakstā.

Ja interesē apskatīties prezentācijā un uzdot jautājumus lektoriem par jaunievedumiem Zend Framework 1.6 versijā, tad iesaku reģistrēties Webināram What’s New in Zend Framework 1.6?. Par to kas ir Webinārs rakstīju kādu laiku atpakaļ.

Citi raksti par šo tēmu

• 09.08.2009 -- ZendCasts.com – lielisks resurss ZendFramework apguvei (1)
• 28.04.2009 -- Scienta ZF Debug bar – eleganta lieta (0)
• 23.08.2008 -- Pārdomas par ietvaru izmantošanu Web programmēšanā (2)
• 26.05.2008 -- “Zend Framework in Action” review (1)
• 15.05.2008 -- Drīzumā grāmatas Zend Framework in Action recenzija (0)

Kad pienāca īstais laiks, pieslēdzos attiecīgajai adresei, aizpildīju formu un autorizējos. Firefox sāka kaut ko instalēt, bet pēc procesa beigām tā arī pasākums nepiestartējās. Pamēģināju visu izdarīt ar Internet Explorer un šoreiz viss bija kārtībā. Pieslēdzos šādai videi:

Tātad vide ar vairākiem logiem. Čatošanas iespēja starp dalībniekiem, jautājumu un atbilžu sadaļa, iespēja noregulēt mikrofonu un skaļruņus. Pirmajā mirklī bija apjukums, jo nezināju kā tālāk process notiks. Bet viss bija vienkārši. Lai dzirdētu to ko citi runā ir jāpazvana pa kādu no norādītajiem telefonu numuriem vai arī jāpieslēdzas caur VoIP. Izvēlējos pēdējo variantu.

No sākuma domāju, kā lai izdara, lai es citiem netraucēju. T.i. – lai pa manu mikrofonu neiet kaut kādi skaņas signāli pie viņiem. Bet izrādījās, ka, lai kaut ko pateiktu, ir jāpaprasa attiecīgo iespēju. Tāpēc, ja nevēlaties webinārā runāt, to darīt nevajadzēs. :)

Tieši noteiktajā laikā parādījās vēl viens logs, kurā varēja redzēt pasākuma vadītāja datora ekrānu. Tajā bija atvērta prezentācija par PHP drošību. Stundu un kādas 15 minūtes varēja sekot līdzi slaidiem, kā arī kodu piemēriem, demonstrācijām, un klausīties vadītāja stāstījumā. Gadījumā ja ir kādi jautājumi, tad tos var uzdot ar čata palīdzību. Uz jautājumiem tikai ātri atbildēts.

Katrā ziņā pasākums noderīgs un interesants. Tiek iegūta iespēja piedalīties tādā kā seminārā par kādu no tēmām. Redzēt visu to ko dara vadītājs uz sava datora, dzirdēt sarunas, uzdot jautājumus. Turklāt šis webinārs bija bez maksas. Pāris slaidi no prezentācijas:

Šajā prezentācijā tika pastāstīts par PHP drošības pamatiem. Informācija bija par to, kā rakstot skriptus izvairīties no SQL injekcijām, komandu injekcijām, cross site scripting, sesiju zagšanām un uzspiešanām, cookie drošības problēmām un dažām citām tēmām. Bija interesanti, lai gan liela daļa no informācijas bija visai primitīva.

Citi raksti par šo tēmu

• 26.07.2010 -- Par Nordea vebināru “Personīgo finanšu plānošana” (6)
• 02.06.2008 -- Izvilkums no Google Reader par tēmu PHP, CSS, Ajax, Web (1)
• 09.05.2008 -- Kas jauns gaidāms PHP6 un PHP5.3 ? (6)
• 08.04.2008 -- Atkal uzdevumiņš PHP programmētājiem (19)
• 03.04.2008 -- Kāpēc zaļā gaisma EclipsePDT? (6)

Vēl tikai viena saite uz ralphz Blog tiem, kas vēlas paskatīties screencastus par to, kā darboties ar EclipsePDT. Par šo lielisko programmu rakstīju jau iepriekš. Screencasti attiecīgajā lapā ir vairāki. Apskatītās tēmas – sākot ar uzstādīšanu, beidzot ar XDebug lietošanu.

Citi raksti par šo tēmu

• 16.08.2008 -- Kādus Eclipse spraudņus jūs izmantojat? (1)
• 03.04.2008 -- Kāpēc zaļā gaisma EclipsePDT? (6)