A good SOAP library lets you plug in a WSDL and returns an API object with all the methods of the webservice. There is literally no equivalent capability for REST. You shouldn't be doing any of the things you describe by hand.
You are vastly oversimplifying when you say "with REST you just have to figure out a URL". Try integrating with a service that takes only custom HTTP verbs with multipart/form-data but because there's no standard way to send an array in HTTP you have to append some parameter multiple times but in the right order. There's some vague attempt at using OAuth for authentication, but it doesn't work with any of the libraries you are used to. Oh, and the service returns a 503 some of the time, which (according to the rambling hacked up docs for this API) means you should retry your request in 10 seconds. No, it's not always trivial.
Anybody that tries to interface with a SOAP interface by writing envelopes by hand is wasting their time and half-implementing the (long, terrible, complicated, blah blah) spec.
Find a good toolkit. Yes, the protocol is way over engineered but good tools can and do abstract that all from you. For instance, PHP's standard library lets you plug in a WSDL URL and consume SOAP services in two lines of code. (And because it is a good toolkit, it lets you spit out all traffic with one debug flag, unlike whatever terrible thing the author of this article is using.)
Most of what people complain about in these comments would be moot with good tools. You would probably complain about REST if you didn't have curl or Firebug and had to telnet all your test calls--that's equivalent to what most people here seem to be doing.
And they should. It's easy to turn a WSDL into an exhibit for a contract, because it is a description of an API that can be converted to human readable and machine readable formats. There is no equivalent for REST, and most REST services have a loose interpretation of what it means to be "RESTful". Try doing serious, paid-availability integration with REST and watch the managers tear out their hair and the lawyers weep.
The only issue I have with TotalFinder--and I paid for it a while back--is that I would love to have the freeform visor mode, but have it correctly pop above the dock as it does for full-width instead of overlapping it. I know it's in your buglist but thought I'd mention it since you're here...
The best "power replacement" for anything on OS X is not an app, it's a piece of hardware: an SSD. If you still have a hard drive, go get an SSD replacement--it makes a world of difference for OS X performance. I couldn't imagine going back. I see some people in this thread talking about how this or that is slow and I can bet that for most of them, a $200 SSD would change everything.
What use is the social captcha if your friends list is public? Many people had this set because it was the new default when the settings switched some half-year ago. A lot of them probably don't even realize it.
You can read about 8 characters at a time, but since most SMS's are pretty short if you have good fingers and get used to the buttons it's not as bad as you might think (kind of like a pager). I know a guy that uses this phone as his primary. For composing, there's no T9, btw.
I think the main difference for me between this and Selenium would be that Selenium offers some macros to click an element, or simulate a drag and drop between two elements. If you added those in here--wouldn't be too much more, I don't think--you'd have a competitive testing framework, albeit Webkit-only.
Two other Mac projects that bring the excellent Google Chrome tab UI into other contexts: TotalFinder, a Finder mod that adds tabs to Finder windows (http://totalfinder.binaryage.com/), and Kod--still in beta--which will be a text editor somewhere in the ballpark of the mythical TextMate 2 (http://kodapp.com).
Whoa, this is by far the most interesting news here. It occurred to me that an evil government could hijack all HTTP requests, slip a script into the <head> and literally monitor every keystroke and click and mousemove for their web users, using their browser as the key logger and with little knowledge by the end user (unless they scan the source of every script). That's freakishly powerful spying capability, beyond just tracking and logging requests/IPs/contents.
I'd agree with you on this; this kind of markup+CSS does not exactly say "toggle button" to the next coder to read it. The most problematic thing, actually, would be that the toggle action hack used here changes window.location.hash and the back button goes through every state change. Probably not desirable behavior and it would take yet more hackery to fix it.
If you have a rather large monitor, that might put your terminal at a ridiculous size. For quick access to Terminal.app, Quake console style, I use Visor, which slides it down from the top of the screen on a global hotkey:
And that sort of sandboxing would prevent a theme from hiding some spammy HTML in its code? I can think of many ways to do that, some of which don't even involve templating-level functions and just rely on the HTML level alone.
You're comparing apples and oranges here. You can run PHP in "safe mode", as many shared hosts do, to prevent shell access and disk access by PHP code.
The only problem here is one of misplaced trust (and perhaps WordPress allowing PHP in templates instead of using a dedicated templating language). People installing WordPress templates generally a) don't care where they come from and b) don't even read the source code, so this theme could probably include such links without any obfuscation and still successfully spread.
OK, I would like you to introduce me to a programming language where installing source code downloaded from an untrusted website on the internet does not come with security caveats. Care to do so?
The web is a wonderful thing, but I don't envy the lot of browser makers. Every once in a while whenever I have to replicate some portion of the whole HTTP/HTML stack, like cookies or in this article content encoding detection, it becomes apparent what a disaster certain things on the web evolved into.
I think Paul was just about to enter college then, so he was old enough. My point is that it was actually quite forward-thinking to try out anything on the web in 1993.
It depends. If your API was built underneath your own site, then it's easy. FB's API doesn't seem to actually support anything on the main site, e.g., I doubt their own "apps" actually run on the FB Apps API. And there's no incentive for any of the engineers to build them like that, because they have such lateral access to internal code and data.
The difference between GET and POST is interface-related, not security-related. A better example for why you avoid GET for non-idempotent operations is to prevent a webcrawler from coming along and innocently making massive changes to your site just by following links. Security-wise, there's little difference between the two, it's trival for the client to change the type of request. (If I can't get some guy on a forum by embedding a picture, I'll send him a link to some website I control where there's a hidden <form> that posts to the site I want.) CSRF is only preventable by putting secret tokens in your forms that get echoed in the submission request (or by double-submitting the cookie as I do, but tptacek will be in here shortly to tell me why that is so silly).
OK, so according to him there's code review and some automated tests.
But that still doesn't address wide open access to the live DB by brand-new devs, and the complete disregard for having a dedicated QA team.
Why QA? I would think FB engineers are more busy doing real work at work than fooling around on their own site (heh, the irony) and finding out that Junior Dev 39's change to the thingamabob broke chat for the umpteenth time in IE7. And as many people have pointed out here, they are a platform for many other businesses now--there's no dogfooding that--and the API stinks in terms of stability and documentation.
So about 1000 people have unfettered access to all of the live data, but there are absolutely no safeguards against them modifying it, copying it elsewhere, or peeking at it? That's terrifying. I'm under the impression that Google has more a stringent philosophy about this, and even then, one of the few SRE's that they do give broad access to was caught stalking teens via GMail data. Imagine the range of bad behavior an FB engineer can get away with after just 4 weeks of "Boot Camp".
Part of the reason I never made a real FB account was my general feeling in 2005 that securing a MySQL/PHP site against internal abuse takes incredible effort, and they wouldn't ever bother to do it. According to this article, that's likely true. And the "everybody can modify anything anytime" philosophy with little QA explains why, after 6 years, FB is still a gaping maw of security holes.
If it's in JavaScript it's trivial for me to hack on the client side, and if you insist on mouse movements I can just send along a prerecorded array of mouse moves before my request. Maybe even tweak a few every time, so you don't catch on right away. It's more trouble than it's worth.
By comparison, PHP actually prevents you from using \r\n in your header() calls to inadvertently make multiple headers or break off into the body. It spits out a
Warning: Header may not contain more than a single header, new line detected.
Yeah, I don't think hard drives work like that. You can modally read or write at each head, not simultaneously, and the granularity has to be larger than a bit (maybe a byte?)