briedis

Vērtība testam apmēram tāda, kā ja tu pirktu jaunu mašīnu, tad noskaidrotu tikai to, cik ātri tā tiek no 0 līdz 100, citu neko...

SEO ir daudz vienkāršāka lieta, kā tie sludināts. Saliec pareizus semantiskos tagus p, article, h1..N, meta tagus, og tagus un satura tagus (mikrodata?) https://developers.google.com/schemas/formats/json-ld, document title, un jēdzīgus URĻus lapām. Pārējais atkarīgs no backliniem, popularitātes, bet, lai to iegūtu, būs jāiegulda mārketingā.

100ms, pat 500ms nekad nespēlēs tik lielu lomu kā vērtīgs saturs, lapas backlinki. Ieraksti "mockup generator" google, un pirmajā vietā būs Printful lapa (Yii2, btw), ar 250ms, kaut arī nākošais rezultāts būs ar 150ms

Nu un? Es ikdienā strādāju ar Yii2, bet ir daži projekti ar Laravel. Laravelā kodēt ir 20x patīkamāk, ērtāk. 10ms vai pat 100ms starpība rezultātā nemaina pilnīgi neko. Dzelži ir lēti, cilvēkresurss nē.

</rant> :)

Kas par mērvienībām? man besis iedziļināties :D

Visādi jēdzīgi ieteikumi, kā rakstīt uzturamu JS: http://www.alexkras.com/summary-of-maintainable-javascript/

Esmu ar šo dillemu saskāries N-tās reizes. Principā vienmēr paliku pie ID, bet ar vairāku kolonnu unique lauka. Ar eloquent vnk atkrīt liels čakars strādājot ar objektiem.

Var arī vienkārši klasi, kurai ir save/delete/find metode. $yourClass = YourClass::find($id1, $id2, $id3); // Taisa DB::select(), saliek vērtības objekta public propertijos un atgriež klases objektu $yourClass->something = 1234; $yourClass->save(); // uztaisa insert vai update balstoties uz iekšējiem propertijiem ar DB::update/insert $yourClass->delete(); // izsauc DB::delete() ar dotajiem parametriem. Jāņem gan vērā, ka te būs nedaudz čakars ar relācijām. Ja vajag relācijas, tad tomēr labāk ir unikāls ID (uztaisi unique key'u uz vajadzīgajiem 3 laukiem). Ja objektus izgūsti no DB ar kaut kādu vienotu klasi, tad principā vari simulēt to, ka it kā tie 3 lauki ir primary, bet patiesībā ir viens unikāls ID tāpat. Sanāk tāds DataMapper patterns ~ http://designpatternsphp.readthedocs.io/en/latest/Structural/DataMapper/README.html Varianti ir visādi, bet, manuprāt, eloquent internālo metožu overraidošana tomēr ir riskanta. Kāds vēl izdomās joinot, relācijas taisīt utt un tad būs mērendz murdziņš saprast, kas patiesībā notiek.

DB::where('x', $x)->where('y', $y)->where('z', $z)->first(); Nu nestrādā īsti tie eloquent modeļi ar vairākiem PK laukiem. Visi šādi workaround ir haki. Uztaisi labāk klasi/servisu/libu/repositoriju, kas menedžē šādas lietas. Uztaisi pliku klasi, kas satur šos laukus. Repositorijs vnk atgriež masīvu/instanci ar šo klasi. Nevajag šādi hakot, būs grūti uzturēt, veikt izmaiņas...

Varat ieteikt kaut kādus rīkus, ar ko interfeisu/integrācijas/User Acceptance testus darbināt? Svarīgs aspekts būtu, lai šādus testus (scenārijus) varētu rakstīt ne-programmētājs, un šos testus varētu darbināt backendā. Mēs te skatamies uz Ghost Inspector rīku, bet man liekas dīvaini, ka testēšana notiek no attālināta servera.

Kur atrodas db? Man, teiksim no LV, kvērijam nebūs mazāk par 300ms, jo jāslēdzas ASV amazones DB :D

Ne obligāti. Ir ļoti daudz aspektu. Tāpēc vajag normāli salīdzināt ar citiem rīkiem. Stiprās, vājās puses, kas tas ir, un kas tas nav. Piemēram, vue.js smuki sevi salīdzina ar citiem līdzīgiem FW.. https://vuejs.org/guide/comparison.html

Es joprojām nesaprotu. Tu (vai jebkurš cits programmētājs) esi kādreiz interesējies, kādi ir "design practices" tam pašam phpmayadmin, cik viņam ir testu? Un kurā brīdī db pārlūkam lomu spēlē scalability? Es kādreiz lietoju phpmyadmin, tad pārslēdzos uz adminer, tieši tādēļ, ka viņš ir 1 fails, tātad elementāra uzstādīšana. Tagad vispār lietoju tikai iebūvēto phpstorma db pārlūku, jo tam vispār ir 0 konfigurēšana nepieciešama, jo pietiek tikai ievadīt db konekcijas datus. Manuprāt, programmētāji ir pietiekami aizņemti ar saviem projektiem, lai tik lielu uzmanību vēl veltītu tādai lietai. Paņem ērtāko un vienkāršāk uzstādāmo un miers.

Rīka lietotājus īsti neinteresē tas, kā viņš uzbūvēts, vai ir testi. Viņiem svarīgi, lai viņš strādā un ir ērts, ar nepieciešamām fīčām. Ja gribas palielīties par tehnisko pusi, ok, bet ja gribas nopārdot lietošanai, tad tomēr būs vajadzīgs nedaudz marketings :) P.S. Pirmo reizi vispār dzirdu tādu "Propel". :)

Neatradu nekur nekādus screenshotus, neatradu arī demo. Kādi īsti ieguvumi salīdzinot ar citiem rīkiem?

Tur jau tā lieta, 1k+ negribās izdot par portatīvo. Nav nekas daudz jādara, lai vajadzētu 2 monitorus. Kodēšanai principā svarīgākais ir vertikālais augstums. Uz laptopa vispār sanāk, ka ekrānā ielien viena funcija ar phpdoc :) 1080p bik par īsu, darbā 1200px vertikāle, un ir jau labāk. VIens ekrāns kodam, otrs pārlūkam. Ja debugo, tad debugeri arī smuki uzliec uz atseviškā moņa, tā lai smuki redz stack trace, mainīgos scope, utt, var ērti inspectot elementus utt. Nu nevar šādā ekrānā neko normāli izdarīt.. https://ziedlejas.lv/screenshots/img.2016.07.08.m0Uy05.png Knapi 15 koda rindas redz un pāris mainīgos. Stack trace'am vispaŗ nepietiek vietas... + slēgāšanās starp logiem ir papildus slodze, lai noturētu koncentrēšanos... Labi, bet par šo nav ko diskutēt...

Nu tāds variants ir legit, jo man mājās arī ir Asus laptops ar external klavieri un normālu ekrānu :) Bet nu, ja grib uzspēlēt kaut ko, tad tāpat jābuildo normāls kompis, ja negrib izlikt štuku par laptopu...

Kāpēc, lai kāds pie pilna prāta kodēšanai migrētu uz laptopa ar neērtu klaviatūru, mazu monitoru? Ar nosacījumu, ka nav jākodē kafejnīcās.

Būtu labāk kādu integrācijas testu uzrakstījis, 100x lielāka jēga nekā no tiem === :)

Diezgan vispārpieņemts standarts. Kamēr nestrādā komandā, protams, ka vari maukt kā māki, bet standarti ir, lai atviegotu pašiem dzīvi. Tas tāds jaunu programmētāju niķis, mēģināt visu pa savam, visi noteikti tādai fāzei iziet cauri :)

Nu jopt, tu runā par kaut kādu striktu kodēšanu bet lieto tādu funkciju kā empty()?? empty vispār ir pats ļaunums, ņemot vērā, ka php nebļaus, ja tāds mainīgais tajā scope nemaz nebūs definēts. Storms arī nebļaus, ja mainīgā vārds tiek pārsaukts, bet aizmirstās pārsaukt to, kas iekšā empty(). Varbūt tu vēl lieto @ tīri ikdienišķās lietās?

i5 + SSD ar 6-8 RAM'u lietoju, nav nekāda vaina, nekas īsti nebremzē un nekarst.

Lietoju PSR1/2standartu auto formatēšanu, pats nedomāju par atstarpēm, IDE pati saliek, kur vajag. Nu figviņzin, tu taču kodē "strikti", un koda atkarības var mainīties, tāpēc tev taču jāpārbauda pret tipu, kuru sagaidi, nevis to, kuram nevajadzētu būt... Sāk jau pretrunas parādīties :)

nē, es tieši par to, ka ja neeksistē. Consider this: $profile = UserProfile::find($id); // atgriež null neeksistējoša ieraksta gadījumā Sanāk, ka === lietotājiem šajā gadījumā jāsalīdzina šādi, lai pārbaudītu vai ir tieši tāds tips: if($user instanceof UserProfile) Lietot !== null nedrīkst, jo tas negarantē konkrētu tipu, bet gan tikai izslēdz null. Es sāku, ka pilnīgi bezjēdzīgi visur piekopt ===, tīri lai "drošāk justos".