Jons Mostovojs @jonn@social.doma.dev

@nasser oh, I've seen something on my partner's screen about heartbleed 2.0. Is there a tl;dr?

@pepicrft the project is called "zeroHR". It takes matasano hiring methodology[1] and dials it to 11.

Basically, we provide small and medium companies with a way to make sure that they don't hire over- or under-qualified software engineers :)

[1]: https://sockpuppet.org/blog/2015/03/06/the-hiring-post/

@pepicrft we're also building in "public" (in an invite-only Zulip, where we invite cool people).

You can join via an invitation link: https://zulip.memorici.de/join/sa6vxky5vmwlgn9xth7st2mj/

We have #beam channel there and a book club. If you want to, come and hang out.

@pepicrft thanks! Talk to you then. I'm also building with life partner btw. :)

BTW, @pepicrft, I've noticed that you're continuously building stuff.
I wonder if there's some synergy between your hobby building and our hobby building.
We could book an intro call[1] or exchange some texts, whichever you prefer.

[1]: https://calendly.com/manpages/30min?back=1&month=2022-10

@nicd haha, my NIH was the authentication with verifiable credentials (without blockchain) because identity providers just don't make sense as a concept.

Then I was thinking about whether or not to support VC standard strictly and DID at all, and erred on the side of "nope". For the reason of "ain't nobody got time for that".

#twittermigration

Registration is open at social.doma.dev. Please no conspiracy theorist scum, russia and trump supporters, antivaxers.

Boost for outreach.

cc @nicd

@nicd or self-host and see for yourself :)

@pepicrft oh, there's also one rather funky way! Rewrite your mix.exs to point to a dependency via filesystem. For example, a `plug` dependency shall become:

```
{:plug, path: "deps/plug"},
```

Now you can insert some hack like IEx.pry[1] straight into your dependency where you want it and `mix compile` shall automatically recompile it. Now it's suffice to run the code in `iex` and you'll get dropped into the breakpoints.

I think that this is the most Elixir way to do it, to be honest, but I'd still check if you're solving XY problem before trying. Static code analysis and tracing are way more impactful while trying to understand what's going on in a BEAM system than step-by-step debugging.

https://hexdocs.pm/iex/1.13/IEx.Pry.html

@pepicrft it doesn't make sense in Erlang at all. Do you stop the execution of all the SMP schedulers at the same time? How do you know that other processes a process in question interacts with has deterministic state and thus you get actual signal rather than noise? Here's a small pearl that talks about it: http://blog.plataformatec.com.br/2016/05/tracing-and-observing-your-remote-node/

That said, if you are writing very simple software and depend on very simple libraries, then you need to compile your dependencies with debug symbols on (`mix deps.compile --debug-info` should suffice) and now you should be able to run debugger. Sadly, it didn't work for me when I briefly tried and the error was:

Invalid beam file or no abstract code: "/home/sweater/github/do-auth/_build/dev/lib/bamboo_smtp/ebin/Elixir.Bamboo.SMTPAdapter.beam"

I think that if you really want to spend time on conventional debugging with Elixir, you can try these steps yourself and then, if you also have the same error, ask on https://elixirforum.com/

@pepicrft not sure what do you mean, but you can totally attach to a node and then observe the execution with pretty much anything, from :sys to full-blown observer.

https://www.erlang.org/doc/man/observer.html

I'm back here because the bigger outreach of spreading the word about the hardships of Ukraine on twitter isn't worth using a platformed owned by mr. musk, the russian asset.

@mlemweb @fossandcrafts you're cool!