petr25102018

Thanks!

One of my favorites from the book is to alias "xdg-open" to "open" because I never remember the command. So now I can just type "open X" to open a file system location or file in a normal GUI program when needed. It is a small thing but I use it a lot.

Something that I didn't put in the book because I learned it only recently is the use of "notify-send", aka you can send yourself a system notification from the command line or script (at least it workd for me in Gnome). For instance once a task is finished:

> echo "when finished send notification" && notify-send "system notification"

Pretty cool if you ask me!

Not for now. But I am happy to send you the PDF by email and receive a donation via PayPal if the reason is not to fund Gumroad. Just contact me on petr@stribny.name or @stribny on X.

Do you mean the website or are you talking about the book PDF?

I just changed the payment model before posting it here, so there is no past data on this. I don't expect it to generate revenue compared to normal sales (it will most likely be a small fraction). But for normal sales you need to be able to promote it.

My primary motivation is to share the work that I spent a lot of time on because I want to move on and work on other things (I don't want it to just sit on my disk when it can be useful to others before getting outdated etc.). It never was meant to be some primary source of income. In that case I would be writing a book about AI :)

Maybe I will write a blog post with some reflections about making the book at some point :)

Noted. For now I put links here, in the comments, and in the Gumroad page to sample pages. I will need to change the homepage later. Thanks for the input!

Honestly I haven't tried yet. Maybe Asciidoctor (Which I used) has it figured out. It would at least need to have good enough output for the code examples, otherwise it would probably be a non-starter.

I added links to example pages (which include TOC) to the Gumroad page and here, but yeah I should have put it on the homepage.

True, the landing page could be more detailed. I didn't want to repeat much the info on Gumroad page, but maybe I should rethink it.

And thanks for the copy suggestions. I am not a native speaker :)

Noted. I will try to provide alternative formats. Not sure how it will go with the code examples, but I shall try.

Edit: One reason why I picked PDF is that I expect the readers to actually follow the examples in their own terminal while going through the book. So in that sense I was thinking about reading it on the desktop.

Example pages here: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...

Thanks for the feedback. I was trying to make it work on mobile but maybe I didn't test it well in the end.

As for a sample, I will go and try to make something now. Thanks.

Edit: Example pages here: https://drive.google.com/file/d/1PkUcLv83Ib6nKYF88n3OBqeeVff...

> Regarding #3, you can already do this with Jinja2 template functions perfectly well. You can also do it with template tags, but it isnt as nice.

This is exactly the problem tho. Every Django solution is "install this thing that replaces or adds a component that should be standard". People adopt frameworks to help them stay on track, not because they want to immediately install 5-10 packages just to correct the framework. Not to mention this just creates a big split when every project will be very different.

> I’ve been beating this drum for a decade now. Django needs “django.contrib.rest”. REST API frameworks have always been too important to leave to third-party maintainers. They need to be maintained in the core.

> I just want something that feels like Django and doesn’t change. Unfortunately I think Django has been debating something as fundamental as content negotiation, the first step towards supporting this is core, for over a decade now.

Absolutely 100 %.

It would be a long list. I will post some examples but you can summarize it as "Django is not ideal choice to build a modern SAAS applications" and "Django developer experience is lacking".

1. REST/HTTP API building needs to be built in for a batteries included framework. In 2025 it is already so so late. REST Framework is "finished" and even if it wasn't the third-party extensions including Ninja feel alien. They need their own routing (why?), their own serialization, have their own extensions or features (rate limiting) that should just be more generic.

2. Python optional typing is always rejected or postponed. Same with any effort to just make starting a project easier because Django doesn't want to ship any dependencies even if it means better outcomes. Recent discussions about shortening django-admin to django can give you enough information about how community decision making is difficult for bringing new (and great) ideas in.

3. Better approach for template components. Django should have good primitives so that people can built UI libraries on top. You can see 10+ third-party packages now but I think it should be included batteries.

4. Authorization. The whole authorization framework assumes that you run a website like the original newspaper. It absolutely cannot work with a multi-tenant SAAS apps that everyone wants to build.

5. Not being able to correct past mistakes or outdated stuff. For example still Django's user model is bad. I really don't understand how something so important cannot be fixed.

I don't know if Plain has a chance to succeed but I understand why it is a fork. Django leadership haven't been able to move Django forward outside of its old paradigms and every attempt, be it a fork or third-party app, counts.

Started using it recently, works great. Very nice way to e.g. define a Python version and have a venv created automatically in a location you want.

In the region where I was growing up next to Poland, we say "chodit do roboty" when describing normal work.

You will most likely need to build something yourself. Django's authorization is limited in this aspect :(

Not sure about all features, but certainly calling and screen-sharing works for me.

> Helix plugin for VSCode

Which one?

You can server-side render the SPA. Not with Django, but with things like Nuxt or Next.

Then the SEO penalty is just the increased page size (maybe some extra loading time). But at least the content can be crawled normally.

It is different. JS is popular because people who write SPAs also want to write backends in the same language.

What I really like about Django and Python ecosystem in general is the kind of stability that it doesn't move too fast and break things, which happens in JS land too often. And Python is a nicer language of the two, for me at least.

But at the end of the day, you can combine both. I work for Baserow now and we combine Nuxt + Django. You can also simplify it to Vue/React + Vite + serve it with Django, use cookies-base auth etc.

You can also use my article to learn a bit about testing with Pytest! https://stribny.name/blog/pytest/

My first choice if the product is a good fit would be old school Django deployed to a single VPS (no docker). I am creating a public starter kit that does exactly that, including the deployment part: https://stribny.github.io/sidewinder/

However, there are lots of use cases that would call for additional SPA (Vue/Nuxt), or other tech. So in that case I'd add it or replace the tech stack entirely. I'd probably avoid specialized cloud services, might consider something like https://supabase.com tho if the app doesn't need a complex backend.

Larger font + sleep + sauna

All of them make a huge difference for me. Sauna is not something that prevents it, but cures it. I can go to sauna after a tiring day and return ready to get going again (regarding eyes).

You will not lose any features by self-hosting. Quite the opposite, some enterprise features like SSO are only possible for self-hosted instances. Source: I work for Baserow.

Every organization is different...

When you lose the one you have.