Failas ir vėl guli čia, o sourcą galite peržiūrėti čia. Sekantis TODO: kažkaip sugalvoti integruoti darbo šeštadienius. Greičiausiai algoritmo jokio sukurt nepavyks, nebent kasmet “pasiupdate`int”, kai Vyriausybė paskelbia šventinius perkėlimus. Pvz. šiemet berods iš sausio 2′osios buvo perkėlimas į vasario 21ą. O gal yra koks servisas šventinėms dienoms bei darbo šeštadieniams pasiimt? Kolkas ir neieškojau kur tos datos skelbiamos, gal žinote kur?

Besižaidžiant su naujaisiais mokesčiais, išlindo ir senokai primiršta PVM vieno cento problema. Problema atsiranda dėl skaičių apvalinimo ir PVM skaičiavimo iš vienos arba kitos pusės. Dažna buhalterinė programa viską skaičiuoja pati, tačiau kiekviena tai daro skirtingai, nes apibrėžto būdo kaip ir nėra. Pvz. vienas variantas: pajamuojant prekes, įvedamos kainos be PVM ir po to suma padauginama, taip gaunamas bendras PVM visai sąskaitai. Antras variantas: skaičiuojamas kiekvienos prekės PVM atskirai (berods buhalterijoje reikia ir tokių duomenų), tuomet juos susumuoja. Visiškai aišku, kad PVM suma gali skirtis netgi ne vienu centu, jei bus įvedama daug prekių, kurių PVM apvalinimo metu bus gerokai iškraipytas.

Mūsų sistemoje sąskaitos formavimas vyksta dar kitaip - prekių kainos be PVM skaičiuojamos atvirkščiai. Tai yra turime kainas su PVM ir iš jų gauname PVM. Tokiu atveju PVM suma nebesutampa pačioje sąskaitoje, sulyginus ją su bendra sąskaitos suma.

Sukau galvą kaip tai išspręsti, kadangi mūsų buhalterija sugaišta nemažai laiko tokių sąskaitų-faktūrų tikrinimui. Sprendimas yra gan “juodas hack”

// hackas vat vieno cento problemai
$vat_sum = 0;
foreach ($vats as $key=>$vat)
{
$vat_sum += round($sum['vat_'.$key], 2);
}

foreach ($vats as $key=>$vat)
{
if ($sum['vat_'.$key]>0)
{

$sk = round((round($vat_sum, 2)+round($order['total_price_without_vat'], 2) - $order['total_price']), 2);

if ($sk!=0)
{
$sum['vat_'.$key] -= $sk;
$vat_sum -= $sk;
break;
}
}
}
// eo hackas

Tiesą sakant, geresnio būdo ir nelabai įsivaizduoju, kaip iš PVM išmesti nereikalingą skirtumą. Rezultatas štai toks.

Yra:

Suma be PVM      12.76 Lt
PVM 9%     0.79 Lt
PVM 19%     0.75 Lt
Viso     14.30 Lt

Buvo:

Suma be PVM      12.76 Lt
PVM 9%     0.80 Lt
PVM 19%     0.75 Lt
Viso     14.30 Lt

Be kita ko, mūsų sąskaitos keliauja dar ir į buhalterinę programą MS “Navision”. Vėlgi, sąskaitų PVM ir bendros sumos turi sutapti. Atrodo ir čia sugalvotas paprastas sprendimas - tiesiog importuodami sąskaitą paduodame ir PVM bei bendrą sąskaitos sumas, Navisionas jas tiesiog kietai “overridina” ir nesutapimų turėtų nebebūti.

Jei kas nors turite kokių minčių ar esat sugalvoję/radę geresnių sprendimų, maloniai prašau pakomentuoti.

Kolkas tiek, produktyvių 2009′ųjų!

Sykį prisireikė man tokio dalyko, matuoti kiek darbo valandų praeina nuo užsakymo statusų pasikeitimų. Tai yra, kaip galbūt daug kur esate matę: “Į jūsų klausimą bus atsakyta per dvi darbo valandas” ir panašiai. Kadangi tokią funkcijėlę rašiau dvi dienas (su įvairiais nukrypimais prie kitų darbų), manau reikia pasidalinti ir su kitais šituo “gėriu”.

Helperio sourcas čia. Pats scripto failas čia. Ištestavau su daugybe variantų, tad manau, kad klaidų neturėtų būti, bet jei netingite knaisiotis, visada lauksiu komentarų

Trumpi pavyzdukai:

echo work_time(’2008-12-18 18:55′, ‘2008-12-19 08:40′);
// returns 40min.

echo work_time(’2008-12-18 14:23′, ‘2008-12-19 07:33′);
// returns 3h. 37min.

echo work_time(’2008-12-18 18:55′, ‘2008-12-22 13:40:15′);
// 15h. 40min. 15s.

echo work_time_difference(’2008-12-19 14:30′, ‘2008-12-19 15:15:01′);
// returns 2701

Jei dar kas nežino, šios atakos nebuvo tokios jau grandiozinės, viso labo buvo nulaužtas vienas ar du serveriai, kuriuose ir gulėjo visi tarybine simbolika išmarginti puslapiai. Mes manome, kad Hostex dirba profesionalai ir išmanantys savo darbą žmonės, tad nereikia šių atakų dramatizuoti. Praėjusiais metais vykusios DDoS atakos Estijoje buvo rimtesnės ir vertos svarstyti tarptautiniu lygiu. Šaunuoliai estai, įkūrę apsaugos nuo kibernetinių atakų centrą, iš kaimynų mums tikrai yra ko pasimokyti, galbūt kartais ir gudrių metodų, kaip tobulinti savo IT ir gauti pinigų

pigu.lt siekia prisidėti prie Lietuvos IT lygio kėlimo ir saugumo stiprinimo ir siūlo bendradarbiauti visiems specialistams ar šiaip suinteresuotiems šia tema. Norime pasiūlyti piniginį atlygį tam ar tiems, kurie atras spragų pigu.lt puslapyje. Jei bus atrasta kritinių saugumo spragų, svarbiausiųjų atradėjus apdovanosime 1024 piguLitais, kuriuos jis/ji/jie galės išleisti pigu.lt prekybos centre.

Jokiu būdu nemanome, jog mes viską darom be klaidų. Nuo bug`ų niekas nėra apsaugotas, kadangi klysti žmogiška

Norintys dalyvauti konkurse ir ketinantys palaužyti mūsų svetainę, prieš tai brūkštelkit el. paštu justinas(eta)pigu.lt arba skype medutiz. Susipažinsim, pabendrausim aktualiom temom, palaužysim mūsų ir Jūsų puslapius (mes nemokamai, o Jūs už prizus).

Šio įrašo originalas yra čia

Slaptas katalogiukas yra tokio pat adreso, kaip ir kitas lietuviams prieinamas žurnalas, tik subkatalogas vadinasi phpmag. Na, URL’as susideda iš šio serverio adreso ir subkatalogo. Jei kam nors kas neaišku, klauskite bet kuriuo kontaktavimo būdu, kokiu tik galite mane rasti. Už šitą gėrį turime būti dėkingi vyrukui, kurio nickas yra drawgas.

Apribokime sistemos resursus

max_execution_time, standartiškai yra nustatytas 30 (sekundžių). Tai reiškia, kad skriptui bus leista naudotis procesoriumi iki 30 sekundžių vieno paleidimo metu. Šis nustatymas yra naudingas hostingo paslaugų teikėjams, kadangi apsaugo nuo piktai nusiteikusių vartotojų, norinčių pakenkti, taip pat ir dedicated serveriams - apsisaugoti nuo kreivai parašytų savų ar trečios šalies skriptų. Dažnai šis nustatymas yra interpretuojamas klaidingai - “skriptas negali suktis ilgiau nei 30 sekundžių“. Iš tiesų, gali. Laikas skaičiuojamas tik tada, kai skriptas naudoja CPU, nors veikti skriptas gali valandų valandas. Pavyzdžiui:

while (true)
{
sleep(100);
}

Toks skriptas naudoja itin mažai CPU, todėl miegodamas gali veikti net ir ištisą mėnesį. Jeigu serveryje naudojate tik web puslapius, protinga apriboti šį nustatymą į kur kas mažesnę reikšmę, pvz. 5. Jei puslapis serveryje generuojamas ilgiau nei 1 sekundę, tai jau laikoma ilgai. Kuo mažesniu laiku jį apribosim, tuo daugiau laiko liks kitoms užduotims. Šį nustatymą galima keisti ir skripto išorėje, ir viduje, su set_time_limit() funkcija.

max_input_time yra skirtas nustatyti, kiek laiko skirti vartotojo įvedimui. Jis defaultu būna 60 sekundžių. Taip pat, kaip ir vykdymo nustatymas, jis įskaičiuoja tik tą laiką, kurį naudoja CPU savo skaičiavimams. Didelio failo uploado laukimas nepaveiks šio limito. Šis nustatymas skirtas apsisaugoti nuo daugiamačių masyvų perdavimo, kurie gali itin paveikti sistemos resursus. Nepaisant to, 60 sekundžių yra ryškiai per daug, joks skriptas neturėtų švaistyti tiek daug savo laiko vartotojo įvedimui apdirbti. Nustatymą siūloma apriboti iki 2-5 sek. Šis nustatymas gali būti keičiamas tik skripto išorėje, kadangi vartotojo įvedimas apdirbamas dar prieš skripto pradžią.

memory_limit - dar vienas nustatymas, apribojantis sistemos skiriamą atmintį. Šis nustatymas yra prieinamas tik tuo atveju, jei php sukompiliuotas su atminties ribojimo palaikymu. Lengvai tai patikrinsite, kadangi memory_get_usage funkcija prieinama tik jei atminties ribojimas yra :

if (function_exists(’memory_get_usage’)) echo ‘Ok!’;
else ‘Ne Ok!’

Atminties limitas yra defaultu nustatytas iki 8MB. Šis nustatymas dauguma atvejų yra tinkamas ir paprastai nereikia jo keisti. Sistemai pakenkti gali būti naudojami skriptai, pasiimantys didelę dalį atminties ir nueinantys miegoti. Pavyzdžiui:

$a = str_repeat(’a', 100000000);
ignore_user_abort(true);
sleep(1000000);

Šis skriptas bando nugriebti ~100MB atminties ir nueiti miegoti, ignoruodamas vartotojo veiksmus, ty. net jei uždaroma naršyklė, jis ir toliau būna vykdomas. memory_limit neišsprendžia problemos iki galo, kadangi su tokiu skriptu galima paleisti kelias jo instancijas, kurių kiekviena pasiims maksimalų atminties kiekį. Be abejo, tokie įvykiai negali praeiti nepastebėti sistemos administratorių, taigi problemą anksčiau ar vėliau reikia išspręsti. Kitiems atvejams, kai kenkia ne žmogus, o kreivai parašytas skriptas, arba pvz. siunčiamas didelis duomenų kiekis iš išorinio šaltinio, tai be abejo yra naudingas nustatymas.

default_socket_timeout - leidžia apriboti laiką, skirtą inicijuoti sujungimui. Defaultu ši reikšmė yra 60 sekundžių. Dažnai sistema, atidarydama socketą praleidžia daug laiko prisijungdama prie lėtų serverių, todėl kenkėjas gali efektyviai išnaudoti sistemos resursus, atidaręs keletą tokių prisijungimų. Kol sistema eikvos laiką beprasmiams sujungimams, neliks resursų tikrų vartotojų užklausoms. Reikia atminti, kad šis nustatymas galioja tik prisijungimo inicializavimo procesui ir neturi efekto skaitymui ir rašymui jau atidarytame sockete, taigi verta naudoti ir stream_set_timeout() jei reikia apsisaugoti nuo gaišimo laukiant skaitymo ar rašymo veiksmų. default_socket_timeout gali būti pakeistas bet kurioje vietoje, protinga jį būtų sumažinti iki 5-10 sekundžių.

URL includinimas

Viena iš php streams galimybių yra elgtis su išoriniais URL lygiai taip pat, kaip ir su vietiniais failais. Pavyzdžiui, fopen() gali būti taip pat sėkmingai panaudota nuskaityti “http://www.php.net”, kaip ir “/etc/passwd”. Tai sukelia nemažai saugumo spragų, kaip pvz. kodo injekcija per išorinį šaltinį, naudojant tokias funkcijas, kaip fopen(), file_get_contents(), readfile(), taip pat didelių duomenų arba lėtai veikiančių URL įkėlimas. Taipogi, gali būti sukuriamas amžinas ciklas, skriptui nuskaitant patį save. Kartais net web serverio perkrovimas neišgelbsti, kadangi keletas užklausų lieka buferyje ir jie vėl toliau sėkmingai ryja sistemos resursus. Serveris turi būti sustabdomas keletui sekundžių ir tada paleidžiamas iš naujo.
Į pagalbą ateina allow_url_fopen nustatymas, kurį nustačius į false, skriptas galės pasiekti išorinius šaltinius tik su curl arba socketais. Blogiausia, kad streamai suteikia priėjimą prie išorinių šaltinių ir tokioms funkcijoms, kaip require ar include. Jei tokių funkcijų parametruose pasitaiko vartotojo įvedamų duomenų, kenkėjas gali nesunkiai paleisti savo rašytus skriptus. Tai dar viena rimta priežastis išjungti defaultu įjungtą allow_url_fopen. Nepaisant visko, su fopen() atidarinėti išorinius URL yra pakankamai saugu (arba/ir reikalinga), ir dabartinėje versijoje (5.2) jau galima pasinaudoti nauju nustatymu allow_url_include, kuris išjungtas defaultu. Jis atskiria URL apdirbimo funkcionalumą, kadangi leidžia kontroliuoti ar leisti tik nuskaitymus, ar ir include/require. Abu šie nustatymai gali būti keičiami tik skripto išorėje, dėl saugumo sumetimų.

Funkcijų ir klasių draudimas

Jei galvojate, kad php turi daug nustatymų, pasidomėkite, kiek yra funkcijų Be abejo, visos funkcijos yra naudingos vienais ar kitais atvejais, tačiau kai kuriomis iš jų paslaugų teikėjai nenori leisti naudotis vartotojams. Tokios funkcijos, kaip exec() leidžia apeiti safe_mode ir open_basedir nustatymus, arba mail() - gali būti panaudota išsiųsti dideliems kiekiams spamo. Tam yra skirti nustatymai disable_functions ir disable_classes, kurioms galima pateikti kableliais atskirtą sąrašą draudžiamų funkcijų ar klasių. Skriptui, bandant naudoti uždraustą funkciją ar klasę bus grąžintas fatal error. Šis nustatymas, nors ir labai naudingas, deja, turi vieną apribojimą. Jis gali būti keičiamas tik php.ini faile, o tai reiškia, kad negalima vieniems vartotojams leisti, o kitiems apriboti tam tikrų funkcijų. Visiems bus vienodi draudimai. Po šio nustatymo keitimo taip pat būtina perkrauti web serverį.

Modulių dinaminis įkrovimas

enable_dl - leidžia pasirinkti ar leisti skriptui įkrauti modulį dinamiškai. Defaultu šis nustatymas įjungtas, todėl suteikia gan patogų dalyką - skripto metu galima įkrauti extensioną, tačiau tai yra didelė saugumo spraga. Nėra būdo žinoti, ką daro įkraunamas modulis, jis gali suteikti priėjimą vartotojui prie to, kas šiaip yra uždrausta ar atlikti bet kokias sistemos operacijas. Net ir be vartotojo piktų kėslų, modulis gali būti parašytas prastai, nekokybiškai, o tai taipogi gali paveikti visą sistemą. Rekomenduojama šį nustatymą išjungti php.ini arba virtual hosto lygmenyje.

Pabaiga

Sėkmės, būkite saugūs! Greitai pasirodys dar viena viso šio romano dalis

PHP standartinėje versijoje yra virš 500 INI nustatymų direktyvų. Šis skaičius gali išaugti, jei įdiegsite PECL ar kokių kitų išorinių modulių. Didžioji dalis nustatymų yra palikti veikti standartiškai (default), gali būti, kad jų judinti niekad ir neprireiks. Nenuostabu, kad turbūt nė vienas žmogus šių visų nustatymų negalėtų mintinai mokėti, tačiau yra keletas svarbesnių, susijusių su saugumu, į kuriuos verta atkreipti dėmesį. Pilnas INI nustatymų aprašymas yra čia.

PHP INI nustatymai taipogi turi keletą “nustatomumo lygių”. Kai kurie nustatymai, pavyzdžiui, yra tik “system” tipo, tai reiškia, kad jį galima pakeisti tik php.ini faile, taigi priėjimas prie jo yra draudžiamas ir skriptams, ir web serverio per-virtualaus hosto nustatymus, ir .htaccess failui. INI sąraše tokie nustatymai žymimi “PHP_INI_SYSTEM”.

Kai kurie nustatymai turi “PHP_INI_PERDIR” lygį. Tokiu atveju nustatymas gali būti keičiamas php.ini faile arba web serverio virtualaus hosto nustatymuose, arba jo .htaccess faile. Dažniausiai tokie nustatymai įtakoja pavyzdžiui, vartotojo įvedamus duomenis, o jie yra apdirbami dar prieš startuojant php skriptą, taigi skripto viduje, kad ir pirmoje eilutėje kreipimasis pakeisti nustatymą, neduotų jokio naudingo rezultato.

Didžioji nustatymų dalis patenka į “PHP_INI_ALL”, tai reiškia, kad nustatymas gali būti keičiamas bet kur, t.y. be jau minėtų būdų, dar papildomai ir pačiame skripte per ini_set() funkciją.

Register globals
Neverta apie juos daug aušinti burnos. Tiesiog reikia išjungti ir tiek Nuo 4.1 versijos išjungti default, tačiau dėl senų skriptų palaikomumo būna daug kur įjungti (ypač shared-hostinge). Šis nustatymas paliečia vartotojų įvedamus duomenis dar prieš vykdant skriptą, todėl jį apdirbti racionaliausia php.ini faile (register_globals=0), virtual host nustatymuose (php_admin_flag register_globals 0) arba .htaccess faile (php_flag register_globals 0). Patikrinti galime per phpinfo() funkciją arba ini_get(”register_globals”).

Magic Quotes
Panašiai gan nemenką žalą darantis nustatymas, kaip ir register globals. “magic_quotes_gpc” nustatymą verta išjungti ne tik dėl saugumo, bet ir dėl tam, kad skriptai būtų vykdomi greičiau - automatinis visų duomenų eskeipinimas taip pat atima resursų, be to, galbūt visai nebūtinas, juk ne visi įvedami duomenys yra naudojami SQL užklausose, be to, magic_quotes veikia ne itin korektiškai, ir vistiek gali palikti spragų saugume. Tai įvedimo apdirbimo nustatymas, taigi jis taip pat yra “PHP_INI_PERDIR” tipo. Dar vienas nustatymas “magic_quotes_runtime” yra panašus, tačiau priešingai nei “magic_quotes_gpc”, yra išjungtas defaultu. Bet kokiu atveju, verta patikrinti, jog abu jie būtų išjungti.

open_basedir
Labai naudingas dalykas shared-hostinge, tam, kad kiti vartotojai, vykdydami skriptus per web serverį, negalėtų landžioti po jūsų failus. Nustatymas keičiamas tik per php.ini failą arba apache virtual hostams. Kadangi atskiriems vartotojams reikia prieiti prie tam tikrų bendrų katalogų ir savo namų katalogo, tai nustatymo keitimas php.ini faile yra beprasmis, reikia diferencijuoti šį parametrą pagal vartotojus. Pvz. php_admin_value open_basedir “/tmp/:/home/user1/”. Reikia atminti, kad būtina katalogą iš abiejų pusių atskirti slashais, nes užrašymas “/home/user1″ leis priėjimą ir prie /home/user1, ir prie /home/user123 ir kitiems katalogams, kurių pradžia būtent tokia, o tai jau yra rimta saugumo spraga.

Safe Mode
Šio nustatymo idėja buvo labai kilni, tačiau pavadinimas gali būti apgaulingas. Safe mode režimas apriboja daug nustatymų susijusių su saugumu, tačiau visus juos galima reguliuoti atskirai ir daug lanksčiau (apie juos kitoje dalyje). Vienas iš svarbiausių dalykų, kad safe mode režime, kai skriptas kreipiasi į failą, tikrinamas skripto savininkas ir failo savininkas. Jei jie sutampa, tuomet operacija leidžiama. Tačiau tokiu būdu galima lengvai prarasti priėjimą prie failų, kurie sukuriami pačių skriptų. Be to, šį apribojimą galima lengvai apeiti su daugeliu funkcijų, pvz. copy(). Nors safe_mode įjungimas ir nekenkia tiesiogiai, tačiau jis sukūria papildomo apkrovimo serveriui, tikrinant failo UID, todėl rekomenduojama išjungti ir protingai suderinti kitus saugumo nustatymus, taip pat atskiriant vartotojus į virtualius hostus bei naudojant gudrias priėjimo teises (chmod).

Expose PHP
expose_php nustatymas įjungtas standartiškai, tačiau nauda iš jo menka, o žala didelė. Įjungimas reiškia, kad kiekvienos užklausos metu siunčiama informacija apie PHP versiją, naudojama serveryje. O tai be abejo naudinga hackeriams, ieškantiems pažeidžiamų senesnių versijų, be to tai yra ir papildomi nereikalingi duomenys, naudojantys saito pralaidumą. Nebūtina visam pasauliui žinoti kokia kalba parašytas tinklapis. Statistikos rinkimui užtenka panaudoti kad ir header(”X-Powered-By: PHP”); kuris nerodo PHP versijos. expose_php nustatymas reguliuojamas tik php.ini faile.

Display Errors
display_errors būna įjungtas default, o tai reiškia, kad visos klaidos bus išvedamos tiesiai į browserį. Be abejo, tokia informacija naudinga norintiems pakenkti. Geriausias variantas yra uždrausti lankytojams matyti klaidas, tačiau leisti programuotojui prie jų prieiti. Klaidų nustatymai gali būti keičiami visuose lygiuose (pačiame PHP skripte - taip pat):

error_reporting(E_ALL | E_STRICT);
ini_set(’display_errors’, 0);
ini_set(’log_errors’, 1);
ini_set(’error_log’, ‘/var/home/user/logs/php.log’);

Pabaiga
Pirmos dalies pabaiga

1. CRUD (Create Read Update Delete), CRUD saugumas, Kaip kiekvieną modelį galima supaprastinti iki CRUD (siūlytojas, berods, araki)
2. Struktūrinai šablonai, praktinis jų panaudojimas (Design patterns) (araki)
3. Kodėl Yahoo ant PHP? PHP in enterprise (Lakūnas?)
4. Ruby on Rails, kaip viską padaryti per 15min? (Yozaz?)
5. Paymentai (apmokėjimai) naudojant PHP (teibaz?)
6. Zend Core for WINDOWS (saint)
7. Migracijos gidas iš PHP į ASP.NET ir atvirkščiai (palete?)
8. PHP brandingas (įvaizdis) (araki?)
9. Naujasis Filter extensionas, duomenų filtravimas ir eskeipinimas (medutis)
10. PHP ateitis, PHP6, namespaces, unikodas, etc. (medutis)
11. Django, SOA! (midgrad)
12. Apkrovimo mažinimas ir dalinimas, scaling, mySQL5 navarotai (index merge, innodb), mod_proxy_balancer, (midgrad)

Neišsigąskite, skliausteliuose nurodyti siūlytojai (nebūtinai skaitovai), entuziastų skaitovų, beje, neatsirado, tačiau galvoju, kad tai nebus didelė bėda O dabar laukiu kokių nors komentarų, pasisakymų, galbūt konkrečių idėjų ir pasiūlymų, skaitovai taip pat welcome. Palete jau lyg ir beveik pasižadėjo, jog suorganizuos vietą (viešbučio konferencijų salė arba koks nors univeras).

Beje, jau yra naujasis php|arch gruodžio numeris, ten pat, kur ir visad. Ramių švenčių ir gerų dovanų!

Reikalingas web (PHP/MySQL) programuotojas.
Darbo pobūdis: freelanceriniai projektai.
Techninio dizainerio gabumai būtų privalumas.
Paskutinio darbo URL arba CV siųsk į mikauzeris@gmail.com

Pervertęs šį numerį pagalvojau apie mūsų PHP bendruomenės (ir Lietuvoje, ir pasaulyje) tolerantiškumą. Padariau išvadą, kad PHP’istai yra labai tolerantiški Nustebino tai, jog žurnale yra ir straipsnis pavadinimu “learning from Ruby on Rails”, labai smagu, jog programuotojai sugeba žvelgti plačiau ir mokytis ne tik virdami “savo sultyse”, bet ir pažvelgdami į kitas (galbūt net šiek tiek konkurentines) kalbas. Kitas pavyzdys: pernai įvykusioje PHP konferencijoje taipogi turėjo būti pranešimas apie “migravimą iš PHP į ASP.NET”, deja autorius negalėjo (ar pabijojo) atvykti. Nors buvo pasisakymų, jog toks pranešimas tik padarytų gėdą konferencijai, buvo ir manančių, jog paklausyti apie tai būtų gan įdomu, pasimokyti kažko iš skirtingos technologijos. Niekas nebūtų priešinęsis tam, kad jis būtų įvykęs, o galbūt ir pavadinimas visai neatspindi galimos naudos. Galbūt dar ir šiemet įvyksianti (tokie planai prie alaus bokalų buvo rezgami :)) konferencija taip pat be pranešimų apie kitas kalbas ar “migravimus” gali neapsieiti. Keletas PHP programuotojų savo bloguose taip pat nevengia brūkštelti apie ruby on rails, juose yra ir pagyrimų, ir kritikos (objektyvios!).

Kartais tenka išgirsti java ar .net programuotojų pašiepiančių, ar net įžeidžiančių pasisakymų apie php. Galbūt tolerancija ir PHP kūrėjų plačios pažiūros leidžia šiai kalbai išsilaikyti viena iš lyderių?