rikatee

Django release notes are great https://docs.djangoproject.com/en/3.1/releases/ but I got frustrated that when upgrading multiple versions it was not easy to get a summary of relevant changes as it's one release per page. If upgrading multiple versions that I have to go across multiple pages.

The changelog comparison tool solves that: choose two versions and see all release notes between the two.

It's also used by Django Doctor codebase audit tool to highlight when a given github project is vulnerable to bugs in the Django version being used.

Now we can remove baked in tech debt from Django codebase, not just detect it during code review (previously https://django.doctor could only suggest improvements to github PRs)

glad you liked it :)

If you submit the same answer twice then it adds them twice.

Future version of the quiz will close that bug :)

for that you need a human unfortunately ;)

on the roadmap is config file but for now devs can just ignore the advice :)

This covers it quite nicely https://django.doctor/advice/C2006

wow well done!

In the real world the GitHub PR bot gives the dev the choice of committing the advice or not. I appreciate that does not reflect perfectly in the game :)

> I also don't see anything wrong with explicit default arguments.

Very much your and your team's choice. I for one see them as noise. Does it add value explicitly stating all the fields of Field? https://docs.djangoproject.com/en/3.1/ref/models/fields/#fie...

If you would not explicitly state all of the defaults why state a subset of them?

I think not because a think the bot cannot know is "why". An anti-pattern may be done for solid business reasons. It's Django Doctor's job to say "x could be y" and it's the dev's job to approve/reject the advice based on what the dev knows about the business and problems being solved.

You're right - that's why the GitHub bot just gives "food for thought" advice and does not block the merge.

It's "have you considered" rather than "you must do this".

The dev has the choice of if to commit the change that is suggested

That gets a bit lost in the game I know :)

Well done. Shows either you're a very intuitive dev, or Django is a very intuitive tool. Maybe both.

These problems I think are more to do with inertia and not having best practices in mind. It's easy to do CharField and not thing about TextField.

Plus over time requirements change, so when a model was created maybe the kwargs were perfectly valid - but over time as refactors occurred tech debt crept in.

I think it's a good thing. It indicates:

- Django is big (because it solves a lot of problems)

- there exists a learning curve

Sometimes people miss best practices when the interplay between those two points occur.

Fortunately bots exist to help with that problem

Thanks! and blimey well done that's better than I did first go around

I made this as a tech demo for what https://django.doctor is capable of doing in Pull Requests when it reviews your code.

Django Doctor is a code improvement bot you can add to GitHub to review your PRs

We now support private repos :)

If anyone would like to read more on the topic I wrote a blog post that includes this point and others: https://djangodoctor.medium.com/the-real-difference-between-...

because while Django Doctor suggests potential improvements, I acknowledge they're not guaranteed to be correct according to the context

not a fan of foxes, I see :)

I'm working on private repo support. chat with me at django.doctor if you want to get in on the private beta

Thanks! Even the simple "Syntax Error" comment could be the difference between bed time and another cup of coffee.

There will be shortly.

In summary: - we dont' collect ANY personal data because we don't need ay. we don't even have a database, We can't misuse your persona data if we don't have it!

- we don't create any non-essential cookies on browser

- your code is deleted as soon as it's checked

- the servers are hosted in USA/London

That's good insight, thanks :)

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

I'm sorry swiley :'(

Glad to be of service :)

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.

Nice! They're quite different beasts though. Restyled enforces code style, while Django Doctor suggests fixes for Django specific anti patterns and has a fox for a mascot. See. Completely different ;)

Your wish is granted kind of: https://github.com/marketplace/django-doctor/

It's a github app, rather than an action. Actions still require you to update a yaml file to use.

Regarding CI: I don't think Django Doctor should block or fail builds. Django Doctor looks suggests improvements, but it's up to the dev to decide to commit them. Plus, no bot should be commiting changes without dev approval. Hello Skynet!

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.

in the case of Django Doctor - there is no direct alternative you can run locally. Nothing else does this:

- finds Django anti patterns. pretty sweet.

- suggests the fix in the PR. One click fix? yes pls.

- Check your entire codebase in seconds via https://django.doctor with no need to install or sign up for anything? hell yeah.

- has a fox as a mascot