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."
Author of peek here. Honestly, I got burnt out. We stopped using this internally at GitHub for our secondary Rails applications which made it difficult to continue working on. Rails was going through its identity crisis with asset pipelines and I didn't feel like trying to support every available option for people like Sprockets, Importmaps, NPM, Bower, etc. It was nice when there was the paved path and users could generally follow the README and be up and running quickly.
Hey there, sorry if this came across as critique on the project itself or you personally. I get it, priorities change and projects get abandoned by the original maintainers.
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.
It's a fair critique! I still keep kicking the can down the road about revisiting the project and modernizing it. The ecosystem has moved along so much since I last revisited it I'll need to take a fresh look at it, accepting the PRs that are currently open is likely out of the question.
> 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.
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.
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.
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.
This looks excellent. I love the cross-pollination of good ideas that seems to be frequently happening between the Laravel, Phoenix, and Rails frameworks.
Very cool project. Similar to the Ruby on Rails debugger that I wrote, which allows you to see all of the methods that are called for a given request (and param values, return values, etc).
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.
First time encountering the term 'debugbar', I see:
> 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?
It's for having in your dev environment and/or sometimes as a toggle for "Special Requests" -- if your session is authenticated and you're marked as blessed, you get extra information about what the application is doing under the hood so you can see what's going on in production as well.
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.
We recently installed something similar (https://miniprofiler.com) into a legacy ASP.NET MVC app. It is setup to only be visible in local development environments.
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.
The last two places I've worked I added a custom "debug bar" of sorts. We typically use in dev and lower QA environments, and they quickly become indespensible to help answer questions like "which version of service X is deployed", something that may be easy for a dev to answer as they can look at what is deployed on the server, but harder for a tester who can only access the frontend.
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".
Also handy (regardless of framework, language, etc) is if you use feature flags, if you're using actual valid credentials against a service or a local testing service (eg S3 vs minio, etc).
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 :-).
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.
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.
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.
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.
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.
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.
Just curious... how come noone else in the ruby scene seems to use an actual debugger? IDEA has a front-end for ruby-debug-ide and it is divine, it puts pry to shame. Does VSCode or others not have this or something?
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.
Most devs I've worked in across multiple languages don't use debuggers. They can't be bothered to spend a couple hours figuring it how to configure one. Meh, to each their own. I always spend the time configuring one and it always pays off.
After monitoring my portfolio performance, CASSANDRA_ E_ OAKLEY blew me away $70k in the last two quarters alone, I learned why these experienced traders make huge profits from the seemingly unknown market.. Also on Facebook CASSANDRA _E_ OAKLEY
Thanks puuush for posting it.