Tavs Ajax ielādes ātrūms.

[Wuu]

Cik ir minimālais ielādēs laiks ko varētu sasniegt no brīža kad tiek nosūtīts JSON caur ajax un tiek saņemta atbilde. Vai 200ms ir ok? Gribētos ātrāk. Mēru ar Firebug. Ja tā vispār ir pareizais veids mērīt. Vienkārši tiek lietota pusjēla Windows mašīna (Nav mana izvēle). Kādā ir kolēģu pieredze šajā jautājumā?  Ja 200ms ir stipri par lēnu, varētu papēti šo jautājumu.

[sNuuFix]

Nezinu kā jums, bet man ajax ielādējas diezgan normālā ātrumā.

 

[gurkjis]

Es esmu 0.. Ko man tagad darīt?

- vari sadzīvot / izdzīvot / tikt sveikā cauri bez ciešanām ? Tad ir ok. Galvenais, lai gan Tu, gan arī apkārtējie (klienti, kolēģi) būtu apmierināti dēļ Tava darba. 

[jurchiks]

@codez - ja sistēma ir 9-10 gadus veca un pie tās ir strādājuši desmitiem programmētāju, tā gluži vienkārši nevar būt BEZ bagiem.

Loģiski, ka izmantojam bug tracking, bet bagi ir ļoti reti. Iemesli mēdz būt tikai divi, un tas nav atkarīgs no testiem - vai nu ir pieļauta drukas kļūda (gadās drausmīgi reti, pārsvarā tiem programmētājiem, kuri neizmanto IDEs, bet gan plain text editorus), vai arī kaut kas nav paredzēts.

Divi piemēri no pavisam nesenas pagātnes projektam, kurš ir rakstīts table designā:

1) headerī ir mazs popup bloks, kurš parādās, kad lietotājam čatā kāds uzraksta. CSSā pozicionēts absolūti, norādīts "left: 980px;". Neviens neko nepamanīja, līdz nedaudz pamainījās bloka platums un tas izslīdēja ārpus 980 + iepriekšējais platums px. Blokam radās vizuāli gļuki. Ar testiem kaut ko tādu tu nekad nepiefiksētu.

2) ir navigācijas bloks, fiksēts platums. Pilnīgi visās lapās izskatās vienādi, izņemot vienu īpašu lapu, kurā contents ir platāks par window width (liela tabula saturā) un saspiež navigāciju par 10px. Haks, kas tika izmantots šī prikola labošanai - uzlikt navigācijas blokam "nowrap" atribūtu, kas vecākos IE uzliek navigācijas tekstam "white-space: nowrap;", un tas, savukārt, rada bagu, ka garāki teksti izpleš navigāciju. Tādēļ noņēmu atribūtu, toties vietā nāca tas resize bags (hack-fix: pielikt width:N px klāt min-width: Npx). Ar testiem arī šo nekādīgi nepiefiksēsi.

 

PHP pusē pat neatceros, kad pēdējo reizi bags ir bijis, jāpaskatās repo logos...

Dažas sīkas drukas kļūdas pirms vairākiem mēnešiem un viena problēma subklases metodē - biju nokopējis metodi no superklases un aizmirsis pielāgot.

 

@gurkjis - es teiktu, ka esmu kaut kur ap 0.65. Es domāju gan par to, lai ārējais rezultāts ir labs, gan par to, lai kods ir kvalitatīvs, bet nekad tikai par vienu no tiem.

 

@nice1 - ziepē virvi.

Edited September 19, 2014 by jurchiks

[Kemito]

jurchik, Tev kāds uzbāžas ar testiem? Neviens Tev konkrēti neliek viņus lietot.

Tu runā par kaut kādām UI grabažām, kas radušās no līkas griešanas rezultātā. Ja nepamanīji manšķiet vairāk tēmēts bija par backend testiem, bet nu tas laikam aizgāja gar ausi.

Backend pusē pārbaudot vai funkcionāli šādas opcijas veikt ir iespējams, kā arī vai konkrētās metodes dara sev paradzētās lietas, un atgriež to, kas nepieciešams, un ja kodu nerakstīsi ar dirsu un netaisīsi baigos everestus katrā klasē/metodē, tad arī iztestēt ar testiem to nebūs problēmas.

9-10 gadus vecu projekta kodu, vispār aiztikt nav vajadzības, es domāju, ka Tev vajadzētu pietiekami lielam saprātam būt, lai to vērstu attiecībā pret jaunākiem kodiem.

Tā vietā, lai meklētu kaut kādu atmasku tam visam, būtu labāk pačekojis benefitus no tā.

 

ju verij funij.

[codez]

Projektā pie kur pašlaik strādāju, testi izķer virs 95% drukas kļūdu.

Taču es nespēju noticēt, ka, dēļ izmaiņām vienā vietā, jums nerodas bug-i citās vietās.

Piemēram, mainot modeļus, to metodes, mainot tabulu shēmas (liekot klāt kolonnas, taisot foreign keys, utt.).

Tās taču ir lietas, kas var tikt izmantotas vairākās vietās un, ja vien programmētājs nepārzin visu projektu no galvas un pie izmaiņas nesataisa to visās vietās, nav tak iespējams paredzēt, kur un kas var sabrukt.

Saprotams ar tādām kļūdām gan sastopos tikai PHP projektos, jo skalā viss ir statiski tipēts, tai skaitā modeļi un līdz ar to shēmas. Pat kveriju builderis rakstot kverijus ir 100% statiski tipēts.

[gurkjis]

Nav tā, ka es testus ienīstu, bet man ir tikai priekšstats izveidojies par tiem, kā arī neesmu vēl praksē tos izmantojis reālā projektā, kas jāuztur. Visam savs laiks. Kad izjutīšu šo "sāpi", ka man tagad lielāks projekts brūk pie izmaiņām, tad arī ķeršos klāt.

Edited September 19, 2014 by gurkjis

[jurchiks]

>Projektā pie kur pašlaik strādāju, testi izķer virs 95% drukas kļūdu.

Normālas IDEs izķer 95% drukas kļūdu vēl pirms testiem.

 

>Taču es nespēju noticēt, ka, dēļ izmaiņām vienā vietā, jums nerodas bug-i citās vietās.

Nu cmon...

 

Divos vecajos projektos nekādu modeļu nav, it īpaši ne db līmenī. Uz tiem es sāku strādāt, kad projekts jau bija entos gadus vecs.

Tajā projektā, kuru viens pats pāris gadus rakstīju, man nekādu problēmu nav bijis, jo projekts ir pilnībā OOP, un es web programmēšanai izmantoju PHPStorm, kas ļauj ar tādu kodu darboties ļoti efektīgi.

 

>nav tak iespējams paredzēt, kur un kas var sabrukt.

Ja piecas reizes pārlasa visas vietas, kur maināmais kods tiek izmantots, ir iespējams. Keyword: readability.

 

Tu varbūt izmanto programmēšanai Notepad++? Ja tā, tad nav brīnums, ka rodas tādi jautājumi.

 

Par testiem (atkal) - man ir tāda pati situācija, kā gurķim. Vajadzības pēc testiem nav bijis absolūti nekādas, jo es nesteidzos un pārdomāju, kā es savu kodu rakstīšu, gan pirms es to daru, gan procesā. Protams, ka bagi ir bijuši, bet bagi ir visiem bez izņēmuma, tā kā "tev ir bagi? raksti testus!" izklausās vienkārši smieklīgi. Ātrāk bagu atrast, nekā uzrakstīt testus, kas to bagu atradīs.

Edited September 19, 2014 by jurchiks

[hjkl]

Tiem, kam ir pieredze ar testēšanu - kad jūs tos testus rakstāt? Tiešām piekopjat "testi vispirms, kods pēc tam"? Jo varbūt, ka man ir līkas rokas un es nespēju pats sevi paredzēt, bet bieži vien mēnesi pēc projekta sākšanas tā struktūra ir tik atšķirīga no sākotnēji iecerētās, ka pirms tam rakstītie testi vnk ir bezjēdzīgi.

[codez]

Tu izvairies no atbildes. Nav modeļi, bet ir db, tātad maināt tabulas shēmas pa tiešo. Kas notiek, ja izmaināt tabulas shēmu un kaut kur, kur šī tabula izmantota, neesat ieviesuši izmaiņas?

Kā tev IDE izķers tādas drukas kļūdas kā kļūda SQL kverijā, izsaukta nepareiza metode, padots nepareizs mainīgais, utt?

 

Viss liecina tikai un vienīga par to, ka tu strādā pie ļoti vienkārša, maza apjoma produkta maksimums 3 cilvēku grupā un jaunas izmaiņas produkcijā savā produktā izlaižat 4 reizes gadā.

 

Un bez labiem testiem, tu nevis ātrāk bug-u atradīsi, bet vispār nezināsi, ka tāds eksistē, līdz kādam lietotājam produkcijā kaut kas nestrādās.

 

 

Ja tavu teikto pārfrāzētu uz grāvju rakšanu, tad tu man izklausies tā:

- Priekš kam vajadzīgs ekskavators, mēs ar lāpstām visu kvalitatīvi sarokam.

- Esam rakuši lielus grāvjus un rokam jau 9-10 gadus.

- Ja tu izmanto plastmasas sniega lāpstiņu, tad nav brīnums, ka tev varbūt arī vajag ekskavatoru, bet man ir Fiskar lāpsta.

- Un divus iepriekšējos grāvjus kad rakām mums nekādu degvielu nevajadzēja un ekskavatoram pneimatika arī nebija jāmaina, jo mēs vispār ekskavatorus neizmantojam, jo mums ir Fiskar lāpstas.

- Par rakšanu (atkal) - man ir tāda pati situācija, kā gurķim. Vajadzības pēc ekskavatora nav bijis absolūti nekādas, jo es nesteidzos un pārdomāju, kā es savu grāvi rakšu, gan pirms es to daru, gan procesā. Protams, ka akmeņi ir bijuši, bet akmeņi ir visiem bez izņēmuma, tā kā "tev ir akmeņi? roc ar ekskavatoru!" izklausās vienkārši smieklīgi. Ātrāk akmeni izcelt, nekā izrakt ar ekskavatoru.

[codez]

Tiem, kam ir pieredze ar testēšanu - kad jūs tos testus rakstāt? Tiešām piekopjat "testi vispirms, kods pēc tam"? Jo varbūt, ka man ir līkas rokas un es nespēju pats sevi paredzēt, bet bieži vien mēnesi pēc projekta sākšanas tā struktūra ir tik atšķirīga no sākotnēji iecerētās, ka pirms tam rakstītie testi vnk ir bezjēdzīgi.

Uzrakstu jaunu funkcionalitāti un uzreiz uzrakstu testus, kas šo funkcionalitāti testē.

tālāk test, ja viss kārtībā un nevienā no ari iepriekš rakstītajiem testiem nav kļūdu, commit, push, ja nē, meklēju, kas salauzts, laboju un atpakaļ uz test.

Edited September 19, 2014 by codez

[jurchiks]

>Kas notiek, ja izmaināt tabulas shēmu un kaut kur, kur šī tabula izmantota, neesat ieviesuši izmaiņas?

Nekas nenotiek, jo tādas situācijas, ka "neesam ieviesuši izmaiņas", nerodas.

 

>Kā tev IDE izķers tādas drukas kļūdas kā kļūda SQL kverijā

Neesi lietojis PHPStorm vai kādu ekvivalentu IDE. Ja ir norādīts Data Source, tad PHPStorm pats salīdzina kverijos norādītās kolonnas/tabulas/etc ar reālo datubāzi, un ja kaut kur ir erori (piemēram, nepareizs kolonnas nosaukums), tad tas uzreiz tiek hailaitots. Turpat uzreiz var ar diviem klikšķiem to kveriju izpildīt uz datubāzes un apskatīt rezultātus.

 

>izsaukta nepareiza metode, padots nepareizs mainīgais

...tur jau pie vainas ir tikai līkrocība.

 

>Ja tavu teikto pārfrāzētu uz grāvju rakšanu

Har har, kārtējā nodiršana. Keep going like that, champ! You're a true man!

[codez]

Nekas nenotiek, jo tādas situācijas, ka "neesam ieviesuši izmaiņas", nerodas.

Nu tā jau arī domāju. Tavi projekti ir tik mazi, ka tu no galvas zini visu projektu un tāpēc vari zināt, ko izmaiņas ietekmēs.

 

Neesi lietojis PHPStorm vai kādu ekvivalentu IDE. Ja ir norādīts Data Source, tad PHPStorm pats salīdzina kverijos norādītās kolonnas/tabulas/etc ar reālo datubāzi

Lai arī pats lietoju PHPStrom, tomēr viņš ir diezgan bug-ains. Bet plain SQL neesmu rakstījis ļoti ilgi - ar tādām muļķībām nenodarbojos. Abstrakcija, abstrakcija, abstrakcija.

 

Bet nu labi šī diskusija iet pa riņķi. Kad būsi pastrādājis pie grāvjiem, kurus tikai ar lāpstu izrakt nevar, tad varam turpināt.

[Kasspars]

Nē nu ja codez tiešām raksta testus, tad viņš tiešām ir True man.

Man, piemēram, trūkst disciplīnas to darīt

 

-----

Un bez labiem testiem, tu nevis ātrāk bug-u atradīsi, bet vispār nezināsi, ka tāds eksistē, līdz kādam lietotājam produkcijā kaut kas nestrādās.

------

^ šitas ir true story, un kad tas gļuks izlec, tad ir baigā dusma uz sevi, sajūta, ka esmu pilnīgs noobs. Un kas ir pats stulbākais, ka ir kolēģi, kas uz šitādiem gļukiem nevis atzīst, ka salaida lažu, bet sāk filosofēt par un ap un meklēt citus vainīgos.

[briedis]

Aicinu par testēšanu turpināt bazaru manis uzsāktajā tēmā: http://php.lv/f/topic/21971-test%C4%93%C5%A1ana/

[daGrevis]

> Ja piecas reizes pārlasa visas vietas, kur maināmais kods tiek izmantots, ir iespējams. Keyword: readability.

 

Tu esi tik naivs. :))

 

> Ātrāk bagu atrast, nekā uzrakstīt testus, kas to bagu atradīs.

 

Tikai ieskaiti to laiku, ko tev vajag manuāli pārbaudīt katru fīču, kas pirms tam it kā strādāja, pirms tika uzrakstīta jaunā fīča. **Automātiskie** testi **katru reizi**, pie izmaiņas.

 

> Nē nu ja codez tiešām raksta testus, tad viņš tiešām ir True man.

 

A man likās, ka ja tu to nedari, tevi neņem darbā normālās vietās. :( Gribu teikt, ka tas ir like must-do labiem programmētājiem, ne tā?

 

> Un bez labiem testiem, tu nevis ātrāk bug-u atradīsi, bet vispār nezināsi, ka tāds eksistē, līdz kādam lietotājam produkcijā kaut kas nestrādās.

 

Sentry.