daGrevis

Tādas problēmas jau ir tikai uz Windows.

Kur to framework var apskatīt?

Naids pret Lisperiem.

> Es labāk domāju par to, kur tērēt naudu. Domāt par biznesa loģikām un projekta kopbildēm ir kaut kāds verga līmenis Pilnīgi otrādi. Un code monkeys arī neko nemaksā.

> Ja rodas vajadzība dinamiski (ar JS) pievienot jaunu elementu, tad arī tam ir jāuzliek event listener. Un te jau rodas divas vietas, kur tiek uzlikts events: backend pusē un client pusē Abi eventi ir klienta pusē. > Viegli nedomāt, vai ne? Tev padodās. Es labāk izvēlos domāt par lietām kas ir patiešām svarīgas — biznesa loģika manā aplikācijā. Es neredzu iemeslu atvēlēt savu laiku lai cīnītos ar garlaicīgām, sen atrisinātām problēmām kā eventu strādāšana starp brovseriem vai atcerēšanos visur uztaisīt cleanup; lai par to parūpējas abstrakcijas...

Ja gribi dabūt vienu lielu failu, izmanto tar (bez gz).

Correlation does not imply causation.

Ir jāsaprot katra rindiņa lai programmētu!

Ko tu man te stāsti ka nevar izmērīt? https://en.wikipedia.org/wiki/Cyclomatic_complexity

Pēc loģikas daudzuma.

Saki, ka React nav labs risinājums lielām, sarežģītām appām?

> Ja "mēs šeit runājam" par "security", tad ir diezgan jocīgi (vai pat amizanti) piesaukt kaut kādus third-party template risinājumus, kuri lielākoties tiek pljek-snjek ievilkti ar visādiem package managariem on-the-fly un noteikti lielākais vairākums pat faktiski neskatās, kas konkrētajā kodā notiek paļaujoties uz tā autoru zināšanām/godaprātu vai kaut kādas publikas pozitīvu novērtējumu utt.. Es šeit par “edgy“ saucu *automātisku* security bugu ķeršanu, like this. https://secure.php.net/manual/en/intro.taint.phpTo darīt automātiski ir vairāk kā crazy. :) Tas ko tev dod labs template engine ir automātiskais escapings. Tā vietā lai paļautos ka dators *uzminēs* kas ir slikts un kas nē, tu escapo visus mainīgos kas tiek padoti templatam. Šādi tev nevajag neko atcerēties (aka cognitive load), un, pats galvenais, tu neuzticies, ka dators uzminēs kur ir problēma. Bet template engine ir tikai viens veids kā risināt problēmu — to tu pats izvēlējies kā manu alternatīvu un tad vēl sāki man braukt virsū par "on the fly" instalāciju ar paku menedžeri. :D

> Vispār jau šim ir risinājums (kas kā reiz forsē programmētājus pievērst uzmanību, kas notiek ar datiem (ne kaut kur "maģiski" kādā pluginfailā) Tas Taint izskatās ļoti, ļoti edgy. Uzticēties, ka sistēma automātiski atradīs problēmas (this will 100% fail at some point) un tad uzticēties, ka kāds šos warningus ņems vērā (kāds piemirsīs, kaut vai netīšām)? Mēs šeit tomēr runājam par security. > No performances viedokļa (un ja dati/apstākļi ļauj t.i. nav būtisks oriģināls), tad "eskeipotus" glabāt ir krietni labāk nekā ziljons reizes transformēt pie izvades (tāpat ar visādiem nl2br() utt). Datus ir jāglabā as-is, nesapistus. Ja ir nepieciešams optimizēt, izmanto cache.

Es pareizi saprotu, Robert, ka tu iesaki escapot datus pret XSS un tad šamus glabāt iekš datubāzes, jau escapotus?

Pret XSS tiek escapots on output.

> Discuss? Jēga renderēt servera pusē ir divos scenārijos: 1) Tava lapa nav dinamiska — tās saturs tiek ielādēts un mainās tikai ejot uz jaunu lapu. Serveris uzrenderē, atgriež atbildi un aizmirst. Šādas lapas ir okay, bet bieži vien gribēsi lai tava lapa ir ar UI/UX kas vairāk atbilst 2016. gadam. Ne visas lapas satur “tekstu un dažas bildītes“. Kā piemērs, Facebook vai Gmail. Tās arī ir “tikai weblapas“, bet būtu neprāts tādas taisīt izmantojot server renderēšanu un abildes agriešanu. Šādām lapām ir bizillions rindas ar JavaScript, kas tāpat visu laiku maina DOM! Beigās sanāks ka tu uzrenderēsi HTML ar template engine A un tad ar savu template engine B, citā valodā, tam pārrakstīsi pāri. Vēl viena lieta ar ko programmētājam ir jācīnas? Waste of time. P.S. Varbūt vēl viens iemesls statiskai lapa būtu SEO, bet nu tas arī ar katru gadu kļūst ar vien mazāk aktuāli. 2) Gribi optimizēt lapas ielādi. Lielām applikācijām kas visu dara klienta pusē ir lielāks izmērs — pirmā ielādēte būs lēnāka. Visa renderēšana notiek klientā, bet tu jau daļēji uzrenderē lapu servera pusē. Kamēr klientam tiek sūts JavaScript un pārējie asseti (pirmā ielāde), klients parāda servera uzrenderēto lapas versiju. Kad frontends ir gatavs pieslēgties, tas pārņem kontroli un turpina iesākto. Šajā gadījumā tiek izmantots viens un tas pats template engine un koda duplikācija ir minimāla. Tie paši templeiti un viss pārējais. Šādi dara jau manis minētais Facebook un, starp citu, arī Instagram Android un iOS appas. Tiek izmantots ReactJS, bet, protams, citi framework to arī pieprot.

Serveris atgriež _datus_, klients uzrenderē (ReactJS).

Izņemot to configu no kura citi manto. Sensible defaults.

Protams, ka nē.

> A kāpēc kodu izmētāt pa visu appu ja var smuki salikt vienā failā un nosaukt par index.php? :) Ko? > Katram bundlim ir viena konkrēta vieta kur definēt servisus, parametrus utml lietas To es arī iesaku darīt. Nevis “bundlim“ pie katra kontrolera (?) ir kkāda anotācija (?) kas pasaka ar kuru URL šis te ir atverams.

Kāpēc izmētāt konfigurāciju pa visu appu ja var to smuki salikt vienā vietā?

Re kur var izlasīt visu kas jāzina. http://www.regular-expressions.info/ Bet šeit var paspēlēties. https://regex101.com/

Lazy un greedy ir regexu lieta. Saprotot kas tas par zvēru, ar regexu varēsi pats nomatchot tieši tā kā vēlējies.

Palasi par lazy un greedy.

Nē, bet kruti. Atceros kāds bija čakars kad vajadzēja sajūgt Invision Power Board kopā ar Django appu. Smuks API pāri sūdam, kas ir WordPress, vai, manā gadījumā, IPB, ir labi.