Germany has had a weird approach when it comes to the Internet for several decades, but sure, it must somehow be related to recent nuclear power policies.
It doesn’t make sense to conflate a decision made by the government with that of a private company, just because they happen to be in the same country.
Ask anyone who did a postgres upgrade. The words "collate" and "glibc" are enough to cause me to pause now. Learnt loads, never going to really use it again, but man do I understand the pain that causes now.
We are unfortunately moving away from self-hosted bare metal. I disagree with the transition to AWS. But it's been made several global layers above me.
It's funny our previous AWS spend was $800 per month and has been for almost 6 years.
We've just migrated some of our things to AWS and the spend is around $4,500 per month.
I've been told the company doesn't care until our monthly is in excessive of five figures.
None of this makes sense to me.
The only thing that makes sense is our parent company is _huge_ and we have some really awesome TAMs and our entire AWS spend is probably in the region of a few million a month, so it really is pennies behind the sofa when global org is concerned.
I read some many stories like this and every time I think of the "your margins are my opportunity" quote, and think there must be so many inefficient enterprises that are ripe for disruption by a small efficient team.
Now you mention it, the other thing we are being forced to do is categorise our work (e.g. commits/PRs) as Cap/Op. And then once a year a bunch of us are randomly selected by one of the big four auditing companies to talk about why that piece of work was Cap/Op.
[Window Title]
Critical
[Main Instruction]
Unsupported GPU
[Content]
Zed uses DirectX for rendering and requires a compatible GPU.
Currently you are using a software emulated GPU (Microsoft Basic Render Driver) which
will result in awful performance.
For troubleshooting see: https://zed.dev/docs/windows
Set ZED_ALLOW_EMULATED_GPU=1 env var to permanently override.
[Skip] [Troubleshoot and Quit]
That's more of an issue with your system than an issue with Zed, you have to veer pretty far from the beaten path to not have proper DirectX nowadays. Are you running Windows in a VM?
I've literally programmed with VSCode for basically a decade this way without issues. Zed lags, it's disappointing and if I really like Zed I'll have to sort out another setup.
MSTSC is one of the rock-solid tools from Microsoft, and does better than almost everything else available on the market other than some PC over IP technologies specifically highly optimized for this use case. I've been programming with an ancient ThinkPad forever because I'm just remoting into a much more powerful machine.
If you are having problems with Windows RDP then the problem is somewhere else along the pipeline, not RDP itself. No other remote solution I've used is even in the same ballpark as RDP in terms of responsiveness and quality. RDP on a LAN is very usable for actual coding work.
Maybe try gaming-oriented remote desktop tools, like steam link or sunshine/moonlight. Those work great with directx, assuming you have a working gpu (at least integrated gpu) on your remote box. They also have way better latency, though use a lot more bandwidth.
By explaining the advantages over "older" methods. A lot of people use Moonlight/Sunshine for non gaming related stuff, specially considering than the alternatives are all proprietary.
They're productivity tools, not gaming software. You'll be faster and deal with less errors using the correct optimized remote desktop tool for your job, versus what you're using now, which can be slow and error prone.
Sunshine and Moonlight are no more than accelerated and finely tuned VNC servers that happen to be targeted at gaming. You can totally set them up as a regular remote desktop solution.
Right, but I'm saying their sites make it very clear that they're meant for gaming, so GGP may indeed have a hard time convincing corporate IT that they're for work.
My post was answering the question of how they should ask for permission to use it. You pitch it as productivity software that helps you do your job better.
If no monitor is connected then RDP doesn't load gpu drivers. It can also make RDP performance much worse as HW accelerated video encoding is not working
I assume it is not an issue with other applications like Chrome or VSCode (I mean VSCode is Chrome). They usually have some sort of fallback rendering on these environments that work well enough.
It may not be an actual problem with zed either, despite the warning.
Maybe it's misdetecting something? I used to use Remote Desktop for game development sometimes, as weather could make the journey to the office impossible, and the performance was always pretty ok, even with UE5 stuff making heavy use of Nanite running at 1440p.
And if it was actually software emulated, which I can't believe for a moment, though I admit I never checked (I just always assumed the window contents were transmitted via some kind of video encoder) - then I can't imagine that a text editor would be a problem.
The input latency might not be as good as you'd like.
> The input latency might not be as good as you'd like.
Yeah input latency is annoyingly rough, not super bad but _just_ laggy enough to make it annoying to use.
Debating how much I want to change things, I can directly punch into my Linux machine but all my dev IDEs are on a VM for a long list of reasons, and I doubt Zed is going to run on my old ThinkPad if it struggles on software rendering, but we'll see.
ORMs are one of those topics that get hotly debated for little reason IMO.
ORMs like almost everything else in SWE they are _tool_. It's not a law or a prescription. It's not mandatory.
ORMs are fine for 99% of cases. When it isn't fine use raw sql, no one is going to mock you, no one is going to jeer at you. Most times ORMs are fine, sometimes they are not.
I think the reason they get hotly debated is that people's personal experiences with them differ. Imagine that every time Alice has seen an ORM used it has been used responsibly, while every time Bob has seen an ORM used it has been used recklessly/sloppily. I'm more like Bob. Every project that I've seen use an ORM performs poorly, with select N+1s being the norm and not the exception.
The problem with ORMs is that they're a very leaky abstraction. Database performance matters a lot for any non-trivial application, and in order to use an ORM performantly you need to understand both the underlying SQL+database but also all of the nuances of how the ORM maps to SQL.
So basically you end up with two situations:
1. You need to hire engineers with double the expertise (not just a SQL engineer, but a SQL+ORM engineer).
1a. You hire a SQL engineer who now has to learn Yet Another ORM.
2. You hire engineers who only know the ORM but not SQL, and your app ends up having shit performance.
Basically, ORMs are simply complicated SQL generating macro frameworks. They are way too leaky to provide a useful level of abstraction like most programming languages.
LLM coding tools may displace ORMs, because they can take away a lot of the tedium with integrating application SQL, which is what ORMs are supposed to do.
Mixing ORMs and raw sql doesn't always work well with ORMs so you often end up in situations where the ORM made the easy parts easier and the hard parts harder.
> Most times ORMs are fine, sometimes they are not.
When fine is defined as "improves dev't speed" I think they are not "fine" for any serious (say 100kLOC+ size) project.
> It's not a law or a prescription.
They come with a lot of webFWs, to the point that a lot of web software is built on top of them. These FWs (Django, Rails, Laravel, Symfony, Play, etc.) promote the use of ORMs.
I worked on the pokemon.com website for several years. It has over 2 million LoC in python (~2.5 once you add in frontend JS). It's a Django site that uses Django's ORM; I can't recall ever seeing any raw SQL. As you might imagine, the site has high traffic and high performance requirements. We never found the ORM layer to be either a hindrance or a performance barrier.
Before the invention of SQL, people wrote software using VSAM files and navigational databases with extremely limited computing and memory resources and it worked.
That isn't the point, though. Some people, myself included, find that processing the data in a declarative language directly in the database makes your code simpler and less prone to bugs.
Not neccesarily. jOOQ[1] and sqlc[2] are great options if you don't like stored procedures, but for a small app or a prototype, just having plain SQL strings in your app is fine.
My point isn't that the code has to be stored in the database, but rather that the processing happens in one place where your data is stored and your middle tier just gets the results. Pure, stateless data. This means you don't have to synchronise shared mutable state between your app and your DB server, cutting out all the headaches of ORMs, such as having to specify your data model in two separate places, n+1 queries, locking, lifecycle management, dirty tracking, eager loading, caching, and optimistic concurrency control. All of this adds to complexity and congnitive load.
SQL also provides a declarative approach to defining your business logic. You define the what, not the how. In addition to greater productivity, the programming model is much simpler because you aren't complecting control flow with data flow. With JSON support in Postgres, your query results don't have to be flat tables either. You can get your data in the exact shape you need.
> How do you version that code
You put it into your VCS. SQL is part of your code base, you can and should version control it just like any Python, Ruby or Java code. When using stored procedures, I recommend putting them in a separate schema, so that the schema can be dropped and recreated in a single transaction during deployment. See [3] for an example of stored procedures under version control.
> how do you reason with the business logic split all over the DB and code
You separate your concerns instead of mixing them. The core business logic is in SQL, with your middle tier doing the plumbing, orchestration of external services and presentation.
Again, performance is not my point. If you want maximum performance, use a low-level key-value store, hence my VSAM analogy. On the contrary, for me it is about simplicity.
SQL is the most high level language in common use. It abstracts away everything: Storage, memory, concurrency, and, most importantly, control flow. Complexity comes from complecting things, simplicity comes from decomplecting [1] things. SQL decomplects the what (data flow) from the how (control flow) which means less cognitive load, higher developer productivity and better maintainability.
In my experience, writing business logic in SQL results in fewer bugs and less code. I have replaced 50-line Java methods with 15-line SQL projections multiple times. With Python, the ratio is closer to 2:1, but it's still impressive.
And all of this without having to consider type impedance, eager versus lazy loading, result set mappings, second-level caching, dirty tracking, lifecycle management, OCC, or obscure savepoint bugs. Performance is just a nice, but welcome side effect.
> We already have an abstraction for interfacing with the DBMS. It’s called SQL, and it works perfectly fine.
ORMs are not an abstraction to interface with the DBMS. They are an abstraction to map the data in your database to objects in your code and vice versa. It's literally in the name.
Feels like a lot of anti-ORM sentiment originates from people who literally don't know what the acronym means.
> They are an abstraction to map the data in your database to objects in your code and vice versa.
Maybe that's part of the problem - you're trying to map tabular data in your database to hierarchical data in your programming language.
Of course there's going to be all kinds of pain when pounding square pegs into round holes. Getting a better hammer (i.e. a better ORM) isn't necessarily going to help.
Okay, so what's the round peg that goes in the round hole, here? Forgetting about objects and just passing around dicts or whatever with no type information?
The way it integrates into Django is more than just an abstraction to SQL. It's also an abstraction to your table schema, mapped to your model. In short, it's the Pythonic way of fetching data from your models in Django.
It allows for functional programming, as in building queries upon other queries. And predefined filters, easily combining queries, etc. And much more.
Of course you don't need all of that. But in a big project, where you might query some particular tables a lot of the times, and there are common joins you make between tables, then sometimes it is nice to have predefined models and columns and relations, so you need less verbosity when building the queries.
You do of course need to learn a new tool to build queries, but it does pay off in some cases.
Yeah, if you remember to use it properly. SQL injection was pretty rampant before ORMs and web frameworks started being used everywhere.
ORMs let anyone make CRUD apps without needing to worry about that sort of thing. Also helps prevent issues from slipping through on larger teams with more junior developers. Or, frankly, even “senior” developers that don’t really understand web security.
I owe Java a lot. Programming clicked for me when I was taught OOP in Java, my other programming module with event-driven design in C# which I hated.
Fast forward a few years later, and I'm actually at a C# shop.
Fast forward a decade, I'm at the same shop. I adore C# and I fondly remember my foray into Java.
I left Java around the time Streams were becoming a thing. I thought it looked like a mess, and then I ran into LINQ in C# land. Swings (pun intended) and roundabouts.
reply