2011 Gotham Ruby Conference Videos are up

Better late than never.

On Mon, Aug 8, 2011 at 12:23 PM, Stephen S.
[email protected]wrote:

Better late than never.

2011 Gotham Ruby Conference on Vimeo

If you want to read abstracts to figure out which talks to watch, some
of
them are at http://goruco.com/speakers/

On Mon, Aug 8, 2011 at 12:23 PM, Stephen S.
[email protected]wrote:

Better late than never.

2011 Gotham Ruby Conference on Vimeo

I thought “Less - The Path to Better Design”, by Sandi Metz was
exceptionally good http://vimeo.com/26330100, it focuses on abstract
issues,
but in a very concrete way (ie it’s not one of those blogs/talks that
sound
great but leave you with no idea how to apply it).

Abstract: The concrete principles of object-oriented design are useful
but
are built upon powerful concepts that the principles tend to obscure.
When
design principles become goals in and of themselves, object-oriented
design
gets a bad name and applications suffer. This talk strips away the
well-known design principles and exposes the hidden, underlying goals of
design. It reveals programming techniques that allow you to write less
code
while creating beautiful, flexible applications. These techniques all
involve less. Doing less, debugging less, testing less and knowing less,
all
in service of achieving more.

On Tue, Aug 9, 2011 at 12:49 AM, Kevin [email protected] wrote:

I thought “Less - The Path to Better Design”, by Sandi Metz was
design principles become goals in and of themselves, object-oriented

That was a great talk. I found myself on the verge of tears as the
hell she describes when things go wrong is basically the application I
have to maintain at the moment. TT Though in my case I’ll be in a
good spot once I move the validations to the client.

If you’re talking about a web app, you should consider that there are
ways
around client side validations. If the validation is imperative to the
security or integrity of your app, then you should still check it server
side (and possibly even in the DBMS itself). In these situations, I
think it
is fine to “blow up”, though. The client side validations are useful to
give
a nice interface and ensure valid data with smooth interaction for the
user.
The server side are just to maintain integrity/security, if server side
blows up, I don’t care about it, it’s because of either a bug that
should be
fixed, or an insidious user, in which case 500 is probably better than a
polite explanation of the issue that gives them more knowledge.

On Mon, Aug 8, 2011 at 10:54 PM, Josh C. [email protected]
wrote:

but in a very concrete way (ie it’s not one of those blogs/talks that sound
in service of achieving more.

That was a great talk. I found myself on the verge of tears as the
hell she describes when things go wrong is basically the application I
have to maintain at the moment. TT Though in my case I’ll be in a
good spot once I move the validations to the client.

On Tue, Aug 9, 2011 at 8:07 AM, Josh C. [email protected] wrote:

The server side are just to maintain integrity/security, if server side
blows up, I don’t care about it, it’s because of either a bug that should be
fixed, or an insidious user, in which case 500 is probably better than a
polite explanation of the issue that gives them more knowledge.

In fact, only the server-side can ensure (for certain values of
“ensure”) security and integrity of data, since that is the only part
of the equation you, as provider/developer, have any meaningful
control over. TSL provides some security for the transmission of the
data, but can also be subverted with MITM attacks, for example, from
governments to Romanian cybercriminals, or can fall prey to insecure
implementations, like on iOS 4.2.x (At least), with Mobile Safari not
validating SSL certificates properly, or Debian’s OpenSSL packages
providing a not-so-random certificate generation limiting the possible
number of certificates to 65 000-and-change (long since been fixed!),
thanks to automated testing/code validation tools.

As for data disclosure (AKA “Oracle Attack”[0]), a non-descript error
is best, as CVE-2010-3332[1] demonstrates.

The question isn’t if you are paranoid. The question is if you are
paranoid enough.

[0] Understanding Padding Oracle attacks « Limited Entropy Dot Com
[1] http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3332


Phillip G.

phgaw.posterous.com | twitter.com/phgaw | gplus.to/phgaw

A method of solution is perfect if we can forsee from the start,
and even prove, that following that method we shall attain our aim.
– Leibniz

Ryan S.'s talk (about concurrency) was good, and his mannerisms and
way of speaking remind me of the author David Foster Wallace for some
reason…