aneth

While I have complete respect for @raganwald, I find it somewhat disturbing that he would even begin to implement or go along with this policy. I can't imagine asking an interviewee to login to their private facebook account, any more than their private email or dating website.

The answer should have been no at the first suggestion and I hope he amends his blog to indicate that even the few times he did this was completely wrong, in addition to placing the company in a tenuous legal situation. As an interviewee, I would be outraged and walk out.

> It's true that you don't lose weight without caloric deficit.

Are you sure? I've lost plenty of weight following a low carb diet while eating tons of high calorie dark chocolate and oily meats.

It's already possible to write templates this way.

render 'template', :locals => {:wombat => 'foo'}

This is an interesting analogy, yet laughably impractical and wrong.

Paid business models do not guarantee success. If they did, Posterous would have charged. It seems land is so cheap, landlords have concluded the best possible chance to find a business model is to be a free landlord. That is a great world for tenants since they don't have to pay rent, and it's a tough world for landlords since they have to maintain beautiful buildings with donation boxes and ad banners.

Given the lack of tenant laws (imagine if there were tenant laws...) paying rent is no guarantee of anything. You can be evicted, abused, moved around, neglected, or anything else without warning or compensation. That's a good thing, which demonstrates how strained and poor this analogy is.

Good luck finding quality, innovative, paid services to match Facebook, Twitter, and Posterous. Let us know how that goes. You'll have some luck, but I'm not sure your chances are much better. I call bullshit.

I don't argue against having multiple ways of accomplishing the same thing - that should be limited but is certainly useful in many circumstances. The issue I have is designing different interfaces for the same feature because you can't think of a way to provide a common one for two use cases or user types. A classic example is wizards, which are terribly abused by Microsoft as an alternative to well designed configuration pages. These wizards don't teach the user how to actually configure the system, are often not reusable, and are only sufficient for a subset of use cases.

Another example is encouraging have customization of tool bars. Well designed menus and toolbars don't need to be dragged, dropped, renamed, etc. Allowing this confuses other users of the same software and makes fixing interface problems down the line nearly impossible without undoing all that customization.

Need to edit your user account? Do we need a different interface if you are an admin? Probably not - just a few more fields. Need a file chooser? The same one works for opening word documents as selecting a file for upload.

I've worked with designers who justify making multiple interfaces for similar functions. Frankly, this approach is almost always wrong and results in confusing interfaces and repetitive, difficult to maintain implementations.

Simplifying an experience to it's essence and ensuring that users learn quickly through consistency is key to design.

Bad designers are often quick to justify why two similar functions need different interfaces. Good designers understand that combining similar functions eliminates cognitive noise and creates the opportunity to add more features more easily and more understandably.

The author of this post strikes me as the bad sort of designer, one who views design as anything other than engineering and who justifies bad design with tortured "emotional" arguments.

Users are emotionally happy when they accomplish what they intend, understand and learn quickly, and feel confident they can repeat their result. Users are not happy when you force a single course of action through one-off behavior driven tunnel visioned design, leaving them confused and disoriented afterwards.

I've seen this before, and it is the product of egotistical designers caught up in their art instead of their users' experience.

Bill was right on this one. Windows interface sucks because it was not designed from the ground up with the user experience in mind by a comprehensive intelligent creator, not because it fails "emotionally" or lacks art.

I don't understand the debate about the stylus. You can buy many models of styli for the iPad. The fact that the thing doesn't ship with a $5 peripheral is hardly a detriment. In fact, it's an advantage - you get to pick your style of stylus - and they are cheap to replace. I bought one for $5 that goes on my keychain - if Apple made that it would be $30.

So, tell me again why there is any debate about why there is no stylus? Because there isn't a form-fitted hole for a proprietary styles? Because apps aren't designed for styli (the ones that need them are)?

Or perhaps it should be renamed, "Why the cloud IS for your startup."

This explains how it's cheaper to deploy on metal for high traffic sites, as if $1000/month in server costs in the event that my site gets massive traffic matters.

With Heroku, I can have a site up and running in minutes with zero sysadmin work and almost no monthly cost. Should my site get hammered, I'm happy to pay $1000, heck $3000 per month, for a few months should it be necessary to handle traffic until I get my act together to reduce costs on dedicated servers. At that price, you can be damn sure you get good support from Heroku.

Compare that to spending a large portion, or even a small portion, of energy and time that could be dedicated to building your product before you even know if you'll get traction - I'll take the cloud any day.

If sysadmin work is so easy to learn, or to farm out with money, it can wait until I need it.

What could possibly be worse? Anything actually malicious or greedy.

For all that GitHub has given to the developer community, an innocent mistake even of this proportion of incompetence is still should not evoke such hatred. And those upset about someone's account being suspended who was actively misusing security holes - well, maybe you should use a provider who looks positively upon reporting security holes by vandalizing customer data. And they suspended his account for only a few hours! Unreasonable? Hate inspiring? Outrageous? I think not.

And by the way, the fact the "issue" of the default had been reported 4 days earlier in a github issue tracker for Rails (which is certainly not followed, let alone on weekends, by github employees) does not in any way impact whether GitHub should have been aware of this vulnerability, and to suggest so is intellectually dishonest.

I agree there are a number of complex issues here, however that line of code still obviously takes ALL content from the outside world and directly updates a model with it. Any developer who does not spot that as a security issue is probably creating many others as well. Rails can not protect against developers not understanding that form submissions can contain any content and should not be trusted or applied directly to models without understanding what's happening. A cautious developer would slice up the submission to update the model with only the expected or allowed fields.

I just learned of the new role feature for attr_accessible because of this controversy. This seems to solve one of the major issues with attr_accessible - that different controllers and users need to update different attributes, so any somewhat complex app would end up widening it's attr_accessible attributes beyond what they should be.

These are still blunt tools though - what if only superadmin users can update a role column to superadmin, but admins can update it to admin or guest. This requires more extensive logic in the controller than simple attribute filtering, demonstrating why this filtering really belongs outside the model. Despite that, I think the new "role" based attr_accessible probably covers most cases and seems quite useful.

For all we know, GitHub may have been using attr_accessible but have expanded it to include columns updatable by admins.

Thank you for the thoughtful comment - perhaps there is hope that HN hasn't been entirely taken over by people talking out of their asses.

Totally agree. The problem is the idiom of using mass assignment, which IMO should almost never be used.

This is not a bug or a security hole in Rails, but an issue with programmers not paying attention.

If Rails had no attr_accessible feature, it would be standard practice to always filter attributes in the controller, and no one would call this a rails issue - they would put the blame where it belongs: Github.

Instead, because attr_accessible exists, people are flaming that it should be enabled by default.

Interesting. I work with Rails every day. I understand and explain the source of the bug, and why it has nothing to do with some oversight by Rails. I'm downvoted.

Every other answer, often admittedly, is written by someone who doesn't know anything about Rails, but jumps on the "oh geez Rails has a terrible security hole" bandwagon.

What has happened to this place?

This has been Rails behavior from day 1. Rails seems to assume that people will make some level of effort to secure their application before deploying to production. There are many ways and places to protect models, and mass assignment protection is a blunt tool that would not have worked for github, so the default behavior is not the issue.

This bug could occur in any framework where someone assumed all attributes submitted are writable by the current user. Rails has no internal concept of users or roles, so building that by default into a model makes no sense.

This is a github bug, not a Rails issue. One could argue it's a questionable, but defensible, decision in the Rails framework, to have such an easy way to take every submitted field and apply it to a model. I'd argue that using such a feature in a production app is a fault of the developer for failing to read their own code, because it's rather obvious and clear what the code does:

@product.update_attributes(params[:product])

Does exactly what you'd expect it to do.

The response to this makes me feel that HackerNews is now populated by a bunch of pretenders. This "bug" has been in Rails since Day 1, and any remotely experienced Rails developer is aware of this functionality. You can argue for a different default, but it's not a bug.

Github did have a bug and noone knowledgeable about Rails appears to have made even a cursory inspection of the security of their controllers - which is where attribute protection actually belongs, since different controllers and different users change different attributes. Protected attributes is a blunt tool for simple situations, which is why it's not enabled by default. Github had a pretty terrible bug, discovered, and fixed it. They may not have handled it perfectly, but the certainly don't deserve this sort of mon hatred - any competitor you go to is likely to have security flaws as well, perhaps more severe and subtle.

@homako didn't just expose the bug in github, he exploited it to make an unauthorized commit to Rails master. His account most certainly should have been at least temporarily suspended as GitHub had no idea what else he might do to prove his point.

So basically, most of the comments here are glaringly wrong or ignorant bandwagoning, and it makes me wonder about the accuracy of information here about topics I'm less familiar with. A sad day when you realize all this intelligent discussion you thought you'd been reading about new topics was probably just grandstanding by eloquent fools.

The first one on the list has not been updated since 2010, when it proclaimed itself "super buggy."

This article seems part of the recent trend of "top x" articles with zero research backing them up.

Because lots of people like to shop together with friends, and most ecommerce sites don't provide a good or even any experience for social shopping. Facebook or someone will eventually get this right. Pinterest is a down that path.

OTOH, I don't see a need for Facebook to necessarily be involved, since I don't think people shop with all their - just a few. Not being a social shopper though, I can't comment much more than that.

This is the first iteration of something I'm sure Apple will refine over the coming years. It's not surprising they haven't addressed the concerns of some applications, particularly power user and developer applications. Instituting a sandbox with user controlled permissions seems a solid step for usability and safety. For sure every feature will probably not ever be possible in a sandbox - for that we have regular installations which are not going away any time soon if ever. Apple is smartly trying to establish a trusted installation pattern for desktop applications resembling the experience on iOS, recent snafus notwithstanding.

So basically, it's notable that some applications are having difficulty with the first iteration of these new restrictions, but it's not surprising and I'm confident the issues will be resolved in time. Meanwhile, we've all survived without the App Store for a long time. I think these applications can survive. This is not the time for outrage.

It's time for a widespread revolt against domain name seizures and suspensions without due process. Where do we start? This path will undermine the internet economy and sets precedents for horrible oppression and control by large interests down the line.

> Even if you pinpoint my building, you don't know my name.

Is your name not Swizec Teller, as it says on your website and supposedly real name policy following G+?

Is there a reason to use any of these services given how trivial it is to set up an open source alternative? You can push errbit to heroku in 5 minutes and you're done.

Perhaps there is a level of service here and a business I don't see, and I'm a huge heroku and third party service user, but I don't see the need for a monthly service fee to aggregate and send exception notifications. It's either a self deploy or a feature of an overall monitoring service like NewRelic.

Not to be uncool, but I enjoy Facebook. I find it to be a fun way to stay in touch with connections, discuss, share, chat, etc. Sure I want data portability, but I believe that will come in time from competitive and user forces, and my life is not a protest. My online social activity is inane anyway - I don't care that much who stores it.

If you are worried about your activities being tracked and sold, stop using your credit cards. Have you read the privacy policy on those lately?

All this anti-Facebook pride strikes me as bitterness. Everyone has a right to do what they want, but would be all the wiser to look at themselves to understand why.

Facebook gives me more than I give Facebook - a lot more. When that stops being true, I'll stop using it. I too am kicking myself for not building a social network in 1996 - I'm not going to convince myself Facebook is evil because I didn't.

Any evolutionary biologist have theories on why our brains would be so underutilized? I wonder if there is a disadvantage to certain kinds of intelligence. Perhaps society works best when there is a variety of levels of intelligence, so there are larger numbers who are easier to lead and satisfied with less grandiose work. Maybe it has more to do with conserving energy or avoiding conflict?

If anything ever reaches "11 out of 10 on the pain scale," your body is probably telling you something.

For those of you in San Francisco or New York, I highly recommend One Medical - you can make same day appointments and they are super efficient and timely. It's a beacon of sanity in the absurdity of American medicine.

I do hope Google Plus is not the future of blogging. Much better to have stylized, distributed hosting with distributed syndicated commenting than the monotonous (and Safari on iPhone crashing) Google Plus.

It doesn't directly claim that, however calling these "The Five Stages of Hosting" implies that an application will likely progress through these stages as it grows, and that application platforms will be quickly outgrown when any sort of scale is reached. That's a pretty clear implication from the title and I'm calling for counter-evidence, because I don't think it's accurate.

I also host on Heroku applications that I hope will grow, and if that's a bad choice, I'd like to know others opinions.

Why is it that a well written site can't scale quite large on heroku? (or similar - I use heroku so I'm biased) Perhaps I'm naive, but I feel one can go from heroku to stage 5 if you truly have a blowout.

According to their website (http://success.heroku.com/) some pretty large websites run there, including Urban Dictionary and Rapportive.

Sure, it may cost more, but not more than a full time sysadmin and you are buying efficiency and flexibility. You can buy a lot at heroku for $10,000/month (the minimal cost of a full time deployment / sysadmin / dbadmin,) including I'd imagine some rather hands-on support.

This article seems to downplay the great advances that have been made in "cloud" deployment. IMO, a cloud service like heroku beats the pants off of self-operated virtual servers and debatably some of the higher "stages."

Really? If we waited until nuclear explosions were proven to consider ethical implications we might be in a very different place. Ethical considerations don't need to stop scientific advancement, but they always must be an ongoing part of the process.

That said, I'm interested in a maker kit.

Belittling others' successes is bad form and indicative of a a sense of entitlement and superiority.

Oink is interesting and beautiful, Kevin Rose is smart and decent. Your app is neither and you sound bitter. It is not surprising to an objective observer that you were ignored.

A little more humility might allow you to learn some lessons here.

Over a billion mobile only users will likely come online in emerging markets over the next ten years.

Many of those will be in India, where RIM is actually growing like crazy. I anticipate Windows on Nokia will be a serious player, and Android phones will drop to prices the masses can afford.

The race is not over and the "mobile web" may yet turn out to be the dominant platform.

Neither of those business models explicitly condones piracy. YouTube and Flickr also reward users for popular content. There is nothing inherently wrong with that, and it's entirely legal - as long as you comply with DMCA and don't knowingly contribute.