A few years ago, I wrote some code to post Untappd check-ins to Mastodon. I've recently updated it to also post a photo of the beer you're enjoying. First up, you'll need a file called config.py to hold all your API keys: instance = "https://mastodon.social" access_token = "…" write_access_token = "…" untappd_client_id = "…" untappd_client_secret = "…" Then a file called untappd2mastodon.py to do the job of grabbing your …
Continue reading →
I'm a big fan of Untappd. It's a social drinking app which lets you check in to a beer and rate it. Look, we all need hobbies, mine is drinking cider. You can see a list of everything I've drunk over the 13 last years. Nearly 900 different pints! After checking in, the app automatically posts to Twitter. But who wants to prop up Alan's failing empire? Not me! So here's some quick code to liberate your data and post it elsewhere. There are two ways - APIs and Screen Scraping. API First up,…
Continue reading →
10 years ago, I asked an innocent question on Twitter. Terence Eden is on Mastodon@edentIs there any service which will let me "check in" to a beer? Because this Chocolate Tom I'm drinking is amazing.❤️ 0💬 4♻️ 018:55 - Thu 21 July 2011 The answers came in swiftly - Untappd was the app to use. So, a few minutes later: Terence Eden is on Mastodon@edentI just earned the 'Newbie' badge on @untappd! http://untp.it/p3POA0❤️ 0💬 0♻️ 019:29 - Thu 21 July 2011 In the last decade, how much beer and ci…
Continue reading →
I rate every pint I taste using the Untappd app. Think of it like TripAdvisor for lager, stout, cider, bitter, and all manner of other beery goodness. Seriously, I've reviewed over 600 different drinks Recently, I decided to see if I could self-host my beer check-ins. The first step - extracting my own data from Untappd. Pay To Play If you become an Untappd Supporter for US$5 per month, you can extract your data in CSV or JSON. I feel like I ought to be able to GDPR that and get it for…
Continue reading →
In app design, we often talk about designing for the user in context. For example, a taxi app can't rely on a perfect GPS signal in a crowded city, a user in the countryside may not have brilliant bandwidth, battery life is not infinite so we should limit certain features when power levels are low. The common theme in those examples is that we are designing for the phone's context, not the user's context. We rarely say "let's introduce a left-handed option" or "do we need a night reading…
Continue reading →
