eprints (HSR Hochschule für Technik Rapperswil)
Not a member yet
1196 research outputs found
Sort by
Containerbasiertes PaaS für individuelle VPS Infrastrukturen
No full textDiese Studienarbeit befasst sich mit der Entwicklung von QuickStack, einer selbst gehosteten Platform-as-a-Service (PaaS)-Lösung, die auf einer Virtual Private Server (VPS)-Infrastruktur betrieben wird und die effiziente Durchführung von Build- und Deployment-Prozessen sowie die Orchestrierung von laufenden Container-Anwendungen ermöglicht. Eine von uns durchgeführte Marktanalyse ergab signifikante Kostenvorteile gegenüber kommerziellen Cloud PaaS Angeboten. Nach einem Vergleich verschiedener Container-Orchestrierungstools wurde die Kubernetes-Distribution k3s aufgrund ihres geringen Ressourcenbedarfs und der einfachen Installation als Basis für QuickStack ausgewählt. Longhorn dient als Shared Storage Provider für persistente Daten über alle VPS-Nodes hinweg. Zu den Kernfunktionen von QuickStack gehören die einfache Installation über einen einzigen Kommandozeilenbefehl, die Unterstützung von Deployments aus einem öffentlichen oder privaten Git-Repository, ein Monitoring-Dashboard zur Überwachung des Ressourcenverbrauchs, Tools zum Debuggen laufender Container, darunter der Live-Log-Stream und das Web-Terminal, sowie die Anbindung von persistentem Speicher an einen oder mehrere Container über alle VPS hinweg. Durch die Bereitstellung dieser Funktionen vereinfacht QuickStack den Aufbau und Betrieb von Anwendungen auf einer VPS-Infrastruktur erheblich. Zukünftige Arbeiten könnten automatisierte Backups, weitere Debugging-Möglichkeiten und Deployment-Templates für Datenbanken und gängige Open-Source-Anwendungen umfassen
Kubernetes Pod Scheduling based on Energy efficient Metrics
No full textInitial situation:
In modern cloud environments, Kubernetes has become the de facto standard for orchestrating containerized applications. However, traditional Kubernetes pod scheduling algorithms primarily focus on resource allocation metrics such as CPU and memory utilization. While effective for performance, these methods often neglect Energy consumption. This is where our project comes in. Our goal is to design a scheduler that works alongside the traditional scheduler, with a specific focus on renewable generated energy availability.
Approach and technologies:
This project introduces an energy-aware Kubernetes pod scheduling Approach that integrates energy availability metrics into the scheduling decision process. The proposed solution enhances the default Kubernetes scheduler by adding a new metric: the available energy for each worker node. For scheduling logic, we consider both the newly assigned priority of a pod and the available energy. Decisions are made based on these metrics, ranging from stopping pods to shutting down entire nodes. Additionally, we implemented a "move" function that allows Kubernetes pods to be manually transferred to another node. This feature demonstrates how workloads can be relocated seamlessly without noticeable service disruption.
Result:
The project was deployed on a solar-powered infrastructure to validate its effectiveness. The system successfully managed pod scheduling by automatically shifting workloads when solar energy was unavailable, and the battery charge dropped to critical levels. Critical system parameters, such as battery thresholds, were made configurable and easily accessible through an intuitive graphical user interface (GUI). To enhance user engagement and improve target audience understanding, containerized workloads were represented as freight containers, giving the project a playful and visually intuitive design. These findings highlight the potential of energy-aware scheduling to improve the sustainability and cost-effectiveness of Kubernetes-based cloud infrastructures, making it a promising step toward greener data center operations
Review of Current Principalled Approaches to System Programming
No full textComputers are an essential part of our everyday life.
In this paper, I described based on the Intel’s CPU which hardware initialization an operating system has to perform and how to interact with the hardware. Starting from how a computer boots to memory management and interrupts to multitasking and finishing with kernel API.
The second focus is the language in which the operating system is written.
As most general purpose operating systems are written in C/C++ the question arose, if it is possible to write one using functional programming languages and techniques. I described why functional programming languages are not always suited for systems programming, and how one still could use techniques and concepts from such languages
Pantry - Price And NuTRition analYsis of cooking recipes
No full textWenn man in einem Kochbuch oder im Internet ein Rezept betrachtet, hätte man oft gerne weiterführende Informationen darüber, was der Einkauf der Produkte für das Rezept kostet und welche Nährwerte das Rezept enthält.
Genau bei diesem Problem setzt die entwickelte Web-App «Pantry» (Price And NuTRition analYsis of cooking recipes) an. «Pantry» ermöglicht es dem Benutzer auf einfache Weise ein Rezept mit mehreren Zutaten zu erfassen. Darauf schlägt die Web-App dem Benutzer ein Produkt je Zutat vor. Des Weiteren werden dem Benutzer der Gesamtpreis für den Kauf aller Produkte, der spezifische Preis für sein Rezept, als auch die totalen Nährwerte, welche sein Rezept enthalten, ausgewiesen. Auf Grundlage dieser von «Pantry» gelieferten Informationen kann der Benutzer dann leichter entscheiden, ob er ein Rezept zubereiten möchte.
Durch eine zusätzlich aufgebaute Produktdatenbank ist «Pantry» in der Lage Produktvorschläge zu machen. Um diese Datenbank zu befüllen, wurde ein Web-Scraper in Python mit Hilfe der Libraries Scrapy und Playwright entwickelt, welcher die Produkte von der öffentlichen Coop-Webseite sammelt, aufbereitet und in die Datenbank einfügt.
Die Web-App wurde dabei mit React realisiert, welche im Hintergrund eine REST-API verwendet. Die auf Spring Boot basierende REST API greift dann auf die Produktdatenbank zurück, um dem Benutzer Produktvorschläge für seine gewünschten Zutaten machen zu können.
Die entwickelte Web-App «Pantry» erfüllt die gesetzten Ziele, hat aber noch Weiterentwicklungspotenzial. So wäre es in Zukunft sicher sinnvoll den Web-Scraper auf weitere Verkäufer (z.B. Migros) auszuweiten, damit «Pantry» Produkte von verschiedenen Anbietern vorschlagen kann
OSMyBiz - Company profile editor for OpenStreetMap
No full textOpenStreetMap My Business (OSMyBiz) is an editor for the collaborative, open-mapping project OpenStreetMap (OSM). It focuses on enabling users to edit businesses on OSM without requiring knowledge about how OSM organises its data, specifically targeting new or inexperienced users. OSMyBiz got created in 2018 as a bachelor thesis project. Since then, it has only gotten minor updates and needs to catch up regarding technologies.
Since its creation, new version changes have been available for nearly all dependencies, and some are not even maintained. There have also been significant changes in the tooling used in modern web applications. OSMyBiz did not get optimised for mobile, and therefore, the usage on mobile devices was suboptimal. One of the external APIs used implemented rate-limiting, which caused constant error messages when moving around on the map. Additionally, the application has a growing list of issues and suggestions.
The application was brought up to date by migrating from Vue 2 to Vue 3, replacing Vuex with Pinia, switching from webpack to Vite and introducing TypeScript. The existing application got reworked to be responsive in a "mobile-first" approach. A caching mechanism was added to the application to reduce the load on the public overpass API instances. The implementation reduces unnecessary load on the shared infrastructure and improves user experience by reducing issues due to rate-limiting.
There are still multiple open issues, ideas and optimisation potential for OSMyBiz. This project has created a solid foundation to implement those further development options. All while ensuring better maintainability and making it simpler to modify the frontend code base
Contract Manager App
No full textIn der heutigen Zeit werden viele Verträge digital abgeschlossen. Zudem gibt es immer mehr Dienste, welche als Mietmodell angeboten werden und Zahlungen direkt auf der Kreditkarte oder dem Konto belasten. Da kann ein Vertrag schon mal aus dem Blickfeld geraten. Um eine bessere Übersicht über seine Verträge zu erhalten, soll ein zentraler Speicherort geschaffen werden, welcher über anstehende Kündigungstermine aufmerksam macht.
Das Frontend wurde in Form eines Mobile Apps mithilfe Googles plattformübergreifendem Software Development Kit Flutter realisiert. Dieses basiert auf der Programmiersprache Dart. Die Backend-Umgebung ist umgesetzt als REST-API, welche mit NodeJS entwickelt wurde. Dabei wurde TypeScript als Sprache verwendet, da dieses die Typensicherheit gewährleistet. Das Backend kommuniziert mit dem Frontend über einen Caddy Reverse-Proxy und der MongoDB Datenbank. Die Datenbank sowie das Backend werden auf dem Cloudhosting Provider DigitalOcean betrieben. Das Backend sowie der Reverse-Proxy und die Datenbank sind containerisiert mit Docker. Damit ein Passwort-Reset vollzogen werden kann, hat man SendGrid als externe Mailing API verwendet. Für die Push-Benachrichtigung sowie für den Google Analytics Service wurde Firebase genutzt.
Mithilfe der Contract Manager App können Verträge erfasst sowie anderen Familienmitgliedern zugewiesen werden. Die Verträge sind kategorisierbar und werden auf einem Dashboard anschaulich dargestellt. So hat man immer einen Überblick über die aktuellen monatlichen Kosten. Insbesondere hilft die App, auslaufende Verträge und mögliche Kündigungstermine im Blick zu behalten. Dies geschieht mittels Push-Benachrichtigung und ist zusätzlich in der App ersichtlich. Dadurch bietet die App eine optimale Aufbewahrung von Verträgen für Einzelpersonen und Familien an
Buchungsapp für einen alternativen Reiseanbieter - Evaluierung und Erstellung eines Frontend-Prototypen
No full textEinleitung:
Das Bedürfnis nach Erlebnissen in der Natur ist für viele eine Möglichkeit die persönliche Freiheit zu entfalten, die durch die Pandemie verstärkt wurde. Viele Vanlifer möchten spontan in ihren Camper einsteigen, unbeschwert drauflosfahren und dort Übernachten, wo es ihnen gefällt. Da Wildcampen häufig verboten ist und sich die Suche nach einem Stellplatz oft schwierig gestaltet, tritt bereits vor dem Reisestart der erste Frust auf. Die Vanlife Travel GmbH hat sich zum Ziel gesetzt, das Planen eines Campingausflugs einfacher zu gestalten. Dafür soll eine Webapplikation entwickelt werden, die Anbieter von Stellplätzen und Vanlifer zusammenbringt und eine spontane Reise möglich macht.
Im Rahmen der Studienarbeit werden die Anforderungen für die Entwicklung der Applikation gesammelt. Ausserdem sollen die Technologien ausgewählt und ein erster Prototyp mit einigen Funktionalitäten entwickelt werden.
Aufgrund des Umfangs der Studienarbeit arbeiten zwei Teams daran. Die Arbeit ist in Frontend und Backend aufgeteilt. Diese Arbeit umfasst den gesamten Frontend-Teil der Applikation.
Vorgehen / Technologien:
Eine Anforderungsanalyse wurde zusammen mit dem Kunden im Rahmen von einem Workshop durchgeführt, wobei unterschiedliche Arbeitsmittel wie Wireframe und Storyboard angewendet wurden um die Anforderungen zu definieren.
Die Applikation umfasst drei Rollen, welche unterschiedliche Bedürfnisse und Anforderungen haben. Aus den drei Profilen werden unterschiedliche Webansichten mit entsprechenden Funktionalitäten entwickelt. Für das Frontend wurde eine Single Page Application entwickelt. Dabei wurde Typescript als Programmiersprache in Kombination mit der React Library verwendet.
Damit nicht alle Services von Null auf implementiert werden müssen, wurde eine umfangreiche Studie für die Integration von SDKs und APIs von externen Tools durchgeführt (z.B. für den Login- oder Bezahlprozess).
Mit OpenApi wird eine automatisierte Schnittstellenspezifikation für die Kommunikation mit dem Backend verwendet. Weitere Libraries wurden eingesetzt, z.B. für die Erstellung von einem Kalender-Library, für die Verwaltung von freien Stellplätzen.
Fazit:
Der Prototyp der Applikation umfasst einige implementierte Features, die mit dem Backend kommunizieren. Die Schnittstelle von Front- und Backend wurde mit OpenApi definiert und generiert. Dabei war die Herausforderung eine konsistente Datengrundlage zu definieren. Deshalb spielt eine gute Kommunikation zwischen den Teams eine grosse Rolle.
Die Technologie-Analyse zeigt auf, dass verschiedene Tools integriert werden können. Die Schwierigkeit bei ihrer Auswahl ist die Definition und Priorisierung der Anforderungen. Eine umfangreiche Studie ist deshalb wichtig und dient als Entscheidungsgrundlage. Eine zusätzliche Herausforderung für diese Studienarbeit ist die Festlegung einer guten Basis für eine umfangreiche Applikation und die Integration der gewählten Technologien
Fitness Data Platform
No full textInitial Situation: Today’s world and day-to-day life are increasingly digitalized, with gadgets and devices that help with all kinds of tasks. This also includes the world of sports and health. The demand for trackers like smartwatches that monitor a person’s vitals, fitness routine, and more shot up in the last few years. We envision massive potential in services and software in this domain. One of these potential services is a platform where users can synchronize multiple smartwatches or fitness trackers, view the data of these gadgets in a unified dashboard, and share their data with their fitness trainers, doctors, or friends.
Objective: With this project, we aim to build a basis for a platform of this type. The main goal is to create an extendable infrastructure and code that can be further expanded upon. That means we want to provide an initial platform that allows users to synchronize and save their data. The user should be able to view a dashboard where merged data of different trackers is displayed. He should be able to share it with the users he chooses. The platform must be structured to enable new features to be added easily in the future.
Conclusion: In this project, we created a prototype for a Fitness Data Platform by using Typescript, Node.js, React, and MongoDB. Our prototype is a web application divided into frontend, backend, and a NonSQL database. This platform allows users to synchronize their Fitbit Connect and Garmin Connect accounts, view their weekly step count merged from multiple devices in a unified dashboard, and share these dashboards with other users by distributing their unique identification codes. Future implementations include additional support for other fitness tracking devices, more data on the dashboard, and being able to customize dashboards
Reconciliation of Point-of-Interest Locations on OpenStreetMap
No full textOpenStreetMap (OSM) is a crowdsourcing project, which creates and distributes open geographical data of and for the world. The continuous change of the real world circumstances can hardly be managed and reflected on maps in general. Consequently, only selective and punctual updates are made and this causes the data on OSM to be neither perfectly accurate nor complete.
To overcome the before-mentioned shortcomings of OSM, web scrapers can be used to collect publicly accessible brand data. The collected data will be stored in a scraper system and compared with OSM by a judging system to identify discrepancies. The results will be manually validated by OSM members and then be uploaded to OSM.
Various open-source tools have been assessed to find an ideal scraper and judging system to perform the matching between publicly available data and the OSM database. The combination of "AllThePlaces" (ATP, www.alltheplaces.xyz) as the scraper system and "OSM Conflator" as the judging system has turned out to be the most suited. The OSM Conflator obtains the external data from ATP. Profiles are used to pre-process the data before the OSM Conflator performs the matching. Currently, for each brand a separate profile has to be created.
During this task, five profiles were created in Python and the data output by the OSM Conflator was analysed. The brands for the profiles were selected by their availability on ATP and their localisation in Switzerland. Thus, the selection consists of Fust, Aldi, Jumbo, Coop Vitality and the public toilets of Zurich city. On average 12.6% of the entries from the external sources do not exist in OSM and were flagged as new entries. One problem is the questionable quality of the tag values, which prevented a match between external data and OSM clues for almost 2% of the entries. On top of that, the data quality of the external sources has room for improvement. In 1.6% of all analysed entries, a matching was not possible as the coordinates from the external sources were too unprecise.
Additional findings concern the creation of queries within the OSM Conflator. As a result of schema mismatches between the different data sources, it is challenging to include suitable tags in the profile to create a precise and performant query for a certain brand. Besides the non-standardised schemas, also the matching of the data is challenging due to spelling aspects of brand names, regional differences in brand naming and real-world circumstances, like e.g. company takeovers.
The output of the OSM Conflator shows that data reconciliation of OSM data is important. A more generic profile, which pre-processes the data for the OSM Conflator, would be ideal. Allowing a profile to dynamically extract different tags from the external data source and directly generate multiple individual queries for OSM, might constitute an interesting improvement for the OSM Conflator. Furthermore, standards for the data sources would be required to establish a more generic profile. The input data needs to be accurate, consistent and trustworthy. These improvements would also enable the reconciliation of regions rather than brands alone
A Security Focused Outline on Bitcoin Wallets
No full textThe famous electronic peer-to-peer cash system called Bitcoin is an open-source protocol allowing individuals to store and transact units of the same named currency.
Private and public key cryptography plays a central role in this value transfer system, which implies the importance of professionally managing the information about such keys.
This work elaborates on the essential prerequisites to understand this relatively new technology that combines elements from the fields of computer science, cryptography, mathematics, and game theory.
In doing so, crucial general and Bitcoin-specific terms are defined and contextually explained.
The central part of this work addresses the outline of different Bitcoin interaction means, commonly known as wallets.
The structure of the presented wallet types orients itself alongside a potential user's experience.
Besides defining explanations and examples of use cases, this work outlines advantages and disadvantages concerning security and privacy.
The start concerns two wallets that target beginners in the field of Bitcoin.
The concept of online accounts is elaborated and attention is drawn to the inherent need to trust when using them.
Also, the relatively primitive type of paper wallets is surveyed.
For a more intermediate interaction with this peer-to-peer cash system, the concept of software wallets, in general, is explained and examples are provided.
The bridge from single-address paper wallets will be drawn to the more sophisticated multi-address wallets enabled through rooted key derivation techniques.
Designated computer devices that solely serve the purpose of managing keying material, known as hardware wallets, represent another intermediate wallet type discussed in this work.
Last, advanced topics are discussed that further leverage the security and privacy of someone's interaction with Bitcoin.
One concerns the setup of a self-managed Bitcoin full node.
This undertaking not only harmonies with the concept of verification over trust but also allows for the complete exclusion of any third party between wallet communication.
Equally advanced is the concept of multi-signature wallets, which is discussed at the end of this work