Can anyone recommend a ~15" monitor that works with a macbook using just a USB-C cable? I don't need particularly high resolution.
I looked a couple years ago, but it seemed like most would require a caldigit hub or something like that.
That is a great feature! I'm considering this for work at conferences and other trips. I tried using an iPad air, but that's not enough extra screen space to make it worth using.
Can you just plug this into a macbook and it gives you an extended desktop? I looked at this about two years ago, and could not figure out which ones would work without something like a caldigit hub.
Are you interested in contributing to Django? Consider applying to join @djangonaut.space for their upcoming session. Applications close on February 2nd.
✍🏾 Apply here: djangonaut.space/sessions/20...
📚 Read more here: djangonaut.space/comms/2026/...
That doesn't sound quite so bad either!
New episode with @wang.social , @calvinhp.com, and host @mkennedy.codes
#524: 38 things Python developers should learn in 2025
talkpython.fm/episodes/sho...
There's always something new to learn about managing time in software. I've been working a lot with timestamps recently, and wrote up some surprising-to-me things from that work.
#Python
www.mostlypython.com/time-deltas-...
$ python manage.py deploy --vm-size shared-cpu-2x --automate-all
The 1.2.1 release of django-simple-deploy allows plugins to extend the core CLI.
For example, the dsd-flyio plugin now supports a `--vm-size` option.
This is what was needed to make plugins much more powerful than simply "give me the smallest possible working deployment".
#Python #Django
I've definitely been stuck at the `uv venv .venv` and `uv pip install <package>` level of adoption. This is a great writeup of how to really simplify your workflow with uv.
I like that approach because you can add a `--url` flag to your test suite, and run those same tests against a deployed version of the project.
For projects that aren't going to see a lot of active development, I've definitely taken the shortcut of just spinning up a development server and running a basic set of tests on the final rendered pages.
I'm going to clarify the cost of a basic Fly.io deployment, but I have to wait until next week to do that.
I've been on the legacy free tier for years now, and I finally "downgraded" my account to the pay as you go plan. Kudos to Fly for honoring their free tier for years after it was deprecated!
I'm jumping back into django-simple-deploy work this week. The focus will be on the dsd-vps plugin, but first up is a refresh of the page that compares a core set of PAAS hosts:
#Python #Django
django-simple-deploy.readthedocs.io/en/latest/ge...
$ git clone https://github.com/ehmatthes/wagtail_demo.git $ cd wagtail_demo $ uv venv .venv && act $ uv pip install -r requirements.txt $ pip install -e ~/projects/django-simple-deploy $ uv pip install -e ~/projects/dsd-platformsh $ python manage.py deploy --automate-all $ platform ssh > python manage.py createsuperuser
Wagtail admin page with logged in user
Fun news! I just deployed a demo Wagtail site to Platform.sh using django-simple-deploy. Here's the steps, and a screenshot of a logged-in admin user.
#Django
9. Trust Is the New Currency Amidst an ever-growing wave of AI slop on the internet, actual humans and trust have never been more valuable. When you can’t trust search engines, especially not videos, and certainly not AI/LLMs, finding a human with real expertise who is willing to share it has never been more valuable. I suspect we will find a few people in different domains who become the “thought leaders” as most content turns into garbage. This is good for them and good for quality content, but bad for the larger ecosystem of people sharing their expertise. If someone already has 1m followers on YouTube for a topic, it will be much easier for them to scale to 2m than for a newcomer to somehow stand out and gain enough traction to generate enough views to make the economics work. This is not really a new challenge, but tech constantly amplifies already-existing dynamics into another stratosphere.
My favorite section focuses on trust. I fully agree with this take, and this mindset is changing how I build software.
People hyping AI for profit are spilling a bunch of s**t that the rest of us have to deal with. I'm enjoying building things that center trust, explicitly against all this AI slop.
@wsvincent.bsky.social shared a really grounded take on the state of AI this week. If you're trying to make sense of where we're at and where we're headed, I highly recommend reading his take. It's a quick read.
wsvincent.com/ai-for-the-r...
Is the volume of emails changing with the availability of ChatGPT? I'm wondering if it's absorbing some of that communication, or just encouraging people to keep going with their "theories".
OpenAI has absolutely fostered this kind of environment.
There's a whole lot of people taking all their hype at face value, who don't have the background to critically evaluate their claims.
This makes me *way* more likely to be on the latest point release, for every version, as soon as any new point release comes out.
Big takeaways: I have a bunch of interpreters (python3.14, python3.13, python3.12...python3.9) available as fast as I can type any of those aliases.
And I can update *all* of them with one command:
$ uv python upgrade
Like many others, I've been loving uv and it's changed my workflows for the better.
I cleaned up my system recently, removing pyenv in favor of an all-uv approach. I wrote up the process here:
#Python #uv
www.mostlypython.com/updating-pyt...
Recent releases also include a number of bug fixes. Docs are here:
py-bugger.readthedocs.io/en/latest/
$ py-bugger --target-file dog.py --target-lines 15-20
$ py-bugger --target-file .venv/lib/python3.12/site-packages/PIL/Image.py --target-lines 3068-3117
py-bugger is up to 0.5.2 now.
Latest feature: you can introduce a bug into a specific block of lines, or even a single line in the target file.
It works for small teaching files, and you can target large files in library code as well.
#Python
This will be even more true as the project continues to evolve, and becomes capable of introducing a wider range of bugs.
The `--exception-type` argument is really helpful for teaching and learning. But in the real world, we don't know what kinds of bugs are going to appear.
Letting py-bugger randomly choose the bug that gets introduced makes your debugging practice closer to real-world debugging experiences.
$ py-bugger Added bug. All requested bugs inserted.
$ py-bugger -e IndentationErrorr You specified IndentationErrorr for --exception-type. Did you mean IndentationError?
In the 0.4.1 release of py-bugger, the `-e` argument is optional. If you leave it off, it will randomly select what kind of bug to introduce in the target project.
It also suggests valid arguments for `-e` if you make a typo.
#Python
I think if you're writing a technical book/post/documentation, you have to stick to this principle:
If the code isn't directly loaded from a tested source file, or copy-pasted from one, it doesn't go in the document.
"I just need to make a little edit to the code in the post, it'll be fine"
No
The next bit of work is to make the `--exception-type` argument optional. A bare call will randomly choose the kind of error to insert. That will open up implementation of a much wider range of bugs that can be introduced.
py-bugger 0.4.0 is out! A few bugs have been addressed, and it now looks for a clean Git status before introducing bugs in a project or file. You can override that behavior with the `--ignore-git-status` flag.
py-bugger.readthedocs.io/en/latest/
#Python
I would love to hear more about the serious side of this. It feels like a y2k-fixing gig that never ends.
