Major scandal in Australia was PwC secretly passing government secrets (tax changes consulting work) to private corporations [1]. And another one was KPMG passing secret client information to win contracts [2]

[1] - https://en.wikipedia.org/wiki/PwC_tax_scandal [2] - https://www.theguardian.com/australia-news/2026/jun/10/kpmg-...

There are a lot of things to like about Django. Remember being blown away when I discovered Django Content Types[1]. Basically generic foreign keys to any model type.

[1]: https://docs.djangoproject.com/en/6.0/ref/contrib/contenttyp...

As someone who's used Django since 0.97 and loves it, Content Types are one of those features that I recommend avoiding. It looks amazing at first but you will eventually regret it.

Writing programs in C has simplified developer experience over Assembly. Issue with JS frameworks is that many find them complex, i.e. complexity has not been abstracted away (which should be goal of abstractions). Maybe DOM manipulation has, but many new complex ideas had to be introduced to achieve it.

But isn't that the right thing to do? Recognize the problems and introduce concepts to tackle them. C introduced pointers as a concept, one more thing to learn and reason about but frees you from using addresses directly. Relational models was discovered as a formal way of understanding and reasoning about data structures. Frontend components introduce a composable architecture with lifecycle hooks, reactivity etc. Those concepts were already there (e.g. with ad-hoc html templates, event listeners, clean up code) but now they are actually formalized and made explicit and developers actively think about them when doing frontend. So the abstraction is there, but I feel for some reason non-UI people assume UI is easy to code, but they never thought about the actual concepts involved. Even without frameworks, you need to consider composability, modularity, events, life cycle, state management, async behavior, etc. I'd rather have those built in and considered as part of the programming model, than to avoid it.

I wonder if this could go down similar way some SaaS systems went to lower barrier to customisation so less technical users could do it. For example, having to interface with some ServiceNow instances I often find major flaws with db schema design - similar data in multiple places, lack of constraints, etc. Basically one big mess you are now stuck with that could have been avoided if a db expert was in charge of data model design.

Or

  API_KEY = os.environ.get("YOUTUBE_API_KEY")
  CHANNEL_ID = os.environ.get("YOUTUBE_CHANNEL_ID")

  assert(API_KEY, "Missing YOUTUBE_API_KEY")
  assert(CHANNEL_ID, "Missing CHANNEL_ID")

Do you use parens with assert? In Python, the assert statement is not a function, right?

That bit me before... it created a tuple which evaluated as true.

Assertions are disabled via `python -O` so they probably shouldn't be used like this.

On the other hand, presumably the program will just crash anyway with some terse permission/request error later on if these values aren't set

Doesn't matter. Assertions should be used for things that are always true (barring bugs in the program). That isn't the case here.

Would love to explore this in Python. But would it be correct to assume single process service would not be as performant due to GIL?

The GIL means you only get to use a single core for your code that's written in Python, but that limit doesn't hold for parts that use C extensions which release the GIL - and there are a lot of those.

The GIL is also on the way out: Python 3.13 already shipped the first builds of "free threading" Python and 3.14 and onwards will continue to make progress on that front: https://docs.python.org/3/howto/free-threading-python.html

And honestly, a Python web app running on a single core is still likely good for hundreds or even thousands of requests a second. The vast majority of web apps get a fraction of that.

I’ve been running essential production systems with pythons uvicorn and 1 worker reliably, mainly because I get to use global state and the performance is more than fine. It’s much better than having to store global state somewhere else. Just make sure you measure the usage and chose a different design when you notice when this becomes a problem.

I have inherited a suite of apps that do this. I have mixed feelings about this: on the one hand, many of them work just fine and will never need a second worker, and they were relatively easy for inexperienced devs to put together.

On the other hand, some of them do have performance problems and are a nightmare to migrate to a different solution, it's hard to reason about what parts of the application turn out to be stateful.

After some experience, starting to use a new programming language is not such a big challenge. Mastering the new language eco system is. AI might help you generate new code faster, but feel like crunching code has not been so much of an issue. Bigger picture system design, something that scales and is maintainable is the challenge.

Advertising is out of control. Doing mundane things like filling up fuel at a petrol stations, or catching a lift at work - there is a little screen targeting you with ads.

Got introduced to Rufus Sewell in 'The Man in The High Castle'. He played an SS commander. Most intimidating and frightening presence on the screen - without raising his voice and no (direct) acts of violence. Great actor.

He is indeed an extremly good actor .. wasted in some earlier US productions that bought him in for the Shakespearean Gravitas (pissed away by poor scripts in Eleventh Hour) .. but a shining light in various UK productions such as Petruchio in ShakespeaRe-Told.

https://thetvdb.com/series/eleventh-hour-us

https://thetvdb.com/series/shakespeare-told/episodes/375791

I knew of his villainous presence as being the baddie in Knight's Tale. He exuded privilege and eliticism so perfectly. Fantastic actor!

Isn't that Svelte?

As a recent convert, svelte has felt wonderful.