Jump to content
php.lv forumi

Kavacky

Reģistrētie lietotāji
  • Posts

    2,510
  • Joined

  • Last visited

Posts posted by Kavacky

  1. SQL selekts NAV veids, kā datus IZVADĪT. SQL selekts ir veids, kā datus IEGŪT. Ko tu pēc tam un kā ar viņiem dari, nav SQL daļa.

     

    Un nē, tu negribi (pat nevari) maisīt dažādus datus SQL pusē, tu gribi to darīt PHP pusē.

     

    Lai vienkāršāk, tu vari "ORDER BY zieda_kategorija ASC, zieda_nosaukums ASC". Tad viss pareizi ies pēc kārtas, tev tikai pašam ar PHP jākonstatē, kur pamainās kategorija.

  2. Tev nevis kverijs ir nepareizs, bet izvadīšanas princips.

     

    Tev nekas nedubultojas, tev ir PRECĪZI VIENA RINDA KATRAM ZIEDAM. Tajā vienā rindā katram ziedam ir klāt precīzi viena kategorija. Kāpēc? Jo tu kverijā velc ārā visus ziedus, kam piekārto klāt kaut kādu papildinformāciju, šajā gadījumā - kategorijas.

     

    Doma, ka vienā kverijā tev varētu būt dažādu tipu rindas ar pilnīgi dažādu informāciju, pašos pamatos ir absolūti nepareiza.

  3. Tu velc ārā ziedu rindas un katrai rindai piekārto klāt ierakstu no kategoriju rindas. Tev nekas tur neatkārtojas. Tā ir viena rinda vienam ziedam ar papildus datiem. Viss ir pareizi.

     

    Ja tu gribi izvadīt ziedus zem kateogrijām koka (pun unintended, haha) veidā, tad liec klāt "ORDER BY ziedi.ziedu_id ASC" un drukā zem augšējā līmeņa, kamēr nepamainās kategorijas nosaukums. Vai arī izvelc vienā kverijā visas kategorijas un otrā - visus ziedus ar kategoriju id'iem, un drukā ciklā cauri kategorijas, tai piedrukājot klāt atbilstošos ziedus.

     

    PS: Neraksti "INNER JOIN", bet vienkārši "JOIN", jo tas ir tas pats.

  4. Par valodas konstrukciju redefinēšanu ir domāts nevis, ka tu raksti "{{ $var }}", kas automātiski eskeipo, bet gan "<? foreach ($arr as $v) { ?>" aizstāšanu ar "@foreach $arr as $v", kas saīsina pasākumu minimāli, kā arī neko fundamentālu nemaina. Nu ērtāk jau ir vispār, jā. :D

     

    Tāpat arī ar visādiem "štrumentiem" nu CNC operātoram nevajadzētu būt iespējai (dot iespēju) izfrēzēt sev rokā caurumu :)

    Nu jā, ir jau arī rīki, kas DB adminam neļauj redzēt īstos datus bāzē, ko šams adminē. Utt... :)

     

    PS: Kas te ieminējās par "XSSīgu datu nepielaišanu līdz templeitam"... lūdzu, izdzeriet indi un aizejiet nomirt. Jebšu jums šķiet, ka "<script>window.alert('trololo')</script>" ir slikts username, kā arī šis posts nemaz nedrīkstētu saturēt šo tekstu? :)

  5. es kā frontent lietotājs varu iesūtīt kodu jebkādu kodu, kas tiks izpildīts uz tā CNC?

    Es pieļauju, ka šajā gadījumā lietotājs ir tās frēzes operators, kurš, ja grib, tad jebkurā gadījumā var palaist uz CNC kaut ko pēc būtības nepareizu.

     

     

    I wish.

    Know that feel. :D

  6. Runa ir par to, ka šīm te paciņām vēl parasti ir miljons dependenciju ar dependencijiem.

     

    Man ir šitāds, uzlikts standalone:

    "dependencies": {
        "gulp": "^3.8.8",
        "laravel-elixir": "^3.0.0"
      }
    Tagad paskaties, kas zem "node_modules/gulp/node_modules" atrodas... un kas atrodas katram no tiem zem "node_modules". Nebija ilgi jāmeklē, un vieta alfabētā jau parāda, ka tas ir tikai sākums: "node_modules/gulp/node_modules/chalk/node_modules/has-ansi/node_modules/ansi-regex"

     

    119 MB. 29780 faili. Lai salipinātu CSS un JS failus un pārkopētu tos citā folderī.

    post-742-0-36050100-1456222407_thumb.png

  7. Okay, un tad route ir "//" vai "/lv/". Now what. Kā jau teicu, edge keiss. Varētu jau būt, ka var sapatchot, bet...

    trim(preg_replace('/\/{2,}/','/',$param_str), '/')
    such fix, much code, very php, wow
  8. Un tad vēl ir tādi brīnumi kā šis epic. Because fuck you and fuck your API stability. :D Un tādu ir vēl - tur visādi dīvaini versiju bumpi, pēkšņi kaut kur pazūd vai mainās publiskas API daļas, kaut kādas klases pēkšņi pārvācas velns zina kur etc.

     

    Doctrine piemēram tieši pieder pie tām lietām, kas ir obviously laba un pie kuras jāpierod. Savukārt Eloquenta Modelī ar 3000+ sloc es gan neko labu īsti nesaskatu. Par to, ka value object entitijas vietā katra entitija ir full blown query buildereris es nekomentēšu... 

     

    Par apakšistēmām - kam tev dependency menedžeris? Standard issue freimworkam ir jābūt vaniļai, nav jāsatur visa iespējamā tufta ko nu kāds kaut kur varētu izmantot - tā vietā ir jānodrošina iespēja to pielikt klāt pie nepiciešamības, bez sviedriem un asarām.

    No kā tad, tavuprāt, FW ir jāsastāv? Vaniļa ir pliks PHP, manuprāt, bet no FW es tieši sagaidu, ka tur pilnīgi visas common/basic darbības, ko man varētu ienākt prātā veikt, jau ir atrisinātas.

     

    Kamēr viss strādā, kā man vajag, un nav jālien iekšā, man pa lielam ir pie kājas, cik tur rindiņas vai cik smuks kods.

     

    Principā vienīgo argumentu pret Laravel es te atzīstu čaļa sievišķīgo garastāvokli un ar to saistītās, bezjēdzīgās izmaiņas. Major versijas, tas būtu skaidrs, bet kāda hrena pēc pat minor ir tādas, ka atšķiras praktiski viss, izņemot nosaukumu - tas gan nav un nevar būt skaidrs.

     

    Pirmo reizi Laravel es iemēģināju 5.0, jo mērķa hostinga īpatnības, ok, pabeidzu un pēc pāris dienām sāku citu projektu uz 5.1. Un WTF, praktiski viss ir jādara citādi. Kā var izturēt, ja tev ir projekts, kas n reizes gadā jāpārtaisa, es nezinu. Man zajebal vēlreiz taisīt to, kas jau ir lieliski darba kārtībā, pat, ja par to maksā. Es vienkārši atstātu to versiju, uz kuras sākts, pārējais pohuj. :D Ja tas ir kaut kāds brokastu recepšu blogs, tad vēl tā, bet, ja tev ir normāla apjoma projekts...

  9. Tāpēc arī tas ir nākošais wordpress. Katrs dara pa savam, nav nekāda vienota standarta.

    C laikos tas vēl skaitījās pluss, ka tev neuzspiež vienu pareizo variantu, kā darīt.

     

     

    Vairāki iemesli - sy ir paredzemāks zem slodzes jo kodola elementi ir battle tested un pielaboti jau gadiem (runa ir par platformu ar >100m apmeklētāju), ekosistēma ir daudz attīstītāka un stabila (+6 gadi history), KB ir probably plašāks, ir daudz vieglāk atrast programmētajus kas jēdz Symfony kā tos, kas jēdz Lara, community ir liels procents ļoti zinošu pilsoņu (Jordi Boggiano, Ocramius, Christophe Coevoet, Schmittjoh, pats Fabiens to name a few) un nesamērāmi lielāks corporate backing, kas nozīmē ka izmaiņas un jaunas lietas sekos kaut kādai loģikai, nevis kā Laravel core devi jūtas konkrētās dienas rītā, kas atkal dod punktus pie stabilitātes.

     

    Par rīkiem - kas vainas Sy console, Doctrine migrācijām? Queue? Freimam manuprāt vispār nevajadzētu bāzt degunu queue un citās analoga līmeņa apakšsistēmās.

     

    Es tā jutos tieši pirmos 3 mēnešus kad sāku ar Symfony. Vēlāk pārdomāju...

    Par battle tested - a Laravels nav? Kas par tiem 6+ gadiem? Laravel nu jau ir 4+ gadi. :) Un ko man dod tie zinošie čaļi, es tak ne viņus pazīstu, ne arī kādreiz pazīšu. Neba nu ierakstīšu forumā jautājumu un tas guru pats personīgi man pēc 5 minūtēm būs safixojis problēmu.

     

    Man pats Doctrine liekas pēc vēmekļa, bet nu tas subjektīvi. Bet kāda vaina analogiem Laravelā?

     

    Kas attiecas uz apakšsistēmām, tad man, tieši otrādi, ir pārliecība, ka tam ir jābūt sastāvā. Tā taču ir visa FW jēga, ka tev ir pieejamas visādas kopā sajūgtas pamatlietas, par kuru implementāciju tev vairs nav jādomā. Pēc nejaušības principa kopā samestas paciņas nav FW.

     

    Ja pie kaut kā ir jāpierod, tas tas, visdrīzāk, nav nekas labs. Nu jā, pēc 3 mēnešiem Stokholmas sindroms klāt. Nejaukt ar to, ka ir acīmredzami laba lieta, ko tu vienkārši vēl nezini, tāpēc kādu laiku ir jāpamācās to lietot.

  10. Neesmu pagaidām redzējis sistēmu, kas man tik ļoti būtu atvieglojusi dzīvi kā Laravels. Dažreiz raudu spilvenā, ka Fuelephant nav Laravelā. :D

     

    Neesmu gan arī nekāds dižais Laravela eksperts, esmu uzcepis 1.5 projektus pagaidām, kur 0.5 veido primitīva galerijas lapele ar adminpanelīti, ko roka neceļas augstāk dēvēt. Kas ir lieliski - ir tik maz savs bloats jāraksta, ka plika instalācija gandrīz nekādu papildieguldījumu vairs neprasa, var sākt taisīt reāli jau tieši to, ko tu gribi uztaisīt, nevis muļļāties ar visu, kas pa tiešo uz ideju neattiecas.

     

    Pirmais acīmredzamais mīnuss, kas, šķiet, daļēji izriet no iepriekšējā, ir supermegaultraduper modularitāte, kas izpaužas tā, ka tehniski ir vājprātīgs overengineering overkills un vienkāršas lietas ir bezjēgā samuhļītas. Typo plikas instalācijas Hello World un tev jau ir pilnībā nelietojams stack trace palags no gaziljons funkciju izsaukumiem. Ja man kaut kas interesē, kā kaut ko var izdarīt, tad šeit ir tas brīdis, kad līst source paskatīties - tas ir pēdējais, ko darīt. Manuālis first, Google second, fuck it later.

     

    PHPStormā nācās atrubīt /vendor un /node_modules, jo tie ~30 k failu, kas tur vienkārši ir no sākta gala, pārāk galināja visu nost. Bet nu daļēji tas ir, jo viss līmēts no 3rd party paciņām, daļēji šī brīnišķīgā arhitektūra... visādi citādi gan tas pie dirsas, kamēr nav jālien iekšā un kaut kas tur jācenšas atrast.

     

    Komjunitijs. Laravelam esot komjunitijs. Ja par "komjunitiju" dēvē arī pat zemāko primātu līmeni nesasniegušu bezsmadzeņu amēbu koloniju, tad Šmaravel komjunitijs ir visnotaļ iespaidīgs. Visas tās uz vienas rokas pirkstiem skaitāmās reizes, kad atbildi uz netriviālu jautājumu izdevies atrast oficiālajā Laravel komjunitijā, es uzskatu par neizmērojamu veiksmi un vinnestu loterijā. Viss pārējais, kas tur redzēts, izskatās pēc neveiksmei nolemtiem mēģinājumiem noskaidrot, cik ir 2+2 "the Laravel way". Problēma tā, ka neviens tur nezina ne tikai, cik tas būs "the Laravel way", bet vispār nezina, nav vēl ne reizi dzīvē sastapis šo advancēto matemātisko konceptu.

     

    Bet nu tomēr tas, ka, izpildot vienu konsoles komandu, tev ir jau gatava ekosistēma ar pilnīgi visu, gan kodu, gan palīgrīkiem, lai varētu sākt bliezt, tas ir lieliski. Nē, nu var jau arī pats savilkt paciņas un salikt savu custom setupu, bet nu kam tas vajadzīgs, ja var novilkt jau ejošu.

×
×
  • Create New...