[HN Gopher] RoR Debugbar
___________________________________________________________________
RoR Debugbar
Author : puuush
Score : 160 points
Date : 2024-02-18 16:39 UTC (6 hours ago)
(HTM) web link (debugbar.dev)
(TXT) w3m dump (debugbar.dev)
| nickjj wrote:
| If anyone is interested in this sort of thing I started a
| proposal with a list of ideas and features around a Rails debug
| toolbar at: https://discuss.rubyonrails.org/t/proposal-a-fully-
| featured-...
|
| 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.
| westurner wrote:
| Django Debug Toolbar > Panels > Default built-in panels, Third-
| party panels, API for third-party panels: https://django-debug-
| toolbar.readthedocs.io/en/latest/panels...
|
| 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
| the_gastropod wrote:
| This looks excellent. I love the cross-pollination of good ideas
| that seems to be frequently happening between the Laravel,
| Phoenix, and Rails frameworks.
| tommica wrote:
| > cross-pollination
|
| That's a great analogy!
| jpb0104 wrote:
| Symfony's dev toolbar has got to be one of the best.
|
| https://symfony.com/doc/current/profiler.html
|
| Always miss this in my RoR projects.
| julienbourdeau wrote:
| Yeah it does SO MUCH!
| ulfbert_inc wrote:
| There's peek[1], albeit not exactly the same thing
|
| [1] - https://github.com/peek/peek
| julienbourdeau wrote:
| I didn't see a demo, only the closed bar with some timing
| stuff. Does it open to do more?
| jupp0r wrote:
| Last commit was 5 years ago. I feel like this is 80% of the
| rails ecosystem nowadays.
| awestroke wrote:
| I definitely get that feeling as well. 80% ghost town
| rubyfan wrote:
| Yet almost all of it still works.
| jupp0r wrote:
| All of it almost works.
| sergiotapia wrote:
| I'm moving from Phoenix back to Rails for a new project.
| Is it true Rails is dead? I thought it's community was at
| least 10x the size of Elixir's.
| notjoemama wrote:
| Rails isn't dead. In fact Hotwire and Stimulus have
| breathed some new life back into the community. With
| Rails 7 there's new and interesting changes happening
| like the normalize method for normalizing data before
| it's persisted to the database, the new testing coverage,
| and the new encrypted credentials, which can replace
| devise as it's easier to extend. STI is still awesome and
| concerns help DRY up the code. I know it's not the new
| kid on the block anymore, but if you code into a Rails
| way of doing things it's still crazy fast for rapid
| development.
| kingkongjaffa wrote:
| I dont know
|
| 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
| matthewmacleod wrote:
| It's a good choice for building a full stack web
| application. You know... the stuff that it is designed
| for.
| pell wrote:
| Ruby is a very beautiful language both in logic and
| consistency. Rails is a mature framework. The ecosystem
| is very much alive albeit not "exciting" anymore and at
| the end of the day people use what they know. The 2010s
| have produced a large number of Rails developers. For the
| majority of CRUD apps Rails (or Laravel or Django) are
| just fine thus there's no need to really make a switch.
| Finally, React can power a lot of things but in my
| experience it is far from offering the right integration
| and rapid development speed that something like Rails or
| Laravel come with.
| sergiotapia wrote:
| > react and typescript
|
| 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.
| jupp0r wrote:
| Rails is practically unusable for anything that requires
| concurrency inside of serving one request. If you have
| all your data in the database that your rails app
| connects to everything is great. If you need to call out
| over the network to 12 different services to serve your
| request or want to do computationally intensive things,
| etc, another language with support for concurrency is a
| better choice imho.
| hakunin wrote:
| I don't think this is quite right. I've done a survey a few
| months ago when deciding what to use for a new project
| (primarily comparing Ruby and Go). What I saw was many
| people rallying around the top useful libs out there. I
| also saw numerous brand new libs showing up, fixing
| mistakes of their predecessors. And each time I compared a
| popular Ruby project with a popular Go one, I'd find
| consistent activity from multiple maintainers in the
| former. And a lot of initial activity that completely dies
| down in the latter.
|
| 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.
| pmontra wrote:
| Good idea but it seems that every developer of a project is going
| to have to use it, because it's a gem and it must be included in
| a layout. It's possible to do that conditionally based on an
| environment variable, but we're still adding some code to the
| Rails app. A better way would be to turn it into an extension to
| developer tools, like the ones for React and Vue. I've got them
| into my Firefox.
| MarceColl wrote:
| How would you be able to implement this functionality only from
| the frontend without ever adding backend code? You'll always
| need to expose this info from the backend somehow. Of course
| with react and vue the data is available since it's already in
| the frontend.
| julienbourdeau wrote:
| Yeah you always need a backend part as part of your dev
| dependencies but currently you also need to add a little
| snippet in your production view code.
|
| 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.
| pmontra wrote:
| The downside is that if the project decides not to have
| that in the code, nobody gets it. Example: I suggest to a
| customer to use it. They decide they don't want it, I can't
| use it too.
| samtheprogram wrote:
| There's no reason you couldn't just leave it in your own
| branch of git and not merge it. It's not that hard.
| julienbourdeau wrote:
| That's a good point, I didn't consider it this way.
| ckolkey wrote:
| One thing to check out: ruby-lsp gets around this by
| using a custom gemfile, which enhances the project with
| the lsp's dependencies. That means you can use the gem,
| with bundler, without adding anything to the "official"
| project gemfile.
|
| You could probably accomplish something similar, and
| possibly inject some rack middleware to add the view, or
| even mount it as a rails engine.
| loktarogar wrote:
| Without some kind of perf api baked into rails, this will
| require some server side code at the very least. An
| extension won't work without _something_ on the server.
|
| But, there's also nothing stopping you from adding this
| during development and not committing it.
| loktarogar wrote:
| Perhaps a future improvement is like how rack-mini-profiler
| does it, and just injects itself
| julienbourdeau wrote:
| Hi I'm the maker of the debugbar. If you have any feedback or
| question, just let me know.
|
| Thanks puuush for posting it.
| bt3 wrote:
| Hey Julien, very nifty!
|
| Can you comment on the inspiration/ similarity with the Laravel
| Debugbar [1]? I noticed your GH says "Laravel by Night" :)
|
| [1] https://github.com/barryvdh/laravel-debugbar
| whizzter wrote:
| If you click learn-more on the linked page the first section
| ends with this:
|
| ".... 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."
| julienbourdeau wrote:
| I'm a big fan of the Laravel debugbar. I even added the Jobs
| collection when I started working on this
| https://github.com/barryvdh/laravel-debugbar/pull/1470
| Alifatisk wrote:
| Very cool, I'll add this to my next project!
| maxlin wrote:
| Thought this was going to be about debugging Rigs of Rods bars
| (joints). Meh
| deedubaya wrote:
| Cool project, but I hate the use of the RoR acronym
| binsquare wrote:
| For anyone else who was confused by what ROR means, it's ruby
| on rails.
| loloquwowndueo wrote:
| Y tho?
| mvdtnz wrote:
| Because undefined acronyms suck. Plenty of space in the title
| for the full "Ruby on Rails Debugbar".
| thr0waway001 wrote:
| As someone who has used the Laravel version of this I gotta say
| it has been pretty damn helpful.
| preezer wrote:
| Very, very, very cool Idea. I'll try it tomorrow
| aurelius83 wrote:
| This seems pretty similar to
| https://github.com/dejan/rails_panel. Was that your inspiration?
___________________________________________________________________
(page generated 2024-02-18 23:00 UTC)