Haters will always hate. Keep up the good work guys! People seem to think they are entitled to something when using open-source software, but they're not. It's still the people working and maintaining it who get to take the decisions, and if you guys think you need analytics to provide a better tool, go for it.
I also completely understand the need for default opt-in. I probably wouldn't check the prompt and leave the default, but for a project like this, I honestly don't mind sending usage data.
If you're not happy with the direction taken by the maintainers, find another tool.
The team behind Brew is doing a great job and if analytics can help them do a better job, then be it. Nobody is forcing you to use it and opting out is simple enough.
Yes, I know about this model but it wasn't made by Fielding and he made his positions pretty clear about what's RESTful and what's not.
I do agree that this model is a good set of steps to build better APIs but then, how do you call them? RESTful Level 1 API?
My point with this article is just to call API what they are (usually just HTTP APIs). I'm totally against the use of the REST buzzword these days since it doesn't mean much anymore: everyone has a different view on it.
The link you gave is pretty good. Note however, that in this article I wasn't trying to explain in details what is REST.
What I want is more to let people know why their APIs are not RESTful so they can use the kind of resources you gave to actually learn more about REST.
Take one of your RDS daily snapshots (which you're taking of course), and recreate a new instance from it. Point your app to it, and you should be good.
Yes, you can just use Rails as an API and create a frontend SPA. But in my opinion, it's faster to write in the 'old way' for a MVP instead of creating 2 different applications (one frontend, one backend). For the future, I'm actually thinking about rewriting the frontend using SPA technologies.
Way faster. We are using a rails API and a React+Flux app as a front end. The whole setup time alone is a considerable pain. I feel that the JS tooling is still too fragmented and sometimes messy, but I'm probably biased by years of rails and iOS development.
Writing the app takes more time since you need to write everything from the ground up (e.g.: no Devise views to just style and forget), but I really hope that in the future the investment will pay. I wrote about it a while ago (although now we are using the more terse Alt implementation): http://fancypixel.github.io/blog/2015/01/28/react-plus-flux-...
Completely agree - just setting up a workable environment for webpack is a disastrous exercise. Even things like cache-busting signatures, etc are a implement-it-yourself deal.
You're probably right indeed! I was just looking into refactoring some code, found that and thought it was pretty cool. Plus Rails comes with CoffeeScript by default.
ES6 is pretty sweet (pun intended) and will probably make CS kinda useless in the future. I'll look into it however I think that currently CoffeeScript is a bit of a standard in the Rails world.
That is a fair point, if I'm using Rails I actually just use plain old JS as I don't personally like CS.
I just found a comment by a Rails contributor [1] which says ES6 will be supported out of the box in Rails 5, which would be ideal. I can't find anything newer to back that up though. I think it might be via ES6 support baked into sprockets.
I also completely understand the need for default opt-in. I probably wouldn't check the prompt and leave the default, but for a project like this, I honestly don't mind sending usage data.
If you're not happy with the direction taken by the maintainers, find another tool.