# axo Application

## Code Sample
#### https://github.com/memorysafety/sudo-rs/tree/main/src/exec

I implemented most of the execution layer of sudo-rs which can be found here. I found this particularly interesting because we had a huge C codebase that we wanted to replicate but at the same time we wanted to leverage all the abstractions provided by Rust and keeping the number of dependencies minimal as well.

## Writing Sample
#### https://github.com/rust-lang/rust-bindgen/blob/ba0ccdb471afa7815c8754f4d43603586aaa9f7a/bindgen/options/mod.rs#L30

A sample of technical writing would be the documentation of a macro in the bindgen codebase that is used to define all the options exposed to the user.

#### https://ferrous-systems.com/blog/bindgen/

A more divulgative sample would be this blogpost explaining some of our contributions to bindgen.

## Analysis Sample
#### https://github.com/memorysafety/sudo-rs/issues/623

While developing the `sudo-rs` first versions, we decided to mark all the sockets as nonblocking to avoid silent hangs.

Once we had a mechanism to poll the sockets and guarantee that using them wouldn't block anyway, I removed the nonblocking mode from the release builds (https://github.com/memorysafety/sudo-rs/pull/619). This caused a bug later that only manifested as the CI workflow failing due to a socket being blocked at random.

I realized this happened because not all sockets were being polled before sending or receiving messages. Thanks to the fact that one of my coworkers suggested to keep the nonblocking mode on debug builds, it was easier to find the culprit in question: https://github.com/memorysafety/sudo-rs/pull/624

## Presentation Sample

#### https://www.youtube.com/watch?v=ltayS6B8kGM&pp=ygUVY2hyaXN0aWFuIHBvdmVkYSBtaXJpL

This is my most recent presentation to the day, it had to do with some of the work I did for miri where I added shims for several syscalls so miri could access some of the host resources.

## Tell us about a tool you use often

I'm very prone to use terminal tools such as `ripgrep`, `fd`, `sd` and the Github CLI because hey have sensible defaults and can be composed easily with other tools. In general, I like tools that do one thing and do it right, but at the same time can be easily configured. Lately lot of Rust versions of common tools fall into this category in my opinion.

In comparison, `find` and `sed` require longer commands and more convoluted syntax than `fd` and `sd` to simply replace a word in a filtered list of files. They are powerfull tools, but their Rust counterparts make the simple tasks easier.

## Tell us about a collaboration you really enjoyed

I really enjoyed the initial development of `sudo-rs`. It was a collaboration between two companies which added a lot of diversity to the project.

I have very fond memories of long pair-programming sessions where we were basically dissecting the original sudo implementation and understanding how it worked by trying to break it.

Eventually we converged to a workflow where every single person had "ownership" over a specific part of the codebase but we all had a "leg" on someone else's part. Meaning that we always had someone who could discuss different approaches to solve a problem or to come up with better designed solutions.

We also had the chance to meet in person once and plan the roadmap for the project which allowed us to set our priorities straight and avoid wasting time on features that weren't that relevant.

## Tell us about a tradeoff you faced, where you made the wrong call
#### https://github.com/rust-lang/rust-bindgen/pull/2263

I was slightly annoyed by the fact that bindgen didn't had a clear separation between the application state and the inputs provided by the user. This was highlighted when an user was trying to clone some entities exposed by bindgen so they could be reused in different parts of their build process.

I expected the changes required to split the state from the inputs to be significant, so I was faced between consulting this with the current maintainer of the project to come up with a solution or to figure it out myself and open a pull request with the refactor.

Since I was in constant communication with the maintainer, I knew that they weren't available at the time due to personal circumstances. I had to choose between defering solving the issue in a manner that was decided with the maintainer until they had time to discuss such a big change; or solve it on my own, saving the maintainer's time in analyzing and deciding on the solution if I got it right, but risking my solution being considered not optimal. I opted for the second option as I thought the change wouldn't be that large anyway.

It turns out that I was wrong and I ended up with a pull request of 2000 lines of code that was rejected because the maintainer considered the benefits too small compared to the number of changes required to do the split.

This PR was eventually abandoned and closed. It would have been better if I had discussed this issue beforehand with the maintainer and, in case we had a consensus on doing this split, plan how to do it incrementally so it could be reviewed easily without disrupting everyone else's pull requests.