I’ve lived in Oregon most my life. Not unlike Washington (or many other states), when you get out of the metro areas the voting turns from “blue” to “red” pretty quickly. East of Bend has significantly more in common with Idaho than the valley (Portland, Salem, Eugene) or the coast- in fact there is a section of eastern Oregon even in the Mountain time zone. Once you get 200+ miles east of Portland, you’re closer (and more likely) to go to Boise than you’ll ever come to Portland.
For reference, Baker City, a larger eastern Oregon population center, is approximately 300 miles from Portland and about 140 from Boise. Pendleton may be about equidistant. I’ve got acquaintances and friends that have only been to the western side of the state a few times in their life and they’re more likely to spend their time in Idaho or Nevada than come west.
The way of life out there is completely foreign to most on the western side of the state, and the eastern side thinks the west is full of “crazy liberals”. It’s been that way my whole life, but the last few years have made it seem completely broken.
I spend a lot of time out east, whether it is Idaho or Oregon, I’ll still spend my time out there- but I’d love to find a way to prevent the divorce (that they’ve been talking about since before I was born).
I disagree on most of your points but I am trying to read your entire comment favorably, but my personal experiences do not line up with almost any of this.
>>> JPA/Hibernate is still the best way to actually produce working applications if you have to use an SQL database for some reason...
This statement makes me think that you either do not prefer to use SQL RDBMS, don’t have to use them very often, believe they are some dusty piece of tech, or all of the above when my experience has me believing that RDBMS are absolutely the most common persistence layer I encounter in JVM, .NET, PHP, and Python codebases.
I don’t think I’ve ever heard a senior JVM based engineer proclaim that JPA/Hibernate are “the best way... to produce working applications”. It simply isn’t. For basic CRUD applications you will AT BEST barely write fewer lines of code with JPA than with native JDBC queries and ResultSet mapping and have all the lock-in and performance drawbacks of JPA.
Lazy loading will inevitably wind up with Session scope problems with any kind of concurrency, forcing nasty internal list enumeration to force a faux eager fetch to work around the problems.
Fetching just the columns you need for a particular projection will have you writing either SQL or Hibernate “SQL” in annotations.
If you have a mix of JDBC and JPA in a codebase you will inevitably wind up with enough consistency and visibility issues as to either ditch one of them or ditch the entire codebase.
Vanilla SQL is so pervasive and CRUD operations are so simple that I would have serious doubts about the credibility of a JPA proselytizer that didn’t know SQL.
I expect every single one of my backend engineers (on any tech stack) to understand the fundamentals of SQL INSERT, UPDATE, and DELETE statements.
> I expect every single one of my backend engineers (on any tech stack) to understand the fundamentals of SQL INSERT, UPDATE, and DELETE statements.
Understanding INSERT, UPDATE, and DELETE doesn't help you very much when you have to persist changes to a single child entity of many in an aggregate (parent entity). How do you track which child has changed? Or if a new child is added? Or one is deleted? Or what if the relation is a child of a child of the aggregate, which might very well be the best way to model your domain.
In these situations, Hibernate/JPA will help you a lot! If you're doing it using plain SQL/JDBC, you'll probably end up writing your own mini ORM, and/or polluting your domain with database concerns. (I do keep my Hibernate entities separated from my domain.)
> I expect every single one of my backend engineers (on any tech stack) to understand the fundamentals of SQL INSERT, UPDATE, and DELETE statements.
And everyone knows them. It is just absurd to talk about Hibernate as a way to avoid learning to write insert, update and delete. That is made up issue. That is like claiming that people who dont write getters and setters dislike them because they did not learned how to write them.
I dont know whether this claim is a manipulative attempt to try to insult people who like framework you dont or what. But it is ridiculous.
> This statement makes me think that you either do not prefer to use SQL RDBMS, don’t have to use them very often, believe they are some dusty piece of tech, or all of the above when my experience has me believing that RDBMS are absolutely the most common persistence layer I encounter in JVM, .NET, PHP, and Python codebases.
Popular doesn't mean good. I have to use SQL RDBMS a lot, and I respect the amount of low-level engineering work that has gone into them, but yeah I do hate using them.
> I don’t think I’ve ever heard a senior JVM based engineer proclaim that JPA/Hibernate are “the best way... to produce working applications”. It simply isn’t. For basic CRUD applications you will AT BEST barely write fewer lines of code with JPA than with native JDBC queries and ResultSet mapping and have all the lock-in and performance drawbacks of JPA.
I don't think seniority is a good metric, but I've got 10+ years of professional JVM experience for what that's worth. Using JPA means you'll write significantly less code, and the code you get to skip is the most tedious (and therefore rarely read or reviewed) part. Lockin is significantly lower: you can seamlessly migrate between databases in a way that you can't with handwritten SQL, and you can migrate between different JPA implementations with minimal work (not that I think there's actually much value in doing that, but the capability is there). Performance for equivalent effort will be significantly better because you've got a caching layer that actually works already in place (unless you turn it off, but, uh, don't do that).
Of course if your CRUD application is performance-critical enough to justify hand-tuning every query and implementing a correct caching layer by hand then you'll do better without the framework. But realistically that's a vanishingly rare case.
> Lazy loading will inevitably wind up with Session scope problems with any kind of concurrency, forcing nasty internal list enumeration to force a faux eager fetch to work around the problems.
Depends on your application - a lot (not all, but a lot) of systems decompose naturally into a sequence of isolated steps that provide a natural session boundary. E.g. for a REST API or MVC-style webapp just put the session in the view and get on with your life - people have some philosophical objection to this but it works really well. (I actually don't think MVC is a great way to structure a webapp, but that's a separate fight).
> Fetching just the columns you need for a particular projection will have you writing either SQL or Hibernate “SQL” in annotations.
True. But, on the assumption that you've actually structured your entities to follow your domain, how often is that something you actually gain a significant amount of performance (or anything) from?
> If you have a mix of JDBC and JPA in a codebase you will inevitably wind up with enough consistency and visibility issues as to either ditch one of them or ditch the entire codebase.
This I completely agree with (at least for people who don't make any actual effort to address the problem), and I think it's where articles like the OP come from. I see a lot of people follow a pattern something like: their application needs some vaguely tricky query, and rather than spending 5 minutes looking up how to do it in the Hibernate documentation they decide to handwrite the SQL for it instead. Then they realise that this makes the Hibernate cache for the affected entity invalid, and rather than look up how to selectively invalidate the cache for the entities affected by their query they disable the cache globally. Then they complain that Hibernate is slow and decide the solution is to handwrite the SQL for other queries instead. JPA works great, but only if you're willing to actually try to use it.
> I expect every single one of my backend engineers (on any tech stack) to understand the fundamentals of SQL INSERT, UPDATE, and DELETE statements.
Ah, but that isn't actually enough. The people talking about getting better performance from handwriting your SQL are people who understand different types of indices, different join strategies, how the query planner chooses which one to use. And if you put the same amount of time and effort into understanding Hibernate, you can get great things out of it.
I was careful to choose popular, and not project opinions about SQL/NoSQL/etc. In my field, most of our data is relational and we use NoSQL for caching, queues, shared work, ETL performance, dashboards, etc. but at the end of the day for persistence, the RDBMS is where the “gold copy” data ends up.
As you mentioned previously, knowing the tool set and the domain is critical to either approach. At a certain point with technology the benefits and costs are weighted by subjective preference and project specific needs. I have weighted SQL higher than JPA by many factors because I can take my SQL knowledge to any backend project, and I’ve been a part of a lot of different tech stacks in my career.
Maybe my travels have lead me to be surrounded by many more engineers that trust the database (and their knowledge of the database) to handle the persistence without a too many layers in between.
I, personally, have never seen a JPA based project that actually worked well with large-ish datasets, high concurrency, or when non-trivial ETL functions are part of the system- and this general domain has been the majority of my career, so I may have blinded myself to THE majority being confused for MY majority.
Thanks for the response and a good look at the topic from a different point of view.
> I was careful to choose popular, and not project opinions about SQL/NoSQL/etc. In my field, most of our data is relational and we use NoSQL for caching, queues, shared work, ETL performance, dashboards, etc. but at the end of the day for persistence, the RDBMS is where the “gold copy” data ends up.
I'd worry about using an RDBMS in that situation because it's fundamentally mutability-first. I prefer to regard the user's actions as the "gold copy" and the current-state-of-the-world as a transient derived thing (i.e. event sourcing), but that doesn't really play to the strengths of an RDBMS. You also have to make global decisions about transactionality (in particular, you can't easily commit a data write without committing updates to all your secondary indices), and the much-vaunted relational integrity can be a problem because you can only represent constraints for cases where the appropriate response to a constraint violation is dropping the write on the floor. And of course you can't safely allow the ad-hoc querying that SQL is designed for.
I do think traditional RDBMS make some sense at the end of an ETL pipeline - where the secondary indices can be a big help for the ad-hoc querying/aggregation that you want to do in a reporting environment. But transactions don't make sense in that environment because it's essentially read-only (or at least single-writer), so you're still paying for a lot you're not using. I wouldn't use JPA for this, but I wouldn't really write code for this kind of environment at all - the point is to expose the data in a structured form for non-code tools.
Essentially I find mature systems outgrow SQL databases - the case where an RDBMS actually fits is the early stages where you want to run ad-hoc reports against your live datastore, you want to keep the current state of the world rather than worrying about history, having to manually fail over to a replica if master goes down is ok, updating all your indices synchronously is fine because write performance isn't an issue yet, and you can put constraints in the database because blowing up with an error page is an adequate response when the user breaks the business rules. Using JPA increases the rate at which you can iterate on the system, which is the priority for that kind of use case.
I felt the exact same way until last year. Java 8+, IntelliJ IDEA, and Lombok combined massively reduced boilerplate.
Groovy was great for “more than Bash” and DSLs.
I was wrong. Last year we gave Kotlin a try as a team and at this point we’re 100% Kotlin where we would’ve been using Java or Groovy (which would be the vast majority of our code).
Spring and IDE support has made this transition easy. Coroutines are great for the type of code we write, SAM advances in Kotlin 1.4x have removed the last couple “I like the way Java handles that better”. Best off, all of those libraries we already created and use are still completely usable, we didn’t have to rewrite anything.
For me nullability checks by default, synthetic/map backed properties, extension functions, inline/reified functions, and coroutines have so drastically improved the readability AND conciseness of our code I can’t imagine going back.
I went with a Filco Ninja Majestouch TKL about four years ago and I’ve loved it. I needed ten keyless because my new under desk keyboard/mouse tray setup wasn’t really wide enough for a super wide keyboard.
You can choose the switch type you want to run with it as well, I’ve been running Cherry MX Blues, I think Black, Brown, and Red are also offered.
It’s a Windows keyboard so I swapped some keycaps and did some OS rebinding for Mac but I’ve loved it. I don’t know if they offer a Mac version yet or not.
It wasn’t cheap, but it wasn’t as expensive as my Das Keyboard I was moving from- which I had to replace after two years as it was fritzing out and the USB hub in it stopped working.
Here’s a link to a review I just found of it as it gives more detail. The reviewed version isn’t TKL though.
I’ve never tried Odroid but Steamlink, even on a Pi4 is not without flaws. Pi3B+ wired has been mostly unsatisfactory for me and Pi Zero W/Pi3 wireless have been nearly inoperable.
Have you had a different experience? If so- what have I been doing so wrong? I’d love to get it to work on a Pi.
I used a USB AC-wifi dongle on my Odroid-Go Advance, and the performance/latency was about the same as my genuine SteamLink on a gigabit wired connection. The main problem with the Odroid-Go Advance was the screen resolution and size making most UIs unreadable or a chore to use. The screen resolution increase on the Super might help with that though; I plan on getting one once they release, so I guess I'll find out.
Screen resolution problems make a lot of sense. I’ve built a few Raspberry Pi gameboys lately with a 3.5” 640x480 screen and they look great but text is _tough_.
I couldn’t find the exact specs in the post, but it’s most likely unable to run Steam because of the processor in use. If you’re not familiar the screen shots are of a very popular emulation front-end called Emulation Station.
Related, a few years back I got in the hobby of building Raspberry Pi (Zero, 3, and 4) into Gameboy (original gen 1) shells. Economies of scale sure are nice, because even the raw materials for building one cost me more than $80.
EDIT: I found the specs (or someone quoting specs) and it looks like it is comparable to Raspberry Pi Zero and does not have wireless. That would make things like Steamlink a non-starter.
I am pretty sure it is not comparable to the RPI zero. The SoC this is based on is Rockchip rk3326. Dual core A35 @ 1GHz each, g31 (bifrost) GPU. RPI zero uses the older arm11 cores.
I have iCloud turned on but it’s set to only sync Notes or something trivial like that that I don’t even use- I can’t recall ever having been badgered for more.
Maybe I got to that state because I was being badgered? It’s been long enough though I can’t recall.
Might be worth a shot if the risk is acceptable enough to you vs the badger.
I’m not an apologist or shill, but as a user I feel like I understand what I’m giving to Apple (or Microsoft/Google/$OS_VENDOR) when I am using their OS _AND_ enabling any kind of cloud sync. Maybe they’re taking more or less than I expected, but if I’m syncing my entire contact list I just have to assume now they have my contact list- and I accepted that when I enabled the functionality.
Some feature flags/settings across all the OSes get hidden, are non-obvious, on by default, or are flat out using dark patterns (looking at you Win10) but in general I assume the default state (for all OSes) is a combination of reducing support incidents, easiest on-boarding, and trying to push some corporate strategic objective summed up as keep the average user happy enough to stick around and possibly give us more money.
Any app I install on said OS, may want to access this information but without all the permissions explainers I have no idea what it’s going to want or why.
Again, I assume the OS has access to all of this because it’s the OS it either needs it or is the manager of the info and access broker.
To sum up my thought, I guess I agree that there’s a double standard but disagree that it’s necessarily bad or shady- but that’s because I already had a double standard in mind when I think about OS vs App.
Specific to ad-tracking and Apple: I have no proof for my belief but I believe Apple who primarily wants to sell me hardware and has made public acknowledgements of the importance of privacy, including making noticeable improvements to their OS, is significantly less likely to abuse my privacy than any other OS vendor out there.
I’m not saying this as a whataboutism, I just base it on my perceptions given all the things you just flat out can’t turn off in Win10 and that Google literally makes their money off of getting ads to your eyeballs and Android’s permissions are a dumpster fire nightmare for privacy.
I feel (again, no real proof) that the Apple eco-system is providing me the best _mainstream and low-effort_ steps to privacy protection vs the others, but I concede that it’s probably not good enough in many ways.
Not to invalidate the way you feel about that interaction, but putting myself in their shoes- I’m not sure my response would be much better.
Running a booth at a conference is EXHAUSTING. Also, that was your first interaction with them and you were at peak excitement. That might’ve been the thousandth time they had heard similar and their spark may have faded by the time you got there.
I get it though, we feel the way we feel. It sucks when your enthusiasm goes un-matched. I’ve written off companies for interactions a more objective bystander might charitably forgive.
BTW- I’ve got no relation to the company or product. I’m just a happy customer who’s run a booth or two in my day and also felt the same way as you about other companies too.
For reference, Baker City, a larger eastern Oregon population center, is approximately 300 miles from Portland and about 140 from Boise. Pendleton may be about equidistant. I’ve got acquaintances and friends that have only been to the western side of the state a few times in their life and they’re more likely to spend their time in Idaho or Nevada than come west.
The way of life out there is completely foreign to most on the western side of the state, and the eastern side thinks the west is full of “crazy liberals”. It’s been that way my whole life, but the last few years have made it seem completely broken.
I spend a lot of time out east, whether it is Idaho or Oregon, I’ll still spend my time out there- but I’d love to find a way to prevent the divorce (that they’ve been talking about since before I was born).