To make it easy for you to get started with GitLab, here's a list of recommended next steps.
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
## Add your files
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
-[ ] [Set up project integrations](https://gitlab.liu.se/tdp003-projekt/egna-datormiljoen/-/settings/integrations)
## Collaborate with your team
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
## Suggestions for a good README
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
## Name
Choose a self-explaining name for your project.
## Description
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
## Authors and acknowledgment
Show your appreciation to those who have contributed to the project.
## License
For open source projects, say how it is licensed.
## Project status
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
Målet med projektet i kursen är att skapa en portfolio som kan användas för att dokumentera de projekt ni gör på IP-programmet. Denna portfolio implementeras i form av en webbplats. På webbplatsen ska det sedan vara möjligt att söka bland era projekt för att exempelvis hitta alla projekt som involverar Python.
Genomförande:
För genomförandet av projektet gäller:
Projektet genomförs i grupper om två personer. Avvikelse kan ske vid särskilda omständigheter i samråd med kursledare.
En individuell arbetsdagbok skall skrivas dagligen, läs mer dagboken och om reflektionsdokumentet här.
Inlämningar och redovisning ska ske enligt kursens planering.
Den fungerande datormiljön behöver nu bli en utvecklingsmiljö, se detta dokument
Aktivt deltagande vid kursens föreläsningar, verktygsgenomgångar och lärarledd laboration förutsätts.
Daglig närvaro 8-17 förväntas.
Översikt av projektet
Webbplatsen består av två huvuddelar: ett datalager och ett presentationslager. Datalagret har till uppgift att hantera all data i systemet. I detta fall lagras datan i JSON-format på en textfil i filsystemet. Datalagret tillhandahåller sedan ett API (gränssnitt, dvs. en uppsättning väldefinierade funktioner) som presentationslagret kan använda för att få information från datafilen. Presentationslagret, i sin tur, har till uppgift att visa den information som en användare har efterfrågat på ett snyggt sätt med hjälp av datalagret. Detta görs genom att presentationslagret genererar den HTML-kod som ska skickas till användarens webbläsare.
Krav på projektet
Här följer kraven på projektet indelat i krav på datalagret, krav på presentationslagret och almänna (icke-funktionella) krav.
Krav på datalagret
Datalagret specificeras genom ett så kallat Application Programming Interface (API). I praktiken ska ni skapa en modul med pythonkod som till pricka följer denna specifikation. Förutom att er modul följer denna specifikation så finns också följande övergripande krav på systemet som direkt relaterar till datalagret:
Systemet ska kunna hantera följande information om ett projekt: projektnamn, projekt-id-nummer, startdatum, slutdatum, kurskod, kursnamn, kurspoäng, använda tekniker, kort beskrivning, lång beskrivning, liten och stor bild, gruppstorlek och en länk projektsida. Projektnamn och projekt-id är obligatoriska, övriga fält kan lämnas tomma.
Projekt-id ska vara ett unikt heltal för varje projekt.
Varje projekt kan ha en sekvens av tekniker angivna.
Sökning ska kunna göras på godtycklig projektinformation. Sökning kan ske på flera fält samtidigt. Sortering ska kunna göras på ett fält, i stigande och fallande träffordning. Man ska kunna filtrera utifrån använda tekniker i sökningen. Observera att allt ska fungera tillsammans, så att man kan söka på ett sökord, filtrera till vissa tekniker och sortera söklistan i en viss ordning samtidigt.
Data lagras i JavaScript Object Notation (JSON) i filen data.json. Filen ska lagras med UTF-8 teckenkodning.
Data läggs till i JSON-filer manuellt (eller av andra verktyg) i systemet.
Förändring av data.json ska slå igenom direkt i systemet utan omstart av webbserver.
(Frivilligt) Utvidga systemet med en administrativ sida för redigering av data.
Krav på presentationslagret
Presentationslagret (portfolion) är en webbplats med en statisk och tre dynamiskt skapade webbsidor, enligt följande lista:
index: statisk eller dynamisk förstasida
list: dynamisk sida som listar projekten
project: dynamisk sida som visar information för ett specifikt projekt
techniques: dynamisk sida som visar en sammaställning över de tekniker som används i projekten
Utöver att dessa sidor finns så ska följande konkreta krav uppfyllas som direkt relaterar till presentationslagret:
Förstasida med bilder. URL: /
Söksida som visar en lista över projekt med kort information om varje projekt och som gör det möjligt att sortera dessa, samt söka bland dem genom ett formulär på sidan. URL: /list
Projektsida som visar fullständig information om ett projekt. GET- variabel för att ange projekt-id: id URL: /project/id - där id är projektets nummer
Tekniksida som visar information om alla projekt utifrån använda tekniker. URL: /techniques
För varje projekt ska en liten bild visas på söksidan och en stor på projektsidan. Det behöver inte vara samma bild. Bildtext för varje bild skall finnas.
Vid fel ska systemet skriva ut informativa meddelanden till användaren på en lämplig nivå för en slutanvändare. (Det vill säga, systemet ska fånga och omvandla felkoder och statuskoder till begripliga meddelanden.)
När en användare försöker visa ett projekt som inte finns, ska korrekt statuskod returneras (dvs. 404).
Icke-funktionella krav
Pythonskriptens utdata ska formateras med en HTML-mall via Jinja2.
Presentationen ska implementeras med hjälp av HTML5 och CSS3.
Versionshantering med Git ska användas.
Hela systemet ska testas av tredje person som får utföra de huvudsakliga uppgifterna som portfoliosystemet är tänkt för. Genomförs under systemdemonstrationen.
Källkoden ska kommenteras på engelska för varje modul, funktion och för varje global variabel. Ej självförklarande kodavsnitt ska även kom- menteras löpande i koden.
Alla namn på filer, moduler, funktioner och variabler ska vara på eng- elska.
Systemet ska dokumenteras (se sepparata dokumentbeskrivningar i menyn)
Katalogstrukturen ska se ut som följer:
MyPortfolio /
doc /
static /
images /
*.png, *.jpg, *.gif
style /
*.css, *.png, *.jpg, *.gif
templates /
*.html, *.xml, *.json
README
data.json
myFlaskProject.py
*.py
Viktigt: Katalogen style/ är till för CSS-filer och bilder som refereras från dessa. Bilder som hör till innehållet/projekten läggs i images/
