Не отдавна съм се посветил на публични frameworks за php. Какво да ви кажа, доволен съм – спестяват много писане, кодът ми може да се редактира от всеки запознат с framework-а, като няма нужда да изучава чак толкова много в детайли архитектурата му. Има си страшно много предимства, но е важно човек да знае за кой проект какъв framework да използва.
Ще започна с това, защото ми е адски смешно 
Видеото е много добро и забавно, наистина! Но…. 
Колкото и шум да има около RoR, поне аз няма да предам фронта. Ruby on Rails има някой сериозни бонуси от сорта на MVC разделението, което вярвам е на доста по високо ниво от това на който и да е PHP фреймуорк, готината темлпейт система, __autoload, което предотвратява нуждата от include, require и т.н. Сигурно има още доста готини неща… само, че аз ще ви кажа, защо няма да мина на руби. Основните причини са 3: SQL, дългогодишен опит с PHP, мисля като PHP developer, дори и когато програмирам на Java или C++, Rails не може нещо, което PHP да не може. За мен няма причина да мигрирам, макар и да е много модерно, макар и да има адски много, поне за мен „измислени“ причини, защо RoR е по-добро от PHP. Това е като нещата, които чета че CakePHP бил по-добър от… <фреймуорк>. И там абстракните им причини…
Всеки трябва да спре да гледа само от неговата си камбанария ами да тества и алтернативните решения. Ама след близо 6 години да се откажа от PHP? WTF? По-добре php guru от колкото Rails beginner 
Някой ако иска да спориме готов съм, не може да ме убедите, че Rails има повече преимущества от „грозното“, „мръсно“ PHP, но освен със забавни видео клипчета едва ли ще стане по друг начин. Между другото продължавам да твърдя, че не може да се сравнява език с феймуорк. Rails vs Zend Framework – ок. Rails vs CodeIgniter – ok. Rails vs PHP – wtf? Rails бил по-бърз от PHP… глупости на таркалета. Единствено startup времето му е по-добро. Ако говорим за бързодействие и трябва да сме обективни ASP.NET ги бие всичките (с изключение на великата Java, според някой независими източници, но пак е спорно) ) Така, че ако това е най-голямата гордост на един Rails developer не е много обоснована, макар и масово в интернет да има твърдения като гореспоменатото. Бла бла Нямам нищо против Rails, даже изглежда като много добра алтернатива, но все пак няма да мигрирам или ако стане, то ще съм се отказал от 90% от принципите ми на тоя етап
Иначе колко Advenced PHP developers познавате, които са минали на RoR? 1? 2?
Така… това го пиша, защото в последните две седмици ме попитаха 3 пъти за това нещо и явно, че хората не го знаят или по-скоро не правят разлика между двете функции. Разлика има и то съществена. Това, което прави двете функции толкова различни, че require() генерира fatal error, а include() ще генерира warning. С други думи при първото положение страницата няма да се отвори, а при второто ще се изпише само грешка на съответното място и останалата част от страницата ще се покаже. Практиката е следната, всички файлове, коит са от съществено значение за страницата, например бази данни, логини, пароли и всичко, без което сайтът ви не може да съществува и функционира правилно, то тогава се използва require(). При всички останали положение include(). Да речем че имате скрипт, който ви показва последните tweetове, за него ще е добра практика да го include-нете, защото и без него сайтът ви ще е ОК. Но ако имате db.inc.php съдържащ функции за връзка с базата данни, най-добре би било да го require()-нете. Просто е, макар и реално начинаещите да не виждат голям смисъл в тази разлика, но с практиката ще се убедите, че и двете функции са полезни и най-вече на места изключително нужни.
N.B.!! Във всички версии преди 4.0.2 всички файлове които се require()-ват трябва да са достъпни, без значение дали редът се изпълнява или не се изпълнява. Да речем, че имате IF условие, което не е истина в дадение случай, но въпреки това, файлът, който require()-вате трябва при всички положения да е достъпен иначе ще получите fatal error и страницата няма да се изпълни. След 4.0.2 всичко вече е ок, но ако при някакво стечение на обстоятелствата пишете на по-предишна от гореспоменатата версия, го имайте на предвид.
Малко в детайли и тънкости – include() е по бърз от двете функции, но пък може да ви създаде големи главоболия. Аз лично съветвам да се ползвате require() навсякъде, където е необходимо, което е в 90% от положенията, като не се притеснявайте чак толкова много за бързодействието, разликата е минимална.
Между другото днес официално направих първия проект – визуалната част на клиентски сайт посредством CodeIgniter и останах колкото доволен, толкова и разочаровн. Доволен от бързината на писане на код и от сравнително големите възможностите на фреймуорка. Разочарован – защото борбата с url адресите е повече от сериозна и се налагат доста хватки за да постигнете желания ефект, който цели един SE оптизатор – като при едно положение така и не разбрах как точно да направя това, което искам, освен на ръка, което си е… недопустимо, защото може и да не знам кое точно трябва да се пренапише в определената ситуация, и то не от незнания, а от динамични възможности на cms-а, а и във форума на CodeIgniter не се намери, кой да ми помогне, май сериозни ги затапих и хвърлих в размисли . Общи впечатления и оценка: 5 от 6, наистина има какво още да се желае за да го провъзглася за ултимално решение.
И един въпрос към всички хостинг доставчици – как може да няма един Ruby хостинг в България?!?!?!?!?!?!?!? В праисторическата ера ли живеем или е 2009та година??
След малко по сериозно ровене и малко повече търсене (по блоговете, в серп нищо не се намери) се оказа, че icn и space.bg поддържат Ruby. С извинения за прибързаните изводи! Утре земем от space.bg пък да видим…. Благодарение на този чуден сайт се образовах, за което благодаря
Ако сте PHP разработчик, то най-вероятно мразите JavaScript Шегувам се, добре де не съвсем, защото аз лично го мразя. Просто не е това, което искам да бъде. Както и да е, това е тема, която няма общо с това, което искам да кажа. Важното е, че вече всеки един PHP developer може да използва някой (на този етап са 408, което е около 81%) функции на PHP в JavaScript приложенията си. Пълен списък може да намерите тук, като в списъка са включени md5(), file_gets_content(), utf8_encode/decode, mktime() и още доста. В момента се работи по някой пробно, а други пък чакат да бъдат направени, но най-вероятно всички функции на PHP ще бъдат включени рано или късно, поне организаторите са си го поставили за цел. На страницата на PHP JS може да намерите и различни пакети, включващи различни функции, като имате възможност да си правите свои собствени такива.
Честно казано цялата идея и концепция ми е доста интересна. Най-вероятно ще се възползвам от някой от възможностите, които се предоставят, но гледам малко негативно на нещата, от гледна точка на бързодействие, като се има напредвид, че една част от функциите имат по-добра алтернатива. Но ще видим…
Между другото , прочетох някъде за интересна идея как да се отървем от спама без да ползваме капча. Идеята беше следната -> правите едно поле, което е скрито, даже е добре да има име от сорта на URL или e-mail или нещо такова, което обикновено се използва винаги от роботите. След което, като правите проверка, ако някой е писал нещо в него просто не събмитвате коментара и готово! Обаче практически няма никаква гаранция, че няма да бъдете наспамени пак, но пък вярвам, че по-голямата част от „боклука“ ще се „изхвърли“ по този начин.
Макар и да съм убеден, че повечето читатели на блога ми знаят какво е Intranet ще бъде голямо неуважение ако не го разясня в началото на поста за всички, които не знаят. Intranet представлява в най-общия случай частна мрежа на една организация, която е защитена по някакъв начин и достъпът до нея е ограничен и е недостъпна за външни лица. Въпреки, че в страната ни не се говори много много за това, всъщност Intranet е повече от полезен. За каква цел може да го използвате, ами в общи лини за съхранение на данни, които са конфиденциални и не искате целия свят да има достъп до тях, а и не само. С пъти по-сигурно съхранението им от колкото да ги държите в папки по рафтовете. Основният проблем в случая е, че това животно е все още доста непознато в страната ни. Нещо като SEO-то преди 3-4 години, просто не се знаеше какво е, дали се яде, дали се пуши и защо пък аз ще имам нужда от това. Да обаче аз съм убеден, че нещата ще се променят и Intranet ще навлезе сериозно в ежедневието на българските компании. В повечето големи такива най-вероятно има подобни мрежи, но уви само големите фирми могат да си го позволят, а и имат идея какво точно е то.
Уеб Дизайн България ® – фирмен блог