gurkjis

Ar getimagesize(), ja masīva pirmie 2 elementi (platums un augstums) ir lielāki par 0, tātad ir bilde.

Darbs ieguldīts, liekas, ka vēl kādam varētu noderēt.... bet ieleja jau parādīja, ka tādas lietas notiek par velti. Otrs moments, cik gan liela iespēja,ka 1) vēl kāds php.lv lietotājs lieto šo foruma sistēmu + 2) viņam tieši LV valodu vajag... Tikai filozofēju.

nu jā, es šito zinu, bet man likās,ka pēdējās versijās varbūt jau ir tomēr sataisījuši kompilatoru-uz-bytekodu un tad pārkompilē tikai, kad source ir mainījusies. Kaut kā grūti ticēt, ka katru reizi ņem un parsē tekstu.. tas ir obvious performance loss. Tur jāskatās internāļos, jo ātrums tomēr PHP ir normāls un kā tieši viņi to panāk.

Kāpēc PHP kompilētājs nevar pats detektēt, ja double quoted stringā nav izmantoti fancy mainīgie, tad to interpretēt kā single quoted ? We need smart software! Tas ir kompilatoru uzdevums, optimizēt obvious lietas.

Piekrītu, ja ir viens kopējs projekts, tad stils ir jāievēro. Tur nav iemesla strīdēties. Ja programmētājs neprot adaptēties, tā ir viņa deficience jeb trūkums. Man šāds trūkums ir, tāpēc es izvēlos strādāt pa savam, lai man nav sevi jāspiež darīt neērtas lietas.

ā. nu jā :) Vajag performance benchmarku, tad ticēšu, ka tas ir slikti, no tāda viedokļa skatoties. Bet tā atkal ir uztraukšanās par nenozīmīgiem sīkumiem. Programmētāja laiks ir dārgāks par mašīnas laiku.

Aha, un ja apostrofs tiek lietots arī kā mēmais priekš LV simboliem, tad vispār programmētājam tādas sienas sabūvētas priekšā... tāpēc es mēmo lietoju tildi ` (to, kas zem Esc).

Saprotu, man arī bija tāda slimība, bet viņa mani "vilka uz leju", jo pārāk bieži biju iestrēdzis "kodešanas izvirtībās", aizmirstot vai novilcinot projekta reālo virzību.

Pamēģiniet kodēt bez apziņas "waste of resources" jeb domājot par priekšlaicīgu optimizāciju... atveras uzreiz jauni ceļi, kā problēmas risināt, nevis laicīgi iespējas nocērtot "tā nevar darīt datoriņam būs grūti". Labāk dabūt normālu rezultātu no funkcionālā viedokļa ( ko var ātrāk/labāk izdarīt,kad atmetam optimizācijas untumus), un tad,ja kāds aparāts sāk protestēt, sāciet optimizēt (protams ja bizness tik tālu vispār tiks).

nu ja tev ir tikai key-value pāri, tad jā, JSONs nav nepieciešams. Bet ja vajag sarežģītākus datus ar masīviem un objektiem, tad ir savādāk. Man liekas, ka tu runā par parastu form-encoded pieprasījumu, bet manā gadījumā bez JSON encode neiztikt, un headerī arī jānorāda application/json, savādāk Chrome taču nemēģinās zīlēt, ka contentā ir tieši JSONs un tāpēc tagad to attiecīgi formatēs Preview tabā...

Ko mocaties ar niekiem.. ja viss darbojas, tad nav īpaši svarīgi, kā tiek panākts. Mans variants, kuru lietoju un esmu laimīgs ar to: Javascript: var url = '/my-api'; var data = { some_key: 'some_val' }; $.ajax(url, { type: 'POST', contentType: 'application/json', data: JSON.stringify(data), dataType: 'json', success: function(response, textStatus, jqxhr) { console.log(response); } }); PHP: <?php $data = json_decode($HTTP_RAW_POST_DATA); // te daram kaut ko ar datiem // ... header('Content-type: application/json; charset=utf-8'); echo json_encode(array( 'success' => true, 'some_data' => 123 )); Attiecīgi, gan nosūtīto, gan saņemto var skaisti formatētu apskatīt caur Chrome devtools.

ar array_splice var dzēst elementus, tev tikai jāiet abiem diviem masīviem cauri un, kad sakrīt id vērtības, tad dzēs, padodot indeksu uz array_splice($masivs, $indekss, 1);

Lai PHP pusē lasītos kā JSON, Tev tas saņemtais strings jānoparsē.. ar json_decode()

Jau gribēju ieteikt paņemt custom Webkit bāzi un pielāgot, bet likās, ka varētu būt overheads tādas vienkāršas fīčas dēļ ņemties. Bet ja sanāca, tad jauki.

googlejot pēc: js print without dialog pirmo linku atverot, kļuva skaidrs, ka tas pa lielam legālā standarta veidā nav iespējams, bet ir daži konkrēti gadījumi, kad tomēr tas ir iespējams (noteiktos pārlūka un OS konfigurācijās)

Par patterniem - arī uzskatu, ka tos vajag lietot, ja Tu jūti "natural fit" jeb tas makes real sense pielietojumā, taču tā nav, ka es meklēju kaut kādas patternu idejas, ko pielietot kodā, parasti ir otrādi, ka man ir kaut kādi izveidojušies ieradumi lietot noteiktus risinājumus noteiktās situācijās, un tad es saredzu līdzību šiem ieradumiem ar patternu aprakstiem. Pieņemu, ka firmās vecākie programmētāji "iesaka" lietot šādu vai tādu patternu, bet jaunais programmētājs īsti nesaprot, kāpēc tas vajadzīgs.. bet es arī nelietotu, ja tas doesn't make sense. Par tiem var ievākt informāciju, lai būtu smadzenēs kaut kāds "iespējamais scenārijs", kas lai tur sēž, līdz radīsies klikšķis... vai neradīsies. Tam pašam JS ir daudzas bibliotēkas,kas simulē OOP, super vienkāršs variants ir http://ejohn.org/blog/simple-javascript-inheritance/ Tagad ir arī daudzas šādas te kompilējamās-uz-Javascript valodas, tā kā mierīgi var izvēlēties to pašu Dart vai citu, kas sirdij tīk.. es iesaku Haxe, kas jau ir tuvāk Actionscript3 pēc līdzības un tajā ir klasiskās OOP un citas lietas.

"daudz lielāka kontrole" - tas ir arī - daudz plašāks iespējamību lauks, līdz ar to ir daudz sarežģītāk tajā orientēties = lielāka iespējamība uz bugiem. Abstrakcijas pilda uzdevumu "lai apakšas dara mašīna un lai cilvēks spētu operēt augstāk". Lietojot abstrakcijas, retajās reizēs, kad ir kas specifisks vajadzīgs, tad jāsajūdz ar slāni zemāk. Tas pats attiecas arī uz multiplatform izstrādes frameworkiem - tiek nodrošināta funkcionalitāte, kas nosedz lielāko daļu lietošanas gadījumu, bet retajās reizēs, pēc specifiskas platformas fīčas - tiek rakstīts custom modulis. Tieši par multiplatform frameworkiem, man ir aizdomas, ka šī stratēģija no biznesa viedokļa ir ļoti izdevīga, taču ir cilvēki, kas saka, ka tas līdz galam nav efektīvi. Vēl nezinu, pats gribu pārbaudīt, it kā obviously un pēc pirmās loģikas tā sanāk, bet praksē jau visādi gadās. Bet nu aizdomājos offtoptic, sry.

Tas īsti nav precizēts, bet budžets = 0 EUR ?

Domāju,ka problēma ir dēļ veciem PHP MySQL tutoriāļiem, kas jauniņos novirza no efektīvākas programmēšanas ceļa.

Nu Tev vienkārši ieselektētajam option tagam ir jāiedod atribūts selected="selected" , tas ir vienīgais veselīgais veids, kā to darīt. Pārējo jau sarakstīja citi biedri, bet pamēģini varbūt arī izmantot php short tagus templeitiem, citadi tie daudzie <?php izskatās pēc izvarošanas scēnas. Un <?php echo 'some' ?> vietā var izmantot <?='some' ?> Ja nemaldos, short tagi ies defaultā kaut kādā no jaunajām php versijām, nevis būs atkarīgi no ini settinga.

Virsrakstā tu piemini <select> tagu, taču kodā to neredzu, ka ar to kaut ko darītu... Varbūt tu saki, ka gribi veidot custom izskata dropdown menu ? Ir gatavi jquery risinājumi tam, google: jquery custom select

Nu laikam visjēdzīgākais ir, ka pie logina username.domens.lv veikt redirektu uz lapu domens.lv, no kurienes veic aktuālo loginu uz soc. portālu, tad portāls redzēs tikai domens.lv.

To nevar pieļaut, ka mašīnas pārņem mūsu pasauli. Mašīna ir instruments, kuram jāpakļaujas cilvēkam, nevis otrādi. edit: aizmirsu: tehnoloģiskā singularitāte ir moments, kad mašīna kļūst gudrāka par cilvēka smadzenēm, un pati spēj strauji advancēties, tad gan tur jāsāk baidīties patiesībā.

codez atkal troļļo :D

- nu tas jau atkarīgs no personības, jebkurā jomā tādi neattistīti kadri var būt. Dators vēl nav visa dzīve, programmētājam ir jādomā, kā sevi attīstīt ne tikai kā profesionāli, bet arī kā cilvēku. Agrā jaunībā, es tam neredzēju sakaru, bet tur ir ļoti spēcīgs sakars. Kad Tu risini sarežģītas problēmas, ir atkarīgs, kāda ir Tava attieksme pret to... iedomīgi pašaizsardzīgi egoisti ("pat ja kļūdijās turpina palikt pie sava") - tas man konkrēti atgādina bērnu / pusaudžu līmeni. Normāli pieauguši cilvēki tā nerīkojas. Ja rīkojas, tas nozīmē, ka viņi ir iestrēguši noteiktā punktā uz savas personības izaugsmes skalas.