jwilliams

Australia has the Telstra "4GX" and Optus "4G plus" networks - it's AU 4G with its own spectrum and band aggregation.

I have seen gigabit speeds on 4GX - once, when it was new and the spectrum was hardly used.

Since the reports are quoting real world maximums, I'm sure that number is true - but doesn't reflect your average experience.

My mistake - I meant to say "coming out of". I got the very first of the 2016 (and the touchbar) models.

I know this topic has been done to death on HN, but this remains a persistent concern.

I've had two keyboard replacements. If you haven't had it done, it's a "topcase" replacement - which involved a good half of the machine. It's a big change and I was told to allow for 5 business days as well.

My Macbook Pro is out of the 4 year replacement window - and the Spacebar is starting to fail.

I've owned every form-factor of the Macbook Pro - won't be next time round.

I was pretty against electric stoves, but just moved into a place with a modern induction setup. Extremely impressed. It can boil water amazingly quickly and the exact heat control is great. I do miss the ability to char things, but not massively.

Succulents and semi-succulents effectively do this. The one that sprung to mind was the Baobab tree, which stores up to 120,000 litres (https://en.wikipedia.org/wiki/Adansonia)

You know more than the source and destination for a transaction - you know the entire chain of custody for any flow of value.

Governments are very certainly tracking this. With augmentation and pattern matching, they will know quite a bit.

I didn't mention canonicalization. My point is that serialized JSON is ordered - which I think is exactly the same property you're referring to.

I think my argument is a bit different -- sure, this is an interface (maybe to a COBOL copybook in this case?). And yes, it's not "JSON".

Agree it's a leaky abstraction. Equally agree it should be documented. Often legacy systems have weirdness after seeing decades of edge-cases. Weirdness that makes them robust in all sorts of unlikely ways. Equally makes them poorly documented, leaky, opaque, and frustrating.

But I certainly have a lot of pause with the sentiment of "some idiot checked the JSON order checkbox on DataPower". My first thought is instead "I wonder why someone thought this was necessary."

(I've used both DataPower and COBOL - I've got a healthy respect for robust, long-lived legacy systems).

I must admit I was scratching my head on this.

The JSON spec might not specify order, but the serialized JSON is ordered by nature. JWT needs it for example (and I'd assume many signature models). Or you might have a caching layer that needs it. Maybe unchecking this causes the legacy backend to get hammered? There are valid non-spec concerns with order.

Replies here seem to assume stupidity here. It's a valid reason, but it's not the only one. Equally, the author doesn't ask "why" - why would it take so long, why was that option enabled?

> Although this one I find infuriating because Google doesn't know how to correctly round off exchange rates

I generally search for "1000 USD in AUD" as a workaround.

Actually agree -- but with some nuance.

I think this would be true if the race condition was in my own code, but doing this against another codebase would be pretty brutal...

Part of the reason Flexbox/DOM is painful is that it's very much "someone else's view/code/logic/etc."

I think there is the other more sarcastic case too - being "I could, but I'm not". Especially the case if the "yeah" is drawn out.

Shall we help Dave move his fridge up four flights of stairs? "Yeah.... nah".

I feel like we might be diverging on what "a general purpose web app" represents.

I've never really seen those issues unless there is a more extreme circumstance.

In my read of "web app", in most cases you want to push/data in and out of the database. And modelling 1:1 and 1:n relationships is pretty natural in my experience. Deeply nested relationships are a pain, but they're usually a pain in SQL too. Document-orientation helps here a bit, but with some drawbacks. Where I think it does fall over completely is analytics, and OLAP-like work.

I guess hotspots can be an issue. However, that implies considerable related transaction volume, which I'd argue DynamoDB can excel at.

If you're using a framework like Rails - then sure, DynamoDB is out. But so is Lambda. The pattern of SPA (React/etc), Lambda, and DynamoDB is what's emerging instead of those frameworks. Definitely agree it can't cover many cases, but covers a lot of ground for me

It's relatively common in embedded programming (in my experience). A lot of real-time programming is around scheduling. You certainly can use formal proofs there too, but statistical methods would be common at significant scale.

What makes DynamoDB a bad choice for a web app? Seems to be where it excels.

I wasn't being specific enough - I meant expensive in the most general sense. e.g. An abstraction is a cost not only in terms of (potential) performance, but developer headspace, etc, etc.

The right number of abstractions is very powerful. Too many any you'll sink under the weight of them.

I wouldn't say it's meaningless. These types of technologies are usually arbitraged out; ending up with a few large players that are squeezing out a return.

It means high frequency volatility is taken out of the equation for the rest of us -- Which generally is a benefit for other players in the market.

FX has (effectively) been that way for a long time.

I see what you're saying - for me, my experience with Java checked exceptions put me off the idea.

In Java it led to lots of exception wrapping and leaky abstractions.

Not sure what the answer is - although my golang experience was better.

Eons ago as an embedded programmer I came to respect Forth. I encountered numerous situations where using Forth led to a much smaller footprint (size in particular) -- Why? For exactly the reasons that Chuck Moore espouses here; you are writing a purpose-built VM from the hardware up.

Even then I don't agree that portability/abstraction isn't important - it's got the potential to be an extremely reductionist position. Instead I'd argue it's incredibly expensive and should be treated as such.

Good read. There are a few things that I'd throw on top as important;

- Active monitoring

- Chaos testing

- Cold start testing

In the book "tents" euphemistically refers to tenting that encloses small towns. Also the tent fabric was a multi-layered thing (one layer was to absorb some radiation). Imagine this is why supports were seen as necessary.

Aerogels are mentioned in both Red and Green Mars - Mostly as pillars for the tents, but KSR mentions "airgels" (spelling in my copy) as an insulation layer in the tent material too.

Yes, I've heard of days getting cut - and many extra-circular programs too. Even in extreme-affluent parts of Silicon Valley.

Often due to the ubiquity of private schools, property taxes aren't funneled effectively to public schools. So funding can be very patchy.

Moving specifically back to SF, the system is also a lottery[1].

1: https://www.kqed.org/news/11641238/how-the-san-francisco-sch...

> How do I work at a Silicon Valley startup that wants to hire me, if I'm an EU citizen with no degree and 5 years of work experience?

It'll be tough for sure. And depends on what the startup is prepared to do. Have you spoken to an immigration attorney? https://news.ycombinator.com/user?id=proberts does AMAs on here regularly and it might be worth contacting his firm for advice (also take a look through his AMAs).

Things I've seen work:

- Work remote, visit SV regularly for work. To be frank, I think that can be the best of both worlds. But YMMV.

- If you work for an overseas subsidiary for over a year, you can try for L-1 to transfer to the US. Generally the "startup" needs to be big (big) for this to be practical. You don't outright need a degree, but 5-years experience is probably on the lower end. If SV is your dream, it might be a case of finding a bigco startup that is prepared to do this. A stepping stone might be working for one of them in the EU first (e.g. Dublin in particular has plenty of satellite offices for SV companies).

- There are other options like the O-1 and H1-B, but these are extremely competitive. Again, immigration lawyer would have a better idea.

In all cases I'd probably give Peter a try first.

To be honest, I've rarely seen this work well outside of Google.

Part of it is how the goals are translated. A business outcome trickles down to a specific technical one -- and a specific team and person -- which on the face of it makes sense, but it's surprising how often pursing that that derived outcome totally loses sight of the big picture.

It's similarly hard to map backwards, which can lead to a lot of the company feeling "mission accomplished", when the objective was still a total miss. That's a painful disconnect to have happen.

In fact it makes it just slightly worse, as deleting cookies potentially logs the user out of other services (some of which require Google).

I'm just jumping into TypeScript after a decent break from production coding. Prior to this break it was Rails, well before that Java.

In my own Hades moment -- Microsoft know how to build great developer tools. The developer ergonomics of TypeScript and Visual Studio Code are excellent. It's really quite surprising to see how far the JavaScript world has come.

Similarly, the DevOps world is becoming much (much) more JavaScript friendly. Serverless, Netlify, and things like AWS Amplify -- all with their foibles, but pushing JavaScript in meaningful ways. I don't think this is the case for many other languages/ecosystems.

Off the top of my head I’d add Lifx and Nuraphone.

Well that's a different way of saying a similar thing.

In that case you're assuming that 80% of engineers should be male - which is a different argument than what was put forward.

If you reduce your argument to the merits of each unique individual hire, then you're going to miss what is a very big and complex system.

If your argument is that all 15 of these employees gained employment on their attributes completely independent of gender -- and that gender plays no part -- then it should strike you as statistically improbable that all 15 would be men.

To me that seems outlandish to ignore. Clearly there must be some biases that lead to such a bifurcated outcome.

OR your argument is that men and women are different for some reason, which led to this situation. If that's your argument then you should make that argument.