From 427f1a44ca1783a3ade7db5d91d6dc45ee0614b1 Mon Sep 17 00:00:00 2001 From: Jassem Date: Tue, 1 Oct 2024 16:39:27 +0200 Subject: [PATCH] aktualizacja 2024 --- ...ystemów_informatycznych-checkpoint.ipynb} | 6 +- ...systemów_analizy_danych-checkpoint.ipynb} | 2 +- ..._platformy_analizy_danych-checkpoint.ipynb | 49 ++ ...02_rozwój_systemów_informatycznych.ipynb | 464 ++++++++++++++++++ ...3_ewaluacja_systemów_analizy_danych.ipynb | 281 +++++++++++ ...aawansowane_platformy_analizy_danych.ipynb | 49 ++ ...b => 2023_04_systemy_analizy_danych.ipynb} | 0 7 files changed, 847 insertions(+), 4 deletions(-) rename materiały na wykład/{02_prototypowanie_systemy_kontroli_wersji.ipynb => .ipynb_checkpoints/02_rozwój_systemów_informatycznych-checkpoint.ipynb} (97%) rename materiały na wykład/{03_ciągła_integracja_ewaluacja.ipynb => .ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb} (99%) create mode 100644 materiały na wykład/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych-checkpoint.ipynb create mode 100644 materiały na wykład/02_rozwój_systemów_informatycznych.ipynb create mode 100644 materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb create mode 100644 materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb rename materiały na wykład/{04_systemy_analizy_danych.ipynb => 2023_04_systemy_analizy_danych.ipynb} (100%) diff --git a/materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb b/materiały na wykład/.ipynb_checkpoints/02_rozwój_systemów_informatycznych-checkpoint.ipynb similarity index 97% rename from materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb rename to materiały na wykład/.ipynb_checkpoints/02_rozwój_systemów_informatycznych-checkpoint.ipynb index 2c09da8..d123a9c 100644 --- a/materiały na wykład/02_prototypowanie_systemy_kontroli_wersji.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/02_rozwój_systemów_informatycznych-checkpoint.ipynb @@ -6,8 +6,8 @@ "source": [ "
\n", "

Systemy informatyczne analizy danych

\n", - "

2. Prototypowanie, systemy kontroli wersji[wykład]

\n", - "

Filip Graliński, Krzysztof Jassem (2023)

\n", + "

2. \\Rozwój systemów informatycznych[wykład]

\n", + "

Filip Graliński, Krzysztof Jassem (2024)

\n", "
" ] }, @@ -223,7 +223,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.13" + "version": "3.9.12" }, "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb b/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb similarity index 99% rename from materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb rename to materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb index 0387185..144e1eb 100644 --- a/materiały na wykład/03_ciągła_integracja_ewaluacja.ipynb +++ b/materiały na wykład/.ipynb_checkpoints/03_ewaluacja_systemów_analizy_danych-checkpoint.ipynb @@ -273,7 +273,7 @@ "name": "python", "nbconvert_exporter": "python", "pygments_lexer": "ipython3", - "version": "3.9.13" + "version": "3.9.12" }, "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", "title": "Przygotowanie do projektu badawczo-rozwojowego", diff --git a/materiały na wykład/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych-checkpoint.ipynb b/materiały na wykład/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych-checkpoint.ipynb new file mode 100644 index 0000000..565fe74 --- /dev/null +++ b/materiały na wykład/.ipynb_checkpoints/04_zaawansowane_platformy_analizy_danych-checkpoint.ipynb @@ -0,0 +1,49 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne analizy danych

\n", + "

4. Zaawansowane platformy analizy danych[wykład]

\n", + "

Filip Graliński (2024)

\n", + "
" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "metadata": {}, + "outputs": [], + "source": [] + } + ], + "metadata": { + "author": "Krzysztof Jassem", + "email": "jassem@amu.edu.pl", + "kernelspec": { + "display_name": "Python 3 (ipykernel)", + "language": "python", + "name": "python3" + }, + "lang": "pl", + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.9.12" + }, + "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/02_rozwój_systemów_informatycznych.ipynb b/materiały na wykład/02_rozwój_systemów_informatycznych.ipynb new file mode 100644 index 0000000..5d1fb03 --- /dev/null +++ b/materiały na wykład/02_rozwój_systemów_informatycznych.ipynb @@ -0,0 +1,464 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne analizy danych

\n", + "

2. Rozwój systemów informatycznych[wykład]

\n", + "

Filip Graliński, Krzysztof Jassem (2024)

\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Prototyp

\n", + "Prototyp to wynik częściowej implementacji, posiadający wybrane cechy produktu końcowego.\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Cele prototypowania\n", + " * Zademonstrowanie umiejętności wykonania produktu końcowego\n", + " * Określenie realistycznych wymagań końcowych\n", + " * Przekonanie się o wpływie innych systemów, środowisk na produkt. \n", + " * Sprawdzenie implementacji kluczowych funkcji\n", + "\n", + "## Potencjalne efekty prototypowania\n", + "* Wykrycie nieporozumień między klientem i wykonawcą \n", + "* Określenie brakujących funkcji \n", + "* Wykrycie błędów w specyfikacji\n", + "* Przewidywanie przyszłych trudności " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototyp poziomy a pionowy\n", + "### Prototyp poziomy (Horizontal Prototype)\n", + "\n", + "**Prototyp poziomy** obrazuje całość systemu, podkreślając interakcję z użytkownikiem, a nie wnikając w funkcjonalności.\n", + "\n", + "Przykłady prototypów poziomych w informatyce:\n", + " * Prototyp papierowy\n", + " * Makieta statyczna\n", + " * Makieta dynamiczna\n", + " * Graficzny interfejs użytkownika" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Prototyp papierowy

\n", + " \n", + "Prototyp papierowy to sposób reprezentacji produktu cyfrowego za pomocą wycinanek z papieru. \n", + " \n", + "* Służy do zrozumienia koncepcji produktu cyfrowego przez użytkownika. \n", + "* Dla autora koncepcji prototyp taki służy do prześledzenia reakcji użytkowników na przyszłe działanie systemu przed jego realizacją.\n", + "\n", + "Prototypowanie papierowe - etapy :\n", + "\n", + "\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Makieta statyczna

\n", + " \n", + " \n", + "Makieta statyczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji, ale nie jest funkcjonalny. \n", + "\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Makieta dynamiczna

\n", + " \n", + " \n", + "Makieta dynamiczna to cyfrowy projekt aplikacji, który zawiera pewne elementy docelowej konstrukcji i wskazuje interakcje z użytkownikiem. \n", + "\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Graficzny interfejs użytkownika (GUI)

\n", + "\n", + " Graficzny interfejs użytkownika to sposób komunikacji użytkownika z komputerem za pomocą elementów graficznych.\n", + " \n", + "Prototypem poziomym nazwiemy GUI, który: \n", + "\n", + " \n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototyp pionowy (Vertical Prototype)\n", + "**Prototyp pionowy** to pełna realizacja kluczowej (kluczowych) funkcji systemu.\n", + "\n", + "Cele prototypowania pionowego:\n", + "* sprawdzenie wyboru technologii\n", + "* pomiary wydajności\n", + "* sprawdzenie poprawności algorytmów i struktur danych\n", + "\n", + "Realizacja prototypów pionowych jest polecana w sytuacji, gdy wykonanie kluczowych funkcji systemu obarczone jest wysokim ryzykiem." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototypowanie z porzuceniem a prototypowanie ewolucyjne" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototypowanie z porzuceniem (Thow-away Prototyping)\n", + "\n", + "W **prototypowaniu z porzuceniem** budowane są kolejne wersje prototypów, a niektóre z nich są porzucane.\n", + "\n", + "Cele prototypowania z porzuceniem:\n", + "* minimalizacja ryzyka,\n", + "* głębokie zrozumienie problemów technicznych\n", + "\n", + "Koszty:\n", + " * Koszty prototypowania z porzuceniem są wysokie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Prototypowanie ewolucyjne (Ewolutionary Prototyping)\n", + "\n", + "**Prototypowanie ewolucyjne** polega na stopniowym rozszerzaniu prototypu, aż spełnia on wszystkie wymagania... \n", + "\n", + "...Wtedy prototyp staje się produktem.\n", + "\n", + "Prototyp ewolucyjny powinien być budowany:\n", + " * w środowisku zbliżonym do produkcyjnego, \n", + " * z dużą dbałością o jakość." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Prototypowanie - podsumowanie\n", + "\n", + "* Prototypy tworzy się w celu zminimalizowania ryzyka niepowodzenia produktu. \n", + "* W prototypach poziomych chodzi o zobrazowanie wszystkich funkcji. \n", + "* W prototypach pionowych chodzi o szczegóły techniczne.\n", + "* Prototypowanie z porzuceniem oywa się z reguły wszerz (prototypy poziome); \n", + " * jest bardziej kosztowne, ale minimalizuje ryzyko.\n", + "* Prototypowanie ewolucyjne odbywa się z reguły w głąb (prototypy pionowe); \n", + " * jest mniej kosztowne, ale bardziej ryzykowne." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Ciągła integracja

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Główne przesłanki CI

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przebieg pracy w Ciągłej Integracji\n", + "1. **Take Integrated Code**\n", + " * Pobieram kod z repozytorium.\n", + " * Instaluję kopię na swojej stacji roboczej. \n", + " \n", + "2. **Do Your Part**\n", + " * Opracowuję nowy kod.\n", + " * Opracowuję nowe testy jednostkowe.\n", + " \n", + "3. **Build on your machine**\n", + "\n", + " * **Repeat** \n", + " * Kompiluję swój kod i buduję wersję wykonywalną,\n", + " * Przeprowadzam testy jednostkowe,\n", + " * **Until**\n", + " * Kod się skompilował poprawnie oraz\n", + " * Testy zakończyły się powodzeniem.\n", + " \n", + "4. **Integrate with Repository**\n", + "\n", + " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n", + " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n", + " * **Go back to: Take Integrated Code**\n", + " * Przypadek 2. Tetsy się powodzą\n", + " * **Continue**\n", + " \n", + "5. **End Session**\n", + " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Dobre praktyki Ciągłej Integracji\n", + "(wg https://www.martinfowler.com/articles/continuousIntegration.html)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Maintain a Single Source Repository\n", + " * Załóż mainline (linię główną): \n", + " * Deweloperzy powinni większość pracy składać na mainline.\n", + " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n", + " * naprawy błędów,\n", + " * tymczasowych eksperymentów,\n", + " * oznaczania wersji publikowalnych." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Test Yourself\n", + " * Pisz testy jednostkowe.\n", + " * Uruchamiaj testy po każdej kompilacji." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Commits Everyday\n", + " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n", + " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n", + " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n", + " * Postulat wymaga rozbicia projektu na małe kawałki." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Every Commit Should Build the Mainline\n", + " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n", + " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Fix the Broken Builds Immediately\n", + "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n", + "Znalezienie i poprawienie blędu jest priorytetem, ale:\n", + " * Nie debugguj kodu na centralnym repozytorium. \n", + " * Przywróć wersję wykonywalną na \"mainline\".\n", + " * Debugguj kod na maszynie lokalnej." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Make it Easy to Run the Latest Executable\n", + "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n", + "* Jest to niezbędne do:\n", + " * testowania integracyjnego (tester),\n", + " * rozmów z klientem (zarząd lub sprzedawca),\n", + " * prowadzenia projektu (kierownik zespołu).\n", + "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Keep the Build Fast\n", + "\n", + " * Maximum 10 minut na build + testy.\n", + " * A jeśli testy trwają dłużej?\n", + " * Testy dwuetapowe:\n", + " * kompilacja + testy jednostkowe przy każdym commicie,\n", + " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Clone the Environment\n", + " * Przygotuj klon środowiska produkcyjnego:\n", + " * ta sama wersja systemu operacyjnego\n", + " * ta sama baza danych\n", + " * te same biblioteki (nawet jak ich nie potrzebujesz) \n", + " * Wszystkie testy przeprowadzaj na przygotowanym środowisku." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Can See What's Happening\n", + "System powinien informować użytkowników o swoim statusie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Automate Deployment\n", + " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n", + " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Narzędzia Ciągłej Integracji\n", + "\n", + "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n", + "\n", + "1. Jenkins\n", + "2. Circle CI\n", + "3. Team City\n", + "4. Bamboo\n", + "5. GitLab" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Korzyści z Ciągłej Integracji\n", + " * Minimalizacja ryzyka\n", + " * Łatwiejsze szacowanie terminu zakończenia prac\n", + " * Szybsza lokalizacja i naprawa błędów\n", + " * Świadomość stanu prac u całego zespołu\n", + " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n", + " * Możliwość pracy w środowisku rozproszonym\n", + " * Możliwość usunięcia bariery między wykonawcą i klientem" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład - Jenkins\n", + "\n", + "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n", + "\n" + ] + } + ], + "metadata": { + "author": "Krzysztof Jassem", + "email": "jassem@amu.edu.pl", + "kernelspec": { + "display_name": "Python 3 (ipykernel)", + "language": "python", + "name": "python3" + }, + "lang": "pl", + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.9.12" + }, + "subtitle": "02. Rozwój systemu informatycznego[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2024" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb b/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb new file mode 100644 index 0000000..85707d9 --- /dev/null +++ b/materiały na wykład/03_ewaluacja_systemów_analizy_danych.ipynb @@ -0,0 +1,281 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne analizy danych

\n", + "

3. Ewaluacja systemów analizy danych[wykład]

\n", + "

Filip Graliński, Krzysztof Jassem (2023)

\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Ciągła integracja

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + " \n", + "

Główne przesłanki CI

\n", + " \n", + "Ciągła integracja (CI) to praktyka rozwoju oprogramowania, w której:\n", + "\n", + "
" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "![Schemat CI/CD](obrazy/cicd.drawio.png \"Schemat CI/CD\")" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przebieg pracy w Ciągłej Integracji\n", + "1. **Take Integrated Code**\n", + " * Pobieram kod z repozytorium.\n", + " * Instaluję kopię na swojej stacji roboczej. \n", + " \n", + "2. **Do Your Part**\n", + " * Opracowuję nowy kod.\n", + " * Opracowuję nowe testy jednostkowe.\n", + " \n", + "3. **Build on your machine**\n", + "\n", + " * **Repeat** \n", + " * Kompiluję swój kod i buduję wersję wykonywalną,\n", + " * Przeprowadzam testy jednostkowe,\n", + " * **Until**\n", + " * Kod się skompilował poprawnie oraz\n", + " * Testy zakończyły się powodzeniem.\n", + " \n", + "4. **Integrate with Repository**\n", + "\n", + " * Przesyłam kod do repozytorium centralnego, skąd przesyłany jest do kompilacji i testów.\n", + " * Przypadek 1. W międzyczasie ktoś dodał swój kod do repozytorium. Kompilacja lub testy się nie powodzą.\n", + " * **Go back to: Take Integrated Code**\n", + " * Przypadek 2. Tetsy się powodzą\n", + " * **Continue**\n", + " \n", + "5. **End Session**\n", + " * Gdy powiodły się wszystkie testy, mogę zakończyć sesję." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Dobre praktyki Ciągłej Integracji\n", + "(wg https://www.martinfowler.com/articles/continuousIntegration.html)" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Maintain a Single Source Repository\n", + " * Załóż mainline (linię główną): \n", + " * Deweloperzy powinni większość pracy składać na mainline.\n", + " * Nie nadużywaj odgalęzień (branchów). Jeśli już, to tylko w celu:\n", + " * naprawy błędów,\n", + " * tymczasowych eksperymentów,\n", + " * oznaczania wersji publikowalnych.\n" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Automate the Build\n", + " * Wersja wykonywalna powinna być tworzona jednym poleceniem.\n", + " * Dotyczy to zarówno repozytorium centralnego, jak i maszyn lokalnych." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Test Yourself\n", + " * Pisz testy jednostkowe.\n", + " * Uruchamiaj testy po każdej kompilacji." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Commits Everyday\n", + " * Każdy powinien \"codziennie\" wypychać swój kod do linii głównej.\n", + " * Umożliwia to wczesne wykrywanie konfliktów, gdyż...\n", + " * Im wcześniej wykryje się konflikt, tym łatwiej go naprawić.\n", + " * Postulat wymaga rozbicia projektu na małe kawałki." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Every Commit Should Build the Mainline\n", + " * Nie odchodzisz od pracy z repozytorium, aż Twój kod nie przeszedł pełnych testów.\n", + " * Korzystaj z systemów ciągłej integracji (Cruise Control, Jenkins)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Fix the Broken Builds Immediately\n", + "Co zrobić, jeśli jednak kod na \"mainline\" się nie buduje? \n", + "Znalezienie i poprawienie blędu jest priorytetem, ale:\n", + " * Nie debugguj kodu na centralnym repozytorium. \n", + " * Przywróć wersję wykonywalną na \"mainline\".\n", + " * Debugguj kod na maszynie lokalnej." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Make it Easy to Run the Latest Executable\n", + "* Każdy członek zespołu (nie tylko deweloper) powinien mieć możliwość łatwego uruchomienia ostatniej wersji stabilnej.\n", + "* Jest to niezbędne do:\n", + " * testowania integracyjnego (tester),\n", + " * rozmów z klientem (zarząd lub sprzedawca),\n", + " * prowadzenia projektu (kierownik zespołu).\n", + "* W specjalnej lokalizacji przetrzymuj wersje stabilne - \"do pokazania\"." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Keep the Build Fast\n", + "\n", + " * Maximum 10 minut na build + testy.\n", + " * A jeśli testy trwają dłużej?\n", + " * Testy dwuetapowe:\n", + " * kompilacja + testy jednostkowe przy każdym commicie,\n", + " * testy integracyjne co pewien czas (np. po commicie wszystkich deweloperów)." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Clone the Environment\n", + " * Przygotuj klon środowiska produkcyjnego:\n", + " * ta sama wersja systemu operacyjnego\n", + " * ta sama baza danych\n", + " * te same biblioteki (nawet jak ich nie potrzebujesz) \n", + " * Wszystkie testy przeprowadzaj na przygotowanym środowisku." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Everyone Can See What's Happening\n", + "System powinien informować użytkowników o swoim statusie." + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "### Automate Deployment\n", + " * Zautomatyzowanie wdrożenia polega na napisaniu skryptów, które instalują system w docelowym środowisku.\n", + " * Pozwala to na szybką reakcję, gdy \"coś się dzieje\". " + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Narzędzia Ciągłej Integracji\n", + "\n", + "https://www.katalon.com/resources-center/blog/ci-cd-tools/\n", + "\n", + "1. Jenkins\n", + "2. Circle CI\n", + "3. Team City\n", + "4. Bamboo\n", + "5. GitLab" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Korzyści z Ciągłej Integracji\n", + " * Minimalizacja ryzyka\n", + " * Łatwiejsze szacowanie terminu zakończenia prac\n", + " * Szybsza lokalizacja i naprawa błędów\n", + " * Świadomość stanu prac u całego zespołu\n", + " * Możliwość kontynuowania prac w przypadku odejścia dewelopera\n", + " * Możliwość pracy w środowisku rozproszonym\n", + " * Możliwość usunięcia bariery między wykonawcą i klientem" + ] + }, + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "## Przykład - Jenkins\n", + "\n", + "https://git.wmi.amu.edu.pl/filipg/paper-cutter/src/branch/master/Jenkinsfile\n", + "\n" + ] + } + ], + "metadata": { + "author": "Krzysztof Jassem", + "email": "jassem@amu.edu.pl", + "kernelspec": { + "display_name": "Python 3 (ipykernel)", + "language": "python", + "name": "python3" + }, + "lang": "pl", + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.9.12" + }, + "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb b/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb new file mode 100644 index 0000000..565fe74 --- /dev/null +++ b/materiały na wykład/04_zaawansowane_platformy_analizy_danych.ipynb @@ -0,0 +1,49 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": {}, + "source": [ + "
\n", + "

Systemy informatyczne analizy danych

\n", + "

4. Zaawansowane platformy analizy danych[wykład]

\n", + "

Filip Graliński (2024)

\n", + "
" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "metadata": {}, + "outputs": [], + "source": [] + } + ], + "metadata": { + "author": "Krzysztof Jassem", + "email": "jassem@amu.edu.pl", + "kernelspec": { + "display_name": "Python 3 (ipykernel)", + "language": "python", + "name": "python3" + }, + "lang": "pl", + "language_info": { + "codemirror_mode": { + "name": "ipython", + "version": 3 + }, + "file_extension": ".py", + "mimetype": "text/x-python", + "name": "python", + "nbconvert_exporter": "python", + "pygments_lexer": "ipython3", + "version": "3.9.12" + }, + "subtitle": "06. Prototypowanie i ciągła integracja[wykład]", + "title": "Przygotowanie do projektu badawczo-rozwojowego", + "year": "2021" + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/materiały na wykład/04_systemy_analizy_danych.ipynb b/materiały na wykład/2023_04_systemy_analizy_danych.ipynb similarity index 100% rename from materiały na wykład/04_systemy_analizy_danych.ipynb rename to materiały na wykład/2023_04_systemy_analizy_danych.ipynb