mncaudill

I didn’t catch him but did look for him every time I rode that way.

Agreed! I routinely cycle around the city and one of my favorite loops is along the Embarcadero and up through Pier 39 and Fisherman’s Wharf.

We live in a beautiful city that people come from all over to see and there are good reasons for that. I’ll also offer to take pictures of families taking their photos with the sea lions (which I also always stop to watch) and chat them up a bit. Fun times.

Clean Code: A Handbook of Agile Software Craftsmanship by Robert Cecil Martin

I wrote a post about how to do these multi-lingual quines a while back: https://nolancaudill.com/2011/01/01/how-to-build-a-quine/

Seriously?

http://blog.linkedin.com/2011/01/11/open-source-linkedin-kaf... http://blog.linkedin.com/2009/03/20/project-voldemort-scalin...

And there's actually a project that takes advantage of that fact: https://github.com/nvkelso/golden-ratio

Coincidentally, I felt compelled to write a bunch of words about the issues with pagination just this past weekend.

http://nolancaudill.com/2012/03/24/pagination/

Nolan, here: the guy that wrote the post about the recent layoffs.

As stated in the post, I honestly believe that Flickr-the-site, in the long run, will be fine. Do these layoffs hurt? Of course! But Flickr has had bigger bumps in the past and has pushed through them all. The engineers there are an incredible crew of guys and Markus's post at the first of the year on blog.flickr.net shows that they've got some exciting stuff on the way.

I also have been (in a small way) helping Aaron with parallel-flickr and I think he as much as anyone would say that he's not building a replacement Flickr but more of being a good archivist and leaving nothing important up to chance, even if the odds are 1-in-some-big-number of Something Bad happening.

Obviously, I don't know the whims of major corporations like Yahoo, but Flickr-the-site, which is its content and its devotion to preserve that content, hasn't wavered in how it treats your data.

At Flickr, we recently added some real-time features to our API, so I built a little page that simply streams every single of our photos that is tagged with #occupywallstreet.

I used node.js -- mainly socket.io (what a great little module) and flickr-conduit (link: https://github.com/mncaudill/flickr-conduit) that I wrote to make using the real-time stuff easier.

Thanks!

I like that you guys are using your database's stock features to accomplish this. Most of the time you don't need complicated systems to get things done. Reducing that mental overload of YET another system is huge.

I work at Flickr and I see they mentioned Flickr's ticket server idea, (ab)using MySQL's autoincrement and "REPLACE INTO" trick and mentioned that a con was the write bottleneck.

We're generating more GUIDs than ever with this system and those boxes are more or less idle on every metric. They're right in that we don't meet their time-ordered requirement, but I just wanted to say that writing (or reading) is not a bottleneck.

SICP is under some sort of Creative Commons license but I'm pretty sure Intro to Algorithms isn't.

At Flickr, I always have our system graphs in one tab and our help forum in another tab.

I'd love to see a pros-and-cons of this approach from a team organizational standpoint.

San Francisco, CA - Flickr

We recently had our 6 billionth photo uploaded and we (the engineers) just built and rolled-out the new geofences feature. Engineers really get to make a difference at Flickr on a daily basis. http://code.flickr.com/blog/2011/08/30/in-the-privacy-of-our... (That's my kitchen.)

We're hiring backend engineers, designers, and operations. Drop me a line at caudill -at- yahoo-inc.com if you're interested. I'd love to talk to you.

The three reasons that jump out at me would be: 1) Redundancy. 2) Cupertino wants them off their grid. 3) Or they're going to have a unique power footprint that they don't want to share with the world.

Hi, sorry you've had some difficulties with the site. We've made performance a big focus on the photo page but there's other sections of the site we're still trying to make faster. Regarding the broken images, we should be all clear on that (we recently brought up a new image cluster), so if you're still seeing that, let me know. I'm caudill @ yahoo-inc.com.

Indeed. A lot of hard work went into the photo page redesign/rebuild. It's difficult majorly overhauling a site that serves so many different needs to so many different kinds of users.

And this is why I trust my files with this guy.