Web lietas

One encoding to rule them all! Tas LOTR iespaidā. Bet ja pie lietas, tad šeit ir lasāms rakstiņš par Unicode un PHP6.

Emocijas dažādas. 1) Yeee – PHP6 nāk un tajā būs Unicode un lokalizāciju atbalsts. Diez LV būs apdalīto vidū vai arī nē. 2) Yeee – PHP6 būs jau šī gada beigās. 3) Hmmm – ja jau tagad daudzi hostinga nodrošinātāji nepiedāvā PHP5 (pēdējā pusgada laikā gan lieta ir mainījusies uz pozitīvo pusi), tad pēc cik lga laika hostinga nodrošinātāji sāks uzticēties PHP6? 4) Bāc – cik daudz atkal būs jāmācās…

One encoding to rule them all! Tas LOTR iespaidā. Bet ja pie lietas, tad šeit ir lasāms rakstiņš par Unicode un PHP6. Emocijas dažādas. 1) Yeee - PHP6 nāk un tajā būs Unicode un lokalizāciju atbalsts. Diez LV būs apdalīto vidū vai arī nē. 2) Yeee - PHP6 būs jau šī gada beigās. 3) Hmmm - ja jau tagad daudzi hostinga nodrošinātāji nepiedāvā PHP5 (pēdējā pusgada laikā gan lieta ir mainījusies uz pozitīvo pusi), tad pēc cik lga laika hostinga nodrošinātāji sāks uzticēties PHP6? 4) Bāc - cik daudz atkal būs jāmācās...

Pāris mēnešus atpakaļ rakstīju, ka viens no PHP Security Response Team dalībniekiem ir pametis konkrēto projektu. Šī intervija ir kā detalizētāks izklāsts tam, kādēļ viņš tā ir darījis. Kā tajā izklāstīti interesanti fakti par PHP drošību (ne tikai skritpu, bet paša PHP uzbūves drošību).

Intervijā ir pieminēts arī tāds projekts kā Suhosin. Jāsaka, ka šis projekts ir ļoti ieinteresējošs un izskatās, ka varētu būt arī noderīgs.

Ak, jā – intervija šeit: http://www.securityfocus.com/columnists/432/1

Pāris mēnešus atpakaļ rakstīju, ka viens no PHP Security Response Team dalībniekiem ir pametis konkrēto projektu. Šī intervija ir kā detalizētāks izklāsts tam, kādēļ viņš tā ir darījis. Kā tajā izklāstīti interesanti fakti par PHP drošību (ne tikai skritpu, bet paša PHP uzbūves drošību). Intervijā ir pieminēts arī tāds projekts kā Suhosin. Jāsaka, ka šis projekts ir ļoti ieinteresējošs un izskatās, ka varētu būt arī noderīgs. Ak, jā - intervija šeit: http://www.securityfocus.com/columnists/432/1

Izvēle par labu vienam vai otram bieži vien ir gluži kā reliģiska nostāja. Vieni uzskata, ka Postgre ir pārāk “smags” un tādēļ lieto MySQL. Citi uzsakta, ka MySQL ir ļoti nestabils un pie daudzām konekcijām mirst nost, tādēļ lieto Postgre. Lūk šeit ir interesants PostgreSQL un MySQL salīdzinājums. Ir vērts izlasīt arī tad, ja nedomājat mainīt savu pārliecību. Tā teikt – informācijas nekad nevar būt pa daudz.

Having foreign keys, views, subselects, and transactions can all be very attractive in PostgreSql -
if you need them and you will make any use of them. If you don't need them or won't use them, then
you're probably better off with MySQL and its superior performance.

Izvēle par labu vienam vai otram bieži vien ir gluži kā reliģiska nostāja. Vieni uzskata, ka Postgre ir pārāk "smags" un tādēļ lieto MySQL. Citi uzsakta, ka MySQL ir ļoti nestabils un pie daudzām konekcijām mirst nost, tādēļ lieto Postgre. Lūk šeit ir interesants PostgreSQL un MySQL salīdzinājums. Ir vērts izlasīt arī tad, ja nedomājat mainīt savu pārliecību. Tā teikt - informācijas nekad nevar būt pa daudz. Having foreign keys, views, subselects, and transactions can all be very attractive in PostgreSql - if you need them and you will make any use of them. If you don't need them or won't use them, then you're probably better off with MySQL and its superior performance.

Bez maz vai iesācēja cienīga kļūda radās, rakstot kārtējo PHP skriptu. Taču neskatoties uz to, ka tā ir visai primitīva cēloņa kļūda, padalīšos ar to, kāda tieši, jo varbūt kādam pagadās tieši šāda kļūda un jātērē laiku, lai saprastu, kas tad īsti noticis.

Situācija bija šāda – ir datums formātā yyyy-mm-dd, piemēram, 1990-07-22. Lai to pārvērstu LV raksturīgā variantā parasti izmantoju date('d-m-Y', strtotime($datums)). Taču, šoreiz bija gadījumi, kad attiecīgā lieta nostrādaja kā parasti un brīžiem nenostrādāja. Kad sāku pētīt uz kuriem datumiem īsti nenostrādā, sapratu, ka tie ir datumi, kas vecāki par 1970-01-01. Lūk! It kā elementāra lieta, bet rakstot skriptu pat neiedomājos, ka būs šādi datumi. Līdz ar to nācās izdomāt kādu apkārtceļu šai lietai. Tā, kā citas standarta funkcijas neatradu, kas to varētu paveikt, tad uzrakstīju mazu funkciju, kura sakārto datumu konkrētajā formātā. Nav jau ideāli, bet vismaz strāda. Ja kādam ir labāki risinājumi šai problēmai – padalieties. Funkcija bija šāda:
function ConvertedDate($date)
{
if ($date)
{
$dz = explode('-', $date);
return $dz[2].'-'.$dz[1].'-'.$dz[0];
}
}

Tātad secinājums – ja maināt datuma formātu, atcerieties par strtotime() ierobežojumiem!

Bez maz vai iesācēja cienīga kļūda radās, rakstot kārtējo PHP skriptu. Taču neskatoties uz to, ka tā ir visai primitīva cēloņa kļūda, padalīšos ar to, kāda tieši, jo varbūt kādam pagadās tieši šāda kļūda un jātērē laiku, lai saprastu, kas tad īsti noticis. Situācija bija šāda - ir datums formātā yyyy-mm-dd, piemēram, 1990-07-22. Lai to pārvērstu LV raksturīgā variantā parasti izmantoju date('d-m-Y', strtotime($datums)). Taču, šoreiz bija gadījumi, kad attiecīgā lieta nostrādaja kā parasti un brīžiem nenostrādāja. Kad sāku pētīt uz kuriem datumiem īsti nenostrādā, sapratu, ka tie ir datumi, kas vecāki par 1970-01-01. Lūk! It kā elementāra lieta, bet rakstot skriptu pat neiedomājos, ka būs šādi datumi. Līdz ar to nācās izdomāt kādu apkārtceļu šai lietai. Tā, kā citas standarta funkcijas neatradu, kas to varētu paveikt, tad uzrakstīju mazu funkciju, kura sakārto datumu konkrētajā formātā. Nav jau ideāli, bet vismaz strāda. Ja kādam ir labāki risinājumi šai problēmai - padalieties. Funkcija bija šāda: function ConvertedDate($date) { if ($date) { $dz = explode('-', $date); return $dz[2].'-'.$dz[1].'-'.$dz[0]; } } Tātad secinājums - ja maināt datuma formātu, atcerieties par strtotime() ierobežojumiem!