# Projekt Beirut

[TOC]

## Q & A

#### Ile mamy czasu na specyfikacje (kiedy musisz mieć kwoty do grantu?)

#### Czy użytkownikami systemu są tylko pracownicy PCPM względnie osoby z nimi współpracujące. Czy również sami potrzebujący? (pewnie tylko PCPM?)

## Uwagi do specyfikacji

Specyfikacja projektu.

Przedmiotem zamówienia jest utworzenie bazy danych (typu: MySQL albo PostgreSQL) wraz z instalacją serwera na danym komputerze i przygotowanie internetowego frontendu do tej bazy danych.

> [name=Jan Kaczorowski] ja to widzę tak: PostgreSQL + API w Rails + Klient Web

Baza danych powinna zawierać następujące dane:
1. Dane osobowe rodzin objętych pomocą humanitarną wraz z ich aktualnym statusem: a więc imię, nazwisko głowy rodziny, ilość osób, status majątkowy, adres zamieszkania, rodzaj pomocy, komentarze (możliwość dodania kilku komentarzy do jednej rodziny).
2. Wśród danych osobowych wyróżniamy dane wrażliwe, do których dostęp będzie ściślej kontrolowany. Rozdział danych na zwykłe i wrażliwe może być realizowany z poziomu API, ale można też np. Utworzyć dwie osobne tablice dla każdej rodziny, z których jedna będzie zawierała dane.
> [name=Jan Kaczorowski]jestem za opcją #1 czyli kontrolowany przez API. Dzielenie danych wg. wrażliwości wygląda na antypattern
3. Adresy rodzin, w tym adresy w których zamieszkiwały poprzednio. Informacje o warunkach lokalowych.
> [name=Jan Kaczorowski] czyli 'Family has many Addresses, z czego 1 jest aktualny'

5. Dane dotyczące numerów kart pre-paid, przypisanych do konkretnej rodziny.
> [name=Jan Kaczorowski] Trzeba pomyśleć jak zdefiniujemy kartę pre paid. Czy numer ma standard (na pewno ma). Czy trzeba kontrolować jej limit?
6. Historię zmian.
> [name=Jan Kaczorowski]czy rodzina ma na raz więcej niż 1 kartę?
7. Dane dotyczące użytkowników bazy danych, w tym możliwość ustalenia, który użytkownik dokonał której zmiany. Lista urządzeń (MAC address) z których mogą się logować użytkownicy.
> [name=Jan Kaczorowski] luzik. Traf chcę, że teraz projektuję taki Access control.
8. Notatki po wywiadzie na temat konkretnej rodziny.
9. Daty kolejnych, planowanych wizyt rodziny.
10. Raporty z wywiadu pracowników.
> [name=Jan Kaczorowski] tekst czy tekst + multimedia (to można wyjaśnić później)
11. Dane dotyczące pracowników PCPM, którzy będą jeździli po kraju i dokonywali wywiadów. W szczególności, które rodziny ma dany pracownik pod opieką i kiedy je odwiedza.
12. Baza danych powinna zawierać treści w języku angielskim, jednak wymagane kodowanie to UTF8, aby można było dodawać treści w innych językach (np. arabskim).
> [name=Jan Kaczorowski] na szczęście nikt poważny nie robi tego już inaczej niż w UTF-8.

Liczba rodzin objętych pomocą jest rzędu kilku tysięcy, liczba osób mających dostęp do bazy jest rzędu kilka. PCPM ma możliwość przechowywania i operowania danymi wrażliwymi w zgodzie z ustawą o ochronie danych osobowych.

Front-end powinien mieć następujące funkcje.

1. Podział danych na dane ogólne (dostępne szerszemu gronu) i dane wrażliwe. Dostęp do pól określonych jako wrażliwe wymagałby dodatkowego uwierzytelnienia.
2. Uwierzytelnienie, w przypadku dostępu do danych wrażliwych, dwustopniowe, to znaczy hasło + MAC address urządzenia. Dodawanie nowego urządzenia może być wykonywane ręcznie.
3. Przeglądanie danych dotyczących rodziny wraz z historią.
4. Dwa rodzaje wyszukiwań:
• Wyszukiwanie szybkie, dotyczące kilku najczęściej stosowanych rodzajów wyszukiwań, na przykład: lista rodzin pozostająca do odwiedzenia w ciągu danego dnia, albo w zakresie kilku dni, lista rodzin, którym należy zasilić kartę pre-paid w najbliższym czasie itp.
• Wyszukiwanie „zaawansowane” a więc wyszukiwanie obiektów (rodzina, pracownik, adres, karta pre-paid) spełniających ustalone kryteria (do 6 kryteriów).
• Hyperlinki przy wynikach wyszukiwania, na przykład przy wyszukaniu rodzin, kiedy wyświetlą się adresy, kliknięcie na adres generuje nowe wyszukiwanie.
• Integracja niektórych wyników wyszukiwania z google maps, na przykład: wyświetlenie adresów rodzin na mapie, możliwość wyszukiwania adresów w ustalonej odległości od danego punktu, możliwość pokazywania na mapie listy rodzin do odwiedzenia przez danego pracownika.
> [name=Jan Kaczorowski]
• Sortowanie wyników wyszukiwania, przy czym nie wymagamy sortowania po danych tekstowych w języku innym niż angielski.

5. Eksport wyników wyszukiwania do formatu XML, w szczególności generowanie raportów w XML.
> [name=Jan Kaczorowski] o! To bardzo ciekawe! Kto potrzebuje raportów w XML. Don't get me wrong. To kaszka z mleczkiem, zastanawiam się tylko kto tak operuje.
6. Możliwość zassania danych z XML (wystarczy do tego skrypt w języku skryptowym typu PHP, Python, nie musi to być robione z poziomu strony internetowej).

8. Działanie w przeglądarkach Firefox, Opera, Chrome, Safari. Możliwość otwarcia i przeglądania bazy danych z poziomu tabletu lub smartfona.
> [name=Jan Kaczorowski] ^ to istotny czynnik kosztowy, bo to oznacza responsywne widoki, czyli po prostu dość czasochłonne, żeby wyglądały wszędzie dobrze.

9. Możliwość dodawania rekordów i edycji z poziomu przeglądarki.
10. Działanie "lightweight", to znaczy możliwie mała ilość dodatkowych elementów w przeglądarce, umożliwiająca przeglądanie przy powolnym łączu internetowym.
> [name=Jan Kaczorowski] w modelu API + Klient webowy komunikacji nie będzie (o ile się rzecz zrobi sensownie) dużo, o ile tylko layout zrobi się prosty i bez zbędnej grafiki. Można też cache-ować część layoutu w przeglądarce (ale nie dane, na Jowisza!) i tą drogą mieć trochę szybciej.
11. Przeglądanie historii zmian, wraz z możliwością cofnięcia zmian przez administratora.
12. Możliwość pracy off-line z załadowaniem danych później.
> [name=Jan Kaczorowski] to też spory czynnik kosztowy (i komplikator). Plus trochę kłóci się z ideą bezpieczeństwa. Bo jak ma działać offline, to znaczy, że dane będą w cache przeglądarki użytkownika :/
13. Możliwość dodania dodatkowej funkcjonalności w przyszłości.
Wymagane jest brak stosowania oprogramowania "closed source" przy tworzeniu front-endu. // <- that's the spirit.

#### Konkluzje

można rozważyć podzielenie projektu na etapy np.

1. Baza danch + część API z ACL + część Klienta Webowego
2. Rozszerzenie API + reszta klienta Webowego (bez offline i responsywności) + Raporty XML i takie cuda
3. Responsywność i offline (jeśli konieczny :/). Przy czy może się okazać, że tańsza i efektywniejsze jest zrobienie prostej aplikacji mobilnej na IOS i Android niż responsywną aplikację na wszystkie platformy. Czar tabelek....