It's all custom; the frontend is React and the backend is Ruby. Our plan is to introduce Markdoc as an intermediary step to improve the authoring experience.
Just to add to that, "normal" markdown (I forget which flavor exactly) is currently used for the text blocks within the Stripe API reference documentation.
Your Thunderbolt cables don't have the lightening bolt logo on them? I didn't think it was a 'requirement' but every TB cable I've seen always has the thunderbolt icon.
Would add https://useyourloaf.com to your list. Great WWDC summaries, amazing auto-layout content, and just in general one of the better written Swift resources out there. I find things are written in more of a 'production ready' way instead of strictly for a tutorial. Check it out!
Does a "delegated type" work with preloading associations, ala "includes"? This remains a pain point with many polymorphic associations in Rails, but not sure how the new functionality handles if, if it does at all.
Based on this GitHub comment[0], it appears the answer is yes although it requires a little additional customization out of the box to prevent N+1 queries..
In conjunction with Rails's "russian-doll" caching, N+1 queries are (or at least, can be) a good thing.
This sounds counterintuitive; but, in the common case of read-heavy services, N ≐ 0 after the first access. When something changes, subsequent views end up loading & rendering the one record that changed, instead of preloading an entire collection.
However, achieving this in practice requires some care in the nesting of view partials and records.
Hey, just wanted to thank you for the link. This sent me down a deep rabbit-hole of DHH interviews! I'm surprised I haven't taken notice of him before, he has so many profound insights. I am really grateful :)
You're welcome. I think he's a deceptively clear thinker, by which I mean, DHH tends to supply a correct and insightful answer without discussing all the potentially wrong ones, or even unpacking all the insights contained within. It's left as an exercise for the student to realise how any particular "road not taken" would've been inconsistent with Rails's underlying principles.
I don't mind that, since I've chosen to infer an assumption that we're all as smart as he is. (even if it does then take me years to explain things to myself...)
If you didn't find it already, his "On Writing Software Well" video series is a fascinating, and sadly abbreviated, journey into his own application code.
I’m assuming the iOS app is based heavily on GitHawk (https://github.com/GitHawkApp/GitHawk) as its developer, Ryan Nystrom, moved to Github last year. Looking forward to getting in the beta!
According to the App Store review guidelines update posted today, Sign In with Apple will be required for any iOS app that implements a single-sign in button.
"Sign In with Apple will be available for beta testing this summer. It will be required as an option for users in apps that support third-party sign-in when it is commercially available later this year."
This is Apple sensing weakness and dropping a bomb right on facebook’s doorstep. And they sidestep the anticompetitive angle by arguing that instant anonymous sign on is simply a better UX, which it is.
It is an incredibly bold move. Just as tech monopoly power comes under scrutiny--in Apple's case the AppStore--they wield said monopoly power...but for a seemingly good cause.
Lol, I doubt it. Apple is years late and sucks at doing the leg work of getting third parties to adopt its suck. Look at Apple Pay which was launched at the perfect time.
Great 1% of online stores supports it. I am sure only a fraction of that traffic actually uses apple pay. You are comparing it to google pay that had a terrible UX and like four conflicting versions. They had to catch up to apple pay once it launched. Apple had the perfect product at the perfect time. They complete wasted the US chip switchover. They could have dominated retail purchases.
Practically any point-of-sale that supports NFC also supports Apple Pay. Adoption rates may vary by region but NFC penetration is very good where I live.
I have switched almost exclusively to Apple Pay, and frequent only one chain of gas station because they rolled out NFC at all of their pumps last year. After the introduction of chip readers gas pump mag stripe readers became the main vector for card skimming in my area and even with the security stickers all of the gas stations have been putting on their pumps I don't trust any mag reader anymore.
At locations that don't have an Apple Pay logo on their card readers, like my local movie theater, I have spied the NFC logo and given it a try and it works.
Except for Amazon, almost all of my online shopping is now done through Apple Pay. I have a shirt out for delivery today from a small retailer I had never heard of before that I purchased with one click and a fingerprint via Apple Pay.
It has not only changed how I buy things, but how I dress. Instead of my George Costanza wallet I only carry an ID and two cards in a slim front pocket wallet, relying on Apple Pay for almost everything and walking out of a store if they are cash-only or don't support chip/NFC.
Regardless of your chosen NFC platform, I recommend that everyone use it and shun points of sale that don't have it.
Apple Pay has been my primary payment method since the day it launched in the UK.
Fortunately, most payment terminals in London already supported NFC payments thanks to NFC debit and credit cards long being prevalent here, and Apple Pay is just tokenised NFC payments.
Same is true of literally every iPhone owner I know, and usage simply increased as payment limits went from £20 to £30 to unlimited (unlimited on Apple Pay, but still limited to £30 on NFC cards or when using older payment terminals).
Plus I got to ditch my oyster card and just use weekly fare capping after a while too. Good times.
I use Apple Pay for almost all my purchases in Singapore, where almost ~80% of merchant terminals support it. Recently, Singapore's train system started allowing Apple Pay payments at the turnstiles. Using the Apple Watch at the turnstiles without having to fumble for the stored value card is amazing.
Even the existing Sign In with Facebook is implemented terribly by many apps, e.g. requiring me to enter my password in app instead of calling out to the Facebook app like maybe 50 of apps support properly.
I think honestly this comes from apps that are built with cross platform frameworks but its still frustrating.
Further more it drives me crazy new apps (and websites) released this year focused on mobile (e.g. pay for fuel at a fuel station with your phone) and I can't even auto complete the credit card or name using the new keyboard extensions because they somehow labelled the forms in a way apple can't figure out.
I'm really curious to see if this impacts enterprise apps that are configured by an administrator to use an internal SSO provider, or if this only applies to apps that allow users to sign up.
For example, Slack can be (and is often) configured to use Okta or some other SSO provider. Does the Slack app have to implement some kind of support for Apple Sign In when such use cases are involved?
Apple have always had excellent Enterprise support on iOS, including "private apps" and what not. There is no reason to believe the same exception wouldn't be extended to Enterprise Devices and Apps.
Therefore, anyone offering Facebook/Google login will also have to accept Apple's anonymized forwarded email addresses, like fc452bd5ea@privaterelay.appleid.com.
But this explicitly doesn’t work as an SSO. How can I tie that back to the actual email address they would have used to create an account using their FB / Google account?
This sounds like a tremendous headache that I really don’t want to worry about. But Apple is looking to leverage their power in the app market to force me to implement a tool I may not be interested in as a merchant?
I despise being strong armed. I hope the EU crushes this.
It seems the email part is optional (ie you can choose to share your verified email with the company if you want).
The above scenario goes against what they are trying to achieve though
1) If you support SSO and email/password - then the email and password are still stored (and possibly not hashed and salted if the developer is incompetent) - so you are at risk of compromise if you reuse passwords
2) If you store the users actual email, you are putting them at risk of credential stuffing, as well as opening them up to tracking
The EU can always surprise, but I suspect they would actually like this because it addresses key risks to consumers of password reuse, credential stuffing, and tracking. Additionally it competes against their ideological targets, Facebook and Google.
EU is not picking on FB and Google specifically. This mindset is toxic. They are picking on all monopolies for European customers and have been for a long time. Basically we believe the market is not healthy if there isn’t any competition.
This is a bit rose tinted outlook. GDPR does not increase competition, the amount of regulation in EU and worker protections in place raise barriers for new competitors. France has laws that prohibit new movies from being put on Netflix in order to support local distributors etc.
Not saying what the EU does is goos or bad, but painting it as pro free market competition seems unfounded.
GDPR isn’t about addressing monopolies. It’s about addressing privacy and data ownership.
Every tech related legislation doesn’t and shouldn’t need to so,be every tech related problem. The EU has other, non GDPR related, mechanisms to handle monopoly issues.
My point is EU will adopt regulation that actively harms competition (such as GDPR), because they have different priorities (e.g. privacy, data ownership as you mentioned).
So to me it seems unfounded to say EU cares about market health and is not, in fact, just picking on FB and Google.
I am honestly curious what you think are examples of EU mechanisms fostering healthy markets. Maybe the MS case but that is the same “EU picks on US tech giant” genre.
Presumably it’s always the same address every time they sign in. It is used for single sign on after all!
However, I wish email and sms would go away as a way to authenticate. Until it does I will be using foo+aliashere@gmail.com so that my account can’t get transferred to someone else through socially engineering a tired rep.
But someone who has already signed up via FB is going to click that button and then get angry when we can’t log them into their account.
I personally don’t use FB login. And I use `+merchant` to keep track of bad actors. But from a merchant perspective this will likely be a chore. And Apple has decided that we don’t get to decide if it’s worth it. We can’t disable FB login because we’ve supported it for a long time and a ton of accounts only have a FB-synced profile.
To be clear, it’s not the product I have issue with. It’s the draconian ultimatum that because we are in bed with FB we have to also get in bed with Apple Sign In.
They could have just built this into their form system. It already recommends my personal email / credit card / auto generated password. Why not prepopulate / suggest an Apple-generated email? Why force the merchant to implement another standard which breaks all other SSO integrations _by design_?
I don’t have answers to those questions. If this was a consumer feature embedded into their keyboard I’d be ecstatic. Strong arming merchants to implement and bear the full cost of confused consumers who can’t seem to login to their app _even when they click the Apple button_ is inexplicable (to me).
"+merchant" doesn't do squat to prevent bad actors from selling your email address. Anyone so inclined to sell your address would just strip off the postfix since they know it's unnecessary per the spec.
One of the many advantages of using a hosted solution with your own domain is that you can receive email from arbitrary addresses in the same inbox. For example merchant1@inboxname.mydomain.com gets sent to my inbox at Fastmail. inboxname@mydomain.com doesn't exist, so there's no way to get my "real" email address from what I give out to merchants. If I start getting spam on an address, whoops, you and everyone you sold my email to get sent to a black hole in the cloud.
I wonder whether that's GDPR compliant. If I give you permission to contact me on me+alias@example.com and you strip off +alias and then contact me on me@example.com, you've inferred data about me I haven't explicitly given you. One could argue that's in a similar ballpark to running a geoIP lookup and then sending me mail through the post.
It seems rude (like if I told you to drop off a package at my back door and you put it by the front door), but I given the existence of RFC 5233 I don't see how this would be "data about me I haven't explicitly given you".
Also, if you try to mail people based on GeoIP data, you're going to have a bad time.
It's about permission. If I give a company a certain set of contact details, and they run some process to find other ways to contact me that seems unfair and beyond what I've given permission for. The fact that it's trival to find my real email from an alias I think is irrelevant - it's still an abuse of trust. Like I say, I can see a correlation with more invasive methods of finding other ways to contact me that I hadn't granted the company (imagine if they start contacting you on social media just because they could look up your profile from your name).
You could argue that a major feature of the GDPR is to legislate that just because a company can do something, doesn't mean it's allowed to do it.
The 'detail' is optional, and doesn't infer any privacy.
It's kind of like if you get mail delivered to:
nprateem, office 2, university of ycombinator
and instead they only store:
nprateem, university of ycombinator
Odds are, mail will still be delivered to you, but it might not come to office 2, and might come to office 1 instead. It's not what you wanted, but there's absolutely no impact to your privacy by them stripping away additional details.
If you decide you no longer want to receive email from user+detail@domain.com it's easy to set up a blacklist filter. If they circumvent that and email you at user@domain.com you've lost that alias and easy way of blacklisting them. And presumably if someone had wanted to be contacted at user@domain.com they would have provided that email in the first place. So I don't think your analogy holds.
Fair, the analogy doesn't hold onto the functions provided, but RFC 5233 is very clear that the user+detail separation does not provide any privacy protections, nor can it.
The 'user' part is still public information, as is what it's used for. There should be no expectation of privacy for information being used per specification design.
The usability trade-off is a shame, but the solution was half-baked at best, and is primarily useful when combined with privacy-sacrificing public email providers. When you have greater control of your email, distinct 'user' parts can be used, which does provide the privacy aspect desired.
we’re a B2B app, it’s unlikely a random user will sign up for our service as it’s quite expensive and contract negotiations happen before the account is activated. we also never send marketing blasts or sell (or even collect) any information about our users. we also don’t operate in any country requiring compliance with the GDPR.
> we also don’t operate in any country requiring compliance with the GDPR
You know it's nothing to do with the country you operate in but the nationalities of your customers though don't you? You could only have a presence on the moon but if you had any EU customers you'd still be bound by the GDPR AFAIK.
to avoid duplicate user signup. allowing the + would not allow me to use a unique constraint for email address on the user table and be sure an email is only used once.
Gmail ignores (or ignored?) dots on the left of the @, so some.person@gmail.com and someperson@gmail.com and s.om.e.person@gmail.com all went to the same inbox. That is gmail-specific.
Because thousands of people already have an account tied to a specific email and are going to click the Apple button and get really mad when we can’t log them in.
Apparently they want to use it, otherwise they wouldn’t, right? This way they can have the easy login using Face ID and you can use the account they already have.
You send information to the apple address, that's what its for. You can still send it invoices or a magic link, the user gets it and clicks on it, nothing is changed in that regard. The difference is they can turn off that email address and never hear from you again if that is what they want.
Stuff sent to the fake email address will be forwarded to the user’s real email address, from what I understand. So you will still be able to communicate with them.
My problem is that I don’t get to choose if your business is worth the implementation cost. Because we’re already in bed with FB we will be forced to implement. It’s the “have to” I’m arguing against, not the feature.
this is the same problem you get from any identity provider — what happens when you finally delete your facebook? — it's just more obvious with Apple. With a 97% satisfaction rate, most iPhone users don’t want to go anywhere else… but yes, if you want to stay free, you should always create credentials directly with any app or service you use, when possible.
That said, the concept of "Apple Sign-In" for Android and other platforms is an interesting one, not likely in the short term, but possible someday!
I'm speculating here, but Apple Sign-In for Android would work just fine if the sign-in process was based on an OAuth flow where the credentials are entered into a web form. From the limited details I've seen that sounds like how Apple Sign In will work.
A service supporting alternate identity providers via OAuth (Facebook, Twitter, Google, Github) via a flow like this shouldn't have trouble with Apple Sign In from a web page, iOS app, or Android app.
It is not about deleting accounts or moving over. Heavy user has multi-device setup, I use Android tablet, iPhone, Mac and sometimes PC, some appliances like Synology with bundled apps also. Nowdays even my printer has online sign in, for file sharing apps. I expect same account to work everywhere. If they provide reasonable platform-independent email solution, it may work.
Yes, but while I can choose to log in with facebook, or google, or whatever, it appears that Apple are mandating that app providers use the Apple sign-in, which means app users no longer get to choose.
Unless I'm misunderstanding what the mandatory part is.
They are mandating that if you offer any other authentication provider (e.g. Facebook, Google, etc), that you have to offer Apple sign-in as an option as well.
The option is mandatory. End users using it is optional.
If the policy is "if you offer one or more authentication providers, you must include Apple sign-in", while it's still a little harsh, I think it's much more defendable and reasonable.
Only if they grandfather existing apps. We made the decision a long time ago to support FB login. That decision now requires us to either stop having an app in iOS, remove FB login (which a good portion of people use exclusively), or implement a new authentication provider _that won't work for people that already have an account with us_.
Again, the tech is fine. The strong-arm is indefensible.
Why would someone already authenticating via an existing identity provider be affected by you adding an additional identity provider?
If you support FB login now and decided to add Google, for example, that doesn't require your existing FB users to do anything different. It should only affect new users who are creating an account and choosing to use the new provider. Wouldn't that be the same for Apple Sign In?
Note, I'm not taking a position on the strong arm tactics, just pushing back on your claim regarding existing users being affected by a new identity provider. That doesn't sound right to me.
I expect the disposable email will end up in Keychain, and you can export from there. Not the most user-friendly thing, but doable. Well, at least on a Mac.
How will this work for apps that depend on the third party for more than just identity? For instance, does an app built on Spotify's API have to include a Sign in with Apple option? Or something like CI2Go, which is an app for CircleCI, which only offers log in via GitHub or Bitbucket.
If you are built on Spotify, then the use is not signing in to your app, but to Spotify (and then authorizing your app), so it should be up to them to provide the Apple Sign In feature, I assume.
Probably Apple is hoping the entire Apple ecosystem not to be defined as "a market" in terms of antitrust laws. I am not sure if the Justice Department will agree with it though; we'll see.
If it's defined as a market, then Apple will be surely in trouble but enforcing Apple ID alone doesn't make much differences from the current situation as it always has been doing similar things for web browsers, music apps, app store itself etc. So it's pretty natural to enforce this policy for Apple; no additional risks but only benefits.
Excluding other third party sign on options would be problematic if Apple were abusing a dominant position among smartphone makers, which is not the case by any objective measure.
Leveraging their status as the controller of the platform to require support for their solution is not the same thing as their solution competing head to head with other solutions.
Note that I'm not making an argument about how to classify the behavior legally, I'm arguing that calling it "competing" is pretty generous.
The trouble here is the definition of "market". Apple's ecosystem (which Apple has an absolute control on) doesn't seem to be very safe from being defined as a sole market since there's no viable substitute to the app store for Apple users.
For instance, even if Apple decides to increase the app store fee to 50% so its app's prices as well, still consumers don't have much choice since buying a new phone is typically more expensive by order of magnitude than buying an app. This is also a part of Spotify's claim as well and Apple is trying to defend itself for this time unlike Apple v. Pepper.
I already have explained; there's no alternative to iOS for apple mobile devices unless you're willing to pay more than $500 for an equivalent level of android device. If Apple allows Android to be installed to Apple devices, then things can be different though.
In fact software monopolies on hardware isn't pretty much the standard, it's a universal reality in just about all consumer products except one—the personal computer. And even then it's exceedingly rare for a consumer to deviate from the shipped software.
"Dominant player" isn't especially relevant in European market law. Essentially the test is that you are of sufficient import to materially affect pricing in that market, which Apple definitely is.
Yes it is anticompetitive. It is using Apple’s monopoly as gatekeeper of their app store.
Apple would have long ago been cited for Antitrust if Android hadn’t had most of the market. I personally think that the definition of a trust is too narrow — one member of an oligopoly abusing its position as a platform provider and strongarming people is also pretty bad.
That’s not how antitrust law works. It’s not a test of whether a company exerts too much control over its own customers. It’s a test of whether customers have some alternatives and a real opportunity to vote with their dollars.
Apple has argued that developers are its customers (in the Pepper lawsuit). What options do developers have? Ignore the iOS market (those most likely to pay money)? There isn't a choice here: you let Apple have 1/3 of all of your revenue and you implement Apple Sign In. Because... competition?...
Antitrust is among the most mature areas of law, in terms of how these concepts have been thoughtfully wrangled over. I definitely encourage you to dig deep on how market scope is determined, if that’s interesting to you. There are many ways to manipulate a market but very few rise to the level of requiring state or regional government intervention.
Twitterrific is on sale right now in the Mac App Store for eight bucks. Both it and Tweetbot are great native Mac Twitter apps and are so much better than the web interface.
Oh I understand the style, I just think it's backwards. The whole point of CSS is to move the styling out of the markup, and this obviously fails atrociously in that regard.
Each class is one CSS property, where it would be literally less verbose to just inline them. It's exactly the same thing as doing style="prop: value; prop: value;" since to change a given area of text from grey to black you'd have to edit every single element the same way.
