Merge pull request 'uaktualniona dokumentacja' (#70) from s434723/DPRI_doc_20-21:master into master

Reviewed-on: bikol/DPRI_doc_20-21#70

Dyczkowski/niezbednik-studenta/dokument_wizji_projektu.md

@@ -0,0 +1,128 @@
+# Dokument wizji projektu
+
+**Niezbędnik Studenta**
+
+**Autorzy: Anna Śniadek, Malwina Chudzińska, Adrian Pacholak, Phillip
+Ławniczak**
+
+**Data: 28.10.2020**
+
+## 1. Wprowadzenie
+
+Dokument dotyczy projektu realizowanego w ramach zespołowego projektu
+inżynierskiego. Niniejszy dokument służy przedstawieniu przeznaczenia
+tworzonego systemu, jego głównych cech i przyjętych założeń.
+
+## 2. Cel
+
+Celem projektu jest ułatwienie studentom Wydziału Matematyki i
+Informatyki organizacji studiów. Studenci poświęcają dużo czasu na
+znalezienie informacji i pomocy naukowych dotyczących danego przedmiotu,
+które umieszczone są na wielu różnych portalach. Chcemy ułatwić
+studentom ten proces zbierając wszystkie te materiały uporządkowane w
+jednym miejscu. Platforma ma stanowić wsparcie naukowe dla studentów
+porządkując pomoce naukowe dostępne w Internecie i gromadząc materiały
+udostępniane przez użytkowników oraz kreować wspólną przestrzeń dla
+studentów ułatwiając im integrację i jednocząc w problemach związanych
+ze studiami.
+
+## 3. Rynek
+
+Serwis „Niezbędnik Studenta" zbiera wszystkie pomoce naukowe,
+zgromadzone przez studentów oraz udostępniane przez prowadzących na
+różnych portalach, w jednym miejscu.
+
+Stanowi alternatywę dla grup tworzonych przez studentów w serwisie
+„Facebook", który zbiera wiele informacji o swoich użytkownikach
+zbędnych z punktu widzenia oferowanych funkcjonalności. Dodatkową
+przewagą Niezbędnika Studenta jest łatwość znajdywania interesujących
+nas grup oraz ich jednoznaczny podział na przedmioty, dzięki czemu posty
+oraz materiały trafiają wyłącznie do grupy zainteresowanych danym
+przedmiotem osób.
+
+Informacje i materiały niezbędne dla studentów WMI są umieszczane na
+wielu stronach. Nie ma natomiast miejsca w sieci zawierającego wskazówki
+odnośnie wyszukiwania tych informacji ani zbierającego odnośniki do
+stron, na których są one umieszczane.
+
+Dużym atutem platformy jest fakt, że jest ona tworzona przez studentów
+dla studentów, co oznacza, że rozwój aplikacji jest uzależniony od tej
+jednej społeczności i ma na niego bezpośredni wpływ.
+
+## 4. Opis produktu
+
+-   Dostęp do serwisu dla studentów WMI po zalogowaniu w systemie
+    cas.amu.edu.pl
+
+-   Lista prowadzących i odnośniki prowadzące do ich stron
+
+-   Lista przedmiotów nauczanych na WMI
+
+-   Możliwość dodania się do **grupy przedmiotowej** w celu dostępu do
+    **strony przedmiotu**
+
+    -   możliwość udostępniania i korzystania z materiałów, notatek,
+        przykładowych zadań wraz z rozwiązaniami -- wszystkie materiały
+        dotyczące danego przedmiotu zostają zgromadzone w jednym miejscu
+
+    -   forum dyskusyjne
+
+    -   odnośniki do sylabusa i stron prowadzących
+
+    -   lista prowadzących przedmiot
+
+-   Użytkownicy mają możliwość inicjować wydarzenia w celu poszerzenia
+    grupy osób do wspólnej nauki lub znalezienia osób uczących się
+    samodzielnie na wydziale w celu integracji
+
+-   Możliwość poszukiwania korepetytorów w osobnej zakładce
+
+-   Możliwość tworzenia grup w celu znalezienia osób do zadań
+    grupowych/projektów
+
+-   Tablica ogłoszeń dla wydziału, stanowiąca miejsce na eventy, kursy,
+    oferty pracy
+
+- Pliki dodawane przez studentów będą grupowane ze względu na przedmiot,
+będą filtrowane pod kątem nazwy, tagów, podział na wykład / ćwiczenia.
+Użytkownicy mogą zgłosić brak przedmiotu w bazie przedmiotów jako błąd
+wysyłany do administratorów. Administrator ma uprawnienia pozwalające
+na zarządzanie (dodawanie / usuwanie / edycję) danymi (przedmiotami,
+prowadzącymi).
+
+- Administrator może nadawać uprawnienia administratora innym
+użytkownikom.
+
+- Administrator ma uprawnienia pozwalające na usuwanie treści (postów,
+komentarzy, plików) oraz banowanie użytkowników (użytkownicy połączeni
+są z kontem w Usosie). Użytkownicy mogą zgłaszać treści, które uważają
+za nieodpowiednie. Komentarze do postów z kategorii zadania można
+oznaczać jako proponowane odpowiedzi.
+
+- Użytkownicy mogą oznaczać komentarze o takim charakterze jako
+poprawne/niepoprawne.
+
+## 5. Zakres i ograniczenia
+
+W pierwszej wersji systemu po zalogowaniu w systemie cas.amu.edu.pl
+dostępny będzie podstawowy interfejs startowy użytkownika, lista
+przedmiotów i ich strony. Użytkownicy będą mieli możliwość dołączenia do
+grup przedmiotowych, udostępniania oraz wglądu do materiałów, udziału w
+forum. Ograniczenia na rozmiar udostępnianych multimediów.
+
+-   Aplikacja webowa
+
+-   Responsywna aplikacja dostosowana do korzystania na urządzeniach
+    mobilnych
+
+-   Technologie:
+
+    -   Baza danych - MySQL
+
+    -   Front-end - JavaScript, React
+
+    -   Back-end - Java, Spring, Hibernate, JUnit
+
+-   Ograniczenia rozmiar plików: 2 MB - jeden plik
+
+-   Ograniczenia rozszerzeń - jpg/png, txt, pdf, docx, doc, odt

Dyczkowski/niezbednik-studenta/dokument_wymagan_projektowych.md

@@ -0,0 +1,334 @@
+# Dokument wymagań projektu
+
+**Nazwa projektu: Niezbędnik Studenta**
+**Autorzy: Adrian Pacholak, Ania Śniadek, Malwina Chudzińska, Phillip Ławniczak**   
+**Data: 28.10.2020**
+
+
+
+## 0. Wersja dokumentu
+
+1.1 - 28.10.2020 - dostosowanie do nowego szablonu
+
+1.2 - 16.11.2020 - naniesienie poprawek wedłgu uwag promotora
+
+## 1. Elementy składowe projektu (produkty projektu) 
+
+### Aplikacja webowa
+
+   -   Zintegrowana z REST API - pobiera dane użytkowników, dane
+        zawarte w aplikacji
+
+   -   Dostępna dla użytkowników posiadających konto w systemie USOS
+
+   -   Zarządzana przez zespół administratorów składający się z
+        wybranych, zainteresowanych studentów
+   
+   -   Umożliwia zalogowanym użytkownikom
+
+        -   korzystanie z forum
+
+        -   dostęp do materiałów zamieszczanych przez użytkowników
+
+        -   udostępnianie plików
+
+        -   pozyskiwanie informacji dotyczących studiów
+
+   -   Dokumentacja dotycząca oprogramowania aplikacji webowej
+
+   -   Technologie:
+
+        -   JavaScript
+
+        -   React
+
+        -   HTML5
+
+        -   SASS
+
+        -   CSS3
+
+        -   webpack
+
+        -   node.js
+
+   -   Publikacja aplikacji:
+
+        -   Dostęp do aplikacji na stronie internetowej
+
+        -   Dostęp do repozytorium oraz dokumentacji aplikacji na serwisie
+             GitHub
+
+### Aplikacja serwerowa - REST API
+
+   -   Udostępnia serwisy REST
+
+   -   Służy do pobierania oraz zarządzania informacjami na temat
+        przedmiotów, prowadzących, wydarzeniach
+
+   -   Służy do pobierania i dodawania materiałów naukowych
+
+   -   Służy do zamieszczania postów i komentarzy na forum
+   
+   -   Używa relacyjnej bazy danych do przechowywania informacji o
+        użytkownikach, przedmiotach, prowadzących, ogłoszeniach,
+        wydarzeniach, postach oraz materiałów naukowych
+
+   -   Zintegrowane z Systemem Usos w celu autoryzacji oraz pobierania
+        informacji o użytkownikach
+
+   -   Dokumentacja dotycząca oprogramowania REST API
+
+   -   Technologie: Java, Spring, Hibernate
+
+
+### Relacyjna baza danych:
+
+   -   Baza stworzona na potrzeby przechowywania informacji o
+        użytkownikach, przedmiotach, prowadzących, wydarzeniach
+
+   -   Technologie:
+
+       -   Azure SQL
+
+###  Repozytorium zawierające kod aplikacji
+
+   -   GitHub
+
+### Elementy nieprogramistyczne
+
+-   Tablica projektowa - Jira:
+
+    -   Historia wymagań funkcjonalności (user stories)
+
+    -   Historia zadań
+
+-   Prototyp aplikacji webowej
+
+-   Dokumentacja dotycząca oprogramowania REST API
+
+-   Dokumentacja dotycząca oprogramowania aplikacji webowej
+
+-   Dokumentacja architektury wykorzystanej w projekcie
+
+## 2. Granice projektu
+
+-   Produkty nie zawarte:
+
+    -   Aplikacja mobilna
+
+    -   Aplikacja desktopowa
+
+-   Funkcjonalności nie zawarte:
+
+    -   Rejestracja użytkowników
+
+    -   Dostęp dla użytkowników nie posiadających konta w systemie USOS
+
+    -   Chat dla użytkowników aplikacji
+
+    -   Możliwość edycji danych użytkownika
+    
+## 3. Lista wymagań funkcjonalnych
+
+   -   Aplikacja webowa:
+
+        -   Autentykacja i autoryzacja użytkowników przez system
+
+        -   Dostęp do informacji na temat przedmiotów i prowadzących
+
+        -   Możliwość dołączania i opuszczania grup przedmiotowych
+
+        -   Możliwość dodawania postów stanowiących ogłoszenia, oferty
+            pracy i oferty korepetycji na tablicy ogłoszeń
+
+        -   Możliwość dodawania postów na forum dyskusyjnym, możliwość
+            komentowania postów i zamieszczania rozwiązań do zadań
+
+        -   Możliwość udostępniania plików innym użytkownikom
+
+        -   Możliwość inicjowania wydarzeń i dołączania do wydarzeń
+
+        -   Możliwość dostosowania powiadomień przez użytkownika 
+       
+        -   Możliwość dodawania przedmiotów, prowadzących, przydatnych linków przez użytkowników z uprawnieniami administratora 
+
+        -   Możliwość zarządzania ogłoszeniami, postami, komentarzami użytkowników przez administratorów
+
+        -   Możliwość dawania użytkownikom uprawnień administratora przez administratorów
+
+  -   Aplikacja serwerowa:
+
+        -   Zintegrowana z Systemem USOS w celu autoryzacji oraz
+            pobierania informacji o użytkownikach
+
+        -   Pobieranie oraz zarządzanie informacjami na temat
+            przedmiotów, prowadzących, wydarzeń, postów i komentarzy na
+            forum
+
+        -   Pobieranie i dodawanie materiałów naukowych
+
+        -   Połączona z relacyjną bazą danych zawierającą dane oraz
+            pliki
+
+## 4. Lista wymagań niefunkcjonalnych
+
+-   Dokumentacja dotyczącą oprogramowania aplikacji webowej i REST API
+
+-   Dostęp do repozytorium kodu
+
+-   Aplikacja dostępna dla komputerów i urządzeń mobilnych
+    
+-   Użyte biblioteki na licencji open-source
+
+    
+## 5. Mierzalne wskaźniki wdrożenia
+
+-   Akceptacja funkcjonalna:
+
+    -   Ukończenie zdefiniowanych funkcjonalności aplikacji webowej
+
+    -   Dostęp do aplikacji dla wszystkich użytkowników systemu Usos
+
+    -   Brak błędów utrudniających korzystanie z aplikacji
+
+-   Akceptacja jakościowa:
+
+    -   Zawieranie testów jednostkowe i sprawdzenie, czy spełniają swoje
+        zadanie
+
+    -   Deploy wersji alpha aplikacji na serwer 30.11.2020, przeprowadzenie testów, sporządzenie raportu i naniesienie poprawek na jego podstawie 
+
+    -   Deploy wersji beta aplikacji 07.01.2021 na serwer, przeprowadzenie testów, sporządzenie raportu i naniesienie poprawek na jego podstawie 
+
+    -   Aplikacja posiada 40 aktywnych użytkowników
+
+## 6. Kryteria akceptacji projektu dla I semestru prac
+
+   -   Dostarczenie prototypu projektu
+
+   -   Aplikacja webowa zintegrowana z REST API oferująca
+        funkcjonalności:
+
+        -   logowanie do serwisu
+
+        -   podstawowy interfejs startowy użytkownika
+
+        -   lista przedmiotów (grup przedmiotowych)
+
+        -   możliwość dołączenia do grup przedmiotowych
+
+        -   udział w forum
+
+   -   Dokumentacja aplikacji webowej i serwerowej
+
+## 7. Kryteria akceptacji projektu dla II semestru prac
+
+   -   Aplikacja webowa zintegrowana z REST API uzupełniona o
+        funkcjonalności:
+
+        -   udostępnianie i pobieranie materiałów w postaci plików
+
+        -   tworzenie i dołączanie do wydarzeń
+
+        -   dodawanie ogłoszeń
+
+        -   powiadomienia i customizacja powiadomień
+
+        -   edycja zawartości strony przez admistratorów
+
+        -   zarządzanie treścią i użytkownikami przez administratorów
+
+   -   Anglojęzyczna wersja aplikacji
+
+   -   Dokumentacja aplikacji webowej i serwerowej
+
+   -   System pozytywnie przeszedł testy obciążeniowe, testy alpha i beta 
+
+
+## 8. Organizacja pracy zespołu
+
+-   Strona klienta:
+
+    -   Studenci wydziału Matematyki i Informatyki na kierunku
+        Matematyka i Informatyka
+
+-   Strona zespołu projektowego
+
+    -   Malwina Chudzińska
+
+        -   Product Owner
+
+        -   Implementacja aplikacji webowej
+
+        -   Tworzenie prototypu interfejsu aplikacji
+
+    -   Anna Śniadek
+
+        -   Implementacja aplikacji webowej
+
+        -   Projekt szaty graficznej aplikacji
+
+        -   Scrum Master
+
+    -   Adrian Pacholak
+
+        -   Implementacja serwisów REST dla aplikacji
+
+        -   Projektowanie bazy danych
+
+    -   Phillip Ławniczak
+
+        -   Tworzenie prototypu interfejsu aplikacji
+
+        -   Implementacja aplikacji webowej
+        
+
+## 9. Ryzyka projektowe
+
+-   Odejście członka implementującego aplikację webową lub stronę
+    serwerową - trudności w ukończeniu aplikacji
+
+-   Określone ramy czasowe, semestry, na stworzenie produktu - ryzyko
+    nieukończenia w czasie
+
+-   Nieporozumienia w zespole dotyczące rozwiązań implementacyjnych,
+    architektury, funkcjonalności lub używanych technologii
+
+-   Konieczność poświęcenia czasu na dopełnienie wiedzy dotyczącej
+    stosowanych technologii
+
+-   Brak odpowiedniego zaangażowania w projekcie ze strony zespołu lub
+    wybranych członków zespołu
+
+-   Przechowywanie danych o użytkownikach
+
+-   Brak zainteresowania aplikacją ze strony użytkowników
+
+-   Brak chętnych do pełnienia roli administratora
+
+-   Zarządzanie nieodpowiednimi treściami
+
+-   Problemy techniczne po stronie systemu Usos
+
+## 10. Kamienie milowe
+
+-   Logowanie przez cas.amu.edu.pl
+
+-   Dostarczenie użytkownikowi funkcjonalności dołączania do grup
+    przedmiotowych
+
+-   Dostarczenie użytkownikowi funkcjonalności dodawania kontentu do
+    portalu
+
+-   Wdrożenie aplikacji serwerowej na serwerze
+
+-   Aplikacja posiadająca dokumentację
+
+-   Aplikacja dostępna na stronie internetowej
+
+-   Aplikacja posiadająca użytkowników
+
+-   Aplikacja uzupełniona danymi dotyczącymi przedmiotów, prowadzących,
+    materiałami naukowymi
+                                                                            

Marciniak/analiza-dyskusji/corpus-rodzaje_argumentacji.tsv

@@ -0,0 +1,702 @@
+id	paragraf	tag
+0-0	Często można spotkać się z podejściem, które zakłada że przy budowie systemu informatycznego powinny być stosowanie najnowsze technologie i modele architektoniczne. Podejście takie jest oczywiście zasadne jeżeli budowany jest nowy system nie obarczony koniecznością integracji z innymi systemami / technologiami.	hipoteza
+0-1	Co jednak w sytuacji w której budujemy system który musi się integrować ze “starymi” technologiami / architekturami? Czy zawsze mamy prawo żądać zmiany starych technologii? Kiedy się to nie uda? Podaj przykłady rozwiązań, które tak jak np. standard EDI mają już wiele lat i nadal są powszechnie wykorzystywane.	hipoteza
+1-0	Zmiana starych technologii na nowe nie uda się na przykład w następującym przypadku. System składa się z ogromnej liczby linii kodu napisanych w języku programowania, którego się już powszechnie nie używa. System ten jednocześnie jest rozpowszechniony - dużo osób z niego korzysta w różnych miejscach. Z tego powodu musi funkcjonować prawie przez cały czas, nie może mieć dłuższych przerw w działaniu.	logiczne
+1-1	Przykładem może być system, który we Francji zajmuje się lokalami (socjalnymi?). Napisany w Fortranie. Mnóstwo osób z niego korzysta codziennie, więc wyłączenie go na dłuższy czas i migracja danych nie są możliwe.	rzeczowe
+1-2	Kolejny przykład to niemiecki system związany ze służbą zdrowia. Zawiera kartoteki pacjentów. “”Przepisanie“” go od nowa również by nie było możliwe.	rzeczowe
+2-0	Czy zawsze mamy prawo żądać zmiany technologii? Nie, ale z czasem możemy być do tego zmuszeni.	hipoteza
+2-1	Przykład systemu napisanego w Fortranie przewijał się już kilkakrotnie. Podobno nikt nie odważy się go zmienić na jakiś inny. Pytanie brzmi czy wszystkie modyfikacje, które będzie trzeba wprowadzić będzie można zrealizować? W końcu Fortran jest językiem ograniczonym, nie obsługuje np. rekurencji, nie jest językiem obiektowym. Oczywiście nie potrzeba języka obiektowego, żeby programować obiektowo, ale z pewnością ułatwia to rozwiązywania problemów.	hipoteza
+2-2	Oczywiście wszystko się da zrobić w informatyce, pytanie za ile i na kiedy. Jednak były podane również przykład (na APO) systemu zdaje się napisanego w Delphi, który z czasem tak się rozrósł, że programiści stracili nad nim kontrolę i było trzeba go przepisać zgodnie z nowymi trendami.	emocjonalne
+3-0	Był jeszcze kontrprzykład na ASI - SOLSystem, który to ze względu na objętość pozostanie w języku Delphi.	rzeczowe
+3-1	Wydaje mi się jednak iż zmiany i unowocześnianie technologii powinno następować, nawet jeśli wydaje się to niemożliwe. Inaczej może się zdarzyć sytuacja podobna do tej w Kalifornii (przepraszam jeśli mylę miejsca) gdzie władze stanowe musiały “”wskrzeszać z martwych“” i ściągać z emerytury programistów COBOLa aby wprowadzili zmiany w używanym od zawsze systemie informatycznym.	inne
+4-0	Jeśli klientela się nie burzy - po co zmieniać coś co działa? Taki argument przesłonił mi motywację objętościową w tym przypadku (choć gdyby jej nie było to zapewne system rzeczywiście zostałbym przepisany).	emocjonalne
+4-1	Jak powszechnie wiadomo, klienta zazwyczaj interesuje tylko czy dany system spełnia jego wymagania, a nie jakie ma fundamenty. Skoro nie mają nawet problemów z nieco archaicznym interfejsem, a nowi klienci również się znajdują, może nie ma potrzeby inwestowania czasu i środków w żmudną przebudowę.	inne
+4-2	Rozumowanie oczywiście naiwne, ale myślę że i w niektórych (raczej niszowych) przypadkach praktyczne. Ostatecznie jednak zgadzam się, że modernizacje powinny mieć miejsce, bo może to zapobiec wielu potencjalnym problemom w przyszłości (a także wytworzyć wiele potencjalnych problemów w trakcie, ale to inna historia).	logiczne
+5-0	Większość moich przedmówców skupiła się głównie na, pewnie najistotniejszym, aspekcie procesu wymiany systemów na nowe - kosztach. Wydaje mi się jednak, że innym, całkiem ważnym, jest stabilność istniejących już systemów. Mając np. jakąś ważną (tzn. np. mającą podtrzymać czyjeś życie, albo czuwać nad sprzętem wartym miliony) aplikację, która działa bez szwanku, przejście na nowy, potencjalnie lepszy system, może spowodować więcej problemów niż zysków.	logiczne
+5-1	Ten błyszczący nowością produkt nie został przecież jeszcze przetestowany na równi z tym starym, który działa latami. Dlatego też w takich sytuacjach “”przesiadka na nowe“” nie jest czymś na co łatwo się zdecydować.	logiczne
+5-2	Jakiś czas temu czytałem, że w części pojazdów kosmicznych NASA nie wymienia się pewnych działających komputerów, gdyż dobrze działają i mają pewną “”zaletę“” nad nowymi. Otóż w przypadku przeniknięcia przez kadłub cząsteczek, które mogłyby “”zamieszać“” w operacjach, które wykonują są one bardziej odporne, jako, że ich podzespoły są większe. Nie wiem na ile jest to wiadomość wiarygodna, a na ile kolejna miejska legenda, ale brzmi sensownie.	rzeczowe
+5-3	Przyłączę się jednak również do zdania mówiącego, że należy się unowocześniać, bo nie wiemy co będzie konieczne w przyszłości. Tak jak często ludy, które nie musiały, z przyczyn ogólnego dobrobytu, rozwijać się padały łupem tych, na których rozwój był wymuszony, tak my możemy kiedyś zmierzyć się z problemem, że myślenie w stylu: “”jak działa, to po co zmieniać“” doprowadzi nas nad przepaść.	emocjonalne
+5-4	Dlatego też należy przeć do przodu, ale nie powinno się przesadzać w pogoni za unowocześnianiem wszystkiego.	hipoteza
+6-0	Widzę, że osoby wypowiadające się w tym wątku wymieniły już kilka kontrargumentach jak objętość dotychczasowego kodu, koszty, stracony czas czy stabilność.	rzeczowe
+6-1	Z wykładów kojarzę dwa projekty informatyczne, którym nie spieszy się do zmiany technologii.	inne
+6-2	Pierwszy to system do zarządzania lokalami socjalnymi we Francji napisany w Fortranie. Nie jestem pewny czy wzmianka o nim pojawiła się akurat na DASI czy na DTSI. W każdym razie poprawki do tego systemu są testowane co najmniej trzy miesiące przed wprowadzeniem ich w życie. Nie wydaje się być to zbyt efektywne. Mimo to sądzę, że ten system przetrwa aż do upadku obecnego rządu Francji.	rzeczowe
+6-3	Drugi przykład który kojarzę, to zintegrowany system obsługi lokali firmy SOL-System. Jako ciekawostkę dodam, że jednym z pracowników tej firmy jest kierownik laboratoriów wydziału matematyczno-informatycznego uczelni, której jeden z absolwentów sformułował twierdzenie, które wygrało drugą wojnę światową. System nie dojść, że napisany w Delphi (wcześniejsze wersje w Pascalu), to nie wykorzystuje systemu uprawnień po stronie bazy danych a aplikacja kliencka ma interfejs typowych dla programów biurowych systemu MS-DOS (przynajmniej jeśli chodzi o główne menu).	rzeczowe
+6-4	Jednakże system jest rozwijany już kilkanaście lat i wątpię, żeby kiedykolwiek doszło do zmiany języka (widzę ewentualną możliwość zmiany środowiska z Embarcadero/CodeGear Delphi na FPC/Lazarus). Ba, sądzę również, że ze względu na przyzwyczajenia obecnych klientów nawet interfejs aplikacji nie zostanie prędko zmieniony.	logiczne
+7-0	Na początek, zacznę od sprostowań dotyczacych systemu firmy SOL-SYSTEM  1. System w obecnej wersji budowany jest przy użycia środowiska Embracadrero Delphi (wciąż rozwijanego i stabilnego)  2. Poprzednie wersje nie były pisane w pascalu lecz w środwisku Clipper, przejscie z tego środowiska trwalo ok 4lat i było zaprojektowanie i zaimplementowaniem systemu od zera.  3. Srodowisko w którym tworzony jest system nie składa się tylko z języka programowania, ale również składa sie na nie serwer baz danych Firebird (ogólnie mówiąc struktury danych i procedury) oraz warstwa dostepu do danych IB-objects i komponenty wspomagające np do generowanie pdf, szyfrowania danych, administracyjnych modułów serwerowych, modułów integracyjnych z systemami zewnętrznym itd.  4. system jest dalej rozwijany w tym środowisku nie tylko ze względu na ilość kodu (na wykładzie był podane to tylko jako jeden z argumentów), ale po prostu nie ma powodu by to robić wszystko działa stabilnie, wydajnie, a pracy jest dość przy rozwoju funkcjonalnym obecnej wersji.	rzeczowe
+7-1	A teraz moje zdanie na temat wymiany srodowiska.	inne
+7-2	Należy sobie postawić pytanie: jaki miałby być cel zmiany środowiska?  *jeżeli jest to środowisko stare, już dawno nie rozwijane, w którym występują błędy utrudniające prace programistyczną oraz wystepuja problemy z uruchamianiem aplikacji w nim wykonanych w nowych systemach operacyjnych - to oczywiście się zgodzę, że trzeba rozwarzyć możliwoć zmiany technologii  *natomiast  zmiana środowiska programistycznego tylko dlatego, że jest moda na inny język programowania, jeżeli środowisko jest cały  czas rozwijane i suportowane, i nie występją w nim błędy oraz aplikacja spełnia wszystkie wymagania klientów oraz środowisk systemowych i bazodanowych, to jest to bez sensu.	logiczne
+7-3	Wymienie dodatkowych kilka inncyh powodów:  * Zmiana technologi to nie tylko przepisanie kodu, to również często potrzeba zmiany modelu danych, motedy dostepu do nich,  konieczność wymiany wielu współpracujących komponentów. Pociąga za sobą ogromne koszty, jest czasochłonna, wymusza koniecznośc  zatrudniania specjalistów znających się na obu platformach przez długi okres, wsparcie dwóch różnych projektów przez długi czas.	rzeczowe
+7-4	"Potrzebny jest długi czas na testowanie nowego rozwiązania. Często wymagana jest zmiana sprzętu.  * W jaki sposób taka zmiana miała by poprawić komfort pracy użytkownika? Jeśli prowadziłby do zmiany interfejsu użytkownika to już  z założenia utrudni ona życie uzytkownikowu przyzwyczajonemu do pracy z poprzednim systemami. A jesli mamy zachować dokładnie interfejs to użytkownik i tak nie zauważy zmiany ;) Oczywiście zakładamy, że system w obu środowiskach działa wydajnie i stabilnie.  *Używając nowego środowiska natykamy się na nowe problemy, które nie występowały wcześniej w starym, a więc zmiana środowiska to nie tylko przepisanie kodu.  *po co inwestować ogromne kwoty w zmiane srodowiska, klienci na pewno za to nie zapłacą!"	logiczne
+7-5	Kilka pytań, które mnie zastanowiły po porzednich wypowiedziach :  *Dlaczego środowisko Delphi jest gorsze od javy, c++, C#, VB, itd? Tylko dlatego, że ma składnie pascala? Czego nie umożliwia co umożiwają inne środowiska, a co może mieć wpływ na jakość produkowanej aplikacji?  *W czym środowisko Lazarus miało by być lepsze od delphi?	hipoteza
+7-6	"Na koniec, zgodzę się w 100% z ostatnim zadaniem autora poprzedniej wypowiedzi ;)"	inne
+8-0	Na ile pamiętam Delphi (z zajęć jakieś 6 lat temu) to nie posiadało ono garbage collectora, chyba że coś się zmieniło od tego czasu? Konieczność ręcznego zarządzania pamięcią (i związane z tym błędy) jest moim zdaniem co najmniej tak samo uciążliwa jak niedostatki składni.	inne
+8-1	Nie twierdzę, że jest to argument, który uzasadniałyby przepisanie prawidłowo działającej aplikacji, która realizuje cele biznesowe klientów, ale gdybym miał pisać aplikację od zera to: brak garbage collectora, uciążliwa (przynajmniej dla mnie) składnia oraz mała w stosunku do Javy czy C# społeczność programistów wystarczałyby mi, aby odrzucić Delphi jako środowisko.	emocjonalne
+8-2	Niekiedy nie mamy już szansy przejścia na nową technologię - w USA dużo systemów było napisanych we fortranie i do dzisiaj programiści fortrana dzięki temu mają pracę a w kryzysie roku 2000 byli potrzebni do pracy nad tymi systemami.	rzeczowe
+8-3	Jeżeli chodzi o przestarzałe technologie wykorzystywane do dzisiaj, wspomnę tylko, że komputer wahadłowca kosmicznego ma tylko 1 MB RAM!  Wszystko działa w UNIX-podobnym środowisku. Dlaczego nie jest to modernizowane? Otóż ta moc wystarcza do przeprowadzania bardzo skomplikowanych przecież obliczeń, a po drugie wdrożenie wymagało by bardzo bardzo wielu testów..	rzeczowe
+8-4	Przykładem zastosowania starszego oprogramowania może być wersja Stable dystrybucji Debian, której kolejne wersje pojawiają się dosyć rzadko i z opóźnieniami.	rzeczowe
+8-5	Powodem tego jest nacisk deweloperów na poprawianie błędów krytycznych i latanie dziur bezpieczeństwa. Nie ma tam miejsca na najnowsze wersje programów. Właśnie dzięki temu dystrybucja ta jest stosowana na serwerach.	rzeczowe
+9-0	Wg mnie należy najpierw wyznaczyć wszelkie za i przeciw, przy zmianie oprogramowania(technologii) na nowsze. Czyli:  - co nam daje obecna technologia  - co zyskujemy, a co tracimy wprowadzając nową technologię  - jakiego sprzętu/oprogramowania potrzebuje nowa technologia  - czy będzie to opłacalne na dłuższą metę  - czy będzie niezbędne  - jakie korzyści z tego będziemy mieli my, a jakie nasi użytkownicy	hipoteza
+9-1	Na pewno ważnym czynnikiem będzie także czas potrzebny na przejście z jednej technologii na drugą, oraz budżet jakim dysponujemy.	logiczne
+9-2	Tytułem podsumowania:	inne
+9-3	Oczywiście trudno jest rozstrzygać jak to będzie. Ale wydaje mi się, że informatyka powoli wkracza na taki poziom rozwoju jak rozwiązania inżynieryjne sprzed powiedzmy 100 lat. We Francji jeździełem windami, które miały ze 100 lat prawie. Oczywiście były konserwowane, wymieniane były części i działały.	inne
+9-4	W Poznaniu mamy tramwaje sprzed kikudziesięciu lat i jeżdzą (i tak w sumie to jeżeli są ekonomiczne i tanie w utrzymaniu - nie wiem czy są - to niech sobie jeżdżą). Samoloty czasami mają po kilkadziesiąt lat i też im niczego nie potrzeba (oczywiście części sprzed kilkudziesięciu lat w nich pewnie za dużo nie ma).	inne
+9-5	Zatem niby dlaczego wszystkie systemy należy zastapić nowymi? Według mnie odpowiedź jest taka: zastępujemy tylko wtedy jeżeli ma to ekonomiczne uzasadnienie. Według mnie niektóre pisane współcześnie (tzn. przez ostatnie 10 lat) systemy w J2EE będą działały i 30-40 lat…	hipoteza
+10-0	Czasem łatwiej jest wprowadzić pewnego rodzaju nakładkę na istniejący już system ułatwiając tym samym pracę z nim. Np. Windows Forms jest to technologia praktycznie w całości bazująca na poczciwym już Win32.	rzeczowe
+10-1	Łatwość użytkowania + wprowadzona obiektowość (również ograniczenia wynikające z nieobiektowej biblioteki) przedłużyły żywotność Win32 na kolejne kilka lat.	inne
+11-0	Widze, że wszyscy raczej zgodnie są przeciwni zmianie technologii w starych systemach. Ogólnie wygląda na to że, nowsze jest wrogiem dobrego. Ale niekoniecznie zawsze. Na przykład w przypadku systemu via internet, z którego zdarza się, że korzystają jednocześnie miliony użytkowników, a są takie przecież, zmiana technologii na nowszą, tzn. dużo bardziej wydajną, no bo wydajność systemu przy tak dużej ilości użytkowników odgrywa w znacząca role, może być zbawienna w skutkach.	hipoteza
+11-1	Prosty scenariusz:  Powstała aplikacja webowa w jakiejś prostej technologii, niech to będzie PHP - oklepane prawda?	emocjonalne
+11-2	Aplikacja zdobywa popularność, zyskuje użytkoników, liczba odwiedziń rośnie - strzelają korki od szampana.	emocjonalne
+11-3	Teraz załóżmy, że liczba odwiedziń osiąga krytyczny poziom. Szybkość działania aplikacji drastycznie spada, przez co rośnie niezadowolenie użytkowników.	inne
+11-4	Trzeba działać. Co robimy? Oczywiście inwestujemy spore kwoty w high-end hardware. Lecz zamiast tego można wziąć na warsztat asynchroniczny framework webowy z nieblokującym I/O (przy okazji, szkoda, że takich rzeczy nie ma w ramach programu kształcenia na naszej uczelni) i zacząć działać.	inne
+11-5	Uwaga teraz ekstremalny przykład: np Node.js - czyli właśnie taki framework do pisania aplikacji webowych. Uwaga, w czym? W javascripcie (oczywiście po stronie serwera). Wydajność systemu opartego właśnie na takiej technologii będzie tak zadowalająca, że o zakupie high-endu bedziemy mogli na długo zapomnieć.	hipoteza
+12-0	Przypomina mi to trochę sytuację na polu aplikacji internetowych, gdzie rynek czasami wręcz zniechęca developerów do używania najnowszych technologii. Jeżeli klient stawia wymagania, aby frontend strony był bardzo rozbudowany i estetyczny, a jednocześnie działał w najpopularniejszych przeglądarkach internetowych, to kulą u nogi staje się nieszczęsny IE6 sprzed niemal dziesięciu lat.	inne
+12-1	Nie wiem, czy HTML, CSS i JavaScript można nazwać nowoczesnymi, ale faktem jest, że w ostatnich latach nastąpił ich znaczny rozwój. Przy okazji producenci różnych przeglądarek zaczęli wprowadzać specyficzne dla siebie funkcjonalności.	rzeczowe
+12-2	Dodając do tego fallback dla “”dinozaurów“” nagle okazuje się, że musimy zaimplementować to samo kilka razy, dodając setki linii kodu JS i hacki na CSS. Jeżeli oprócz tego nasza strona ma działać nawet przy wyłączonym JS i wtyczkach typu Flash/Silverlight, oznacza to, że nie możemy polegać na nowoczesnych technologiach wogóle.	emocjonalne
+12-3	Być może trochę przejaskrawiam, zwłaszcza, że mamy dobre frameworki dla JS rozwiązujące za nas dużą część problemów z różnicą API i fallbackiem, jednak pewien niesmak pozostaje. Zwłaszcza, gdy ma się świetne rozwiązania na wyciągnięcie ręki (np. canvas + JS zamiast Flasha) i nie można z nich skorzystać, bo statystycznie ponad połowa ludzi i tak nie zobaczy efektu.	logiczne
+12-4	Oczywiście jestem jak najbardziej za używaniem nowych, dobrych technologii Ubolewam tylko nad faktem, że czasami przez problemy zaznaczone przeze mnie powyżej, idealistyczne podejście do projektu może zostać zabite przez deadline i budżet.	emocjonalne
+13-0	Zgadzam się z przedmówcą. Spójrzmy na problem ze strony otrzymanego zlecenia na system. Czemu mamy się martwić o to, co będzie X lat później i nad czym nie będziemy mieli nigdy pełnej kontroli. Niech zleceniodawca zapłaci nam za system, który jest “”w miarę“” aktualny na dzień dzisiejszy, nie koniecznie w najnowszej technologi, a w miarę upływu czasu, gdy on przestanie być aktualny..	emocjonalne
+13-1	Niech zapłaci po raz kolejny. Nigdy nie będziemy mieli gwarancji, że technologia będzie najnowsza/aktualna. Piszmy w tym co jest dobre i aktualne, nie koniecznie najnowsze.	hipoteza
+13-2	Co do przykładu SOL-SYSTEM, to wydaje mi się, że co kilka lat (jeśli będzie na ten produkt jeszcze zainteresowanie) można go “”przepisać“”, ale to naprawdę w dramatycznych przypadkach. Po co zmieniać coś, co działa i jest wystarczająco użyteczne?	hipoteza
+14-0	Podobnie jak moi przedmówcy, uważam, że jeśli dane rozwiązanie spełnia swoją funkcjonalność, jest poparte długim okresem użytkowania świadczącym o stabilności i bezawaryjności danego systemu oraz nic nie wskazuje na potrzebę wprowadzania w przyszłości dość radykalnych zmian w systemie, to zmiana technologii raczej nie wydaje się być uzasadniona.	logiczne
+14-1	Jednym z ważnych czynników jak już jeden z kolegów wspomniał jest skalowalność systemu (sprostanie zwiększonej ilości użytkowników), zapewnienie stabilności działania i dostępności systemu - wówczas w przypadku nieprzewidzenia takiej sytuacji, lub napotkania na barierę ze strony aktualnie wykorzystywanej technologii, przesiadka na inną (być może wcale nie nowszą) technologię może okazać się nieuniknioną koniecznością.	logiczne
+14-2	Nigdy jednak nie jesteśmy w stanie do końca przewidzieć wszystkich czynników zewnętrznych, które kiedyś mogą sprawić, iż technologia, którą wybraliśmy może okazać się nieodpowiednia - dlatego uważam, że jeśli dostaniemy sygnały (nawet najmniejsze), mogące wskazywać na (być może) konieczność wprowadzenia w przyszłości drastycznych zmian w systemie wymagających zmiany technologii, to nie powinniśmy się tego bać i z wyprzedzeniem przygotować się (poczynić pewne kroki) do ewentualnej (gotowości do) zmiany technologii, by przebiegła ona możliwie ‘płynnie’ i bezboleśnie.	hipoteza
+15-0	Rozwój projektu, zmiana jego wersji musi iść w parzę z wymaganiami postawionymi przez klientów. Jednakże, nowe wersje oprogramowania powinny być wystawiane dla klienta nie jako wersja ‘Stable’ a np Release. To chyba rozwiązanie. Kto potrzebuje aktualizuje, kto nie czeka na opinie użytkowników odnośnie poprawnego działania.	hipoteza
+15-1	W kwestii kosztów przepisywania oprogramowania w celu dostosowania do nowszych technologii : jeśli firma, która ma stary i skomplikowany system będzie potrzebowała prostych zmian, a zmiany te będą zlecone innej firmie niż ta, która wdrożyła ten system , zmiany te mogą być z upływem czasu droższe lub może być problem ze znalezieniem firmy, która się tego zlecenia podejmie.	inne
+15-2	Takie sytuacje zdarzają się przy mniejszych projektach, gdzie klient nie chce unowocześniać swojego systemu przy okazji zmian, bo będzie za drogo. Oczywiście zgadzam się z tym, że jeżeli system działa mimo iż powstał nawet przy użyciu ekstremalnie starych technologii to należy go w takim stanie zostawić, szczególnie jeśli nie przewiduje się w nim zmian.	inne
+15-3	O korzyściach płynących ze stosowania cloud computing można usłyszeć na niemal każdej poświęconej mu prezentacji. O wysokim potencjale “”przetwarzania w chmurze“” świadczy nie tylko mocna pozycja weteranów tego rynku jak Amazon czy Rackspace, ale również pojawienie się nowych silnych graczy jak Microsoft i Google. Warto jednak zastanowić się również nad kilkoma kwestiami otwartymi związanymi z przetwarzaniem danych w chmurze.	hipoteza
+15-4	"A. Jakie potencjalne problemy biznesowe mogą wyniknąć z utrzymywania aplikacji w chmurze?  B. Jakie zagrożenia trzeba uwzględnić na poziomie architektury/projektowym przygotowując aplikację do umieszczenia w chmurze?  C. Czy biorąc pod uwagę mnogość dostawców rozwiązań typu cloud computing oraz zróżnicowanie poszczególnych usług można (a jeżeli można, to czy warto) rozwijać aplikację działającą na wielu środowiskach typu cloud?  D. Czy warto budować chmurę prywatną (private/internal cloud) w obrębie przedsiębiorstwa?  E. Czy cloud computing ma szansę przebić się w instytucjach, które zwracają szczególną uwagę na ochronę danych (banki, instytucje finansowe itp.)?  F. Jakiego rodzaju systemy powinny/nie powinny/mogą/nie mogą zostać przeniesione na chmurę w Polsce? Czy cloud computing może znaleźć zastosowanie w administracji publicznej np. w ZUSie ;) ?"	hipoteza
+16-0	Pozwolę sobie na pierwszą wypowiedź w duchu krytyki cloud computingu. Widzę w tym podejściu zasadniczy problem - konieczność zarządzania czasem działania wynajmowanych maszyn wirtualnych (ze względu na koszty). Jest to kwestia, o której do tej pory firmy nie musiały myśleć. Przestawienie na nowy model może być dość oporne, co może doprowadzić do klęski cloud computingu.	logiczne
+16-1	Nie do końca rozumiem dlaczego konieczność zarządzania czasem działania maszyn jest aż tak wielką wadą tego rozwiązania ze mogła by doprowadzić do klęski. Z tego co wiem, to stawka jest, przynajmniej u niektórych dostawców, naliczana z dokładnością do 1 sekundy/minuty wykorzystanego czasu. Czas podłączania/odłączenia maszyny jest również dość krótki rzędu 10-60 minut. Stąd niebawem, jeśli jeszcze ich niema, pojawią się narzędzia do automatyzacji i optymalizacji ilości używanych maszyn w zależności od obciążenia obsługi.	logiczne
+16-2	Takie rozwiązanie mogło by pozwolić zoptymalizować wykorzystanie sprzętu, np: wcześniej przytoczony ZUS pracuje od poniedziałku do piątku i tylko powiedzmy od 8:00 do 15:00, ponieważ wiemy że w weekend nie będzie żadnego obciążenia systemu to możemy zmniejszyć ilość maszyn powiedzmy do 10% ilości niezbędnej do pracy w ciągu tygodnia. Pozwala to zaoszczędzić koszty, a jak coś pozwala zaoszczędzić to managment firmy już jest na to chetny :)	emocjonalne
+16-3	Stąd moje zdziwienie taka wadą, gdyż w moim rozumieniu jest to jedna z największych zalet cloud computingu - płacimy za sprzęt, który potrzebujemy w danym momencie, a nie za sprzęt, który musi podołać maksymalnemu obciążeniu które zdarza się co jakiś czas.	hipoteza
+16-4	Moim zadaniem większy problem może stanowić konieczność przestawienia się z myślenia o zasobach jako o konkretnym sprzęcie na myślenie o zasobach jako o usłudze. Wiele osób myśli, przecież jak będziemy im płacić po x $ miesięcznie to po 5 latach nazbieralibyśmy na własny sprzęt o wystarczającej mocy, a bylibyśmy przynajmniej niezależni.	emocjonalne
+16-5	Takie rozumowanie jest poprawne, przecież podobnie jest z wynajmem mieszkań, lepiej kupić własne mieszkanie niż przez całe życie je wynajmować. Jednak zakup mieszkania różni się od zakupu sprzętu komputerowego. Po pierwsze dom kupiony 10 czy 20 lat temu nadal spełnia wymagania znacznej większości współczesnych użytkowników. 20 letni komputer miał by zainstalowane Windows 3.0 (nawet nie 3.11 bo ten ma dopiero niecałe 19 lat).	logiczne
+16-6	Druga różnica polega na tym, że pojęcie 20 letni dom nikogo nie dziwi, co więcej takie domy sprzedaje się obecnie po cenie nieznacznie niższej od ceny nowowybudowanych. 20 letni komputer brzmi przynajmniej niezwykle, a 20 letni komputer zarządzający pewną niezawodną usługą wykorzystywana przez wielu użytkowników to naprawdę rzadkość (choć istnieją takie systemy, np system informacyjny na dworcu Poznań Główny), współczesne komputery o dużej mocy nie są przeznaczone do pracy przez 20 lat, lecz co najwyżej 2.	inne
+16-7	Dlatego w tym przypadku rozumowanie to nie uwzględnia dodatkowych kosztów i problemów. Jeśli chcemy kupić własną infrastrukturę to oprócz kosztu jej zakupu, utrzymania, trzeba również doliczyć koszt jej wymiany na nowa gdy ta już się zużyje. Wtedy jednak może się okazać ze lepiej będzie płacić już Im za usługę niż za własny sprzęt.	logiczne
+17-0	Przetwarzanie w chmurze wywołało spore zamieszanie w branży ogólnie określonej jako IT. Interesujące jest, a dodatkowo chyba jedno z najważniejszych, jak zostanie rozwiązana kwestia bezpieczeństwa.	hipoteza
+17-1	Jak podaje World Privacy Forum (organizacja non-profit zajmująca się m.in.problemem bezpieczeństwa danych w Internecie) nie jest do końca jasne, co się dzieje z danymi przechowywanymi w ramach tejże usługi, ani gdzie dokładnie przechowywane są dane. Na pewno osoby nieupoważnione mają łatwiejszy dostęp do danych przechowywanych w chmurze, przecież dane oprócz przechowywania muszą dodatkowo płynąć z i do chmury. W dużej mierze bezpieczeństwo opiera się o zaufanie do dostawcy usługi.	rzeczowe
+17-2	Żeby rozwiązać problemy na pewno trzeba zastosować odpowiednio mocne zabezpieczenia i  to w wielu miejscach całej usługi.	hipoteza
+18-0	Bezpieczeństwo danych to jedno, gorzej jeśli w ogóle zostanie utracony do nich dostęp (szczególnie tyczy się to mniejszych providerów). Powiedzmy, że system nagle padnie i zewnętrzny usługodawca nie może (lub nie chce!) naprawić usterki - jesteśmy zdania na łaskę techników. Podobnie może się zdarzyć jeśli usługodawca nie będzie mógł dalej dla nas świadczyć usług.	emocjonalne
+18-1	Praca z chmurą ma to do siebie, że trzeba być podłączonym do internetu. Może to wydawać się śmieszne, ale w historii parę razy zdarzało się, że np. statek uszkodził kabel i co spowodowało albo gigantyczne zator ruchu lub odcięcie dostępu. Rozwiązaniem może być np. rozproszenie głównych węzłów, jednak nie jest ono zawsze możliwe choćby ze względu na różne systemy prawne.	inne
+18-2	"W jednej z dyskusji w internecie poruszono też możliwość bankructwa providera w czasach kryzysu. Co prawda obecnie nic nie wskazuje na to aby np. Amazon miał ogłosić upadłość ;), ale patrząc na to jak Lehman Brothers nagle pożegnał się z rynkiem…"	inne
+18-3	M.in. dlatego warto inwestować w prywatną chmurę, aby dane nie uciekały za daleko, a nadwyżce zasobów można też zarobić.	hipoteza
+19-0	Andrzej, tylko to o czym mówisz nie ma związku z samym cloud computingiem, a dostarczaniem przez kogoś usługi. Już w obecnych, powiedzmy klasycznych data canter, przy dzierżawie serwera albo wirtualki mamy do czynienia z takimi samymi zagrożeniami. To w kwestii dostawcy leży zapewnienie ciągłości usługi w tym np. redundantnych łącz.	rzeczowe
+19-1	"Oczywiście część problemów tradycyjnie się pokrywa, jednak chyba źle rozłożyłem akcent w poprzedniej wypowiedzi ;) Poza aspektem technicznym jest też biznesowy. W klasycznym podejściu firmy mają względnie wąski zakres działalności. Główni potentaci świadczą szeroki wachlarz usług, więc istnieje realne zagrożenie, że część moich rozwiązań może być wykorzystywana w innych podmiotach usługodawcy bez mojej wiedzy."	emocjonalne
+19-2	Tam gdzie są wielkie korporacje jest duża sieć powiązań między firmami (m.in. poprzez kapitał), więc mojemu providerowi może bardziej zależeć na wspieraniu pośrednio własnych rozwiązań (które mogą pojawić się w późniejszym czasie) niż konkurencyjnych.	inne
+19-3	"Cóż, nie jestem wielkim fanem korporacji, w szczególności tych które mają powód do grzebania w moich danych, jak np. Google ;)"	emocjonalne
+20-0	Obecnie cloud computing stał się bardzo głośnym tematem. Czasami mam wrażenie, że za kilka lat stanie się czymś dla nas naturalnym. Już teraz zdecydowaliśmy się oddać swoje dane innym firmom (patrz: mail, kalendarz, filmy u “”wujka“” Google), pytanie czy oddawanie swoich “”obliczeń“” również możemy przekazać innym?	hipoteza
+20-1	Wydaje się, że wszystkie zalety chmur są też ich wadami.	hipoteza
+20-2	Owszem nic nie zapowiada upadku Amazona, ale nigdy nie wiemy, czy rząd USA nie zdecyduje się zmusić ich do oddania ich wszystkich danych w celu “”walki z terroryzmem i pedofilią“”.	emocjonalne
+20-3	Statki często przepływają nad kablami i wszystko działa, ale zdarzają się pojedyncze przypadki, gdy coś się psuje. Wystarczy przypomnieć sobie “”odcięcie“” ZEA i Arabii Saudyjskiej w zeszłym roku (przecięte zostały dwa z pięciu światłowodów łączących te kraje z siecią).	rzeczowe
+20-4	Do tego, pomimo pozornego rozproszenia. Internet należy (jest pod kontrolą) kilku dużych organizacji. Jak zapewnić ich niezależność i sprawiedliwość? Czy nie będą nas “”podsłuchiwać“”?	hipoteza
+20-5	Do tego rozwój sieci - infrastruktury nie nadąża za potrzebami. Coraz częściej zdarzają się przestoje spowodowane zapchaniem się łącz. Czy sieć jest wsatnie utrzymać dużo chmur?	hipoteza
+20-6	Jedyną naszą obroną jest anonimowość przez masowość. Giniemy w tłumie informacji i dopóki jesteśmy “”nieciekawi“” dla innych możemy czuć się bezpiecznie. Możemy też zadbać o własne zabezpieczenia danych (np. szyfrując je), ale potrzebujemy do tego własnej mocy obliczeniowej, czy to nie psuje idei cloud computingu?	hipoteza
+20-7	Nie twierdze, że CC jest złe, ale należy się solidnie zastanowić czy jest adekwatne do naszych potrzeb.	logiczne
+20-8	Idealnie pasuje tu komiks. Dzisiejszy (07 Stycznia) Dilbert:  http://dilbert.com/strips/comic/2011-01-07/	inne
+21-0	Zastanawia mnie, dlaczego wszyscy burzą się tak bardzo o bezpieczeństwo.	emocjonalne
+21-1	Czy każdy z nas będzie przechowywał w chmurze dane z hasłami albo inne bardzo ważne dane? Skoro tak, to wtedy niestety trzeba zapłacić więcej dla lepszej ochrony.	logiczne