progolferyo

How about more control over the software & configuration side of ELB as well? If you could control more things that nginx or haproxy let you control, I think there would be a lot less need for another routing mechanism behind ELB.

In addition to weighting, we need an nginx layer for different app pools, custom routing options, max connections limits, request queueing, url rewriting, static content serving for specific requests. The list goes on but these things could easily be brought up into the ELB layer.

podrivo: did you do everything by hand or did you use some kind of IDE?

very cool.

Umm, why is this post #1. this is obviously something related to a dev typo or pushing the wrong key.

slow hacker news day maybe? :)

In theory, i like the idea but I can't see paying for an API like a service would generate as much money for them in the long run as their current ads strategy. API Services tend to cap out at a certain rate so then you need to start offering unlimited packages, etc. Companies are not going to be paying millions of dollars for API services, I cant think of one example where this is remotely valid.

Have you thought about how Twitter would actually structure something like that? Twitter is monetizing FAR FAR better than any of these other small Twitter API clients. Something like Tweetdeck might have generated hundreds of thousands of dollars, but thats a joke compared to the kind of money Twitter is dealing with.

You'd be surprised, "scaling" a database is something that more and more folks are having to do lately, with the onslaught of mobile apps and facebook apps and web apps, it's just a whole lot easier to create an application that gets hundreds of thousands of users - millions of users.

And more importantly, you can have an application that has hundreds of thousands of users and not really make a ton of money, so you kinda need something that is easy to use because you don't have the capital

Although I agree with the Facebook App sucking (and seeming to get worse and worse), I do feel like the article is a bit misguided. I don't give 100% blame to UIWebView and no-Nitro simply because the entire way Facebook has developed the mobile app has been hacky and misguided.

The code itself is poorly designed, the API's are all over the place, there are inconsistencies everywhere and the performance is clearly lacking. On the flip side, take a loop at the LinkedIn app for iPhone. It's super slick, easy to use but still has a ton of features and the performance is far better. Yes, it's not as slick as Path but its miles ahead of the Facebook app.

So if I were Facebook, I'd rely a bit less on the 100% platform agnostic approach, take it back a bit and build the things that make sense cross-platform with HTML and build the parts separately that make sense to build using native code. This approach to me accomplishes much of the same cross platform success without creating such a crappy and laggy app.

nice, i like it! did you do anything with it post-hackathon?

We've seen some issues with FB graph errors. It's probably related to that

If you have an Android device, we even support <media> to take pictures from the browser

I don't think anyone is disputing the fact that guys in coffeeshops can't make successful startups. I don't think that is the point the author is trying to make. The ecosystem, much like the rest of the world, is centered on averages and unfortunately, it becomes a LOT easier to start a company and not FAIL when you have something to leverage. In the startup world, there is the deadpool and avoiding the deadpool is very unlikely when you have a plethora of experience to play.

Everyone starts with nothing and people succeed based on merit, there is nobody who is creating a shitty product and succeeding just because they are Kevin Rose. BUT, Kevin Rose can start a company and get millions in funding with the snap of his fingers and average Joe has to work and work and grind and grind before that happens. And probably, there are average Joe's out there that do all of this and still don't make it because of some other reason, that may even be out of Joe's control.

So conclusion is that success in the startup world is still about making a great product and building a good business but getting funding in my opinion is just as equally about product as it is about selling the founders to the investors and if you have something good to sell, like 'I created Flickr', it's incredibly easy to raise money. And one could argue that with money comes another level of huge advantage, and the sooner you raise money, the more advantage you have. SO in the end, having experience is a huge differentiator when looking at averages across the board.

So the rendering is definitely faster but I think the biggest advantage to non-computer graphics engineers is in the available API's over the actual improvement in rendering time, at least with what I ended up doing with it.

Honestly, it was just a fun project that let me experiment with the new CoreImage API's, but also make something fun, polished and worth a buck. With the new camera in the iPhone4S and everyone upgrading to iOS5, the photo apps are going to explode.

Ughh, the link is broken at the moment, stupid EC2 Elastic IP screwed up my instance and therefore my DNS. Here's a link to the app, http://bit.ly/spookify in the meantime...

The Wufoo guys just created a kick-ass product, they are really talented javascript and css engineers. Now it's common for a site to be streamlined with drag and drop interfaces, dynamic lists and the like, but a few years ago, those kinds of sites were hard to come by. Plus they are just cool guys, I actually found a bug in the site once, sent them a reference to the bug in their contact form and one of the team members sent me back a personal note about fixing it. Those are the kinds of finishing touches to a product that I think made Wufoo excel, albeit in a kind of weird tech space.

ditto.... lol

I guess most of your points make sense. I just feel like Yelp does very little to be open and transparent. I get that its very difficult, nobody ever said its easy to algorithmically guess review spam.

But they clearly don't want users to see unfiltered reviews. A tiny gray link below all 40 reviews, then a captcha (or two or three) and then a slow user experience before you can see the filtered reviews is lame.

I agree with you about the showing other reviews of the same subject, that would be neat. I guess if I were Yelp, I would try harder at standing up for their algorithms and show more data about why they work and why we are better off having their amazing algorithms.

I had an experience a year or so ago with a friend who started a moving service in SF. A couple of months after he started the business, he noticed he received a review on Yelp from some dude that said during a moving job, the guy took a smoke break and peed all over the sofa he was moving. Not only was the story ridiculously false but my buddy had no idea who the reviewer was. The review did however NOT get filtered, even after he responded to the review and contacted Yelp. And he was stuck with this crazy review at the top of his profile. This went on for months and it really damaged his credibility, meanwhile he would have positive reviews from legitimate customers who would naturally have a newer profile or whatever and the reviews would get filtered. It just seems like Yelp should be more sophisticated. (And yes, they are 10000% better than TripAdvisor)

A quick and dirty solution could be to add something to the page using javascript after the page has loaded and only let the link work if that variable exists (and check the value of the key with the server, if you wanted to be more cautious). Not a complete solution, but a first step and invisible to the user (and a pain in the ass to a robot)

Plus captcha's are just such a stupid user experience anyway, if you want to avoid the robots problem, there are plenty of ways around captchas

Interesting article. I don't understand the filtered review system at all. Beyond the 'he said / she said' complaints that occasionally come out, there are things about their system that simply don't make any sense unless Yelp is incompetent or slimy. For example:

- When you post a review, you as a reviewer think its unfiltered forever. When you revisit the page as a logged in user and read a place that has your review, your review is visible. When you log out or log in as another user, the review is filtered and hidden. At the very least, it should tell you your review is filtered, I see no reason to pretend the review is not filtered when the review is legitimate.

- When you view unfiltered results, the per page number mysteriously changes to 10 per page. I don't see any reason why this should change. Plus the results are pretty slow to load, quite slower than the results for filtered reviews.

- Why do you need to enter in a captcha to view the unfiltered reviews? Why would they care if you were a bot only for the unfiltered reviews and not the normal reviews? I don't see the difference, unless they want to prevent people from writing scripts to pull in unfiltered review data. Plus the captcha is fucking horrible, literally half the captcha's I get are not readable and I need to refresh.

- The filter algorithm seems to be clearly flawed and simply catches way too many reviews that should not be filtered. For example, take this user: http://www.yelp.com/user_details?userid=tZlbsUVo-8wtnR7oMa-3... . The guy has 11 reviews, 1 1-star review, 1 2-star review and nothing out of the ordinary and yet his review about Yelp was filtered. Why? His points in the review seemed legitimate. He seems to be a normal user, not a new user and posts reviews across the board (more good reviews than bad in fact). They should either fix the algorithm or be more transparent about why reviews are filtered because I can't understand why a review like that is filtered.

Fun and sensitive question! Taxes certainly bite big time, especially on on an acquisition where its paid out as a bonus.

Longest engineer at the company when the acquisition happened, exit was around ~200k, pre-tax.

Hmm, while the documentation does say this, in my experience the token never changes, even across app for a given device.

Whenever these ridiculously huge acquisitions take place, it's always the same. How can Google possibly think that 20 billion couldn't have created something far better than anything Motorola has to offer. They have the talent, the infrastructure, the money, the manpower.

The Skype deal felt like just the same...

The performance of the demo is awesome. Has anyone tried to do anything more complicated and tested performance. Would be fun to make a js game from this.

Does anyone know what javascript engine this game is using. It appears to be 'Enjine' but I can't seem to find any information about it.

As a PC turned Mac user for the last 3 years, this is truly the best thing about working on the Mac platform. My girlfriend is still on her shitty HP laptop and it is so incredibly painful to watch her worry about viruses and malware on a daily basis.

I hope Apple's policy around this is not going to be sweep it under the rug because it could get out of control as Apple market share grows and more effort is dedicated towards hacking the Mac.

As stupid as this story is, it is still something that Apple is gonna have to probably start paying more and more attention to, given the trajectory of Apple market share in the future and the increased effort will be taken towards the Mac platform.

I think

Looks much much easier to use. CocosDenshion was a good idea but in practice it is flawed in the things that the author of this library talks about, which is that there are annoying bugs in iOS's and both audio engines (openAL & AVAudioPlayer) need to be handled differently.

We are using the 3taps API, not parsing Craigslist directly. They aggregate all this data for us.

The images are just pulled from a single category on craigslist. So we currently have no way of separating out the motorcycles from the motorcycle helmets, without further filtering.

Thanks!

Working on this feature. We ran out of time to implement this for the hackathon.

WE WON! WE WON! hip hip hurray! hip hip hurray!