mandarīnpīle

Omg, omg, omg laikam neesmu vienīgais kurš par tādām lietām aizdomājies. Par to, ka cilvēks ir mašīna ar organiskās bioloģijas mehāniku un nukleotīdu programmatūru. :-| Šo teoriju šķoba tikai viena lieta: 1. Mēs varam izgatavot programmatūru kas uz noteiktiem ievaddatiem izdod tādus izvaddatus, ka liekas - tā ir saprātīga. 2. Un apmēram tā arī es uzlūkoju cilvēku, tikai tas ir daudz, daudz sarežģītāks software kopums. Mašīna, kas var reaģēt daudz dažādos veidos. 3. Vienīgā problēma - kāpēc mums ir apziņa? Mašīnām, lai cik daudz dažādos veidos tās nespētu reaģēt un pieņemt lēmumus, apziņas taču nav? Vai varbūt tomēr ir? No kurienes rodas tā dzirksts mums galvā, kas liek sevi apzināties un tā teikt dzirdēt savas domas? :-| Ja nu arī mans laptops sevi kaut kādā līmenī apzinās?

Šobrīd tā tiek darīts, bet it feels so wrong.

Nepieciešams Skats ar garu, sarežģītu SELECT statementu. Lai pats un citi varētu to vēlāk pielabot, saprast, pievienoti komentāri un tādas konstrukcijas kā JOIN ir katra savā rindā. Nu, uz šo pusi: -- Descriptive comment SELECT .. FROM .. LEFT JOIN .. ON RIGHT JOIN .. ON -- Another info Bet šo skatu izveidojot, mysql dzēš visus komentārus un sastumj visu vienā garā rindā, turklāt ar JOINiem saliek jocīgas iekavas. Jautājums - kā saglabāt saprotamu struktūru?

Sākotnējais risinājums (neapdomīgi lietojot ORM) ar veselu kvēriju kaudzi izpildījās 1.5 sekundēs. Visus datus ielasot vienā kvērijā un tad loopojot php pusē visa padarīšana ielādējās 0.1 sekundē.

Kādi ir plusi un mīnusi foreign key norādīšanai jau datubāzes schemā, kādos gadījumos to darīt un kādos ne? Vai tas ir nepieciešams, ja visas šīs saistības ir norādītas jau php pusē Modeļos? Cik pats saprotu: Plusi: Neļauj insertot, updeitot tādus ID, kas nemaz neeksistē Neļauj izdzēst tādus ierakstus, kas kaut kur ir referencēti Mīnusi: inserti, updeiti ir daudz lēnāki, jo jāpārraksta viss indexs. Piemēram, ja man ir tabula, kurai ir PK un kādi 6-7 FK. Vai SELECT pieprasījumi strādās ātrāk, ja norādīšu, ka tie ir FK? I mean - tik pati labi šīs saistības var uzrakstīt tikai php pusē Modeļos.

Mani interesē ko codez domā par to programmēšanu, kas šobrīd vidusskolās jau notiek. 95% gadījumu - Pascal. Pārējie pieci sadalās starp C++ un Java. Vai tas ir normāli? Kādā blogā izlasīju labu salīdzinājumu - kaut arī stūrēšanas un pedāļu spiešanas pamatprincips nemainās, autoskolās šodien nez kādēļ nevienu nemāca braukt ar veciem žiguļiem. Kādēļ tā notiek vidusskolās?

Beidzās.

Ja neviens nekritizēs, tad nekas arī nemainīsies, ne tā? :-|

Tajā tabulā ir lekciju saraksts kādai skolai. Mainīgie query ir šūnās, kas piedāvā brīvstundās ievadīt kādu lekciju. Piedāvāt drīkst tikai tādas lekcijas: pieejamas konkrētajam kursam Pasniedzējs dotajā dienā un stundā nepasniedz citu lekciju Datubāzē ir tabulas: TeachingRelation, ar laukiem id, grade_id, teacher_id subject_id. Tā norāda kurš pasniedzējs kurai klasei māca kuru priekšmetu. Lesson, ar laukiem id, teaching_relation_id, day_id, plkst_id, cabinet_id. Norāda kurā dienā, kurā kabinetā plkst cikos notiek TeachingRelation definētais mācību process. Jeb relācijas: TeachingRelation has many lessons. Lesson belongs to TeachingRelation. kabinets, diena, plkst belongs_to Lesson. priekšmets, skolotājs belongs_to TeachingRelation. Datu daudzums: 300 TeachingRelations 600 Lessons Gala rezultātā jātiek pie datiem no tabulas TeachingRelation. Katrā šūnā pieejami 3 izejas mainīgie - kurss, diena, pulksteņa laiks. Kas, virzoties uz priekšu sarakstā, mainās. Līdz ar to mainās arī query. Mans šā brīža risinājums, kas notiek katrā šūnā: Blacklisto TeachingRelations, kuras nav pieejamas. Query ir kaut kas uz šo pusi: select teaching_relation.* from teaching_relation left join lesson on teaching_relation.id = lesson.teaching_relation_id where teaching_relation.grade_id = x where lesson.day_id = x where lesson.plkst_id = x Izvada visas TeachingRelations, kas nav blacklistotas. (Pie esošās struktūras uzreiz tikt pie whitelista liekas, ka nevar.)

Lapā ir vairākas tabula ar kopumā ~600 šūnām. Katrā šūnā ir dinamiski dati, kas ievākti no datubāzes. Query struktūra visur ir vienāda, bet parametri atšķirīgi (piem 1. šūnā where `something`=1 bet 2. šūnā where `something`=2) Kā būtu labāk? 1. Ģenerējot html katrā šūnā palaist query ar īpašajiem parametriem. => 600 query kopā. 2. Sākumā ievākt visus datus no DB. Ģenerējot html, katrā šūnā palaist php loopu, kas iet cauri sākumā ievāktajiem datiem un salīdzina vai tie atbilst parametriem. => 1 query kopā, 600 php loopi kopā. No koda lasāmības 1. variants ir daudz glītāks. Bet ko tas dara ar ātrumu?

Es gribētu izlasīt daGrevis eseju, nopietni. Un, manuprāt, no codez sanāktu labs Latvijas diktators, kas spētu šeit ieviest kārtību. :-|

Vidusskola ir reti neefektīvs veids, kā mācīties. Es tā parēķināju, ka: kopš iziešanas pa mājas durvīm līdz atnākšanai atpakaļ (mācības + ceļš) paiet 8,5h. No tām stundas notiek 4.6h. Manā novirzienā loģiskie priekšmeti - matemātika, fizika, programmēšana, ķīmija - 80min. No šīm 80min ievērojams procents ir "gaidām kamēr lēnākajiem pieleks", "gaidām kamēr skolotājai kafija uzvārīsies" u.c. blakus lietas Atnāc mājās - esi noguris. Izpildi mājasdarbus, stundu pasporto - esi vēl vairāk nogulis. Tad varētu būt laiks sākt mācīties programmēšanu u.c. jaukas lietas, bet, ak, vai - ir jau kādi 21:00. Daži teiks - mājās nekas nav jāmācās - skolas solā tev visu iemācīs (jā, vēl 12.klasē vairums skolu bīda if/else konstrukciju) Vai tas ir pareizi? Bet ko tu padarīsi.. :(

Tad kāpēc vispār Composer pekedžos ir pieejamas front-end lietas? Cik saprotu, pekedžu var uztaisīt visi, kam nav slinkums, bet nu tāpat...

Kā jūs veicat third-party koda iekļaušanu savos projektos? Izmēģināju kā tas strādā ar Composer. Pieejamo Package saraksts iespaidīgs, autoloaderis labi strādā ar php klasēm, bet aprāvos ar mēģinājumu caur Composer tikt pie JS freima. Piemēram, Composer nokačā manā vendor/ mapīte jQuery, bet kā pareizi rīkoties tālāk, lai varētu to iekļaut savos Skatos? Izlīdzējos ar html rindiņu: <script type="text/javascript" src="vendor/components/jquery/jquery.min.js"></script> Bet liekas ļoti nepareizi manuāli iet iekšā vendor mapē un meklēt failus. Bet ja to nedara, tad maģiski arī nevar sākt uzreiz lietot jQuery. Dažiem freimiem Composera package atšķīrās no tās, ko iegūst "pa tiešo" nokačājot no izstrādātāja mājas lapas, un tad pat nav skaidrs, kurš fails jāiekļauj. Kāds šajā gadījumā ir Composera "right way" lai sāktu lietot jQuery? Vai vispār iesakat lietot Composer, varbūt ir kas cits?

Ar Ajax jārealizē datu nolasīšana, dzēšana, updeitošana. Tam izveidota tabula: http://jsfiddle.net/L9Tc3/2/ Problēma: Uzbrauc ar peli uz lauka, ko vēlas updeitot Nospiež 'Update' Ieraksta jaunās vērtības Spiež 'Save' jQuery nolasa (un šajā fiddlā alert()'o ) vecos datus, nevis jaunos Kā tikt pie jaunajiem datiem? Liekas ka 'on' nedarbojas gluži tā, kā expected.