Maris-S

Kaklz, arī normāls programmētājs nevar sevi pieteikt vienkārši apsēstoties pie jebkāda datora kaut kur laukos vai pilsētā vai vēl kur. Jurists arī nevar noīrēt jebkādu biroju un sākt piedāvāt savus pakalpojumus, ir daudz jāiemācās, tam ir jāiztērē daudz laika un šie cilvēki ciena savu iztērēto laiku. Tu padomā pats kāpēc Tu mācījies 12 gadus pamatskolā un vidusskolā, pēc tam gāji uz universitāti, arī patstāvīgi dienām un naktīm meklēji internetā informāciju, pirki grāmatas? Tu to darīji, lai varētu pa 5 minūtēm sataisīt lapas un atdot tās par velti? Ja jau tas ir tik vienkārši sataisīt vizītkartes lapu un uzlikt viņu uz servera, tad kāpēc vispār kāds meklē mūs, mājas lapu izstrādātājus?

Nu lūk arī piemērs, kad ir gatavi taisīt lapu par velti, lai vai kāda tur tā lapa ir un cik viņa ir vienkārša, bet ja ir cilvēki, kas gatavi visu procesu sākot no klienta meklēšanas, runāšanas ar viņu un līdz pat lapas reģistrācijām un novietošanām uz servera vienkārši dāvināt, līdz ar to uzdāvināt visas zināšanas, tad normālu atalgojumu par darbu un zināšanām neviens nedabūs un arī uzņēmēju, no kuriem atkarīgas izstrādātāju algas, naudas apgrozījums samazināsies, jāpielieto elementāra matemātika, lai secinātu kas būs ar izstrādātāju atalgojumu un prasībām pret viņiem.

Indoom, Леший, jā, ir jāveic papildus darbības, lai saglabātu izvēlēto lauciņu. Kā jau teicu, jquery nemaz neesmu lietojis un tikai tāpēc izmēģināju, domāju pārbaudīt vai cloneNode nepilnība viņiem izlabota vai nē, tīri intereses pēc. Pats es taisīju aptuveni šādu javascript: function cancelEvents(e) { if (!e) e = window.event; e.cancelBubble = true; if (e.stopPropagation) e.stopPropagation(); } function clone(element, e) { var dub = element.cloneNode(true); if (!e) var e = window.event; element['on'+e.type]=null; if (typeof(dub.value)!='undefined') dub.value=''; element.parentNode.appendChild(dub); cancelEvents(e); return dub; } function cloneRow(element, e) { newRow=clone(element, e); //IE do not leave selected option after clone select element. var previousSelects=element.getElementsByTagName('select'); var newSelects=newRow.getElementsByTagName('select'); for (var i=0; i<previousSelects.length; i++) if (previousSelects[i].name==newSelects[i].name) newSelects[i].options[previousSelects[i].selectedIndex].selected=true; var newInputs=newRow.getElementsByTagName('input'); for (var i=0; i<newInputs.length; i++) newInputs[i].value=''; cancelEvents(e); return newRow; } Briedis, jā, bet bugs izskatās ir izlabots, jo ar jaunāko jquery stradā IE, bet sācis Mozillā FF nestrādāt, laikam pārcentušies. Par to 'javascript:' īsti pat nezinu vai jāliek vai nē, parasti viņš arī ieliekot strādā pareizi, tur vēl var būt arī 'vbscript:'. Cik uz ātro pameklēju tad sanāk lapā pieeja būtu izmantot meta tagu, kas norāda kādi skripti tiks izmantoti tālāk un tad pēc tam viņu nenorāda. <meta http-equiv="Content-Script-Type" content="text/javascript">

Ja jāuzliek cms tas pat tuvu nav vizītkartes tipa lapai, lūk vizītkartes tipa lapas piemērs: http://www.medijumi.lv/medijumi.html, pie tam 30 ls ir bez dizaina. Dizains var izmaksāt arī klāt 100-150ls. Kā jau rakstīju ņemot vērā visas papildus darbības, ar to domāju par papildus darbībām atbilstoša cena.

Леший, nestrādā vienalga. Domāju tas ir saistīts ar cloneNode metodes nepilnībām. Pagaidām cits darbiņš jāpadara, būs vēl Briedis ieteikumu jāizmēģina pēc laiciņa.

Principā tā nav sūdzēšanās, ja palasa uzmanīgi nosaukumu un saturu un uzmanīgi paseko līdzi rakstītajam, tad runa iet par iemesliem kāpēc parādās sludinājumos visziņu meklēšana. Parasti ieraugot tādus sludinājumus bieži sanāk dzirdēt ka tā tāda stulba pieeja, te es nedomāju par kādu konkrētu sludinājumu. Mans garais sacerējums ir vairāk kā mans personīgais viedoklis kāpēc rodas tādas situācijas un kritizēt tikai darba devējus par to nav īsti pareizi. Arī nekur neesmu teicis ka vizītkaršu lapa ir jātaisa par tūkstošiem, arī agrāk neviens par tūkstošiem viņas netaisīja, varbūt gadus 15 atpakaļ. Vizītkartes lapai 30 ls ir normāla cena, protams ņemot vērā cik konkrētam gadījumam tiek veiktas papildus darbības. Progress tas protams ir, bet nu ja programmētāji pārdod savas zināšanas pa lēto, tad darba devējs vienkārši nespēs uzturēt dārgus speciālistus katrā lauciņā. Par to kāpēc izstrādāt mājas lapas no lego klucīšiem arī nesanāk pa lēto jau pateicu. Daļēji šis viss izskaidro kāpēc iesācēji dažreiz slinko un negrib apgūt pašus pamatus, ne reti php.lv forumos pieredzējuši programmētāji brauc virsū iesācējiem kad tie slinko un paši nemeklē literatūrā atbildes. Bet priekš kam meklēt? Saliks, izmantojot gatavu cms, izprasīs forumā dažas vienkāršas atbildes un pārdos lapu pa 30-50 ls. Nav jau nekādas motivācijas mācīties. Par to vai tas viss man personīgi rada problēmu un vai ir iemesls sūdzēties... Pagaidām nē, kā jau teicu, ja klients grib pa lēto un saka man ka lūk atradu vienu kas taisa uz pusi lētāk, tad arī pasaku viņam, ka mana cena ir tāda kāda viņa ir un viņš var izvēlēties pie kā taisīt, protams arī paskaidrojot no kā rodas cena, ja viņš vēl vēlas klausīties. Vai tas viss man radīs problēmas nākotnē? Nezinu, laiks rādīs.

Foxsk8, viedoklis ir ļoti labs un pilnīgi pareizs. Savā domu gājienā es negribēju pateikt ka tikai un vienīgi programmētāji ir vainīgi, bet aprakstīju tieši to daļu kurā tomēr ir viņu ietekme kopējās darba spēka izmaksas samazināšanā kā arī kāpēc veidojās situācija kad meklē cilvēkus ar plašām zināšanām. Tā nav liela daļa visumā no kopējās problēmas, jo patiešām, kā Tu saki, programmētāji arī pielāgojās tirgus situācijai, bet tā kā katrs domā vairāk par to kā izcīnīt tieši sev projektu (arī es tā daru), tad laika gaitā pa mazam cena iet uz leju un nav kopējas vienas sfēras speciālistu labas ilgtermiņa stratēģijas, bet protams tas reāli nav nemaz iespējams. Tas ka mājas lapas sastādītajai tāmei ir smuks apraksts par izstrādes izmaksām, tas ir ļoti pareizi, to sapratīs darbinieki, arī darba devējs to ļoti labi sapratīs, bet ar klientu ir sarežģītāk, viņš uzreiz pateiks ka redz te man piedāvā to pašu nevis pa 500 ls, bet saliks par 80 latiņiem uz gatavas cms bāzes, tā paša wordpress. Patiesību sakot viņš pat nepateiks, vienkārši apskatot tāmi vairs nekontaktēsies un viņam nevarēs paskaidrot: ka reāli kvalitatīvu projektu tik lēti sataisīt nevar, ka pat gataviem cms ir jāseko līdzi, jāskatās kas par drošības caurumiem atklājas laika gaitā, jāspēj reaģēt uz to, tāpēc ka izplatītam open source tas ir ļoti svarīga lieta, jāatjaunina laicīgi, jāpārbauda vai pēc atjaunināšanas viss strādā, tātad seko arī kāda uzturēšanas maksa utt. un tajos 80 ls sasniegt kvalitāti nu nekā nesanāks. Bieži vien klientam kvalitāte nav svarīgākā lieta un daudzi izstrādātāji uz to arī dzīvo, protams kamēr nesaskaras ar sekām, piemēram, rodas nepilnības ar kurām izstrādātājs netiek galā, jo lētums nesniedz motivāciju savlaicīgi padziļināt zināšanas un kopēji skatoties kvalitātes līmenis zems ne tikai konkrētai mājas lapai, bet Latvijas darba tirgus izstrādātāju vidējais rādītājs kvalitātei pazeminās, līdz ar to 90-tajos gados esošais uzskats, ka Latvijā programmētājiem liels potenciāls un iespējas, vairs nepastāv. Šķiet tas bij Šķēle, iespējams tomēr cits politiķis, kas kādreiz izteicās ka sevi cienošs programmētājs nestrādās zem 2000 ls mēnesī, tagad izklausās smieklīgi. Man personīgi sanāca runāt, pirms krīzes, ar cilvēku, kas saistīts ar būvniecību, tajā laikā būvniecībā strādāja daudzi mazi uzņēmumi un darīja to pa lēto, kvalitāte protams zemāka, līdz ar to dažiem potenciālajiem klientiem radās uzskats ka Latvijā nav vispār kvalitatīvu būvnieku. Tā kā būvniecība nav mans lauciņš, tad nevaru apgalvot neko par situācijas patiesumu, bet vismaz informācijas tehnoloģijas pie mums ļoti strauji iet uz šādu līmeni. Tādai intensīvai produkta cenas samazināšanai izstrādes cena normālā veidā tikt līdzi nespēj, jo projekta cena nespēj segt pareizu un kvalitatīvu projektu izstrādāšanas pieeju. To var atļauties lielie uzņēmumi bet mazie un līdz vidējiem un arī iesācēji nevarēs, ja nav lielas rezerves attīstībai un reklāmai. Tā kā ienākumi par projektu nesedz izstrādāšanas izmaksas, kaut kur jāsāk samazināt izdevumi, pareizāk sakot nav jāpalielina izdevumi, piemēram uz papildus darbiniekiem un rezultāts ir viena darbinieka meklēšana, kas varēs strādāt pie jebkuras projekta izstrādes posma daļas. Tā patiešām nav izstrādātāju vaina, bet sava ietekmes daļa tādas situācijas veidošanā ir. Kā jau teicu, izveidot kopēju kvalitatīvu stratēģiju mājas lapu izstrādātāju vidū nav iespējams, tad noteikti radīsies jautājums - kāda jēga no šādām diskusijām? Jēgas lielas nav, bet, ja tie izstrādātāji, kas tikai tagad uzsāk savu darbību un ienāk mājas lapu izstrādātāju tirgū, atradīs informāciju par cenas/kvalitātes attiecību, par aptuvenu projektu izmaksu pašnodarbinātības un oficiālajā darba tirgū pašreizējā laikā, tad viņiem būs nojausma uz ko tiekties un iespējams ilglaicīgi nepievērsīsies lētā gala izstrādes pieejai un tādā veidā kopēji samazinās cenu kritumu, arī konkurence un klienti no tā būs tikai ieguvuši, jo izstrādes kvalitāte un arī izstrādātāju motivācija būt uzmanīgākiem, attīstīties un strādāt precīzāk paaugstināsies. Kaklz, arī Tev ir taisnība, strādājot pie maziem projektiem ir salīdzinoši vienkārši apvienot vairākas izstrādes posma lietas. Tomēr, kaut arī šo diskusiju pamudināja uzsākt konkrēts sludinājums, mana galvenā doma ir tieši diskusija par darba tirgu mājas lapu izstrādātājiem kopumā Latvijā. Ja runā par konkrēto sludinājumu, tad par viņu uzņēmumu neko jau nezinu, tāpēc nevaru spriest ne par projektu apjomiem ne par ko citu, bet ņemot vērā manu jau izklāstīto viedokli uzskatu tas ir normāli. Neskatoties uz to cik uzņēmums ir liels, tad ir tikai apsveicami ka tāds vispār ir un kāds uzņēmīgs cilvēks kaut ko dara, varētu viņam tikai novēlēt veiksmīgi attīstīties un tad jau arī parādīsies vajadzība un arī iespēja veikt darba dalīšanu. Katrs darbinieks kaut kad uzsāk savas darbības un ļoti daudzi ir uzsākuši tieši strādājot pie vairākām lietām, daudzi arī turpina. Tomēr ilgtermiņā tas nenesīs optimālāko rezultātu ne uzņēmumam, ne darbiniekam, ne klientam, jo strādājot ar visu vienlaicīgi darbinieks pārāk lēni virzīsies līdz profesionāļa līmenim tieši savā lauciņā, varbūt arī nenonāks līdz tam, līdz ar to arī uzņēmuma profesionālais un produktu līmenis neaugs. Man liktos nesaprotama situācija kad samērā liels uzņēmums, kas spēj uzturēt kvalitatīvus profesionāļus katrā sfērā, izmantotu lētā tirgus situāciju un samazinātu izdevumus aizvietojot vairākus speciālistus ar vienu cilvēku, kas dara visu, nedomāju ka tas palielinātu produkta kvalitāti, bet katram par to ir savs uzskats, pie tam domāju tiem, kas izstrādā lielus un nopietnus projektus, darba dalīšana ir labi organizēta. Tāpēc uzskatu ka tas ir normāli kad ģēniju meklēšana parādās pie maza apjoma projektu izstrādāšanas, bet tiekties vajag pēc apjomu palielināšanas un darba dalīšanas, lūk tad kad visiem būs tāda tieksme un izpratne priekš kam to vajag, ieskaitot klientus, lūk tad arī pacelsies darba produktivitāte, kvalitāte un šķietami dārgākās izmaksas kopumā atmaksāsies.

Tā kā darba sludinājumi bieži vien aiziet netēmā, tad savas domas par darba dalīšanu, kas radās palasot atbildes uz šo sludinājumu, izteicu šeit: http://php.lv/f/topic/17155-imesli-kapec-tiek-mekleti-geniji

Šo tēmu pamudināja aizsākt šis sludinājums: http://php.lv/f/topic/17129-meklejam-programmetaju Parasti diskusijās pie darba sludinājumiem mēģinu neiesaistīties, jo aiziet netēma un bieži vien daudzi kritizē potenciālos darba devējus, tāpēc arī ievietoju netēmā ar atsauci uz darba sludinājumu. Šoreiz nolēmu izteikt viedokli par mājas lapu izstrādes darba dalīšanu. Protams es palieku pie viedokļa ka ir jāatdala tādas lietas kā sistēmanalītiķis, programmētājs, dizaineris, administrators utt. Tomēr ja paskatās uz esošo mājas lapu tirgus situāciju, tad jāsaka ka Latvijā tas ir diezgan sarežģīti sasniedzams. Par pareizu darba dalīšanu varētu domāt uzņēmumi, kuru apgrozījums ir stabili virs vidējā un pat augstāks, nevis dažas lapiņas mēnesī un kuriem jau ir izstrādāti salīdzinoši daudz projekti, kas tiek izvietoti uz uzņēmuma serveriem un spēj atpelnīt aparatūru un administrēšanu (serveru administratori nav lēti), vai arī kas spēj droši atpelnīt vismaz uzņēmuma iekšējo sistēmu administrēšanu. Ar salīdzinoši mazu mājas lapu izstrādes projektu apgrozījumu tādu sadalījumu nav viegli uzturēt, jo vidējā cena mājas lapām paliek ar vien zemāka kā jau Latvijā daudz kam, kā saka lētais darba spēks un diemžēl pie tā ir vainīgi arī paši programmētāji. Te pat, pēc foruma tēmām, var redzēt ka bieži vien viens cilvēks strādā gan pie dizaina, gan programmē. Tādā veidā protams mājas lapas cena tiek samazināta, lai izkonkurētu pārējos, bet kvalitāte diez vai palielinās, vai nu dizains vai programmējamā daļa būs izveidota neprofesionāli. Ļoti bieži šeit tiek izteiktas domas par mājas lapām kuru secinājumi dažreiz nonāk līdz aptuveni tādam - tā lapa ir 30 ls vērtībā jo to var pa stundu vai divām salikt wordpresā. Galīgi tam nepiekrītu un personīgi es nekad netaisu lapas kam ir cms zemāk par 100-150 ls, pat ja tās būtu uz wordpres vai vēl kāda cita cms un tas pat ir pats mazākais minimums. Domāju 30 ls varētu maksāt kāda vizītkartes tipa lapa ar vienu valodu un vienu, divām sadaļām, ar vienkāršāko dizainu vai arī jau ar saliktu dizainu htmlā un normāli saliktu. Pat par šo pašu ir jādomā vai ķerties klāt, jo vēl būs jāiztērē laiks, lai saskaidrotu klientam kas ir hostings, kam to vajag, kāpēc viņam vajag tieši izvēlēties pa 5 ls mēnesī, nevis lētāko pa 2.50 ls (piemēram, lētajam ierobežots e-pasta adrešu skaits), kas ir domēna vārds, kas tie par papildus tēriņiem un vēl jāaizpilda viņa vietā visas pieteikuma formas un jāsakopē visu uz serveri, tātad klāt arī administrēšana, it kā sīkums, bet kopā salasās. Ar šo visu garo sacerējumu gribēju pateikt, ka pašreiz braukt virsū uzņēmējiem par to, ka meklē ģēnijus, kas prot visu, nav īsti pamatoti. Ir jāpaskatās uz to arī no uzņēmēja puses, jo tagad tirgus situācija ne vienmēr ļauj izdarīt visu no pareizākās puses, tas protams nav pareizi, bet daļēji vien paši esam vainīgi. Tā teikt jāiemācās cienīt pašiem sevi un pareizi noteikt savu cenu. Ir jāatceras ka izstrādājot mājas lapu Jūs prasāt samaksu ne tikai par 2 stundām darba wordpress konfigurēšanai, bet arī par administratīvo darbu un vēl svarīgāk par mēnešiem un gadiem iekrātajām zināšanām, kuru vērtība ir daudz reizes lielāka par laiku ko Jūs iztērējat mājas lapas izstrādei. Kamēr būs izstrādātāji, kas taisa lapas pa lēto, vai dažreiz pa velti, Latvijā mājas lapu tirgus paliks lētā darba spēka līmenī un līdz ar to tirgus pats no sevis pieprasīs meklēt ģēnijus, kas prot visu.

Леший, piekrītu, tieši tādu variantu arī domāju, bet vienīgi parasti sanāk nevis tabulas taisīt pamatojoties uz checkboksiem kādus vajag, bet gan checkboksus taisa no tabulām kādas ir sistēmā, piemēram valodām - id un language laukiem. Tad arī pa ciklu vienmēr pārbauda datus no datubāzes un salīdzina ar post datos sūtītajiem, ja tāds ir post datos, tad šī vērtība tika atzīmēta. Protams datubāzes vietā var izmantot arī manuāli veidotu masīvu.

Vēl vari padomāt par tiem 10 insert otrajā tabulā, iespējams tos var apvienot vienā vaicājumā, bet bez tabulu struktūras un konkrēta piemēra nevar neko precīzi pateikt. Jebkurā gadījumā transakcijas būs vajadzīgas, pirmās tabulas insert būs atsevišķi.

Tā tīri intereses pēc izmēģināju, jo man no jquery īpaši nav nekādas zināšanas pagaidām, bet liekās dīvaini tas, ka jquery neprecīzi apstrādā <select> elementus, neatstāj izvēlēto vērtību. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Jquery</title> <script type="text/javascript" src="js/jquery.min.js"></script> </head> <body> <div id="container"> <div id="content" style="width: 250px; height: 150px; margin-top: 10px; background-color: lime"> <select name="choose"> <option value="1">Viens</option> <option value="2">Divi</option> <option value="3">Trīs</option> <option value="4">Četri</option> </select> </div> </div> <input type="button" value="Pievienot" onclick="javascript: $('#content').clone().appendTo('#container');"> </body> </html> Sākumā īsti nestrādāja ne mozillā, ne IE8, nokopēju jaunāko versiju, tagad IE8 strādā, bet FF vienalga nē, IE6 un Operā arī strādā. Tā kā esmu taisījis šādas lietas patstāvīgi, bez jquery, tad ir zināms tāds bugs IE pārlūkos, ka javascript cloneNode metode neatceras select izvēlēto vērtību, iespējams tāpēc arī vecāka jquery versija nepareizi darbojās ar šo lietu, bet tagad tas ir labots. Tomēr tā kā joprojām nestrādā FF, tad ir jautājums, tas ir jquery bugs, vai es tomēr kaut ko daru nepareizi?

Domāju Evi runā par GUI, nevis komandrindas, pārlūkiem.

Īsti nezinu kā Tu domā ielikt vienā tabulā, laikam domā vienā laukā. Tātad vadoties pēc mana iepriekšējā piemēra arī taisi rakstzīmju virkni, saprotamāk runājot stringu, kas pa ciklu liek klāt atzīmētos, tātad post datos esošos, ķekšus.

Kāpēc neder? Sākumam lai taisītu checkboksiņu sarakstu izvelc to identifikatorus no db, tad kad saņemsi post datus pa ciklu jāiet izvilktajiem no db, salīdzinot tos ar post datiem: $check_db=$db->query('...'); if (isset($_POST['submit_ok'])) { $received=$_POST['c']; freach ($check_db as $value) { if (isset($received[$value['id']])) echo($value['id']); } Protams te bez pārbaudēm un līdzīgām lietām, bet pareizs kods jātaisa atbilstoši esošai situācijai.

Es personīgi nelietoju jquery cik vien tas iespējams, bet daži gatavi skripti ir bāzēti uz tā vai kādām līdzīgām bibliotēkām, bet tā salīdzinoši vienkāršām darbībām pašam savs javascripts.

Tavā gadījumā, ja Tu domā parādīt komentārus pie ziņu izvilkšanas, tad vienkāršākais variants, jau ar esošajām tabulām, būtu apmēram tāds: select a.*, count(b.id) as comment_count from news a left join news_komentari b on b.nid=a.id Protams vaicājumu nepārbaudīju, bet doma tāda ka Tu tabulas news datu izgūšanas laikā vienlaicīgi izvelc arī atbilstošo komentāru skaitu. Codez variants arī labs, bet ja negribi ar php skriptu katru reizi liekot vai noņemot komentārus veidot vēl vienu atsevišķu vaicājumu un ja Tev ir vēlēšanās mācīties dziļāk, tad paskaties mysql triggers. Datumu formatēt vari ar php funkciju date(), tikai sākumā Tev no datubāzes jādabū unix timestampu, to var izdarīt ar mysql funkciju unix_timestamp, to var atrast šajā sarakstā.

Kāpēc uzreiz jākaujas, var par precību un kāzu lietām kaut ko veidot.

Šis labais: 'skolai sākoties ... galvenais, lai jaunākās spēles iet'. Pareizi, ko vēl skolas laikā darīt!? :) Piedošanu par joku, nenoturējos!

Cik sapratu tad viņam vajag vienu div otram pa virsu, skatoties pēc viņa pozicionēšanas attālumiem, ja doma ir nolikt vienu otram blakus, tad jā platuma izmēri nav pareizi sarēķināti. Apkārtējā div augstuma izlabošanai varētu palīdzēt 'clear floats' izmantošana. Tas <br> manējā piemērā ir tāds ne css risinājums, lai izlabotu ārējā div augstumu.

Ieliec kodam sākumā: error_reporting(E_ALL); ini_set('display_errors', true); Iespējams līdz vaicājumam nemaz nenonāk.

Pamēģini: float: right; Ja pareizi saprotu ko jāpanāk.

Tev vajadzīga absolūtā pozicionēšana. <div style="width:500px; position: relative"> <div style="width:200px; float:left; background-color:red">X1</div> <div style="position: absolute; width:400px; top:2px; left:0px; background-color:green;">X2</div> <br> </div>

Konkrētas klases pārzināšana gan ir jautājums, kurš būtu jāapskata no visām pusēm. Piemēram, man ir gadījies, kad izveidoju klasi un dažas no metodēm neizmantoju bieži, gadās pie viņām atgriezties pēc ilgāka laika, ka pat neatceros nosaukumu, kamēr nepaskatos metožu sarakstu, paskatoties protams var izsecināt kura no metodēm ir šitā. Tādā situācijā man metožu nosaukumi q1(), q2(), q3() nepalīdzētu. Protams Tev taisnība ka datubāžu vaicājumu metodes tiek izmantotas ļoti bieži, bet piemēram klasei ko es iepriekš aprakstīju es pārsvarā vienmēr lietoju query_assoc() un query_value() metodes, dažreiz query_row(), pat neatceros vai vispār esmu lietojis query_array() un ja man retāk izmantojamās metodes, piemēram query_row() un query_array(), būtu nosauktas ar cipariem, es noteikti viņas kaut reizi, bet sajauktu. Mans viedoklis par šo tāds. Savējās bieži izmantojamās klases metožu nosaukumos lietot nosaukumus kā qn() ir pieļaujams, bet nav ieteicams, jo nevar zināt vai kādam vēl būs jāstrādā pie projekta un vai nesanāks tā ka ilgstoši nevajadzēs izmantot klasi. Taisot reti izmantojamas klases vai pat vienreizējās konkrētam projektam vai arī klasēm plašākai publikai tādi nosaukumi ir pilnīgi izslēgti.

Kā jau teicu, kodā ir skaidrs, bet kad jāmeklē metode pēc nosaukuma un jādomā ko tad īsti viņa dara, tad gan ir atšķirība. Par rindas garumu saekonomējot kādus 10 simbolus, pat 30 simbolus Tu neko īpaši neiegūsi, nopietni vaicājumi dažreiz izveido skrullīti ne tikai uz sāniem, bet arī uz augšu un leju.