No description
Find a file
2024-05-05 23:50:12 +02:00
lab01 Completed lab 1 and 3 2024-02-01 01:58:53 +01:00
lab02 Completed lab 2 2024-02-13 07:27:15 +01:00
lab03 Completed lab 1 and 3 2024-02-01 01:58:53 +01:00
lab04 Removed log 2024-05-05 20:39:20 +02:00
lab05 Completed lab 5 2024-02-21 12:56:56 +01:00
lab06 Completed lab 6 2024-02-22 16:05:47 +01:00
lab07 Added labs 2024-03-11 22:48:59 +01:00
lab08 Reverted changes due to task specifications 2024-05-05 14:18:15 +02:00
lab09 Commented and restructured code 2024-05-05 03:33:27 +02:00
lab10 Completed lab10 2024-04-04 00:34:57 +02:00
lab11 Commented and restructured code 2024-05-05 03:33:27 +02:00
lab12 Removed redundant log 2024-05-05 20:39:43 +02:00
lab13 updated gitignore 2024-05-05 03:13:11 +02:00
lab14 Updated incorrect file versions 2024-05-05 20:38:38 +02:00
lab15 Added run instructions 2024-05-05 18:47:32 +02:00
project Renamed folder to project 2024-05-05 17:46:45 +02:00
.DS_Store Removed target and large data files to reduce project size 2024-05-05 18:42:54 +02:00
.gitignore Added source code for lab04 and lab05 2024-02-13 07:49:39 +01:00
portfolio.mp4 Added portfolio video 2024-05-05 23:50:12 +02:00
README.md Updated title to portfolio, unable to change url path due to gitlab issue 500 2024-05-05 19:06:21 +02:00

Portfolio

Overview

This portfolio is structured with one folder per lab, and a seperate folder for the project. In each lab and the project we find a src folder which contains the source code for my labs and project.

Run the code

Go into the lab that you want to start (or folder), and run cargo run --release This will start the project in release mode, which adds extra optimalizations to run the code in a non-testing environment.

For lab 1-5 run ghc -o main <Filename>.hs; ./main. For lab 1-4 each file needs to be run individually based on the template above since there is no main folder. This is different since we are using two different languages, and for the very first tasks we did not include a src folder since it was mostly single file isolated programs.

About the code

Each folder contains its own Readme, which either contains the task description, or for the harder labs it contains both the task description and a "submission" title at the top of the readme, which is my note about the task. This allows the viewer to see both what the task was, and the implementation and my thoughts about it to provide as much insight as possible. They dont contain run instructions since thats outlined in this file, and all the projects run in the same way.

About each project

Note that this is just a brief description. The portfolio report goes in depth on each one.

Lab 1-5: Experimenting with Haskell features Lab 6: Parsing and handling input in Rust Lab 7: Generating acronyms and string manipulation Lab 8: Different forms of fibonacci functions Lab 9: Modular approach to simplify and optimize logic to adhere to certain tests. Lab 10: Simple API using the actix web framework Lab 11: In depth input manipulation, BufReader pt 2. Lab 12: Simple interpreter in Rust Lab 13: Simple compiler to WAT in Rust Lab 14: Extremely sophisticated algorithm to find the fastest way between all islands on a map Lab 15: Complete Go Game implementation, with frontend, server-client mode, api mode and direct terminal mode. Project: Bitcoin miner profitability calculator

Tests

The functions contain tests up to lab 12. After this the test coverage is limited due to how advanced the projects were, and the limited time given. For example there are tests in the code, but it is very difficult to verify that 4 clients can connect to a server and play in parallel. However, the code provides meaningful error messages in these cases, which will cover any issues related to this. For more insights in how a specific project is structured, please see the Readme file of that specific project.

Reflections

There are reflections both in the report, but the general overview is that I have tried to structure my code modularly, and never using libraries when not strictly necesarry, as way as ensuring that each part of the code only serves a single purpose. For all of the open ended labs I decided to code in Rust, as most of them required reading for buffer and sophisticated network communication or event driven programming, in which I feel that Rust has a larger community and there are more tools to choose between to ensure I use the most appropriate tool for each task.

Throughout this course, each lab pushed me to adapt and learn quickly, often requiring me to dive deep into documentation and community discussions. This was particularly evident in the transition from Haskell in the early labs to Rust in the later projects. The shift wasn't just about learning a new syntax but allowed me to adapt a new way of thinking about memory management, concurrency, and safety, which are central to Rusts philosophy.

Decision-Making Behind Technology Choices

Choosing Rust for the more complex labs was driven by its robust ecosystem and features that excel in memory safety and concurrency management. This decision was reaffirmed as I delved into network communication and event-driven programming, where Rusts performance and safety guarantees shone, especially in multi-threaded environments where data integrity is paramount.

Evaluation of Outcomes

Reflecting on the projects, I'm pleased with the functionality and robustness of the applications I developed, though I recognize areas for improvement. For instance, while most tests in lab 13 functioned as intended, a real-world interpreter would require more extensive testing and more sophisticated error handling to manage edge cases more gracefully.

Adaptability and Future Application

The skills and insights gained from these labs have not only enhanced my technical proficiency but have also improved my adaptability and problem-solving capabilities. These are skills I anticipate will be crucial in my future projects and professional development, especially as I tackle more complex, real-world problems where there is no guarantee that the response comes or that the data is there when you request it.

Integration of Feedback and Peer Learning

Feedback from instructors and peers was invaluable, providing me with different perspectives on my approach and coding style. This feedback helped refine my solutions, and drove me to search for more optimal solutions, especially when facing competition or seeing something peers had done better. As a result my code became both more efficient and readable. Learning from peers, especially those who tackled the same problems with different methods, provided me with a broader understanding of the possible solutions and their trade-offs.

Summary

Overall, this portfolio is a testament to my growth as a programmer. It encapsulates not just a series of coding tasks but a comprehensive learning journey. Each line of code and project decision encapsulates hours of learning, experimenting, and refining, reflecting both the challenges faced and the knowledge gained.