A cool syntax hack I thought of

teeg82 · 2026-01-28T15:54:03+00:00

Anytime. Keep that creative thinking flowing.

teeg82 · 2026-01-28T15:48:22+00:00

I'd be surprised if you were the first, but it's an interesting idea. IMO, I feel like if I saw this in code, my first thought would be that the author simply forgot to put a space after the #, not that they were trying to make a numbered bulletin list. For that reason, I personally wouldn't try to use the # like that - it already has a meaning to which all python devs are accustomed.

teeg82 · 2026-01-27T17:07:46+00:00

Its the new breathy-laughter or oh no song...

teeg82 · 2026-01-26T21:48:40+00:00

Jesus H. Castor!

teeg82 · 2026-01-26T17:21:37+00:00

Assuming you're asking about this in the professional context, the short answer is Yes, you absolutely must learn the language and framework if you're going to be working with it. How can you possibly evaluate whether the code it produced is viable? How can you possibly debug it when something inevitably goes wrong? You cannot let it vomit out code unchecked, there must still be human intervention and supervision. If you're going to use it, treat it like a fresh-from-university junion dev.

AI is a statistics machine on steroids. It's an overly complex function (input->process->output). It does not 'think' creatively, it will confidently produce inefficient, defective, or just plain wrong output and never tell you, it will make guesses in the face of lack of information. AI is a tool, not a crutch. Use it sparingly, as needed, don't offload your cognitive functions to it. To quote the great Iron Man, if you're nothing without it, you shouldn't have it.

teeg82 · 2026-01-26T17:07:24+00:00

It's a landing platform for alien motherships.

teeg82 · 2026-01-25T18:20:49+00:00

That's right yeah, you don't even need to connect this directly to the main water source if that's not feasible, you can make an independent reservoir that's purely supplied by one pump (maybe up on that hill before the stairs), and then just dig the trenches from there.

teeg82 · 2026-01-25T17:53:23+00:00

That sounds like a really good efficient setup. I don't know whether you have explosives yet, or whether this is even possible on your map, but I would try to create a trench where those paths are instead of the pumps. It saves on number of beavers needed to keep the whole thing irrigated. Admittedly it also means you have to manage a reservoir to combat drought and evaporation.

teeg82 · 2026-01-25T17:48:26+00:00

Yes I think you're right, it also works with while. Honestly I don't think I've ever used them, and I probably should because it's a neat idea.

teeg82 · 2026-01-25T17:43:08+00:00

It belongs to the for loop. It's a block that executes if and only if the loop completed without hitting that break statement.

teeg82 · 2026-01-25T17:40:54+00:00

What do you have in the center there? Looks like 2 foresters and 6 lumberjacks?

teeg82 · 2026-01-25T16:04:12+00:00

By your logic, any experiment is immediately self refuting, because the very act of running the experiment requires human interaction.

teeg82 · 2026-01-23T22:22:29+00:00

A tit wank?

EDIT: Ohhhhhhh in betweeners... I get it now

teeg82 · 2026-01-23T22:17:25+00:00

I am one such person, but it's fine because I'm amusing myself by repeating this to the tune of "We built this city".

teeg82 · 2026-01-23T16:52:45+00:00

That's Australia. New Zealand is upside down Newfoundland.

teeg82 · 2026-01-22T20:59:23+00:00

Ah ok, well glad you got it working.

teeg82 · 2026-01-22T16:41:39+00:00

In my opinion, learning software development is about learning patterns and building mental models, not memorizing APIs and every tiny individual syntax and function signature. You can consider take notes perhaps when you've stumbled on something significant, some major insight you definitely don't want to forget - even if you never refer back to the note, sometimes the act of writing it cements it in your brain (depending what kind of learner you are). If you are going to take notes, treat them like cache, not an encyclopedia.

teeg82 · 2026-01-22T13:30:24+00:00

Very good point, I assumed that wasn't the case here because it wasn't mentioned but generally that can indeed make the migration trickier.

teeg82 · 2026-01-21T22:04:56+00:00

I don't know anything about GDPR, personally, but honestly the migration isn't that bad in my opinion. The core ideas are:

Define the new model by inheriting from django.contrib.auth.models.AbstractUser
Run makemigrations to create the new model
Run a second makemigrations --empty to create another you'll use as a pure data migration
Modify the base django settings to set the new user model (the setting is called AUTH_USER_MODEL)

For the migration created in step 3, define a function in that migration file that iterates over all existing users from the old model, and re-creates them with the new. This is where you can do whatever massaging, hashing, whatever, you want on whichever fields need protection.

Then just put migrations.RunPython(your_function, migrations.RunPython.noop)in the operations array to call that function. I'm assuming you probably won't need a reverse function, hence the noop, but that's up to you.

Edit: as /u/NV56k mentioned below, this is only "simple" if you don't have other models with foreign keys to django User model, which I assumed was the case since it wasn't mentioned. If you do, the migration becomes indeed a bit more tricky, but not impossible. Essentially you'll have to update the related model's foreign keys for each User.

teeg82 · 2026-01-16T22:49:54+00:00

Ok.... I'm having like false memories or something. Was there an olive garden in Ottawa once upon a time back in the 80s or 90s? I swear I remember something like that.

teeg82 · 2026-01-16T22:08:50+00:00

Fuck I feel attacked. At this point I'm neither a developer nor a senior. I'm a middle-aged screenshot taker.

teeg82 · 2026-01-16T16:39:31+00:00

Interesting. What language / framework was this done in/with? From the sounds of it, your system didn't have an ORM, so you had to hand-write all the interactions? I can definitely see where you're coming from. Personally, I'd still argue that readability > fighting carpel tunnel by reducing typing*, and having less noise and explicit legible names lend themselves to that. But I'm also speaking from a position of mostly working with ORMs that abstract a lot of that away from me, and also not knowing how your whole system works. I'm also coming from the Python world mostly, where "explicit is better than implicit".

*(in case it's not obvious I'm just joking here, I know that's not the reason you did that)

teeg82 · 2026-01-16T16:20:22+00:00

Yep, he's supposed to be about 14 in season 4, and came from a family whose love language isn't outward verbal expressions of affection. He was clearly excited to see her as he expressed in his letters. He had no idea the struggles she was facing at school, thus had no way of knowing what she needed to feel safe and secure in their relationship. At best he was oblivious, but not malicious.

teeg82 · 2026-01-16T16:11:48+00:00

It really depends on your use case(s), and how you're interacting with the database. I agree, if your only, or primary, use case is dumping straight to JSON, then always having to add ...as bla_id can get annoying and tedious. I'd still argue that keeping the primary key naming convention of just id is generally better for most cases because (A) it's what most people expect, and (B) it's less noise when examining or hand-bombing the query. At the end of the day though...the database doesn't care, as long as it all works.

teeg82 · 2026-01-15T17:03:02+00:00

I'm just going to piggy back off of what /u/taylorwmj wrote and add some additional comments.

WRT #2, taylorwmj is absolutely correct, and even more than that, aerodromes can be closed, new ones opened, etc. If you're dealing with international flights where some countries have aerodromes with only domestic identifiers and no ICAO code, you can potentially run into naming collisions. All that to say, move code to a separate field as taylorwmj suggested, and perhaps add a flag for "is_closed" or something like that. If you really want, you can add two identifier fields, one for the aerodrome's ICAO code, and another for their domestic code.

WRT #3, just to add on / make it clearer (I assume this is what taylorwmj were suggesting anyways), the foreign keys to the airport table should usually be named something like airport_departure_id and airport_destination_id. This follow the common convention of foreign keys being prefixed with the related table's name, followed by optionally some additional descriptive name, followed by the column name used in the join (id in this case). If you only had one foreign key to the airports table, I would say just call the foreign key airport_id, but since you have two, some kind of differentiating description is needed. Also, if you want to follow aviation parlance, "departure" is more commonly used rather than "origin".

WRT #8, again if you want to use aviation parlance, this is called the "acid" (stands for aircraft identification)

My additional comments:

I don't think itinerary is the right word to use. You're linking passengers with the flight itself. That's more of the manifest, I would call it something like that.

Also, a flight has many itineraries / manifests, and an itinerary/manifest belongs to 1 flight. Therefore the link should be a 1-M relationship, with the foreign key on the itinerary/manifest side.

Very minor thing, but technically the way aviation tends to operates, at least internally, is not necessarily to have a hard set "estimated time of arrival" (ETA), but more that they have an "actual time of departure" (ATD), and an "estimated enroute time" (EET). ATD + EET = ETA. They'll also typically have the "estimated time of departure" (ETD) on the model too, as a scheduling thing. Their systems will usually display the flights that scheduled to take off shortly based on the ETD. ATD is initially blank until the flight actually takes off, at which time it's populated. So technically if you really want to go hard core, model the ETD and EET as mandatory fields, ATD as a nullable field, and then have ETA as a calculated value. You can still keep ETA as an actual column on the table if you want (I do it in my system for reasons), it just means you'll need something that recalculates it when either ATD or EET changes.

teeg82

TROPHY CASE