RoR Debugbar(debugbar.dev) |
RoR Debugbar(debugbar.dev) |
Thanks puuush for posting it.
Can you comment on the inspiration/ similarity with the Laravel Debugbar [1]? I noticed your GH says "Laravel by Night" :)
".... I was able to explore my application in ways I didn't think was possible. Yet, I always missed what I was used to in PHP with the Laravel Debugbar."
https://symfony.com/doc/current/profiler.html
Always miss this in my RoR projects.
That's a great analogy!
NOTE: I'm not the author of this tool but they did end up replying in that thread. I didn't even know their tool existed until I happened to stumble upon it on Twitter well after my post.
It would be neat if something like this were built out and included in Rails at some point. Especially with Rails 8 focusing on tool integrations and overall developer happiness.
Firelogger.py//middleware.py: https://github.com/binaryage/firelogger.py/blob/master/firep...
Distributed tracing w/ OpenTelemetry, Jaeger; Metrics with ~JMX
W3C Trace Context v1: https://www.w3.org/TR/trace-context-1/#overview
> This project is inspired by what you get in the PHP world, with the Laravel debugbar for instance.
Curious to know what a debugbar does? From a read of the docs (and a play around) it looks like it lets you navigate your site as usual, but it displays which controller/action got you to the page, any callbacks, and database queries. Anything else? What's a typical use case for this, or is it more like turn it on and it's just handy to have that extra info in your dev environment?
Some let you add whatever information you want into the panel.
It's a convenience feature to make it easier to wade through information rather than having to dredge everything out of logs by hand, which a lot of people still do.
In areas of the code where ORMs obscure the actual SQL that runs, it's shortened the amount of time and effort it takes to discover a slow route and optimize it.
"Handy to have that extra info in your dev environment" is pretty spot on.
Other useful environmental information we find useful includes "which DB is being used", which OpenShift namespace (with a link to the console), traceability for the deployed artifact (e.g. links to the GitHub release tag, CI pipeline which built the artifact, docker registry with the correctly tagged image). Especially useful if you have downstream or upstream services, is to have colour coded status info about whether the services are up.
For the few days investment getting this up and running, it pays itself back in terms of time gained answering questions such as "Why doesn't this feature work? Oh, after investigation, this service was down during testing".
Enabling this for non-technical users really helped also report any issues they would see, it was great for testing environments.
Plus you would probably end up needing all this information anyway if you do any error tracking, so it probably exists somewhere already :-).
Great to see that you finally released this ;)
It could be a browser extension like Rails panel + meta_request but I think it’s also good that anybody working on the codebase always get the debugbar, regardless of their browser or setup.
Some of the other stuff mentioned in the blog post... why tail development.log if you can tail stdout and get all that nice console coloration and such?
> I hate switching constantly between the browser, and the terminal where I tail the logs. I want to see the debugging information in the same window.
Get yourself multiple screens my dude.
That said, this looks like an interesting project.
But, there's also nothing stopping you from adding this during development and not committing it.
You could probably accomplish something similar, and possibly inject some rack middleware to add the view, or even mount it as a rails engine.
> NOTE: starting with v0.7.0, it is no longer recommended to add the ruby-lsp to the bundle. The gem will generate a custom bundle in .ruby-lsp/Gemfile which is used to identify the versions of dependencies that should be used for the application (e.g.: the correct RuboCop version).
https://github.com/MiniProfiler/rack-mini-profiler gets you most of the way there and comes by default in the Gemfile for new Rails applications.
My comment was more aiming at the ecosystem at large. Lots of the (RoR) stack in my current day job depends on long abandoned libraries with unmerged fix PRs from years ago and I see this all the time in the Rails ecosystem. Interest in the ecosystem is shrinking and this is one symptom.
> Interest in the ecosystem is shrinking and this is one symptom.
I think the interest in the ecosystem is still very strong, there is just more publicity and marketing around the newest frameworks and capturing peoples attention. Rails is more than ever the best place to go zero to one, and still scaling past 100M at GitHub.
There are so many libraries that are largely feature complete. For example, Devise doesn't need anymore features. There is some traction of going the more lazaronixon/authentication-zero route which is a generator for owning the code rather than having everything live in a gem. This is just one specific example. Rails is moving more and more third party things in house showing it matured in the ecosystem and can move into core Rails.
I find myself reaching to a gem as a last resort if at all possible these days.
The overall feeling I got is that Ruby on Rails has gotten a lot more "getting shit done", "don't waste time" mode, — many businesses depend on it. Libs became higher quality compared to the early playful years.
People who use Rails really seem to love it.
But in 2024 things like react and typescript exists.
Python is there for data science stuff
Typescript is there for the web.
I don't understand why you would pick Ruby instead
Avoiding this stuff is one point on the list. I know I'm being a little snarky, but it's true. If you're building a fullstack app with fullstack devs you can avoid a lot of complexity that stuff brings.
These are nonstarters for me. It seems like vercel has corrupted react beyond recognition, and other full-stack frameworks like Remix just do a lot of `rigamarole` to mimic a fraction of what an older fullstack framework like rails/django/phoenix can do.
frontend is desperately trying to catch up to backend.
backend is trying to capture frontend to seduce people back, and they're getting there with freakishly good UX like phoenix liveview and rails 8's morph.
Rails is great for a world where an app was running on one server, but that world just isn't there anymore as much as it used to.
No, that’s still a choice you can make. It’s still possible to make your app run on one server with Rails/Django/PHP and to scale it horizontally and vertically very easily. The requirements of a web app / web site barely changed in 10-15 years, the only things that changed is that new ways to do the same things appeared regularly : some were real improvements, most are just hype-driven.
If you need to call external APIs you can still do it on the client if that’s what you want or on the server with task queues / messages queues which are still a good practice anyway and which can be handled by how many servers you want.
https://ruby-concurrency.github.io/concurrent-ruby/master/Co...
1. there are lots of problems preventing this working in practice currently (see my sister comment here: https://news.ycombinator.com/item?id=39433274).
2. the result of doing this is not the beautiful ruby code you are used to, compared to languages that have been designed for concurrency from the beginning.
Contrast that to other architectures like NodeJS where there's an event loop driving execution that would suspend execution and work on the next request while waiting for OpenAPI to respond. This enables you to service thousands or tens or hundreds of thousands of the same kind of request with the same amount of RAM.
There are approaches to improve this in Ruby/Rails like Fibers, however lots of libraries in the ecosystem use global mutable state and assume it's request local. If you have multiple requests served concurrently by the same worker, they'll overwrite this state and bugs will happen. Also baking this onto the language is not very ergonomical (beautiful in Ruby speech) if you compare it to languages where concurrency has been a primary design concern in the beginning.