aplamas idejas?

[Mr.Key]

Code Completion + IDE.

Neko stulbu garos nosaukumos nesaskatu. Principā, Self documenting kods. Piemēram, ir stulbi taisīt variabļus $p $rq $t, protams, nenokomentējot to nozīmi, tā vietā, ja var $page, $request, $timestamp.

Whitespace neko nemaksā. Stundas un dienas, kas paiet, pēc gada mēģinot atcerēties, ko kods īsti dara, gan maksā.

 

NS ir ok, tehniski jau tas neko īpašu nemaina, tāpat tā Static Route būs zem Zend/Controller/Router/Route/Static.

 

p.s. Esmu reiz slimojis šito slimību, kad visu gribas ar īsākiem nosaukumiem un iestājas paralīze, ja jāraksta class Module_Model_Product, nevis vnk. class Product.

Edited December 4, 2011 by Mr.Key

[nemec]

2)Nē, tas ir tieši MVC ietvara uzdevums. Bet lietas būtība ir nedaudz savādāka. Vienreiz nedēļā/divās/mēnesī tiek uzpdeitota live aplikācija, viss, kas pa nedēļu pabeigts, tiek laists dzīvajā. Pēc tam, kad uz webserveriem ir iesūtīta jaunā versija, kuras kontrolieri atroda vielaikus ar vecākām versijām, tiek iedarbināts jaunās versijas palaišanas mehānisms - sākumā paši notestē, tad palaiž uz nelielu skaitu lietotāju, pēc tam, ja kļūdas netiek detektētas, jaunā versija tiek palaista uz visiem. Kāpēc tas ir MVC ietvarā? Tāpēc, programmētājs neko nezin, par versijonēšanu, viņš updeito vecos kontrolerus ar saviem uzlabojumiem, bet serverī MVC nodrošina šo versiju pakāpenisku un kontrolētu pārēju. Pie tam automātiski atceļ updeitošanu, ja jaunā versija sāk mest ietvaram detektējamas kļūdas.

 

Pastāsti sīkāk, kā tas ir realizēts pie tevis. Ja vari, tad būtu forši arī kodu redzēt (github?)

 

 

Vēlreiz, kas attiecas uz MVC, tad tas ir boot fails, kontrolera, routera, modeļa un viewa ietvars. Tas nav nekāds kosmoss, lai to uzrakstītu dienas vai divu laikā, kas attiecas uz visām pārējām klasēm: db, memcahced, bilžu apstrādes, utt. utjp. tad tām nav tieša sakara ar MVC un tās es arī bieži izmantoju jau gatavas.

hmm, tiešām?

Ja programmē twitter, tad protams tev nederēs tie "lēni" kombaini. Nu bet ja pieņemam, ka programmē vidēji sarežģītas lapas. Kaut ko pa vidu, starp facebook un vizītkarti.

 

Es saprotu, ja aug skills, tad saproti kur kādam ietvaram ir caurumainas un neloģiskas lietas. Var rīkoties visādi - uzlabot esošo, mainīt ietvaru, mainīt valodu, taisīt savu. Ja izvēle krīt uz pēdējo, tad jātērē daudz laika (tātad naudas).

Man MVC ir

• komandrinda, lai var manipulēt ar kodu - atjaunot datus datubāze, veidot aplikācijas utt
  
• ORM
  
• datubāzes versijas - mainu modeli, iekopēju produkcija, viena komanda un man ir jauna schema sql ielādēta
  
• vienību testi - gan atsevišķu koda gabalu, gan pieprasījumu (web aplikācijām - get un post dati)
  
• konfigurācija - vienā vietā
  
• auto admin - jā, man nepatīk bakstīties phpMyAdmin vai konsolē
  
• šabloni
  
• formas. Labi ja var veidot pa taisno no modeļiem.
  
• forši ja ir jau kaut kādi gatavi skripti, piemēram modeļa saraksta izvadīšana, paginator un pārējie labumi
  
• csrf aizsardzība
  
• lietotāju pārvaldība
  

Noteikti vēl šo sarakstu var ilgi turpināt. Ja nevari atrast labu PHP ietvaru, tad varbūt pamēģini ruby, java, python?

 

Vai ko tādu varēsi salasīt pa 2-3 dienām?

[nemec]

Vai man vienīgajam interesē kā codez organizē versiju kontroli + testēšanu, par kuru stāsta?

 

2)Nē, tas ir tieši MVC ietvara uzdevums. Bet lietas būtība ir nedaudz savādāka. Vienreiz nedēļā/divās/mēnesī tiek uzpdeitota live aplikācija, viss, kas pa nedēļu pabeigts, tiek laists dzīvajā. Pēc tam, kad uz webserveriem ir iesūtīta jaunā versija, kuras kontrolieri atroda vielaikus ar vecākām versijām, tiek iedarbināts jaunās versijas palaišanas mehānisms - sākumā paši notestē, tad palaiž uz nelielu skaitu lietotāju, pēc tam, ja kļūdas netiek detektētas, jaunā versija tiek palaista uz visiem. Kāpēc tas ir MVC ietvarā? Tāpēc, programmētājs neko nezin, par versijonēšanu, viņš updeito vecos kontrolerus ar saviem uzlabojumiem, bet serverī MVC nodrošina šo versiju pakāpenisku un kontrolētu pārēju. Pie tam automātiski atceļ updeitošanu, ja jaunā versija sāk mest ietvaram detektējamas kļūdas.

 

Kā pārējie to dara?

[codez]

Pa soļiem tas ir tā:

1) Jaunās versijas uzkopēšana uz webserveriem pēc noteiktas struktūras - ne pa virsu vecākām versijām. Es to daru ar ftp, bet var izmantot arī citas metodes, piemēram, Facebook uz saviem 100 000 serveriem 2 attālinātos datu centros tam izmanto torrent-u, lai tas notiktu ātrāk un ar vienmērīgāku slodzi.

2) Pagaidām turpina strādāt iepriekšējā versija. Config failā norāda userid, ip adresi vai jebkuru citu nosacījumu, pēc kuriem rādīs jaunākās kontroleru versijas. Sākumā tas ir testeriem, kuri iztestē vai viss strādā.

3) Ja strādā, tad tālāk var ieslēgt lietotāju grupu, pēc id intervāla, katru n-to, pēc ip adrešu intervāla. Šijā posmā jau sāk strādāt automātiska versiju kontrole. Ja jaunā versija sāk mest pārāk daudz kļūdu vai pārslogo sistēmu, tad attiecīgie kontroleri tiek atcelti un turpmāk servēta iepriekšējā versija.

4) Ja ar nelielu lietotāju kopu strādā, tad jaunā versija tiek palaista visiem. Arī šajā posmā strādā automātiska versiju kontrole.

 

Tas viss realizēts izmantojot PHP, memcached un mysql uz viegla MVC freimworka kodola. Versijas tiek atsevišķi skaitītas katram modulim, kas sevī ietver 1 vai variākus kontrolerus un attiecīgo frontendu.

 

 

P.S.

Vispār mani arī interesē, kā citi veic jaunu uzlabojumu publicēšanu.

[Joyride]

DEV -> TEST -> PROD

 

Uz DEV izstrāde + pamata testēšana, kad kāda fīča ir pabeigta, tad izmaiņas tiek uzliktas uz TEST serveriem, kur testēšanu turpina citi un tad, ja viss ir kārtībā, izmaiņas tiek publiskotas arī uz PROD serveriem.

 

Ja nu tomēr sanāk šmuce, tad nāk talkā versiju kontrole un tiek atjaunoti vecie dati, re-deploy un tālāk problēmas novēršana.

Edited December 15, 2011 by Joyride

[Mr.Key]

Pa soļiem tas ir tā:

1) Jaunās versijas uzkopēšana uz webserveriem pēc noteiktas struktūras - ne pa virsu vecākām versijām. Es to daru ar ftp, bet var izmantot arī citas metodes, piemēram, Facebook uz saviem 100 000 serveriem 2 attālinātos datu centros tam izmanto torrent-u, lai tas notiktu ātrāk un ar vienmērīgāku slodzi.

2) Pagaidām turpina strādāt iepriekšējā versija. Config failā norāda userid, ip adresi vai jebkuru citu nosacījumu, pēc kuriem rādīs jaunākās kontroleru versijas. Sākumā tas ir testeriem, kuri iztestē vai viss strādā.

3) Ja strādā, tad tālāk var ieslēgt lietotāju grupu, pēc id intervāla, katru n-to, pēc ip adrešu intervāla. Šijā posmā jau sāk strādāt automātiska versiju kontrole. Ja jaunā versija sāk mest pārāk daudz kļūdu vai pārslogo sistēmu, tad attiecīgie kontroleri tiek atcelti un turpmāk servēta iepriekšējā versija.

4) Ja ar nelielu lietotāju kopu strādā, tad jaunā versija tiek palaista visiem. Arī šajā posmā strādā automātiska versiju kontrole.

 

Un kāds tam sakars ar MVC vai ietvariem?

 

Labāk iepeisto, kā notiek Tava automātiskā versiju kontrole, kas konstatē pārāk daudz kļūdas un atceļ izmaiņas... Ja vien protams, tas nav manuāli? Kas vispār domāts ar "automātiska versiju kontrole", bez skaistiem vārdiem.. reāli, kas tiek darīts?

 

p.s. Tu strādā Facebook?

[codez]

Skars ar MVC ir tāds, ka MVC core pa tiešo ir atbildīga par pareizās versijas moduļa kontrolera palaišanu attiecīgajam lietotājam, pie attiecīgā pieprasījuma. Būtība tas viss notiek Router klasē.

Īsumā, kļūdas konstatē MVC core (Router-is), vāc statistikas datus un pārāk liela kļūdu procenta gadījumā config failā nomaina izpildāmā moduļa kontrolera versiju atpakaļ. Protams versijas var slēgāt arī manuāli.

 

Es nestrādāju facebookā.

[Mr.Key]

Parasti MVC ietvars piedāvā vismaz trīs iespējas:

1) Izvērst router klasi (extendot)

2) Izmantot savu router klasi

3) Izmantot pluginus vai konfigurāciju

 

Tu vienkārši neesi uztvēris, kur ir robeža starp MVC standarta iespējām un kur sākas unikālas projekta, projekta komandas vai uzņēmuma īpatnības, kas tiek realizētas kā jau minētās iespējas.