jwilliams

Plus, native speakers tend to use a lot more idiom. Which generally makes things much harder to understand (but arguably more fun) -- this is even quite noticeable when encountering English from different regions.

I read “Molecular Biology of the Cell” when dabbling in bioinformatics (one of the books mentioned in the article).

It’s an excellent textbook. You’ll need a base level of chemistry and biology - not two of my best subjects, But despite that I still got a lot of it.

In this case it's literally the name of the party (Liberals and Labor are the two major parties). You're correct on the economic and social axes, but that's become less distinct over the last decade.

This is an interesting debate, but I don’t think this is useful framing:

“And it’s laughable how weak the browser platform itself is.”

Which begs the question of why then do developers use web/electron?

Ubuiqity, cross-platform, distribution, updates... and, yes, some developers also prefer web api.

Perhaps the question is how do we bring a web/election experience to native apps?

In my experience this is untrue -- I've worked with many business processes that are very complex, and software hasn't even got involved yet.

More generally, the issue is that customers often do not understand which requirements lead to complexity, and which ones don't. If the software development relationship is transactional (and in Enterprise it usually is), then this leads to unmanaged complexity.

A lot of software (and processes) fail to have an "escape hatch" where exceptions are kicked out for manual intervention. Putting this in and then managing to the intervention rate is a decent way to manage complexity.

The other similar approach is to build in containers - and use Docker layers to contain the dependencies.

Same. I even regularly see a few at Coit Tower.

This is common (in principle) in Australia and the UK. Functionally you have a mortgage account and then an “offset” account that is automatically deducted (ie reduces) from interest payments.

More sophisticated accounts also include unsecured credit (credit cards). But that’s less common. Most just opt for automatic payments from the offset.

> Rule #14: Don’t take in any investors

I know order isn't emphasized in the list, but this should really be #1. Most of the other rules stem or are dependent on this one.

The opposite to exceptions isn't (necessarily) error codes. Golang errors are a recent example.

The same hardware. Miners get both a reward for mining (the fixed set of coins) as well as collecting fees. After they’re all mined, it’ll just be the fees.

Microsoft's great advantage is enterprise bundling. Not only do they already have sales relationships with every big IT shop in the world - they're selling both software and cloud (which means they can discount one or the other).

To Microsoft's credit they maximized this advantage very well.

Equally, the swastika is a common religious symbol in East Asia.

Another title is "Things users will struggle through, because your product fixes a critical, fundamental issue for them"

No snark intended. Often a product that solves a real huge pain point has it's own sharp-ish edges too.

There are reports of crows in South America using traffic to crack hard nuts. They wait for cars to stop at a traffic light, leave the hard nuts out, wait for the green light — and then collect the results on the next red.

The same birds will fly up and drop nuts to crack them. What is notable is they will fly in diminishing lower arcs to drop the nuts. It’s a precise conservation of energy.

Remarkable stuff.

There is the assumption that this is to protect the programmer -- however I feel it's much more likely it's there to protect others.

As others have pointed out, this was a systemic failure. Pointing out the individual highlights those upstream.

As an aside - in the Kim Stanley Robinson Red/Green/Blue Mars series, the tents are supported, rather than solely relying on pressure. This includes the use of aerogels (or "airgels") for the struts.

Agree, but the issue is with the article, not the title (which is directly from the source). The article even leaves off with:

> The lesson, maybe, is simple: If your phone is so much more powerful than the computers that put humanity on the moon, then why are you just staring at Instagram all day?

It's a pretty miserly take overall.

There was talk the permissions used were a bit worrying: https://www.lifehacker.com.au/2019/10/nsws-digital-driver-li...

On Google Play it included access to Calendar, Camera, Photos, Location, Storage...

I'm a reluctant user of GraphQL. I can't specify any deep technical reasons, I just prefer a lot more control over interfaces - particularly where I'm in control of both the client and server.

But. I use GraphQL. GraphQL is a whole toolchain around client-server interactions. (IMHO) It's a pain to get started using is, but then the benefits of tooling start to compound.

HTTP2 won't replace GraphQL. Perhaps a set of libraries that use HTTP2 effectively. Even then I'd be surprised if it was a huge departure from GraphQL fundamentals - but you never know.

The Pixel had (*had) the fingerprint reader on the back. For me that worked perfectly ergonomically-speaking. Plus, since it's on the back, I'd have thought it wouldn't be too difficult to have both face/fingerprint.

The subtext here is that experts are never "experts", you are constantly iterating and learning.

Yup. It's a pretty strong confound in this interpretations. You could easily flip the Mail Online headline to "People with health issues often sleep poorly".

Tightly-coupled doesn't necessarily mean you don't have contracts.

In this case, the contract is shared TypeScript types between the front and back-ends. This means you can statically verify as much as the type system allows.

API Gateway appears to be the biggest bugbear here - and it's definitely got price/overhead issues.. that I'm sure AWS will resolve.

Serverless is great if you're starting from scratch, and have flexibility with your tech stack. If not, you're better of carving off chunks that make the most sense for lambda (with the upshot that this will make your existing components simplier/faster/etc).

I think this is true today - but historically many of those suburbs (and the tram network) were very working-class.

> Also, the article makes no mention whatsoever of Melbourne, an example of LRT working very well for over a century.

For those curious about Melbourne's system - this is a train/tram map (there are plenty of buses too): https://www.railmaps.com.au/melbourn.htm

Ubiquity and scale are important drivers of the success of the network.

CDK experience has been mixed. Prior to GA it was all over the place, but it's gotten more stable now.

A lot of cloudformation quirks leak directly into CDK. And I've learned to be patient (e.g. one change at a time, roll though all environments, do adds and deletes separately...).

Right now using it is 50/50 for me. I'm assuming as more construct libraries become commonplace that will help the most (up until recently this was hamstrung by the amount of breaking changes)

Frontend - React / TypeScript

Backend - Lambda / TypeScript

Infrastructure - AWS CDK / TypeScript

Kept in a monorepo, which means tightly-coupled code-sharing between all the different components.

Definitely has it's negatives - but being in small startup (solo technical) also means lots of interruptions and chopping and changing.

Having one language, stack, and repo makes it much easier to me to start, stop, and pick things up as I go.

I saw a Lyft driver clip a car outside my house - I emailed Lyft to let them know. Provided time, registration, make/model, address.

They replied saying that was insufficient information to identify a driver. So I left a note for the damaged car and suggested they file a police report.

Lost a lot of respect for Lyft that day.