platinumdragon

That was exactly their implication. "We don't go for that open source crap" is a motto of theirs. Usually it's just obnoxious. This time, they just happened to blindly fall on the right side of the line.

"Sites that use OpenSSL will display a small “lock” icon in the top left-hand corner of your Web browser’s address bar (though not all sites showing this lock use OpenSSL);"

This sentence physically hurt to read. I seriously hope that Google Translate wrote this.

Until Atom does something for other than Mac, it's just an experiment and not a real tool.

Does this article cover anything that the previous ten articles over the past two weeks have missed? Just curious...

Also, your website is unreadable on mobile due to that damn sidebar.

Not on Chrome for Android. Yes on Chrome for Windows. However, it's been years since wired.com has been relevant, so it won't be missed.

Post doesn't even touch on the subject of the title, and you have a typo where you ask for new challenges.

Wow, amazing article! Thanks!

Would be interested in at least reading, but your stupid floating share bar covers the text on mobile.

I love how it's completely unreadable on mobile. Try clicking on the feedback button and none of the options are selectable.

I have a hard time seeing them adding more useless crap to their interface as beating anyone.

This is exactly the method I advocate at work. The package private access type is perfect for testing. We have a small reflection library for use when package private isn't appropriate, but it just isn't that often.

It looks nice with the syntax coloring, and it's obvious a good amount of work went into it, but I personally don't see a clear benefit to altering my workflow to save what appears to literally be a couple of characters over a transaction.

What might be interesting is being able to import and export configurations to standardize git usage across multi-coder projects?

I am definitely a victim of this as most engineers would be, particularly those of us that have been working for others. We're accustomed to being handed the business need and simply told to build it. As such, that whole "does this make business sense" part of the equation doesn't come naturally for us.

I don't get it. What's with the clouds always obscuring all or part of the pictures we're supposed to identify?

What type of error are you seeing? I can successfully bring the page up and register my email. (It's just a basic landing page atm)

I've (just) started 1701.io (http://1701.io) to rethink enteprise applications and make them applicable to projects of any size and budget.

"...to do anything else but uploading the game."

What? Is he sticking a copy in the mailbox for everyone who downloads it? I hope that's a translation error, because it simply makes no sense.

Very nice! I was going to give my vote to the guy who cured cancer, but this has more meat to it.

Pretty asinine that I can't even read about what snapbugz is in my mobile. It might be the greatest thing since sliced bread, but I'll never use it, because I tried to find out more info and got slapped in the face for it. If it were of interest, then I would email myself a reminder to use it on desktop.

Stop linking to pages that don't exist...

I'm pretty surprised to read such uninformed comments on hacker news, but then I'm relatively new the community.

Yes, RPC is better suited for complex abstract actions where you don't have a resource as a context, whereas REST is better suited for resource-based access and actions. Both should have a place in your toolbox, and to say that one is superior to the other is simply trolling for a religious war.

REST is not relegated to CRUD, and is being grossly misrepresented when it is said to. SQL is a scripting language, not a RPC or REST API. If you can make SQL into a RPC, I'd love to see it. It must be absolutely nasty.

RPC is great for situations where you don't necessarily need an answer, or the answer is so abstract that it doesn't really relate to a specific resource. The great thing about RPC is you usually have something like a WSDL that many tools can use to generate your client code for you. It makes it very easy to implement into your client project, but can be very brittle, as any changes to the WSDL will break the client.

REST is great for when your actions revolve around resources, whether they be actions or access. Not everything needs to be relegated to the URL. You can post or put just about anything in the body, including SQL if you were so inclined (please don't ever do something like that). The thing about this is you're using the resource in the URL as context, so it's a different way of modeling your API. Though there is WADL and a couple of other standards for describing a RESTful service, none of them are well accepted and there is poor tool support for generating client code for you. This is a disadvantage in that it forces you to roll your own code (which probably averages about 5 lines per call), but is an advantage in that you can easily follow a "tolerant reader" methodology which makes your client highly resistant to API breakage.

If you're smart, you'll use HATEOAS in your responses. It may not be used by all clients, it's up to them, but it does allow flexibility if they do use it. We've had great success with it at the Fortune 100 company I work for.

I agree that many people use REST as a marketing term and don't fully understand it. Those who do though are using it successfully and enjoy when the opportunity to use it for their project. The important thing is to remember that both are important and not try to fit one into a hole that calls for the other.