Boeing
I worked with the Boeing Augmented Reality Kit (BARK) team during my eight-week software engineering internship. BARK uses aircraft design and manufacturing data in augmented reality applications for factory work and inspection, and my assignments were in the backend that processes that data. My documentation tool became part of the team's daily work. The team also decided to use Temporal as its next workflow engine after reviewing my research and prototype.
I used Kiro CLI in a Python program to generate and update README files. Kiro is an AI coding agent, and I found that the context I gave it made a difference to the documentation it wrote. Asking for a README directly gave me a generic description of the project. Instead, I had it look at what the product does, what technologies it uses and how its files are organized, saving each analysis before moving on. It then uses all three to write the README. I put the script in a Docker image so the automated build pipeline could run it without having to clone another repository, which the build jobs weren't allowed to do.
One of the assignments I enjoyed was finding a center point for AR alignment. It was part of a Java parser I wrote to extract component coordinates from 3D models and produce metadata for BARK. Averaging the centers of a model's surface patches seemed straightforward, but that gives more weight to a side with more patches. Weighting by bounding-box volume also includes empty space around concave shapes. I tried calculating the polyhedron centroid with the divergence theorem, which gave the expected answers on test solids with known centroids. That calculation depends on a closed boundary, though, and our CAD exports didn't always satisfy that condition. Passing the tests didn't mean I could assume it would work on the real parts. I ended up estimating a center by weighting meshes according to size and limiting the effect of outlying geometry, then evaluated it on six real parts. The estimate isn't an exact volume centroid. What interested me was understanding why the mathematical method worked, and why that alone wasn't enough to make it suitable for the models I had.
The other large assignment concerned the background jobs that convert and package models for viewing. With the team's jBPM configuration, jobs went through one shared session and ran one at a time. Restarting the service could lose the work in progress. I compared Flowable and Temporal to see how they would run jobs concurrently and recover after a failure, including how retries were handled. Temporal was the option I recommended to the team. I then built a Java prototype to test it with real files. The prototype ran all seven steps of the model-viewer process, through both the direct and conversion paths, with independent steps running in parallel. I used typed interfaces instead of untyped maps to define what went into each step and what it returned. The team still had to connect it to production data services, move the remaining job definitions and finish the deployment work before carrying out the migration.
I worked with my mentor, Hao Chen, and the other engineers to understand what the existing services did and why they were set up that way. I could ask about the requirements, explain what I wanted to change and get feedback before revising my implementation. For Temporal, I presented my recommendation to the team and senior technical fellows, and wrote architecture and migration notes for the people who would continue the work. I also spent time with the other interns outside our assignments. The beach cleanup here was with my Integrated Product Team.
Unfortunately, I wasn't allowed to take many photos of the technical work because it involved proprietary information. :(