Nicht eingeloggt
luis-rosado›luis.json
// luis.json

Luis
Rosado

Informatiker EFZ Applikationsentwicklung 

Ich mache die IMS an der bwd Bern und bin im dritten Jahr auf dem Weg zum Informatiker EFZ, Fachrichtung Applikationsentwicklung.

Wenn mich etwas interessiert, baue ich es meistens einmal selbst nach, bis ich verstehe, warum es funktioniert. Aus dieser Angewohnheit sind die meisten Projekte auf dieser Seite entstanden.

Jetzt suche ich ein Praktikum, in dem ich in einem Team an Anwendungen mitarbeite, die auch wirklich jemand benutzt.

E-Mail schreiben GitHub ansehen
Wohnort
Burgdorf BE
Schule
IMS an der bwd Bern
Stand
3. Ausbildungsjahr
Schwerpunkt
Web und Backend
Arbeitet gern mit
TypeScript, React, Python
Erreichbar
luisrosado008@gmail.com

Quellen

Was auf dieser Seite nicht von mir ist:

Visual Studio Code
Microsoft. Die Oberfläche ist dem Editor nachgebaut, ebenso die Farbdesigns Dark+ und Light+.
Devicon 2.16.0
Die Technologie-Logos bei Skills, Tech-Stack, Explorer und Tableiste. MIT-Lizenz.
JetBrains Mono
Die Schrift für Code und Beschriftungen. JetBrains, SIL Open Font License.
Inter
Die Schrift für den Fliesstext. Rasmus Andersson, SIL Open Font License.
stats.fm
Meine Hördaten bei den Interessen. Die Cover kommen von Spotify und Apple Music.
Weitere Farbdesigns
Dracula (Zeno Rocha), Nord (Sven Greb), One Dark (Atom) und GitHub Dark, alle mit MIT-Lizenz.
Hilfsmittel
Für Themen, die im Unterricht noch nicht vorkamen, also die Absicherung des geschützten Bereichs und das Suchen hartnäckiger Fehler, habe ich mit Claude Code gearbeitet und in Dokumentationen und Blogs nachgelesen, vor allem MDN und der Node-Dokumentation. Mehr dazu steht in readme.md.

Text, Aufbau, CSS, JavaScript, die Serverfunktionen und die Bilder der Projekte sind von mir. Die Bildquellen meiner ersten Website stehen dort auf ihrer eigenen Seite.

luis-rosado›skills.py
# skills.py · Technische Fähigkeiten

Skills

Neben jeder Technologie steht das Projekt, in dem ich sie eingesetzt habe. Was ich dort genau gebaut habe, steht bei den Projekten.

  • in einem Projekt eingesetzt
  • Grundlagen aus dem Unterricht
  • arbeite ich mich gerade ein
  • im Berufsalltag gezeigt

Web & Frontend

  • HTML5 / CSS3, in einem Projekt eingesetzt Portfolio
  • JavaScript, in einem Projekt eingesetzt Portfolio
  • TypeScript, in einem Projekt eingesetzt Askel
  • React / React Native, in einem Projekt eingesetzt AskelKobui
  • C# / .NET MAUI, in einem Projekt eingesetzt Mein Rezeptbuch
  • Jest, Grundlagen aus dem Unterricht Askel

Backend & Daten

  • Python, in einem Projekt eingesetzt Redis-Webshop
  • Flask, in einem Projekt eingesetzt Redis-Webshop
  • NestJS, in einem Projekt eingesetzt URL-Shortener
  • Redis (NoSQL), in einem Projekt eingesetzt Redis-Webshop
  • Node.js / Serverless, Grundlagen aus dem Unterricht Portfolio
  • SQL / MariaDB, Grundlagen aus dem Unterricht Unterricht

Betrieb & Werkzeuge

  • Git / GitHub / GitLab, in einem Projekt eingesetzt alle Projekte
  • Docker / Compose, in einem Projekt eingesetzt Redis-WebshopURL-Shortener
  • Kubernetes / ArgoCD, in einem Projekt eingesetzt URL-Shortener
  • CI-Pipeline, in einem Projekt eingesetzt URL-Shortener
  • Linux / Bash, Grundlagen aus dem Unterricht Arch Linux
  • Azure / Betrieb, Grundlagen aus dem Unterricht DevOps-Modul
  • Netzwerke / TCP-IP, Grundlagen aus dem Unterricht Unterricht

Soft Skills

  • Schnelle Auffassungsgabe, im Berufsalltag gezeigt alle Projekte
  • Selbstständiges Arbeiten, im Berufsalltag gezeigt Apotheke Achillea
  • Teamfähigkeit, im Berufsalltag gezeigt AskelKobui
  • Zuverlässigkeit, im Berufsalltag gezeigt Apotheke Achillea
  • Stressresistenz, im Berufsalltag gezeigt Apotheke Achillea

Als Nächstes: Java, dazu REST-APIs von Grund auf, nach den zwei Endpunkten dieser Website.

luis-rosado›techstack.ts
// techstack.ts · Technologien & Tools

typescript
interface TechStack {
languages: string[];
databases: string[];
tools: string[];
os: string[];
devices: string[];
}

const luis: TechStack = {
languages: ["JavaScript", "C#", "SQL", "HTML/CSS"],
databases: ["Redis (NoSQL)"],
tools: ["Git", "GitHub", "GitLab", "VS Code"],
os: ["Windows 11", "Arch Linux"],
devices: ["Lenovo ThinkPad (Dual-Boot, Schule)", "Desktop-PC (Windows, zuhause)"]
};

Tech Stack

HTML5
Frontend
CSS3
Frontend
JavaScript
Frontend / Logic
C#
Programmierung
.NET MAUI
Mobile / UI
Redis
NoSQL / Key-Value
Docker
Ausliefern
Kubernetes
Betrieb
Git
Versionierung
GitHub
Kollaboration
GitLab
Schule
VS Code
Editor
Windows 11
Hauptsystem
Arch Linux
Dev-Setup
Bash
Terminal / Skripte

Setup

Für die Schule nutze ich ein Lenovo ThinkPad mit Dual-Boot: Windows 11 für den Alltag, Arch Linux fürs Programmieren. Entwickelt wird in VS Code, versioniert über GitLab. Zuhause steht zusätzlich ein Desktop-PC mit Windows.

luis-rosado›projekte.html
<!-- projekte.html -->

Projekte

Jedes Projekt beginnt mit einem Abstract, also der Kurzfassung in zwei bis drei Sätzen. Darunter stehen die Details, der eingesetzte Stack und, wo vorhanden, Quellcode und Demo.

Persönliche Projekte

// Persönlich · eigenständig · laufend

Portfolio

AbstractDiese Seite hier. Die Oberfläche ist einem Code-Editor nachgebaut, mit Tabs, Explorer, Terminal und Kommandopalette. Öffentlich sind Skills und Projekte, hinter einem Passwort liegen Noten und Lebenslauf. Alles von Hand geschrieben, ohne Framework und ohne eine einzige externe Abhängigkeit.

Drin steckt unter anderem eine Tabverwaltung mit Tastatursteuerung, ein Explorer, der auf dem Handy zur Schublade wird, sechs Farbdesigns und ein eigenes Druck-Stylesheet. Der Login geht an eine Serverless Function, die das Passwort gegen einen gesalzenen scrypt-Hash prüft und ein Token mit vier Stunden Laufzeit zurückgibt. Noten und Lebenslauf liegen auf dem Server und stehen nie im ausgelieferten HTML. Wer den Quelltext im Browser öffnet, findet dort nichts.
Meine Rolle
Alleine umgesetzt: Konzept, Gestaltung, Frontend und Backend
Besonderheit
Kein Framework, keine npm-Abhängigkeiten. Was im Browser ankommt, habe ich geschrieben.
HTMLCSSJavaScriptNode.jsVercel
Quellcode auf GitHub
// Persönlich · eigenständig · laufend

Yu-Gi-Oh! Deckbuilder

AbstractEin Deckbuilder für das Yu-Gi-Oh!-Sammelkartenspiel: Suche über rund 14 300 Karten, Deck-Editor mit Main, Extra und Side, laufende Prüfung gegen die Turnierregeln und die aktuelle Banlist. Dazu, was ein Deck kostet, und wie wahrscheinlich eine Karte in der Starthand liegt. Reine Client-Anwendung ohne Backend.

Die Kartendaten holt ein Skript einmalig beim Bauen in einem Request; zur Laufzeit spricht die App keine fremde Schnittstelle an. Die rund 14 300 Kartenbilder sind 400 MB und gehören weder ins Repository noch in jeden Build, sie liegen deshalb in einem eigenen Cloudflare-Projekt und werden über eine Build-Variable eingebunden. Die Ergebnisliste ist virtualisiert, im DOM steht nur der sichtbare Ausschnitt. Die Chance auf eine Karte in der Starthand ist exakt über die hypergeometrische Verteilung gerechnet und nicht simuliert. Ein Deck lässt sich über einen Link teilen, der es vollständig im URL-Fragment trägt – kein Server, keine Datenbank. Bei den Master-Duel-Kosten werden die vier CP-Töpfe getrennt ausgewiesen statt addiert, weil sie sich im Spiel nicht gegeneinander tauschen lassen.
Meine Rolle
Alleine umgesetzt
Besonderheit
Ausser React keine Laufzeit-Abhängigkeit: Drag and Drop, der Dialog der Grossansicht und die Zwischenablage kommen alle vom Browser selbst
ReactTypeScriptViteTailwind CSSCloudflare
Live ausprobieren Quellcode auf GitHub
// Persönlich · eigenständig · eigenes Skript

Wallpaper-Switcher mit automatischem Farbschema

AbstractEin Bash-Skript, das aus meinem Hintergrundbild ein Farbschema errechnet und es auf das ganze System anwendet. Ein Bildwechsel färbt damit Fensterrahmen, Leiste, Menü und Terminal automatisch mit um, ohne dass ich eine Konfigurationsdatei anfassen muss.

Das Skript verkettet vier Werkzeuge: waypaper setzt das Bild, matugen leitet die Farbpalette daraus ab, rofi ist das Auswahlmenü und waybar die Statusleiste. Danach schreibt es die Konfigurationsdateien der beteiligten Programme neu und startet sie kontrolliert neu. Der knifflige Teil waren nicht die Farben, sondern die Reihenfolge: Lädt ein Programm zu früh neu, liest es noch die alte Palette.
Meine Rolle
Alleine geschrieben
Gelernt
Bash, Kommandozeilenwerkzeuge verketten, Konfigurationsdateien und Prozesse unter Linux
BashMatugenWaypaperRofiWaybarHyprland
Quellcode auf GitHub
// Persönlich · eigenständig

Arch Linux + Hyprland Dual-Boot

AbstractEin selbst aufgesetztes Dual-Boot-System auf meinem ThinkPad: Windows 11 für den Alltag, Arch Linux mit dem Window Manager Hyprland fürs Programmieren. Der Weg dahin führte über Ubuntu und Linux Mint, bevor ich zu Arch gewechselt bin. Eingerichtet, weil ich wissen wollte, wie ein Linux-System unter der Oberfläche zusammengesetzt ist.

Arch über archinstall installiert und Hyprland von Grund auf konfiguriert. Bei Hyprland gibt es keine fertige Oberfläche: Jede Taste und jedes Fensterverhalten steht in einer Konfigurationsdatei. Dazu Alacritty als Terminal, die Fish-Shell, waybar als Statusleiste, fuzzel als Programmstarter und Nautilus als Dateimanager. Das Abmeldemenü ist kein fertiges Programm, sondern ein rofi-Skript, das aus der Leiste heraus aufgerufen wird. Aus diesem Setup ist auch der Wallpaper-Switcher entstanden, der inzwischen ein eigenes Repository hat.
Meine Rolle
Alleine umgesetzt
Gelernt
Partitionierung und Bootloader, Konfigurationsverwaltung, Fehlersuche ohne grafische Oberfläche
Arch LinuxHyprlandAlacrittyFishWaybarNautilusDual-Boot
Konfiguration auf GitHub
// Persönlich · eigenständig

Konsolen-Modding: Switch & 3DS

AbstractAuf meiner eigenen Nintendo Switch und meinem 3DS eine Custom Firmware eingerichtet. Mich hat interessiert, wie ein Bootvorgang abläuft und an welcher Stelle ein System seine Signaturen prüft.

Bei der Switch über ein RCM-Jig im Recovery-Modus den Payload Hekate geladen und ein EmuMMC aufgesetzt, also eine abgetrennte Systemkopie, damit das Originalsystem unangetastet bleibt. Das ging nur, weil die Firmware noch nicht gepatcht war. Auf dem 3DS läuft Luma3DS. Beide Geräte gehören mir, und es ging um die Boot-Kette, nicht um Inhalte.
Meine Rolle
Alleine umgesetzt
Gelernt
Bootvorgang, Recovery-Modi, Signaturprüfung und der Umgang mit englischer Fachdokumentation
RCMHekateEmuMMCLuma3DS
// Persönlich · eigenständig · eigenes Werkzeug

Sailo

AbstractEin kleines Werkzeug, das meine eigenen Spielstand-Sicherungen von Switch und 3DS ordnet: mit Zeitstempel sichern, auflisten, zurückspielen. Entstanden, weil die mit Checkpoint bzw. JKSV exportierten Spielstände sonst unsortiert auf der SD-Karte liegen.

Jede Sicherung landet als Ordner mit Zeitstempel unter Spiel und Konsole, ohne Datenbank oder Index-Datei: Der Ordnername JJJJ-MM-TT_hh-mm-ss ist zugleich der Zeitstempel und sortiert sich schon als Text richtig, dadurch kann der Index nie vom tatsächlichen Ordnerinhalt abweichen. Beim Wiederherstellen sichert Sailo den aktuellen Stand automatisch, bevor der Zielordner geleert wird – sonst blieben Dateien des alten Stands liegen, die es in der Sicherung gar nicht gibt, und der Spielstand wäre eine Mischung aus beidem. Geschrieben mit .NET 9 und Avalonia statt MAUI, damit das Werkzeug auch unter Linux läuft.
Meine Rolle
Alleine umgesetzt
Gelernt
Dateisystem-Operationen sicher gestalten, sodass ein Fehlschlag nie zum Datenverlust führt, und Avalonia als plattformübergreifende Alternative zu MAUI
C#.NET 9Avalonia
Quellcode auf GitHub

Schulprojekte

// Schulprojekt · Modul 210 · eigenständig

URL-Shortener mit GitOps-Kette

AbstractEin URL-Shortener aus zwei NestJS-Diensten und einer MariaDB, der nicht nur läuft, sondern auch ausgeliefert wird: containerisiert, über eine CI-Pipeline gebaut und von ArgoCD automatisch in einen Kubernetes-Cluster deployt. Das Interessante war weniger das Kürzen von Links als der Weg vom Commit bis in den laufenden Cluster.

Die Anwendung. shorty nimmt lange URLs entgegen, gibt einen Kurzcode zurück und leitet beim Aufruf per 302 weiter. keeper ist der einzige Dienst, der die Datenbank sieht, und ist per API-Key geschützt. Von aussen erreichbar ist nur shorty über den Ingress, keeper hängt als ClusterIP dahinter. Ein Angreifer, der von aussen kommt, hat also keinen direkten Weg zur Datenbank.

Der Weg in den Cluster. Beide Dienste laufen in Containern, gebaut über eine GitLab-Pipeline. Die Kubernetes-Manifeste liegen bewusst in einem zweiten Repo: Anwendungscode und gewünschter Cluster-Zustand sind getrennt. ArgoCD beobachtet dieses GitOps-Repo und gleicht den Cluster automatisch an. Ein Deployment ist damit ein Commit, kein kubectl-Befehl von Hand. Wer den Zustand ändern will, muss durch Git, und dort ist jede Änderung nachvollziehbar.

Dazu kam schriftliche Arbeit, die ich sonst nirgends gemacht habe: ein Rollenkonzept mit IAM und RBAC, ein Sicherheitskonzept und eine Kostenanalyse für einen Betrieb in AWS. Alle drei theoretisch, aber sie haben mich zum ersten Mal darüber nachdenken lassen, was der Betrieb einer Anwendung tatsächlich kostet und wer worauf zugreifen darf.
POST /api/kurz läuft wirklich

Der Kurzcode wird hier wirklich von einer Serverless-Function vergeben, aber nirgends gespeichert und nicht weitergeleitet. Eine Weiterleitung auf beliebige fremde Adressen würde diese Domain zum Steigbügel für Phishing-Links machen, und das ist mir eine Vorführung nicht wert. Im Projekt selbst übernehmen das eine MariaDB und ein zweiter Dienst, der als einziger die Datenbank sieht; die Kubernetes-Kette läuft hier ohnehin nicht mit.

Meine Rolle
Alleine umgesetzt. Der Kurs stellte ein leeres Grundgerüst mit den ersten sechs Commits, alles ab der Containerisierung stammt von mir: 17 der 23 Commits.
Gelernt
  • Warum man Anwendungscode und Deployment-Zustand trennt
  • Dass Container zur Sicherheit gehören, nicht nur zum Ausliefern, etwa wenn sie nicht als root laufen
  • Einen Dienst so schneiden, dass nur einer nach aussen zeigt
  • Dass ein Deployment reproduzierbar sein muss, sonst ist es Glückssache
NestJSTypeScriptMariaDBDockerGitLab CIKubernetesArgoCD
Anwendung GitOps-Repo
// Schulprojekt · Modul 335 · Dreierteam

Askel

AbstractAskel heisst auf Finnisch «Schritt» und ist eine mobile App, die eine Fahrt per GPS aufzeichnet: Position, Höhe und Geschwindigkeit. Routen lassen sich speichern, benennen, farblich markieren und auf einer Karte anzeigen. Alle Daten bleiben auf dem Gerät, ein Backend gibt es nicht.

Umgesetzt mit React Native und Expo. Die Standortdaten kommen über expo-location, die Aufzeichnung läuft während der Fahrt weiter und die Routen werden lokal gespeichert. Dass es kein Backend gibt, war eine bewusste Entscheidung: Bewegungsprofile sind heikle Daten, und was das Gerät nie verlässt, kann auch nicht abfliessen.
Meine Rolle
Co-Developer im Dreierteam. Von mir stammen unter anderem:
Umgesetzt
  • Dauerhaftes Speichern der aufgezeichneten Routen auf dem Gerät
  • GPS-Aufzeichnung mit Distanzberechnung (lib/distance.ts)
  • Einstellungsbereich der App samt Formatierung der Messwerte
  • Farbauswahl beim Speichern einer Route
  • Schaltfläche zum Zentrieren der Karte auf die eigene Position
  • Automatisierte Tests für Distanzberechnung, Formatierung und Speicherung
React NativeExpoTypeScriptexpo-locationJest
Quellcode auf GitHub
// Schulprojekt · Modul 322 · eigenständig

Mein Rezeptbuch

AbstractEine Android-App zum Verwalten von Rezepten, geschrieben in C# mit .NET MAUI. Vier Bereiche über eine Tab-Leiste: die Sammlung mit Suche und Vegetarisch-Filter, eine Eingabemaske mit Validierung, eine FAQ-Seite und eine Info-Seite. Auftrag im Modul 322 für einen fiktiven Kunden, von der Oberfläche bis zur Logik allein umgesetzt.

Aufbau. Die App folgt MVVM, also der Trennung von Oberfläche und Logik. Die Views sind XAML-Dateien und enthalten keine Logik, der Zustand liegt in den ViewModels, und ein RezeptService als Singleton hält die Rezepte. Eine BaseViewModel mit SetProperty und INotifyPropertyChanged sorgt dafür, dass die Oberfläche jede Änderung von selbst mitbekommt: Ich setze eine Eigenschaft im Code, und das Feld auf dem Bildschirm aktualisiert sich, ohne dass ich es anfasse. Das war der Punkt, an dem Datenbindung für mich zum ersten Mal Sinn ergeben hat.

Validierung. Titel und Beschreibung sind Pflichtfelder und werden beim Tippen geprüft, nicht erst beim Speichern. Der Titel braucht mindestens drei Zeichen, die Beschreibung zehn; die Meldung steht direkt am Feld statt in einem Dialog, der erst nach dem Absenden aufgeht. Die Navigation läuft über die Shell mit benannten Routen, das Detail einer Karte wird als RezeptDetailPage?RezeptId=… aufgerufen.

Was sie nicht kann. Die Rezepte liegen nur im Arbeitsspeicher. Schliesst man die App, sind die selbst angelegten wieder weg und nur die vier Beispielrezepte da. Bilder gibt es ebenfalls keine, nur Platzhalter. Beides war im Auftrag nicht verlangt, es ging um Oberfläche und Datenbindung, aber es ist die erste Sache, die ich nachziehen würde: eine SQLite-Datei hinter denselben RezeptService hängen, damit der Rest der App unverändert bleibt.
Meine Rolle
Alleine umgesetzt: Oberfläche, ViewModels und Datenhaltung
Gelernt
  • C# in einem echten Projekt statt in Übungsaufgaben
  • MVVM: warum die Oberfläche nichts über die Datenhaltung wissen soll
  • Datenbindung mit INotifyPropertyChanged statt Felder von Hand nachzuführen
  • Oberflächen in XAML aufbauen und über Styles zentral gestalten
  • Eingaben prüfen, während getippt wird, nicht erst beim Absenden
C#.NET MAUIXAMLMVVMAndroid
Quellcode auf GitHub
// Schulprojekt · überbetrieblicher Kurs (ÜK) · Dreierteam

Kobui

AbstractKobui ist eine Web-App, die ein lokal laufendes Sprachmodell (KoboldCpp) an ein eigenes React-Frontend anbindet. Gedacht als datenschutzfreundliche Alternative zu Cloud-Diensten: Weil das Modell auf dem eigenen Rechner läuft, verlässt keine Eingabe das Gerät.

Frontend mit TypeScript, React und Vite, gestaltet über CSS Modules. Die Anwendung spricht die lokale Schnittstelle von KoboldCpp an und bringt eine eigene Anleitung mit, damit man sie auch ohne Vorwissen aufsetzen kann.
Meine Rolle
Organisation und Gestaltung im Dreierteam. Ich habe Aufgaben verteilt, den Zeitplan im Blick behalten und bin eingesprungen, wo es gegen Ende knapp wurde.
Beigetragen
Installationsanleitung für das lokale Backend, Ergänzung alternativer Modelle und Korrekturen an der Bedienoberfläche
Gelernt
Wie viel Abstimmung ein Dreierteam braucht. Und dass ein realistischer Zeitplan mehr wert ist als ein ehrgeiziger.
TypeScriptReactViteCSS Modules
Quellcode auf GitHub
// Schulprojekt · über drei Module gewachsen · laufend

Redis-Webshop

AbstractEin Webshop, der seine Daten nicht in einer Tabellendatenbank hält, sondern komplett in Redis. Entstanden ist er im NoSQL-Modul als ziemlich leeres Grundgerüst. Seither ist er mein Übungsprojekt: In jedem folgenden Modul, in dem es gepasst hat, habe ich ihn um das erweitert, was gerade dran war.

NoSQL-Modul: das Datenmodell. Jeder Datensatz liegt als Hash unter einem sprechenden Schlüssel, also product:12, user:3, cart:3. Redis kennt kein WHERE, deshalb braucht jede Suche einen eigenen Index. Die Kategorien liegen als Mengen unter idx:kategorie:* und enthalten die Produkt-IDs. Genau das war der Lerneffekt: In SQL wäre es eine einzige Abfrage gewesen, hier muss ich den Index beim Speichern von Hand mitschreiben. Vergesse ich das an einer Stelle, findet die Suche das Produkt nie wieder.

Docker-Modul: das Ausliefern. Anwendung und Datenbank starten seither zusammen über Docker Compose, damit der Shop auch auf einem fremden Rechner ohne Einrichtung läuft. Aus derselben Zeit stammt eine Kleinigkeit, über die ich mich immer noch freue: Die Verbindung sucht sich ihren Port selbst. Steht keine Umgebungsvariable, probiert sie 6379 und 6380 durch. In der Schule lief Redis auf einem anderen Port als zuhause, und statt die Datei jedes Mal zu ändern, klärt das Programm es eben selbst.

DevOps- und Azure-Modul: der Betrieb. Zuletzt ging es darum, die Anwendung nicht nur lokal laufen zu lassen, sondern auf einem Server zu betreiben und im Blick zu behalten.

Heute kann der Shop: Anmeldung mit Rollen für Admins und Kundschaft, Produkte anlegen, bearbeiten und löschen, einen Warenkorb pro Benutzer und Skripte, die alles mit Testdaten füllen.
Meine Rolle
Eigenes Repository, von mir umgesetzt und über die Module hinweg weiterentwickelt
Warum immer dasselbe Projekt
Ein neues Thema an bekanntem Code zu lernen zeigt den Unterschied deutlicher als ein frisches Beispielprojekt. Nebenbei sieht man an der Historie, wie sich derselbe Shop über ein Jahr verändert hat.
Gelernt
  • Datenmodellierung ohne Tabellen: der Schlüssel ist die Struktur
  • Warum eine Key-Value-Datenbank schnell ist und was man dafür aufgibt
  • Indizes selbst pflegen, statt sie von der Datenbank zu bekommen
  • Mehrere Dienste gemeinsam starten und ausliefern
  • Dass eine Anwendung auf einem Server andere Fragen stellt als eine, die nur lokal läuft
PythonFlaskRedisDocker ComposeJinja2Azure
Quellcode auf GitHub
// Schulprojekt · 1. Lehrjahr · eigenständig · mein erstes Projekt

Erste eigene Website

AbstractEine Info-Seite über mich mit fünf Unterseiten: Home, Über mich, Freizeit, Ausbildung und Kontakt. Reines HTML und CSS, ohne JavaScript, von Hand geschrieben und über FTP auf den Klassenserver geladen. Das war im ersten Lehrjahr meine erste Website überhaupt.

Inhaltlich ging es um mich selbst, technisch um die Grundlagen: eine gemeinsame Navigation auf jeder Seite, ein durchgehendes Layout, eingebundene Bilder und eine Quellenseite für alles, was nicht von mir stammt. Die Seite liegt bis heute unverändert auf dem Schulserver; eine Kopie davon liegt als Unterseite hier, damit sie erreichbar bleibt, wenn der Schulserver es irgendwann nicht mehr ist.

Ich zeige sie bewusst im Originalzustand. Die Rechtschreibung ist stellenweise daneben, jede Unterseite wiederholt dieselbe Navigation als Kopie, und es gibt kein Layout fürs Handy. Genau daran sehe ich den Abstand zu dem, was ich heute baue: Das Portfolio, auf dem Sie gerade sind, ist dasselbe Vorhaben, eine Seite über mich, nur ein Jahr später.
Meine Rolle
Alleine umgesetzt: Inhalt, Layout und Umsetzung
Gelernt
  • HTML-Grundgerüst, Verlinkung zwischen mehreren Seiten und Einbinden von Bildern
  • CSS auslagern, statt jede Seite einzeln zu gestalten
  • Dateien per FTP auf einen Webserver bringen
  • Dass Quellen anzugeben dazugehört, auch bei Bildern
Was ich heute anders mache
Navigation nicht mehr in jede Datei kopieren, Layout von Anfang an fürs Handy mitdenken und den Text vor dem Veröffentlichen gegenlesen
HTMLCSSFTP
Kopie hier ansehen Original auf dem Schulserver
luis-rosado›interessen.json
// interessen.json

Interessen

Was ich neben der Schule mache.

Hardware und Softmods

Ich habe einen PC selbst zusammengebaut und zwei Konsolen mit Custom Firmware versehen.

Gaming

Ich habe über hundert Spiele gespielt. Wenn mir eines gefällt, spiele ich es auf 100 Prozent: alle Trophäen, alle Nebenaufgaben, alle Sammelobjekte. Die meiste Zeit habe ich in Persona 3 FES, Palworld und Elden Ring verbracht.

Musik

Ich höre den ganzen Tag Musik und sammle Alben auch physisch. Das sind meine liebsten:

Dazu The Smiths, bei denen ich mich auf kein einzelnes Album festlegen kann. Was ich tatsächlich höre, steht in meinen Hörstatistiken:

Lesen

Ich lese hauptsächlich Mangas und sammle die Reihen bis zum letzten Band. Zu einigen davon habe ich auch Figuren.

Bildnachweis: Key-Art der Spiele von Steam, Album- und Bandcover aus dem Angebot von Apple und der Open Library. Die Rechte liegen bei den jeweiligen Studios, Labels und Verlagen; die Bilder stehen hier als Hinweis auf das Werk.

luis-rosado›kontakt.sql
-- kontakt.sql

Kontakt

Ich suche eine Praktikumsstelle in der Applikationsentwicklung. Bei Fragen oder wenn Sie Unterlagen brauchen, schreiben Sie mir. Ich antworte meistens am gleichen Tag.

E-Mail schreiben luisrosado008@gmail.com Quellcode ansehen github.com/Lro-rgb
Burgdorf BE · erreichbar auch über die Schule

Zugang zum geschützten Bereich

Noten und Lebenslauf liegen im Ordner unterlagen hinter einem Passwort. Die Zugangsdaten bekommen die Schulleitung, die betreuenden Lehrpersonen und Betriebe, bei denen ich mich bewerbe. Falls Sie den Zugang brauchen und noch nicht haben, genügt eine kurze Mail.

Verantwortlich
Luis Rosado
Zweck
Persönliche Portfolio- und Bewerbungswebsite im Rahmen der IMS-Ausbildung am bwd Bern. Keine kommerzielle Nutzung.
Hosting
Vercel Inc.
Schriften
JetBrains Mono und Inter über Google Fonts (SIL Open Font License)
Bildnachweis
Technologie-Logos von Devicon (MIT-Lizenz). Key-Art der Spiele von Steam, Album- und Bandcover aus dem Angebot von Apple und der Open Library. Die Rechte liegen bei den jeweiligen Studios, Labels und Verlagen. Alle übrigen Inhalte stammen von mir.
Externe Daten
Die Hörstatistiken auf der Interessen-Seite werden beim Aufruf von stats.fm geladen. Dabei erfährt stats.fm Ihre IP-Adresse. Der Verweis auf die Anschrift führt zu Google Maps. Dorthin gelangen Ihre Daten aber erst, wenn Sie ihn anklicken.
luis-rosado›README.md
# README.md · Wie diese Seite gebaut ist

Über diese Seite

Diese Seite ist meine persönliche Website im Rahmen der IMS-Ausbildung und gleichzeitig Teil meiner Bewerbungsunterlagen. Ich habe sie von Hand gebaut, ohne Baukasten und ohne Framework.

Hier steht, warum sie so aussieht und funktioniert, wie sie es tut. Gestalterische Entscheidungen sind nachvollziehbar oder sie sind Zufall; ich möchte, dass meine nachvollziehbar sind.

Aufbau
Code-Editor als Oberfläche
Technik
HTML, CSS, JavaScript von Hand
Abhängigkeiten
keine
Farbdesigns
sechs, umschaltbar
Sprachen
Deutsch und Englisch
Bedienung
vollständig per Tastatur

Warum ein Code-Editor als Oberfläche

Die Seite richtet sich an Betriebe, die Applikationsentwicklung ausbilden. Deshalb ist die Oberfläche selbst eine Arbeitsprobe: Sie ist einem Code-Editor nachempfunden, also der Umgebung, in der ich täglich arbeite.

Jeder Abschnitt ist eine Datei, deren Endung zum Inhalt passt: skills.py, techstack.ts, kontakt.sql. Das ist kein Selbstzweck: Die Endung sagt schon vor dem Lesen, worum es geht, und der Explorer links zeigt die ganze Struktur auf einen Blick. Wer lieber klassisch navigiert, benutzt die Tableiste oben; beides führt zum selben Inhalt.

Schrift

SchriftEingesetzt fürBegründung
JetBrains Mono Überschriften, Tabellen, Codeblöcke, Navigation Für Code entworfen: feste Zeichenbreite, klar unterscheidbares 0/O und 1/l/I. Hält Tabellenspalten optisch in Flucht.
Inter Fliesstext und Beschreibungen Eine Monospace-Schrift ermüdet über mehrere Sätze. Inter ist für Bildschirme optimiert und auch in kleinen Graden gut lesbar.

Zwei Schriften mit klarer Aufgabenteilung: Monospace für Struktur und Daten, Inter für Sprache. Der Wechsel ist kein Stilmittel, sondern ein Hinweis darauf, welche Art von Information gerade folgt.

Farben

Die Farben stammen aus den echten VS-Code-Themes. Ein einziger Akzentton führt durch die ganze Seite: aktiver Tab, Links, Schaltflächen, Fokusrahmen. Wer ihn einmal zugeordnet hat, findet sich überall zurecht.

Grün, Orange und Rot sind für Bedeutung reserviert, nicht für Dekoration: Einstufungen bei den Skills, Notenwerte, Fehlermeldungen. Farbe ist dabei nie der einzige Träger einer Information. Überall steht auch der Text dabei, damit die Seite bei einer Farbsehschwäche verständlich bleibt.

  • Editor #1e1e1e
  • Seitenleiste #252526
  • Aktivitätsleiste #333333
  • Statusleiste #2d5876
  • Akzent #4FA3E3
css
/* Dark+, das Standarddesign von VS Code */
:root {
--bg: #1e1e1e; /* editor.background */
--sb: #252526; /* sideBar.background */
--act-bg: #333333; /* activityBar */
--status-bg: #2d5876; /* statusBar, gedämpft */
}

Grafische Elemente

Es gibt bewusst keine Schmuckbilder und keine Symbolfotos. Jedes grafische Element hat eine Aufgabe:

ElementWarum es da ist
Technologie-IconsOriginallogos der jeweiligen Technologie. Ein Stack ist damit auf einen Blick erfassbar, ohne jede Zeile zu lesen.
Tableiste & ExplorerTragen die Editor-Metapher und sind gleichzeitig die Navigation. Zwei Wege zum selben Ziel.
ZeilennummernVerstärken die Metapher und zeigen nebenbei, wie lang ein Abschnitt ist. Auf schmalen Bildschirmen ausgeblendet, weil dort der Platz wichtiger ist.
Farbige SyntaxDie Codeblöcke sind echt eingefärbt statt als Bild eingebunden. Dadurch bleiben sie markierbar, durchsuchbar und für Screenreader lesbar.

Bedienung und Barrierefreiheit

Die ganze Seite lässt sich ohne Maus bedienen. In der Tableiste wechseln die Pfeiltasten zwischen den Dateien, Pos1 und Ende springen an den Rand, Entf schliesst einen Tab. Jedes bedienbare Element hat einen sichtbaren Fokusrahmen, und ganz oben führt eine Sprungmarke direkt zum Inhalt.

Wer im Betriebssystem reduzierte Bewegung eingestellt hat, bekommt die Seite ohne Animationen. Jeder Abschnitt hat eine eigene Adresse: #projekte lässt sich zum Beispiel direkt verschicken.

Technische Angaben

BereichUmsetzung
FrontendHTML, CSS und JavaScript von Hand, ohne Framework und ohne Build-Schritt. Was im Browser ankommt, ist genau das, was ich geschrieben habe.
BackendServerless Functions (Node.js) für Login und geschützte Inhalte
Passwortschutzscrypt mit Salt, Vergleich in konstanter Zeit; Sitzung über ein signiertes Token mit vier Stunden Laufzeit
AbhängigkeitenKeine. Weder Frontend noch Backend laden ein npm-Paket.
HostingVercel
Versionsverwaltunggithub.com/Lro-rgb/PortfolioV1, der komplette Quellcode dieser Seite ist öffentlich einsehbar
BrowserGetestet in Chrome, Edge und Firefox. Funktioniert in jedem aktuellen Browser; ältere bekommen dieselben Inhalte, nur ohne einzelne visuelle Effekte.

Warum ohne Framework

Ein Framework hätte mir Arbeit abgenommen, und genau deshalb habe ich darauf verzichtet. Tabverwaltung, Tastatursteuerung, Fokusverwaltung und der Login-Ablauf sind Dinge, die ich verstehen will, statt sie einzubinden.

Hilfsmittel

Ein Teil dieser Seite berührt Themen, die im Unterricht bisher nicht vorkamen, allen voran die Absicherung der Daten im geschützten Bereich: Passwörter als scrypt-Hash statt im Klartext, signierte Tokens mit Ablauf und die verschlüsselt abgelegten Unterlagen. Dazu kommt das Suchen hartnäckiger Fehler.

Für beides habe ich mit Claude Code gearbeitet und in Blogs und Dokumentationen nachgelesen, vor allem MDN und der Node-Dokumentation. Was ich übernommen habe, habe ich vorher nachvollzogen. Sonst stünde hier nicht, warum die Seite so gebaut ist, wie sie gebaut ist. Der Inhalt, der Aufbau und die Entscheidungen darüber sind meine.

unterlagen›noten.csv
# noten.csv

Noten

// Gesperrt. Bitte oben einloggen.
unterlagen›lebenslauf.md
# lebenslauf.md

Lebenslauf

// Gesperrt. Bitte oben einloggen.
main 0 Fehler, 0 Warnungen
– JSON
↗