As someone who has spent a good deal of time playing poker, I totally agree that this is a glaring editorial oversight.
Yet when phrased this way, it reminds me of "I'd rather be lucky than good" - something I've heard players say when criticized after winning in spite of poor play.
Sometimes this is sarcasm, but sometimes not.
There are in fact some folks who approach poker with a sort of chaos or joker mentality, and many who gain great satisfaction from winning by knowingly playing against and defying the odds - especially when the statistical aberrance is at the expense of another player who played the "right" way and lost all their money as a result.
For others, I think the saying is just a recognition of the supreme influence of variance in a poker player's lifetime success, a tacit admission that knowledge and skill alone are never enough.
I found it quite simple to install RabbitMQ server and its admin panel in my WSL local dev environment.
And the cloud/prod instance took a few clicks (just spun up a DO Marketplace server image) followed by < five minutes of RabbitMQ user and firewall configuration.
It was also dead simple to start using RabbitMQ within my application. I found a well maintained package, installed it, edited a couple lines of my application's config, and everything just worked.
I specifically avoided Redis based on my understanding that it can't guarantee message persistence, so if it crashes, your unprocessed messages are lost.
The article didn't mention the lack of version control, which AFAIK is impractical due to the sheer amount of HTML and layout-defining configuration WP stores in the db.
In spite of WP's revision history feature on Posts and other models, I've always found this to be a major issue on WP sites.
Obviously there are numerous other problems with WP, that's just one I didn't see the author touch on.
I try to talk clients out of WP whenever possible, and most let me build using a proper MVC framework.
I like to think I'm making the Internet a little better, one not-another-WordPress-site at a time.
“What we want to do is to become the operating system for the open web. We want every website, whether it’s e-commerce or anything to be powered by WordPress."
The only thing I disagree with is the lack of a web client.
It just seems like you could save a ton of work by starting with the web client, then create desktop versions via something like todesktop.com.
Then you're spending less time on updates - it's just one desktop version, and the iOS + Android versions are just consuming data from your API anyway.
> Code is free and open source, but 98% don't have the time/the knowledge/the will to self host
The vast majority of people who use GSuite won't understand or care about the OSS angle. Even if they do, they won't have the sophistication to examine your code. Thus, they must simply "trust" you, the same way they'd trust a corporation like Google.
People who really care about OSS are more likely to choose a more established solution for each use case (ie. Nextcloud for storage), and to self-host those solutions.
> will happily be us to manage and secure their data (like DropBox)
Again, if your edge over Dropbox is "we're open source!", I think this is just not compelling to most potential users who still want someone else hosting/managing their files. In that case, the open source transparency doesn't even mean anything, because the code in your repo isn't necessarily the code you're running on your servers.
In my case, I don't trust Dropbox, but I want their infrastructure. So I use a third-party encryption tool to ensure that they don't have access to folders I want to keep private. Best of both worlds.
That's an entirely different conversation... I do think Uber in particular was great at creating hype and glossing over the fact that their pricing/model isn't sustainable without the substantial rider/driver subsidies and worker exploitation that let them consistently undercut traditional taxi pricing.
What I meant is that any poor market performance for Uber/Lyft could simply be a function of investors waking up to the aforementioned realities, it doesn't necessarily indicate the bursting of some broader bubble.
Furthermore, I don't even view Uber/Lyft as "tech" companies. Sure, they make software, but they're not in the software business.
> an API developer not wanting to write own/reinvent cache layer for their REST API
For Laravel projects at least, a package like spatie/laravel-responsecache makes it super easy to handle caching for GET API routes. I'm sure there are similar packers for other frameworks often used in API development.
I really like Bloom, I'd just rather handle it at the application layer, where I can get the finest level of customization (assuming there's a suitable package to abstract the most tedious work away).
Seems you could keep the associated code to a minimum, and easily maintainable, by using model events to trigger cache updates.
Personally, I'd rather have a little more code than a new dependency (and the resources the Bloom takes from each API worker it's installed on). But in situations where it's non-trivial or inadvisable to do it at the application layer, it seems Bloom could be quite useful.
> A simpler caching approach could have been to enable caching at the Load Balancer level for HTTP read methods (GET, HEAD, OPTIONS). Although simple as a solution, it would not work with a REST API. REST API serve dynamic content by nature, that rely heavily on Authorization headers. Also, any cache needs to be purged at some point, if the content in cache becomes stale due to data updates in some database.
> NGINX Lua scripts could do that job just fine, you say! Well, I firmly believe Load Balancers should be simple, and be based on configuration only, without scripting. As Load Balancers are the entry point to all your HTTP / WebSocket services, you'd want to avoid frequent deployments and custom code there, and handoff that caching complexity to a dedicated middleware component.
I agree with his overall message - it's hard (and takes time) to actually do something valuable. And I agree that we're in an age where iterative startups ("Uber for X") outnumber innovative startups.
But there is just so much wrong with this article. One of the most egregious errors is the assertion that the conditions which enabled unicorns are no longer present.
Nothing could be further from the truth.
The only accurate assertion of the article - that it's genuinely hard to add value - was already obvious.
I prefer to give them the benefit of the doubt, though a clear explanation of why the above policy was not followed seems warranted. (It also doesn't appear to have been followed in several other instances reported by other former customers in various HN threads.)
If DO reserves the right to cut off services and access to your own data permanently and without warning (outside of a court order or confirmed illegal activity), that needs to be unequivocally stated, and the triggering factors should be made known. Otherwise, DO is not fit for production systems.
Additionally, it would be nice to see the creation of a transparent, high-level appeal process for customers affected by suspensions. Truly malicious customers wouldn't use it (what would they hope to successfully argue to an actual human reviewer?), but it would greatly benefit legitimate customers to have an outlet other than social media by which to "get something done" in the event of an inappropriate suspension followed by a breakdown in the standard review process.
I'm no longer able to edit the above comment, so to elaborate on #1:
Following is a comment[1] by Moisey Uretsky in another thread[2]:
> Depending on which items are flagged the account is put into a locked state, which means that access is limited. However, the droplets for that account and other services are not affected at all. The account is also notified about the action and a dialogue is opened, to determine what the situation is. There is no sudden loss of service. There is no loss of service without communication. If after multiple rounds of communication it is determined that the account is fraudulent, even then there is no loss of service that isn't communicated well in advance of the situation.
Yet when phrased this way, it reminds me of "I'd rather be lucky than good" - something I've heard players say when criticized after winning in spite of poor play.
Sometimes this is sarcasm, but sometimes not.
There are in fact some folks who approach poker with a sort of chaos or joker mentality, and many who gain great satisfaction from winning by knowingly playing against and defying the odds - especially when the statistical aberrance is at the expense of another player who played the "right" way and lost all their money as a result.
For others, I think the saying is just a recognition of the supreme influence of variance in a poker player's lifetime success, a tacit admission that knowledge and skill alone are never enough.