bvm

It's a pretty fine line you're treading here. A lot of the reason the competition is so expensive is that they are licensing the data in bulk. There's lots of litigation in this area, see the Meltwater cases in US and UK.

How are you licensing the content?

The Dubliners is my desert island book. I can happily just sit there and re-read The Dead over and over again and never bore of it, there's so much there. Especially the way it builds to that incredible ending passage.

His soul swooned slowly as he heard the snow falling faintly through the universe and faintly falling, like the descent of their last end, upon all the living and the dead.

Grammarly causes a surprising amount of frontend issues.

I agree with you completely, we use Kops and see a similar workload. The real boon for us is not in production, where the HA/error-tolerant/easy horizontal scaling certainly helps, but in development, where we can easily bring up ephemeral feature branch deploys as part of the CI/CD pipeline (which itself runs on k8s using Gitlab CI)

Reminds me of the audio editor that shipped with Windows...95? Had some great times with that thing reversing everything in earshot, doing reverse reverb etc etc

edit: this thing https://i.imgur.com/UXqSteO.png

Yeh I would argue don't use a message queue for this, they're really best processing many messages quickly, there are plenty of scheduling libraries that have various persistence layers to handle this depending on your ecosystem.

Using this opportunity to shout out to Rascal (https://github.com/guidesmiths/rascal) which makes using RabbitMQ on Node an absolute joy.

Surely it's cheaper to just pay someone to do data entry at that point.

The direct link to the dataset is here: https://curation-datasets.s3-eu-west-1.amazonaws.com/curatio...

https://github.com/curationcorp/curation-corpus instructions on how to use it with examples for BERTExtAbs and BART. Sorry for the confusion!

I am logged in, and I can't read it.

Combining random with this fantastic chrome plugin: https://chrome.google.com/webstore/detail/wikitube/aneddidib... has really enhanced my morning.

Nothing esoteric, git trunk with feature branches that build, test and deploy in Gitlab CI to a-feature-name.our-company-name.local on k8s, notifies QA team that there's something to check, gets approved, merged to master and released automatically, functionally tested on canary prod deploy and then rolled out wider.

> I find that the main advantage of having less moving parts is that there's exponentially less things that can go wrong - and that makes reliability possible with very small teams

Right but it is a trade off to some degree. For us, to have ephemeral feature branches deployed to QA completely in a hands-off manner means we can do multiple releases per day as a small team. Most (almost all!) of the advantages we have seen from moving to a k8s infra have been DX, rather than UX.

> You'll spend all your time managing these, and relatively little time actually being productive.

I see this a lot, and I'm always somewhat surprised by it. It took a couple of days to put together our kops-based cluster on EC2, wire it in to Gitlab CI and get the various load balancers, ingresses et al plumbed in, and then perhaps an hour a week maintaining it from there?

I do agree it's not the right place to start, but I think the standard operational complexity of k8s is frequently overstated. The argument I do buy against k8s is that when it goes wrong, debugging can be a nightmare.

Question: do you guys find a graphql-only API acceptable in 2019? For us to develop a (good) REST API layer on top of our existing solution is a non-trivial piece of work, and GQL offers us all we need on the front end. Customers seem ok with it, but we haven't got any large enterprises yet.

I love gitlab, I really do, but their uptime is atrocious for a multi-billion dollar company.

Ah it reminds me of Kimono Labs. I miss that product, it was fantastic.

(not sure where you're based but...) a Henry! https://www.numatic.co.uk/products.aspx?r=4&sr=1 They're cheap, they're reliable, you can use them bagged or bagless, they're basically indestructible (our chimney sweep uses a bog standard one for the actual sweeping), if anything does break you can easily repair them, they are really very good at vacuuming. Excellent product, would buy again, if I ever had to.

and fax.

yeh we pay them like $15/month for Hub/Cloud/Private Image Storage/whatever it's called this week.

It actually seems quite cheap...we have something like 2TB of tags up there, and they don't charge for network I/O. I did feel slightly bad when a hidden crash looping pod set to always download lay undiscovered for a month...that's a LOT of I/O.

I'm really confused as to why they do this: there must be hundreds of people and hundreds of millions of $s working on the YouTube algo. I'm seemingly in the minority that thinks it's largely brilliant, it regularly uncovers things that are related to stuff that I'm interested in but new takes on them, and sometimes throws up some absolute genius recommendation from nowhere. However, like you, my "Up Next" selection is plagued by videos I've previously watched! It's horrible UX.

yeh that happened to me when i rotated the password on our master docker hub (or cloud or whatever it is today) account prior to all of this.

> knitpicky

this one writes itself

Annoyingly, what's kept me on it is the fact that some super-niche private groups (that would otherwise be ideally suited to a forum or subreddit) have sprung up that have content that I simply can't get anywhere else.

Does anyone else find they can't tell if things are an intentional design decision or an implementation bug anymore? case-in-point: the rendering of the title of this piece.

This is honestly the most poorly communicated downtime I've ever experienced. Now, they give a non-update saying they're going to send an email (yes, email) about it later today: https://twitter.com/mandrillapp/status/1092810757929086977

Mandrill is 30 days of send history with 90 days of stats.

I've had lots of issues with outbound. Bulk sends failing completely. Individual seems to work but is very slow.

I had the exact same experience on my dev cluster. It's a bit of a scary black box if you don't have the time/experience necessary to debug it.