The reverse is true as well. I traveled in India with a friend from China who used their Chinese sim card in India, and their data was censored through the firewall. Really annoying to be outside China and not able to use Google maps.
Railscasts taught me so much when I was first learning web development right out of university. I used to watch Railscasts episodes religiously when they came out. I don't know if I would have grown as much as a developer without being exposed to the whole ecosystem of tools and techniques that Railscasts presented - I'd often discover libraries existed that solved problems I would never have known to seek out otherwise. Thank you for the time and effort over the years producing the episodes @rbates! Looking forward to hearing the full story in the next installments!
I updated the post to note Thompson Sampling and added a note about using only recent data as a potential improvement and linked to this comment. Thanks for this note!
Can confirm, using a non-root user also solves the issue (which I should have been doing anyway). It guess Cloud Run assumes $HOME is set to /home/something and since root uses /root it gets confused?
Ugh that's embarrassing. It seems like it works for most words, but has a few obnoxious outliers like "male" that I can't figure out why they score as female. It might just be a quirk of the dataset or something :/
I wondered if this could be useful for open source journalism stuff like bellingcat does. Essentially combing through tons of photos online to figure out where / when they were taken and Put together an understanding of an incident
This is solved in real life by taxes which make it uneconomical to sit on high value land while doing nothing with it. If it's not high value then who cares, feel free to squat. The problem is ICANN just charges $10/month per .com no matter the value, so it makes it economically viable for domain squatters to buy everything and just extort anyone who comes looking to do something productive. Just raise the yearly price on .coms, or raise the price proportional to how popular ICANN thinks the name will be, or ideally both. If it was $1000+/year for a high-value domain name, and $100/year for a reasonable length .com, squatters would vacate real fast.
Raising the price would solve the issue overnight. It doesn't need to be a uniform price increase, either - ICANN can guess which domain names are likely to be pricey based on length, dictionary words, or other heuristics. It can't be that hard. There's no reason why every domain name needs to cost the same amount per month. Domain squatters only do this because it's economically viable for them to register 10K domain names and just extort anyone who wants to do anything productive with them.
Also, ICANN should directly auction expiring domain names themselves. It's infuriating that when a domain name expires, whoever has the fastest script pays $10 and then immediately resells it for $100K to whoever actually needed it.
Do you know why? I also wonder this. I think I followed the paper correctly. My theory is that maybe there's a default male bias in the English languge?
Coffeescript definitely felt soooo much nicer to work with than JS at the time. Writing in Coffeescript back in 2012 felt like Typescript does now, where going back to working in base JS felt miserable after using it. ES6 took a lot of ideas from coffeescript which basically made it redundant. I wonder if the same will happen to Typescript if types get added into a future version of JS? We'll probably have another post about switching a massive codebase off Typescript onto whatever the next big thing is.
At that point, why not just directly grow the meat itself and skip the animal? It's already possible with today's technology and is getting cheaper every year: https://en.wikipedia.org/wiki/Cultured_meat
I wouldn't necessarily recommend using query rewriting for public graphql apis, but for internal apis or private apis to power mobile apps or web apps it should be fine. Just make sure you add tests for the old queries to ensure they keep working. Once you see the deprecated queries stop being used as users update their clients you can drop the rewriting entirely too.
The recent Google employee protests against their Dragonfly project give me hope that there might be a similar push by tech workers in the US, but it could also just be an isolated incident.
Oddly I never considered starting a new project with it, but now I'm questioning why that is. I guess I just don't see many new projects started in Rails, and nowhere I've worked the past few years uses it. I stopped using it after Rails 3, but I'll give it a try again in the next side-project I work on and see how it goes.