[phillmv]

> It forced me to learn all these issues and understand them well enough to be able to customize each and align them with a products design.

This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails - but just because something is more fun doesn't mean you're going to get all these details right.

The attack surface in modern web apps can be such a large search space that the majority of people will never get it right. The point behind frameworks is that you can engage in efficiencies in scale when it comes to sensible defaults; even the most well seasoned and security paranoid developer can drown in the cornucopia of details that all have to be done right.

[whyme]

> This is a standard developer response

vs. a what? I've worn many hats in my day, the least of which has been a developer hat.

There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand.

I'm all for having a framework, where you can review the code and be comfortable with what you're relying on, but in the absence of having a good one, well then build one. The benefits Clojure brings to the table more than make up for the work in either case.

There's just no excuse for not knowing the concepts and not knowing if your product needs them.

[phillmv]

>The benefits Clojure brings to the table more than make up for the work in either case.

No one's saying "stop using clojure". The argument here is "build a clojure framework lots of people use".

>There's equal risk in relying on a code base incorporating features with underlying concepts that you or your team does not understand.

You do this all the time. I mean, I understand on a high level what my computer does but I can't describe to you the exact tree balancing algorithm my filesystem uses, how my CPU performs cache invalidation and branch prediction or even how exactly the JVM works.

Computers are too complex to not rely on underlying concepts you or your team doesn't understand.

The point is, within just the context of a web developer developing a web application there is too much stuff to know to always get it right. We need to reduce the number of things people have to think about, or else we'll always miss something.

[whyme]

> The argument here is "build a clojure framework lots of people use.

The argument I am addressing is that people are deploying products with poor security because a great, all encompassing, framework does not exist. There's no excuse for doing that.

This is not about having to understand cryptography, it's about knowing when and where you need to use it and making sure it's included when you do. The issues outlined in the video are trivial.

[phillmv]

The excuse is precisely that there isn't a great, all encompassing framework.

Setting up a scenario where everyone has to get everything right all of the time is setting everyone up for a lot of heartbreak.

Having bad password management and opening everyone up to CSRF and XSS is not "trivial". They're gotchas, and looking out for gotchas is a waste of everyone's time.

[whyme]

When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me. That goes for using a bad framework or lack thereof.

As I said, I'm all for having a great framework, but I would not excuse the mistakes being made here, and I'm simply saying that I believe that my products and my knowledge level benefited by not having one.

> Having bad password management and opening everyone up to CSRF and XSS is not "trivial".

I'm not suggesting everyone should need to be aware of these issues, I'm saying someone on your team should be. And if you're a team of one, be prepared to make mistakes (which will not be limited to the issues outlined here).

[phillmv]

>When I make mistakes, which I often do, I don't go around thinking oh, darn, they should have known that for me.

Well, you should! These are mind numbing details that are best taken care of by other people. I am too concerned with building a good product to want to spend too much time going over mind numbing details.

The argument from "I become a more well rounded developer" is valid, but these should be things you learn once and then stop worrying about forever. There's a lot of magic in Rails, but it all goes away given enough time. Better abstractions are our bread and butter and we'll get nothing done if we continue to shy away from them.

[ryandrake]

Unfortunately, with security, you have to "get everything right all of the time" because the attacker only has to get their attack right once.

[phillmv]

I worded it unfortunately, but we're getting at the same thing.

What I mean to say is the easier it becomes for everyone to get everything right all of the time the more likely it is to occur.

Expecting everyone to individually know and understand every single gotcha is unrealistic compared to distributing the work load across a framework.

[mantrax3]

> "This is a standard developer response - I recall when Sinatra was a fresh kid on the block, and the same arguments people used against Rails"

And the more time passes, the more problems with Rails are being discovered that have to be altered in a non-BC way.

A library makes no assumptions. It's just there and you decide how to use it. In the right hands it's more powerful than a rigid framework.

A framework that tries to teach you how to do things is by definition a pair of training wheels. Not the best setup for competing in Tour De France.

The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.

[stcredzero]

The solution to incompetent developers isn't a bigger, more rigid framework. It's education and training.

In aerospace, it's understood that better training can be part of the solution, but often better instruments and interfaces and well designed automated tools can be lifesaving as well.

[mantrax3]

Of course, and in software development we call these instruments, interfaces and well designed automated tools libraries.

A framework in aerospace would be more akin to a pre-built airplane with a bunch of holes where you put seats, in-flight entertainment consoles and other auxiliary non-critical equipment (because remember, airplanes are scary and you were told you can't do it yourself). Then you paint it and stick your logo on it.

Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is you cooking. And just like warming up TV lunch doesn't make your job title a "chef", I don't believe people relying on frameworks to do the hard thinking for them deserve the title "architect" or even "senior developer". Which, again, is all fine, unless you or your boss are kidding yourselves about it.

And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework". And NASA's space mission based on that framework isn't going too well, either. Whoops. Turns out frameworks aren't one-size-fits-all.

In a nutshell, apps have to be architected by competent architects, using simple, modular, does-one-thing-well libraries. These people know how to achieve scalability and security taking the particular needs of the app at hand.

The presenter in that video said that making assumptions is dangerous. There's no greater assumption than the fact a framework is right for your app, without understanding what this framework does under the hood. And there's no type of component making more assumptions for your app than a framework. Rails calls it "opinionated". I call it: you're the framework's slave, not the other way around.

There's no way around it. I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of the framework mentality is a bunch of people making beginner mistakes and getting hacked all over the web.

[stcredzero]

And then one day the military, say, realize they now have a bunch of useless "military jets" built on top of a "passenger airplane framework".

The He 111 started out as a civilian plane, then became a bomber. But to be fair, it was always a bomber masquerading as a civilian plane.

http://en.wikipedia.org/wiki/Heinkel_He_111

Which is all fine, if it does the job for you, but you're not designing the airplane, anymore than microwaving TV lunch is cooking.

I don't think this is a very good analogy at all, unless it comes to something like App Engine or Heroku, and I'm not sure even then.

I know when Rails came out the hype was so huge, that everyone believed they and their dog can write big complex web apps. Nope. The only result of that is a bunch of people making beginner mistakes and getting "pwned" all over the web.

The smart move would've been to see this coming, then intervene, thus cementing that big huge groundswell of mindshare with better informed members of the community as a result. The thing is, we programmers are more apt to act like old-time barnstormers and solemnly shake our heads at the pilot who stalled and crashed, than to invent stick shakers and automated stall warnings.