Journey

The Problem

I had a perfectly functional desktop PC. It worked fine for development. But I kept running into issues:

• Projects conflicting with each other
• “Works on my machine” problems
• Wanting to access projects from anywhere
• Curious about server infrastructure
• Paying for cloud hosting for hobby projects

The Solution: Replace Desktop with Server

I did something that sounds extreme: replaced my desktop PC with a server.

Not a secondary machine. Not in addition to my desktop. Instead of my desktop.

This server became my:

• Development environment
• Project hosting platform
• Learning laboratory
• Personal cloud

Why This Made Sense

1. Always Accessible

SSH from anywhere. On laptop, on another computer, on mobile (if desperate). My development environment follows me.

No more “I forgot that file on my home computer”.

2. Isolation Through Containers

Different projects in different Docker containers:

• No dependency conflicts
• Clean separation of concerns
• Easy to reset if something breaks
• Can experiment without fear

Broke something in a container? Recreate it. No harm done.

3. Learning by Doing

Want to understand:

• Containerization? Set up Docker
• Networking? Configure container networks
• Storage? Volumes and bind mounts
• Orchestration? Docker Compose
• Monitoring? Grafana and metrics collection

Building a development server teaches all of this through hands-on experience.

4. Cost Savings

Cloud hosting costs for hobby projects add up:

• VPS: $10-20/month
• Storage: $5-10/month
• Bandwidth: Can get expensive

Development server:

• One-time hardware cost
• Electricity (minimal for efficient server)
• Full control over everything

After a year, it pays for itself.

5. Project Hosting

Host my own:

• Web applications
• APIs
• Databases
• Git repositories
• CI/CD pipelines
• File storage

No monthly bills. No vendor lock-in. Complete control.

What I Run

Infrastructure

Containers: Docker for application isolation and reproducibility

Reverse Proxy: Nginx for routing traffic

DNS: Local DNS for easy service discovery

Services

Development:

• Docker containers for different project environments
• Isolated databases and dependencies per project
• Git server for private repositories

Hosting:

• Web applications (Flask apps, APIs)
• Databases (PostgreSQL, Redis, InfluxDB)
• File storage

Monitoring:

• Grafana for metrics visualization
• Custom dashboards for system health
• Container logs aggregation

Backup:

• Automated nightly backups
• Volume backups
• Test restores regularly

What I Learned

System Administration

• Linux server administration
• User and permission management
• Service management (systemd)
• Security hardening

Networking

• TCP/IP fundamentals
• Container networking
• Port mapping and routing
• Firewall configuration
• Remote access setup

Containerization

• Docker architecture
• Image building and optimization
• Container networking
• Volume management
• Docker Compose orchestration

Storage

• File systems (ext4, btrfs)
• Volume management
• Backup strategies
• Disaster recovery planning

Monitoring

• Metrics collection
• Alerting strategies
• Log management
• Performance analysis

Challenges

1. Complexity

Running your own infrastructure is more complex than using managed services. You’re responsible for:

• Updates and security patches
• Monitoring and alerting
• Backup and recovery
• Performance optimization

But: This complexity is educational. Every problem solved is knowledge gained.

2. Reliability

Home internet isn’t datacenter-grade:

• Power outages happen
• ISP issues occur
• Hardware can fail

Solution:

• UPS for power protection
• Good backup strategy
• Accept that 99.9% uptime isn’t the goal

3. Initial Time Investment

Setting up a development server takes time:

• Hardware selection
• OS installation and configuration
• Docker setup
• Service configuration
• Learning curve

But: The time invested pays off in knowledge and capability.

Is This For Everyone?

No.

Don’t build a development server if:

• You just want to write code (use managed services)
• You don’t enjoy infrastructure
• You need guaranteed uptime
• You don’t have time for maintenance

Do build one if:

• You’re curious about how infrastructure works
• You enjoy learning by doing
• You want full control over your environment
• You see value in hands-on experience

What This Taught Me

1. Appreciation for Managed Services

Running your own infrastructure makes you appreciate:

• How much work cloud providers do
• Why managed services cost what they do
• The value of proper monitoring and alerting

But also: when DIY makes sense vs when to pay for services.

2. Systems Thinking

Understanding infrastructure deepens your understanding of applications:

• How networking affects performance
• Why certain architectures scale better
• What operational concerns matter
• How monitoring helps debugging

3. Troubleshooting Skills

When something breaks (and it will), you learn:

• Systematic debugging
• Reading logs effectively
• Understanding system behavior
• Fixing problems at the root

4. Confidence

There’s confidence that comes from:

• Knowing you can set up production-like environments
• Understanding the full stack (application to hardware)
• Being able to deploy and manage services
• Not being dependent on specific platforms

Practical Benefits

For Development

• Consistent environment across projects
• No “works on my machine” issues
• Can experiment freely
• Easy rollback if things break

For Learning

• Hands-on experience with real infrastructure
• Safe environment to break things
• Learn by doing, not just reading
• Build transferable skills

For Projects

• Host hobby projects for free
• Full control over stack
• No vendor lock-in
• Learn deployment and operations

Current Projects Hosted

• Aspira development environment: Docker container with performance monitoring
• Web applications: Flask apps in isolated containers
• Databases: PostgreSQL, InfluxDB, Redis containers
• Git repositories: Private repos for personal projects
• File storage: Volume-backed storage
• Monitoring dashboards: System health and project metrics

The Bottom Line

Replacing my desktop with a development server wasn’t just about hardware:

It was about learning by doing.

Every project I host teaches me something:

• How to deploy properly with Docker
• How to monitor effectively
• How to debug in production
• How to think operationally

I’m not just a developer writing code. I’m someone who understands the full stack from application to infrastructure.

That understanding makes me a better engineer.

Would I Recommend It?

If you’re curious about infrastructure: absolutely yes.

Start small:

1. Get modest server hardware
2. Install Linux
3. Set up Docker
4. Host a simple project in a container
5. Add monitoring
6. Iterate and learn

You don’t need enterprise hardware. You need curiosity and willingness to learn.

If you just want to code: maybe not.

Use managed services. Focus on applications. That’s totally valid.

But if you want to understand how systems work end-to-end, building a development server is one of the best investments you can make.

---

“I replaced my old PC with a server that hosts my projects and acts as my personal cloud. Docker makes everything reproducible and isolated.”

Aspira: The Project That Changed How I See Code

Aspira didn’t just teach me about chess engines it taught me about myself as a developer. When I started, I thought it would be a fun side project. Write some code, make a bot play chess, maybe learn a few tricks. I had no idea what I was getting into.

The first time Aspira played a legal game, I was like a kid. But very quickly, reality caught up with me: perft tests exploding, impossible-to-isolate bugs, architecture collapsing as soon as I tried to push further. I spent nights tracking down errors that weren’t typos, but mistakes in logic, understanding, and design. I realized that in a chess engine, everything is connected, and the slightest approximation can cost you dearly.

I threw everything away. Started from scratch. Not out of perfectionism, but because it was the only way to move forward. This time, I put correctness above all. Bitboards, magic bitboards, clean make/unmake functions, tests at every step. And only when everything was solid did I start chasing performance. The result? 20 million nodes per second, but more importantly, an engine where I understand every line, every choice.

But the most important lesson was about myself: patience, humility, the ability to doubt, to start over, to seek not the “clever” solution but the right one. Aspira is the project that taught me that true satisfaction doesn’t come from raw performance, but from deep understanding and the journey taken to get there.

The name “Aspira” comes from “aspiring”: to understand, to build, to go further. And somewhere along the way, this project ended up aspiring me too. And that’s what makes it precious.

Building Remote Management at Alemca

I spent 1.5 years at Alemca, a Montpellier startup building IoT remote management solutions. This is where theory met reality and I truly learned what it means to work on production systems.

What I Did: I renovated the web application (Flask, Jinja templates), architected data and file management modules, made technical decisions (InfluxDB, S3 storage, etc.), and designed APIs that other services depended on.

What I Learned: Architectural decisions have long-term consequences. Clean code isn’t optional at scale. Security must be built in from the start. Technical debt trade-offs are constant. Communication is as important as code quality.

One of the best parts of my time at Alemca was the team. I had the chance to work with talented, passionate people who were always willing to share their knowledge and challenge each other to do better. The atmosphere was both demanding and supportive: we could debate architecture, joke about bugs, and celebrate wins together. I learned a lot from my colleagues, and I’m genuinely grateful for the trust and autonomy I was given. Looking back, I realize how much this environment helped me grow not just technically, but also in how I communicate, collaborate, and approach problems as a team.

The Beginning: STI2D at Lycée Joseph Vallot

I wasn’t completely new to computers when I started my Bac STI2D (Science and Technologies of Industry and Sustainable Development) at Lycée Joseph Vallot in Lodève. But it’s where I learned the fundamentals that everything else would build on.

What I really learned:

• Boolean algebra and logic gates
• How computers actually work at a low level
• Mathematics applied to real systems
• Physics principles behind technology
• How to think systematically about problems

It wasn’t just “learn to code” - it was “understand how systems work”. That foundation matters more than I realized at the time.

University: BUT Informatique in Montpellier

Three years at IUT Montpellier studying for my BUT Informatique (Bachelor of Technology in Computer Science). This is where I really became a software engineer.

Technical Skills:

• Software development (multiple paradigms)
• Systems programming and architecture
• Advanced mathematics (yes, even more math)
• Database design and management
• Network architecture
• Security fundamentals

Soft Skills:

• Communication and technical writing
• Project management
• Team collaboration
• Presenting technical concepts
• Balancing requirements and constraints

The mix of deep technical knowledge and professional skills was crucial. Code is only part of being a software engineer - you need to communicate, collaborate, and understand business context.

What University Got Right

1. Depth Over Breadth

Rather than superficially covering every technology, we dove deep into fundamentals:

• How operating systems work
• Why algorithms matter
• What makes code maintainable
• How to analyze trade-offs

These fundamentals let me learn any new technology quickly because I understand the underlying principles.

2. Real Projects

Working on team projects with deadlines, requirements changes, and technical constraints prepared me for professional work better than any tutorial could.

3. Learning to Learn

The most valuable skill: learning how to learn independently. How to read documentation, debug systematically, and research solutions.

First Professional Experience: Alemca

1.5 years at Alemca, a Montpellier startup building IoT remote management solutions. This is where theory met reality.

What I Did:

• Renovated the web application (Flask, Jinja templates)
• Architected data and file management poles
• Made technical decisions (InfluxDB, S3 storage, etc.)
• Designed APIs that other services depended on

What I Learned:

• Architectural decisions have long-term consequences
• Clean code isn’t optional at scale
• Security must be built in from the start
• Technical debt trade-offs are constant
• Communication is as important as code quality

The Pattern

Looking back, there’s a clear pattern in my journey:

Curiosity → Understanding → Building → Mastery

1. Curiosity: Why does this work? How is this built?
2. Understanding: Research, learn fundamentals, go deep
3. Building: Create projects to solidify understanding
4. Mastery: Iterate, optimize, teach others

This pattern started in high school and continues today. Whether it’s chess engines, distributed systems, or new technologies, the approach is the same.

What Drives Me

I love understanding how things work. Not just “how to use X” but “how does X actually work under the hood?”

This curiosity led me to:

• Build a file system in Java to understand how file systems work
• Create a chess engine to understand search algorithms and optimization
• Set up a home lab to understand server infrastructure
• Study distributed systems through PawnPower

I value quality over speed. I’d rather spend time building something right than patch it forever. Technical debt is sometimes necessary, but it should be a conscious decision, not the default.

I’m versatile. I’m not just a “Java developer” - I’m someone who understands systems at multiple levels. Development, operations, architecture, security. The whole stack.

Where This Led

Today, I’m a software engineer who:

• Primarily codes in Java but explores new technologies through projects
• Values clarity and quality in every line
• Thinks architecturally before writing code
• Can build and manage complex systems
• Learns constantly and deliberately

The path from Lodève to here wasn’t linear, but every step built on the previous one. And the journey continues - there’s always more to learn, more to build, more to understand.

The Next Chapter

I’m looking for a project that challenges me technically. Where I can apply everything I’ve learned: clean code, thoughtful architecture, systematic analysis, pragmatic decision-making.

I love solving complex problems and building systems that are both powerful and maintainable. That’s what I want to spend my time doing.

---

“Before being a Java developer, I’m someone curious who researches. I learn every day and I love it. I’m passionate about understanding how everything around us works, and I love creating projects that help me discover how things function.”

The “Useless” File System

One day, I decided to build a file system in Java.

Not because I needed a file system. Java already has perfectly good file I/O. Not because it would be production-ready. It wouldn’t be.

I built it because I wanted to understand how file systems work.

Reading documentation tells you what a file system does. Building one teaches you why it’s designed that way, what trade-offs exist, where complexity hides.

The Pattern

Looking at my project history, it seems random:

• A file system in Java
• Discord bots for fun and moderation (at first in JS, following tutorials and docs, not understanding much, and only much later discovering JDA and the Java ecosystem)
• A development server to host everything
• A chess engine that processes 20M positions per second
• A distributed chess testing platform

But there’s a pattern: each project exists to understand something deeply.

Learning by Building

Reading teaches you surface knowledge. You understand the what and maybe the how.

Building forces you to confront reality. You hit edge cases documentation doesn’t mention. You discover why certain design decisions were made. You feel the pain of bad abstractions.

Example: The File System

Reading about file systems: “Files are organized in blocks, with inodes tracking metadata…”

Building a file system:

• How do you handle fragmentation?
• What happens if you run out of inodes?
• How do you recover from partial writes?
• Why is seeking expensive?
• What trade-offs exist between block size and wasted space?

You don’t just know what a file system is - you understand why it works that way.

From Curiosity to Capability

This approach has an interesting side effect: I become capable at things by being curious about them.

Home Lab Example:

• Started curious about server infrastructure
• Built a home lab to explore
• Now I understand networking, virtualization, resource management
• Can deploy and manage complex systems

Chess Engine Example:

• Curious about how chess engines work
• Built Aspira from scratch
• Learned low-level optimization, bitboard operations, search algorithms
• Gained expertise in performance-critical code

Distributed Systems Example:

• Wanted to understand coordination and failure handling
• Built PawnPower with distributed workers
• Learned about distributed state, network reliability, real-time communication
• Can now architect distributed systems

The “I Can Do Anything” Trap

There’s a dangerous side to this: feeling like you can do anything.

Technically, it’s kind of true. Given enough time and curiosity, I can learn and build most things.

But there’s a gap between “can learn” and “should do”:

Frontend development is my acknowledged weakness. I can build frontend interfaces. I understand React, CSS, responsive design. But I’m not as competent as someone who specializes in it.

I prefer being honest: let someone who loves frontend handle it while I focus on what I do best - backend systems, architecture, complex problem-solving.

Why This Matters

This curiosity-driven approach shapes how I work:

1. I Learn Technologies When They’re Needed

I don’t learn React because it’s popular. I learn it when a project needs it and I want to understand it deeply.

This prevents resume-driven development: choosing technologies because they’re trendy rather than because they solve the problem.

2. I Understand Trade-offs

When you’ve built systems from scratch, you understand their trade-offs viscerally:

• Why databases are designed the way they are
• When to optimize and when to ship
• What complexity is necessary vs accidental
• When to use established solutions vs build custom

3. I Can Dive Deep Quickly

Need to work with a new database? I understand database fundamentals, so I focus on what makes this one unique.

New framework? I understand the patterns, so I learn the specifics.

The fundamentals compound. Each deep dive makes the next one faster.

The Process

When approaching something new:

1. Research fundamentals - How does this work conceptually?

2. Build something small - Make it concrete, hit real problems

3. Read source code - See how experts solved it

4. Build something bigger - Apply learnings, discover deeper complexity

5. Iterate - Each version teaches you something

This is slower than following tutorials. But the understanding is deeper and lasts longer.

Current Curiosities

Right now I’m exploring:

• NNUE (neural networks for chess evaluation)
• Kernel-level optimization for Aspira
• Advanced distributed system patterns
• Cache-friendly data structures

Each will likely become a project. Each project will teach me something that applies beyond its specific domain.

The Core Philosophy

I’m not just learning to code. I’m learning how systems work.

Code is a tool for understanding. Projects are experiments in learning.

The goal isn’t to build everything from scratch in production. It’s to understand deeply enough that you make better decisions when using established solutions.

---

“I’m passionate about understanding how everything around us works, and I love creating projects that help me discover how things function.”