PostgreSQL jest jednym z trzech najpopularniejszych wolnodostępnych systemów zarządzania relacyjnymi bazami danych. Zdecydowaliśmy się używać PostgreSQL między innymi dlatego, że poznaliśmy go dość dogłębnie podczas zajęć przedmiotowych kursu Bazy Danych. PostgreSQL jest systemem darmowym, istnieją obsługujące go darmowe programy interfejsowe jak również duże zaplecze informacyjne na temat użytkowania tegoś systemu. Wszystkie te czynniki przekonały nas, że wybór PostgreSQL będzie najrozsądniejszy. Instalacja: Pakiety niezbędne do przeprowadzenia instalacji oraz instrukcja znajdują się na stronie producenta: http://www.postgresql.org
Apache jest najszerzej spotykanym serwerem HTTP w internecie. W ramach realizacji projektu dostaliśmy konto na serwerze borg.ia.agh.edu.pl. Kontener Apache był już zainstalowany na serwerze.
Jest językiem skryptowym działającym po stronie serwera do dynamicznego generowania stron internetowych. W naszym projekcie jest warstwą pośrednią pomiędzy bazą danych a klientem korzystającym z naszego systemu. Korzystamy z wersji PHP5. Strona producenta: http://www.php.net/downloads.php
Język Znaczników Hipertkestu (HTML) oraz Kaskadowe Arkusze stylów (CSS) stanowię warstę prezentacji
System Rewersy ma trójwarstową architekturę
Logiczny oraz konceptualny opis systemu znajduje się w dwóch wcześniejszych częściach projektu: części konceptualnej oraz części Logicznej.
Pierwszy kontakt z system REWERSY to panel logowania. Jest to standardowy panel z polem na login i hasło. Hasło trzymane jest w bazie danych w postaci zaszyfrowanej algorytmem kryptograficznym md5. Następne podstrony dostępne są tylko dla zarejestrowanych użytkowników. Jedyną szansą osoby niezarejestrowanej jest otrzymanie zaproszenia przez inną osobę już zarejestrowaną. Po poprawnym zalogowaniu użytkownik jest przekierowywany do strony głównej systemu zawierającej listę dostępnych opcji oraz pole z treścią zmienną.
Pierwszą opcją w Menu jest możliwość zaktualizowania profilu. Często zdarza się że użytkownik zmienia nazwisko (np. kobieta po ślubie) lub zmieniany jest e-mail lub miejsce pracy na AGH, dlatego też opcja aktualizacji profilu jest niezbędna dla utrzymania spójności danych.
Zabezpieczeniem przed atakiem jest podanie starego hasła żeby wprowadzić jakiekolwiek zmiany w profilu.
Tuż po zalogowaniu jak i po kliknięciu w „Twoje Książki” pojawiają się dwie tabelki. Pierwsza z nich listuje Książki, których właścicielem jest zalogowany użytkownik: tytuł, rok wydania, wydawnictwo, autor (autorzy), opcje oraz uwagi. Książki te użytkownik dodał samodzielnie, tzn. wprowadził ich dane do formularza dodawania książek - jest od dostępny po kliknięciu w napis „Dodaj Książkę”, ponad tabelkami. W kolumnie 'opcje' mamy do dyspozycji trzy możliwości: usunięcie własnej książki (pod warunkiem że nie jest nikomu wypożyczona), edycję książki oraz pożyczenie jej komuś. Należy podkreślić fakt, że finalnym potwierdzeniem pożyczenia książki w naszym systemie jest potwierdzenie pożyczenia zatwierdzone przez użytkownika będącego właścicielem książki. Oznacza to, że tylko użytkownik będący właścicielem książki może ją zaznaczyć jako pożyczona w systemie. Oczywiście, chętny do pożyczenia może zarezerwować daną książkę jednak, ostatecznie, musi udać się po nią do właściciela. Właściciel na swoim profilu, w systemie REWERSY, markuje tą książkę jako pożyczona i od tej chwili książka jest pożyczona według systemu REWERSY.
Informacje o osobach, które pożyczyły bądź zarezerwowały książkę, data pożyczenia oraz możliwość odrzucenia/akceptacji rezerwacji jest możliwa w kolumnie 'Uwagi'.
Poniżej tabeli 'Twoje Książki' znajduje się tabela z listą książek pożyczonych przez użytkownika, wraz ze szczegółami: tytuł, rok wydania, Wydawnictwo, Autor, Właściciel oraz Status. Status książki to data jej pożyczenia. Data ta subtelnie przypomina użytkownikowi, żeby nie przekroczył, umówionego wcześniej, terminu zwrotu.
Tabela prezentuje listę wszystkich książek dostępnych w systemie. Wyglądem przypomina tabelę „Twoje Książki”.
Na powyższym rysunku przedstawiona jest tabelka zaproszonych użytkowników przez zalogowaną osobę, po kliknięciu w opcję „Usuń użytkownika”.
Jak wspomniałem wcześniej. Użytkownik zapraszający ma możliwość usunięcia z systemu użytkownika przez siebie zaproszonego. Eliminuje to konieczność istnienia głównego administratora, który odpowiedzialny byłby za usuwanie użytkowników - z różnych, nieistotnych w tej chwili, przyczyn. System bez głównego administratora możemy nazwać systemem webowym rozproszonym. Każdy z użytkowników jest po trosze administratorem, odpowiedzialnym nie tylko za swoje pozycje biblioteczne oraz pożyczone książki ale także za istnienie kont użytkowników przez siebie zaproszonych.
Hierarchia zaproszeń przedstawią się w formie drzewa. U korzenia drzewa znajduje się osoba posiadająca PIERWSZE konto w systemie, która zaprosiłą kolejnych użytkowników. Ci, którzy zostali zaproszeni tworzą liście tego drzewa, więc kolejne jego warstwy. Konto losowego użytkownika może zostać usunięte przez tego, który go zaprosił - znajdującego się o jedną warstwę niżej w Drzewie Zaproszeń. Najlepiej zobrazuje tą sytuację poniższy schemat fragmentu Drzewa Zaproszeń w momencie usuwania jednego użytkownika, w tym przypadku tego z nr2 (są dwie możliwości: albo sam usuwa swoje konto, albo jego konto jest usuwane przez użytkownika 1). Aby użytkownicy nr3 i nr4 nie „wisieli w powietrzu”, tzn żeby Drzewo Zaproszeń miało wciąż spójną formę, to użytkownik 1 musi przejąć po numerze2 - numery3 i 4. W tej chwili nr1 mógłby teoretycznie usunąć również konto nr3 i nr4.
Jeśli użytkownik zdecyduje się usunąć własne konto, ma taką możliwość po kliknięciu w zakładkę „Usuń swoje konto”. Jest jeszcze proszony o potwierdzenie tego. Po wciśnięciu 'tak' operacji już nie można cofnąć. Konto zostaje usunięte wraz z książkami, które dany użytkownik posiadał i udostępniał w systemie Rewersy. Jego rezerwacje oraz rezerwacje na jego książki zostają również usunięte zostają również usunięte.
Każdy użytkownik systemu ma możliwość zaprosić tyle nowych osób, ile chce. Nie wprowadzaliśmy tutaj żadnych limitów. Musi on tylko wypełnić formularz zaproszeniowy. Po prawidłowym jego wypełnieniu na skrzynke mailową gościa zostaje wysłany e-mail. Treścią maila jest informacja do jakiego systemu został on zaproszony, kto go zaprosił oraz jakie są dalsze etapy procesu rejestracji. W e-mailu znajduje się również unikalny URL, który jest generowany specjalnie dla tego gościa, i po kliknięciu którego zostaje wyświetlony formularz rejestracyjny.
Gdy gość poprawnie się zarejestruje powyższy URL jest usuwany z bazy danych, przez co nie jest możliwe użycie tego samego URL rejestrującego więcej niż jeden raz.
Po głębszym zastanowieniu możnaby dojść do wniosku że system stworzony przez nas jest systemem zbyt „luźnym”. Oznacza to że pojedynczy użytkownik ma dość duże prawa, począwszy od usuwania użytkowników przez siebie zaproszonych skończywszy na zapraszaniu teoretycznie nieskończonej liczby nowych użytkowników. Taka cecha systemu jest pożądana w społecznościach o wysokim stopniu wzajemnego zaufania. Uznaliśmy że społeczności naukowe AGH są dopowiednie dla tego typu systemu. Należy również wziąć pod uwagę fakt, że system Rewersy jest systemem tylko pomocniczym, eliminującym pewien chaos w wymianie książkowej pracowników naukowych ale nie narzucającym dodatkowych, często zbędnych, reguł lub procedur postępowania przy wymianie książkowej.
Oczywiście nasza ocena środowiska działania systemu jest czysto subiektywna, niekonsultowana z większą grupą pracowników naukowych AGH. Dlatego też zakładamy możliwość zmiany podejścia do problemu i nieco ulepszenia naszego systemu w przyszłości.
Ogólnie rzecz biorąc wersja finalna naszego projektu jaką opisujemy w tym raporcie jest wersją 2.0. Pierwsza wersja (1.0) nie była projektowana „od zera” lecz miała bazować na kodzie źródłowym popularnego oprogramowania do dokumentacji - Dokuwiki.
Dokuwiki jest oprogramowaniem typu wiki. Oprogramowanie typu wiki jest to nazwa specyficznych stron internetowych, które można nie tylko oglądać, ale też tworzyć, edytować i zmieniać bezpośrednio za pomocą przeglądarki internetowej.
Wszelkie informacje zgromadzone w Dokuwiki trzymane są w plikach tekstowych. Do działania systemu nie jest potrzebna baza danych.
Uznaliśmy wspólnie z opiekunem projektu, że jest możliwe przerobienie kodu źródłowego Dokuwiki w ten sposób, by jako back-end stworzyć bazę danych współpracującą z systemem Dokuwiki, zamiast plików tekstowych.
Udało nam się odnaleźć plugin do dokuwiki o nazwie „PostgreSQL Authentication Backend”:
http://www.dokuwiki.org/auth:pgsql . Pozwalał on na trzymanie listy użytkowników oraz danych osobowych i haseł w bazie danych, która byłaby obsługiwana przez Dokuwiki. Mimo że obsługę logowania/wylogowywania z Dokuwiki za pomocą back-end'u PostgreSQL udało nam nam się stworzyć, to napotkaliśmy dużo problemów z wkomponowaniem reszty bazy danych naszego systemu w architekturę Dokuwiki. Poza tym wymagało to bardzo dużo zmian w samym kodzie źródłowym PHP, który był ewidentnie przystosowany do obsługi plików tekstowych a nie do współpracy z bazą danych.
Zamiast zmieniać większość kodu PHP silnika Dokuwiki postanowiliśmy, że prostszym rozwiązaniem będzie napisać „od zera” obsługę bazy danych za pomocą PHP. Dużo rozwiązań zaczerpnęliśmy z Dokuwiki czyniąc te systemy podobne w działaniu. Na przykład komunikacja między plikami .php jest podobna do tej z Dokuwiki:
Podczas realizacji projektu każdy z nas zapoznał się z obsługą serwera Apache, serwera bazy danych PostgreSQL oraz dogłębnie poznaliśmy programowanie w języku PHP. Doceniliśmy też pracę w grupie w celu rozwiązywania problemów nierzadko skomplikowanych i wymagających różnych punktów widzenia. Wykonanie zajęło nam dużo czasu. Głównym tego powodem było zrezygnowanie z kontynuowania tworzenia wersji 1.0 - opartej o Dokuwiki. Zmiana podejścia zmusiła nas do przemyślenia od nowa naszej koncepcji oraz restrukturyzacji naszego kodu co wiązało się oczywiście z nakładem czasowym.
Oceniamy doświadczenia zdobyte w trakcie realizacji projektu bardzo pozytywnie. Całkowita zmiana podejścia do pewnych spraw, bycie elastycznym i umiejętność dostosowania się do sytuacji są dzisiaj cechami bardzo pożądanymi. Projekt ten nauczył nas modyfikacji oraz dostosowywania naszych celów do aktualnych możliwości oraz posiadanego kapitału.
System Rewersy jest wciąż w bardzo młodej wersji i wymaga dużej ilości, na pierwszy rzut oka nieznaczących, poprawek.
Po pierwsze, należy rozważyć problem, czy system nie jest zbyt „luźny” dla społeczności naukowej AGH? Może powinny zostać uwzględnione np. jasne kary za nieoddanie książki w terminie, lub obostrzenie pewnych akcji, np. podanie dokładnego powodu, dlaczego użytkownik jest usuwany z bazy - nadzorowane przez kogoś.
Należałoby również ulepszyć wyszukiwarkę książek w systemie, dodać kategorie, dodać różne opcje wyszukiwania.
Zmiany te należałoby wprowadzić dopiero po dokładnych rozmowach z pracownikami naukowymi AGH a także testach systemu REWERSY przy dużym obciążeniu ruchu na serwerze.
