Jump to content
php.lv forumi

Recommended Posts

7 hours ago, webi said:

Piekrītu, ka ietvari bremzē ātrdarbību.
Kamēr projekts mazs, bez noslodzes - viss labi.
Tiklīdz jāsāk optimizācija, saproti, ka vieglāk uzreiz uzraksīt visu optimizētu konkrētam projektam.

Maziem projektiem, jau ok.. 
- bet kad liels.. 
- paskaties uz DB un saproti.. - ....:rupjie vārdi izlaisti:.... 
- esmu redzējis tādas DB.. kur  maz neliekās.. un pārsvarā tās bijis uz "ietvaru" rēķina.. 
- esmu - nu ļoti skeptisks uz visu to - .. 

Link to post
Share on other sites
  • Replies 59
  • Created
  • Last Reply

Top Posters In This Topic

On 2/22/2020 at 5:39 PM, codehighriga said:

Par drošības caurumiem runājot - iesaku nopietni apsvērt kāda ir varbūtība, ka caurs būs tūkstošiem cilvēku review-ots, publiski pieejams open source kods, un kāda šī varbūtība ir tevis paša rakstītajam kodam, kam review taisījis augstākais viens cits kolēģis.

Man ir bijusi darīšana ar vairākām uzlauztām lapām, gan senos laikos savām, gan daudz vairāk reižu sakopjot citu nelaimes, un praktiski vienmēr, kad problēma ir bijusi kodā, tā ir nākusi no "tūkstošiem cilvēku review-ota open source" CMS/frameworka/liba nevis sava koda. Jā, varbūt arī savā custom kodā ir kāši, toties tie netiek katru dienu publiskoti un automatizēti eksploitoti no visiem, kam nav slinkums.

Ietvars var palīdzēt ar izstrādes ātrumu (un arī ne vienmēr) un atvieglot darbu komandā, bet ātrdarbībai un drošībai tas nes tikai mīnusus.

Edited by mad182
Link to post
Share on other sites

Tad jau ejiet vēl tālāk - varam ātrdarbības dēļ atsacīties arī no objektiem, klasēm, type hinting, utt. Varbūt rakstam atkal visu kodu vienā index.php, kurā includojam globālu functions.php ? Bez namespacing, protams, tas būs lēni.

Lielummānija kaut kāda - tipa es viens pats esmu gudrāks par lielo open source community, zinu labāk visus drošības aspektus, zinu labāk arī kā visu optimizēt. (Droši vien pats īsti nezina, ko šeit domā ar "optimizāciju", ko ar "drošību").

Ar to gribēju pateikt, ka visa optimizācija, kas manas dzīves laikā ir bijusi nepieciešama, ir bijusi par 95% tieši datubāzes struktūras optimizācija, query skaita optimizācija, korekts cache lietojums. Šīs lietas tiešām dod izmērāmu labumu - bieži vien mērāmu sekundēs, un tām NAV nekāda sakara ar freimworku. Savukārt samainīt Laravel/Symfony pret pašrakstītu tuftu - nu dabūsiet no 200ms uz 150ms. Baigais jau nu ieguvums. Ja to tik ļoti vajag, tad lētāk pacelt serverim pieejamos resursus un iegūsiet tādu pašu ātrdarbību bez pašrakstīta velosipēda atkārtotas izgudrošanas.

Atgriežoties pie drošības - tā arī nesapratu, kas konkrēti padara pašrakstītu freimworku drošāku par open source freimworku? Konkrēti? Ja vienīgais arguments ir tas, ka publiski nav zināmas konkrēta freimworka versijas ievainojamības - tas ir vājš arguments. Tik pat labi pret jūsu sistēmu var palaist automatizētus tooļus, kas nav targetēti uz specifiskiem freimworkiem, bet gan generic ievainojamībām. Un - hops - būsiet tāpat uzlausti. Visticamāk drošība tikai samazināsies.

Edited by codehighriga
Link to post
Share on other sites
1 hour ago, mad182 said:

Man ir bijusi darīšana ar vairākām uzlauztām lapām, gan senos laikos savām, gan daudz vairāk reižu sakopjot citu nelaimes, un praktiski vienmēr, kad problēma ir bijusi kodā, tā ir nākusi no "tūkstošiem cilvēku review-ota open source" CMS/frameworka/liba nevis sava koda..

Vienīgais skaidrojums šim varētu būt, ka lapa uz "sava" koda nevienam nav vajadzīga :)

Bet nopietni runājot - vari nosaukt konkrētus piemērus? Un aprakstīt konkrēta OS FW ievainojamību.

Link to post
Share on other sites

Ai aizgāja normāls spams, bet man gribās arī iepļackāt savu viedokli.

Daži te runā par ātrdarbību it kā būvētu feisbuku vai twitteri. Ātrdarbība nenes naudu 99.99% gadījumos.

Frameworkus vajag, lai būtu vienota sistēma, kā būvēt lietas. Frameworki ļauj nesalīdzināmi ātrāk realizēt ideju.

"Es freimworkus nelietoju", bet varu derēt, ka kad jāsāk jauns projekts, tad pats ņem copy pasta koda fragmentus no iepriekšējā projekta.

Dzelži ir lēti, par pāris stundām programmētāja resursa var ez paņem jaudīgāku dzelzi.

Diskusija tik pat muļķīga, kā apgalvojums, ka labāk kodēt teksta redaktorā, jo tam redz boot laiks ir par 4s ātrāks.

Link to post
Share on other sites
14 hours ago, briedis said:

Diskusija tik pat muļķīga, kā apgalvojums, ka labāk kodēt teksta redaktorā, jo tam redz boot laiks ir par 4s ātrāks.

Starpcitu, pēc pēdējiem Windows, PhpStorm un Docker updeitiem ir palicis grūti programmēt ar 8GB RAM atmiņu. Vairākas reizes dienā izmet out of memory errorus gan docker, gan phpstorm. Ar 16GB joprojām viss ok. Tomēr varu saprast, ja kāds priekš web developmenta ņemtu arī datoru ar 32GB - tā teikt rezerve pāris gadiem.

Link to post
Share on other sites

Jāsaka ka dīvaini. Man darba datoram ir 8GB RAM ar 200GB HDD.
PhpStorm ir vaļā 24/7 ar retiem restartiem reizi nedēļā (vai pat retāk, ja windows galīgi nebrēc) un nekad nav bijusi šāda problēma.

Link to post
Share on other sites
1 hour ago, codehighriga said:

Starpcitu, pēc pēdējiem Windows, PhpStorm un Docker updeitiem ir palicis grūti programmēt ar 8GB RAM atmiņu. Vairākas reizes dienā izmet out of memory errorus gan docker, gan phpstorm. Ar 16GB joprojām viss ok. Tomēr varu saprast, ja kāds priekš web developmenta ņemtu arī datoru ar 32GB - tā teikt rezerve pāris gadiem.

Nu, tikko paskatījos - man docker ēd 10GB, bet storms tikai 2GB ar ļoti lielu projektu.
Varbūt tomēr palūdz vēl 8GB? Rams taču ir lēts, būtu muļķīgi upurēt produktivitāti pārdesmit eiro dēļ.

Link to post
Share on other sites
23 hours ago, aaxc said:

Jāsaka ka dīvaini. Man darba datoram ir 8GB RAM ar 200GB HDD.
PhpStorm ir vaļā 24/7 ar retiem restartiem reizi nedēļā (vai pat retāk, ja windows galīgi nebrēc) un nekad nav bijusi šāda problēma.

Ok, PhpStorm viens pats neko traku ar RAM nedara. Vainīgais tiešām sanāk Docker. Iespējams pēdējā laikā projektam pielikts vēl kāds rijīgāks konteiners klāt, īsti nezinu. Jebkurā gadījumā, vajadzība pēc RAM ļoti pieaugusi. Un kā jau teicu - ja RAM usage šobrīd karājas pie kādiem 14GB, tad nemaz vairs neliekas pārspīlēti datorā ielikt 32GB RAM. Tuvāko 2-3 gadu laikā noteikti varētu noderēt.

Link to post
Share on other sites
On 3/1/2020 at 10:00 PM, briedis said:

Frameworkus vajag, lai būtu vienota sistēma, kā būvēt lietas. Frameworki ļauj nesalīdzināmi ātrāk realizēt ideju.

"Es freimworkus nelietoju", bet varu derēt, ka kad jāsāk jauns projekts, tad pats ņem copy pasta koda fragmentus no iepriekšējā projekta.

 

 

Protams ka katrs izmanto savus "vecos-pārbaudītos" koda fragmentus, tas piederās pie lietas.. 

Bet bieži "ietvari" tiek izmantoti pavisam elementāru lietu izveidošanai..
- nu nafig vilkt milzu JS "ietvaru" , ja lapā izmanto vienu JS funkciju.. 
teiksim $(......) vietā var elementāri uzrakstīt  standarta JS f-ju (vai pat tīri HTML 5 iespējas), un ietvarus vispār neizmantot..  
protams ja projekts ir liels, un to izstrādā vesela cilvēku grupa, tad ir vērts padomāt.. bet tā.. vienkāršai vizītkartes lapai.. (2-3 lapas kopā).. priekš kam tas vajadzīgs.. 
- un jā, JS ietvari, agri vai vēlu var sagādāt pārsteigumus- tko to izstrādātāji pārtrauks tos uzturēt (teiksim likvidēs lapu, no kuras tie tiek ielādēti) .. 

P.S. slikts ir programmētājs, kas nedomā par koda optimizāciju, bet domā- ai lietotājs nopirks labāku "dzelzi" ... 
 

https://mults.info/mults/?id=375
 

Link to post
Share on other sites
4 hours ago, Grey_Wolf said:

- nu nafig vilkt milzu JS "ietvaru" , ja lapā izmanto vienu JS funkciju.. 

JS ietvari parasti netiek veidoti, lai izmantotu vienu JS funkciju. Tu jauc ar bibliotēkām.

4 hours ago, Grey_Wolf said:

- un jā, JS ietvari, agri vai vēlu var sagādāt pārsteigumus- tko to izstrādātāji pārtrauks tos uzturēt (teiksim likvidēs lapu, no kuras tie tiek ielādēti) .. 

Tu droši vien pat neesi dzirdējis par npm.

4 hours ago, Grey_Wolf said:

P.S. slikts ir programmētājs, kas nedomā par koda optimizāciju, bet domā- ai lietotājs nopirks labāku "dzelzi" ... 

Nē, slikts programmētājs ir tas, kas taisa "elementāras lietas" pats, neizmantojot instrumentus, kuri tam ir domāti. Jo tāds programmētājs iztērēs laiku, izgudrojot divriteni, kuram noteikti būs drošības caurumi un nebūs normāla composer atbalsta utt.

Runājot par ātrumiem - ar opcache to pašu laravel var paātrināt diezgan pamatīgi. Tavs self-made kods varēs sacensties ātrumā?

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...