jurchiks

You're welcome :)

@ziedinjsh - paklau, tev `sort` kolonna nav varchar?

>sql sintakse prasa semikolu Tikai konsolē un .sql failos.

Update kverijā nevajadzētu būt problēmai. Nesmuki, protams, ka tu hardkodē variabļus, tas ir ļoti viegli eksploitojams, bet tehniski kverijs nav nepareizs. Vienīgi pid vērtībai nevajadzētu būt pēdiņās. Tu salīdzināji ar AJAX aizsūtītos datus ar lapas output pēc refresh?

Nu tad kaut kas netiek pareizi apdeitots, kad tiek pārvietota bilde. Salīdzini $photoOrder datus ar to, kas tiek izvadīts lapā pēc refresh.

Bet viņš tak jau rāda tā, kā ir sakārtots: >order by sort asc

"Normāls" un "nenormāls" ir subjektīvi jēdzieni. Daudz vairāk nekā puse visu pasaules programmētāju nelieto ORM, tā kā objektīvi skatoties, ORM nav normāls. Vai tas ir labi vai slikti, arī ir subjektīvi un nevienu neinteresē, galvenais ir, lai līdzekļi noved pie rezultāta, kas strādā labi, un arī bez ORM var strādāt labi. Tas pats ir ar testiem.

>Datubāze tiek modelēta no modeļiem, nevis otrādi. Normālā gadījumā. Tas ir tikai tad, ja tiek lietots ORM.

@codez - acīmredzot, tev jēdziens "liels projekts" nozīmē kaut ko pavisam citu, ko man. Nē, es nevienu projektu nezinu no galvas, pat tajā, kuru viens pats esmu rakstījis, paretam gadās šo to pārlasīt. Esmu PHPStorm piefiksējis tikai vienu bagu - spell-checking nevar izslēgt kommitu mesidžiem. Viss pārējais strādā ļoti labi. @daGrevis - "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." Tu to tā saki, it kā tev jebkura izmaiņa kodā ietekmētu visu pārējo kodu. Man tas liek domāt, ka projektā ir dependency problēmas. >Gribu teikt, ka tas ir like must-do labiem programmētājiem Atceries, ko es teicu par Jehovas lieciniekiem?

Nosacījums pēdējiem diviem rūļiem ir identisks, velns viņu zin, kas tur notiek, bet tas nav pareizi. Pārtaisi pēdējo par kaut ko šādu: RewriteRule ^gallery/([a-z]+)$ gallery.php?w=view&cat=$1 Bet vispār šāda rūtošana ir ārkārtīgi nefleksabla.

>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!

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

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

@daGrevis - ja kolēģim jālauž tavs kods, lai dabūtu gatavu kaut ko citu, tad es uzskatu, ka jā, pie vainas ir slikts/nefleksabls kods. Tā nevajadzētu būt. @gurkjis - kurš te iedala lietas melnā un baltā? Ja tu domā, ka tas esmu es, tad kāpēc tu tā domā? Par to koka struktūru un tās testēšanu - izklausās jau jauki, bet reālās aplikācijās tas parasti nav tik vienkārši. +testus it kā vajadzētu palaist pirms katra kommita vai vismaz pusha (ja izmanto GIT). @codez - tas TL;DR bija par MANU postu... Reading comprehension, do you have it?

@Kemito - kā tu ieviesīsi testus projektā, kurš ir apritē jau 9-10 gadus un pie kura strādājuši desmitiem programmētāju? Un vai tas būs tā vērts? Kā tu uzrakstīsi testu, kas pārbauda, vai kaut kāda lapa vai dizaina elements izskatās pareizi visos vajadzīgajos pārlūkos? Un visbeidzot, kā tu pārbaudīsi VISU, ne tikai to, kas TEV ienāk prātā? Neba nu rakstīsi simts testus, lai izķidātu absolūti visus vienas funkcijas iespējamos return values, ieskaitot corner cases. Tā ir ārkārtīga laika izšķiešana. @daGrevis - vai tev tā ir ierasta lieta, ka kolēģi lauž tavu kodu? TL;DR - paturiet savus testus pie sevis, un es neteikšu, kur jums tie jābāž. Nekad nevajag citiem uzmākties. @Kasspars - "Pro programmētāji uzskata, ka nezin neko." Vai tiešām?

Nekad ar to nav bijušas problēmas, un es programmēju jau vismaz četrus gadus. Es vienmēr cenšos rakstīt īsas un vienkāršas funkcijas, kuras dara tikai vienu lietu un neko citu. Ja tu raksti super-funkcijas, kuras dara krasi atšķirīgas lietas atšķirībā no parametriem, tad tā jau ir tava problēma. Vispār, situācija "mainot kaut ko vienā vietā, kaut kas netiek salauzts citā vietā" ir raksturīga spageti kodam.

Nestrādāju viens pats (izņemot vienu projektu, pie kura pašlaik vairs nestrādāju, projekta autors klusē jau kopš vasaras vidus, projekts klusi grozās un viss notiek), nedz arī pie maziem projektiem, visi ir lieli un veiksmīgi. Tu arī man bāzīsi testus rīklē? Tevis minētajiem vienkāršajiem un "krutajiem" variantiem nav nekāda sakara ar optimizāciju, tās gluži vienkārši ir sākotnējās versijas un to attīstība. Par tādu sīkumu izstrādi jau no paša projekta sākuma neviens te nerunā, tu te ej galējībās tāpat kā daGrevis. @daGrevis - t.i. tu raksti testus, bet nenodarbojies ar TDD?

Zini, cik es esmu ievērojis, TDD fani ir ļoti līdzīgi Jehovas lieciniekiem - abi ir pārlieku uzmācīgi. >jo pēc tam mainīt būs pārāk sarežģīti. Pilnīgas muļķības. Vai tu tiešām uzskati, ka bez TDD nav iespējams rakstīt fleksablu kodu?

>izstrāde ir pārāk ilga, jo projekts ir over-engineered >ar to “pa ātro“ nevajag ieiet galējībās Galējībās nevajag ieiet jebkurā gadījumā, bet pirmajā gadījumā tu noteikti iegāji galējībā. Kvalitāte != galējība/over-engineering. Un testus vispār te nevajag pīt iekšā. Par tiem GUID - pirmais piemērs ir galējība. @Kasspars - priekš tam ir mockupi.

Man vienīgajam liekas, ka vairums šajā topikā atbildošo cilvēku programmē stilā "ka tik ir"? Ciest nevaru tādu pieeju programmēšanai, tāpēc visapkārt ir tik daudz sūdainu programmu. @codez - ko tu tādu taisi, ka rezultāts nevienam nav vajadzīgs? Vajag taču veselo saprātu izmantot, pirms ķeries klāt pie projekta. Spriežot pēc taviem komentāriem, izskatās, ka tu regulāri fiksi uzbliez augšā pirmo prātā ienākušo ideju un tikai pēc tam domā, vai kāds to vispār izmantos. @Kasspars - nav gudri šipot sūdīgu kodu. Tā ir tikai sevis mānīšana, jo agri vai vēlu kādam tā zupa vienalga būs jāstrebj, ja vien tu nestrādā pie tādiem pašiem projektiem-viendienīšiem kā codez. @Kavacky - piekrītu visam. Vienkārši tā frāze "ātrā šipošana" liek nevajadzīgu uzsvaru uz ātrumu, bet ātrums un kvalitāte pēc būtības neiet kopā. P.S. inb4 atnāk F3llony un nodirš visus no galvas līdz kājām.

Es tos TODO parasti tajā vai nākamajā dienā arī uztaisu. Par otro punktu - vai tu gribi teikt, ka labāk rakstīt knapi pieņemamu kodu un uzlabot to tikai tad, kad absolūti nepieciešams?

@gurkjis - piekrītu, ka sākotnēji optimizēt nevajag. Es arī papriekš uztaisu pamata versiju un tad, ja ir kaut kas, par ko es jūtu, ka tas nav īsti kārtīgi uzrakstīts vai jau rakstot esmu paredzējis kaut kādas problēmas, bet tajā brīdī tas nebija svarīgi (parasti tad piemetu klāt TODO), tad es to koda gabalu uzlaboju līdz tādam līmenim, ka viss liekas kārtībā. Es tā īsti nemāku to paskaidrot, bet pārsvarā, lasot kādu koda gabalu (šeit tiek pieņemts LASĀMS koda gabals), vienkārši var just, vai kods ir pietiekami kvalitatīvs vai tomēr kaut kas nav kārtībā. @codez - "šipot produktu ātri ir ļoti svarīga biznesa sastāvdaļa." Quality over speed. Always. Steigties māk visi, bet uztaisīt kvalitatīvu produktu... @Wuu - so true. Man pašam uz mobilā tagad ir ļoti jocīgs bags visprastākajai piezīmju aplikācijai - on-screen widgetā flipojot no vienas piezīmes uz otru, pa vidu vienmēr ir 4 tukšas piezīmes, vienalga, kurā virzienā flipo. Atverot piezīmju aplikāciju, uzrādās divas piezīmes un nekas cits, bet, widgetā flipojot, ir šāds gļuks. Vienkārši smiekli nāk par tādu līkrocību. @daGrevis - žēl tikai, ka vairums burvju ir iesācēji, it sevišķi web developmenta kategorijā.

Are you having fun yet?

Nu tad es sevi uzskatu par ko vairāk, kā programmētāju.

Tādas optimizācijas, kuras ir sarežģītas un grūti uztveramas, parasti ir tās, kur cilvēks cenšas izspiest pēdējo nanosekundi. Normālas optimizācijas ir arī normāli lasāmas. Tiesa, man optimizācija asociējas arī ar koda lasāmības uzlabošanu, i.e. ne tikai koda performances optimizāciju, bet arī programmētāju darba efektivitātes optimizāciju, un tur lasāmība spēlē lielu lomu. > Parasti kko vari izdarīt 10ms ar 10 rindiņām vai 1ms ar 100 rindiņām. Neesmu tādus gadījumus manījis, bet nu es parasti par 9 ms nesatraucos. Ja ir kaut kas, kas prasa > 100 ms, kur acīmredzami vajadzētu prasīt desmit reizes mazāk laika, tad *varbūt* ir vērts optimizēt, bet no 10 ms uz 1 ms - jābūt īpašiem apstākļiem, lai to censtos paveikt. Es parasti rakstu maksimāli vienkāršu kodu, un performance arī pārsvarā ir vienkārši laba.