Programmēšana: tu to dari nepareizi

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Š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.

ZendCasts.com – lielisks resurss ZendFramework apguvei

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

ZendCasts.comDažas dienas iepriekš jau Twitterī padalījos ar saiti uz Web lapu ZendCasts. Tad biju arī nodomājis, ka gan jau tie, kam tas interesē būs piefiksējuši. Taču tagad sāku domāt, ka ne jau visi Twitterī man seko, turklāt arī tie kas seko to nedara 24/7. Turklāt arī Google nebūs manu Tweetu noindeksējusi un nevarēs parādīt potenciālajiem informācijas tīkotājiem.

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.

Scienta ZF Debug bar – eleganta lieta

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Ja esi viens no nedaudzajiem Zend Framework lietotājiem (nē – pasaulē to lieto daudzi, bet Latvijā, diemžēl, retais), tad tevi varētu interesēt rīks, kuru dēvē par Scienta ZF Debug bar. Kā jau nosaukums liecina – tā ir rīkjosla ZendFramework aplikāciju kukainīšu ķeršanai. Šķiet, ka citiem ietvariem šādi risinājumi jau ir pieejami krietnu laiku, taču Zend Framework tāds izveidots nesen (jāpiebilst, ka Scienta ZF Debug bar ir trešās puses izstrādāts rīks).

Izskatās tas šādi:

2009-scienta_debugbar

Šā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.

Par Web projektu uzturēšanu

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Kā jau daudzi no jums zinās – es ikdienā nodarbojos ar Web programmēšanu. Viens no darbu veidiem kurus veicu ir Web projektu uzturēšana.  Ar to es saprotu to, ka ir kāds Web projekts, kuru var būt veidojis gan kāds cits, gan es pats un kuram pēc kāda laika jāveic kādus labojumus, papildus funkcionalitātes ieviešanu. Šoreiz gribētu pastāstīt par to, kā es uztveru citu veidoto projektu uzturēšanu. T.i. – ar kādām emocijām es projektus pieņemu un kas ir neatņemama šādu projektu sastāvdaļa.

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?

Pārdomas par ietvaru izmantošanu Web programmēšanā

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

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.

Kādus Eclipse spraudņus jūs izmantojat?

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Šodien paspēlējos ar Eclipse. Biju nodomājis, ka nepieciešams pāriet uz Eclipse Ganymede (3.4) (iepriekš izmantoju Eclipse 3.3). Gribēju, lai izmaiņas ir pietiekami ievērojamas, tāpēc nolēmu sainstalēt vairākus jaunus spraudņus (plugins). Tas viss beidzās ar to, ka Eclipse kļuva tik bremzīgs, ka to vairs nevarēja uzskatīt par labu rīku. Tāpēc saliku jauno Eclipse ar tādiem pat spraudņiem kā iepriekš. Šajā sakarā vēlos uzzināt to, kādus spraudņus jūs izmantojat. Varbūt, ka šādā komunikācijā sanāk vienam otram kaut ko noderīgu ieteikt.

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!

Pieejams Zend Framework 1.6 RC1

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Nepilnu dienu pēc tam, kad uz serveriem tika izlikts Zend Framework 1.6 RC1 Preview, esam sagaidījuši arī Zend Framework 1.6 RC1 versiju. Šajā versijā ir vairāki būtiski jaunievedumi, kā arī izlabotas vairākas kļūdas. Tā kā šī ir tikai Release Candidate versija, tad attiecīgo pakotni nevajadzētu izmantot uz produkcijas serveriem, bet ar to var jau paspēlēties, lai pārbaudītu vai viss strādā. Un ja gadījumā pamanat kādas kļūdas, tad noteikti ziņojiet, lai tās varētu paspēt izlabot līdz fināla versijai. Pirms fināla versijas būs arī RC2. Lielākais papildinājums funkcijās ir Dojo integrācija. Šī implementācija ir veidota tā, lai būtu vienkārši integrēt arī jQuery un citas JavaScript bibliotēkas. Nedaudz žēl, ka izvēlēts tika Dojo, nevis jQuery, jo ar pēdējo es strādāju ikdienā, taču Dojo pat nekad neesmu izmantojis.

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ļ.

Webināri – ērts izglītošanās veids

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Vairākas reizes biju redzējis, ka Zend piedāvā piedalīties kaut kādos mistiskos webināros. Pirms dažām dienām nolēmu, ka jāpapēta kas tas tāds ir. Šoreiz webināra tēma bija “PHP Security”. Tā kā tēma interesanta, tad aizgāju un piereģistrējos. Uz e-pastu saņēmu saiti, kur varēs piedalīties webinārā, kā arī paroli pasākuma pieejai.

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.

Svētki un Eclipse screencasti

Ierakstīts kategorijā PHP utml., Saites, Viss cits | Autors: Endijs Lisovskis |

Pēc katrām garākām brīvdienām atkal apjaušu to, cik šādas brīvdienas ir destruktīvas. Destruktīvisms izpaužas jo īpaši stipri nevis pašās brīvdienās, bet dažās nākamajās darba dienās. Šobrīd ir tā, ka nedēļa jau ir pusē, bet ir pirmdienas sindroms. T.i. – darba nedēļa tikko sākusies, nekas vēl nav izdarīts, darbu saraksts garš, garš. Līdz ar to visai nomācoši, jo ir arī apziņa, ka šonedēļ no 5 darba dienām ir tikai 3. Tātad – katru dienu jāizdara krietni vairāk. Jāķeras pie darba, vai ne?

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.

Par outsourcingu uz Indiju – stāsts no dzīves

Ierakstīts kategorijā PHP utml. | Autors: Endijs Lisovskis |

Kādu laiku iepriekš biju rakstījis par Web projektu outsourcingu uz eksotiskām valstīm. Ja iepriekšējais teksts bija tikai mans apcerējums par attiecīgo tēmu, tad tagad piedāvāju izlasīt kāda reāla Latvijas iedzīvotāja pieredzi ar Web projektu outsourcingu uz Indiju. Pārpublicēts šeit no tavsdarbs.lv. Un jā – tiku saņēmis autora atļauju.

Elle un Indija. Pirmā sērija

Indija. Elle. Kas tur nav bijis – nespēj to ne iztēloties ne aptvert. Es ari tur neesmu bijusi, taču, man pat laikam ir iemesls stipri negribēt.