He's not saying open source is categorically awful, but that there are awful things about it. Pointing out these deficiencies is a way to foster communication to fix shortcomings that may exist in the community. You're right, FOSS has allowed a great many things to happen, but that doesn't mean FOSS and its methods are perfect. Continually revisiting and refining processes should be at the forefront of FOSS.
I would think the code base suffers as well. I'd tend to avoid code reviews, or at least not actively seek them out, if public humiliation was par for the course.
"While the primary function of the black box devices would be to record and transmit data that could be used to assist a driver and passengers in the event of an accident..."
I'm not even convinced the primary use case is helpful. Most people have cell phones nowadays, and sometimes systems like OnStar. Furthermore, who is going to handle the data (storage, responses, etc.)? How much money are we going to spend on this? Scary monitoring implications aside, this seems like a terrible idea.
I agree with the "it's just a tool" sentiment in general, but what other great alternatives are there? I haven't had a favorable experience with SOAP, so I can understand why people think REST The Best Thing Evar. This is based on my own experiences, so I may have used SOAP wrong, misunderstood its intentions, etc. Do you have any examples of when SOAP (or another technology) is preferable to REST?
You can write RESTful SOAP, I don't think the two ideas are perpendicular. The problem with SOAP is more implementation than spec - PHP SOAP is different from .NET SOAP which is (slightly) different from Java SOAP, which leads to headaches.
REST is just a style of API. You can write a JSON API that isn't RESTful just as easily, and in some cases a RESTful API is not warranted.
Do you have an example of RESTful SOAP? I think SOAP's lack of situational HTTP method adoption (i.e. it uses GET or POST for everything, vs DELETE/PUT/etc. when appropriate), and the fact that it wraps another envelope around an already available HTTP envelope makes is hard to deem any SOAP implementation as RESTful. I'm not trying to prove you wrong, I'd just like to see an example (a quick google search yielded nothing for me).
REST was initially described in the context of HTTP, but is not limited to that protocol. You could write a RESTful SAML in SOAP in JSON API, if you desired.
Fox Sports has a pretty restful XML API. I can't remember if it's SOAP specifically, though.
Nope. Guy's got it right. 'Perpendicular' (or 'orthogonal' if you prefer), meaning that the concerns are on separate axes, and thus independent of each other.
SOAP is a bit weird because it's both an envelope/delivery mechanism as well as a discovery/interface negotiation methodology.
REST is just straight up a set of interface design principles. It doesn't care what you're delivering, it doesn't care about the channel you deliver it through.
That doesn't make it impossible to do. REST is traditionally implemented on HTTP, but the core goals and methodologies could be implemented over any protocol.
The "other thing" for us is is RPC and PUB/SUB patterns over sockjs (which wraps Websockets+fallbacks).
REST is a tool. But given an engineer a tool like a hammer and pretty soon everything will look like a nail. Sometimes you need a screwdriver when you actually have screws. Hammering them in will work but it is ugly.
Yeah I considered PUB/SUB as another alternative, and it makes sense to use it for realtime applications, but I'm not sure what else (due to my ignorance, not necessarily PUB/SUB limitations). As for RPC, isn't SOAP the successor to that?
> I continually hear stories (friends of friends, of course) of people hitting it big and wonder if I just don't get it.
For every hitting it big, there is an opposite (and often larger) story of losing it big. Often by the same people -- except they are happy to tell you about their wins and don't talk so much about the losses.
It's not even a zero sum game -- the fees and spreads ("friction") are non-trivial.
Cool idea! Is it mainly a science/tech directory, or do you plan on incorporating other online learning resources (like language learning sites/books/etc.)? It looks like mainly Khan Academy results show up for me. Also, you have "Communication" as an example search term, but it doesn't return any results.
Thanks! No, we'll try to cover all topics. That's just the beginning and resources like Khan Academy are highly respected and useful, that's why included it from the start.
As for the search term, the search algorithm isn't perfect yet, working on it :)
A manager from Namecheap said that there's a deal when you transfer 50+ domains. You might be able to work something out with them for 20+, but the manager didn't respond to a request for a 43 domain transfer, so it seems unlikely.
Someone could ask Namecheap to allow people to "bundle" a transfer to hit their discount levels. Enable customers to get together and transfer all their domains from a single registrar like GoDaddy all on the same day. Customer Foo has 43 domains, customer Bar has 7 domains, they both transfer all of these domains on the same day and both key in a bundle code. They both show up in the same transfer bundle, so both get the 50 domain discount.
The bundle code could be an extension of the discount code, like Foo would enter BYEBYEGD:Email-addy-of-Bar while Bar enters BYEBYEGD:Email-addy-of-Foo. That type of structure would limit the bundling to two customers coordinating with each other (so Namecheap doesn't lose out on handing out too many discounts). Other structurings of bundles are possible, of course, depending upon Namecheap's internal sales and marketing goals.
