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.

Man liekas, ka NEvajadzētu būt katram savs.. Ir diezgan atšķirīgi raksturlielumi lightOnDark - mazs gaismas daudzums, relatīvi paplašinātas acs zīlītes darkOnLight - liels gaismas daudzums, relatīvi sašaurinātas acs zīlītes Un kontrasts attiecīgi kāds nu kuram liekas normāls. Principā pēc 1 gada kodēšanas uz gaiša, balta fona un pēc tam nomainot uz tumšu, starpība bija milzīga. Acīm bija daudz, daudz vieglāk. Pat pēc vairāku stundu skatīšanās monitorā acis automātiski nemēģināja nedaudz samiegties. Liekas, ka jo mazāks kontrasts, jo mazāk izstarotās gaismas (saglabājot labu salasāmību, protams), jo acij mazāka slodze. Ar atstaroto gaismu būtu citādi..

Es domāju par sava teksta editora ietekmi, kurā blenžu stundām ilgi

Nu man nesen viens cilvēks skaidroja kādēļ no aprites izgājušas melnas un brūnas tāfeles skolās, uz kurām raksta ar baltu krītu. Pēc kaut kādiem pētijumiem zaļā krāsa esot veselīgāka (man gan šķiet ka ne tik ļoti krāsai, kā kontrastam te ir nozīmē. Melns-balts un tumši zaļš-balts) nav gluži viens un tas pats)

Kur varētu atrast uzticamu informāciju par to kā atšķiras "gaiši burti uz tumša fona" no "tumši burti uz gaiša fona" colorschemu ietekme uz redzi?

Šajā topikā varētu padalīties ar veidiem kā celt darba/mācību produktivitāti, ātrumu, koncentrēšanās spējas u.t.t. Ceru uzzināt ko nedzirdētu. Runa NEiet par programmēšanas valodu, versiju kontroli, freimworku vai tml ko lietojam, bet par visādiem blakus rīkiem, kas derētu praktiski jebkuram programmētājam neatkarīgi no specialitātes. Pats šobrīd īstenoju, piemēram, : Datora vadīšana praktiski bez peles. Attiecīgi rīki kā Vim, Vimium, Awesome WM ~1.5 h dienā pavadu ceļojot vai gaidot kaut kādu transportu. Tā vietā lai skatītos laukā pa logu, telefonā iekačātas audio grāmatas un screencasti par programmēšanu Izklaides, ziņu un tml WEB lapu, kurās mēdzu pavadīt stundām nelietderīga laika, bloķēšana host failā. Kaut arī atbloķēšana ir ~10s jautājums, parasti ieraugot blokādes ziņojumu browserī pazūd vēlme tās atvērt un atgriežos pie kaut kā derīga. Vispārīga mācību plāna sastādīšana 3-4 mēnešiem uz priekšu un progresa dokumenēšana Desktopa wallpapera, windowsu dekorāciju u.c. GUI elementu praktiska izskaušana, lai nenovērš uzmanību. Manuprāt, ja kaut uz mirkli redzams desktopa wallpapers, tad mums ir ļoti nelietderīgi aizņemts ekrāna laukums. Browsera, teksta editora un failu managera autostarts ieslēdzot datoru uzreiz katram savā workspeicā.

Es par Ruby..

Nu nezinu. Vai Ruby būtu grūtāks par Pythonu? (Neesmu lietojis Django, bet Railsā viss bija pretty self-explaining..)

Tu briesmiigi gribi lai kaads Tev pajautaa, kas ir vislabaakais, vai ne?

Why not Ruby? Tāpēc, ka tu pats raksti pitonu, vai arī tam ir kādi nopietni argumenti?

Vai te ir kāds kurš lieto komandlīnijas browserus? Pa tiešo no termināļa? Nd stuff.. :D