nathan-io

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'm equally surprised by your anecdote.

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.

I'm running Discourse on a $5/mo droplet, 1 vcPU 1GB RAM. I just added 4GB of swap space. No issues so far.

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."

God help us all.

Understandable. How are ISPs supposed to keep mining and monetizing browsing history if everyone starts using DoH?

You're right there, not sure what I was thinking there.

Regardless, my original point is still valid. You could serve web/MacOS/Windows/Linux users with a single UI.

Yelp has always been a thinly veiled extortion platform, overrun by spam, yet surprisingly quick to filter legitimate five-star reviews.

I tried their paid advertising for a client in 2017, and have avoided it like the plague ever since.

Not only did the trial yield no leads, but Yelp billed substantially more than the defined monthly campaign spend.

It took repeated complaints and escalation to a sales manager to even get part of the overage credited.

My experience was:

* Near zero detail or transparency in campaign reports

* Deceptive and confusing budget rules

* Absurd cost per click (even compared to Google Ads)

* Sudden filtering of all the legitimate 5-star reviews on one listing, after we declined further sales efforts

I certainly am.

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.

Love the BYO CouchDB feature - very interesting!

> 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.

These are both wildly unprofitable companies, and they may likely never become profitable.

Possibly not the best examples...

> 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.