It’s basically saying “consent to me reading all your mail or you will not longer get mail that you need to live a normal life”. I can’t imagine why anyone wants to let the EU and some police clowns comb through their sexy time videos, kids playing on the playground, and personal journals. I would think a continent that has been through Stasi, the SS, and KGB would welcome this with open arms instead of grabbing the pitch forks and torches.
Yup. I gave up on trying to get Google wallet / Android pay to work on my lineage device. I got it working sometimes but it broke after update and just wasn't reliable enough to keep trying when paying for stuff. I'm not really sure whom they're protecting with this stuff -- the credit card processing companies, maybe?
I have found Play Integrity Fix [1] with playcurl [2] is reliable enough for passing Play Integrity in Wallet and other apps. My current issue is that Google Messages has its own integrity checks that are stricter than Play Integrity, and will silently stop handling RCS messages if it fails those checks. I currently have RCS disabled because it is too unreliable.
I also have OP7Pro (what an amazing phone btw), and yes, we're pretty much sufficiently out of date that they still work - a wild but true reality we find ourselves in.
I mean my Messages app. I installed it years ago and never updated, because why would I ever updated an SMS app, the only thing that can ever happen is for things to break that used to be working, lol. I don't even know if I run A12.
I do know, though, that the OP7Pro is one of the last Android devices that are whitelisted by Google to pass SafetyNet without hardware-backed attestation. Shame that TWRP wiped my working setup. I've been trying to get them to add any basic protection against that for over three years: https://github.com/TeamWin/Team-Win-Recovery-Project/issues/...
It is an amazing phone. Notchless, relockable bootloader (not just unlockable, but custom AVB key support!!), in-screen fingerprint sensor, 90Hz AMOLED, and great build quality.
> because why would I ever updated an SMS app, the only thing that can ever happen is for things to break that used to be working, lol.
Text parsing/rendering is a security Achilles' heel, and SMS app vulnerabilities are commonly exploited entry points for persistent malware from the likes of NSO. All things being equal, should update SMS apps for the security updates.
Text parsing and rendering is supposed to be done by the OS. And if there's an OS-level vulnerability like that, then the OS is what you update, not necessarily just the app.
How do you know it's carrier RCS? To the best of my knowledge they are only gatekeeping access to Google Messages private network, not carrier RCS? (Considering the very little number of carrier RCS that's not very relevant though)
> I'm not really sure whom they're protecting with this stuff -- the credit card processing companies, maybe?
(small nit: does "whom" even go there?)
They're protecting the TEE because they do not want third parties to be able to automate Google Pay through modified software. This isn't necessarily just about normal end users but more like smartphone farms.
[1] Moral: Don't assume everyone knows what a particular acronym means. Just because it's in your head doesn't mean everyone else knows what you mean.[2] E.g., if I say 'JRE' I mean 'Java Runtime Environment' and not 'Joe Rogan Experience'.
[2] According to Piaget[3], people are able to identify that others don't know what's in their heads sometime between ages two and seven.
>is a little far to be a simple misjudged tone, even if it was intended as a joke. I did find it a bit funny but it still felt a bit insulting too.
No. Not a joke. Just pointing out something you already knew: That I (or anyone else) don't know what's going on inside your mind unless you tell me.
That you ignored such a simple truth and didn't think to define your terms was a waste of my time. As such, I felt insulted at your (apparent) complete lack of respect for the time and attention of others.
Take that as insulting if you wish, and if you find it insulting enough, please ignore me completely going forward. I promise you I won't mind.
> That you ignored such a simple truth and didn't think to define your terms was a waste of my time. As such, I felt insulted at your (apparent) complete lack of respect for the time and attention of others.
My neglecting to define it was not because I was ignoring that not everyone knows everything I do.
There are quite a few acronyms that are widespread enough on HN (or in programming in general) to be used without defining them anew every single time (such as, say, "API"). I hadn't considered that of those, "TEE" is not one. That doesn't mean I don't understand the concept of individual knowledge, only that I don't always put a complete effort into my drive-by comments, and evidently had not into that one.
Even at that point, it would have taken less time for you to ask for a definition without additional remarks that imply I should have known better. Who are you to imply I didn't know better? I'd say that was the real waste of your time, considering it makes up over 50% of the comment.
Additionally, I don't have a "complete lack of respect" for others' time and attention. I would've edited the comment to fix it if it had still been within the edit window. I apologized for having left the definition out because that was an honest mistake, and it was never meant to waste anyone's time or attention. Even before the apology, I don't think it was very reasonable for you to have assumed that the waste of time was intentional, and replied in the way you did.
> Take that as insulting if you wish, and if you find it insulting enough, please ignore me completely going forward. I promise you I won't mind.
I generally don't ignore people until I have nothing left to say to them. But yes, people (myself included) typically find it insulting when you assume bad faith of them. If this was truly your intention, then it is not just my fault for "wishing" to take it as insulting. Your tone has an impact on how others perceive you.
To be blunt, if you are rude on purpose and proceed not to care about how it makes others feel, that behavior isn't welcome here. I can understand if you felt frustrated that I didn't define my acronyms, but that's no reason to lash out about it, even when it's in the form of mere patronizing remarks.
Yeah, I'm sorry that they spoke to you like that. It was unwarranted, as was the subsequent benefit of the doubt I gave them. It's apparently just the attitude they communicate with others with. Unfortunate.
That said, thank you for your thoughts on this. I'm glad you shared them. Good on you.
That said, I don't need you (or anyone else, for that matter) to tell me how I should or shouldn't interact with others -- as that's incredibly condescending (and incredibly rude as well) and makes a number of unwarranted (as I mentioned) assumptions.
Again, thanks for your thoughts. I'll give them the attention they deserve.
I'm pretty sure you told the GP how they should or should not interact with others by telling them not to use acronyms. I'm don't understand how that's any different.
>'m pretty sure you told the GP how they should or should not interact with others by telling them not to use acronyms. I'm don't understand how that's any different.
Except I did nothing of the sort. I took the information given and attempted to interpolate (unsuccessfully, I might add) what OP was talking about.
While I did make the point that OP should have realized that others don't know what they're talking about if they don't tell us, I most certainly didn't say they shouldn't use acronyms.
Rather, I chastised them for not defining ambiguous terms, which wasted my time and energy trying to figure out what they were going on about.
>I took the information given and attempted to interpolate (unsuccessfully, I might add) what OP was talking about.
You could have used your brain and just Googled "TEE Android". But by all means, despite not having either the domain-specific knowledge nor the common sense to manage to Google it competently, feel entitled to be an arse about it. I trust you can read my tone here?
Sorry, TEE stands for Trusted Execution Environment. It's where stuff like DRM executes with access to secrets that the HLOS (Android) can't tamper with. On ARM SoCs the TEE is usually provided as part of TrustZone. No need to patronize.
When I read posts like this I'm always surprised and confused.
I've had quite a few interviews for software jobs in my life but not a single one was leetcode style or with a whiteboard...
Is this just a cultural difference between countries? (I live in germany) or was I just lucky?
Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code
Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.
Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.
Yeah. And a gentle nudge that Conway's Law is about lines of communication in general, not specifically the org chart.
I used to be in charge of the stored procedures that served as the API to a shared database system used by many teams. (So, not exactly the same thing, but I'd argue that the sprocs vs ORM debate isn't entirely dissimilar from the REST/RPC vs GraphQL debate.) My turnaround time for getting database API changes into staging for application teams to play with was typically less than one work day. But that happened because I had a lot of latitude to just get things done, because the company valued rapid delivery, and therefore made sure we had what we needed to deliver things rapidly, both from a technical and a business process perspective. This was in a very highly regulated industry where every change required paperwork that would be audited by regulators, too.
I've also worked at places where this sort of thing took ages. Typically the worst places for work backing up were organizations that used Scrum, because the whole "sprints" thing meant that the _minimum_ time to get something from another team was about 1.5 times the sprint duration. And even then you could only manage that if you could deliver a request that already met all of that particular team's requirements for being able to point it, and could convince their Product Owner that it was a higher priority than whatever their pet project is this quarter, and the stars align so that you perfectly time the submission of your request with respect to that team's Scrum process's frame rule.
The thing I want to point out here is that absolutely none of that bullshit was ever the API technology's fault.
My experience is that the problem is avoided in theory, but not in practice.
Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.
The modern web development practices are just insane.
The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy.
On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cram information into every single bit!"
Every place you look, things are completely bananas.
> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy.
For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint.
What ever happened to full-stack developers? The "frontend" and "backend" developer split is so incredibly inefficient that it's really jarring—you take something that should take 2 hours and magically, through tickets, delegation, and waiting for results (then repeat that for debugging, who knows how many times!), make it into a 2-3 day task.
I once reproduced (black-box style!) a two-week effort by a three-man team in six hours of work simply because I had PyCharm and IDEA opened side-by-side and could write code on both sides at the same time.
If someone has a good explanation for why the full-stacks that were once the norm went almost extinct, I'd be happy to give it a read!
For context: I work on large-scale browser apps that are closer in complexity to something like Linear or Obsidian than to your standard WordPress blog with some forms. E.g I'm currently working on a browser-based GIS tool for the financial sector.
I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be almost good enough at doing two different things or extremely good at one thing. I chose the latter option.
Modern browser apps are complex beasts, at least if you want to do them right. You obviously have to worry about all the technical bits --- HTML, CSS, JavaScript, your view library of choice, platform APIs like <canvas> and WebAudio, cross browser testing, bundle sizes, performance optimizations, techniques like optimistic rendering, all that good stuff.
On top of that, you also need to work closely with designers to make sure they know the features and limitations of the platform(s) they're designing for. More often than not, you end up being a sort of bridge between the backend devs, designers, and product managers.
A lot of times you end up doing design too, whether you like it or not. I've learned a lot about UI/UX design just because I often have to fill in the gaps where a designer forgot to include a certain error state, or didn't test their design on tablet screens, or didn't account for cases where a certain API might not be available.
I tried for many years to learn as much as I could about Django as well as React and friends. But it eventually got too much. I found that I wasn't able to keep up with both ecosystems, and I was producing code that wasn't very good. I could certainly build things quickly because I was familiar with all parts of the stack, but it came at the cost of code quality, security, stability, and robustness. I eventually decided to hang up my backend developer hat and focus exclusively on what goes on inside the browser (which can be a lot by itself these days!)
It's probably possible for a single individual to build a high-quality server-rendered MPA with some forms without making a mess of it. But that says more about how good Rails/Django/Laravel are than about the capabilities of any single individual. I don't think a single person could build a product like Linear end-to-end without cutting corners.
IMO the fact that being a full-stack dev is so taxing is an indication that the stack as a whole is just way too complex and overengineered. Which is rather obvious from looking at the state of affairs on the frontend side of things. Desktop GUI devs don't usually have those problems.
Thing is, even when web apps are essentially used as desktop app replacement (Electron etc), all the complexity discussed here is still there.
As far as looking OS-native, this is (unfortunately) increasingly less relevant as OSes themselves drop desktop UX consistency even internally. But that aside, Qt is still around and is a very mature framework for "near native" UI, and then there's Avalonia and others. Even Gtk is surprisingly decent on Windows these days. Although I'm not sure what this all has to do with the original subject, since web apps most certainly don't look native anywhere.
I don't think the claim is that a single developer should be able to build an entire enterprise product, but rather that a single developer should be able to implement the software side of a task end-to-end. The latter is a reasonable expectation when your software is monolithic.
> ... I don't think a single person could build a product like Linear end-to-end without cutting corners.
Cutting corners is a feature. I bet the Linear team is as pained as any, internally, at the tradeoffs they're making.
There is no way to know "what to get right" without going through it. So for 80% of the dev cycle the job is to cut corners to get to the 80/20, rinse and repeat forever.
This isn't against excellence and the dream of a beautiful product experience as your reply seems to convey.
If you absolutely need 2 people for that, they should be side by side.
But yes, that break-down of the problem is insane. People artificially split an atomic problem in two, and go create all of that extra craziness to try to solve the communication problem they made.
And then people go and push UX and UI tasks into the frontend developer, and ops tasks on the backend since them are there... What is insane again, because those are really incompatible tasks that can't be done with the same mindset.
And since it's standard, backend tools won't support the frontend and the other way around. So the insanity gets frozen on our tooling.
Because people have a limited appetite for complexity.
I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort.
Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to actually invest time in learning whatever back-end they're dealing with this time.
Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.
This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive.
At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize
It really is. Regrettably, I've drifted away from it in large part because of client requirements for more "modern" and "maintainable" solutions (e.g. Python or Node; I'll take Python every time, thanks). Django comes very close in terms of productivity (and is better in some ways: auth, admin, etc.) but the Rails CLI, generators and community (not sure if this is still relevant) give it the edge.
The "recent" (last 10+ years) movement towards "lightweight" libraries (instead of frameworks) that require you to either reinvent the wheel, copy-and-paste or use some random "getting-started" template every time you start a new project is disheartening. As others have said above, I think it's partially resume-driven-development and people wanting to tinker (both of which I do appreciate).
Something which continues to surprise me is that there hasn't really been a "modern" successor to Rails. Granted, I haven't kept pace with developments in the Node/TypeScript world but, last time I looked, Sails was on the right track but wasn't very actively developed and I was shot down (in favor of Express spaghetti) when I suggested it. There's also a smattering of Rust web frameworks but none that quite fit the bill and come with all of the batteries and opinions included. I keep saying I'm going to do a Summer of Code project which attempts this but ... life.
There are some Java frameworks that are kinda similar? Take a look at Micronaut for example. It has data access interfaces that use ActiveRecord's naming approach, controllers, view renderers, and a whole lot more on top.
Thanks. I'll take a look. Didn't mean to overlook Java, I'm just less familiar with that environment. I've dabbled with some JVM languages and could also see Kotlin being a very nice option for such a framework. Though, to be fair, I know Java has come a long way in terms of expressivity, syntactic sugar, etc. (better performance is a given).
There's no modern successor to Rails because Rails itself os still modern and very much up to date. The recent introduction of Stimulus allows to implement a SPA completely on rails (if they wanted) with the same simplicity present everywhere else in the framework.
Many organizations would rather pay 3 people $120,000 each instead of paying 1 person $300,000 to do the same work, for a variety of reasons. Some good, some bad.
Microservice architectures and the associated explosion in complexity on both ends are to blame. When it takes twice the time to build something, it is natural to hire twice as many developers. Increased complexity drives specialization.
I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.
Sounds good in theory. In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code. This isn't a problem until the application gets big enough and now you have business logic that should be the same spread out across an app. This leads to weird bugs where something that should work the same way doesn't depending on which page you're accessing things from. Of course, I don't a solution, solving things like this is what makes software engineering hard.
> In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code
There is no easy or simple or final solution. The solution is to do the hard work of software engineering and catch this stuff at code review time or to plan and do refactoring later when you realize something needs normalization. I wish developers would just accept that software engineering is hard and do the hard work necessary.
There's that whole "the best software engineer is lazy because he will automate stuff", but that does not give anyone a license to automate stuff in an unmaintainable way. Automating stuff is hard and there is no easy way out.
The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance.
Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database.
The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.
Came here for that. People in this thread basically reinventing GraphQL lol.
"We need a http API endpoint that gives you all the data for one page. And also be able to reuse parts of it for other pages." Yeah bro, this is GraphQL.
Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.
You are literally Transferring the REpresented State of a given page/view/screen.
Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.
There's a separate project Cloud Seeder [1] which is completely open source and gives you 1 click server appliances and IP addresses on-premises. Disclosure, I work there.
At the moment we only support the major hyperscalers since they're the most common ejection destinations, but we're considering adding more options. No concrete plans for this at the moment though
reply