brynary

We are working on the UI for exposing it to OSS. The issue is right now we are not doing GitHub OAuth for OSS repos, so we can't know who should be able to configure the settings for t a repo. This is something we're addressing.

In the mean time, if you email hello@codeclimate.com we can configure it manually for your OSS repo.

We do have an "Exclude Patterns" setting that accepts a dir globs in the repo settings area.\

Edit: We also automatically ignore minified files. If you need a hand with anything please shoot us an email and we can help you out (hello@codeclimate.com)

Absolutely. It's all static analysis -- so we're pulling all the information we can out of the codebase without running the code. Under the hood, it's based on the Brakeman open source tool: https://github.com/presidentbeef/brakeman

It looks for all the big issues (XSS, CSRF, SQLi). In many cases it means keeping track of where user input enters the system (e.g. params) and how it is eventually used. So if you interpolate a param into a string and then give that string to ActiveRecord, it will produce a warning with high confidence you're vulnerable to SQL injection.

We run it every 2-3 hours on your repo, then look for new things that come up and send out alerts.

More info about Security Monitor is here: https://codeclimate.com/security-monitor

If anyone has any questions about Code Climate, Security Monitor, or how all this works, let me know.

I wrote up a detailed explanation of the issue and how the proof of concept works here: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod...

Using BCrypt for them provides a layer of protection against brute force attacks, no?

I wrote about that bit in my previous post:

http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-i...

But really, in short, don't worry too much about it. Plan on reorganizing once or twice as you find what works for you.

-Bryan

Yes! Gradual is they key. Your architecture should scale up gradually to handle the app complexity.

Good points/questions. I'll try to respond to each...

* RE: Strategy pattern. My understanding of the strategy pattern is it simply refers to "algorithms are encapsulate and can be selected at runtime". (http://en.wikipedia.org/wiki/Strategy_pattern)

* RE: New class per object query. Agreed that grouping these can make sense. Had to keep the example brief.

* RE: Events. That's another approach -- thanks for the suggestion.

* RE: "View Model" vs. "View". I had it as "View Model" in the original draft and got feedback from reviewers that they are usually called just "Views". :-) I've heard it both ways .

Thanks for the questions!

-Bryan

That's a great summary. It's easy to lose that meta-awareness, even if you're an experienced coder. You are holding a hammer, and the nail isn't going in, so your first instinct it "hammer harder". But usually it means you need a screwdriver.

That's a good point. It sounds like what you're describing is essentially a Facade. That can be useful if you need coordinated objects to manage complexity, but want to keep it simple for clients to use that part of the application. I sometimes create a Facade for a Ruby module that is a package of fine grained classes.

Not all apps require these techniques to stay maintainable. My background is working on larger Rails apps, built up over multiple years by teams of 6+ people, so the post is shaped by those experiences.