Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RoR Debugbar

debugbar.dev

Post reply on HN
Print view View original

61–70 of 80 posts

Re: RoR Debugbar

#61

Post by pserwylo »

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".

Re: RoR Debugbar

#62

Post by thejosh »

pserwylo wrote: post #61

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 info…

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 :-).

Re: RoR Debugbar

#63

Post by dewski »

jupp0r wrote: post #59
dewski wrote: post #50

Earlier quoted context omitted.

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 g…

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 ecosy…

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.

Re: RoR Debugbar

#65

Post by zelphirkalt »

jupp0r wrote: post #42
sergiotapia wrote: post #35

Earlier quoted context omitted.

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.

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.

Can you explain why concurrency within processing a request makes things difficult for Rails?

Re: RoR Debugbar

#66

Post by hit8run »

jupp0r wrote: post #42
sergiotapia wrote: post #35

Earlier quoted context omitted.

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.

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.

Couldn’t you solve this problem with something like this:

https://ruby-concurrency.github.io/concurrent-ruby/master/Co...

Re: RoR Debugbar

#67

Post by pmontra »

ckolkey wrote: post #31
julienbourdeau wrote: post #26

Earlier quoted context omitted.

That’s a good point, I didn’t consider it this way.

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.

Some details from https://github.com/Shopify/ruby-lsp

> 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).

Re: RoR Debugbar

#69

Post by pjerem »

jupp0r wrote: post #52
francislavoie wrote: post #48

Earlier quoted context omitted.

You could say the same for PHP. But for 99.9% of applications, that doesn't apply.

Yeah, right. Because all the interesting things nowadays happen on the same server that renders your html and nobody calls into other SaaS APIs or interacts with external systems much. 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.

> 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.

Post reply on HN