Autorskie frameworki do PHP - część 3. Wydajność i bezpieczeństwo

1. Autorskie frameworki do PHP - część 1. Wstęp
2. Autorskie frameworki do PHP - część 2. Użytkownicy
3. Autorskie frameworki do PHP - część 3. Wydajność i bezpieczeństwo

User to nie wszystko..... Pewnie, że nie!

Nasz system musi spełniać wymagania z innych zakresów niż UX. Musi być wydajny i bezpieczny. Zagrażają mu ataki zarówno ze strony hakerów, jak i zwykłych użytkowników uzbrojonych w ilość maszyn i jednoczesnych połączeń. Pierwsza kwestia często jest lekceważona. Przecież hakerzy są tylko na filmach i w książkach Stiega Larssona. Nie jest to jednak prawda. Fakt, "włamania" na strony sklepów internetowych i zmiany cen wszystkich sprzedawanych produktów na 1PLN, to zwykle dzieło niezadowolonego pracownika zwolnionego 3 dni wcześniej. To niewiele ma wspólnego z hakerami. Co innego jest w przypadku stron dużych instytucji takich jak uczelnia. Tu częściej możemy mieć do czynienia z prawdziwymi atakami, gdyż włamania do takich systemów są zwykle powodem do dumy i dają parę punktów do szacunku w "środowisku". Przy projektach tego typu i takiej skali wiele pracy należy włożyć w bezpieczeństwo.  Dodatkowo pamiętajmy, że budujemy sporą bazę danych osobowych, zatem podlegamy kontroli GIODO!

Wydajność jest równie ważna. Dla kandydata na wymarzony kierunek na wymarzonej uczelni dzień publikacji wyników rekrutacji to najważniejszy dzień w życiu (przynajmniej tak mu się wówczas wydaje). Nic więc dziwnego, że jeśli obiecano mu wyniki rekrutacji 5 lipca o 12:00, to on i 100 000 jego kolegów wejdzie na stronę już o 11:55, by sprawdzić czy się dostał. Potem odświeży tę stronę jeszcze 100 razy by być pewnym, że nie śni, lub by pochwalić się babci. Taki "pik" potrafi zaskoczyć zarówno programistów i adminów, jak i nawet same serwery (nawet te od dużej mocy).

Niestety w przypadku każdego projektu musimy brać pod uwagę jego koszty. Liczą się licencje i opłaty za wsparci czy szkolenia. Lwią część zawsze stanowi koszt programistów, testerów i obsługi systemu. Musimy również zakładać ewentualne koszty związane z wystąpieniem błędów, które nie zostaną wykryte podczas testów, a mogą narazić nas na dodatkowe koszty takie jak odszkodowania czy koszty sądowe.

Mamy już podstawowy zasób wiedzy, potrzebny do podjęcie decyzji o wyborze frameworku, z pomocą którego będziemy realizować nasz projekt. Czas podjęć decyzję...

Rozważając wszystkie aspekty przedstawione przeze mnie wcześniej decyduję się na niewątpliwie droższe i bardziej pracochłonne rozwiązanie (przynajmniej w początkowym okresie), czyli na autorski framework. Projekt jaki będziemy tworzyć musi być bardzo elastyczny. Musi dać się dostosować do różnych grup użytkowników jak i umożliwiać szybkie dostosowanie do zmian prawa i przepisów uczelni. Technologie muszą nam stawiać jak najmniejszy opór i musimy posiadać odpowiednią kadrę fachowców. Zacznijmy od warstwy najniższej, czyli wybierzmy system operacyjny na jakim oprzemy nasz projekt. Ze względów politycznych warto by zdecydować się na platformę opensource. Jest w dobrym tonie jeśli uczelnie i urzędy promują właśnie takie rozwiązania. Dodając do tego wysoce wyspecjalizowaną kadrę fachowców od systemu linux wybór wydaje się oczywisty. Wybrana dystrybucja nie wydaje się,  istotna w kontekście niniejszego artykułu. Kolejna kwestia to baza danych. MSSQL możemy skreślić od razu, z racji wybranego przez nas systemu jak i z powodów politycznych (podobnych jak w przypadku OS). Z powodu kosztów jak i licencji musimy również zrezygnować z produktu firmy Oracle. Pomimo, iż przy gabarytach system jest to wybór dość oczywisty. Na placu boju pozostały jeszcze dwa systemu bazodanowe: MySQL i PostgreSQL. Inne systemu nie są rozważane z powodu braku kadry potrafiącej je obsługiwać. W tym przypadku wybór jest chyba oczywisty. Moim zdaniem Postgres znacznie lepiej nadaje się do użytku w dużych systemach. Mając już dwa istotne elementy naszej platformy. Przychodzi pora na język programowania oraz serwer www.  Mamy zatem alternatywę Java i PHP. Java jest trendy, ale jednocześnie jest dość ciężka i wiele wymaga zarówno od programistów jak i od serwerów. Wiem, wiem! Znam statystyki i testy porównawcze wydajność Javy i pehapa. Tylko jestem praktykiem, a w praktyce PHP ma mniejsze wymagania. I kropka. 

Mamy zatem wybrany język programowania. Łatwy, niezbyt wydajny, ale da się jakość żyć. Do tego Apache jako jedyny słuszny serwer (ten pogląd jeszcze skorygujemy w przyszłości). Mamy chyba komplet. Teraz czas na framework. Mamy Symfony, Zend'a czy CakePHP, jak i wiele innych. Są darmowe (lub nie bardzo drogie). Ale stawiają nam pewne wymagania i ograniczenia. Własne rozwiązanie możemy bardzo mocna dostosować do wybranej przez nas platformy i silnika bazy danych jak i do specyfiki projektu. Dodatkowo możemy już na etapie projektowanie zaplanować szkolenia i dokumentacje co ułatwi nam rekrutacje programistów. Wystarczy, że znajdziemy dobrego programistę PHP i poświęcimy na jego szkolenie kilka dni. A powinien dobrze sobie radzić w naszym projekcie. Koszt własnego rozwiązania będzie oczywiście znacznie wyższy niż zakup licencji czy użycie produktów darmowych. Jest to jednak koszt o charakterze inwestycji. Taka instytucja jak uczelnie może z czasem sprzedać cały projekt systemu jak i sam framework. Co pozwoli na obniżenie kosztów budowy frameworku, a niekiedy może nawet okazać się dochodowe.

Znamy już powody wyboru własnych rozwiązań dla PHP. Poznaliśmy również zasady i argumenty brane pod uwagę podczas podejmowania takiej decyzji. Rozumiemy też cześć wymagań jakie nasze rozwiązanie ma spełniać i wiemy jakie zadania będą przed nim stawiane. W kolejnych artykułach postaram się przedstawić proces powstawania takiego właśnie frameworku. Jako przykład posłuży mi niekomercyjny framework zwany: silnikiem, którego jestem współautorem oraz kilka innych autorskich rozwiązań z jakimi miałem okazje pracować. Postaram się pokazać pułapki w jakie można wpaść, problemy i ich rozwiązania.

Mam nadzieje, że uda mi się pójść również o krok dalej i pokazać jak można wykorzystać darmowe rozwiązania takie jak Postgres, PHP czy linux by budować szybkie, bezpieczne i łatwe w rozbudowie systemy informatyczne na dużą skalę.

Autorskie frameworki do PHP - część 2. Użytkownicy

1. Autorskie frameworki do PHP - część 1. Wstęp
2. Autorskie frameworki do PHP - część 2. Użytkownicy
3. Autorskie frameworki do PHP - część 3. Wydajność i bezpieczeństwo

Rozważmy teraz kwestie użytkowników....
Projektując każdy system informatyczny największą wagę należ poświęcić właśnie tej kwestii. Pamiętajmy, że to właśnie dla userów tworzymy nasze tkownidzieło. Zwykle systemy elektroniczne mają pewne grupy użytkowników. Grupy, te charakteryzują się zwykle pewną pulą cech wspólnych. Zazwyczaj będą to uprawnienia lub cele w jakim używają naszego system. Nasz przykładowy projekt nie różnie się w tej kwestii od innych. Już po wstępnej analizie możemy wyodrębnić trzy podstawowe grupy użytkowników. Spróbujmy je zatem nazwać i scharakteryzować.

1. Kandydaci na studia. Grupa potencjalnie najbardziej oczywista. Ludzie młodzi i inteligentni mający duże doświadczenie w użytkowaniu komputerów - Dzieci Neo - czyli superuserzy... ale czy na pewno? :D Okazuje się, że kandydat na studia nie zawsze daje się tak łatwo "zaszufladkować". Zwróćmy uwagę, że na studia idą osoby w różnym wieku. Oczywiście przytłaczającą większość stanowią tegoroczni maturzyści, ale przy projektowaniu systemu znacznie większą wagę powinniśmy zwrócić na przypadki, rzadkie i bardzo rzadkie, niż na te pospolite. Dlaczego? To proste, osoby ze schematu to znany nam przypadek i raczej nie zapomnimy o jego potrzebach. Osoby odstające od schematu to przypadki trudne, najmniej nam znane i mało przez nas rozumiane. Łatwo więc będzie nam pomylić się czy zapomnieć o pewnych drobiazgach - w artykułach z tego cyklu wrócę jeszcze do tej kwestii - więc zapamiętajmy ją sobie. Wracając do naszych kandydatów. Tworzymy system dla ludzi posługujących się biegle komputerami i dla osób, które nie wiedzą w jaki sposób zmusić komputer do wyświetlenia wielkiej litery bądź litery "ś", że o "ź" nie wspomnę. Będą to ludzie w wieku 18 jak i 55 lat. Mieszkańcy miast (którzy często nie znają nazwy gminy w jakiej mieszkają) jak i mieszkańcy wsi (w których nie mamy nazw ulic, czy numerów mieszkań). Będą to osoby nieprzeciętnie inteligentne jak i takie, które ukończyły prywatną szkołę jedynie dlatego, że "ich tatuś tę szkołę kupił". Generalnie pełne spektrum naszego społeczeństwa :)
2. Pracownicy uczelni obsługujący system. To również bardzo ciekawa i zaskakująca grupa. Nazwijmy sobie tę grupę dla ułatwienia "wsparciem". Nasi pracownicy to powiedzmy: 3-4 pracownice jednego z działów naszej uczelni. Powiedzmy że, są to osoby w wieku lat 45+. Powiedzmy że, nie potrafią się posługiwać komputerem i nie są zbyt chętne do nauki nowych rzeczy czy podejmowania zawodowych wyzwań - typowi urzędnicy wychowani w poprzednim systemie. Resztę wsparcia stanowią informatycy: bazodanowcy, programiści i administratorzy systemu. Większość z nich jest przekonana o swojej nieomylności oraz wyższości nad resztą społeczeństw, a ich cenny czasz jest marnotrawiony przez błahe problemy maluczkich. Co bardzo istotne ich czas faktycznie jest cenny, gdyż takie osoby często zarabiają więcej niż urzędnicy. Ostatnia podgrupa to "pracownicy sezonowi". Osoby przychodzące do pracy wyłącznie w okresie największej ilości pracy do wykonania mające pomagać etatowym pracownikom wsparcia. Jak każdy zbieracz ogórków, nie mają odpowiedniego wykształcenia, doświadczenia i kwalifikacji. Nie możemy im do końca ufać, gdyż zwykle nie możemy wyciągać konsekwencji za ich czyny. Nie możemy również od nich wymagać zbyt wiele, bo przyszli tu tylko na chwilkę i za moment lecą dalej.
3. Komisje rekrutacyjne. Grupa użytkowników składające się wyłącznie z naukowo-dydaktycznych pracowników uczelni. Jednak do samej obsługo systemu oddelegowywane są osoby o najniższych tytułach naukowych/zawodowych o najkrótszym stażu na uczelni. Zwykle jest to doktorant nie mający dość silnej pozycji jak ich dość odwagi by sprzeciwić się swoim przełożonym profesorom będącym przewodniczącymi komisji rekrutacyjnych. Te osoby jednak mają dość odwagi i przekonania o swej silnej pozycji by wymagać "niemożliwego" od pracowników wsparcia :D.

Z grubsza to tyle co do userów naszej aplikacji. Ale pamiętajmy, że w skład projektu wchodzi również wybór frameworku. Zatem mamy potencjalnie jeszcze jedną grupę userów. Programistów, dbających o rozwój i utrzymanie naszej aplikacji. Tego typu projekty zwykle są rozwijane w sposób ciągły. Stale dokładane są nowe moduły i udoskonalane stare. Projekt musi być dostosowywanych do nowych przepisów oraz zasad rekrutacji. Np. ministerstwo wprowadza "Nową maturę" co zupełnie zmienin dotychczasowe podejście do pozyskiwania informacji o wynikach naszych kandydatów. Grupa ta powinna być zatem potraktowana w sposób szczególny. Istotne jest to z jaką łatwością będzie można wprowadzać zmiany do systemu lub lokalizować błędy. Jak również, to jak łatwo rekrutować nowych programistów, posiadających odpowiednią wiedzę i kwalifikacje. 

User to nie wszystko.....