Compare commits

...

180 Commits

Author SHA1 Message Date
594bdaa7f5 Merge pull request 'uaktualniona dokumentacja' (#70) from s434723/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#70
2021-01-28 00:17:39 +01:00
729fdd3a08 Merge pull request 'Dokumentacja' (#69) from s434779/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#69
2021-01-28 00:17:25 +01:00
mevryn
34d7e8ba1f uaktualniona dokumentacja 2021-01-27 23:00:00 +01:00
cfaf4b17e7 Merge pull request 'Update FlatMapp project requirements' (#62) from s434657/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#62
2021-01-27 21:47:15 +01:00
d00d8ae80e Merge pull request 'Electron update' (#60) from s434802/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#60
2021-01-27 11:54:26 +01:00
d029cbd789 Delete 'Krzywdzinski/ciecie-szkla/(gotowe) Wizja projektu (6).docx' 2021-01-26 22:13:46 +01:00
2010632cce Delete 'Krzywdzinski/ciecie-szkla/(gotowe) Wymagania projektowe (2).docx' 2021-01-26 22:13:35 +01:00
d23a8a53da Upload files to 'Krzywdzinski/ciecie-szkla' 2021-01-26 22:13:07 +01:00
baa15b82e6 Dokumentacja 2021-01-25 23:24:37 +01:00
66fe08e436 Merge pull request 'Dodanie dokumentacji oraz prezentacji na obronę' (#68) from s434690/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#68
2021-01-25 21:20:59 +01:00
e9ce13ec2a Dodanie dokumentacji oraz prezentacji na obronę 2021-01-25 21:07:35 +01:00
b04141a607 Merge pull request 'korpusy uczenia maszynowego' (#66) from s434659/DPRI_doc_20-21:analiza-dyskusji into master
Reviewed-on: bikol/DPRI_doc_20-21#66
2021-01-25 09:44:09 +01:00
4a82793fce Merge pull request 'Dokumentacja developTeam' (#67) from s434732/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#67
2021-01-24 22:37:32 +01:00
827a78c6b6 Upload files to 'Pilka/obiekty-sportowe' 2021-01-24 22:01:00 +01:00
148511afa0 Delete 'Pilka/testy.png' 2021-01-24 22:00:37 +01:00
62384b7deb Delete 'Pilka/InstrukcjaWdrożeniowa.pdf' 2021-01-24 22:00:31 +01:00
e0e1023159 Delete 'Pilka/InstrukcjaPaneluAdministratora.pdf' 2021-01-24 22:00:25 +01:00
8428198f9a Delete 'Pilka/DokumentacjaTechniczna.pdf' 2021-01-24 22:00:17 +01:00
a5cb132364 Upload files to 'Pilka' 2021-01-24 21:59:30 +01:00
3d0e61ca6c Merge pull request 'Dodanie dokumentacji wdrożeniowej, dokumentacja backend/fronted, prezentacji dla komisji itp.' (#64) from s434812/DPRI_doc_20-21:plannaplan-dokumentacja into master
Reviewed-on: bikol/DPRI_doc_20-21#64
2021-01-24 18:22:04 +01:00
496099ae34 Merge pull request 'Dokumentacja techniaczna SushiBar' (#65) from s426206/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#65
2021-01-24 18:21:44 +01:00
26107bb7ab korpusy uczenia maszynowego 2021-01-24 18:09:43 +01:00
14a2ea0b97 Dokumentacja techniaczna 2021-01-24 17:17:47 +01:00
c16b41fd3a
Dodanie dokumentacji, prezentacji itp
Signed-off-by: Marcin Woźniak <y0rune@aol.com>
2021-01-24 17:08:13 +01:00
4acb23b25a Update FlatMapp project requirements 2021-01-23 20:28:09 +01:00
17ae3a6179 Merge branch 'master' into master 2021-01-23 20:27:04 +01:00
5b9642c1ab Prześlij pliki do 'Witkowski/flat-mapp' 2021-01-23 20:25:49 +01:00
91b4a2e897 Merge pull request 'Added project requirements document 2.0.1' (#59) from s394161/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#59
2021-01-23 14:18:32 +01:00
048eea333e Electron update
Auth0 and Electron production conflict
2021-01-22 19:25:32 +01:00
24812fdec8 Upload files to 'Krzywdzinski/motocykle' 2021-01-22 11:04:46 +01:00
e37248bcbf Upload files to 'Krzywdzinski/rpg' 2021-01-22 11:03:51 +01:00
3b0baef630 Upload files to 'Krzywdzinski/portal-randkowy' 2021-01-22 11:03:29 +01:00
04471c2907 Upload files to 'Krzywdzinski/o-piwie' 2021-01-22 11:03:07 +01:00
c0fd3ead8b Upload files to 'Krzywdzinski/ciecie-szkla' 2021-01-22 11:02:47 +01:00
370f02061f Added project requirements document 2.0.1 2021-01-21 21:20:27 +01:00
26dc220970 Merge pull request 'raport_z_testow' (#55) from s440552/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#55
2021-01-19 22:05:41 +01:00
e807fd87b5 Merge pull request 'Dokumentacja techniczna aplikacji BusinessCard' (#57) from s434815/DPRI_doc_20-21:s434815-patch-1 into master
Reviewed-on: bikol/DPRI_doc_20-21#57
2021-01-19 20:38:26 +01:00
8fbbd8f840 Dokumentacja techniczna aplikacji BusinessCard 2021-01-19 20:33:42 +01:00
361b6ae893 Merge pull request 'dokumentacja_deweloperska' (#1) from bikol/DPRI_doc_20-21:master into master
Reviewed-on: s440552/DPRI_doc_20-21#1
2021-01-19 18:18:49 +01:00
6765607cc5 Prześlij pliki do 'Marciniak/possessed-redeemer' 2021-01-19 18:17:39 +01:00
6b478bb176 Prześlij pliki do 'Marciniak/possessed-redeemer' 2021-01-19 16:44:17 +01:00
d319dfb9db Merge pull request 'dokumentacja techniczna' (#54) from s434659/DPRI_doc_20-21:analiza-dyskusji into master
Reviewed-on: bikol/DPRI_doc_20-21#54
2021-01-19 13:54:50 +01:00
7e786f888e dokumentacja techniczna 2021-01-19 00:56:23 +01:00
f6089f71f7 Merge pull request 'dokumentacja Brewed' (#53) from s434723/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#53
2021-01-18 22:54:58 +01:00
402c0a0878 Merge pull request 'wymagania_projektowe' (#52) from s440552/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#52
2021-01-18 22:52:55 +01:00
2dd0b329b6 Merge branch 'master' into master 2021-01-18 16:26:14 +01:00
04b5bd3eaa Merge pull request 'Wizja i zakres projektu WhisperPress' (#49) from s434690/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#49
2021-01-18 12:54:15 +01:00
63d3b0f94a Merge pull request 'MealyCompiler (Solomonoff) imporved documentation' (#44) from s434749/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#44
2021-01-18 10:07:37 +01:00
5b6bed8c09 Merge pull request 'master' (#48) from s434802/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#48
2021-01-18 09:02:39 +01:00
mevryn
fc0333b1ae dokumentacja Brewed 2021-01-18 00:41:07 +01:00
c365d60cb1 Prześlij pliki do 'Marciniak/possessed-redeemer' 2021-01-17 14:08:11 +01:00
aee5f97351 Update FlatMapp project requirements 2021-01-16 17:41:50 +01:00
abe48879bd Update FlatMapp project requirements 2021-01-16 17:41:31 +01:00
8789bcd49e Prześlij pliki do 'Witkowski/flat-mapp' 2021-01-16 17:40:31 +01:00
6d1bbe2c80 Merge pull request 'Zaktualizowany opis pracy w zespole' (#50) from s434804/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#50
2021-01-16 14:55:50 +01:00
2b7355875f Merge branch 'master' into master 2021-01-16 13:26:14 +01:00
907659e28a Zaktualizuj 'Witkowski/aport-me/dokument_wymagan_projektowych.md' 2021-01-16 13:21:08 +01:00
8715acfd7f Merge pull request 'wymagania-projektowe' (#47) from s434723/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#47
2021-01-15 19:22:48 +01:00
d03e590ce1 Wizja i zakres projektu WhisperPress 2021-01-15 18:42:10 +01:00
528257bfc9 Update 'Przybylski/awionika/wizja_projektu.md' 2021-01-14 21:40:16 +01:00
993ea717ef Update 'Przybylski/awionika/wymagania_projektowe.md' 2021-01-14 21:39:58 +01:00
489100232a Update 'Przybylski/awionika/wymagania_projektowe.md' 2021-01-14 21:38:59 +01:00
0e0fd95081 Update 'Przybylski/awionika/wizja_projektu.md' 2021-01-14 21:38:31 +01:00
WSebo
57277742dd Update dokumentacji 2021-01-14 21:34:35 +01:00
mevryn
6b7fb92ce3 wymagania-projektowe 2021-01-12 14:04:08 +01:00
7ce3b8fce0 Merge pull request 'dokument wizji i wymagań' (#45) from s434659/DPRI_doc_20-21:analiza-dyskusji into master
Reviewed-on: bikol/DPRI_doc_20-21#45
2021-01-12 00:01:49 +01:00
f1b4ed024d Merge pull request 'Dodanie pliku wymagań projektowych' (#46) from s434779/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#46
2021-01-11 23:59:50 +01:00
4b9b7512de Dodanie pliku wymagań projektowych 2021-01-10 23:30:32 +01:00
9b79130b0f poprawiony wygląd wymagań 2021-01-10 21:18:27 +01:00
5666a9551a dokument wizji i wymagań 2021-01-10 21:11:19 +01:00
Alagris
5070567b40 MealyCompiler (Solomonoff) imporved documentation 2021-01-09 10:44:49 +01:00
69ee43dfdb Merge pull request 'Pomocnik Profesora prof. Michał Hanckowiak' (#43) from s440056/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#43
2021-01-05 17:53:35 +01:00
489a53557a Merge pull request 'Dokumenty - SushiBar - dr Tomasz Piłka' (#12) from s426206/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#12
2021-01-05 12:35:16 +01:00
44b1f8e872 Merge pull request 'develop team files' (#29) from s434732/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#29
2021-01-05 12:34:55 +01:00
pawroz
bb1d24a4a2 Pomocnik Profesora prof. Michał Hanckowiak 2021-01-04 20:25:49 +01:00
8efdc9827e Merge pull request 'wizja i wymagania projektowe' (#42) from s434817/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#42
2021-01-04 11:33:06 +01:00
525460d60c Merge pull request 'vision + project scope' (#39) from s434749/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#39
2021-01-04 09:52:03 +01:00
4b26539c30 Merge pull request 'master' (#40) from s153070/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#40
2020-12-23 10:50:57 +01:00
43a397b0f0 Merge pull request 'Wizja i wymagania - update' (#41) from s434795/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#41
2020-12-23 10:50:30 +01:00
c3d9380303 Usuń 'Ostateczny dokument wymagań projektowych.pdf' 2020-12-23 01:36:11 +01:00
f3abdc4e75 Usuń 'Ostateczna wizja projektu.pdf' 2020-12-23 01:35:58 +01:00
f03bb12e4f Prześlij pliki do '' 2020-12-23 01:32:26 +01:00
5aff9e0c25 Prześlij pliki do 'Hanckowiak/sprawozdania' 2020-12-23 01:14:46 +01:00
46df9bb322 Usuń 'Hanckowiak/sprawozdania/Dokument wymagań projektowych.docx' 2020-12-23 01:13:02 +01:00
156191a67f Usuń 'Hanckowiak/sprawozdania/Dokument wizji projektu(poprawiony).pdf' 2020-12-23 01:08:35 +01:00
Daniel Matuszewski
5e27202fd2 docs complete 2020-12-21 18:40:12 +01:00
Daniel Matuszewski
3dab14ab12 beta version 2020-12-21 11:35:13 +01:00
4bdc6659c1 Merge pull request 'Pomocnik Profesora Wizja projektu - prof. Michał Hanckowiak' (#38) from s440056/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#38
2020-12-21 10:07:22 +01:00
34dfafe015 Merge branch 'master' into master 2020-12-20 20:47:04 +01:00
Alagris
7a90f34370 vision + project scope 2020-12-20 19:42:46 +01:00
pawroz
0888bd83e1 wizja projektu - Pp 2020-12-19 13:43:43 +01:00
c07d5951d2 Merge pull request 'Wizja i wymagania projektowe' (#31) from s434795/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#31
2020-12-18 13:30:04 +01:00
a58e498a61 Merge pull request 'PickApp: Added project requirements' (#23) from s434607/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#23
2020-12-17 16:40:30 +01:00
33c9dc8ca0 Prześlij pliki do 'Zywica/pickup' 2020-12-16 08:31:26 +01:00
e2ea9c1f9c Usuń 'Zywica/pickup/Project Requirements.pdf' 2020-12-16 08:29:45 +01:00
12e0656188 Merge branch 'master' into master 2020-12-16 08:23:10 +01:00
b6571b4258 Merge pull request 'dr. Piłka - Dodanie dokumentow - plannaplan' (#4) from s434812/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#4
2020-12-15 09:31:28 +01:00
2f3219084b Merge pull request 'wizja i zakres projektu BusinessCard' (#10) from s434820/DPRI_doc_20-21:s434820-patch-1 into master
Reviewed-on: bikol/DPRI_doc_20-21#10
2020-12-15 09:27:39 +01:00
21d05ffeef Prześlij pliki do 'Hanckowiak/gameweb' 2020-12-14 18:48:55 +01:00
26754170a2 Prześlij pliki do 'Hanckowiak/gameweb' 2020-12-14 18:46:01 +01:00
59f0c94239 Merge pull request 'Dodanie dokumentów z wizją i zakresem projektu "Wycena -RP"' (#34) from s434823/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#34
2020-12-14 11:50:17 +01:00
02c0838ef8 Merge pull request 'Dokument Wymagań Projektowych' (#27) from s440056/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#27
2020-12-14 11:49:41 +01:00
ab7b415d94 Merge pull request 'first version of docs' (#32) from s153070/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#32
2020-12-14 11:48:41 +01:00
ea766c8833 Merge pull request 'Add UltiTracker document' (#30) from s434762/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#30
2020-12-14 10:47:06 +01:00
7732d7229c Merge pull request 'Platformowa gra w Unity: Dodanie dokumentu wymagań projektowych i wizji projektu' (#35) from s434797/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#35
2020-12-14 08:43:52 +01:00
68cb530d66 Merge pull request 'Generator Sprawdzianów - Dodanie Wizji Projektu i Wymagań Projektowych.' (#36) from s434735/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#36
2020-12-14 08:42:18 +01:00
498ad13fd0 Merge pull request 'Dodanie wizji projektu i wymagań projektowych dla awioniki' (#37) from s434802/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#37
2020-12-14 08:41:19 +01:00
458b3e5c44 Upload files to 'Przybylski/awionika'
Dodanie wizji projektu i wymagań projektowych
2020-12-13 23:56:04 +01:00
6e3fa53afe Dodanie Wizji Projektu i Wymagań Projektowych. 2020-12-13 23:33:27 +01:00
Kamil Tyrek
5a0cf4880a Dodanie dokumentu wymagań projektowych i wizji projektu 2020-12-13 20:21:49 +01:00
12685ea03d Dodanie dokumentów z wizją i zakresem projektu "Wycena -RP" 2020-12-09 18:04:04 +01:00
c310d556f9 Merge branch 'master' into master 2020-12-08 23:47:33 +01:00
nowaak
756a79d48c Update UltiTracker - wymagania projektowe.pdf 2020-12-08 23:46:58 +01:00
59e63749e0 Merge pull request 'Dostosowanie dokumentu "Wymagania projektowe" do uwag promotora.' (#24) from s434744/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#24
2020-12-07 15:26:35 +01:00
1485013b95 Merge pull request 'Added Travellan's scope document' (#33) from s434604/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#33
2020-12-07 15:24:02 +01:00
b7818f6fea Merge branch 'master' into master 2020-12-06 21:31:58 +01:00
8c9834e546 Added Travellan's scope document 2020-12-02 20:15:13 +01:00
81b32b6770 Merge pull request 'wizja projektu' (#25) from s434782/DPRI_doc_20-21:s434782-patch-1 into master
Reviewed-on: bikol/DPRI_doc_20-21#25
2020-12-02 07:49:37 +01:00
strus100
e120897820 first version of docs 2020-12-01 19:56:06 +01:00
7e8466dec3 Dokument wizji projektu
Wizja dla projektu "Sprawdzarka z zajęć"
2020-12-01 00:18:16 +01:00
c77e944093 Dokument wymagań projektowych
Dla projektu "Sprawdzarka z zajęć"
2020-12-01 00:16:44 +01:00
d07d57f2ba Merge branch 'master' into master 2020-11-30 14:13:18 +01:00
c68a71efec Wymagania projektowe - SushiBar - dr Tomasz Piłka 2020-11-30 14:12:11 +01:00
6fb81e465c Merge pull request 'Carpool: project requirements document' (#28) from s440054/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#28
2020-11-30 12:04:20 +01:00
e2cec27817 Update: project boundaries 2020-11-29 20:09:39 +01:00
9d9da8576b Update: project boundaries 2020-11-29 19:54:01 +01:00
6a7b577803 Update: project boundaries 2020-11-29 18:45:30 +01:00
207ad2cd10 Add external links 2020-11-29 18:42:05 +01:00
d75b6e0c5c Update: non-functional requirements 2020-11-29 18:27:24 +01:00
0e21edc744 Uaktualnienie kryteriów akceptacji semestr 2 2020-11-29 18:05:00 +01:00
Julian Kobryński
9d1d9f08de Repo and jira links added 2020-11-29 17:58:09 +01:00
Julian Kobryński
5ee96888da Subtitle typo fixed 2020-11-29 17:45:44 +01:00
2bee0737ac Merge pull request 'Dodanie wizji i wymagań projektowych - system skautingowy - profesor Dyczkowski' (#26) from s426197/DPRI_doc_20-21:dyczkowski-scouting-docs into master
Reviewed-on: bikol/DPRI_doc_20-21#26
2020-11-29 12:49:09 +01:00
nowaak
5482accfe4 Add UltiTracker document 2020-11-29 11:50:47 +01:00
bb3adfe0fe develop team files 2020-11-28 17:30:53 +01:00
6a7b78c760 Merge pull request '+ Create project requirements document. Update README.md' (#1) from carpool/docs into master
Reviewed-on: s440054/DPRI_doc_20-21#1
2020-11-26 20:28:45 +01:00
Norbert Litkowski
74e26a0ab0 + Create project requirements document. Update README.md 2020-11-26 20:17:15 +01:00
ae6893061d Merge branch 'master' into dyczkowski-scouting-docs 2020-11-25 11:45:19 +01:00
ce232ddec1 wizja projektu 2020-11-25 11:33:09 +01:00
89ea7e0d21 Dokument Wymagań Projektowych
Dokument Wymagań Projektowych - Pomocnik Profesora - Zapisy 

Paweł Rozpłochowski
2020-11-25 11:25:55 +01:00
33026a18c0 Prześlij pliki do 'Zywica/ork'
Dostosowanie dokumentu "Wymagania projektowe" do uwag promotora.
2020-11-25 00:01:04 +01:00
895f55b216 Added project requirements 2020-11-24 19:22:07 +01:00
04e56cf5ea Merge pull request 'added "Wymagania Projektowe"' (#8) from s434744/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#8
2020-11-24 16:10:53 +01:00
f6100391e5 Merge pull request 'Added DevMatch project documentation' (#3) from s394161/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#3
2020-11-24 16:01:44 +01:00
6f95826186 Merge pull request 'Upload files to 'Witkowski/transport-platform'' (#22) from s442613/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#22
2020-11-23 21:46:39 +01:00
ed9b6c5e78 Upload files to 'Witkowski/transport-platform'
requirement
2020-11-23 21:25:18 +01:00
40e513d509 Merge pull request 'Rentall project requierements doc' (#16) from s432759/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#16
2020-11-23 17:25:40 +01:00
9d34856b85 Delete 'witkowski/PanaCea/PanaCea final Documentation.pdf' 2020-11-23 13:09:34 +01:00
cdb1759a36 Merge pull request 'master' (#21) from s439546/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#21
2020-11-23 13:00:15 +01:00
80eb840b51 Merge pull request 'Upload files to 'Witkowski/pana-cea'' (#1) from s439546-patch-1 into master
Reviewed-on: s439546/DPRI_doc_20-21#1
2020-11-23 12:59:10 +01:00
0f8eafaa28 Upload files to 'Witkowski/pana-cea' 2020-11-23 12:58:16 +01:00
f7a1386a2c Merge pull request 'witkowski/PanaCea' (#20) from s439546/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#20
2020-11-23 12:51:46 +01:00
cf8f5ea556 witkowski/PanaCea 2020-11-23 11:52:10 +01:00
9cf1ed96aa Merge pull request 'doc without comments' (#18) from s150169/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#18
2020-11-22 23:10:39 +01:00
d1dc3c71c7 Doc added 2020-11-22 23:09:02 +01:00
542914eb91 Subir archivos a 'Witkowski/pool-aid' 2020-11-22 23:05:11 +01:00
d575bc4f17 Merge pull request 'Added Project Requirements document' (#17) from s150169/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#17
2020-11-22 22:59:31 +01:00
0ab7b789fb Subir archivos a 'Witkowski/pool-aid' 2020-11-22 22:52:17 +01:00
cd8b4601ae Загрузить файлы 'Zywica/rents' 2020-11-22 17:53:10 +01:00
a54c9975db Merge pull request 'dokument wymagań projektowych dla projektu Conference Web' (#15) from s434742/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#15
2020-11-22 17:07:19 +01:00
946f8999ab poprawka wg. wskazań dr Witkowskiego 2020-11-22 15:11:49 +01:00
0e0e47165f Merge pull request 'Wymagania projektowe' (#11) from s440551/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#11
2020-11-21 20:52:53 +01:00
380e14fbd6 Merge pull request 'Added AportMe project requirements document' (#14) from s434804/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#14
2020-11-21 20:52:21 +01:00
28e9d1214c Merge pull request 'Uploading FlatMapp project requirements' (#13) from s434657/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#13
2020-11-21 20:52:09 +01:00
f7091f82f0 Added AportMe project requirements document 2020-11-21 20:18:18 +01:00
39bc384a68 Uploading FlatMapp project requirements 2020-11-21 17:16:27 +01:00
e94dd98627 Wizja projektu 2020-11-21 14:28:32 +01:00
2642c20cc6 dokument wymagan projektowych 2020-11-20 19:17:05 +01:00
10e0dac1e7 Wymagania projektowe 2020-11-20 11:56:19 +01:00
c89a2f208e wizja i zakres projektu BusinessCard 2020-11-19 20:40:35 +01:00
6685dbf52b Merge pull request 'Dokumenty Inteligentny Dom - Wizja oraz Wymagania.' (#6) from s434685/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#6
2020-11-18 08:14:42 +01:00
9524bc85cf Merge pull request 'Dokumenty dla projektu Niezbędnik Studenta' (#9) from s434741/niezbednikstudenta_docs:master into master
Reviewed-on: bikol/DPRI_doc_20-21#9
2020-11-18 08:14:24 +01:00
f53a9ad642 Update 'Dyczkowski/niezbednik-studenta/dokument_wymagan_projektowych.md' 2020-11-18 00:29:54 +01:00
b58276f0b8 Upload files to 'Dyczkowski/niezbednik-studenta' 2020-11-18 00:28:46 +01:00
f5c9bdbebc added "Wymagania Projektowe" 2020-11-17 15:38:56 +01:00
8af2d9a0dc Merge pull request 'Uploading Langsheet project requirements' (#7) from s434654/DPRI_doc_20-21:master into master
Reviewed-on: bikol/DPRI_doc_20-21#7
2020-11-16 23:05:57 +01:00
1be9b0f0e0 Dodanie dokumentow
Signed-off-by: Marcin Woźniak <y0rune@aol.com>
2020-11-16 18:50:06 +01:00
ee656156ae Added DevMatch project documentation 2020-11-15 23:06:54 +01:00
acb53739d3 Prześlij pliki do 'Dyczkowski/inteligentny-dom'
Dokumenty Inteligentny Dom - Wizja oraz Wymagania.
2020-11-11 22:17:40 +01:00
Eryk Miszczuk
129df2821b Dodanie wizji i wymagań projektowych 2020-11-10 21:14:13 +01:00
423 changed files with 104101 additions and 2 deletions

Binary file not shown.

View File

@ -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

View File

@ -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

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

File diff suppressed because it is too large Load Diff

View File

@ -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