I'm currently trying to buy a pair of shoes on amazon, and many reviewers are calling out the fact that after giving the shoes a five star, they go to buy a second pair of the same shoe to find that it is completely different and of terribly quality.
I actually owe my programming career to MTM. When I was ~10-11 years old, I held many tournaments. At some point, my tournament grew to the point where I couldn't manage signups day of, and tried to make a website using frontpage + some form of extensions (angelfire? tripod?) to have early signups. I eventually learned javascript and a tiny bit of perl.
Looking back at that point in time, I did a horrible job of managing those tournaments (Sometimes my pre-teen responsibilities took priority and made me miss some tournaments. Oh and I seem to remember storing passwords in clear text). However I look at myself today and am extremely happy to be a successful developer, which may have never happened if it hadn't been for the MTM1/MTM2 games and websites, which I am certain I probably copied a ton of "codes" from back then.
You hit my opinion exactly. I love to hate/hate to love meteor because of how easy it is, but I just can't come up with an easy testing scheme outside of full out integration test, or making some separate modules that are injected. Thanks for the link.
If you are worried about cost, just run it on a subset of your servers. 10-20% of your servers should be enough to gather most information you need... unless you are using new relic as the only aggregator of server status/monitoring... and that should be heroku's job.
We were battling a specific type of Heroku error (H12) that really required all of our dyno's to be monitored. We turned NR off and went with a (much) less expensive service that ended up telling us exactly the information that we needed across our entire cluster of machines. Hopefully with this extra cash, NR can improve their service because I honestly wasn't that impressed. It didn't live up to the hype at all for me.
There are cases where startups, social impact organizations, or any fast moving team would pick rails for its fast movement, accessibility, and support, even if they thought that there were even more security issues than that have happened.
Security is not something that should be traded off just to reduce development time or effort slightly.
Regardless of the situation, it's much more responsible to focus on doing security properly, while cutting corners on the UI, documentation or other less-critical areas of the application. Those are generally the kind of updates that can wait a little while. Implementing proper security should not be done via updates or patches "later on" in the project.
There's always a tradeoff between security and other variables. There's no such thing as 100% secure, so where you make your stake in the spectrum of security depends on your business domain. Just as you have different engineering requirements when building a spaceship vs a prius, you have different software practices for different types of projects.
Consider physical security against terrorist attacks. You can spend unlimited resources trying to prevent these. But this is subject to diminishing returns, and has other costs.In software projects, too, there IS a point at which it is more rational to trade off security against something else.
I would argue that the situation with Rails is analogous to the (historical) situation with Windows. There have been some design mistakes which have opened up more surface area for attacks. But the number of exploits has a lot more to do with market share.
You are more than welcome to use Metasploit - a lot of our customers didn't want to go through the trouble of setting up their own Metasploit config, etc., so we built this to give them a simple quick check.
Why bother with something this elaborate? I ran a Metasploit scan on the /24 network that my Linode is located in and turned up 4 vulnerable servers in a matter of minutes. If someone were hunting for vulnerable hosts, this form would be a really inefficient way of finding them when you consider how easy this is to discover using simple network scans.
