Напоследък май здраво съм се вманиачил по играчката си. Щом я дооправям и по Коледа…
Ботът успешно стигна до третата бета на версия 0.30. И както и при предишните бети, дописването е колкото за разлика между доста сериозни версии.
Като начало, прибавих теглене на описание на API модулите на уикито, с пълните им описания, списъците на параметрите, и т.н. Още не се оползотворяват при работата на бота, само се предоставят чрез подходящи функции на скриптове, които го ползват. И оползотворяването им ще дойде, но в някоя по-късна версия. Може би когато направя структурата на бота модулна, съответстващо на модулите на API-то… Работи от МедияУики версия 1.12 нагоре; много от модулите се рапортуват коректно, или изобщо ги има само при най-нови версии.
(Една невчесана, но полезна демонстрация на изтегляната информация за уикита може да бъде видяна на http://apibot.zavinagi.org/demos/wikiinfo. Въвеждате пътя към API скрипта на уикито, структурата на чието API искате да разгледате, избирате си от чавките отдолу каква информация искате за него, и цъкате бутона. Чака се до минута-две, в зависимост от количеството информация и скоростта на връзката.)
Добавих също така функции и екшънобекти за качване на файлове в уики, пряко или чрез URL. Още не са съвсем изтествани, но се надявам да работят. Ако са нужни някому, ще има бъг репорти и бъгфиксове. Ако не, значи нужда от бъгфиксове няма. 🙂
Дописах web-based backends за някои от основните функции на уикито – ботът ги използва при версии на MediaWiki, в чието API все още няма съответната функция. Най-старата инсталация, която имам подръка, е версия 1.11 – при нея работят прилично. За при по-стари не знам.
Преработих също и карантията на някои от итераторите. Видимо работата с тях е същата, но създаването на техни наследници вече е много по-функционално. Дано бъде от полза.
Изчистих един тон идиотски бъгове. Направо срам ме хваща, като си помисля колко грешки си откривам. Но и се гордея, че си ги откривам.
Като цяло, ботът стигна до повратна точка в развитието си. Функционалността на основния модул вече е на практика завършена – покрити са всички функции, които API-то на МедияУики предлага стандартно, поне към наличната засега версия (1.16). Оттук нататък надали ще има големи промени в експортираните от него функции. Само ще се дописва при поява на нова функционалност в API-то на МедияУики. (Между другото, броят експортирани от основния модул функции надхвърли 300. 🙂 )
Стандартните итератори вече също са като цяло стабилизирани като интерфейс. Дори да има отсега нататък по-сериозни промени, очаквам да са предимно “под капака” – да не дават особено отражение върху написаните за Apibot скриптове.
Стандартните екшънобекти са постабилизирани, но за тях не смея да давам толкова сериозни гаранции. Просто ботът все още се използва твърде малко, за да е изтествана схемата им наистина. Надявам се обаче използването да нарасне :-), и схемата и при тях да бъде изчистена.
А идеи – колкото щеш. Да имах и времето да ги реализирам всички, щеше да е супер:
– основният модул да се разбие на подмодули, съответстващи на модулите в API-то на МедияУики
– да се реализира функционалност за екшънобектите, която да позволява техни параметри да бъдат задавани от прехвърляните обекти с данни по “механизиран” начин
– да се реализират “трансформобекти”, които да могат да бъдат вмъквани като верига между итератори и екшънобекти, и да трансформират предаваните обекти с данни по стандартни начини. Горе-долу както програмки под Юникс могат да си предават данни една на друга, и да се сглабят като лего в сложни обработки.
– да се допишат още итератори за какво ли не, и екшънобекти за какво ли не
– и най-вече, да се направи уеб интерфейс, който позволява на бот-оператор да си “сглоби” през него верига от итератори и екшънобекти, и да им зададе необходимите параметри и без да знае PHP. Определено ще е от полза.
… Но това са мечти. Засега наличното е 0.30 бета 3. Свободен софтуер – на който му трябва бот за МедияУики, е добре дошъл да го пробва. 🙂
Привет Григор,
Честит празник! 🙂
Следя поредицата ти от постове за Апибот и я намирам за доста интересна. 🙂
Не съм php програмист и не мога да помогна с конструктивни коментари в областта на езика, но може би имам една идея от гледна точка на методологията на разработката.
Но преди да я изложа, искам първо попитам дали имаш автоматично тестване или цялото тестване е ръчно?
Поздрави,
Николай
@Николай Василев: Уви, цялото тестване е ръчно. Като за капак, дори не съм пуснал едно PHP в strict mode, да изплюе каквито предупреждения по кода ми види, че да ги оправя. Просто не смогвам. 🙁
Дай си идеята за методологията. Охотно приемам всякакви идеи. 🙂
Привет,
Идеята ми е свързана с писането на автоматизирани тестове.
В Java света има един framework (може би “платформа” трябва да се преведе), за С# има алтернатива – NUnit, и т.н. Мислех си, че най-вероятно има такава платформа и за PHP.
Последните години се зароди методология наречена Test Driven Development, при която за очакваната функционалност първо се пишат тестове (класове или функции, които тестват твоите класове и функции), с цел да гарантират, че твоят код върши това, което е по спецификация (нещо като гаранция, че при определен вход, функцията ти връща определен резултат/се държи по определен начин). След това се пише реалния код на програмата, така че да удовлетворява тестовата функция. След това се пише отново тест за следващата частичка от софтуера, имплементира се така, че да удовлетворява тестовете и т.н. докато се завърши програмата.
В процеса на работа се натрупват доста тестове по този начин и в последствие, ако нещо се променя по вече съществуващия код, ако това повлияе на първоначално имплементираната функционалност, тестовата функция не успява да се изпълни, пораждайки грешка. По този начин човек има (известна) гаранция:
1) че когато пише програмата, всичко се изпълнява съгласно спецификацията (според която са създадени тестовете)
2) в процеса на еволюция на програмата, ако неволно програмистът промени нещо, което не е по спецификация, проблемът ще бъде установен още по време на разработка на програмата, а не когато тя бъде пусната в експлоатация.
3) от тестовите функции може да се разбере как се очаква да се държи дадена част от кода.
4) гарантира високо качество на кода.
Гореописаното писане на тестове се отнася само за различните класове/функции и т.н., затова се нарича unit testing.
След като работата по даден модул в програмата приключи (всъщност може и по време на разработката), могат да се напишат и интеграционни тестове (integration testing), които имат за цел да гарантират, че не просто отделните класове и функции изпълняват, това което се очаква от тях коректно, но и целия модул комуникира и функционира коректно като част от цялата система.
Не съм сигурен, че успях да предам много добре идеите. Може би уикипедия е добра начална точка за въведение в автоматизираното тестване на програмите:
– http://en.wikipedia.org/wiki/Test-driven_development
– http://en.wikipedia.org/wiki/Unit_testing
– http://en.wikipedia.org/wiki/Integration_testing
Ако мога да бъда полезен (поне на ниво идеи, т.к. не съм запознат с РНР, ще се радвам да помогна)
* Java unit testing платформата се нарича JUnit.
@Николай Василев: Мисля, че разбрах идеята ти. Харесва ми. Пред нея обаче има няколко проблема, за които ми е нужен съвет как да ги реша:
1. Недостатъчно работна ръка. Реализирането на тези идеи изисква поне 2 пъти повече работа, отколкото сегашната ми. Вярно е, резултатът е истински на ниво, но аз просто нямам толкова време към момента. Може би следващата голяма версия, в която планирам да пренапиша кода почти изцяло, може да се работи по този начин.
2. Ботът реално е клиент, който работи със сървър – API-то на МедияУики. А то често е не съвсем стабилно. Към момента например не мога да изтегля от Уикипедия инфо за userrights модула на API-то – заявя ли го, API-то се бъгва. (Съответно, ботът заявява модула, но проверява дали резултатът не е бъгнат, и ако е, праща нова заявка, без него.) Възможните бъгвания на API-то са твърде много, за да има как да се отсяват автоматично – респективно, системата като цяло не е изтестваема. (Да се изтества само ботът също не е малко, но не е всичкото.)
3. API-то непрекъснато еволюира. Всяка нова версия на МедияУики добавя нови функционалности поне в по няколко модула на API-то. Съответно, написаните вече за тях тестови модули не проверяват дали те се употребяват правилно. Отделно от това, ако дописаният за тях бот пробва да ги използва, тестовите модули могат да рапортуват това като грешка (“ботът подава погрешен параметър…”). В идеята определено има хляб, но уви, не е лесна. Както се казва, walking on water and implementing a specification is easy, if both are frozen…
Между другото, ти основно на Java ли пишеш? 🙂
Привет Григор,
1. Да, отнема малко повече време, но после имаш гаранция, че кода ти работи както се очаква. Да, отначало изглежда, сякаш тестовете отнемат адски много време, но напоследък се включват като част от времето за разработка на задачата, т.е. започват да стават задължителни. Шефовете започват да изискват, когато реализираш някаква задача, тя да се смята готова едва когато си написал и тестове, за да гарантираш, че това, което си направил, работи коректно.
Реално, не е нужно тестовете да ти покриват 100% от функционалността. Достатъчно е да покриеш най-ключовата част от кода си. За елементарните функционалности (като setter и getter например) няма смисъл от тестване.
2. Принципно има и други платформи за тестване (в областта на Java) освен JUnit – EasyMock и JMock, които ти позволяват да създаваш mock-oбекти, т.е. обекти, които симулират функционалността на външни системи докато ти си тестваш твоята функционалност. Съответно, ако външната система промени функционалността си, ще трябва и ти да промениш тестовете (но като се замисли човек дори и собствения ти код тогава ще се промени, за да функционира адекватно).
3. Ами не е нужно да пишеш тестове за работата на МедиаУики. На теб ти трябват тестове само за твоят код. МедиаУики е външна система и реално ти нямаш контрол върху нея. В такива случаи, когато външна система еволюира, твоята трябва да се напасва към промените. Неизбежно е.
Да, основно пиша на Java 🙂 От време на време хвърлям поглед и в чуждите дворове, но нямам много време и се старая да не изпускам новостите поне в областта на Java…
@Николай Василев: Проблемът с времето е не че отнема прекалено много време (само около 2 пъти повече), а че отнема време, което нямам. Тоест, изборът ми се оказва между нещо несъвършено и нищо. По-добре несъвършеното… Освен това, методологията с “пълното тестване” (то неизбежно е непълно, по описаните причини) е типична по-скоро за closed source разработка. При open source методите по-често се работи на “release early, release often” – тоест, разчита се и на потребителите да тестват и да бъгфиксват. Напълно различна философия на девелопмент е.
За тестовете – при клиент-сървър взаимодействия от такава категория са изтестваеми напълно само баналните неща. Един вид синтаксисът на програмната логика. За нейната проверка са ми достатъчни тестови модули със сложността на МедияУики – тоест, ако я пренапиша за тестови цели, мога да мина със само толкова работа. За семантиката на логиката сложността на тестовите обекти се качва нагоре. Като се има предвид сложността на МедияУики, ресурсите на средна по размер фирма надали биха ми били достатъчни.
За тестовете за работа на МедияУики – нужни са ми тестове за актуалната й спецификация, защото тя не е формално дефинирана в цялата си пълнота. В добавка, спецификацията й е динамична – дори старите модули непрекъснато търпят добавки, понякога и промени, и често в тях внезапно се появяват бъгове (като например този с userrights). Иначе казано, не мога да си напиша тестов модул, защото “сървърът”, към който ботът се връзва като клиент, непрекъснато се променя. Трябва да променям непрекъснато и тестовия модул, при това без да знам какви промени е необходимо да внеса (далеч не всички се документират, особено от бъговете). Не е реално да го постигна.
Затова вървя по линията на най-малкото съпротивление. Имам инсталирани МедияУикита най-различни версии, от последна девелопмент версия (Уикипедия) до 1.11 (API-то поддържа кажи-речи само Query модула, и то много ограничено). Те ми служат като тестови модули. Тестването по този начин не е съвършено, но и по другия всъщност не е. Разликата в качеството на теста е сравнително малка, а в положения труд е в порядъци. Ако работя както сега, давам продукт, който не е съвършен, но е като цяло работоспособен, и ако се открие бъг, може да бъде чистен. Иначе просто няма да мога да стигна до това да дам дори начален продукт. По-добре зле изтествано нещо, отколкото добре изтествано нищо.
Отделно от това, често нямам време да направя дори най-простички тестове на това или онова. Каквото хване синтактичният парсер на PHP се оправя, другото се оставя на потребителите. Колкото смогна, толкова правя. Който иска по-издебъгнато – кодът е открит, платформата е свободна. Искаш салата – ей ти от мен безплатно лехата със салатите, откъсни си, нарежи си, сервирай си. Искаш салата без да си мръднеш пръста – сори… Справедливо е, нали? 🙂
Привет отново,
Да напълно съм наясно с всичко, което описа.
Не съм съгласен за позицията ти, че тестването е характерно за closed source разработки, но всичко е въпрос на навик и виждане (и най-вече време).
Иначе, аз не се опитвам да те убедя, че задължително трябва да тестваш кода си. Просто ти показах една гледна точка и идея 🙂
@Николай Василев: И през ум не ми минава да твърдя, че тестването е характерно за closed source разработките. Твърдя, че философията на open source е нещата да не се държат до пълно изтестване, а да се пускат често и рано – прилича, но не е същото.
А и съм напълно съгласен, че трябва да тествам кода си. Просто нямам времето да го направя както трябва. 🙁