Ibrahim Balic breaks silence on hacking Apple developer site

1. Instapaper was very popular.

2. Gruber links to him a lot, and he writes well. More cynically, he has modeled his writing style after Gruber's, so if you want more of a Daring fireball fix, you read Marco.

I don't think Marco's opinions really hold anywhere near the weight of John's. Some just have an appreciation for this style of writing.

Taking the 73 accounts is arguable in court.

Once you cross the line and scrap another 100K users in order to get their attention and shut the developer site down - you've just boxed yourself. There is no really no defense for doing something like this, regardless of your motives.

Look: WebObjects was amazing at the time. But have you used it recently (meaning in the last several years) to write something? Because it's almost literally impossible to write something that looks modern and acts modern.

WebObject was designed to hide web development as much as possible from the developer. I.e., to make writing desktop applications and web applications as similar as possible. You'd make a view in HTML, a controller in Objective-C (or later Java), draw connections between them just as if you were making something in Interface Builder, etc. Basically, HTML just became another OpenStep view you could target.

The downside of hiding the web part of web development as much as possible is you get a technology that is very far removed from modern practice. To achieve the view/controller design pattern above, WebObjects effectively effectively uses a continuation-like pattern to hide the whole HTTP request/response loop. That's why WebObjects URLs are disgusting beasts: they tell WebObjects what state corresponds to what you're doing. ASP.NET WebForms does this same thing, by the way, although it slaps its data (called ViewState) into invisible form elements on the client-side, whereas WebObjects stores its state server-side. Former inflates the page by 30k in even simple situations, latter makes the server need tons of RAM, but they both get you to the same place, and about equally well.

The problem is that's not how you write web apps these days. If you're doing a simple-as-tea CRUD app, then sure, whatever, but you could also just publish your FileMaker or Access database to the web and be done with it in that case. And for everything else, WebObjects, unlike even ASP.NET WebForms, makes it virtually impossible to have clean, trivially usable REST endpoints, which means you can kick your responsive client-heavy web app ideas to the curb. Yes, you can work around it, and ProjectWonder provides some tolerable solutions, but you're really fighting the framework the whole way. Why bother?

I'm also highly dubious that having Objective-C on the server is really a good thing. All those pointer errors you make in your iOS app that generally just result in a crash suddenly result in your server being rooted. Memory fragmentation becomes an insanely huge deal, since Objective-C's GC is primitive, and so on and so forth.

EOF was great, and would probably still be great. WebObjects was a great idea at the time, but that time has gone.

Always try to do a parallel without computers to see if a computer law pass the retarded test.

In this case "it's illegal to enter a door left wide open for months, pick up a wallet full of money from a desk visible inside thru said open door, and return it to the home owner with all the money and a note about closing the door because it's not a safe neighborhood"