Maxime Buffa
@madmakks.bsky.social
Sr. Backend and DevOps Engineer
Elixir/LiveView Contractor at blinq (blinqme.com)
https://github.com/mbuffa
https://mbuffa.github.io/
Elixir/LiveView Contractor at blinq (blinqme.com)
https://github.com/mbuffa
https://mbuffa.github.io/
And here I am.
With a 7k LoC pull request.
With a 7k LoC pull request.
November 18, 2025 at 11:47 PM
And here I am.
With a 7k LoC pull request.
With a 7k LoC pull request.
Ahah, I get it. You made some changes on the right one though.
Nothing wrong in keeping the "e" as-is. I just do think that the fact it's cropped strengthens the "stamp" look.
Nothing wrong in keeping the "e" as-is. I just do think that the fact it's cropped strengthens the "stamp" look.
August 22, 2025 at 10:35 AM
Ahah, I get it. You made some changes on the right one though.
Nothing wrong in keeping the "e" as-is. I just do think that the fact it's cropped strengthens the "stamp" look.
Nothing wrong in keeping the "e" as-is. I just do think that the fact it's cropped strengthens the "stamp" look.
Something like this (pardon the Krita skills ;^)
August 22, 2025 at 9:57 AM
Something like this (pardon the Krita skills ;^)
Super big centered logos look terrible no matter the case, IMO. I'd rather have a small, subtile logo on the top right or left.
For the logo itself, I would adapt it, with the "e" on the top, and "Erlang" in thin font, T-Shirt color in Red (the logo's background color).
For the logo itself, I would adapt it, with the "e" on the top, and "Erlang" in thin font, T-Shirt color in Red (the logo's background color).
August 22, 2025 at 9:38 AM
Super big centered logos look terrible no matter the case, IMO. I'd rather have a small, subtile logo on the top right or left.
For the logo itself, I would adapt it, with the "e" on the top, and "Erlang" in thin font, T-Shirt color in Red (the logo's background color).
For the logo itself, I would adapt it, with the "e" on the top, and "Erlang" in thin font, T-Shirt color in Red (the logo's background color).
What a mothstosity!
August 20, 2025 at 7:17 AM
What a mothstosity!
Where are you, Marshall?
August 18, 2025 at 8:40 PM
Where are you, Marshall?
When you make some Sentry.Client.push_event() calls to debug your WebSocket reconnect flow on Friday evening, and somebody microblogs about something similar on Monday:
a close up of a stuffed monkey wearing a green shirt and blue jeans .
ALT: a close up of a stuffed monkey wearing a green shirt and blue jeans .
media.tenor.com
August 18, 2025 at 8:19 AM
When you make some Sentry.Client.push_event() calls to debug your WebSocket reconnect flow on Friday evening, and somebody microblogs about something similar on Monday:
Yes, but Trailblazer happened in 2015: github.com/trailblazer/... and inspired a couple of developers.
No longer "fat models, skinny controllers" and no use of unpredictable ActiveRecord hooks, but dedicated services/operations.
No longer "fat models, skinny controllers" and no use of unpredictable ActiveRecord hooks, but dedicated services/operations.
GitHub - trailblazer/trailblazer: The advanced business logic framework for Ruby.
The advanced business logic framework for Ruby. Contribute to trailblazer/trailblazer development by creating an account on GitHub.
github.com
June 21, 2025 at 7:11 AM
Yes, but Trailblazer happened in 2015: github.com/trailblazer/... and inspired a couple of developers.
No longer "fat models, skinny controllers" and no use of unpredictable ActiveRecord hooks, but dedicated services/operations.
No longer "fat models, skinny controllers" and no use of unpredictable ActiveRecord hooks, but dedicated services/operations.
Given how agitated the waves look, it's obviously related to the stocks market.
April 16, 2025 at 10:43 AM
Given how agitated the waves look, it's obviously related to the stocks market.
Ah, Jose replied, see his answer:
github.com/elixir-lang/...
github.com/elixir-lang/...
Add except if exists to inspect by mbuffa · Pull Request #14385 · elixir-lang/elixir
Hello there,
This is a proposal to add a except_if_exists option when deriving Inspect, so that we may specify a list of fields that we absolutely want to avoid leaking into logs and ttys, in all c...
github.com
April 1, 2025 at 3:46 PM
Ah, Jose replied, see his answer:
github.com/elixir-lang/...
github.com/elixir-lang/...
Now that I think of it, this would be overwritten by any `@derive` in your schemas.
You may be better of deriving in your schemas, and define a test macro or function that would test inspect on your schema and check that it doesn't contain any sensitive data, I think.
You may be better of deriving in your schemas, and define a test macro or function that would test inspect on your schema and check that it doesn't contain any sensitive data, I think.
April 1, 2025 at 3:35 PM
Now that I think of it, this would be overwritten by any `@derive` in your schemas.
You may be better of deriving in your schemas, and define a test macro or function that would test inspect on your schema and check that it doesn't contain any sensitive data, I think.
You may be better of deriving in your schemas, and define a test macro or function that would test inspect on your schema and check that it doesn't contain any sensitive data, I think.
I don't think there's currently a way to do what you want.
But an option could be added to Inspect's derive macro to have an option that doesn't validate the list, like this:
github.com/elixir-lang/...
I'm not sure if the absence of validation would be well received though.
But an option could be added to Inspect's derive macro to have an option that doesn't validate the list, like this:
github.com/elixir-lang/...
I'm not sure if the absence of validation would be well received though.
Comparing elixir-lang:main...mbuffa:add-except-if-exists-to-inspect · elixir-lang/elixir
Elixir is a dynamic, functional language for building scalable and maintainable applications - Comparing elixir-lang:main...mbuffa:add-except-if-exists-to-inspect · elixir-lang/elixir
github.com
April 1, 2025 at 1:58 PM
I don't think there's currently a way to do what you want.
But an option could be added to Inspect's derive macro to have an option that doesn't validate the list, like this:
github.com/elixir-lang/...
I'm not sure if the absence of validation would be well received though.
But an option could be added to Inspect's derive macro to have an option that doesn't validate the list, like this:
github.com/elixir-lang/...
I'm not sure if the absence of validation would be well received though.