I got invited to talk about Electron at QCon San Francisco in November and the video and transcript of the presentation are now available. Electron gives you the power to write a single application for Windows, MacOS and Linux. But Electron apps can easily feel out of place among other applications, exactly because you have…
Flickr, please fix your API!
Randomcuteanimal.com is no longer online
The past weekend, I built randomcuteanimal.com, which shows you a random CC-licensed Flickr photo of a cute animal. This being cute animals, I have to block out a lot of words such as “dead”, “scary”, “disgusting”, but also “playboy” (different bunnies here!), “tracks” (animal tracks aren’t cute), “stuffed”, “knitted” (only real animals!) and a boatload of other tags just to make sure you don’t suddenly stare at a disemboweled sea otter (That happened. Not cute). But the Flickr API has different ideas.
No dead animals please
Flickr’s photo search API allows you to search by excluding certain tags. This is great, because it means I can filter out all sorts of stuff that you just don’t want to see while looking for cute animals, such as anything concerning dead, shooting, fighting but also knitting, graffiti, skulls, playboy (bunnies), fur and stuff I hadn’t even imagined would give problems, such as “kitchen”, “makeup”, “art”, and a whole slew of other tags.
But it seems that exclusion tags are merely a suggestion to Flickr. Flickr doesn’t really seem to care when I say I don’t want dead animals. Every now and then, it just slips one in to see if I notice. Unfortunately the difference is pretty clear. On the other side, seeing a knitted hedgehog isn’t quite as offensive, but it isn’t quite a real animal, either.
What it comes down to though, is this: if you want to look at just some cute animals, a dead rodent is a major buzzkill.
This really is my biggest problem, and I don’t have a solution for it yet other than obsessively blacklisting individual photos. Suggestions are very welcome
Not that photo again!
When I select photo’s, I request a random search page between page 1 and 10000, with each search page containing one photo. You’d think the odds of the same photo popping up twice would be really minimal, right? As it turns out, the page attribute is also merely a suggestion to the API. There are a number of photos that just keep popping up for everyone, up to a point where they’re the only photo visible. Now, my random number generator isn’t broken, so it’s definitely happening at Flickr’s end.
This photo is really cute, but it starts to lose it’s shine after randomly showing for the tenth time.
Luckily I can circumvent this by checking if I already showed you this photo, and then requesting another one. I’m kind of forcing randomness here, I guess.
Sometimes, one means zero
Lastly, I tell the API to only return one photo, because, well, I only need to display one, and requesting more is wasting both my and Flickr’s bandwidth. However sometimes in the API one means zero and no photo gets returned. It doesn’t give an error or anything, but it doesn’t give me a photo either. This problem goes away entirely when you request two photos. So that’s what I do now. If it does go wrong again, I have a sickeningly adorable Red panda on my error page that should see you through to the next page refresh.
Thus concludes a weekend of playing with the Flickr API. The above three problems are very annoying so I hope Flickr will improve their search to fix these problems. If only so I can show people even more cute animals ;)
Starting with MacOS 10.14.5, all signed applications by ‘new’ developers will need to be notarized or they will trigger Apple’s Gatekeeper software and prevent users from installing your app. That means that aside from signing your application, you will need to notarize it as well. This is how to successfully notarize your Electron application. MacOS…