Първо малко за конкуренцията, защото в момента темата ми е много на сърцето. Напоследък се запознавам с все повече хора, които са ми пряка конкуренция и с които чупим от една пита. Повечето от тях ги познавам или само виртуално или пък съм се запознал с тях благодарение на някой блог, форум и прочее. Какво забелязвам – въпреки, че сме конкуренти всички са много любезни, мили и отзивчиви. Което е супер! Честно казано, ако всичко беше съвсем истинско щеше много да се радвам. Обаче не е. В интерес на истината, аз не възприемам конкуренцията като нещо лошо. Напротив – това са хората, които ни карат да работим по-здрави, да ставаме по-рано и да правим по-добри проекти на по-изгодни цени за по-малко време. Конкуренцията е нещо хубаво! Не мога да разбера обаче, защо някой хора не могат да го проумеят и до ден днешен.

Така… това го пиша, защото в последните две седмици ме попитаха 3 пъти за това нещо и явно, че хората не го знаят или по-скоро не правят разлика между двете функции. Разлика има и то съществена. Това, което прави двете функции толкова различни, че require() генерира fatal error, а include() ще генерира warning. С други думи при първото положение страницата няма да се отвори, а при второто ще се изпише само грешка на съответното място и останалата част от страницата ще се покаже. Практиката е следната, всички файлове, коит са от съществено значение за страницата, например бази данни, логини, пароли и всичко, без което сайтът ви не може да съществува и функционира правилно, то тогава се използва require(). При всички останали положение include(). Да речем че имате скрипт, който ви показва последните tweetове, за него ще е добра практика да го include-нете, защото и без него сайтът ви ще е ОК. Но ако имате db.inc.php съдържащ функции за връзка с базата данни, най-добре би било да го require()-нете. Просто е, макар и реално начинаещите да не виждат голям смисъл в тази разлика, но с практиката ще се убедите, че и двете функции са полезни и най-вече на места изключително нужни.

За да си уеб програмист не се изисква просто да изядеш 2-3 книжки за PHP, MySQL, XHTML, CSS, JavaScript, Ajax и да вземеш 2-3 сертификата по гореспоменатите дисциплини. Не… Това изобщо не е достатъчно. Знаете ли, професията ни всъщност е колкото интересна, толкова и трудна и напрегната. Сега ще кажете „Еми че кво му има, пишете там някви си неща и готово!„, еми да ама не. Истинският уеб програмист е минал през ада за да достигне до едно хубаво средно ниво на познания, опит и уважение от колеги и познати.

PHP Frameworks или как може да не харесваш нещо толкова полезно?

От доста време се каня да го направя и най-накрая се наканих. Първоначално искам да кажа, че за мен PHP frameworks не са от най-добрите решения за мен и моите проекти. Просто съм такъв тип програмист, не ги обичам, а и те не ме обичат. През цялото време в което създавах уеб приложения съм творил с моя личен фреймуорк, който е нещо подобно на The no-framework PHP MVC framework, за който ако не сте чували ви съветвам да прочетете и да се запознаете с идеята му. Като се има на предвид, че 90% от уеб приложенията, които ни се налага да правим са доста подобни, фреймуоркът ми вършише перфектна работа.

PEAR (PHP Extension and Application Repository) е система за PHP за управление на пакети. Както добре знаете PHP потребителите нараснаха главоломно в последните няколко години и именно поради тази причина започна да се предлага много код във формата на сорс кодове, на готови класове, различни библиотеки и прочее. Но това в крайна сметка е колкото полезно, толкова и неудобно, главно поради причината, че е доста трудно да следите за нови версии на използваните от вас пакети. Представете си, че използвате над 200 пакета и класа – тогава ще ви се налага всеки ден да проверявате 200 сайта дали случайно не се е пръкнало нова версия. Много програмисти се абстрахираха от тази ситуация и започнаха сами да поддържат собствени библиотеки, но това е крайно не оптимизирано от гледна точка на това, че им се налага да откриват топлата вода, при положение, че тя вече е открита. Все пак и този вариант си има своите предимства, но няма смисъл да разказвам за това сега.