refactor: move handbooks to sections

README.md

@@ -6,13 +6,13 @@ Teoretycznie powinno się tu znaleźć wszystko co powinieneś/aś wiedzieć o p
 
 - Jak dodać nową stronę?
 
-  1. Dodaj nowy plik .md folderze `content/docs/guides/` np. `mario.md`
+  1. Dodaj nowy plik .md folderze `content/docs/solvro/` np. `mario.md`
   2. W pliku `mario.md` musisz napisać tytuł i opis jako fronmatter, przykładowo:
 
   ```md
   ---
-  title: Web development
-  description: Oto jak w Solvro rozwijamy aplikacje webowe.
+  title: Gaming section
+  description: Oto jak w Solvro gramy w mario.
   ---
 
   Heeej, to jest treść strony!

astro.config.mjs

@@ -77,15 +77,23 @@ export default defineConfig({
               label: "Jak pisać dokumentacje?",
               link: "/how-to-write-docs",
             },
+            {
+              label: "Komunikacja",
+              link: "/communication",
+            },
+            {
+              label: "Jak używać githuba?",
+              link: "/github",
+            },
           ],
         },
         {
           label: "Solvro",
           autogenerate: { directory: "solvro" },
         },
         {
-          label: "Handbooki",
-          autogenerate: { directory: "guides" },
+          label: "Sekcje",
+          autogenerate: { directory: "sections" },
         },
         {
           label: "Projekty",

src/content/docs/guides/Github.md → src/content/docs/github.md

@@ -1,6 +1,8 @@
 ---
 title: Github
 description: Jak korzystać z Githuba w Solvro?
+sidebar:
+  order: 0
 ---
 
 _Działalność KN Solvro skoncentrowana jest wokół kodu, więc naturalnie nasz Github jest sercem naszej organizacji. Poniższy handbook ma przybliżyć strukturę i konwencję przyjęte na naszym GitHubie oraz przedstawić sposób i zasady pracy podczas działalności projektowej._
@@ -34,11 +36,11 @@ Dzięki publicznemu członkostwu widać Solvro na twoim profilu, a przede wszyst
 1. Wejdź na [https://github.com/orgs/Solvro/people](https://github.com/orgs/Solvro/people)
 2. Namierz siebie na liście członków i kliknij na swoją aktualną widoczność
 
-   ![informacja o prywatności członkostwa](../../../assets/github/image2.png)
+   ![informacja o prywatności członkostwa](../../assets/github/image2.png)
 
 3. Wybierz członkostwo publiczne, i tada! Jesteś już pełnoprawnym członkiem naszego koła.
 
-   ![opcja ustawienia publicznego członkostwa](../../../assets/github/image3.png)
+   ![opcja ustawienia publicznego członkostwa](../../assets/github/image3.png)
 
 ### Podaruj nam gwiazdki ⭐⭐⭐
 
@@ -47,11 +49,11 @@ Zachęcamy do gwiazdkowania naszych publicznych repozytoriów Pokażmy innym, ż
 1. Wchodzimy na listę repozytoriów. Ich publiczna liczba będzie tylko rosła (miejmy nadzieję).
 2. Wchodzimy po kolei w co fajniejsze projekty.
 
-   ![losowo wybrany projekt Solvro](../../../assets/github/image9.png)
+   ![losowo wybrany projekt Solvro](../../assets/github/image9.png)
 
 3. Zostawiamy gwiazdkacza ⭐\!
 
-   ![opcja gwiazdkowania repozytorium](../../../assets/github/image5.png)
+   ![opcja gwiazdkowania repozytorium](../../assets/github/image5.png)
 
 ## Nazewnictwo repozytoriów
 
@@ -149,7 +151,7 @@ Projekty mają wiele zaawansowanych diagramów, z których możecie korzystać w
 
 Podstawowym typem jest jednak tablica KANBAN, gdzie można dodawać zadania w formie draft, lub przypinać issues lub pull-requesty.
 
-![strona projektu](../../../assets/github/image8.png)
+![strona projektu](../../assets/github/image8.png)
 
 #### Flow pracy na boardzie
 
@@ -189,7 +191,7 @@ Jeśli nie rozumiesz technikaliów związanych z którymś z poniższych punktó
 
 Wchodzimy na naszą tablice zadań i przypisujemy się do zadania sygnalizując, że zgłaszamy się do jego zrobienia:
 
-![zgłaszanie się do PR](../../../assets/github/image6.png)
+![zgłaszanie się do PR](../../assets/github/image6.png)
 
 ### Rozpoczęcie pracy nad zadaniem
 
@@ -210,13 +212,13 @@ Wchodzimy na naszą tablice zadań i przypisujemy się do zadania sygnalizując
 1. Gdy jesteśmy gotowi, zmieniamy status taska na **In Review** (jeśli taki status jest w projekcie).
 2. Tworzymy pull requesta z naszego brancha na branch **main** lub **dev** (jeśli aplikacja na main jest już opublikowaną wersją produkcyjną).
 
-   ![przycisk otwórz PR](../../../assets/github/image7.png)
+   ![przycisk otwórz PR](../../assets/github/image7.png)
 
 3. Dodajemy znaczący tytuł (najlepiej powiązany z nazwą lub numerem taska/tasków) i krótko wypisujemy co zmieniliśmy lub dodaliśmy. Jeśli napotkaliśmy jakiś problem/dylemat, możemy wyjaśnić jak go rozwiązaliśmy, jakiej dokonaliśmy decyzji i dlaczego. Jeśli z jakiegoś powodu nie wykonaliśmy 100% zakresu zadania, to jest to dobre miejsce żeby o tym wspomnieć. Jeśli chcesz ładnie sformatować swój opis, obczaj [tą szybką ściągę do gh markdowna](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet).
 4. Można oznaczyć swojego techleada jako reviewer (opcjonalne).
 5. Po prawej na dole, w sekcji _Development_ możesz przypiąć **issue** (np. swoje zadanie), który zostanie automatycznie zamknięty po zmergowaniu tego pull requesta.
 
-   ![dodawanie issues do PR](../../../assets/github/image4.png)
+   ![dodawanie issues do PR](../../assets/github/image4.png)
 
 6. Oczekujemy na code review od naszego techleada.
 7. Przeglądamy komentarze, wprowadzamy sugestie i dyskutujemy nad rzeczami, z którymi się nie zgadzamy. Zadajemy pytania i wprowadzamy zmiany, commitujemy i pushujemy.
@@ -278,5 +280,5 @@ Uwaga: Oprócz README repozytoriów, każdy projekt (kanban board) ma też swoje
 
 To już koniec tego handbooka. Mam nadzieję, że był przydatny i aż tak bardzo nie bolał, mimo zauważalnej liczby stron. Proszę zgłaszać swoje propozycje zmiany tego dokumentu i miłego kodowania 🙂🙃🙂
 
-![Podpis Szymona Kowalińskiego](../../../assets/github/image10.png)
+![Podpis Szymona Kowalińskiego](../../assets/github/image10.png)
 **Wiceprezes VII Zarządu KN Solvro**

src/content/docs/hello-there.md

@@ -46,22 +46,22 @@ Znając [wstępne informacje](#na-początek) o naszej dokumentacji, chcielibyśm
 Ogólne informacje:
 
 - [Zapoznaj się z naszą strategią](/solvro/strategy)
-- [Kanały komunikacji](/guides/communication-channels)
-- [Jak używać GitHuba?](/guides/github/)
-- [Jak prowadzimy projekty? Czego się spodziewać?](/guides/prowadzenie-projektów)
+- [Kanały komunikacji](/communication)
+- [Jak używać GitHuba?](/github)
+- [Jak prowadzimy projekty? Czego się spodziewać?](/sections/management/prowadzenie-projektów/)
 - [Poznaj nasz zarząd](/solvro/vii_board)
 
 Poradniki technologiczne:
 
-- [Web](/guides/web-development/)
-- [Mobile](/guides/flutter-mobile/)
+- [Web](/sections/frontend/)
+- [Mobile](/sections/mobile/)
 
 ### Dla starych wyjadaczy
 
 Oprócz materiałów dla nowych członków, warto zapoznać się z:
 
-- [Jak prowadzić projekt?](/guides/prowadzenie-projektów/)
-- [Deploy Guide](/guides/deployment/)
+- [Jak prowadzić projekt?](/sections/management/prowadzenie-projektów/)
+- [Deploy Guide](/sections/devops/deployment/)
 
 ---
 

src/content/docs/index.mdx

@@ -153,15 +153,15 @@ Oprócz spotkań weekly całego koła odbywają się cykliczne spotkania projekt
 
 Po restrukturyzacji kierujemy się w stronę GiTHuba. Chcemy, aby był on sercem naszej organizacji, gdzie przepływa cała praca operacyjna i kod. Tam również prowadzone są projekty od strony operacyjnej, rozpisywane zadania itd. Końcowo będąc studenckim kołem chcemy chwalić się naszymi projektami i w tym właśnie celu projekty koła, które na to pozwalają będą realizowane jako open-source. Pozwoli to uhonorować członków projektu i potwierdzić swoje doświadczenie przy szukaniu pracy. Z tego również powodu dbamy o dobre praktyki pisania kodu i pracowania z githubem (PR, jednolite commity, readme itd.). Dla początkujących na naszym blogu znajduje się post [Podstawy GITa](https://solvro.pwr.edu.pl/blog/solvro-talks-1-podstawy-gita).
 
-Must-have lekturą jest również [Handbook Githuba](/guides/github)
+Must-have lekturą jest również [Handbook Githuba](/github)
 
 # Projekty
 
 ## Jak działamy
 
 KN Solvro łączy w sobie zwinne techniki startupowe oraz solidne podejście naukowe. Oznacza to, że chcemy sprawnie realizować projekty i dążymy do jak najszybszego wypuszczenia MVP (Minimal Viable Product), ale z zachowaniem dobrych praktyk i dokumentacji projektowej.
 
-Dokładnie jak przeprowadzić projekt w Solvro można się dowiedzieć z pomocą[Handbook prowadzenia projektów](/guides/prowadzenie-projektów/)
+Dokładnie jak przeprowadzić projekt w Solvro można się dowiedzieć z pomocą[Handbook prowadzenia projektów](/sections/management/prowadzenie-projektów/)
 
 ## Czas wskoczyć w projekt
 

src/content/docs/guides/Adonis.md → src/content/docs/sections/Backend/Adonis.md

@@ -18,7 +18,7 @@ description: Szybki start dla tych, którzy chcą poznać Adonisa i tworzyć św
 
 Oto lista najważniejszych rzeczy, które warto w mniejszym lub większym stopniu ogarniać biorąc się za naukę korzystania z Adonisa:
 
-- **Git i GitHub** - podstawowe narzędzia pracy każdego developera. Z zasadami korzystania stosowanymi w Solvro można zapoznać się w [Handbook GitHub](/guides/github)
+- **Git i GitHub** - podstawowe narzędzia pracy każdego developera. Z zasadami korzystania stosowanymi w Solvro można zapoznać się w [Handbook GitHub](/github)
 - **IDE** - środowisko do pracy z kodem. Do najpopularniejszych opcji należy Visual Studio Code i Webstorm od Jetbrains.
 - **TypeScript** - jest to podstawowy język wykorzystywany przez Adonisa. Bez jego znajomości ciężko cokolwiek zrobić.
 - **NodeJS** - technologia pozwalająca na uruchamianie JS poza przeglądarką. Wykorzystywana do budowania backendu. Zrozumienie działania importów i menadżera pakietów NPM jest potrzebne do sprawnego poruszania się po frameworku.
@@ -72,7 +72,7 @@ npm run format
 
 ## Deployment
 
-[Poradnik jak zdeployować apkę Adonisową](/guides/deployment)
+[Poradnik jak zdeployować apkę Adonisową](/sections/devops/deployment/)
 
 ## Rozszerzenia
 

src/content/docs/guides/Deployment.mdx → src/content/docs/sections/Devops/Deployment.mdx

@@ -1,6 +1,7 @@
 ---
 title: Deploy
 description: Jak postawić apke na naszym serwerze na coolify?
+order: 10
 ---
 
 import { Steps } from "@astrojs/starlight/components";
@@ -30,10 +31,10 @@ Link do dockerfile’a z adonisowej dokumentacji, który możecie dostosować do
 Crème de la crème, dostępny pod adresem https://devops.solvro.pl - o dostępy do zarządu
 
 _Widok projektów - wszystkie projekty postawione na Coolify_
-![](../../../assets/deployment/image8.png)
+![](../../../../assets/deployment/image8.png)
 
 _Każdy projekt ma swoje zasoby (Resources), które składają się na cały system projektu_
-![](../../../assets/deployment/image11.png)
+![](../../../../assets/deployment/image11.png)
 
 ## Baza danych
 
@@ -58,7 +59,7 @@ W naszym przypadku używamy Postgresql, tu nie ma większej filozofii, wystarczy
 
 </Steps>
 
-![](../../../assets/deployment/image14.png)
+![](../../../../assets/deployment/image14.png)
 
 Ważne dane, które będą potrzebne do envów na backendzie:
 
@@ -88,7 +89,7 @@ Ważne dane, które będą potrzebne do envów na backendzie:
 
 6. Wybieramy brancha, którego Coolify ma deployować  
     Wybieramy jak Coolify ma tworzyć obraz kontenera (zawsze **Dockerfile** przy Adonisie)
-   ![](../../../assets/deployment/image13.png)
+   ![](../../../../assets/deployment/image13.png)
 7. Czas na konfigurację 🚀
 
 </Steps>
@@ -97,26 +98,26 @@ Ważne dane, które będą potrzebne do envów na backendzie:
 
 Po udanym procesie tworzenia resource’a powinniście ujrzeć następujący widok
 
-![](../../../assets/deployment/image17.png)
+![](../../../../assets/deployment/image17.png)
 :::tip
 Po zmianach w zakładce zapisujcie zmiany, żeby potem nie wychodziły jakieś kwiatki.
 
-![](../../../assets/deployment/image2.png)
+![](../../../../assets/deployment/image2.png)
 :::
 
 Na początku warto zmienić nazwę na bardziej czytelną, zmienić domenę \{poddomena\}.solvro.pl, ewentualnie dodać opis.  
 Przykład:
-![](../../../assets/deployment/image3.png)
+![](../../../../assets/deployment/image3.png)
 
 Jeśli macie monorepo to warto też zmienić Base Directory, jeśli macie np. w jednym repo frontend i backend.  
 Przykład z [Planera](https://github.com/Solvro/web-planer) 🔥:
-![](../../../assets/deployment/image21.png)
+![](../../../../assets/deployment/image21.png)
 
 #### Network
 
 Ports Exposes jest istotny, domyślnie Adonis słucha na porcie 3333 - jeśli ustawiliście inny w env-ach to zmieńcie na ten z env-ów.  
 Porst mappings - jeśli nie macie konkretnych powodów, to nie zmieniajcie mapowania portów do hosta.
-![](../../../assets/deployment/image5.png)
+![](../../../../assets/deployment/image5.png)
 
 Zakładka Pre/Post Deployment Commands jest użyteczna, jeśli chcecie, żeby po każdym deployu jakaś akcja się wykonała - w naszym przypadku wykonujemy migracje:
 
@@ -129,25 +130,25 @@ node ace migration:run --force
 W advance’ach warto zaznaczyć Preview Deployments co pozwoli na sprawdzenie działania aplikacji po otworzeniu pull requestu na repo.
 Ostatnio (11.2024) Bartosz pisał, że automatyczne preview deployments są wyłączone i jeśli chcemy zrobić preview deployment, to musimy sobie wyklikać.
 
-![](../../../assets/deployment/image20.png)
+![](../../../../assets/deployment/image20.png)
 
 ### Preview deployments
 
-![](../../../assets/deployment/image22.png)
+![](../../../../assets/deployment/image22.png)
 
 ### Zmienne środowiskowe
 
 Kolejna ważna zakładka, Enviroment Variables - tu ustawiacie niezbędne zmienne środowiskowe.
 
-![](../../../assets/deployment/image19.png)
+![](../../../../assets/deployment/image19.png)
 
 Polecam wejść w widok developerski, przekleić envy z folderu projektu adonisa i poustawiać odpowiednie wartości:
 
-![](../../../assets/deployment/image16.png)
+![](../../../../assets/deployment/image16.png)
 
 Dane do zmiennych zaczynających się od DB\_\{zmienna\} wyciągacie z bazy którą uprzednio utworzyliście, wszystkie dane możecie wyciągnąć z URL’a bazy:
 
-![](../../../assets/deployment/image15.png)
+![](../../../../assets/deployment/image15.png)
 _**postgres://\{username\}:\{password\}@\{host\}:\{port\}/\{database\}**_
 
 Jeśli nie chcecie ręcznie przeklejać danych z url'a możecie poprosić Gepetto albo Kloda (jest to względnie bezpieczne)
@@ -156,19 +157,19 @@ Jeśli nie chcecie ręcznie przeklejać danych z url'a możecie poprosić Gepett
 
 W Sourcie mozecie wybrać brancha, którego chcecie deployować.
 
-![](../../../assets/deployment/image6.png)
+![](../../../../assets/deployment/image6.png)
 
 ### Health checks
 
 Jeśli nie chcecie mieć irytującego warningu koło statusu resource’a to możecie ustawić healthchecki [https://coolify.io/docs/knowledge-base/health-checks/](https://coolify.io/docs/knowledge-base/health-checks/)
 
-![](../../../assets/deployment/image10.png)
+![](../../../../assets/deployment/image10.png)
 
 ### Deployments
 
 Zdarzyć się może, że w trakcie deploy-u co się wykrzaczy - na ratunek przychodzi zakładka _Deployments_, w której możecie sprawdzić logi wszystkich deploy-ów i naprawić usterkę.
 
-![](../../../assets/deployment/image23.png)
+![](../../../../assets/deployment/image23.png)
 
 ### Terminal
 

src/content/docs/guides/Web Development/best-practices.mdx → src/content/docs/sections/Frontend/best-practices.mdx

@@ -267,4 +267,4 @@ Tutaj zapraszam do korzystania z naszego coolify’a pod adresem [https://devops
 
 Za wsadzanie linka w przycisk będę karał tygodniową chłostą, to nie jest poprawny html, sam react krzyczy, że nie można tak robić i czytniki ekranów się zepsują jak spróbują to przeczytać
 
-Więcej na ten temat znajdziesz [tutaj](/guides/web-development/accessibility/#przyciski-jako-linki)
+Więcej na ten temat znajdziesz [tutaj](/sections/frontend/accessibility/#przyciski-jako-linki)

src/content/docs/guides/Prowadzenie projektów.md → src/content/docs/sections/Management/Prowadzenie projektów.md

@@ -91,7 +91,7 @@ Lead jest odpowiedzialny za jego utworzenie, odpowiednie skonfigurowanie pól i
 
 Pamiętajmy o jak najbardziej pomocnych opisach zadań najlepiej od razu z linkami/screenami do makiety UI/UX.
 
-Więcej informacji można znaleźć w [Handbooku Githuba](/guides/github)
+Więcej informacji można znaleźć w [Handbooku Githuba](/github)
 
 ### Makiety UI/UX
 
@@ -150,7 +150,7 @@ Od tego momentu przechodzimy na tzw. produkcję, gdzie reliability musi być zac
 
 Infrastrukturą wdrożenia będzie zajmował się devops i końcowo produkcyjna aplikacja będzie hostowana na innym serwerze niż developerska. Domena aplikacji produkcyjnej jest subdomeną solvro.pl
 
-Więcej info z deploymentu znajdziesz w [Handbooku Deploymentu](/guides/deployment).
+Więcej info z deploymentu znajdziesz w [Handbooku Deploymentu](/sections/devops/deployment/).
 
 ## Zamknięcie lub dalsza praca
 

src/content/docs/guides/Flutter (Mobile)/index.md → src/content/docs/sections/Mobile/index.md

@@ -41,7 +41,7 @@ Na szczęście dzięki wieloplatformowości możesz pisać we Flutterze i testow
 
 Z "tańszych" OS-ów polecam bardziej Linuxa niż Windowsa, ale ostateczny wybór należy do Ciebie.
 
-O Linuxie i WSLu możesz przeczytać więcej w napisanym przez specjalistę [Web Development Handbook](/guides/web-development#wsl). Praca na Linuxie jest zwykle wygodniejsza niż na Windowsie, ale nie jest to wymagane.
+O Linuxie i WSLu możesz przeczytać więcej w napisanym przez specjalistę [Web Development Handbook](/sections/frontend/#wsl). Praca na Linuxie jest zwykle wygodniejsza niż na Windowsie, ale nie jest to wymagane.
 
 :::tip[Link dla kolegi]
 Losowa instrukcja instalacji wirtualki macOS: <https://antyweb.pl/wirtualny-macos-na-windows-10-dziala-imessage-icloud-i-inne>