Better late than never.
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 Schor <beholdthepanda@gmail.com>wrote:
Better late than never.
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 Mon, Aug 8, 2011 at 12:23 PM, Stephen Schor <beholdthepanda@gmail.com>wrote:
Better late than never.
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 Mon, Aug 8, 2011 at 10:54 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
On Mon, Aug 8, 2011 at 12:23 PM, Stephen Schor <beholdthepanda@gmail.com>wrote:
Better late than never.
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.
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 Tue, Aug 9, 2011 at 12:49 AM, Kevin <darkintent@gmail.com> wrote:
On Mon, Aug 8, 2011 at 10:54 PM, Josh Cheek <josh.cheek@gmail.com> wrote:
> On Mon, Aug 8, 2011 at 12:23 PM, Stephen Schor <beholdthepanda@gmail.com > >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.
>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.
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
···
On Tue, Aug 9, 2011 at 8:07 AM, Josh Cheek <josh.cheek@gmail.com> 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.
--
Phillip Gawlowski
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 Smith's talk (about concurrency) was good, and his mannerisms and
way of speaking remind me of the author David Foster Wallace for some
reason...
···
--
Posted via http://www.ruby-forum.com/.