jurchiks

Tu tur kaut kur neesi aizmirsis $i++?

Nu, tāds tas Laravels ir.

Tagad tev ir jāciklē cauri visiem GET/POST parametriem un jāmeklē tas | simbols, pēc kura jāgrupē subitems. Tā ir tā liekā parsēšana.

Ko tas Laravel normalaizeris reāli ar taviem datiem izdara? Kaut ko būtiski maina?

Bet tavā gadījumā tev ir jāveic lieks parsings.

Vai nu javaskriptā, vai PHP, bet kaut kur tas ir jāģenerē, ne no kurienes tas neradīsies (izņemot primitīvus <input name="field[]">).

Uhh...

<input type="text" name="subtypes[1][]" value="whatever" />

Tu taču tikko teici, ka tu ar JavaScript tur neko nedari.

Anyway, es vispār taisītu tā, lai rezultātā dati būtu:

types[0][id]=1&types[0][subtypes][]=X&types[0][subtypes][]=Y

...

Rezultātā PHP nebūtu nekāda sviesta, vnk:

foreach ($_POST['types'] as $type)

{

    $id = $type['id'];

    $subtypes = $type['subtypes'] ?: [];

}

Varētu jau vismaz šādi:

?type[]=1&subtypes[1][]=A&subtypes[1][]=B

&type[]=2&subtypes[2][]=A&subtypes[2][]=C&subtypes[2][]=Z

...

>Tas ļauj iztikt bez JavaScript iesaistes elementu nosaukumu veidošanā.

Bet vai nebūtu vieglāk/labāk tomēr paņemt palīgā JavaScript?

Kaut kā nebiju piefiksējis, ka Prinful tik daudz ko drukā...

Kāda saistība drukas produktiem un e-veikaliem?

codeacademy - daļa bezmaksas, pēc tam grib 15 naudiņas mēnesī. 

drukas kļūda - pareizi ir https://www.codecademy.com/

Vēl var piemest klāt Pluralsight/Codeschool + https://developer.mozilla.org/en/docs/Web.

Vai tiešām draugiem.lv taisa woocommerce veikalus?

Totāli un pilnīgi FALSE!

Neironu tīkli paši apmācās un tajos rodas algoritmi, kurus neviens neparedz, tieši tāpēc arvien biežāk neironu tīklu risinājumi rada rezultātus, kas pārsniedz pat cerēto un strādā tā, ka neviens īsti nesaprot, kas tur iekšā notiek.

Labi, bet tas attiecas tikai uz manu pirmo teikumu. Bagus un neparedzētas (lasīt: nevēlamas) situācijas tas nekādīgi neizslēdz.

Jebkura sistēma ir tikai tik laba, cik labs ir tās radītājs. Ja radītājs kaut ko nav paredzējis vai pielaidis kļūdu... Tad tikai radītājs pats vai viņa aizvietotājs spēs to labot, ne sistēma pati. Vismaz tuvākajā paredzamajā laikā.

Izņemot tevi un F3llony.

Tas tā nebija domāts, ka tikai 0.5h max.

Jāapskatās.

>labiem developeriem vienmēr pieejami labi darbi

Muļķības. Ne visiem labajiem developeriem ir plašs paziņu loks, kuri visi pastāvīgi piedāvā darbu.

Tipa tas darbs, kuru pakaļ met, vienmēr ir labs, ja?

Oi, kruts uzbrauciens. Nedēļas laikā labu darbu neatradīsi, ja vien baigi neveicas.

Un kurš nu kuru par vāvuli būtu nosaucis... Pot calling the kettle black.

Tev vispār nevajadzētu neko veidot.

Ar ko domāju - kādēļ lai strādāšanu no mājām vērtētu zemāk kā strādāšanu ofisā..

By the way ir zināms kantoris kurš algas ziņā lien zem tiem 800eirām kur cilvēks raujas no rīta līdz vakaram ar cerību ka priekšniecība to novērtēs un kādu dienu kādu grasi piemetīs pie aldziņas..

Latvijā vērtē zemāk.

Tādu kantori nodedzināt.

Ir prikoli, bet ne tik neintuitīvi.

http://davidshariff.com/js-quiz/

Vajadzēja uzreiz savu rezultātu arī iedot.

Bet vispār, skumji, ka JS ir tik daudz tizlu un neintuitīvu quirku (piemēŗam, ka [] + [] = empty string; PHP/Python/Ruby u.c. valodas atgriež jaunu, tukšu masīvu).

Faktiski, ja tu gribi būt hardcore JS skripteris, tad tev jāmāk atpazīt kaudzi huiņas, kuras citās valodās nav. Jautri.

Ieviest testus var jebkuram projektam, jautājums tikai - kādus. Neredzu traucēkli kādam vecam projektam ieviest funkcionālos testus, lai nebūtu jākliko formām 15x cauri, lai saprastu visus gadījumus, kur kas strādā.

Kāpēc solo projektiem "nav vajadzības"? Testi nav domāti tam, lai otram pateiktu, ka viss strādā, vai arī otrs kaut ko darot, saprot, ka kaut ko salauza. Tik pat labi, tas "otrs" esi Tu, labojot kodu citā vietā, un radot problēmas citur. Testi nu būtu lieta, ko vajadzētu apsvērt iemācīties, nevis pretoties "papildus kodam". To, ko Tu pavadi "spaidot formas", ja vispār to dari, pārbaudot savu darbu, Tu vari izdarīt uzrakstot kodu, un tas strādā automatizēti.

Maziem projektiem, arī nebūtu ne vainas kaut ko uzrakstīt, lai atvieglotu sev darbu.

Biju piemirsis par funkcionālajiem, domāju tikai unit testus. Bet lieliem, veciem projektiem ar aizvēsturisku HTML struktūru (few classes/IDs) arī tā būtu būtiska problēma. Bet nu tādos gadījumos tas jau nav atkarīgs no manis, un zinot tos projektus, esmu pārliecināts, ka projektu vadītāji būtu automātiski pateikuši "netērē laiku liekām lietām, ar to lai nodarbojas testētājs" (tas, kurš manuāli kliko 15x cauri formām, un citādāk nemāk).

Es labi saprotu, kas ir testi un kā tos rakstīt, bet man personīgi vai nu pēc tādiem nav bijis nepieciešamības (jo es rakstu vienkāršu kodu, kurā man viss tāpat ir saprotams), vai nav bijis iespējas tos ieviest.

>"Tik pat labi, tas "otrs" esi Tu, labojot kodu citā vietā, un radot problēmas citur."

Savos privātajos projektos es to gandrīz vienmēr pamanu uzreiz, jo, kā jau esmu vairākkārt minējis, es visas izmaiņas pārlasu vairākas reizes, kamēr pilnībā saprotu visu, ko esmu izdarījis, pirms kommitoju (7 reizes nomēri...). Ļoti retos gadījumos, kad baigi steidzos vai esmu baigi ar kaut ko aizrāvies, gadās, ka nepārlasu, un tās ir praktiski vienīgās reizes, kad pieļauju kļūdas. Bet arī tad es tās ātri pamanu un izlaboju, jo vēlāk pārlasu iepriekš veiktās izmaiņas.

BET. Mēs kārtējo reizi ejam offtopikā. Varētu jau vienreiz mūžā piebremzēt.