190 karma · joined November 4, 2019
If Apple supported the beforeinstallprompt event (available in Chrome since 2015) then people would have same experience as installing app [0]. Instead, you must create a wrapper around webpage and submit thru App Store.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Window/befo...
const D = new Temporal()
const t = new Interval({minutes:5})
const v = D.add(t)Simple realization. Big payoff
> You may be surprised to know that, when doing a "conventional" CC transaction, you are most certainly not giving any stranger information that would allow them to perform a transaction in your name on another merchant.
How do you know as a client the merchant doesn’t have a skimmer embedded in their payment page? Or that they don’t post directly to their servers (whether accidentally or not)? Are the PCI police going to catch them? Maybe they want to store cards to process later and don’t know or care about pci.
The problem is using the same details for every transaction in a loosely authorized way.
In a perfect world the merchant won’t have access to the card details (like with one-time payments) and everything would go thru a provider with a preauthorized payment. But we don’t live in that world right now.
He says:
> You shouldn't share a secret that someone else could use to generate payments. You should share some type of payload that is only valid for the payment you're making.
He’s advocating for a more secure one-time way of making a payment.
It would be more secure since it’s one-time and could not be reused even if the merchant didn’t use a pci compliant design
No. In best case, you’re giving your payment details to a PSP. A couple years ago NewEgg had a javascript skimmer on their checkout page that harvested all their customers payment details for months. Obviously anyone with access and intent could do the same for any payment page.
Sample data:
CREATE TABLE users (user_id serial, name text);
CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id;
INSERT INTO users VALUES (1, 'Bob');
INSERT INTO users VALUES (2, 'Sally');
sqlite> .schema
CREATE TABLE users (user_id serial, name text);
CREATE TABLE comments (comment_id serial, user_id int, comment text unique);
CREATE VIEW user_comment_view as select u.user_id, u.name, c.comment from users u, comments c where u.user_id = c.user_id
/* user_comment_view(user_id,comment) */;
sqlite> .schema users
CREATE TABLE users (user_id serial, name text);
sqlite> select * from users;
1|Bob
2|Sally
test=# \d
List of relations
Schema | Name | Type | Owner
--------+-------------------------+----------+----------
public | comments | table | postgres
public | comments_comment_id_seq | sequence | postgres
public | user_comment_view | view | postgres
public | users | table | postgres
public | users_user_id_seq | sequence | postgres
(5 rows)
test=# \d users
Table "public.users"
Column | Type | Collation | Nullable | Default
---------+---------+-----------+----------+----------------------------------------
user_id | integer | | not null | nextval('users_user_id_seq'::regclass)
name | text | | |
test=# select * from users;
user_id | name
---------+-------
1 | Bob
2 | Sally
(2 rows)
Typescript, as the name implies, adds types to your script. If you don’t see the benefits of types then typescript may not be for you.
> My issue is with the amount of extra work it places on developers… and doesn't deliver all that much value.
If you think adding types doesn't add much value then typescript may not be for you. In my experience, types are defined once then provide a lifetime of value.
> you are at the whim of TypeScript developers and how they decide to progress with the language.
This is true of any library, programming language, operating system, hardware, etc. But adding types isn’t somewhere I’d worry about backward compatibility being broken. All the newer versions of typescript are backward compatible. If you have a library that requires a newer version of ts then upgrading ts won’t break anything dependent on earlier versions.
I'm sure Meta's legal team would find reasons why they wouldn't have to be responsive or other ways narrow the scope. SimulaVR in turn could use the same arguments against Meta.
Wondering if anyone else can confirm faster builds with it hidden?
Exactly. Telemetry can be a useful like you said and should be clear to users when they are being opted into it. Especially if someone has disabled all telemetry, they should be prompted to enable it or configure it with the new settings. If you silently re-enable it on their device when they already went thru the trouble of disabling it (and not expecting the settings to change day-to-day), you'll get some knee-jerk assumptions and reactions, whether your intentions where noble or not.
Couple thoughts:
- You should let the user know the goal of the demo before they start it, for example, "Let's build a query of Users by Country and Export it to Google Docs" and indicate their progress through the demo (eg, Step 1 of 5) with a caption of the action they are taking at the bottom of the screen that reinforces the previous bubble. Like:
- Step 1: Let's build a query of Users by Country
- Step 2: Here our Users by Country is shown as a bar graph. Let's change it to a Table View
- Step 3: We have 14 users in the UK. Let's check the underlying results
- Step 4: Let's export the results to Google Docs
- Step 5: Here's our result exported to Google Docs
String.prototype.replaceAll = function (n, sub) {
let t, f = "g";
if (n instanceof RegExp) {
t = n.source;
f = n.flags;
if (!f.includes("g"))
f += "g";
} else {
t = RegExp.escape(n);
}
let r = new RegExp(t, f);
return this.replace(r, sub || "");
}