BinaryIdiot

For sure. Even when they went online the experience was _bad_. Ordering would almost never ship when it said it would and one time I ordered something for pick-up at a store and when I got to the store an employee their said another employee took the tags off of what I purchased and sold it to a customer.

They missed the internet and when they tried to get into it, they just failed at every turn.

> They're a real estate company.

Are they, though? Their CEO owns another company that buys up properties and then WeWork rents to them. I don't know how much real estate WeWork owns anymore. Though I think you're closer calling them that than a tech company.

> it reinforces a false narrative that tech companies are bullshit.

They're not a tech company tho...

> I can't wait for RCS messaging. I'm honestly wondering it Apple will support it, or try to segment the text messaging market even more.

I mean, RCS is practically dead (at least in the USA). But even if it does come it'll basically replace SMS with something slightly better. I don't see how it addresses the iMessage stuff. iMessage will likely still send much higher quality images and videos and RCS, AFAIK, can't do some the same features like showing who's typing.

RCS is cool but I don't think it's going to be a game changer in any way. I think it'll just be an incremental update, if it even comes to the USA.

They do not [usually]. This patent was rejected and abandoned.

I own a Surface Book 2 and a Surface Laptop 2. Both are amazing but I find the Laptop 2's keyboard better because of the fabric on it (which sounds bizarre).

Either way, except for some Windows annoyances I really don't miss my MacBooks.

This is what I've always done. Develop using a few dependencies, freeze, continue development with reproducible builds. It has always included the sub-dependencies in the list so, as far as I can tell, this works great for that case...

I'm not sure about conflict resolution when but I run a pip freeze it adds TONS of dependencies outside of the 2-3 I had in my app because those were the dependencies of my dependencies.

When you setup an S3 bucket the permissions are pretty explicit. The issue here is the UI is confusing (arguably it's wrong but I digress) and is related to a configuration that you'd have to hunt for. It's not an obvious permission that you can easily know it should be changed unless you have experience with it (whereas S3 it's listed right there when you created it and by default it's pretty private).

> That courier was full of shit. You get paid regardless of customer status, and you also get paid per minute over a certain delay threshold. Sounds like you just got a bad actor.

I mean, that's basically what he said but that it had been an hour and a half (IIRC) and he said Courier would stop paying him to wait.

I've never been a courier so I wouldn't know.

It's funny, I know almost no two people with similar experiences (user or courier).

For example as a user I have literally never had a good experience with Caviar. It almost always wrong in different ways.

As a courier one time the guy called and said that the restaurant was taking so long that Caviar would no longer pay him to wait so we ended up paying him out of pocket to cover it (he said we could cancel and get our money back but that he'd also get nothing after waiting for a very long time).

Uber Eats, as a user, has usually worked pretty well. As a courier one of them told us they constantly have out of date restaurant menus, people order from them, the restaurant substitutes or ignores it completely and now they have to deal with an angry person.

It really feels like restaurants are not equipped to handle these types of services and all of the services don't train their people if at all, as well as treating them kinda like crap many times.

Thank you, that is very helpful. I wish Apple included some sort of message conveying that information in their permission pop-up.

> But then you've basically just built a graphQL api

Not really. The type of API where you specify what you want and the API itself included whatever data you need in an RPC fashion has been around for decades, I feel weird calling it a "graphql api".

Ultimately GraphQL gives you some tools. The developer just has to figure out if those tools make up for the additional overhead (processing, size, training, etc). Sometimes it'll be justified I just think more often then not it really isn't.

This. Even is Boeing had to drop out of the airplane game _entirely_, they have a ton of other lines of business.

If another 737 Max crashed then that would be the end of the Max, IMO, but I doubt older 737s would be dropped and Boeing would still be around easily enough.

I suspect your take is correct but I understand the alarm from the previous poster as the way it's worded makes it sound like they'll look just for condition X, Y and Z and _then_ take action versus your explanation which looks for a lot of incoming, bad data and then handles it.

This might just be a bad case of people talking past one another.

> 1. Fewer API round trips compared to REST.

Why? This is always my chief complaint about GraphQL: there is no reason it should take fewer trips than directly hitting an endpoint unless you're structuring everything very rest-y in which case you're doing it wrong and GraphQL is a bandaid (and you'd still probably make the same amount of trips unless you're heavily caching things). IMO.

> 2. Clients only download the data they need.

Most third party APIs let you specify what fields you want via a query string or post variable which amounts to the same thing.

Honestly I think if people stopped trying to force REST into everything and just made RPC like calls to HTTP we'd have far less of a need for GraphQL.

Don't get me wrong, I still think GraphQL is pretty cool for third party access in some respects but I don't think it's as useful as a lot of people make it out to be.

Right? I don't even understand when I should or shouldn't allow bluetooth access. Does this mean things won't work with my headphones? Almost all of my apps have requested it!

I wish Apple did a little more user training as to _what_ this means instead of a generic "let app use bluetooth?"

> heavy constricting belt on a still-developing cranium

How tight are you making the VR headset? Whatever tightness you're using might be a bit much if you consider it "heavy constricting".

> We don’t share tech stacks, but we do work together, and as you can imagine that leads to wasted resources. We’re a C# shop our direct neighbour does PHP, because of limited resources, we can’t utilise each others projects. That’s just a silly waste. Good luck convincing anyone to change their overall and often cohesive strategy for tech choices though.

One suggestion, if you don't mind. When I did work for the DoD as a contractor, because of small business rules in government contracting we were pretty much forced to work with at least 10 other companies and all of them had their own preferences for tech stacks, their own expertise, etc. So we tried to go down the road of using things like thirft or avro so regardless of what language / stack you used, as long as you could interface with those on the same network (since we're talking about inter-service communication here) it was still pretty quick.

It's not ideal but sometimes you gotta work with what you have. Sometimes you can find unique ways to bridge gaps across platforms to re-use work. One time a group we worked with tried to use a web app with multiple iframes as the communication bridge between stacks. It _worked_ but it was pretty hacky and slow.

Depends on the problem you're talking about. Slack made their memory usage considerably worse due to poor programming so that's obviously an issue. But that also doesn't negate the other issues electron brings.

Personally I would have used those years of development time to go native but it is what it is.

Yes. The biggest change here is moving away from direct DOM API usage to React and not having multiple instances of a browser window inside of electron.

Considering this took _two years_ it's kinda incredible they couldn't rewrite it natively in that amount of time or less. I'm guessing the only reason this took two years is due to the incremental approach they initially took.

I had no idea this was how QuickBooks even worked in the cloud. Could Intuit be in any way liable (like is this a sort of franchise type of thing)? Or is it closer to Word Press where different companies can install "QuickBooks Cloud" and then offer it?

Correct. Now, I highly doubt they'd do it, but Amazon could take some action such as banning you from their services until you return the item. At which point do you want to own the item more than using Amazon? Could be a tough choice for some.

Though I still don't think they'd do that.

Yes, technically the person or company who is shipping with UPS (or FedEx for that matter) can redirect shipments. Sometimes it's expensive, sometimes not so much. Regular folks receiving do not have as much control.

I've never done it personally but when I worked at Polk Audio way back in the day they had a special application that interfaced with UPS and they could reroute things already in route. I don't know what the limits are, etc, but seems doable.

Having said that I doubt they'll do it once it's out the door.

Sounds like an interesting blog series. I'd love to know more about how Microsoft uses rust today and how they plan on using it in the future.

It would be really cool to be able to download a crate, created by Microsoft, that allowed you to hook into, say, the Win32 API in a rust way (or maybe a more modern API I'm just looking for an easy setup to start making Windows GUI apps in a rust-way).

You're comparing good / competent developers with developers who are either new or incompetent.

Being good at your job doesn't mean you're a "10x engineer".

> But I can say without a doubt that I have met a small handful of people who are many, many times more productive than ordinary developers.

I've met a few developers like this. These developers can get tasks done _faster_ than anyone else, guaranteed. But I have never seen one that can do that _and_ produce quality.

Sure, anecdotal, but if you're getting something done considerably faster than others yeah you could just be _better_ than them, but that's unlikely the whole story. You're likely not getting good (if any) tests, good architecture decisions (maintainability), etc.

10x developers may well exist if we're only talking about speed but I have never met one who was a net positive overall (unless we're simply talking about people who are "productive" or "more productive than their peers" but I'd argue that's completely different than what was meant by 10x).

Hell, I have even been called a 10x engineer before by a manager who was trying to get me to work over 80 hours a week. And you know what? It worked. I felt like I was the best, my shit didn't stink, I was getting more tasks done than anyone else, and the entire time I was killing myself to do it. I slowed down a bit for about a month when I had to learn something new and I was fired after working with these same people for 5 years.

"10x engineer" is a marketing gimmick used to gain leverage in various ways, IMO.

> What are these native languages you speak of?

Really any of them. Swift UI is the only example I can think of where a group of folks are working on making UI easy and intuitive to create and manage inside of a native language.

Why is there not an effort to make something as intuitive in C++ or GO or Rust? C++ would probably be the hardest one, sure, and there are many UI frameworks for all of these languages but none of them are as simple or intuitive as Swift UI or how React / Vue works inside of JS.

I'd love to see some more experimentation in ways of building UI in native languages. Heck, even in managed languages like C# or Java they could use the same type of treatment.

> What functionality can be left out of Hermes as compared to JSC/V8 in order to shrink its sie?

At the moment Hermes isn't compatible with ES6 (it's missing a lot of stuff). Perhaps, since part of the build step for RN anyway is transpiling, they don't need to provide all of ECMA's features. ES5 is more simple, less complex so I wonder if some performance can be had there.

But since they are building an engine strictly for making native apps using JS, there may be shortcuts or other stuff they can drop that JSC/V8 normally have to worry about but that's just speculation.

I'd love to see more info addressing your questions!

This is what I always go back to. We have so many smart engineers working on ways to interpret JS to interact with native components and try to tighten that loop to make it faster. Why is there not a large movement to just make UI development in native languages better? Like, Swift UI looks great but it appears to be a huge exception to what everyone else wants to do.

I'd love to see more work go towards making cross platform UI easier to do in native languages. I feel like you could get a lot more mileage out of that, especially if you add WASM as a compilation target, then you can get the same ubiquity that JS has.