Flickr Code Blog

Foursquare went with OpenStreetMap though, and claim "while the new Google Maps API pricing was the reason we initially started looking into other solutions, we ultimately ended up switching because, after all our research and testing, OpenStreetMap and MapBox was simply the best fit for us."

http://blog.foursquare.com/2012/02/29/foursquare-is-joining-the-openstreetmap-movement-say-hi-to-pretty-new-maps/

They could be lying to cover a penny-pinching move, but I think they're telling the truth simply because Foursquare doesn't need particularly good geodata. It only needs for locations you visit to be fairly recognizable and locatable, it doesn't need to know that you can't do a u-turn or go that way up a one-way street or the exact location of a point to less than 1m accuracy. The only businesses it cares about it wants in its own dataset, not the map providers. Same story for Apple and its photo display or (going way back now) Yahoo/Flickr using OSM for geolocating photos in Iraq and China, Afghanistan etc. despite Yahoo having their own map team:

http://code.flickr.com/blog/2009/02/13/changelog-yahoo-updated-map-tiles-and-some-osm-ones/

This process has been going on for a while now, it's the traditional story of the open alternative eating the market from the bottom-upwards and accelerating as it gets wider use and improves in quality in a virtuous circle.

Every linguist will tell you that language is always mutating and any dictionary is a biased snapshot of how language is actually being used. The same is true for geography. Locals always know the quickest routes, the shortcuts, the bike-friendly streets. Top-down approaches like Tele Atlas and Navteq can miss these subtleties.

OpenStreetMap is brilliant not only because it's crowd-sourced mapping, but because it allows the crowd to define and create new feature types and place-tags on-the-fly. This means you get a map that shows you where footpaths and dog parks are, but it also means that there's infinite room for connection with other services. Flickr's support for OSM tags is a striking example: http://code.flickr.com/blog/2009/09/28/thats-maybe-a-bit-too-dorky-even-for-us/

I should also mention that some of my university colleagues are working on map wiki for cyclists in Minneapolis. http://cyclopath.org It is focused on being a research platform for collaborative map-making.

From my experience working with PHP for over 13 years (since PHP 3 was new), I can say your article is mostly true, and I have definitely seen the invisible-image-as-a-poor-mans-cron trick in production a time or two. The only nitpick is that I have really only seen stuff like this on small sites that don't have enough traffic for it to ever matter, so it's generally a temporary issue or a stop-gap measure, not common practice as was implied.

That said, there's nothing stopping people from just throwing a task in Redis from their PHP frontend and using node.js or Python, or Ruby to manage the queue. This is what Flickr did (http://code.flickr.net/2012/12/12/highly-available-real-time-notifications/), and it seems to work well for them. People just have to keep in mind what each language excels at and know the drawbacks. Articles like yours help, so thanks for the good read.

I have been using Flickr to archive my photos since 2013 when they announced a 1TB limit for free users, and have been paying them $50/year since 2016 when they limited availability to Pro users for their first-party auto-upload tool ( http://flickr.com/uploadr ).

It did seem like the 1TB limit was too good to last when it was announced 5 years ago.

Still, it's a relatively inexpensive extra archive for my photos (400GB) that supplements other backups. The archive is sorta searchable and kinda good for sharing with family and friends.

I haven't really used their social or community features (the Explore experience, the magic donkey, and the pandas are all alien to me -- https://www.flickr.com/photos/thomashawk/361974994 , http://code.flickr.net/2009/03/03/panda-tuesday-the-history-of-the-panda-new-apis-explore-and-you/ ).

I had asked a similar question on Quora [1] few years back. Here is the summary:

- Facebook: https://www.facebook.com/Engineering?sk=notes

- Google: http://google-engtools.blogspot.com/

- Twitter: http://engineering.twitter.com/

- Linkedin: http://engineering.linkedin.com/blog

- Dropbox: https://tech.dropbox.com/

- Instagram: http://instagram-engineering.tumblr.com/

- Netflix: http://techblog.netflix.com/

- Flickr: http://code.flickr.com

- Etsy: http://codeascraft.etsy.com/

- Yelp: http://engineeringblog.yelp.com/

- Heroku: https://blog.heroku.com/

- Airbnb: http://nerds.airbnb.com/

- Bitly: http://word.bitly.com/

- Evernote: https://blog.evernote.com/tech/

- Highscalability: http://highscalability.com/

[1] https://www.quora.com/What-are-the-companies-that-have-some-of-the-best-engineering-blogs

Hello, Sentinel 2 is doing quite a good work for many users, here is for example Flickr report: http://code.flickr.net/2014/07/31/redis-sentinel-at-flickr/

Of course Sentinel does not make Redis conceptually different from what it is from the point of view of consistency guarantees during failures. It performs best-effort attempt to select the best slave to retain writes, but under certain failure modes its possible to lose writes during a failover.

This is common with many failover solutions of *SQL systems as well btw. It depends on your use case if this is an affordable risk or not. For most Redis use cases, usually the risk of losing some writes after certain failovers is not a big issue. For other use cases it is, and a store that retains the writes during all the failure scenarios should be used.