1·
4 天前I really want to see a Mary Kline still life make an appearance in Backrooms 2.
- 8 Posts
- 639 Comments
Joined 3 年前
Cake day: 2023年8月4日
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
7·4 天前Sigh
Updoot
What th-
Wait. Never mind. I didn’t ask. I didn’t finish the question so you legally cannot answer. Per the… Geneva Convention. Yeah. That sounds right.
There were some lesser ones as well. Jeans was one. And Xavier: Renegade Angel. Probably others that I missed or am forgetting.
I have to ask. What does it mean to have “learned” the languages you listed?
I’ve been a professional software engineer for 20 years. I’ve been writing in the Go programming language for 14 of those years. And not once have I touched a debugger… until a couple of nights ago. I bring that up to make the point that “learning” something like a programming language is an ongoing process. I sometimes forget things and have to relearn them. And I learn new things I never knew before about Go almost every day. I guarantee I have a ton left to learn. I can name several of them off the top of my head. And that’s even without considering all the new things that will be added to Go in the future. Or to mention all the other languages I regularly write in. OpenSCAD, for instance, is a much simpler language than Go because of its narrow, niche focus. I’ve been writing OpenSCAD code for a good… 8 years or so, and I learn new things about it pretty much every time I use it as well.
I don’t view things in terms of having “learned” a programming language. I’ve learned everything I needed to learn to accomplish each of the projects I’ve done. I’ve also learned things here and there just by watching a random YouTube video or reading a blog post. And I’ll continue to do just that.
My recommendation: make something that you want to make. Learn what you need to learn to make it. It’s fair to make it something relatively small; something that’s only a little bit of a stretch. Or something that’s a big stretch is fine as well. Don’t do the project just to learn. Make your project something you genuinely want to see in the world. Learn by doing and do by learning. Think of the two as one and the same activity. Try to figure out the “right” way to do the thing rather than the “easy” way. And find the fun in thinking deeply about a problem and working through building it until you’re happy with the result.
Given how much thought a lot of superfans of the Bible give to him, you’d think he was the protagonist.
Maybe they’re secret shippers.
ITT: Lemmys don’t like being told what to do, apparently.
when I pee
Sounds like you answered your own question.
Claude’s a gatcha.
Will you get the rare following instructions loot or the deletes-your-whole-prod-environment loot that you already have 10 of?
Now draw him putting “rule” in the title. ;)
4·7 天前Huh. Wonder if the recent PHP situation had anything to do with that.
Username checks out.
1·10 天前Is this position against lookup or read-only db tables?
Largely, yes.
The kind of cases where I’ve seen people stick things in the database that I thought would better be elsewhere:
- If it’s small and doesn’t need to change between releases, you can save all the moving-part kind of overhead of pulling that data from the database just by throwing that data in the source code. Often times people do this just so they can have a “foreign key” to something in the data in question. But a nice, semantic “enum” sort of field in the database can refer to something static that’s already in memory no problem.
- If it needs to change at an administrator’s or developer’s (or manager’s) whim, it’s probably configuration, not dynamic data. In the Java ecosystem, Spring Cloud Config makes it easy to change configuration without releasing the code. (I mean, in a perfect world, releasing should be as easy and straightforward as changing configuration, but not everyone lives in a company where all the managers have read The Phoenix Project and caught the DevOps bug.) Putting configuration in the database tends to create a big audit trail gap, unless you spend a bunch of effort building a custom audit trail kind of system.
- If it’s big and not (very?) relational, it may be better suited for files in a directory. This can be true even if it does change based on user input. (Users uploading images, for instance.)
Mind you, certain kinds of behind-the-scenes users can still qualify as “users” for purposes of considering whether “it needs to change based on user input”. For instance, if your marketing department (without software engineering expertise) needs to be able to mess around (without software engineering assistance) with marketing materials displayed on customer-facing websites, you probably need a content-management system of some sort, and I don’t think the database is necessarily a bad place to store a lot of that information. (Things like images probably shouldn’t go in the database, but metadata about those images are probably quite reasonable data for the database.)
Also, I’m rethinking the term “user input”. I could certainly see it being reasonable for automated systems to put data in the database. Like, if you have a scraper doing stuff to be displayed to end users, that doesn’t belong in the source code or configuration, and if it’s very relatioal, it could well belong in the database. Maybe it’d be better to say “if it doesn’t change based on client input, it doesn’t belong in the database.”
If it doesn’t have to change based on user input, it doesn’t belong in the database.
Oh my god. I’m not the only one who thinks this!
Good catch. Thanks.
You won’t believe what he looked like after smoking only one marijuana.
Perineum Sunningwikipedia (SFW, surprisingly.)
What a way to celebrate yor cake day.
I could go on.
(Some of these are jokes, obviously, but your point totally stands. Hell, I’d even watch the joke ones.)