The next steps on my Outreachy journey: Docker, big challenges, and small victories

As I reflect on the past few weeks of my Outreachy internship with LibreHealth, I‘m struck by how much I‘ve grown both technically and personally. It‘s been a rollercoaster of emotions – from the initial excitement of diving into a new codebase to the frustration of getting stuck on environment setup to the pure elation of seeing my first successful build.

For those who are new to my journey, let me catch you up. I‘m currently interning with LibreHealth, an open source project that develops health IT solutions for low-resource settings. My main focus is on improving the documentation for the Radiology module, which allows clinicians to order and view medical imaging studies like X-rays and CTs.

When I first started, I was eager to jump right into the code and start exploring. But I quickly realized there were some big gaps in my understanding of how the module actually worked and how to get it running on my local machine. That‘s when I first encountered the behemoth known as Docker.

Demystifying Docker

If you‘re not familiar with Docker, you‘re not alone. I had certainly heard the buzzword thrown around before, but I didn‘t fully grasp what it was or why it mattered. As I soon learned, Docker is a platform that allows developers to easily package, distribute, and run applications in isolated environments called containers.

The key idea behind containerization is that it allows you to bundle an application along with all of its dependencies, libraries, and configuration files into a single package. This package can then be run consistently across different computing environments, from your laptop to a data center.

Docker uses a client-server architecture, with the Docker client communicating with the Docker daemon to build, run, and distribute containers. Containers are launched from images, which are essentially snapshots of a pre-configured application and its dependencies.

So why is this relevant to the LibreHealth Radiology module? Well, the module is designed to be run in a Docker container to ensure a consistent environment across different deployment scenarios. This means that in order to fully test and document the module, I needed to get Docker up and running on my development machine.

Easier said than done, as it turned out.

Down the virtualization rabbit hole

My first attempt to install Docker for Windows ended abruptly when I realized it required Windows 10 Pro or Enterprise. As a longtime Windows 8 user, I wasn‘t quite ready to make the leap to a new OS. Undeterred, I started searching for alternatives and came across Docker Toolbox, a legacy solution for older Windows systems.

But before I could even attempt to install Toolbox, I was confronted with a daunting prerequisite: enabling hardware virtualization. This sent me down a rabbit hole of research trying to understand what virtualization actually means and how it differs from containerization.

In a nutshell, virtualization allows you to run multiple virtual machines (VMs) on a single physical machine. Each VM runs its own operating system and operates as an isolated environment, with the hypervisor managing resources between VMs. Containers, on the other hand, share the host operating system kernel and isolate the application using OS-level primitives.

While containers are more lightweight and efficient than VMs, the Docker engine still requires virtualization to be enabled on the host machine. This meant I needed to access my BIOS settings and enable Intel VT-x or AMD-V, depending on my processor.

Simple enough in theory, but a bit more harrowing in practice. I spent hours scouring forums and tutorials for the magic key combination to enter BIOS on my specific laptop model. After a few false starts and a minor panic that I had accidentally bricked my machine, I finally managed to locate the virtualization setting and enable it.

With that hurdle cleared, I was finally ready to install Docker Toolbox and start playing around with containers. Or so I thought.

Troubleshooting my way to success

The Docker Toolbox installation went smoothly enough, but I quickly hit a wall when trying to actually run the LibreHealth Radiology module. The docker-compose up command stubbornly refused to recognize my configuration files, throwing cryptic "file not found" or "access denied" errors.

I felt completely stuck. I had no idea how to even begin debugging the issue or where to look for answers. I started to doubt whether I was cut out for this level of technical complexity.

But then I remembered one of the core tenets of Outreachy: nobody expects you to know everything coming in. The whole point is to learn and grow with the support of your mentors and fellow interns. So I swallowed my pride and started asking for help.

I posted my questions in the LibreHealth chat channels and on the Outreachy forum. I pored over documentation and Stack Overflow posts late into the night. And slowly but surely, I started to piece together a solution.

It turned out my docker-compose file had some outdated configuration options that were no longer supported in newer versions of Docker. With some trial and error, I figured out the updated syntax and got the containers building successfully.

I also discovered that the Radiology module needed some additional configuration to connect to a test PACS (picture archiving and communication system) server. This required diving into the module source code and tracing how the DICOM (digital imaging and communications in medicine) standard was implemented.

Bit by bit, I chipped away at each roadblock until I finally had a working development environment. The feeling of seeing the Radiology module UI load in my browser for the first time was indescribable. I felt like I had just cracked an impossible code.

Lessons in perseverance and humility

Looking back on those first few weeks, I‘m struck by how much I learned – not just about Docker and DICOM, but about myself. I discovered a resilience and determination I didn‘t know I had. I learned to embrace the struggle as part of the learning process.

I also gained a new appreciation for the power of humility in tech. It‘s so tempting to try to bluff your way through a problem or be too proud to admit when you‘re lost. But some of my biggest breakthroughs came from simply acknowledging what I didn‘t know and asking for help.

This experience also reinforced for me the critical importance of good documentation, especially in open source projects. I saw firsthand how even a small gap in instructions or context can derail a new contributor for days. It renewed my motivation to create documentation that is comprehensive, accessible, and empathetic to the reader‘s perspective.

The road ahead

With my local environment finally up and running, I‘m excited to dive deeper into the LibreHealth Radiology module and start documenting its features and architecture. I know I still have a lot to learn about the clinical workflows involved in medical imaging and how the module supports them.

But I feel better equipped to tackle those challenges now that I‘ve built up my technical troubleshooting skills and my confidence in asking for help. I‘m also incredibly grateful to have the support of my Outreachy mentors, who have been endlessly patient in answering my questions and pointing me to resources.

As I look ahead to the rest of my internship, I‘m excited to stretch myself even further. I want to explore areas like information architecture, API documentation, and usability testing. I‘m also hoping to contribute some code fixes and refactoring to make the module more maintainable.

More than anything, I want to use my skills to make a real impact. I truly believe in LibreHealth‘s mission to make health IT more accessible and equitable. If my documentation can help even one clinician provide better care to their patients, it will all be worth it.

Reflecting on growth

Ultimately, that‘s what I love most about the Outreachy program. It‘s not just about honing your technical skills, although that‘s certainly a big part of it. It‘s about growing as a whole person and discovering what you‘re capable of when you push yourself outside your comfort zone.

I came into this internship feeling like an impostor, convinced I wasn‘t "technical enough" to contribute anything of value. But with each small victory – whether it was enabling virtualization, troubleshooting a Docker error, or drafting my first documentation page – I started to prove myself wrong.

I still have moments of doubt, of course. I don‘t think that ever fully goes away. But I‘m learning to reframe those doubts as opportunities for growth rather than signs of inadequacy.

I‘m also learning to celebrate my victories, no matter how small. Getting Docker set up may seem trivial to a seasoned developer, but for me, it was a hard-won battle that taught me so much. It deserves to be recognized and celebrated.

As I continue on this journey, I know there will be many more challenges and victories ahead. But I feel more ready than ever to face them head-on, armed with a growth mindset and a supportive community behind me.

Here‘s to the next step, and the next, and the next.