I was genuinely surprised your comment doesn't end with an "/s", but anyway, I'd be interested to hear the rationale of users who pay for "smart people thoughts".
Your comment implies that paying money to hear the thoughts & opinions of smart people is some sort of new concept that should be considered with skepticism. And yes, Twitter does contain more than just political shouting matches by random people.
Here's a few examples:
1. I follow a few photographers that I greatly admire. Some of their best work is on Twitter. With super-follows, I can support these artists and get exclusive posts for things like gear reviews, etc.
2. I follow a lot of economists/scientists that often have really interesting insights. Noah Smith, Tyler Cowen, Ezra Klein, Scott Manley, to name a few. I'd happily pay a couple dollars a month for more in-depth content by them on Twitter.
3. I also follow some interesting writers and creators, like Craig Mod, Hundred Rabbits, and Kyle Chakya. I could see myself paying them a couple bucks a month if enough of their content was offered that way. They are also people I really respect, so I'd be happy to support them.
> the rationale of users who pay for "smart people thoughts"
I pay for the Economist all the time. So far it's been great. The news is completely useless on a personal value basis, but reading the insightful calm reporting without drama has been fantastic. Especially during the US election when it felt like the whole world was screaming at me 24/7.
I'm also a big buyer of audiobooks from experts so that I can get their "smart people thoughts" on $topic.
Most government tenders for a contract are available online, I'm from Australia so not entirely sure what I'm looking at but this[1] appears to be some sort of reference to the tender, although there is limited information provided.
Ever since xmlhttprequest (and even before that with images) we've been able to do server-side validation without a full page reload.
This "solution" completely ignores the purpose of client-side validation which is to a) reduce load on server-side resources, b) validate faster without the network latency and c) validate more securely and privately by not sending the content to the server.
imo, "modern" would mean it removes or replaces features and characteristics which were exclusive to or popular in a previous time period but are not essential or can be replaced with "modern" alternatives.
This is preventing me from reading (and possibly writing) with Cloud Logging APIs across multiple accounts and regions.
Also worth noting this incident is described as part of "Operations" but actually impacts "Cloud Logging" and is still using the old "google-stackdriver" category internally..
I think there is some difficulty specific to Shopify here, as REST APIs go their original one was fairly sane and provided powerful features.
When their GraphQL API was released its data structures were similar but not identical to the REST API and some very important fields and features were missing which translated to a "90%" adoption by developers who needed those missing pieces. Additionally (and somewhat in keeping with points in the article,) they also introduced API versioning at this time which added a good amount of friction within the community.
More generally the issue with Shopify's GraphQL APIs is its lacking features (eg, list totals, offset pagination, object fields) which are (or had been) particularly important to the ecommerce domain and they've struggled to provide any meaningful alternatives.
As an example, developers working with ecommerce applications often have to process data en masse (fulfillments, inventory, etc..) and with the Shopify REST API and it's offset pagination these tasks were trivial to parallelise by simply chunking the workload based on the pagination method. In the GraphQL API offset pagination was removed in favour of cursor pagination which has no reasonable alternative to parallelise tasks in the same way, this requires developers to rewrite core logic and services for what may have previously been a very acceptable, efficient and most importantly working application.
The issue with Shopify's GraphQL API is not GraphQL itself, but rather the implementation of the API not meeting the requirements of the consumer - and the fact that those consumers were forced to switch to a different API without feature or even conceptual parity didn't promote feelings of joy or glee about the situation.
Personally I think their push for GraphQL was due to internal operational issues and their need for a more efficient system. This has been seen in their reasoning for reducing the timeout of an API used to fetch shipping options (from 10 seconds to 5 seconds) in preparation for Black Friday / Cyber Monday sales events, their announcement provided some developers less than a single business day to respond to the changes[1] which were dropped after community backlash and then changed to address the feedback.
Completely forgot in the other comment but your product would be subject to GST, which is a tax. I can't imagine Google paying GST %s on their Australian ad sales, but it's a starting point.
What if you as a European (company) employ 1000 Australians in Australia and have Australia specific resources (including sales) in Australia and use those Australian resources exclusively for Australia.. are you still not operating in Australia?
Painfully ironic that the static landing page for a service offering to improve website performance (by adding more technology) scores a miserable 66% on mobile and 90% on desktop with Google's PageSpeed Insights[0]. I honestly didn't realise static sites could score so poorly.
I'm assuming this is targeted at a non-technical audience (although posting to HN would suggest otherwise), but I suppose it could provide some benefit under ideal conditions.
Including a 24kb font for the three "pep" letters in the heading just tops off the eternal face-palming. Incredible.
Well done, it's a neat idea and if the service can provide a measurable improvement I think it's worthwhile to pursue further.
Seeing the service in action would really help both technical and non-technical audiences, I need to know it's not going to be a liability and my clients would want to see pretty colours / improvements.
Something like "before.pep.dev" and "after.pep.dev" would be great.
