Manas piezīmes

~$ php -r "echo (2.55 + 1.9) * 100, \"\n\";"
445
~$ php -r "echo intval((2.55 + 1.9) * 100), \"\n\";"
444

Ja tiek atsūtīts mails, kurā ir tikai atačments, bez maila body, tad, spiežot reply, templātē msg body tiek paņemts no iepriekšējā maila. "Fīča" nostrādā, ja esmu listes skatā, nevis mails ir atvērts jaunā logā.

1. Nevaru izlogoties no administrācijas daļas.
2. Labojot vecus ierakstus, izmaiņas neparādās raksta detalizētajā skatā. Piemērs.
3. <pre> tagos negribu, lai \n tiktu pārveidoti uz <br> - šeit šķiet mans roku leņķis vainīgs, vairāk jāpameklē kādi markup plugini un jādisablē nl2br. Izrādās nl2br plugina konfigurācijā var norādīt tagus, kuros neveikt nekrietnās darbības.
4. Dažkārt raksti nesaglabājas, tas šķiet saistīts ar 1. punktu.
5. Trackback sūta savu stulbo requestu uz rakstā pieminētiem linkiem arī pēc labošanas - atkārtoti.
PSEC!

Sen man lasot kādu rakstu nav bijis tā, ka mute paveras vaļā... Aplūkojot šeit ielinkotos attēlus, tieši tā notika - paliku ar vaļā muti.
Uztaisīju arī spoguli bildēm...

Nesen nosūtīju "pakārtotiem" klientiem importa XML faila aprakstu XSD formātā ar pašu XML failiņu kā piemēru. Šodien šamējie zvana un prasa sarunāt tikšanos, jo, redz, zviedri īsti nesaprot, ko ar to darīt. "Vienu failiņu viņi nevarējuši atvērt", ar to laikam jāsaprot tas, ka nezināja, kā lasīt XSD.
Jāpiebilst, ka XSD standartu apguvu uzreiz taisot šo aprakstu...

Lietoju The Bat!.
Nosūtu klientiem e-pastu, kā attach ir pievienots .sql failiņš.
Konstatēju, ka klientam rādās nevis manis rakstītais plain/text vēstules part, bet gan pievienotais .sql!
Pārsūtu vēstuli vēlreiz, The Bat! pievieno pārsūtāmo vēstuli arī kā .eml.
Outgļuks šoreiz parāda pārsūtīto tekstu, kas atrodas plain/text partā. Bet, lai aplūkotu .eml, šis plēš vaļā Outlock Express!
Neesmu redzējis sulbāku email klientu.

Pēc update uzlikšanas viņš man paprasīja angliski, vai es vēlos restartēties. Uz negatīvu atbildi paprasīja arī latviski.
Īsti gan nezinu, kas ir lielāks WTF, vai tas, ka 2x paprasa vienu un to pašu lietu dažādās valodās, vai tas, ka pēc update uzlikšanas pieprasa restartēties?

SQL> select \* from dual where 1=1 and dummy=2;
select \* from dual where 1=1 and dummy=2
                                 \*
ERROR at line 1:
ORA-01722: invalid number

SQL> select * from dual where 1=2 and dummy=2;

no rows selected
Kā redzams, tad konstrukcija abiem pieprasījumiem ir identiska, bet pirmais pieprasījums atgriež ERROR paziņojumu, kamēr otrais pilnīgi legāli izpildās.
Tā kā kļūda ir saistīta ar to, ka tiek salīdzināti dati ar dažādiem tipiem, tad atliek secināt, ka šīs ir runtime tipa kļūdas. Manā skatījumā gan tas ir mazliet nepieņemami un absurdi.

Spekulācija: pieļauju, ka optimaizeris uzmeklē konstanšu clauses un, ja kāda atgriež false, tad pārējās šī līmeņa clauses ignorē. Protams, pārbaudīta tiek visu nosaukumu eksistence, bet netiek pārbaudīta datu tipu atbilstība. Tā tiek pārbaudīta tikai tad, ja visas konstantās (un līdz ar to arī izmetamās) clauses ir atgriezušas false.

Papildinājums: izskatās, ka ORACLE automātiski casto varchar2 uz number, kā rezultātā

> select \* from dual where 1=1 and to_number(dummy)=2;

un

> select \* from dual where 1=1 and dummy=2;

ir ekvivalenti. Pie šādiem nosacījumiem viss ir ok.