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.

I see what you did there.

Flickr - San Francisco, on-site

If you're a smart developer who can get things done, I'd like to talk you. We've got lots of interesting problems to solve on a site that is used and loved by millions of people daily.

My contact info is in my profile.

Just an FYI: Timoni is a she, not a he.

San Francisco - Flickr needs you!

We're currently looking for a backend engineer to help build new features that millions and millions of people will use. If the idea of pushing code live a dozen times a day while being the official caretaker of the White House and the British monarchy's photos interests you, I want to talk to you. You can email me at caudill -at- yahoo-inc.com.

Flickr is currently looking for an intern. Email me at caudill at yahoo-inc.com if you want to write a bit of code for us this summer! We're set up in the Financial District in SF.

At Flick(e)r, we finally fixed the misspelling of the company name.

Flickr's the exact same, as I'd imagine most big sites are.

Really the only way I can think of providing fast vs slow with most sharded architectures is to slow down the non-payers as opposed to speeding up the payers (which is obviously a horrible idea).

I'd like to focus on the two benefits that the OP mentioned: speed and reliability.

The obvious idea to speed up the pro experience would be to isolate pro accounts on their own shard with fewer accounts per shard as compared to the non-pro shards. This might provide some improvement but not much. And here's why:

1) People that pay for pro generally use the site more which means that they have more photos, more comments, more faves, more everything. The advantage of not fighting others for the same resources is quickly dwarfed when you have an order of magnitude more things to keep track of.

2) The majority of the site is still non-pro. This means if there was some speed-up by isolating the pro accounts (which, as stated, I doubt there would be), you'd only enjoy this speed when you're visiting other pro accounts which would limit your ability to have a fully fast experience.

The second request concerns reliability.

This one is easy. Maintaining two versions (ie, the fast and the slow versions) of an application involves two paths through the code. More code and/or differing architecture means added complexity. More complexity means more opportunities for things to go wrong, either in code or deployment. More things going wrong means a less reliable site, so by definition increasing reliablity for a subset of users but not another set makes the site less reliable.

I'll just leave this here. http://dukechronicle.com/article/morrison-column-distorts-du...

I'd even say it's cleaner than almost all of San Francisco and SF's worst parts (eg, the Mission, Bayview, Hunter's Points) are more violent than Durham's worst parts.

Every urban environment of any size is going to have its problems but there is a definite reality distortion field surrounding how violent and dirty people think Durham is.

Between American Tobacco (where I lived for 2 years before moving to SF) and the Warehouse District, you've got most of downtown covered. Then factor in the restaurants and bars up and down Main and Ninth streets and that's a safe and clean downtown. Durham's a great town and it's events like this that keeps raising its profile.

And Tyler's or Bull McCabe's for the after-dinner drinks. Or maybe Alivia's. Or the Federal. Man, that place has beer COVERED.

Here's a PHP->C->Python->JavaScript->original PHP quine I wrote a few weeks ago: https://gist.github.com/749686

And here's a little write-up on how I approached the problem: https://nolancaudill.com/2011/01/01/how-to-build-a-quine/