Why development is part of the lab
I do not treat infrastructure and software as separate interests. I write code to automate repetitive work, test APIs, build small interfaces and turn operational ideas into usable tools. The lab gives those applications real systems to interact with.
Languages and use cases
- Python for automation, data handling and API scripts
- Rust for learning safe systems programming and efficient utilities
- JavaScript, HTML and CSS for web interfaces
- Electron for cross-platform desktop applications
- PHP for web application and WordPress-related work
- Java for cross-platform programming experiments
- Docker Compose and YAML for repeatable service definitions and infrastructure configuration
How I approach a small application
I start with the problem and the data flow, define the smallest useful interface, keep secrets outside the source tree, add error handling and logging, then test against a disposable lab environment before using the tool on live services.
What I want the portfolio to show
The important point is not a wall of language logos. It is that I can move between infrastructure, troubleshooting and code when a problem needs more than a manual click-through.
Package Electron, Python, Rust, PHP, JavaScript or Java projects only after linting, dependency review and basic error-path testing.
Start with a small repository, a written problem statement and a minimal cross-platform prototype. Keep configuration outside the code, add repeatable build commands and test on each intended operating system.