# Ethlio

Elio has contributed to different instances of Starkware projects at dOrg, after his return from his full time position at badger. So I analyzed his contributions to the open source Starkware AMM demo and closed source StarkEx monorepo; as well as some of his contributions to Badger's open source UI.

## Starkware AMM demo: In-depth analysis
### Statistics:

* Total lines: 3,300
* Contribution = 64.21%

### Automated analysis results:

- General assessment: https://sonarcloud.io/summary/overall?id=namesty_starkware-demo
- Main points of improvement: https://sonarcloud.io/project/issues?authors=eliobricenov%40gmail.com&resolved=false&types=CODE_SMELL&id=namesty_starkware-demo

#### Conclusions and observations

- There are no reliability or security bugs
- There is very little percentage of code duplication; which is very positive
- All ratings are "A"
- The "code smells" are only 3 and trivial.
- Overall, the code's exceptionally clean.

### Human analysis results:

#### Positive highlights:

- Code's well separated; concerns are isolated atomically. Even util functions are semantically organized
- React code's idiomatic, hook-oriented and leverages Context API and React Query
- Application has tests. UI components are being tested with React Testing Library
- CI/CD pipeline's in place, for automatic linting, testing and deployment to Netlify
- Avoids using string literals directly as constants
- Abstract configuration variables into environment variables
- Commit history is good (denotes context of updated code, is atomic, etc.)
- Proper use of Material UI, using its Grid system, customization through the components's APIs.
- Styling through theming to make UI resilient to design changes and easy to update
- Componentization and state management seems correct too

#### Points of improvement:

- Application code's services have no unit tests. Tests not only help to verify things are working correctly, but also push coding towards the pattern of dependency injection (as it makes code easier to test), gives insight on code that may be difficult to consume, exposes unncessary entrypoints, etc.

## StarkEx Dashboard: Contributions

### Contribution highlights:

- He implemented a distributed cloud functions architecture with Google Cloud
- He added tests and monitoring functions to catch error notifications via email and Slack
- He came up with a way to scrap historically accurate DeFi data, through consumption and processing of services like Moralis. The data he harvested isn't even something Starkware had prior to his implementation
- Starkware pushed him to compare his data results with L2Beat because there were some mismatches and they trusted L2Beat a lot. Elio's implementation turned out to be the correct one and L2Beat ended up changing their data and patching their implementation because of him
- He detected additional technical needs very early, and proposed a working solution that was scalable and that suited the client's needs. He saw and went beyond what the client said, and could detect obstacles and solve them way before the client even became aware of such obstacles.

## Badger UI: Contributions

### Contribution highlights:

- Code's almost totally UI oriented with React.
- Clean, idiomatic React, with hooks patterns
- If you see the review comments, like here: https://github.com/Badger-Finance/v2-ui/pull/244/files; you'll see that the patterns are correct and comments are around minor implementation details