Kaklz

Viss ir atkarīgs no tā, kāds ir plānotais rezultāts. Ja tas ir priekam ko uzkapāt ar čomiem, tad mierīgi varēs iekļauties nelielās summās. Ja tu taisies būvēt azartspēļu sistēmu, tad vispirms palasi likumdošanu. Tur ir atļauja atļaujas galā, programmatūras verifikācija pie sertificētiem uzņēmumiem (tieši lai izvairītos no codez minētās krāpšanas ar AI), u.c. jaukumi, kas normālā gadījumā nav paceļami, jo mērāmi ar kārtu stipri virs pāris simtiem tūkstošu latu.

Miksē abus variantus kopā. Prasi apmaksāt tikai pēc izveidošanas + piedāvā pirkt arī vairāk kredītus un nākamajās reizēs jau izmantot tikai kredītus, nevis veikt apmaksu caur banku.

.. un pēc tam nākas iepazīties ar visiem likumdošanas jaukumiem un apdomāt vai tas patiesībā bija to vērts :)

Pirms kaut ko sāc darīt, drošības pēc palasi krimināllikumu - tur visai smuki ir atrunātas sliktās lietas. Kamēr tu maini ID ar rociņām, tikmēr viss ir forši. Ja tu uzraksti skriptu, tad jau tev var sākt piesieties. No otras puses - ja tu raksti zirnekli, kas staigā pa tev pieejamiem linkiem - visam vajadzētu būt kārtībā (kā nekā pēc šāda principa strādā meklētāji - Google, Bing, utt.). Problēmas, piemēram, rodas gadījumos, ja tu sāc kaitēt portāla darbībai. Piemēram tu ievāc lietotāju vārdus un paroles (ar kādu phishing lapu) un tad sāc viņu vārdā kaut ko rakstīt portālā. Šādā gadījumā tas smuki klasificējas zem krimināllikuma 241. panta: Runājot par grabberiem - lai arī tas nav likumdošanā atrunāts, būtu pareizi, ka tu ievērotu /robots.txt saturā minētos noteikumus un .. vairumā gadījumu uz saturu tomēr darbojas kaut kādas autor/īpašumtiesības.

1) Nomaini $num pret $keyCount ;) 2) $row mainīgais netiek izmantots

44% bounce rate par bēdīgu nosaukt būtu pagrūti: http://www.zigmars.l...ko-ar-to-darit/

ar uzdevuma risinājumu nesaistīts ieteikums: izvēlies vienu valodu, kādā tu sauc mainīgos. Parasti 90% programmētāju izvēlas angļu valodu mainīgo, metožu, klašu, u.c. nosaukumiem. Tavā kodā ir mikslis. Ja nezini atbilstošo vārdu angļu valodā, tas ir lielisks iemesls atvērt vārdnīcu un iemācīties. Pirmās problēmas jau tu pats vari lieliski pamanīt, piemēram šādās struktūrās: public function Action($darbiba,$id,$masivs) { $this->Darit($darbiba,$id,$masivs); } Kas vienkārši pārdefinē atbilstošās funkcijas angļu valodā nemainot ne kripatiņu loģikas. Par pašu uzdevumu - teorētiski tu vari skriet cauri ciklā tam masīvam un taisīt foreach ($masivs as $object){ switch (get_class($object)){ case 'Direktors': $xml .= '<direktors>' . $object -> asXML() . '</direktors>'; break; case 'Apkopejs': $xml .= '<direktors>' . $object -> asXML() . '</direktors>'; vai kāda nu tev tur ir tā XML struktūra. Kodu netestēju, ar SimpleXML esmu darbojies maz, tas ir minējums uzmetot ātrumā aci PHP.net dokumentācijai un pieejamajām funkcijām.

Šis ir tas gadījums, kad pie ātrdarbības vajadzētu pieskaitīt arī koda lasīšanas ātrumu, kļūdu iespējamību un apakšā esošo loģiku. Ja tur var būt tikai skaitļi lielāki par 0, tad jāraksta > 0, ja nedrīkst būt tikai 0, tad tā arī jāraksta != 0 un citu variantu nav. Tu nekad nevari zināt, vai kāds gudrinieks tur kādā brīdī neiemāna kādu negatīvu skaitli, kuru tu vēlāk mistiskā kārtā aizmirsti apstrādāt un viss sabrūk.

Atļaušos nepiekrist par nedēļām.

http://webtech.lv/temp/hwe2/ Ir ok manuprāt :) 1) ja tu dari tādu mahināciju tad tikpat labi tu to lauku tad vari ielikt arī produktu tabulā - nebūs vairs nepieciešamas grupēšanas, kas ir viena no šaurajām vietām 3) tas tev neliedz pie importa ieviest savas primārās atslēgas, kas ir balstītas uz integeriem :)

Starp citu par SQL injekcijām sauc mazliet citas lietas. Lūdzu lieto pareizos terminus :) Tāda wall realizācija vairs nenotiek ar klasiskiem MySQL līdzekļiem - tur apakšā ir stipri jaudīgāks mehānisms un stipri paliela deva maģijas. Vienkāršajā gadījumā var skatīties uz daGrevis piedāvātā risinājuma variantu.

Saliec laika mērīšanu ik pēc kādām n rindām (kaut vai ik pēc 10) vai pirms visām šaubīgajām vietām - pirms pirmā selekta, pirms cikla, pēc cikla. Ātri vien lokalizēsi problēmu un sapratīsi, kas ir tas, kas bremzē. // skripta sākumā $time_started = microtime(true); // ik pēc n rindām vai pirms šaubīgajām vietām echo '<!-- ' . (microtime(true) - $time_started) . '-->'; un pēc tam paskaties sourci, kurā brīdī ir tas maģiskais pieaugums laikā

Iznes ārpus cikla tos abus SQL: Šim nav nekāda sakara ar eventu sarakstu, bet tas tiek 1000x izpildīts viena pieprasījuma laikā $sql_level = mysql_query("SELECT level FROM user WHERE id = '".$_SESSION['uid']."'"); LIST($level) = mysql_fetch_row($sql_level); Šo mierīgi var nedarīt ciklā, bet ārpusē ar vienu query un attiecīgi atkal stāsts par ~1000 query mazāk. // Komentāru skaits pasākumam (pāsakumu sarakstos) $sql_comment = mysql_query("SELECT COUNT(*) FROM comment WHERE event_id = '".$event['id']."'"); Nesaistīti ar SQL: katrā IF zarā šos visus pārdefinēt ir vājprāts. Tos, kas nemainās nodefinē vienreiz un IF konstrukcijās maini tikai tos, kas mainās. if ($m == "all") { $del_show_icon = "style=''"; $del_icon_class = "event_del"; $del_div_name = "follow_del"; $del_show_icon2 = "style='display: none'"; $del_icon_class2= ""; $del_div_name2 = "remove_del"; } else { $del_show_icon = "style=''"; $del_icon_class = ""; $del_div_name = "remove_del"; $del_show_icon2 = "style='display:none'"; $del_icon_class2= "event_del"; $del_div_name2 = "follow_del"; } } else { $show_icon = "style='display:none'"; $icon_class = "event_favactive"; $div_name = "remove"; $show_icon2 = "style='display:none'"; $icon_class2= "event_fav"; $div_name2 = "follow"

Labāk šo laiku velti mācībām. Būs lielāka jēga un lielāka atdeve.

Strādājot par sētnieku (vai jebkuru citu makzvalificētu darbu) tu 100Ls nopelnīsi ātrāk un vieglāk. Zemē nomests laiks.

Beidzot saņēmos un sāku iedziļināties tajā info, ko tu te esi iedevis. 1) ja tu liec indeksus, tad lūdzu vismaz iepazīsties ar pašiem indeksu pamatiem. 3 indeksi uz tabulu, kurai ir 2 lauki ir stipri par daudz. Paskaties kaut vai uz to tabulu caur phpMyAdmin un palasi to, kas rādās ar sarkaniem burtiem uz dzeltena fona :). Ja tu tā indeksus esi salicis visur, tad ir traki :). Neliela piezīme - indeksi arī aizņem vietu uz diska un palēnina datu ievietošanu tabulās, kā rezultātā saliekot daudz nejēdzīgus indeksus tu vari jūtami nobremzēt DB pat pie nelielas slodzes. 2) Atlasīt datus no tabulas tikai pēc kritērija "where published=1" ir auzas jebkurā gadījumā, jo MySQL indeksi šādā gadījumā ir bezjēdzīgi (paskaties beigās pievienoto prezentāciju un cerams pamanīsi par kuru vietu es runāju). Tikpat bezjēdzīgs ir pieprasījums, ja indeksa nav - mysql ir jāskrien cauri visai tabulai un jāmeklē konkrētie ieraksti ar konkrēto vērtību. 3) tavs risinājums ar group by + having meklēšana ar group_concat uzbūvētājā laukā nozīmē, ka mysql katru reizi būs jāiet cauri pilnīgi visiem ierakstiem tabulā un jāmeklē tavi interesējošie kopas elementi katrā no ierakstiem. Ja tu teici, ka tev tie ir 5k, tad tās ir 5k grupēšanas operācijas + pēc tam katrā no grupām vēl 2 meklēšanas. Un tas ir lēni. 4) man nav skaidra tava loģika, kas slēpjas zem šiem pieprasījumiem. tu taisi LEFT JOIN, kas nozīmē, ka tev ir vienalga, ka kādam klasifikatoram varētu nebūt pretī produkts? Tad kāpēc praktiski vienīgais, ko tu mēģini dabūt ir ar produktu saistītā informācija? 5) Nemēģini vienmēr visu izdarīt vienā milzīgā SQL pieprasījumā. Sadali pa daļām. Tavā gadījumā man izskatās, ka varētu darīt šādi: Dabūjam listi ar produktiem, kuriem klasifikatora klases id ir abi definētie: SELECT productHansaCode, COUNT( * ) AS cnt FROM `hwe2_product_classification` WHERE `classificationClassID` in ("0161", "3202") GROUP BY productHansaCode HAVING cnt>1; savācam rezultātu kaut vai uz PHP un pēc tam uzbūvējam vēlvienu SQL pieprasījumu, kurā izmantojam vairs tikai productHansaCode, kuram visticamāk ir primārā atslēga galvenajā tabulā: SELECT hwe2_products.hansaCode AS HansaCode, hwe2_products.decorName AS DecorName, hwe2_products.`length` AS SheetL, hwe2_products.hansaGroupCode AS hgc, hwe2_products.stock AS Stock, hwe2_products.webDescr AS WebDescr, FROM hwe2_products WHERE hwe2_products.hansaCode IN ([iEPRIEKŠ IEGŪTĀ LISTE]) AND published=1 Rezultātā optimizācijas (ja tās vispār ir vajadzīgas) tev ir jāveic praktiski tikai 1. SQL, lai to dabūtu maksimāli ātru, jo otrajā jau viss ir forši - viss notiek pēc primārās atslēgas. Tā kā nav nekāda sīkāka info, tad laba daļa no tā visa ir minējums. Ja dikti gribas iespringt, tad abus manus SQL pieprasījumus var apvienot vienā izmantojot subselect. 6) vai tiešām klasifikatori visi ir tekstuālie mainīgie un arī tabulām primārās atslēgas tu liec kā mainīga garuma teksta laukus? 20 simbolus gari varchar lauki db aizņem 5x vairāk vietas, nekā integer tipa lauks. Atkarībā no tabulas tipa MyISAM / InnoDB tur vēl ir vairākas nianses, kāpēc tas ir slikti no ātrdarbības viedokļa. Paskati kaut vai šo: http://www.slideshar...sql-performance

Labāk pastāsti ideju, ko tu gribi panākt. Tāda datu stumdīšana ar cron slikti beigsies.

Atsevišķa tabula, kurā ir konkrētam ierakstam visi piesaistītie kopas elementi. Bet vispār, ja gribi lai kāds tavā vietā DB kaut ko optimizē, tad dod create sintaksi visām tabulām (redzu, ka esi iedevis tikai vienai), dod piemēra datus un SQL kuru gribi optimizēt . P.S pieprasījumam 0.6 sekundes uz nepilniem 5000 ierakstiem ir drausmīgi lēni.

1) Cenšos ~ reizi nedēļā aiziet peldēt. Pēc fizioterapeita ieteikuma cenšos vairāk peldēt uz muguras, jo tieši tas esot labākais veids mugurai un sēdošajam darbam. 2) Nu jau pāris mēnešus reizi nedēļā staigāju uz karsto jogu (bikramjoga.lv). Manuprāt lielisks vingrojumu komplekss gan mugurai, gan prātam, gan vispārējai veselībai. (info nezinātājiem - nekāda sakara ar budismu vai citām reliģiskām lietām tur nav) 3) Apmēram reizi nedēļā cenšos noskriet ap 5km svaigā gaisā. (arī tagad decembrī). Kad būs sniegs, slēpošu ar distanču slēpēm. 4) vasarā iespēju robežās uz darbu (~15km) pārvietojos ar velo / slidām Pie reizes mums arī darbs ~ reizi mēnesī nodrošina profesionāla fizioterapeita vizīti, kuras laikā visi kauli tiek nolikti īstajās vietās. Katrā ziņā stipri ieteiktu neko nedarīt uz savu galvu, bet speciālistu uzraudzībā. Vai nu tā ir sporta zāle, vingrojumi vai kas cits. Pašdarbībā vēl vairāk vari sačarēt visu.

Ja vien es pareizi saprotu, ko tu domā, tad tā ir ļoti slikta ideja. Labāk aizmirsti par to. Ja tiešām gribi zināt šo slikto risinājumu, tad skaties http://lv.php.net/eval virzienā.

http://www-01.ibm.com/software/awdtools/appscan/ šos man mēģināja ietirgot, tiesa nav īsti bijusi iespēja notestēt. Maksā arī tā visai normāli - ap 10kLs gadā. A triālis tik vien kā dara, kā meklē caurumus viņu pašu speciāli uzbūvētā lapā, kas ir pilnīgi caura kā siets, lai varētu nodemonstrēt visu. Kā jau teica Aleksejs - uz produkcijas vides ar šiem uzmanīgi -ka nesanāk tā, ka viņš paņem un noskenē arī visus http://host/whatever/?deleteprofile=1 un visus pārējos interesantos linkus :)

A kas testā jādara nepastāstīja?

Aizej offline iemuldi ar kursabiedriem turpat kojās, sagrupējieties un viens otru pavelciet uz priekšu. Gan bakalaura, gan maģistra grādu es būtībā ieguvu pateicoties motivācijai no kursabiedriem, kuri neļāva atslābt un atmest ar roku. Reizi pa reizei es arī viņus pavilku līdzi un tikām līdz galam visi.

Ja tas ir starptautisks projekts, tad vari mēģināt flippa.com, tiesa tur par ievietošanu ir jāmaksā kādi 20$, toties tur ir mazāk visādu puskoka lēcēju. Vienīgo savu projektu ko esmu notirgojis uz ārzemēm notirgoju vnk cilvēkam, kas interesējās, vai to nepārdodu . Ja kādu tavs projekts nopietni ieinteresēs, tad tevi atradīs :)

Tas ir pasākums, par kuru ir vērts samaksāt. P.S arī piedalos.