OK, this is extremely neat, I was thinking of doing something like this but by breaking bigger projects into smaller pieces.

I am ready to be a full contributor, count me in.

Even without junior or mid elixir jobs, you can cry in 90% of cases when looking at a elixir codebase that was written by someone that switched to elixir and still writes in the way it used to in their previous languages, and there are countless cases when this happens in companies, one of them I discovered recently.

The biggest value I see from this platform is teaching of how to write “standard” code, in a manner how credo enforces consistency at syntax level. At the same time this also means that the focus of the assignments should be on quality, not quantity. Each example should prove excellence in all aspects of what it makes a good codebase, namely: simplicity/clarity/documentation/tests.

A humble first version of https://elixirland.dev/ is now online.

I’d really like something like this but about telemetry. I understand technically how it works, but setting it up to be practical and actionable is beyond me apparently

So, Phoenix / Elixir gives you a lot of tools to help you with breaking up big apps, there is:

• Phoenix Contexts / Modules / Umbrella apps/ The fact that any file can live anywhere is great for Domain logic.
• Phoenix pubsub for eventing / realtime communcation between parts
• EXQ / background workers
• OTP for singular state enforcement
• Opus.Pipeline for workflows
• Statemachines

et cetera. The core issue IMHO is the question “when should we use which part”, so that we:

• Don’t make things even worse (ever tried debugging an app that is strung together with Pubsubs? Sideeffects with sideeffects)
• Do not get stuck in refactor hell (lets change the wheels on a car while driving!).
• Don’t get stuck in a Design Pattern hell (FactoryFactoryFactory).

I think you can teach all of the tools of the toolbox above, but knowing when to use what is mostly down to experience IMHO. My teacher used to call it “Navigating the swamp”.

Now that I think of it, you can probably make an example where you basically say “as an exercise it has been decided that in this case we will try and decrease the complexity of the app by using a Pubsub pattern”.

You would probably be able to create one single “complicated” example and have multiple possible solutions. Start with a SignupController that is 200 lines long.

• Convert it to using Managers
• Convert it to using Background workers where possible that update the frontend using Pubsub
• Convert it to use a workflow
• Convert it to use a statemachine …