I run a $3m/yr startup on a free tier Cloudflare account. To this day I have no idea why Cloudflare is not charging us for anything. I would have happily paid them for their service
289 karma · joined September 30, 2022
1. NEVER RIDE ON THE SIDEWALK. Cars on the street cannot see you due to other parked cars and WILL make right or left turn on you. Additionaly, cars coming out of parking lots won't see you on the sidewalk.
2. NEVER RIDE ON OPPOSITE SIDE. Ride on the same direction as cars, make yourself visible.
3. INDICATE ALL TURNS WITH HAND SIGNALS. Be predictable. Don't just turn or otherwise behave unpredictably. Indicate turns, make eye contact and then turn.
4. (Obvious) ACT LIKE A CAR AND DON'T RUN LIGHTS.
* I would never assume the AI answer to a consequential problem to be authoritative, unless it shows me the source and I can click on the link to verify the source and the data presented (search engine use case).
* Rewrites with AI are bug-prone and often produce hard to trace bugs to the seemingly correct nature of these bugs. Generating the scaffolding works super well.
* Images are often too smooth, videos too robotic and rhythmic, water too shiny, etc. Trained eyes can easily distinguish between AI and real.
* Hallucinations are commonplace.
If they were issued for IP addresses they would have to reissue the certificate every time they spun up a new server. Also it's why if you spin up another server and make DNS point google.com to that server, it would not pass verification since the certificate you will be using on that server is not issued to *.google.com, but rather some other domain you own. The IP address plays no role in certificates.
The complexity is very manageable, a decent Java, Objective-C or .NET developer can pick it up in less than a day, is feature-packed and stuff just make sense.
Now, I understand there's probably a lot more to it which is why I would expect it to be a company of around 50 engineers and 150 business/marketing/etc and that's being generous.
The hill I'd die on is that, with money not being a scarce resource and a technically feasible challenge present, a team of 200 should be able to build and sustain almost anything in the world. And that's being even generous. I think realistically a team of 50 should be able to build almost anything
Now, I understand there's probably a lot more to it which is why I would expect it to be a company of around 50 engineers and 150 business/marketing/etc and that's being generous.
The hill I'd die on is that, with money not being a scarce resource and a technically feasible challenge present, a team of 200 should be able to build and sustain almost anything in the world. And that's being even generous. I think realistically a team of 50 should be able to build almost anything
But in rental market, the demand is not dynamic. You HAVE to get an apartment to live in once your lease is up. If 80% of the complexes around you are on this and on top of that the independents also set their pricing based on the market controlled by the majority, then they can charge you whatever they want. You HAVE to buy and you HAVE to get it with the price dictated by them. There is absolutely no supply and demand in this at play.
When you're talking about Google products, fragmentation comes built-in as expected. There is no reason for 3 versions of maps to exist within Google ecosystem but I don't think they really care
Sure, you are ~allowed~ to begin an immediate descent in an emergency, but it is not a good idea considering from the pilot's perspective, the bang is most likely an engine going out and altitude is always your friend in this condition.
Apple really needs to justify this spending to the end user by having more convincing use cases than watching movies in it.
If I was Apple, I would offer extreme incentives for developers with a proven track record on the App Store, going even as far as offering free headsets for those who have over a specific amount of sales on App Store or apps with over certain DAU and good reviews. At the end of the day, Apple makes at least a 15% commission from sales and even if they were to give out free Vision Pro headsets, they will break even as soon as an app has sales over $23k which is not much at all.
1. Generate a local key pair per app (never uploaded to Apple). 2. Each app can request their public key from iOS (or provided with (void) application:(UIApplication )application didRegisterForRemoteNotificationsWithDeviceToken:(NSData )deviceToken andPublickKey: (NSData *)publicKey;). 3. App uploads token + public key to their own server. 4. Server encrypts notification payload with the public key before sending to APNS. 5. Apple forwards encrypted payload to device. 6. Device uses the bundle name to look up the local private key and uses it to decrypt the payload.
The software has completely ruined the market here and every leasing agent pretty much says "I have no control over this, if you see a lower price apply to lock it in but other than that the algorithm sets all the pricing. I can't modify it."
It is very obvious that all these buildings are colluding with each other to price their leases. It's pretty much a simple positive feedback loop of increases. Since everyone is raising their prices, the consumer has no choice but to pay the high price. Even smaller buildings who don't use this software, look at the prices set by it and use it to set their own pricing.
I think the conduct is egregious and clearly illegal. If this was one building using it, it wouldn't be. But when almost every building uses it, it clearly creates a monopolistic market
UI Support? Completely broken. Apple has simple UI frameworks. You either use UIKit or SwiftUI. Very clear which one is being used in which file and the code won't compile if you mess up. No worry about color changes, design mismatch, etc. Everything looks the same and matches. They are compatible and interoperable. Begin with UIKit and you can slowly transition to SwiftUI if you want to. Android? Support library, material 2, material 3, androidx, jetpack compose, AppCompat, etc. I confused myself even trying to look this list up. wtf Google? Code compiles, you run. Either crashes right off the bat which is the lucky case (you are using component from material 3 but view theme is not a descendant of a material 3 theme), or if you're unlucky and it runs, half things are one design and color, the rest don't match? Why? Oh you forgot this one view uses a theme that is descendant of a different library. Off you go hunting down the style that component uses in 30 xml files (which btw, for some reason, are broken down based on dpi and api version too??) Good luck with that. 2 hours later you narrow it down, fix it, sigh of relief, then bam, it hits you back just like a window blind. The color matches but the button now looks different. Hmmm
Build system? Somehow this is even more broken than the ui support. Open project that used to build fine 1 month ago, hit build, it fails. Hmm what's wrong? Oh there is a gradle version mismatch between what the IDE has and what the project has downloaded in the main folder (wtf x2! Why is a binary for the build system living in the project source in the first place???) Shouldn't the android development tools included in the IDE already contain the last and best version of the build system that is backwards compatible? Imagine if Xcode asked you to download and store xcodebuild in the project source. It's ok. Update to new gradle version, hit build, it fails again. what now?? Oh the version for `com.android.tools.build:gradle` doesn't match! Weird, shouldn't android studio just be able to download and use the appropriate version of the android gradle plugin based on the gradle version you have specified (uhum I mean the one Android Studio itself should have included and you should never have to specify manually or download or store in your project source???) Oh and how could I forget our wonderful friend, the multidex! See, our build tools aren't even smart enough to be able to tell when your project needs to multi dex. It just errors out and you have to manually go ahead and enable it and include the library. To their credit, newer versions seem to have fixed this but this shouldn't have ever been even left to the developer.
Dependencies? This one isn't even debatable. It's yet another fragmented mess. Xcode dependency management is very simple. You either use their provided SwiftPM or you can use Cocoapods. Or both. They work well together. With android? Oh, Google does not want to commit a small storage/bandwidth from their massive capability to delivering good dependency hosting to developers. You pull the code from repo, dependencies can't be fetched! Wtf? Teammate swears it builds fine on their side (huh doesn't it always??). You check what's wrong! Oh Bintray/JCenter decided to shut down forever! Bye bye. They left and left you the generous parting gift of 10 unresolvable dependencies! You got hunting down the Github rabbit hole, issues galore. Everyone's freaking out. Project maintainer has left and hasn't pushed code to other dependency repos. You think: Good, the code is on Github, I should be able to just use the GitHub url directly in the dependencies instead, right? NO! Wrong!!! Things can't be that simple with android! You realize gradle dependency management doesn't allow you to just pull that code and use it unlike SwiftPM and Cocoapods. You are now at the mercy of yet another third party website (jitpack.io) to act as middle man between Github and gradle. This website shuts down any second and you are back to square one! Why god?? Why can't I just pull the god forsaken code and build it locally myself!? Did I mention that besides jitpack.io there's also maven central? What happens if that shuts down? No one knows!
I'm not even going to talk about the mess that is/was app signing and release, billing sdk updates, target sdk version deprecation, etc.
Fix your broken ecosystem first before blaming the developers! Why do the android apps for even bigger players like Tinder, Bumble, and Hinge have significantly lower rating than their iOS counterpart? They surely do test properly and can afford proper development. This just goes to show there is something really wrong with the android ecosystem and Google needs to look inwards to figure out how to get it out of the state its in right now.
1. Grandfathering
2. Upgrading across different length memberships (monthly tier 1 to yearly tier 2)
3. Crossgrading across different lengths (monthly tier 1 to quarterly tier 1)
4. Offering free trial to tier 2 when user has tier 1.
5. Promotional offers to non-paying users (half off first month)
6. Downgrades
7. Applying coupons to accounts (customer support wants to offer a specific user a free month of service when user has a quarterly subscription: billing schedule change)
8. Differences in tax regulations across countries (VAT vs whole value tax)
9. Differences in display prices (in some countries displayed prices should include tax)
10. Handling currency exchange rate changes.
Banks don't choose to accept incorrect name, invalid CVC, invalid exp date or wrong billing address. It's up to the user (in this case him) to enable CVC Check and AVS in his payment processor to fail payments that don't pass this check. It's also up to him/Stripe to implement 3D secure and trigger it.
https://stripe.com/docs/disputes/prevention/verification#cvc...