LendingHome | Senior/Staff/Principal Software Engineer | Full-time | San Francisco, CA & Pittsburgh, PA | ONSITE VISA
LendingHome is reimagining the mortgage process from the ground up based in technology as a simple, fast, transparent marketplace for borrowers and investors. We’re chasing the goal of being the best way to get a mortgage and the best way to invest in them.
IBM Watson Group creates products and technologies using Cognitive Computing to solve real problems, from winning Jeopardy to assisting doctors. Watson does this by analyzing massive amounts of structured and unstructured data. We are on the cutting edge of technology working to change the world.
Our team within Watson Group works on Watson Explorer, a web application enabling data exploration and visualization. We are looking for senior and junior front-end developers to join us.
How we work:
* Open and collaborative office environment - you will not be stuffed into a cubicle and left alone.
* Software craftsmanship - pairing, Test Driven Development (TDD), small commits in Git, Gerrit code reviews, continuous integration and deployment, daily standups with progress visualization
* Technologies we use - CSS (Sass and Compass), JS, JRuby on Rails, and Java
What you'll do:
* Develop full-stack web applications
* Work with designers and researchers to translate users’ needs into reality
* Influence design and direction of product
Want to come work with us? We're interested in you, too! See all of the positions below:
IBM Watson Group creates products and technologies using Cognitive Computing to solve real problems, from winning Jeopardy to assisting doctors. Watson does this by analyzing massive amounts of structured and unstructured data. We are on the cutting edge of technology working to change the world.
Our team within Watson Group works on Watson Explorer, a web application enabling data exploration and visualization. We are looking for senior and junior front-end developers to join us.
How we work:
* Open and collaborative office environment - you will not be stuffed into a cubicle and left alone.
* Software craftsmanship - pairing, Test Driven Development (TDD), small commits in Git, Gerrit code reviews, continuous integration and deployment, daily standups with progress visualization
* Technologies we use - CSS (Sass and Compass), JS, JRuby on Rails, and Java
What you'll do:
* Develop full-stack web applications
* Work with designers and researchers to translate users’ needs into reality
* Influence design and direction of product
Want to come work with us? We're interested in you, too! See all of the positions below:
ONLY if it's important to you that one process be able to run multiple threads on multiple CPU cores concurrently.
Even without this, there are MANY use cases where multi-threaded concurrent request dispatch makes a LOT of sense. For instance, the recent controversy about heroku routing, right?
With MRI or another interpreter with the GIL, you'd want to run one app process per CPU core -- but having each of those processes also do multi-threaded request handling can still even out latency (that is, avoid those awful ~95th+ percentile latencies in the heroku routing debacle), and increase overall throughput.
Especially if your app, like most but not all web apps, is more I/O bound than CPU bound (waiting on DB, disk, or external APIs).
Matz likes the fact that it Just Works and you can't accidentally have weirdness based on how your code runs. There aren't any plans to remove it at this time.
That's true, but I don't buy that argument: look at how fast everyone has updated their gems to be Ruby 2.0 compatible. The Ruby world likes running on the edge; if MRI forced us to consider thread safety, we'd learn about the issue much quicker as a community. Since we'd be forced to. ;)
What I want you to see in that thread I mentioned is the
way the core team perceives this. You are not discovering
anything unknown, we already know this stuff and we like
attr protection to work the way it is.
Looks like this guy got really frustrated with the Rails devs basically saying that he didn't know what he was talking about. This reminds me of all of the unsafe defaults that PHP used to have. Same justification too, "it's a config setting, so it's up to the developer/sysadmin to read the docs and set them right."
This justification seems especially odd to me since Rails did so much in the first place to popularize the idea that the default behavior should be the one most likely to be "right". Don't they (or didn't they at one time) have a mantra "convention over configuration"?
This also makes it all the more serious. As the PHP developers found out the hard way:
When you make it really easy to get started, a lot of people won't learn the system in depth enough to understand all the issues because they don't need to in order to make it work "well enough" for most cases.
By making Rails so easy to get started, they pretty much guarantee that there's going to be a ton of developers that don't pick up on, or forget, that they need to deal with issues like this.
That even a site like Github was vulnerable to this demonstrates just how seriously wrong it is to pick a default like this..
This guy brought up the vulnerability and the maintainers didn't seem to take it seriously since he wasn't articulate enough or was not approaching them with enough respect maybe for their liking? I wish they would have kissed his ass a little to get the low-down on the vulnerability so I didn't have to worry about my company's private github repos. He deserves props for bring it up for discussion.
This has been discussed since the early days of Rails, and they have chosen to leave their defaults as such and encourage developers to implement model security as needed. Github (seemingly) did not implement model security. This is a vulnerability that is different from application to application, and if the team was following best practices, is not there.
If it's a simple mass-assignment vulnerability, the Rails team has nothing to do with it given that mass-assignment is a feature and the vulnerability is well documented:
The fact that this is even a discussion is sufficient for me to consider it a bug. It's irresponsible of the Rails team to leave this default the way it is given that it's long been a known risk.
That they like to consider it a "feature" doesn't make it any better - it just makes them look like idiots
Er.. that's because there's nothing malicious an attacker can do with the mass-assignment vulnerability in the "Hello Rails" app?
Being able to change the :id or timestamps of the post isn't anywhere near the SQL injection vulnerabilities I've seen in many tutorials in other languages/frameworks.
I agree, though, I wouldn't recommend Rails to people who can't bother to read documentation.
