Różnice między wybraną wersją a wersją aktualną.
Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
sk2:projekt [2024/02/02 14:07] jkonczak aktualizacja linku do instytutowego serwera git |
sk2:projekt [2024/11/11 20:19] (aktualna) jkonczak [Użyteczność!] |
||
---|---|---|---|
Linia 1: | Linia 1: | ||
- | ====== SK2 – projekt zaliczeniowy z programowania (2023/2024) ====== | + | ====== SK2 – projekt zaliczeniowy z programowania (2024/2025) ====== |
Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt __ustalony z prowadzącym__. | Do zaliczenia pierwszej części laboratoriów (programowanie) należy zrealizować projekt __ustalony z prowadzącym__. | ||
Linia 21: | Linia 21: | ||
- Radio internetowe – serwer ma kolejkę plików dźwiękowych, które kolejno strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki. Wymagane GUI. | - Radio internetowe – serwer ma kolejkę plików dźwiękowych, które kolejno strumieniuje do wszystkich podłączonych klientów. Klienci mogą wgrywać na serwer nowe pliki, widzą bieżący stan kolejki i mogą wykonywać dowolne operacje na niej, mogą też zlecić przeskoczenie do następnego pliku z kolejki. Wymagane GUI. | ||
- Inny projekt, uzgodniony z prowadzącym. | - Inny projekt, uzgodniony z prowadzącym. | ||
- | | + | |
+ | <small> | ||
Więcej pomysłów na projekty można znaleźć na stronach pozostałych prowadzących: | Więcej pomysłów na projekty można znaleźć na stronach pozostałych prowadzących: | ||
+ | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* http://www.cs.put.poznan.pl/ddwornikowski/courses/projekty_sieci2_2015.html | * http://www.cs.put.poznan.pl/ddwornikowski/courses/projekty_sieci2_2015.html | ||
- | * http://www.cs.put.poznan.pl/mkalewski/files/zadania.pdf | + | * http://www.cs.put.poznan.pl/mkalewski/files/zadania.pdf / https://www.cs.put.poznan.pl/mkalewski/edu/sk/doc/zadania.pdf |
* http://www.cs.put.poznan.pl/jkonczak/misc/lukasz_tematy_projektow.pdf [projekty Łukasza Piątkowskiego, cached] | * http://www.cs.put.poznan.pl/jkonczak/misc/lukasz_tematy_projektow.pdf [projekty Łukasza Piątkowskiego, cached] | ||
* http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html | * http://www.cs.put.poznan.pl/ksiek/sk2/zadania.html | ||
* http://www.cs.put.poznan.pl/mboron/prez/zasady_projektow.pdf | * http://www.cs.put.poznan.pl/mboron/prez/zasady_projektow.pdf | ||
- | | + | </small> |
Linia 53: | Linia 55: | ||
<html><div style="margin: -1.2em 0 0 0"/></html> | <html><div style="margin: -1.2em 0 0 0"/></html> | ||
* **ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji ''connect'' (firewall), zerwanie połączenia, etc.,** | * **ma działać w sieciach rozległych (przez internet) – czyli obsługiwać opóźnienia, brak informacji zwrotnej z funkcji ''connect'' (firewall), zerwanie połączenia, etc.,** | ||
- | * **ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. nie udzielać odpowiedzi w quizie / kahoocie),** | + | * **ma uwzględniać że użytkownicy mogą się dowolnie łączyć, rozłączać (np. w trakcie kiedy serwer wykonuje na ich rzecz działanie), nie robić nic (np. nie udzielać odpowiedzi w quizie / kahoocie),** \\ <small>(w tym wymaganiu chodzi o to, żeby użytkownik łączący się "nie w porę" też dostał sensowny komunikat, a zakończenie / zerwanie / utrata połączenia bądź nieaktywność gracza nie wpłynęła negatywnie na pracę serwera; proszę nie próbować implementować "powracania" rozłączonego użytkownika)</small> |
* jeśli program ma parametry konfiguracyjne, to powinny być konfigurowalne a nie ustawione na sztywno w kodzie; proszę się też zastanowić co użytkownik może chcieć ustawić (i pozwolić mu na to), | * jeśli program ma parametry konfiguracyjne, to powinny być konfigurowalne a nie ustawione na sztywno w kodzie; proszę się też zastanowić co użytkownik może chcieć ustawić (i pozwolić mu na to), | ||
* dla niewielu często zmienianych parametrów wystarczy linia poleceń, w innym przypadku proszę używać plików konfiguracyjnych, | * dla niewielu często zmienianych parametrów wystarczy linia poleceń, w innym przypadku proszę używać plików konfiguracyjnych, | ||
+ | * serwer musi nasłuchiwać na dowolnym adresie IP, a klient musi mieć możliwość wyboru adresu IP serwera bez ponownej kompilacji | ||
* w interaktywnych projektach (edytor grafiki, gra) klienci mają widzieć co się dzieje (np. ktoś przesuwa figurę na rysunku, inny gracz oddał głos na ruch), w projektach gdzie klient widzi stan serwera (job scheduler, dropbox) zmiany stanu mają mu być pokazywane bez konieczności odpytywania (np. klient widzi że jego zadanie się skończyło, każda zmiana pliku jest bez zbędnej zwłoki synchronizowana a konflikty zgłaszane), | * w interaktywnych projektach (edytor grafiki, gra) klienci mają widzieć co się dzieje (np. ktoś przesuwa figurę na rysunku, inny gracz oddał głos na ruch), w projektach gdzie klient widzi stan serwera (job scheduler, dropbox) zmiany stanu mają mu być pokazywane bez konieczności odpytywania (np. klient widzi że jego zadanie się skończyło, każda zmiana pliku jest bez zbędnej zwłoki synchronizowana a konflikty zgłaszane), | ||
* nie można wymagać wszechwiedzy od komponentów systemu: np. w job schedulerze klient nie będzie wiedział znikąd gdzie są maszyny obliczeniowe, od użytkowników komunikatorów internetowych nie należy wymagać znajomości adresu serwera (zamiast tego można przykładowo dostarczyć z aplikacją plik konfiguracyjny). | * nie można wymagać wszechwiedzy od komponentów systemu: np. w job schedulerze klient nie będzie wiedział znikąd gdzie są maszyny obliczeniowe, od użytkowników komunikatorów internetowych nie należy wymagać znajomości adresu serwera (zamiast tego można przykładowo dostarczyć z aplikacją plik konfiguracyjny). | ||
Linia 95: | Linia 98: | ||
===== Terminy ===== | ===== Terminy ===== | ||
- | * **Tematy projektów należy uzgodnić nie później niż do 24.11.2023.** \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. | + | * **Tematy projektów należy uzgodnić nie później niż do 30.11.2024.** \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. |
* O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu opis projektu musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego. | * O skończeniu projektu należy poinformować prowadzącego mailowo. Do tego czasu opis projektu musi być zaakceptowany przez prowadzącego i prowadzący musi mieć dostęp do kodu źródłowego. | ||
- | * **Mail z informacją o skończeniu projektu należy wysłać najpóźniej 12.01.2024**. \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. | + | * **Mail z informacją o skończeniu projektu należy wysłać najpóźniej 11.01.2025**. \\ Przekroczenie tego terminu skutkuje obniżeniem oceny o 0.5. |
- | * **Działający projekt należy zaprezentować w laboratorium przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 31.01.2024)**. | + | * **Działający projekt należy zaprezentować w laboratorium przed końcem okresu zajęć dydaktycznych semestru zimowego (tj. przed 31.01.2025)**. |
* Wysłanie maila z informacją o skończeniu projektu a zaprezentowanie projektu w laboratorium muszą dzielić przynajmniej 2 dni (na przejrzenie kodu przez prowadzącego). | * Wysłanie maila z informacją o skończeniu projektu a zaprezentowanie projektu w laboratorium muszą dzielić przynajmniej 2 dni (na przejrzenie kodu przez prowadzącego). | ||
* Zaprezentowanie projektu w laboratorium projektów możliwe jest na/po zajęciach lub po mailowym uzgodnieniu z prowadzącym. | * Zaprezentowanie projektu w laboratorium projektów możliwe jest na/po zajęciach lub po mailowym uzgodnieniu z prowadzącym. | ||
* Do zaliczenia przedmiotu konieczna jest pozytywna ocena z projektu. | * Do zaliczenia przedmiotu konieczna jest pozytywna ocena z projektu. | ||