I was impressed by an earlier mod along similar lines, Portal Stories: Mel. Hope this one is as well-done.
I don’t think Netflix actually cancels shows after two seasons any more often than other networks do.
Somehow people got it into their heads that Netflix is far more cancel-happy than its competitors, but if you look at the numbers, traditional TV networks have had like a 50% cancellation rate for decades.
Even TOS was cancelled after two seasons!
If Netflix is more prone to cancelling shows at all, which I’m not convinced is even true, it can’t be by an enormous margin.
The paper (linked from the article) has a photo of the actual tablet in question, which was apparently discovered circa 1900.
SQL, where injection is still in the top 10 security risks
This is absolutely true, but it's not what it looks like on the surface, and if you dig into the OWASP entry for this, you'll see they talk about mitigation.
You can completely eliminate the possibility of injection attacks using well-understood technologies such as bind variables, which an ORM will usually use under the covers but which you can also use with your own queries. There are many, many database applications that have never once had a SQL injection vulnerability and never will.
The reason SQL injection is a widespread security risk, to be blunt, is that there are astonishingly large numbers of inexperienced and/or low-skill developers out there who haven't learned how to use the tools at their disposal. The techniques for avoiding injection vulnerability are simple and have been well-documented for literally decades but they can't help if a lousy dev decides to ignore them.
Now, a case could be made that it'd be better if instead, we were using a query language (maybe even a variant of SQL) that made injection attacks impossible. I agree in principle, but (a) I think this ends up being a lot harder than it looks if you want to maintain the same expressive power and flexibility SQL has, (b) given that SQL exists, "get bad devs to stop using SQL" doesn't seem any more likely to succeed than "get bad devs to use bind variables," and (c) I have too much faith in the ability of devs to introduce security vulnerabilities against all odds.
it would be great to “just” have a DB with a binary protocol that makes it unnecessary to write an ORM.
Other people have talked about other parts of the post so I want to focus on this one.
The problem an ORM solves is not a problem of SQL being textual. Just switching to a binary representation will have little or no impact on the need for an ORM. The ORM is solving the problem that's in its name: bridging the conceptual gap between an object-oriented data model and a relational data model. "A relational data model" isn't about how queries are represented in a wire protocol; instead, it is about how data, and relationships between pieces of data, are organized.
So, okay, what if you get rid of the relational data model and make your database store objects directly? You can! NoSQL databases had a surge in popularity not too long ago, and before that, there have been lots of object databases.
What you're likely to discover in an application of any real complexity, though, and the reason the industry has cooled somewhat on NoSQL databases after the initial hype cycle, is that the relational model turns out to be popular for a reason: it is extremely useful, and some of its useful properties are awkward to express in terms of operations on objects. True, you can ditch the ORM, but often you end up introducing complex queries to do things that are simple in SQL and the net result is more complex and harder to maintain than when you started. (Note "often" here; sometimes non-relational databases are the best tool for the job.)
And even in an object database, you still have to know what you're doing! Storing objects instead of relational tuples won't magically cause all your previously-slow queries to become lightning-fast. You will still need to think about data access patterns and indexes and caching and the rest. If the problem you're trying to solve is "my queries are inefficient," fixing the queries is a much better first step than ditching the entire database and starting over.
You're not missing much power with jOOQ, in my opinion as someone who has used it for years. Its built-in coverage of the SQL syntax of all the major database engines is quite good, and it has easy type-safe escape hatches if you need to express something it doesn't support natively.
Totally fair! They did a good job of making the main storyline playable as a solo player, but the core gameplay loop is still unmistakably MMO-style and not to everyone's taste.
I love that song in particular because (very minor spoiler) it works both as background music and as diegetic music. In the story, that boss is trying to entice you into going permanently to sleep and living in a dream world where you'll achieve all your goals and desires, while becoming her meat puppet in the real world. When you're playing the game rather than watching it with onscreen lyrics on YouTube, you are only sort of half-listening to the song while you focus on the battle, so you don't realize right away that the battle music is the boss singing to you to seduce you into her flock even while you're fighting her.
Final Fantasy XIV has a diverse soundtrack and a terrific story, but it is a huge time commitment. The story starts off pretty slow and takes a long time to build up.
A few boss fight themes as examples:
Watched season 1 back when it was first airing, but never got around to season 2. People seem to hate it but I can't quite tell if that's because it wasn't up to the standard of season 1 or if it was just bad TV.
Should I skip it and go straight to season 3? Or is it worth watching on its own merits?
As a fan of Ms. Marvel, I enjoyed the main campaign well enough, but all the MMO stuff is obnoxious. Luckily you can mostly ignore it and go through the campaign missions single-player. I uninstalled it after getting to the end of the story.
This is spot on. I would add one little wrinkle: you not only have to accept that not everything works like it does in your home country, but also that not everything should.
You can be the kind of expat who spends all day griping about how much worse things are in your new home than your old one, or you can be the kind who shifts their mindset such that the new country’s ways become second nature.
jOOQ is really the best of both worlds. Just enough of an ORM to make trivial CRUD operations trivial, but for anything beyond that, the full expressive power of SQL with added compile-time type safety.
And it's maintained by a super helpful project lead, too.
I think the value of standups depends a ton on the team's composition and maturity.
On a team with a lot of junior or low-performing devs who don't have the experience or the ability to keep themselves on track, or a team with a culture that discourages asking for help as needed, a daily standup can keep people from going down useless rabbit holes or unwittingly blocking one another or slacking off every day without anyone noticing.
On a team of mostly mid-level and senior devs who are experienced enough to work autonomously and who have a culture of communicating in real time as problems and updates come up, a daily standup is pure ceremony with no informational value. It breaks flow and reduces people's schedule flexibility for no benefit.
When I'm thinking about whether it makes sense to advocate for or against daily standups on a team, one angle I look at is aggregate time. On a team of, say, 6 people, a 15-minute daily standup eats 7.5 hours of engineering time a week just on the meetings themselves. The interruption and loss of focus is harder to quantify, but in some cases I don't even need to try to quantify it: when I ask myself, "Is the daily standup consistently saving us a full person-day of engineering time every week?" the answer is often such a clear "yes" or "no" that accounting for the cost of interruptions wouldn't change it.
Especially infuriating when the other person is in a very different time zone. I once worked on a project with a partner company in a time zone 10 hours ahead of mine and it was common for trivial things to take days purely because the other person insisted on typing "Hi," waiting for my "Hi, what's up?" response (which they didn't see until the next day since our hours didn't overlap), and then replying with their question, which I didn't see until my next day. Answering the actual question often took like 30 seconds, but in the meantime two or three days had gone by.
I came to believe they were doing it on purpose so they could constantly slack off and tell their boss they were blocked waiting for my answer.
My frustration is less with the people who are late and more with the meeting host making the rest of the attendees sit around twiddling their thumbs waiting for the late person. Unless the late person's presence is the point of the meeting, just get started and let them catch up.
"We'll wait a few more minutes for person X to join, then get the meeting started," like the other ten people who made the effort to show up on time deserve to be punished with extra meeting time for being responsible. Bonus points if this causes the meeting to run a few minutes long.
What do you mean by “privacy” in this context? Privacy from people looking in the window? From the car company?
Using it to describe streaming services isn't new. For example, here's a Variety article from 2019 that uses it that way.
"Streamer" has been a widely-used entertainment-industry term for streaming companies for years. It's not a new thing people are making up to be cute.
Not the person you're replying to, but I'm also a "try the local cuisine" person. A good percentage of the places I've visited have had some local thing that you'd have to really look for to find elsewhere. I don't end up liking all of them, but I like the experience of trying something new. Some specific examples:
- St. Louis, MO, USA: Gooey butter cake which is as gross and as delicious as it sounds.
- Changsha, Hunan, China: Stinky tofu. The local Changsha style of stinky tofu is completely unlike the more common style you'd find in night markets in Taiwan or elsewhere; it's only a little stinky but is dense, savory, and spicy.
- Singapore: Kaya toast. Kaya is a sweet coconut-based spread and they put it on buttery thick toast. I was addicted to this when I was in Singapore for work.
- Scotland: Haggis. It was... okay? Didn't love it, didn't hate it, don't see why it has the reputation it has.
- Jingdezhen, Jiangxi, China: Jiaoziba, which is a little local style of dumpling that's rich and quite spicy.
- Hiroshima, Japan: Okonomiyaki, a kind of savory pancake. Okonomiyaki is common in Japan but it's usually Osaka-style. The version they make in Hiroshima includes noodles in the dough.
In my experience, if you talk to a few locals, one of them will usually think of a local specialty and tell you where to try it.
I think this is a more subtle question than it appears on the surface, especially if you don't think of it as a one-off.
Whether or not Scientology deserves to be called a "religion," it's a safe bet there will be new religions with varying levels of legitimacy popping up in the future. And chances are some of them will have core beliefs that are related to the technology of the day, because it would be weird if that weren't the case. "Swords" and "plowshares" are technological artifacts, after all.
Leaving aside the specific case of Scientology, the question becomes, how do laws that apply to classes of technology interact with laws that treat religious practices as highly protected activities? We've seen this kind of question come up in the context of otherwise illegal drugs that are used in traditional rituals. But religious-tech questions seem like they could have a bunch of unique wrinkles.
Domain-driven design includes the idea of a "ubiquitous language" where the engineers and the domain experts and the product owners come together and agree on terminology for all the domain concepts, and the project then uses that terminology everywhere.
But on the projects I've been involved with, much more common is a situation where the requirements docs mostly use one term but sometimes use a different name for the same thing because the docs were worked on by two people who disagreed on the terms, the designers decide they don't like how the words look so the UI calls the concept something else, the database developer reverses the term's word order to fit their personally-preferred schema naming conventions, the API designer invents a compound name that includes both the UI and the database names, and so on. (I only barely exaggerate.) Which names map to which other names becomes tribal knowledge that's usually not written down anywhere.
This kind of thing bugs me a lot, but I seem to be in the minority. I recognize that it makes very little functional difference, but it just feels sloppy to me and I don't like having to remember multiple names for things. I will usually advocate for renaming things in the code for consistency, and other people on the team will almost always agree that it's a good idea and will happily accept my PRs, but I'm usually the only one taking the initiative.
So, my question to you fine folks: am I wrong to care much about this? Do you think using consistent names for domain concepts across the board actually makes a meaningful difference in terms of code maintainability and discoverability? Or is the effort required to keep the names consistent over time actually greater than the mental overhead of working with the inconsistent names?
I ignored this show when it first came out because the initial trailer didn't do much for me, but I ended up enjoying the first season, and so far I'm enjoying season two even more.
It's kind of a variety-show take on "Rashomon" in the form of a comedy murder-mystery. The gimmick is that in each episode, you get one character's version of the story as a mini-movie in a film style that suits that character. So you'll see the same events unfold as a romantic comedy, an action thriller, a horror movie, a musical, and so on. Some of the mini-movies fall flat, but the ones that work are lots of fun.
The mystery itself was pleasantly constructed in season one, with clues hidden in plain sight from pretty early on if you knew what to look for. Season two isn't finished yet, but it seems like it'll do the same; in the first episode there's a little comedy bit about picking people up from a hotel that's just a quick gag on one level, but is also clearly the writers saying, "Pay attention, because minor inconsistencies are going to matter."
Anyone else watching this show?
I just filled out a passport renewal form and listed "brown" as my hair color. But if I'm honest, I'm at an age where there's more gray hair than brown hair.
There's still enough brown that it's obviously my original color, so I don't think I lied on the form, but it got me wondering: what's the cutoff?
Curious to know how many people do zero-downtime deployment of backend code and how many people regularly take their service down, even if very briefly, to roll out new code.
Zero-downtime deployment is valuable in some applications and a complete waste of effort in others, of course, but that doesn't mean people do it when they should and skip it when it's not useful.
In a recent Spring Boot project I decided to try a new pattern in my integration tests and it worked out pretty well. Curious if others have had success with this too; I haven't seen it written about anywhere.
The basic idea: Use by lazy to create graphs of canned test fixtures, and use those lazy values as defaults in the fixture setup code.
To make up a simple example, say you have "books" and "authors" tables in a database, where every book has to have an author. You might have a couple functions in your test code to populate those tables and return the IDs of the newly-inserted rows so you can use them in tests:
``` fun insertAuthor(name: String): Long { ... } fun insertBook(title: String, authorID: Long): Long { ... }
fun testCheckOut() { val authorID = insertAuthor("John Steinbeck") val bookID = insertBook("Cannery Row", authorID)
library.checkOut(bookID) // ...then assert the book is checked out } ```
The "by lazy" pattern reduces boilerplate in cases where you just need a book and an author but it's fine for them to be canned values.
``` val cannedAuthorID: Long by lazy { insertAuthor("John Steinbeck") } val cannedBookID: Long by lazy { insertBook("Cannery Row") }
// This is the same as before fun insertAuthor(name: String): Long { ... }
// But this has a default if your test doesn't care who the author is fun insertBook(title: String, authorID: Long = cannedAuthorID): Long { ... }
// Referencing cannedBookID will insert both the book and the author fun testCheckOut() { library.checkOut(cannedBookID) // ...then assert the book is checked out }
// The canned IDs are inserted exactly once fun testCheckOutTwoBooks() { library.checkOut(cannedBookID)
// This will use the already-inserted author ID val secondBookID = insertBook("Of Mice and Men")
assertThrows<TooManyBooksException> { library.checkOut(secondBookID) } } ```
The benefit isn't too big with this simple example, but my real project has a more complex data model with multiple layers of dependencies, and it ended up making my tests considerably less cluttered with incidental boilerplate.
Of course, the other approach to this class of problem is to spin up a fully-populated set of test fixtures that gets shared by all the tests. For example, a test database that gets reset with a known set of example data for each test run. That can work well too, and it's a technique I sometimes use, but I prefer to have tests construct the environments they need.
Anyone else used this kind of setup? Are there any additional tricks I'm missing?