nevir

I see this too, also for engineers that have only interacted with relational dbs via ORMs & query builders

If the regime survives, it is also going to target (and murder) a whole hell of a lot of innocent civilians that it suspects aided Israel (and many/most will almost certainly be innocent). Due process is not a thing with IRGC.

By looking the account up with Google's People API - https://developers.google.com/people

They would have to verify the account is active, AND the id hasn't changed

Oh my god, I need to play SQ6 again

> because really it comes down to the frequency of data parsing into and out of the protobuf format.

Protobuf is intentionally designed to NOT require any parsing at all. Data is serialized over the wire (or stored on disk) in the same format/byte order that it is stored in memory

(Yes, that also means that it's not validated at runtime)

Or are you referencing the code we all invariably write before/after protobuf to translate into a more useful format?

Many hosting environments give you this.

For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)

Having been in this exact position multiple times now (once quite successful, others not), you should probably consider it a wash.

Unless the company hits unicorn AND your shares become liquid (secondaries don't count—you generally won't be able to sell enough shares to make a meaningful dent), you'd make just as much or more at a FAANG firm with way less risk.

Of course, I say this while not at a FAANG firm, because I prefer startup type work.

outsource all the things?

Yeah, our police force has definitely been struggling - but funding isn't the problem.

As a Seattle resident: wat? No we didn't.

One problem is performance.

(Most) GraphQL clients are optimized for relatively small/simple objects being returned, and you typically pay a cost for every single edge (not node) returned in a response / cached in memory.

It can quickly get to the point where your project is spending more time per frame processing GraphQL responses & looking data up from the cache than you spend rendering your UI

Meet, to me, is the perfect balance of functionality and simplicity (as an end user). And features like this only make that more apparent.

Zoom and Teams always frustrate me, even though they're what I use far more often.

It's too bad that video conferencing is largely a game of who has the most boxes checked - IT admins and A/V folk are the ones that need to be convinced, and Meet just doesn't ...meet... their needs

I hope it's also reported as a DNS record

Publishers demand it, but don't understand it.

The platforms roll their eyes, but implement it anyway; cause it's a rounding error, and keeps publishers happy

Each "picture" in the list is rendered via css rules defined for a single div.

Lots of box shadow shenanigans, usually

Could ligatures be used to make the heads/tails automatic? (e.g. first letter of any word is rendered as a head, last letter always a tail)

Iran maybe?

What are the chances that the ~60 bytes are going to push the request over the frame size and end up splitting into another packet?

Readability is a billion times more important than visual design for presentations…

…and I'd argue that a lot (but not all) of the examples here harm readability: drawing your attention away from content, etc

Visual design is certainly important to make a memorable presentation—but you really need to start from the foundations, and then layer visual design on top.

It won't take long for the interest in it to bump it to the top.

Here are some reasons for using UUIDs; not apply to all businesses:

- client-side generation (e.g. can reduce complexity when doing complex creation of data on the client side, and then some time later actually inserting it into to your db)

- sequential ids leak competitive information: https://en.wikipedia.org/wiki/German_tank_problem

- Global identification (being able to look up an unknown thing by just an id - very useful in log searching / admin dashboards / customer support tools)

Consider this approach:

<form> <button formaction="https://your/destination">Clicky!</button> </form>

Oh, lol, I totally forgot about those technical limitations! We couldn't even have done it if we wanted to.

Also hi :) long time!

The US courts thought so, too.

https://www.google.com/amp/s/amp.theguardian.com/technology/...

Here's a little story / timeline from 2009-2010 (from my perspective as a dev on Kindle for iOS):

* we submit the Kindle app ...including an in-app bookstore... to Apple for initial app review

(Note: multiple ebook readers with in-app bookstores are already on the app store at this point)

* several weeks pass with no response

* Apple announces in-app purchasing (to be released several months later)

* Apple rejects our app: we have to give them a 30% cut of all sales through the app, or remove the store and all references / external links to it. We chose option 2.

* Apple forces the other ereader apps to remove their stores or go with IAP. Several (most?) just gave up and pulled their apps entirely

* Apple negotiates agreements with most of the major book publishers that if they want to sell books on iBooks, ebooks must be listed at the same price on ALL stores, and have a 30% margin

* Apple launches in-app purchasing and the iBooks store (with the iPad announcement, IIRC)

...aka even if we (or any other ereader app) wanted to sell books via our app, the terms Apple set forth effectively meant that ALL profit from those sales must go to them (and we would have to eat the bandwidth / service costs on top of that)

Also consider that in some cultures, people have no last name, or multiple last names.

Have one input: "What should we call you?"

and, if you really need it: "your full name"

5k x 2k has been worth every penny

The description is glorious:

---

A Brainfuck interpreter written in PostScript

This program aims at being accurate, readable and minimal.

FWIW, that's typically the structure that Amazon is looking for in an interview (though, some interviewers are better/worse than others)

- start with the super inefficient solution, solve it pretty quickly

- point out performance problems or edge cases that would need to be solved for a larger scale solution

- go implement those optimizations

These days, batching DOM updates doesn't give you as big of a win as it did in the past (browser tech has improved, browser engines do more batching under the covers, etc).

Also web components tend to use more modern layers of the web stack (style isolation, shadow DOM, etc) - which allow the browser to perform more optimizations, as well. I think we'll find that they become more performant over time. Also consider that some "native" html components are effectively implemented the same way as web components these days.

Often you'll find that React/etc are perf hits (vs finely tuned components) because their declarative nature tends to lead to unnecessary work …which is totally fine 99% of the time, because the productivity win from that is HUGE.