Mr.Key

Runāt un rakstīt ir divas dažādas lietas. Tas ir viens. Otrs - pilnīgi piekrītu, ka ūdens liešana un terminu iespraušana, lai gudrāk izklausās, vieš pamatotas(!) aizdomas, ka tas tiek izmantots, lai kompensētu reālo spēju trūkumu. Taču, ja esi eksperts, ātri sapratīsi, vai cilvēks runā tukšu vai nē. Īpaši, ja termini tiek lietoti nepareizi, to ļoti ātri iespējams konstatēt. Tie, kas vēlas apspriest lietas būtību, meklē saprotošas ausis un apspriež tematu, lai atrastu pareizāko risinājumu. Tie, kas vēlas nomaskēt savu neprasmi, tie piedzied ausis. Un, kas attiecas uz kolēģiem, komandas parasti veido cilvēki ar līdzīgām vērtībām. Diez vai man sāpēs, ka noteikta daļa, redz, nekad negribētu mani par kolēģi. Cilvēki ir dažādi, tas ir tikai normāli.

Attiecībā uz pirmo - tieši tā. Attiecībā uz otro, domāju, ka diez vai. Vieglāk ir paņemt uzcītīgu cilvēku un pievērst programmēšanai, nekā censties pāraudzināt neuzcītīgu programmētāju. Ja man būtu iespēja, es mestu ārā no darba neuzcītīgus programmētājus un viņu vietā ņemtu pilnīgus iesācējus. Kaut kur tiku lasījis lielu uzņēmumu vadītāju teikto, ka to, vai no programmētāja - iesācēja iznāks lietas koks vai nē, var saprast dažu mēnešu laikā. Un ka uzcītīgs juniors gada - divu laikā sasniedz augstu līmeni. Neuzcītīgo programmētāju gadījumā pat desmit gadu pieredze neko labu neizsaka, jo tā ir slikta prakse, kas atkārtota gadu no gada.

Parasti tādu Kristiānu kods arī ir šausmīgs. Ja cilvēks neprot gramatiski pareizi rakstīt un literāri glīti izteikt savu domu, ir jābūt ļoti, ļoti naivam, lai ticētu, ka programmēšanā tāds izpaužas daudz augstākā kvalitātē. Nē, patiesībā dzīvē tas tā arī ir - kods ir šausmīgs, samocīts, neglīts un pats autors dižojas ar attaisnojumiem "man tas bija par grūtu", "man nebia vaidzibas iespringt ko piesienies", utt.

Piemēram, rakstot view helperi, ir gan HTML tagi, gan PHP kods. Lai nu kā, tādu praksi esmu manījis daudzos projektos, pret kuriem izjūtu respektu.

Skati drīkst saturēt if/else. Es gan nodalu to tā, ka skatos izmantoju konstrukciju if (): endif;, kas vienmēr ļauj saprast, ka tas ir skats, nevis php kods. Cits jautājums ir par veidņu dzini - katram savi nosacījumi. Smarty, piemēram, ir savas izteiksmes, bet "mustache" logic-less veidnes nesatur konstrukcijas, jo veidņu attēlošanu veic kods, kurš gan satur konstrukcijas, utt. Par pārējo - parasti konkrētās lapas kods izveido lapas HTML, kurš vēlāk tiek ietverts layoutā. Tas var notikt kaut vai tā, ka ar output buffering uzkrāj HTMLu, kuru rada konkrētās lapas kods, iemet to mainīgajā $content un tad ietver layout skriptu, kur "echo $content". Datu padošana skatam - atkarīgs no tā, kā tiek realizēts tavs MVC, taču vispārīgi - kontrollera kods sagatavo datus un padod skata objektam. Papēti Zend, Symphony u.c. ietvaru izmantotos principus.

Tieši tā, tā vpār kaut kāda figņa kas visu tikai sarežģī un neļauj daudz un ātri strādāt

dizainers vs. dizaineris ...

arī es... kā gan es to varēju nezināt? Bet lūk tā: laikam vairs nevajadzēs risinājumus ar flash.

Uztaisi, ka otrais izsaukums ir kā callback pirmās funkcijas beigās, un tiek iebarots tajā setTimeout(). Var ne kā parametru, bet kā globālo mainīgo. Vai arī uztaisi, ka ar setInterval tiek gaidīts, kad beigsies pirmā funkcija un tad palaiž otro.

Ne gluži, bet to, vai ir materiāls, kuru vērts slīpēt, var saprast ātri. Konkrēti šeit acīs duras frāze "izmēģināts pilnīgi viss". Acīmredzot, kaut ko tomēr neesi vēl izmēģinājis ;) Pamēģini sākt visu no 0 un tad skaties, kurā punktā pazūd tie burti. Noņem tos set charset, set names, pamaini tabulām, konekcijai charsetus. Nešķiet interesanti, netrīci līksmē to darīt? Tad pagaidi, kad pašam radīsies interese. :)

Domāju, ka datoru vari pārdot, nopērc planšetīti, varēsi browsēt webu utt.

Pirmo reizi dzirdu šādus principu nosaukumus, bet, pēc tā, ko tie izsaka - es teiktu, ka jā! :-)

Var gan, skat. kā: $account->increaseSpace($amount); Ja var aizmirst biznesa loģiku, tad to var aizmirst arī šādi - aizmirstot noņemt naudu. ;)

Izcili! Neesmu darbojies citās jomās, varbūt tur tas nespēlē tik ļoti lielu lomu, nekā programmēšanā, tāpēc nekrīt acīs tik ļoti, ja šo faktu ignorē. Varbūt citās jomās tos, kuri negrib pieņemt šo faktu, vienkārši izgrūž. Piemēram, atnāk celtnieks uz darbu un pasaka, ka viņam nepatīk standarta ķieģeļi, viņam gribas katru ķieģeli savādāku un tie pamati arī, nu priekš kam tie vajadzīgi... Domāju, ka tur ar tādiem nediskutē, kā programmētāju vidū - mēģina pārliecināt, ka, redz, vajadzētu tā kā ievērot labās prakses, derētu tā kā patternus pielietot utt. Tad tādi izgrūsti, "neviena nesaprasti", šie cilvēki pamana, ka varbūt varētu programmēt - maldīgi pieņemot, ka tur var darīt visu tā, kā gribās pašam.

Man nepatīk, ka uz darbu jāiet 9-18. Ļoti nepatīk. Bet, iespējams, ir iemesls, kāpēc pasaule tā iekārtota. Tas pats attiecas uz programmēšanu.

Tu piedāvā visās metodēs "pārbaudīt tikai vienreiz - pašā metodē"? Kāpēc tik ļoti centies regulēt, kuram nebūt programmēt? Varbūt Tu pats zemapziņā baidies no atklāsmes, ka esi izvēlējies neīsto jomu un tāpēc centies atgrūst citus? Dīvaini...

Nākas skumji atzīt, ka man nav piedāvāts nevienu reizi... :-( Vai tas bija tā, ka ja teiktu "jā", tad uzreiz parakstītu līgumu un piedāvātāji nebija rekrūteri?

Jā, jautājums, kā nodalīt atbildību par to, kurš veic šo pārbaudi? Viens variants ir modeļos, taisot tight-coupling. Cits variants ir FC + ACL, kas nodrošina, ka attiecīgās kontrolieru metodes ir pieejamas autorizētam lietotājam. Bet, piemēram, batch skripts, kurš ielādē pasūtījumus, kas tiek novilkti CSV failā no citas sistēmas, varētu negribēt nekādu autorizācijas pārbaudi, neskaitot to, ka tiek nodrošināta šī avota uzticamība. Autorizācijas pārbaude modeļos vairs nebūs tik ērta, ne tā?

Šādā situācijā 4. punktā būtu jābūt "Neesi autorizējies", ja vien tā forma nez kapēc hidden datos padod lietotāja ID tā vietā, lai lietotāju noteiktu pēc sesijas ID. Exception varētu izlido tad, ja pirkumu taisa lietotāja dzēšanas laikā un pieprasījuma sākumā lietotājs vēl nav izdēsts, bet, kodam nonākot līdz tranzakcijas uzsākšanai, lietotājs jau ir izdzēsts. Te arī rodas jautājums, vai tad, kad kods, kurš pieņem, ka lietotājs ir autorizējies un eksistē, tiek veikts pirkums, iespēja, ka klients vairs neeksistē, ir izņēmums (metam Exception), vai daļa no biznesa loģikas (redirect uz login lapu)? Vai tas tiek realizēts programmas kodā vai datubāzē? Ja datubāzē ir pilns ar nosacījumiem, vai tos dublēt kodā (negribētos), jeb kodā uzķert DB Exception? Utt.

Tas, kā šī lieta varētu praktiski realizēties, ir Exception, ko izraisa datubāzes nosacījumu (constraints, rules) neizpildīšanās. Ja domā programmā veidotus nosacījumus, kas izmet Exception gadījumam, ja šie nosacījumi tiek aizmirsti, tad tas tā interesanti sanāk. Un ja nu aizmirsīsi izveidot nosacījumu, kas izmet Exception gadījumiem, ja tiek aizmirsti nosacījumi? :-)

Izņēmumsituācijas ir dažādas, par to MS piemēru runājot, man tā izskatās pēc pārbaudes, vai sistēmas dati ir korekti. Vienkāršs piemērs: // Kāda datubāzes modeļa kaut kāda metode: $rows = $dataTable->find($id); if (count($rows) == 0) { // Nav atrasts // Web aplikācijas GET gadījumā nav exception // Bet IR Exception, ja tas ir kodā, kur zināms, ka $id ir tikai reāli eksistējoši DB ieraksti. // Un to izlemj metode, kas izsauc (kontrolierī, citā modelī), tāpēc te tikai return. return false; } elseif (count($rows) > 1) { throw new Company_Developers_Drunk_Exception('Kaut kas neticams, nav PK!'); } // Normālais gadījums ... Tādejādi, piemēram, ja lido ārā Exception, tad ir skaidrs, ka sistēmā kaut kas darbojas nepareizi, darbība neraisa uzticību un situācija prasa izpēti. Un, visticamāk, programmas labojumu. Iespējams - apkārtrisinājumu, izveidojot programmatisku rīcību, ja zināms, kas jādara kāda konkrēta Exception gadījumā. Tāpēc arī negribētos biznesa loģikai izmantot Exceptions, jo jau pašā sākumā ir zināms, kā jārīkojas katrā situācijā un ka būs jārīkojas, jo neatstās taču tā, ka sistēma izvada pircējam rezultātu "Sistēmas kļūda: nepietiekams preces atlikums. Gadījumā, ja kļūda atkārtojas, lūdzam sazināties ar tehnisko dienestu."

Īsāk nenozīmē saprotamāk, saprotamāk nenozīmē īsāk. Kā jau te tika minēts, Exceptions izmanto izņēmumsituācijām, nevis biznesa loģikas kontrolei. Ja biznesa loģika ir gara un sarežģīta, tad tas tā arī ir. Kā novērst koda dublēšanu un kur izvietot šo sarežģīto loģiku? Tas ir arhitektūras lēmums, jau minētā izvēle starp fat controllers/thin models vai thin controllers/fat models. Vai šo darbību veiksim kontrolierī, vai konta (account) modelī, vai pat veidosim atsevišķu modeli? Ja veidojas gari, nepārskatāmi IFi, tos var saīsināt, pārnesot uz metodēm ar pašdokumentējošiem nosaukumiem, kontrolierī vai modeļos un IFu saturu aizvietojot ar šo metožu izsaukumiem. Nesaku, ka ar Exceptions nevar panākt līdzīgu rezultātu, bet... arī ar GOTO var daudz ko izdarīt. Es gan tā nedarītu. Esmu tā darījis, tas kods man pašam nepatīk un tika/tiek pārtaisīts. Exceptions neiesaka lietot tā, kā to apraksti Tu. Laika trūkuma dēļ nevaru iedot atsauces vai izveidot koda paraugu, taču, ja tas nav pavisam droši, vismaz es esmu pārliecināts, ka tā pat ir slikta prakse. Un arī koda vienkāršošana reizēm, bet ne vienmēr, nozīmē tieši to, ka kods tiek izveidots garāks un darbojas lēnāk, un to izveidot aizņem ilgāku laiku. Taču, vai Tu zini, ko nozīmē uzturēt ātri un pa savam izveidotu sistēmu un ieviest tajā izmaiņas?

+marrtins, F3llony

Aiziet iekurt krāsni un pārskaitīt sveces.

Atsevišķs AJAX kontrollieris? Kontrolieris var būt viens un tas pats, AJAX gadījumā datus atgriež AJAX formātā, ne AJAX gadījumā parastajā formātā. Man, piemēram, patīk ZF risinājums, kurā iespējams ieslēgt konteksta slēdzi, kas, konstatējot, ka pieprasījums ir AJAX (pēc header), skatam piešķirtos datus atgriež AJAX formātā, attiecīgi, izslēdzot layout un view. Vienu un to pašu action metodi var izmantot nemaz nemainot to (metodi), jo konteksta "ķeršanu" ieslēdz kontroliera modeļa init() metodē. Lūk, DRY! Pielietojums: attēlo lapas sākotnējo ielādi ar view, un, ja klients atbalsta JS, HTML piedāvā lapas atjaunošanu (vai pāršķirstīšanu, utml.) ar AJAX, saites downgreidojas uz HTML saitēm, ja JS nav. Attiecīgi, bez JS viss notiks tāpat, tikai ar pilnu lapas pārlādēšanu. Tā kā klienti bez JS šobrīd nav aktuāli (laikam), tad reālākais lietojums ir tāds, lai Google varētu indeksēt visas lapas, nevis tikai pirmo. Account modelī funkcija, kas pārbauda, vai accounts ir autorizējies? Tas varētu būt novecojis variants. Kā jau teikts, autorizācija ir kontroliera atbildība, autorizēties var daudzos dažādos veidos. Exceptions derētu lietot izņēmumsituācijām, nevis ļoti atbilstošām pārbaudēm. Cik zinu, Exceptions mētāšana nav efektīvs veids pārbaužu veikšanai gan no programmas izpildes viedokļa, gan no koda uzturēšanas (saprotamības) viedokļa. Vēl arī jautājums par tranzakcijām - pārbaudot konta atlikumu, tajā sekundes daļā, kad tiek veikts pirkums, tas var izmainīties. Kā to risināt, kurā brīdī iesākt tranzakciju un kā izvairīties no deadlock? Kontrolieri ir dažādi, tipiski web FW satur FrontController un ActionController, vēl arī nodala fat models/thin controllers vs. thin models/fat controllers - divas dažādas pieejas. Primāri daudz ko nosaka FW izvēle. Ja izvēlas gatavu FW ar labu arhitektūru, atliek vienkārši tai sekot. Ja ir vēlme ieciklēties uz savu FW un ignorēt jomas attīstību turbo tempos, var jau darīt arī tā...