Wymagania dotyczące projektów

Technologia

Projekt należy wykonać w technologii Ruby on Rails, możliwe jest łączenie z innymi technologiami jak flash, flex. Wykonany serwis należy zainstalować na wierzbie, w związku z czym należy dostosować wersję RoR do dostepnej na serwerze (lub zastosować zamrażanie wersji).

Dokumentacja

Dokumentację należy dostarczyć razem ze źródłami projektu, umieszczając ja w katalogu doc. Dokumentacja obejmuje:
  • opis funkcjonalności systemu
  • opracowanie wyników "peer testów"
  • instrukcję instalacji i uruchamiania w przypadku nietypowym (patrz niżej)

Typowa instalacja i uruchamianie

O ile nie opisano nietypowego sposobu instalacji i uruchamiania, aplikacja powinna wymagać do uruchomienia następujących kroków:
  1. założenie bazy danych o nazwie 'nazwisko_imie'. Dostarczony plik database.yml w sekcjach development i production powinien zawierać domyślne wpisy dla bazy o takiej nazwie, to znaczy: 
    
  adapter: mysql
  database: nazwisko_imie
  username: root
  password:
  host: localhost
  encoding: latin2
    Jako domyślne kodowanie bazy przymujemy latin2, takie jak na wierzbie. Jeśli korzystamy z bazy w utf8 lub innym kodowaniu, informacja o tym powinna się znaleźć w instrukcji instalacyjnej.
  2. uruchomienie migracji za pomocą polecenia rake db:migrate. Migracje tworzą strukturę bazy danych oraz dodają do bazy danych dane niezbędne do prawidlowego działania systemu, takie jak wartości tabel słownikowych (kategorie, statusy itd) i dane predefiniowanych użytkowników.
  3. uruchomienie serwera. Wszelkie dodatkowe biblioteki (np. rmagick, ferret, sphinx) potrzebne do działania serwisu muszą być wymienione w instrukcji instalacyjnej.
  4. uruchomienie serwisu w przeglądarce pod domyślnym url'em (np. localhost:3000, powinno nastąpić przekierowanie do strony głównej)
  5. dla serwisu wymagającego logowania przyjmujemy, że predefiniowany super użytkownik loguje się za pomocą admin/admin, a użytkownik zwykły user/user. Jeśli serwis przewiduje większą ilość ról użytkowników, informacja na temat ich danych musi znaleźć się w instrukcji instalacji.

Elementy podlegające ocenie

  1. błędy
    • błędy w standardowym działaniu systemu
    • błędy użytkownika. System powinien być odporny na wprowadzanie błędnych danych -- brak wypełnionych pól, wprowadzenie danych złego typu czy niedozwolonej długości, błedy typu "data od" późniejsza niż "data_do" itd.
    • błedy złośliwego użytkownika. System powinien byc przygotowany na próby obejścia zabezpieczeń, uzyskania dostępu do danych nieistniejących i typowe ataki (sql injection, xss)
  2. jakość
    • jakość schematu bazy danych. Odejście od schematu znormalizowanego musi mieć uzasadnienie.
    • jakosć modelu obiektowego. Należy starać się korzystać z dziedziczenia zamiast definiować wiele podobnych klas (np. kategoria, podkategoria), unikać mieszania różnych dziedzin w jednej klasie, obiekty powinny mieć zrozumiałe atrybuty i metody.
    • jakość kodu. Unikać długich metod, duplikacji, stosować komentarze. Starać się stosować spójne nazewnictwo, w szczególności nazwy metod i zmiennych muszą być zrozumiałe, lepiej tez unikać mieszania nazw polskich z angielskimi.
  3. interfejs
    • spójność. Starać się stosować jednolity schemat kolorystyczny, czcionki, elementy formularzy, nawigację
    • odporność na użytkownika. Strona nie może się rozjeżdzać w przypadku wprowadzenia przez użytkownika zbyt długiego napisu czy niewymiarowego obrazka.
    • czytelność. Wszystkie napisy muszą być widoczne (rozmiar czcionki, tło) oraz poprawne ortograficznie
    • wszystkie komunikaty i opisy muszą być w jednym języku (również komunikaty związane z walidacją danych)
    • należy stosować się do zasad ergonomii i projektowania interfejsów poznanych na wykładzie
    • serwis na 5.0 musi zawierać atrakcyjne elementy interfejsu, takie jak techniki AJAX, efekty javascript czy łączenie z komponentami flash. Należy przy tym zachować umiar i odpowiednią proporcję wodotrysków do funkcjonalności.