coinbend VS debug

Very good question. I don't have a degree so the way that I use to demonstrate my skills is all due to public projects. I'll show you the main projects that really landed me my first tech jobs. Granted, they weren't very good and have many engineering problems. I was still learning at the time but here they are:

1. https://github.com/robertsdotpm/pyp2p - This was an attempt to make a peer-to-peer networking library in Python. Don't use it or anything as it's horrible code. But it was enough to get me a job at a startup called Storj. I messaged the team and was able to talk about specific about the challenges of peer-to-peer networking which were relevant to the product they were building.

2. https://github.com/robertsdotpm/coinbend - This was my attempt to build a decentralized cryptocurrency exchange whereby all trades were done without the need for an intermediary to hold deposits using smart contracts. This was actually one of the first 'decentralized exchanges' made at a time when the only coins that existed were forks of Bitcoin. It was impressive enough to land me a job at Exodus which is still the most incredible company in the blockchain space.

((If anyone's wondering: I lost both jobs due to severe untreated depression. Lmaoo... But I'm on meds now.)) But yeah, companies absolutely will hire people without degrees and based on the quality of the projects you've worked on. I know that many people say that working on side projects doesn't matter. But you need to actually talk about your projects and reach out to people for it to matter. If you just apply through HR they'll just go through a generic list of things to check off while they look at your resume.

By the way OP: I've always found that taking the effect to actually understand the problems that companies are trying to solve and outlining how existing work that you've done qualifies you to provide a solution is the fastest way to get a job. But again -- you need to reach the people who know what you mean. Shout out to Storj and Exodus -- both great companies that I would recommend.

I've written Ruby for coming up on 20 years, so to be honest I haven't paid attention to what is written on that subject in recent years.

Bundler shouldn't be running inside a trap context, but you might be running into a situation where standard input/output from the actual process triggering your breakpoint has been redirected. In that case, ruby-debug[1] is a good option, as you attach to it from outside[2]. Basically, run "rdbg --open yourscript.rb" and then use rdbg -A from another terminal.

You use Pry remotely too[3] if you prefer.

[1] https://github.com/ruby/debug

[2] https://github.com/ruby/debug?tab=readme-ov-file#remote-debu...

[3] https://github.com/Mon-Ouie/pry-remote

what is ruby debug not able to do that you want it to do?

https://github.com/ruby/debug

a nice ide integrated experience:

https://code.visualstudio.com/docs/languages/ruby#_debugging...

https://github.com/ruby/vscode-rdbg

https://code.visualstudio.com/docs/editor/debugging

Execution is paused at the breakpoint (which has a little arrow pointing at it). You can then enter commands to the rdbg prompt to control the debugger. For a list of the different commands you can use, visit the documentation for the debug gem.

In 2017, I wrote a toy language called Goby[1] to learn how Ruby works. A few folks contributed quite a bit to it and one of them later referred me to my previous job (as a backend developer).

Fast-forward to 2021, I got interested in debugging tools so I started contributing to the then newly created Ruby debugger[2]. In less than a year I opened more than a hundred PRs and became the 2nd biggest contributor of it. And that eventually landed me a job to work on Ruby's development tools, like LSP servers, REPLs, and of course, the debugger :-)

[1] https://github.com/goby-lang/goby

[2] https://github.com/ruby/debug

Fun fact, Ruby as a single-threaded language is how most people experience it, but Ruby has a rich cooperative multitasking called Fibers that hopefully is getting more exposure, in amongst a bevy of competing implementations and other also-ran concurrency primitives (besides the usual contenders like Threads, Process fork, foreman that just runs several processes alongside one another...)

https://github.com/ruby/debug/issues/486#issuecomment-157531...

If you want to use debugging and multi-threaded or multi-fiber Ruby at once, you can! You just have to get a bit creative. I always refer back to this thread on the Ruby `debug` gem (though the advice applies to any other REPL you can use) about applying a Mutex. You can use the built-in Fiber.blocking to prevent other fibers from running at the same time as yours, or you can use a Mutex to just ensure that you don't hit the debugger multiple times in the same process IO that would mean you've got multiple REPLs all grappling for the StdIO at once.

For a long time Ruby dev who almost never did concurrency unless it was facilitated by the OS, or before being exposed to it directly in other languages like Go, the Ruby "super power" remains intact, it's just a bit more mysterious with the concurrency stuff added. Ruby has amazing diversity in its concurrency tools, which is a nice way of saying "the language authors decided not to pick a king concurrent runtime/winning gem whilst all of the competing implementations were all a bit nascent and un-fully-formed!"

I like the bruno/fiber-scheduler but it looks like it is not the winner. It should be easy to switch to another fibers implementation, I think async is the crown champion now, but I still haven't been motivated to switch - the fiber-scheduler that is named fiber-scheduler has been good enough for me, despite shortcomings!

Debuggers are powerful tools that allow you to step through your code line-by-line, inspecting variables and understanding the flow of execution. Using debuggers is a whole topic unto itself, and getting into the weeds with that would balloon the scope of this post. If you want more information on using them, I recommend reading the README for rdbg. This is the debugging solution for modern Ruby/Rails development. It's in Ruby's stdlib as of v3.1, and Rails 7+ apps include it in the Gemfile by default. I also recommend this section of the Rails guides for exploring how to use the debug gem with Rails applications.

Trace Inspector, a tool that displays Ruby trace logs with pretty UI while debugging in VS Code, has recently landed in debug.gem. debug.gem is a Ruby standard debugger library and the default debugger in Rails. Since debug.gem supports VS Code, you can debug Ruby programs in vscode-rdbg.

For newer versions of Rails (introduced in v7): Debug Gem

While pry is nice Ruby 2.6+ includes the debug gem in the standard library which avoids the need to install another dependency.

Have you tried ruby/debug's catch command? You can do catch Exception to achieve the same effect.