На времето мразех да правя тестове. Много. Не виждах голям смисъл в цялата тая работа. Какво да му тествам, по кода си личи, че работи. Какво може да се прецака в 30 редова функция? Защо да губя време в рефрешване, попълване на форми и разиграване на различни кейсове. Пълна идиотщина.

За съжаление обаче в реалния живот тестовете са необходими. Когато имах по-малко проекти, по които работих всичко беше песен. Пишеш, правиш, струваш, ако изкочи нещо – то ше се чуе и съответно ще се поправи. Чудна работа. Но с времето проектите започват да се трупат. Сайтовете за които трябва да трепериш стават над 100. Във всеки един момент нещо може да се счупи и отговорността ще падне върху твоите плещи. Ами ако всичко се счупи точно в един ден? Какво ще правя? Как изобщо мога да имам застраховка, че всичко работи както трябва? Ами какво ако съм поел още 10 нови проекта, чиито краен срок е съвсем скоро. И ако изкочат да речем 10 бъга по стари 5 проекта, как изобщо ще спазя крайния срок на нещо? Застраховката за цялата тази доста прецакана работа се нарича автоматизирани тестове.

Не за пръв път ми се случва да правя архитектура на уеб приложение, което ще бъде мултиплатформено, аджеба няма да се ограничаваме само с PHP или Джава, но може би за пръв път се задълбочавам толкова много в това си начинание. Малко предистория – за нашия опен сорс стартъп, едно от няколкото приложения, които решихме да направим е тип GTD, което е практически почти клонинг на изестните такива (tadalist, mojonote), но поправя някой тяхни дразнещи недостатъци. За повечето от вас, които не знаят аз съм голям почитател на тодо списъците. Правя си постоянно. Правя ги в промишлени количества. И както сами се досещате използването на хартиен носител за такова начинание води до много неудобства. Естествено сметнах, че е безумие да се налага да си нося десетките списъци постоянно с мен за да правя справки. Именно поради тази причина започвах да използвам различни уеб приложения. Повечето от тях са много готини, но все намирах недостатък. И така се роди идеята за проекта.

Ха честита Ви нова година драги колеги! Живи и здрави и двойно по-успешни проекти тази година. Но най-важното здраве за вас и вашите близки, другото ще го изкодите както се казва

Тъй като на повечето от вас ви се налага да работите с api-та на ежедневен принцип имам нужда от вашето мнение. Имам честта да изградя API за една от най-големите куриерски фирми. Въпреки това, мнението на един екип не е достатъчно при направата на такова творение. Именно заради това отправям апел към всички вас, които имате опит с консумацията на API-та. Какво бихте искали да има, кое би ви направило живота по-лесен при вграждането? Какви са вашите изисквания, без които не може да се съгласите да го импортвате? Мнението ви е важно! Въпреки, че аз ще се занимавам с „дизайна“ и поддръжката му не отказвам фийчър рикуести.

Преди известно време се вдигна голям шум за това, че двама от lead разработчиците на CakePHP прекратяват дейността си по проекта. Голяма част от хората, които не просто използват Cake, ами се вълнуват от това, което става покрай него, изказаха големи притеснения относно бъдещето на фреймуърка. Въпреки това, преди няколко дни излезе файнъл рилийз на 1.3  и нещата поне на този етап изглеждат добре.

Паралелно с това се случи и нещо, далеч по-значимо за мен. Роди се фреймуърка Lithium. Още от самото начало се вдигна доста шум около него, който напълно логично намаля след време. В момента на публикуване на този пост Lithium е вече версия 0.9.5, тоест доста близо до заветната единица и стабилен рилийз.

В последните три дена си играх и направих един клиентски проект на CakePHP. Останах с адски добри впечатления от framework-a. Всъщност има много повече предимства от колкото ще ви се стори на пръв поглед. Недостатъци почти не се намират, особено ако имате опит с други frameworks ще е убедите, че е доста по-добре замислен и реализиран от останалите. Ето и моето ревю на CakePHP Framework.

Документацията

Много е слаба наистина. Дори и на пръв поглед да ви се стори много добра, всъщност основни примери и разяснения липсват. Добрата новина е, че всичко, което ви трябва може да бъде открито в Google, защото обществото на CakePHP е доста будно. Естествено цялата нужда информация я няма синтезирана на едно място и е малко неудобно, но какво пък, не е болка за умиране. Естествено това би отказало хората, които не им се занимава чак толкова. Имено заради това CodeIgniter печели ежедневно много потребители, защото документацията е перфектна и за да започнете ви трябва много малко. Но способностите на CI са далеч под тези на CakePHP.

ORM и валидация

Повече от перфектни са и двете. Основната разлика при това с CodeIgniter, е че валидацията се налага в модела и няма нужда да я пишете всеки път. Което е бомба. Има доста „вградени” методи по които можете да валидирате, които включват дали записът е уникален, дали е валиден e-mail и така нататък. Доста по-идейно решение от колкото валидацията да се пише многократно.