6,858 karma · joined December 30, 2017
Currently:
AI inference/training/orchestration C#/.Net Python TypeScript Angular SQL
Too many other things.
> ▲ Module 'some-library' used by 'src/app/some.component.ts' is not ESM
> CommonJS or AMD dependencies can cause optimization bailouts.
> For more information see: https://angular.io/guide/build#configuring-commonjs-dependen...
While I agree the attack vector is pretty awful, I was just curious exactly what the exploit was. The article doesn't even mention it.
It links to Apple, which is likely that 0-day 0-click that Pegasus uses (BLASTPASS). They report that as a flaw in PassKit though, which would not affect Android or Windows.
That's why I was thinking the WebP overflow?
That is actually worse, and makes the discussion here even more off-topic, because that has nothing to do with JavaScript. I has to do with decoding WebP images.
Does this have to do with the 0-day exploit in WebP that is causing a huge mess for the entire ecosystem?
Everyone seems to be fixated on "ads shouldn't be able to run JavaScript" and the like.
What exactly is that JavaScript in the ad taking advantage of? Why would it matter that it's an ad and not just a website?
If ads can do it, web pages can do it.
Obviously meant to confuse people, because that looks an awful lot like it would contain pseudoephedrine.
But the "PE" now stands for the useless "phenylephrine".
I just checked a heavy user for our enterprise SPA. localStorage is using ~12 KB.
I don't know what people are just throwing in localStorage but they certainly aren't pulling down much of the database (which still would have to be checked to ensure cached data in there isn't stale).
In what use case do you run into that?
I'm lead and an architect on an enterprise application at the moment that drives the whole company. It's your standard configuration, front-end, APIs, SQL. The system requests what it needs to fulfill only what functionality the user is dealing with.
Earlier in my career I was dealing with large enterprise desktop applications that talked directly to the database, with no centralized API. Some of them had thousands of individual desktop clients hitting a single multi-tenant SQL server. No problem, SQL Server would handle it without breaking a sweat. The bandwidth to an indidual client was fine. It was fast. And that was 20 years ago.
"get the database"
How small do you think these databases are?!
You're going to download the entire hotel booking platform's database?
For how many hotels? One at a time, and then get another databse? Or are you getting a Sqlite booking database for every hotel in the world? And you're going to send them to each user? For what date range?
And even if that were possible, you then have to commit your offline updates. What if someone else booked the date range prior to you? Now your Sqlite copy is stale. Download the entire thing again? There could have been countless changes from other users in the time since you last got your copy.
This explanation just leaves me even more confused. It's illogical.
I mean, I get it, from a technical standpoint. Ok, so you're going to send read-only Sqlite databases to everybody.
Is it missing what the API (that you still need) is updating when you insert or update something and all client DBs are now stale? Is there a central database? How often are you pushing out read-only database replicas across the wire to all clients? Is that really less "chatty"? If so, how much bandwidth is that saving to push an entire database multiplied by the number of clients?
None of this seems logical. Maybe I'm missing the real-world use-case. Are we discussing tiny Sqlite databases that are essentially static? Because in the last 30 years I've not run into a situation where I needed to have clients execute SQL queries on tiny, static databases let alone still need to potentially update them also.
I decided to just write it in .Net with SQL Server, since that's what Microsoft was saying to do at the time.
That was 22 years ago, when it was in beta.
I've also made a career out of it. I got to greenfield another project recently, and I went with C# for the APIs.
I do everything I can to follow KISS. These are important enterprise systems that drive the entire company. I went with a front-end framework in TypeScript, C# APIs, and a relational SQL DB as the gist of it. It turned out great ... performant, reliable and the users were reporting positive feedback (this one was a recent upgrade from an older system).
The other side had the same number of users, but had over 100 PHP microservices, Docker containers, queuing frameworks, and all sorts of additional technologies in the mix. It had 5 times the number of engineers on it, but was at the end of the day was functionally equivilant and had the same volume of traffic.
When comparing the up-time, it was clear the microservices architecture was the main source of pain. They weren't even comparable. We are always talking about whether we're at "5 nines", and the other system was having major outages every other week.
You could argue that it was a poorly architected system, and that microservices weren't the root cause, but that really wasn't the case. The entire system was based around the microservices, and they weren't working as promised. What originally was seen as separation of logic and concerns and everything else that microservices offer eventually over time became a tangled, inter-dependant system of services that were very high in bandwidth, slow in performance, difficult to maintain and bad in reliability.
This isn't the first time I've seen this. I've worked with microservice architectures in other companies, and I haven't yet seen it "done right", or at least how I understand it. It always comes across as great in principle but bad in practice.
When I got my first job in software engineering, it was when .Net was in beta. Since I only knew VB, I chose to go with VB.Net and Windows Forms.
Well, that was quite a jarring introduction to actual object oriented programming!
This is the point when a lot of people surrendered. The change was too much, there was no path forward for VB, and Microsoft wanted everyone on .Net.
I eventually switched to C# and we had a hybrid application for a while before it was all ported to C#. It actually went on to become industry leading software in its space.
20+ years later, that doesn't seem to have been a bad choice. Windows Forms is very simple, with a powerful drag-and-drop designer, double-click to hook up events, it's all very similar. Yes, you have to understand object oriented programming much more than you would have under VB, but that's as close as you are going to get from Microsoft on the desktop. They try to hide it as best they can.
I still use Windows Forms if I need to put together something that "just works" on Windows as a desktop app quickly. It's unmatched for that.
There are newer technologies, such as WPF, WinUI3, Avalonia and others for .Net but they come with a complexity that would be above your typical use-case for VB6 back in the day. The VB6 user who just wanted to get stuff done probably doesn't want to have to understand how to implement the MVVM pattern just to get a UI.
It seems like this has since been removed, but what kind of crazy decision is that?
In 1992, Congress passed a law saying everything was to be declassified in 25 years. October 2017 came and went, and the FBI blocked around 7,500 documents from release. The DEA didn't want CI names related to organized crime in them. The State Department blocked some due to "national security and foreign affairs concerns".
Trump claimed while running for President that he was now going to release everything, yet the FBI and CIA stepped in again and those plans changed.
Trump finally said he couldn't release them due to some being "of such gravity that it outweighs the public interest in immediate disclosure".
So they remain secret, 60 years later.
I managed to put together the overall framework, architect a SQL database for it, and after a bit of time had a working replacement for the most important parts of what it was replacing. While discussing the next steps, the owner of the company mentions he just sold one already to one of the largest clients using the old system. I found that rather surprising, as he made no mention of announcing it let alone starting to sell it, and it wasn't ready to be sold, but here we were.
We go to meet with this company to discuss specifics, and one of the questions they ask is "exactly how much bandwidth is utilized when we do X? We have Y employees and want to know exactly how much it uses if they were to be using it at the same time".
Now, I wrote this thing to be as performant as I could, but at no point up to now did I have time to run specific performance metrics on it such as how much bandwidth was being used by every specific piece of functionality. It wasn't even an announced product, as far as I knew.
My boss turns and just stares at me. So I answered honestly, said I didn't have the exact numbers, and I can get back to them, but I felt that their current setup should be more than sufficient.
Meeting ends, we get back to the car, and he is suddenly irate.
"Don't ever, ever tell a client you don't know something! How could you do that? That made us look like we don't even understand our own product! You know what you do in that situation? Make up a number that works! You never say you don't know! Unbelievable!"
I'm not in sales. I got dragged into this meeting out of nowhere only to get chewed out for not properly fielding a question, about a product that I didn't know we were selling, that I couldn't possibly have expected to answer at that point.
It's incredibly helpful to move fast on large projects.
It's not about missing null checks and other simple things. If you change code in one place, that happens to affect code in some far off other place, it won't compile. In JavaScript you would end up with a runtime error and be wondering what is going on. With TypeScript the compiler will tell you right away what the issue is.
I found it incredibly helpful today when we had to completely refactor an Angular service method. I wanted to remove a parameter. It was called in various places, and all I had to do was run the compiler and get back "can't do it, go check XyzComponent.ts line 51" and give me a link to it. I'd click, go right to it, change the call site and repeat. After a few minutes it was compiling again and it was clean.
Sure, you can change function signatures in JavaScript and go and manually find all the places that function is called, but what if you miss one? A really good IDE can probably figure it out, much like they can sort of handle intellisense for raw JavaScript code. But with the compiler you are ensured that you got them all and everything checks out.
That's just one simple example.
Sounds like a project I'd stay away from.
With comments like "Also, TypeScript hurts to write. Good riddance."
What exactly is the problem here? Do we have too many developers who grew up on JavaScript and aren't seeing the benefits of static typing? Is a tiny compiler (transpiler) step on the front-end simply too much to ask?
I say this as a lead on an enterprise Angular project who used to loathe front-end development (for 20+ years). TypeScript has brought back some sanity.
I fully understand the reluctance or just sheer annoyance of having to set up a toolchain just to end up with JavaScript. I've written an absurd amount of JavaScript since 1995. And yes, it is quirky, and awkward, and at times seemed downright ridiculous. ES6 at least was somewhat of a paradigm shift towards normalcy. Granted, JavaScript was created "in 10 days" and then simply became the de facto language of the web.
But after I started working with TypeScript, and enforcing linting rules through ESLint, and working in a proper IDE for it like VSCode, there is simply no going back. And it's not just the development that is so much better. With tools like webpack you also easily get tree-shaking, bundling, and minification, which are all good things for the users.
For very small sites with a single developer, sure you can just write JavaScript and call it a day. But anything even slightly beyond that and I would take the small amount of time to setup a build environment. It's not that difficult, and once it's set up properly it should stay out of your way and help tremendously.
I'm full stack lead on an enterprise Angular project that happens to require all of this stuff, but I would use it going forward for many less complex, non-SPA projects as well.
After 20+ years I don't necessarily loathe working on the front-end anymore.
That's not to say I didn't have to be pulled kicking and screaming into this world at first, while yelling "get off my lawn!". That may have been the case.
I never said storing BLOBs was a great idea, but for smaller databases, like you say, and with small files, it is an option and it won't wreck your performance like you think in many cases. The profiler knows how to handle this, and if you query doesn't need it, they aren't going to impact it like you are saying. As always test, test, test.
For large databases, that's why I meantioned FILESTREAM. Those are not in the database, they are essentially pointers to files on disk.
> To make matters worse, when a new version of the file arrives, people never overwrite the existing file - they store the new version as a new row or object
This may be a requirement? And if it is, you have to store it somewhere. Using FILESTREAM you are free to put the actual files wherever you want. The database column says where to find it.
What is so specific about "biological" (which is a fairly meaningless term) that can't be replicated if we do the same thing with silicon or other substrates?
I think you are hand waving the whole thing and thinking consciousness = brains.
Sure, our brains produce consciousness, but WHY? Structure? Density of information? Complexity? Brain waves?
Nobody knows.
Just with SQL Server alone, for decades now you can store BLOB data.
Need more than 2GB?
There's FILESTREAM, where enormous files can sit on the disk, outside the DB, but be referenced as if they were in the database via a varbinary(max) column.
"Think of it as having a new database column type where you can store files of any size"
We have that. It might not be AWS S3 and cached on a CDN, but that is just adding additional cost, complexity, and lock-in.
I would tend to agree. I don't understand these sorts of decisions to rewrite huge sites in niche languages and frameworks. You tend to get one engineer who really likes some language, has some clout, and is able to pitch it as a good idea. And then the blog posts about how it saves the company untold millions, while hiding all of the associated costs.
Not only is it niche, so your costs going forward will be higher, it even required investing in new "tools and strategies" just to bechmark it.
"Elixir has proven so efficient that testing the limits of our services became a challenge unto itself, requiring investment in new benchmarking tools and strategies".
I wouldn't personally gamble on a robust job market for Elixir developers in a decade. And those there are will be able to command higher wages.
Sure, they will be out there. But so were COBOL developers for Y2K.
Precisely.
Sometimes, I wonder if people are curious why after all these years am I apparently still working? Have I not become a "VP" or a "founder" or, better yet, a "VC"?
To each their own. I'll be ok.
Oh, the horror!
In all seriousness, I have been at this since the late 90s. 1996 specifically when HTML/JS/CSS all became a thing. Do I want to write another complex dynamic HTML form with validation? Not really, no. I really don't enjoy it.
Do I want to upgrade this current Angular application from 16 to 17 that I lead?
Yes, I actually do.
Because I know that will keep us from falling behind, from more tech debt, from an impossible upgrade path. Am I barking orders from on-high? No, I'm not. I'll actually do it myself, because I want to make sure we are are where we need to be.
And after all these years, obviously the front-end is only the least of it. The APIs, the database, the custom hardware, the 3rd party vendors ... the ...
Anyway, burnout is real, if you are feeling it, take a step back. But otherwise, I'd say with technology, you need to care about "new" otherwise you will fall behind.
I still don't know how they pulled this off, and as a software engineer I've read all of the development blogs.
It is still impressive that you can scale this thing to huge mega-bases, with things smoothly gliding down coveyer belts, inserters swinging, bots flying around, trains everywhere, biters doing biter things all over the exposed (essentially endless) map ... and no problem in most cases.
60 FPS/UPS.
It almost seems as if the entire thing is written in handcrafted assembly compared to how other games perform.
I'm sure parts of it are.
I had over 500 hours in Factorio before I felt comfortable with signalling. I got so frusturated with it originally I just ignored it as best I could.
But the "chain in, rail out" thing as others are mentioning really is the key. It's not always as perfectly simple as that, but it's a very good starting point.
You break everything up into blocks ... if you place a chain signal right before an intersection and a rail signal on the way out, you'll be there for most situations.
Most.
My most complex map has about 50 trains running and all intersecting each other and so far, everything is running smoothly on that one. No trains slamming into each other and everything running efficiently as far as I can tell. Almost all of it is just that "chain in, rail out" thing.
It's for a very specific type of hardcore player and very few people have actually finished it.
This is the flowchart for ONE science (space) ... one. There are numerous sciences.
It's not expanding into anything, because it's infinite.
I always hear "space itself is expanding" but how does that work with topology?
When you travel in a given direction you will arrive back where you started?
Surely that "shape" or "object" or topology or whatever you want to call it has a volume, relative to something else, or it wouldn't be able to be calculated?
As you can tell, I have no idea what I'm talking about but endlessly curious on this subject.
I have also been using uBlock Origin heavily since the start.
I'm not sure I fully understand the purpose of this. If this is a Manifest V3 thing, I thought Mozilla wasn't adopting it ... so why would uBlock need to adopt it on Firefox?
I'm clearly missing something.