Hacker News Reader

Comment by rzodkiew | Hacker News Reader

I'm probably old fashioned, but I don't understand why would I want something like that as a web-service, rather than something I can run locally (like all the js linters or rubocop).

View on HN

It's not either/or. We use them in case a developer forgets to run them, or hasn't set their environment up properly or similar.

That's why you make it part of the CI pipeline and require it to pass before merging, making it impossible to forget.

The only reason you'd release a tool like this as a github integration and not an open source library (optionally with a CLI tool) is that you want to get money from it - nothing wrong with that, but that is very much an either/or question.

Blocking the build works well for things that are boolean "correct" or "not correct", but some things are not are just "food for thought". Django doctor points out when something looks like it can be improved, but that's ultimately up to the dev to take the advice. It's "have you thought of..." rather than "you must do this".

With the advantage that if the dev likes the advice, all they need to do is click "commit"

I've been in a few organization with hundreds of repos. It can be a pain to upgrade libraries. In this context, with SaaS you don't need to.

But yes, SaaS is not a silver bullet. If you like convenience and getting updates, bug fixes, and quick set up with no overhead then it's for you. If you want to run things yourself then understandable have a great day :)

>I've been in a few organization with hundreds of repos. It's can be a pain to upgrade libraries.

Sure, configuration management is hard, it doesn't mean you don't have to do it. If anything, in an organization that big, you should have someone creating a process for managing dependency upgrades. There will always be critical security vulnerabilities and other use cases for package upgrades that need to be patched across all of your repos.

In general I agree, but specifically for this: It does mean you don't have to do it _for this particular feature_. If we can "reduce hard" then that's a good thing. It's one less configuration to manage.

But if you have to do it sometimes, and you're proactive about process and automation, not only is this good practice for quickly patching security vulnerabilities, it will help you solidify your configuration management processes and automation, because at the end of the day, you're going to have to do it.

The suggestion that you don't have to do it for this particular feature is kicking the can down the road.

> It can be a pain to upgrade libraries. In this context, with SaaS you don't need to.

I see manually updating libraries as a feature that allows for deterministic linting.

I wouldn't want my linter to always be updated to the latest version because that might introduce warnings or deprecation errors that aren't warnings or errors in the version of the tools used in the code I'm linting.

Agreed in general, but Django Doctor is not a linter. It suggests code improvements the dev can choose to commit with one click. Linters block builds until the code conforms to a pre set style, often requiring the dev to manually do it themselves. Django Doctor gives "food for thought" that the dev can follow or ignore.

The same can be said for a linter. You can just ignore the lint warning and have it not block the build as well.

Most linters also don't require manual changes but do automatic fixing, ie: black[0].

Non-user initiated updates to QA tools will only lead to alert fatigue because people will write it off as an update to to tool.

[0] https://github.com/psf/black

Maybe I'm grandiose but I see the "form factor" as key: MP3 players existed before ipods. Some people found the new form factor more convenient.

Similarly they way Django Doctor works is more convenient:

- it's suggests a change that can be applied in one click - it's suggestion can be ignored - no overhead cost because it's SaaS

but yes, if you don't value SaaS in this context then that's fair enough :)

It might be because I'm old fashioned and come from a terminal background (you kids with your MP3's, I'll stick with tapes). But for me the SaaS is the overhead. Moving away from my terminal and local dev environment. Waiting for web requests to return before I can continue really breaks my workflow. Also the idea that formatting and other coding standards are not decleratively enforced (and autofixed) but an arbitraty choice during review has become strange to me over the past few years. As with Black for example. Every choice about formatting can be premade and automatically applied by a computer. This saves so much time in the review process. No bike-shedding about tabs or spaces. Just conform to one autoformatted standard and optionally convert it to your local preference (and back) in your IDE/Git-hooks.

That said, if you live in Github and other SaaS services this fits really well. In the past I've setup similar workflow to cater to people who never dared to touch a terminal or Git itself. So there is certainly enablement this tool brings to some people.

That's good insight, thanks :)

I wrote https://github.com/kalekseev/django-extra-checks that do exactly this using builtin django checks framework, it has a couple of drawbacks though: 1) Django checks doesn't provide a good way to disable checks for some lines. 2) Parsing AST is quite slow and django check runs on every dev server reload.

Reply on news.ycombinator.com