Chodzi tutaj o klasy api_*, służące do manipulacji pojedynczymi wpisami w Bazie.

API

uniBoard do pracy z użytkownikami, forami, postami, grupami ustawień a nawet emotikonami używa specjalnych klas. Za każdym razem kiedy chcemy dłubać np. przy profilu użytkownika i potrzebujemy walidacji wprowadzanych danych, możemy wykorzystać api_user, które tworzy się w następujący sposób:


$user = new api( $appCore, $appCore -> _REQ( 'id_usera'));


Jeśli user został znaleziony i załadowany, własność „data_loaded” ma wartość true.

set

Do ustawiania wartości w API służą metody dostępowe set*():


// Fill API with data
$this -> api -> setUserName( $this -> appCore -> _POST( 'user_name'));
$this -> api -> setUserLogin( $this -> appCore -> _POST( 'user_login'));


Każda metoda wykonuje przynajmniej dwa kroki:

1. Zapis danych wewnątrz API
2. Poinformowanie metody saveData() o nowych zmianach

Opcjonalnym trzecim krokiem jest sprawdzenie poprawności danych. Jeśli pojawi się błąd zapisu, API zablokuje metodę saveData() i ustawi własność „error” na true. Dodatkowo komunikat błędu znajdzie się w liście „errors”. Co dalej zrobi z tym kod, zależy od programisty.

get

Tutaj zaczynają się problemy. Każda własność znajdująca się w API wymagania metody get. O to api_smiley:


$api -> getSmileyName();
$api -> getSmileyReplace();
$api -> getSmileyImage();


Wygląda dobrze. 3 Fajne metody… niestety api_user ma ich aż 46. Pisanie takiej ilości getów jest niesłychanie upierdliwe i pożera sporo czasu który mógłbym poświęcić na coś ciekawszego, np. pisanie akcji które z tego api korzystają.

Dlatego postanowiłem wywalić wszystkie te gety i zamiast tego używać bezpośrednio własności API:


$api -> smiley_name;
$api -> smiley_replace;
$api -> smiley_image;


Pisanie api jest teraz dużo szybsze.

__GET __SET – STOP!

PHP 5 udostępnia obiektom magiczne metody __GET i __SET. Dlaczego więc ich nie wykorzystuję? Funkcje te zostały wprowadzone do PHP5 jako rozwiązanie problemów projektowych i odciążenie dla biednego eval().

Problem w tym że wielu ludzi używa ich do ułatwienia sobie pracy podczas pisania kodu. Napisanie jednego __SET jest wygodniejsze niż 46 własnych. Metody te nie bez powodu nazywane są magicznymi. Magiczność nie oznacza jednak „magiczne zrób się samo” tylko „niech php wykona testy i uruchomi specjalny kod ze skryptu”.

Problem w tym że $obiekt -> zmienna; dla zmiennej publicznej oznacza dla php sprawdzenie czy zmienna istnieje w obiekcie i zwrócenie wyniku. Zmienna prywatna dokłada tutaj wymóg sprawdzenia przez php możliwości dostępu (trochę wolniejsze), istnienia metody __SET (wolniej) i zinterpretowanie kodu PHP użytkownika (z ang. Bottleneck – wąskie gardło). Większość standardowych funkcji PHP to nakładki na leżący pod nimi gotowy kod C++, który zawsze jest szybszy od odpowiadającego mu kodu impretowanego!

Szukającym liczb polecam jeden z przykładowych benchmarków z Google.

Na jeden czytelny obrazek przypada kilka nieczytelnych i kilka kosmicznych. Te ostatnie postanowiłem zbierać.

Szczególnym rodzajem obrazków kosmicznych są te ze słowami niemożliwymi do przepisania. Słowa reCAPTCHA bierze z książek, a te nie zawsze zawierają znaki wyłącznie z angielskiego alfabetu, bądź używają formatowania niemożliwego do napisania „z palca”. A to trzeba przepisać coś z indeksu górnego, a to pojawi się cyrylica, klasyczna greka albo orientalne kaji.

Zbiór można przeglądać tutaj:

reCAPTCHA FAIL GALLERY

Kolekcję będę uzupełniał w miarę chęci.

www.uniboard-project.org

Na razie nic tam nie ma, ale kto wie co przyniesie przyszłość.

1. Komentarze profilów
2. Własne pola profilów
3. Reputacje użytkowników
4. Podział na zdjęcia i avatary
5. System przyjaciół i wrogów
6. Lista gości w profilu
7. Prywatne dyskusje
8. System Powiadomień
9. BBCode [Flash]
10. „Agresywny” Parser Postów
11. Ajaxowe bajerki przy rejestracji
12. Opisy tematów

A co nowego?

Z nowości na chwilę obecną podam tylko dwie: pierwszą jest nowy styl, drugą zmiana domyślnego języka projektu na Angielski. W trakcie Beta-testów równolegle do poprawek w tym pierwszym powstawać będzie tłumaczenie skryptu na język Polski.

Nie oznacza to jednak że nic w kierunku ukończenia uB nie robię. W tym wpisie postaram się przybliżyć wam zmiany w projekcie które zaszły w tym miesiącu.

Siódmy Sierpnia

Siódmego Sierpnia Anno Domini 2010 po powrocie z wakacji zasiadłem do kodu i postanowiłem przejrzeć to co już mam pod kątem wydajności i jakości. Wynikiem tego przeglądu było załamanie nerwowe.

Jakość Kodu

W trakcie powstawania uniBoard przeszedł przepisanie sporych części kodu od nowa. Wynikiem tego był kompletny śmietnik w kodzie, który czynił go nieczytelnym dla nikogo oprócz mnie, i tylko dzięki faktowi że to ja za nim stałem. Kod nie był pisany według żadnych standardów, a długi okres jego powstawania skutkował różnicą w wieku między poszczególnymi plikami wynoszącą nawet 22 miesiące.

Wydajność również nie powalała. Chociaż nowy kod nie był takim pożeraczem zasobów jak Callisto, uniBoard był średnio 2-3 razy wolniejszy od IP.B 2.3, a wyświetlenie tematu zajmowało mu tyle samo co paskudnie napisanemu poprzednikowi. Dodatkowo mimo kolejnych zmian w parserze postów ciągle możliwe było pisanie wiadomości, przy których wyświetlaniu server po prostu klękał i błagał aby go dobić.

Ważną cechą którą każdy twórca aplikacji powinien posiąść jest samo-krytyka. Twój kod może ci się wydawać najdoskonalszym rozwiązaniem problemu jakie kiedykolwiek powstało, ale tak nigdy nie będzie. Uznałem więc że jako twórcy skrypt w pierwszej kolejności powinien odpowiadać mi. Nie ma być doskonały. Ma mi się podobać.

uniBoard nie spełniał tego warunku…

Po Siódmym Sierpnia

Ósmego Sierpnia postanowiłem zastanowić się od nowa nad całym projektem.

Dlatego zadałem sobie kilka pytań:

1. Czy naprawdę muszę zaimplementować każdą funkcję?
2. Czy funkcjonalność jest cenniejsza od wydajności i skalowalności?
3. Czy koniecznie wszystko ma być zawarte już w pierwszym wydaniu?
4. Czy warto zawsze słuchać sugestii potencjalnych użytkowników?

Nim zaczniesz czytać odpowiedzi, pamiętaj że są one moimi opiniami. Jeśli się z nimi nie zgadzasz… cóż, jestem pewien że znajdziesz na rynku bardziej odpowiednie dla ciebie rozwiązanie forum.

Czy naprawdę muszę zaimplementować każdą funkcję?

NIE – Ani phpBB ani SMF czy inny PunBB nie powalą nikogo kto przynajmniej raz bawił się ACP IPB bądź vBulletina oferowaną funkcjonalnością, a jednak każde z tych rozwiązań skupia wokół siebie wierną i aktywną społeczność. Quality over Quantity – Jakość ponad ilość.

Czy funkcjonalność jest cenniejsza od wydajności i skalowalności?

NIE – Odpowiedz sobie na następujące pytania: Czy chcesz aby społeczność na twoim forum była duża i aktywna? Czy gdy stanie się ona zbyt duża, zmienisz rozwiązanie czy server? Duża funkcjonalność to fajna sprawa (tyle "ptaszków" w ACP!), ale w dalszej perspektywie lepiej jest poświęcić funkcjonalność na rzecz umożliwienia dalszego wzrostu społeczności. Mniejsza funkcjonalność jest tańsza od konwersji na inne rozwiązanie lub zmiany platformy na wydajniejszą. Less is More – Mniej znaczy Więcej

Czy koniecznie wszystko ma być zawarte już w pierwszym wydaniu?

NIE – Na razie udajmy że nie ma związku między czasem potrzebnym na zawarcie zaplanowanej funkcjonalności a jej rozmiarem i zabawmy się w abstrakcję. Powiedzmy że 5% błędów w kodzie zostaje niewykryte aż do wejścia w fazę produkcyjną. Niech nasz kod ma na starcie 40 funkcji z czego połowa jest błędna. Z dwudziestu funkcji 2 będą błędne. Doświadczenie nauczyło mnie że im większy projekt, tym mniejsza wykrywalność błędów. W euforii użytkownicy rzucają się na dane główne ignorując funkcje dodatkowe.

Czy warto zawsze słuchać sugestii potencjalnych użytkowników?

NIE – Każdy może mieć swoje oczekiwania względem projektu, jednak spełnianie wszystkich zachcianek zgłaszanych przez użytkowników to prosta droga do klęski. Zamiast poświęcić czas na rozwój aplikacji i poprawienie jej jakości, twórca idzie „w bok” implementując funkcje które będą wykorzystywane przez drobną część użytkowników, a które będą przecież wymagać poprawek, rozwoju i aktualizacji. Lepszym rozwiązaniem będzie implementowanie tylko tego co według ciebie pasuje do systemu forum i będzie popularne wśród użytkowników. Z drugiej strony jeśli zapotrzebowanie na jakąś funkcję będzie realne, zawsze istnieje szansa że ktoś wykona odpowiednią modyfikację, w ten sposób biorąc na siebie jej rozwój.

Co to znaczy dla projektu?

uniBoard powstaje od nowa. Jest to trzeci rewrite w burzliwej historii skryptu, jednakże tym razem różni się on od poprzednich. Nim jednak przejdziemy dalej, uprzedzę ewentualne zarzuty o zmarnowaniu 2.5 roku na tworzenie kodu który i tak pójdzie do śmietnika. Wraz z kodem nie wyrzucę doświadczeń i wiedzy które zdobyłem w trakcie prac nad nim, a te posłużą mi do stworzenia jeszcze lepszego projektu.

Nie mam zamiaru zanudzać was technicznymi szczegółami pokroju „php 5.3.0″, „MySQLi”, „MVC” czy „agresywne cache”. Zamiast tego w oparciu o pytania z poprzedniego rozdziału przedstawię Wam nowe założenia projektu:

uniBoard ma być aplikacją Forum

Jeszcze raz – aplikacją forum. Tak, forum. Wiesz czym jest forum? Spójrz tam. Nie, to nie forum, to kombajn. Teraz tam. To też nie forum, to CMS. Teraz tam. Widzisz? Działy, a w działach tematy i posty. To jest forum. A tam? Tam jest platforma startowa dla rakiet kosmicznych.

uniBoard będzie oferować funkcjonalność forum. Nie założycie na nim portalu newsowego, nie będziecie pisać na nim artykułów używając rozbudowanych opcji edycji*, nie będzie też śledził torrentów i nie pokieruje budową domu. Nie znajdziecie też w nim na standardzie takich zajefajnych funkcji jak kolorowe tytuły tematów, shoutbox czy piwa (całkiem dobre, ale nie na forum).

* – Tak, spotkałem kogoś kto chciał przy użyciu skryptu forum prowadzić… gazetę. Ten ktoś na sugestię braku rozsądku wielce się obraził i z miejsca uznał że uniBoard kiepskim skryptem forum będzie… chociaż nie jestem pewien czy nie chodziło mu o CMS.

Po pierwsze: wydajność

Powiedzmy sobie że prowadzisz forum hobbystyczne np. o uprawie paprotek i nie masz wielkiego pojęcia o technikaliach. Kupiłeś server za 60zł rocznie i domenę za drugie tyle, a więc utrzymanie tego wszystkiego to 120zł rocznie. Nagle w całym kraju wybucha moda na paprotki. Posiadanie paprotki jest „trendy” i twoje forum zaczyna rosnąć. W końcu dochodzi do rozmiaru przy którym forum po prostu zwalnia, a część użytkowników zaczyna zgłaszać białe strony a twoi znajomi dzwonić „coś się stało bo chyba ktoś zhakerował bo jakieś pięćset errorów jest”.

Szybkość i generowanie obciążenie to nie są tylko abstrakcyjne terminy których używają admini by być pro. Rozmiar aktywności na forum przekłada się na wymagania względem servera który to forum utrzymuje, a to oznacza koszta. Skrypt może być darmowy, prowadzenie forum na początku też, ale gdy zacznie rosnąć, w końcu zacznie wymagać inwestycji. A wtedy bądź pewien, bardziej od funkcji będzie interesować ciebie zmniejszenie wykorzystania zasobów.

Weźmy pierwszy lepszy benchmark porównujący liczbę obsłużonych żądań strony z tematem między phpBB 3 a MyBB 1.6. Dla ludzi nie mówiących w języku Apache Benchmark wyjaśnienie: w jedną sekundę MyBB 1.6 wypluło z siebie 86 stron z odpowiedziami w temacie, podczas gdy stare i zacofane** phpBB 3 „jedyne” 200. Oznacza to że gdyby nasze paprotkowe forum w pewnym momencie uznało „do nawozu z tym!” i przeszło z MyBB na phpBB3, straciło by fajne funkcje typu system reputacji albo szybka odpowiedź na ajaxie, ale byłoby wstanie wyświetlić odpowiedzi w temacie około 120 osobom więcej niż poprzednio. To 150% zysk przy zerowych wydatkach na sprzęt.

Funkcjonalność lub użytkownicy, sami wybierzcie. Pamiętajcie jednak że wyłączenie czegoś w ACP przy większych funkcjach oznacza mniejszy zysk niż gdyby takiej funkcji w ogóle w kodzie nie było. Takie funkcje zwykle siedzą głęboko w programie, więc część kodu który za nimi stoi wykonywany jest bez znaczenia czy funkcja została odfajkowana w ACP, czy nie.

** ironia

Model przyrostowy

Największa zmiana w porównaniu z poprzednimi uniBoard’ami to nowe podejście do kwestii wydań. Gdy uniBoard będzie posiadać to co w forum najważniejsze, a więc fora, posty, rejestracje, etc ect, zostanie wydany jako 0.1. Zero-kropka-jeden, nie jeden-kropka-zero. Oznaczać to będzie że kto chce skrypt forum z podstawowymi funkcjami, już może go wykorzystać, ale wszystkie zaplanowane funkcje nie zostały jeszcze zaimplementowane, więc w przyszłości ukażą się kolejne wydania noszące numerki między 0.2 a 0.9, aby w końcu osiągnąć wersję 1.0 gdy wszystkie funkcje które były zaplanowane zostały zaimplementowane.

Powolutku, pomalutku…

Prośby o nowe funkcje

Zmiana podejścia nie tyle do kodu co prowadzenia projektu. O ile poprzednio byłem otwarty na wszystkie funkcje, osiągnąłem w tym ekstremum, implementując praktycznie wszystko o co ktoś poprosił a ja miałem wiedzę i umiejętności do zrobienia. Dlatego postanowiłem co następuje: Każdy będzie mógł napisać prośbę o nową funkcję, ale tylko te które pasują do skryptu forum i według mnie są naprawdę tego warte, zostaną zaimplementowane. Pozostałe będę zwyczajnie ignorować.

Możesz teraz krzyknąć „co za ignorancki egoista!”, ale prawdziwy powód jest inny. Jako twórca projektu mam pewną wizję którą chcę zrealizować. Nie którzy nie będą mogli zrozumieć że ich funkcja nie nadaje się do tego aby być na standardzie. Próby wyjaśniania tego w większości kończyły by się dosłownym „pierniczeniem kotka za pomocą młotka”.

Pamiętajcie jednak o modyfikacjach. Fakt że nie ma czegoś w wersji „z pudełka”, nie oznacza że nikt nie będzie mógł we własnym zakresie stworzyć i wydać modyfikację która to umożliwi.

Projekt ma realizować moją wizję skryptu forum. Jeśli wizja ta ci się nie podoba, nie będę jej zmieniał aby ci dogodzić. Na rynku dostępnych jest wiele rozwiązań. Jeśli chcesz funkcji jak w „przemie” lub MyBB to wybierz je. Nie będę „przebierał” mojego skryptu aby zaspokoić czyjąś zachciankę posiadani imitacji „made in Poland”.

Na Koniec

Alfa uB 0.1 zaplanowana jest na Wrzesień, a postępy w pracach oraz sam kod można oglądać w SVN projeku na Google-Code.

Licencja pozostaje bez zmian – Gnu GPL v3

Mam nadzieję że ten przydługi tekst wyjaśnił wszystkim sytuację projektu i powody stojące za moimi decyzjami.

Dodatkowo przekonałem się do Tweetera. Co aktualnie robię, można sprawdzić tutaj.

Po długiej przerwie wkońcu pojawił się odpowiedni materiał na nowy wpis. Ponownie bedzie on poświęcony systemowi szablonów uniBoard ;)

Bardziej zainteresowani moim blogiem czytelnicy zapewne pamiętają, że w uniBoard templaty były parsowane w locie. Bardzo zachwalałem ten system, lecz miał on dwie istotne wady.  Parsowane klucze działały, jeśli zostały zapisane w odpowiedniej kolejności, inaczej parser głupiał.  Oprócz tego parser templat potrzebował trochę pamięci aby działać (liczba ta zaczynała się od 100kb i dobiegała do 10mb), co było absolutnie nie do zaakceptowania zwłaszcza, że chciałbym aby mój skrypt przeważnie mieścił się w 4mb ram, zaś gdy trzeba wykonać więcej operacji, i tak nie przekraczał 8mb. Ale to wymagało czegoś wiecej niż poprawek w istniejącym kodzie.

Tak, od tygodnia piszę uniBoard od nowa. Engine który poprzednio potrzebował 6mb aby wyświetlić nagłówek i stopkę, teraz robi to samo nie przekraczając 1mb.  Spadły również czasy generowania strony, co docenia ludzie z wolniejszymi hostami. Ale najwieksza zmiana dotyczy właśnie szablonów.

Jak było?

Poprzednio w uniBoard gdy jakiś szablon był potrzebny, prosiło się obiekt $style aby ten załadował grupę do której on należał. Następnie tworzyło się instancję klasy api_get_template, w konstruktorze zawierającej id szablonu. Potem wrzucało się mu kilka zmiennych metodą „registerValue()”, i parsowało przez „drawTemplate()”.

Jak jest?

Całkiem podobnie. Gdy potrzebujesz jakiegoś szablonu, prosisz obiekt $style, o wskaźnik na grupę. Ten ładuje szablon, lub też tylko zwraca wskaźnik na obiekt. I tutaj zasadnicza różnica. O ile poprzednio obiekt tworzyło się „na miejscu”, o tyle teraz wszystkie szablony są pierw „kompilowane” do obiektów php, i w takiej formie ładowane do kodu. Ma to dwie zalety. Po pierwsze, odpada parsowanie surowego tekstu za każdym razem gdy wyświetlamy szablon. Po drugie, jeśli szablon jest dobrze napisany, nie musimy się martwic o kolejność parsowania elementów, całą robotę odwala za nas parser php. No i po trzecie, szablony cachowane są już w formie funkcjonalnej, do której wystarczy już tylko wrzucić dane.

Trzeba jednak pamiętać że kompilator szablonów jest leniwy. Szablony budowane są tylko w określonych momentach:

1. Utworzenie nowego szablonu
2. Wykonanie edycji szablonu
3. Reczne przebudowanie cache stylu przez ACP
4. W ostatnim etapie instalacji

Jeśli dokonasz zmien w szablonie bezpośrednio w DB, ale nie wykonasz przebudowy cache w ACP, skrypt dalej będzie używać przestarzałych szablonów, bądź raczyć twoich użytkowników błędęm krytycznym.

<uni[$hello_world]/>

Ostatnią zmianą w szablonach uniBoard są tagi. Tagi to specjalne słowa-klucze, które podczas kompilacji zamieniane są na specjalne odpowiedniki. O ile poprzednio parser doszukiwał się tagów wszędzie gdzie mógł, o tyle kompilator nie jest już taki chętny do zgadywania, co autor templaty miał namyśli umieszczając gdzieś jakiś tag.  Zamiast tego kompilator odróżnia surowy html od tego co ma być skompilowane w taki sam sposób jak parser (np.) php.

Zasada jest prosta. Pierw w szablonie wyszukiwany jest kod który ma zostać skompilowany. Kod ten jest rozpoznawany właśnie wtedy, kiedy znajduje się między <uni[ a ]/>. Następnie następuje sprawdzenie, czy w tagu znajduje się struktura warunkowa, zwykła zmienna, czy funkcja(e).  W zależności od sprawdzenia, zawartość tagu zostanie skompilowana inaczej. Jeśli tag zawiera tylko jakąś wartość, zostanie ona zastąpiona kodem php odpowiedzialnym za jej zwrócenie. Jeśli instrukcję warunkową, ta zostanie zastąpiona odpowiednią pętlą, zaś warunek zostanie przepisany tak, aby działał i niezawierał nieporządanego kodu. Gdy zostanie napotkany blok zawierający funkcje, te zostąną przetłumaczone na odpowiadający im kod php. Z różnych względów, zdecydowałem się nie implementować obsługi funkcji do warunków. I tak do niczego by się w nich nie przydały.

Porównanie

Na zakończenie zademonstruję dwa fragemnty kodu, demonstrujące wykorzystanie templat kiedyś, i dziś:


$this -> style -> loadTemplatesGroup( 'some_templates');
$template = new api_get_template( 'template_id');
$template -> registerValue( 'var_a', 3.14);
$template -> registerValue( 'var_boing_boing', 'Want to register?');
$this -> output -> addToOutput( $template -> drawTemplate());


I nowy kod:


$template = $this -> unisolutions -> style -> loadTemplate( 'some_templates');
echo $template -> template_template_id( array(
var_a' => 3.14,
'var_boing_boing' => 'Want to register?'
));
$this -> output -> drawFullOutput(); //metoda wykonywana na końcu generowania html przez akcję


Hello,

We have looked over software and we can tell that this is not our software, it does look as if some parts may have been inspired by our software but, ultimately all the code looks original.

If you have any other questions, please ask. Have a great day!

Nakisha Thomas
Invision Power Services
Director of Customer Satisfaction

http://rpiton.com/_work/old/Callisto/dark.jpg

Dla zainteresowanych powiem że na dzień dzisiejszy uniBoard generuje to samo + listę for ;)