I'm been reading The Pragmatic Programmer and have come across the concept
of 'Design by Contract' (http://en.wikipedia.org/wiki/Design_by_contract),
which is a concept I haven't come across before.
It seems like quite a useful technique, so I was wondering what all of your
thoughts were on the technique in general, and also the benefits, drawbacks
and alternatives to it's application in Ruby programming specifically.
Adam
···
--
== If you're doing it alone, you're probably doing it wrong ==
I played with it back in the day when I was evaluating eiffel (DBC was first popularized by Bertrand Meyer, designer of the eiffel language). I know there was at least one library back in the day for DBC in ruby, but I've never used any of them. You might want to check this one out:
It's old, but I doubt that matters for this topic.
···
On Jul 22, 2014, at 0:12, Adam Wenham <adamwenham64@gmail.com> wrote:
Hi all,
I'm been reading The Pragmatic Programmer and have come across the concept of 'Design by Contract' (http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I haven't come across before.
It seems like quite a useful technique, so I was wondering what all of your thoughts were on the technique in general, and also the benefits, drawbacks and alternatives to it's application in Ruby programming specifically.
It is good to learn Design By Contract (DBC). Thinking about invariants, pre-conditions and post-conditions helps in making classes which work well and are easy to use. You might profit from using DBC as a learning exercise.
I do not favor the addition of DBC conditions for most production code, primarily because unit tests provide most of the same value that conditions provide, but without bloating the code.
Wayne Conrad
···
On 07/22/2014 12:12 AM, Adam Wenham wrote:
I'm been reading The Pragmatic Programmer and have come across the concept of 'Design by Contract' (http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I haven't come across before.
I got into Design By Contract with Obvious (http://obvious.retromocha.com)
in Ruby and ended up writing my own concept of contracts in Ruby. I find
them to be useful simply because they give you runtime type guarantees that
you don't get normally with Ruby. Without a stronger notion of interfaces
in Ruby, you have to lean harder on your unit tests to provide some kind of
guarantees about certain behaviors. With contracts, you actually write a
lot fewer tests because your contract specifies and ensures more correct
input and output.
Obvious contracts were really simple, but I think the idea could be taken
further to handle things like validation.
In general, with stronger guarantees around input and output, you have to
write fewer tests.
-Brian
···
On Tue, Jul 22, 2014 at 7:05 AM, Wayne Conrad <kf7qga@gmail.com> wrote:
On 07/22/2014 12:12 AM, Adam Wenham wrote:
I'm been reading The Pragmatic Programmer and have come across the
concept of 'Design by Contract' (Wikipedia, the free encyclopedia
Design_by_contract), which is a concept I haven't come across before.
It is good to learn Design By Contract (DBC). Thinking about invariants,
pre-conditions and post-conditions helps in making classes which work well
and are easy to use. You might profit from using DBC as a learning
exercise.
I do not favor the addition of DBC conditions for most production code,
primarily because unit tests provide most of the same value that conditions
provide, but without bloating the code.
Thanks Ryan. So it seems old, and not particularly widespread these days.
Is the technique still relevant? Or just a stepping stone on the way to
better TDD and BDD tools and techniques? The Wikipedia page says that it's
there to augment unit and integration testing, but is it really necessary
in creating robust software? Does it fill a niche that actually needs to be
filled?
···
On 22 July 2014 08:30, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Jul 22, 2014, at 0:12, Adam Wenham <adamwenham64@gmail.com> wrote:
> Hi all,
>
> I'm been reading The Pragmatic Programmer and have come across the
concept of 'Design by Contract' ( http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I
haven't come across before.
>
> It seems like quite a useful technique, so I was wondering what all of
your thoughts were on the technique in general, and also the benefits,
drawbacks and alternatives to it's application in Ruby programming
specifically.
I played with it back in the day when I was evaluating eiffel (DBC was
first popularized by Bertrand Meyer, designer of the eiffel language). I
know there was at least one library back in the day for DBC in ruby, but
I've never used any of them. You might want to check this one out:
On 22 Jul 2014, at 09:30, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Jul 22, 2014, at 0:12, Adam Wenham <adamwenham64@gmail.com> wrote:
Hi all,
I'm been reading The Pragmatic Programmer and have come across the concept of 'Design by Contract' (http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I haven't come across before.
It seems like quite a useful technique, so I was wondering what all of your thoughts were on the technique in general, and also the benefits, drawbacks and alternatives to it's application in Ruby programming specifically.
I played with it back in the day when I was evaluating eiffel (DBC was first popularized by Bertrand Meyer, designer of the eiffel language). I know there was at least one library back in the day for DBC in ruby, but I've never used any of them. You might want to check this one out:
I think that's true. Another way to look at it is that you've moved some checks from the formal test into the code-under-test. You can also view static type checking the same way: It moves some checks into the code (but not just that: static type notations also aids in reading the code). Not coincidentally, one of the DBC gems in this thread seems to be used primarily to add type checking.
Wayne Conrad
···
On 07/22/2014 06:38 AM, Brian Knapp wrote:
In general, with stronger guarantees around input and output, you have to write fewer tests.
On 22 July 2014 08:50, Adam Wenham <adamwenham64@gmail.com> wrote:
Thanks Ryan. So it seems old, and not particularly widespread these days.
Is the technique still relevant? Or just a stepping stone on the way to
better TDD and BDD tools and techniques? The Wikipedia page says that it's
there to augment unit and integration testing, but is it really necessary
in creating robust software? Does it fill a niche that actually needs to be
filled?
On 22 July 2014 08:30, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Jul 22, 2014, at 0:12, Adam Wenham <adamwenham64@gmail.com> wrote:
> Hi all,
>
> I'm been reading The Pragmatic Programmer and have come across the
concept of 'Design by Contract' ( http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I
haven't come across before.
>
> It seems like quite a useful technique, so I was wondering what all of
your thoughts were on the technique in general, and also the benefits,
drawbacks and alternatives to it's application in Ruby programming
specifically.
I played with it back in the day when I was evaluating eiffel (DBC was
first popularized by Bertrand Meyer, designer of the eiffel language). I
know there was at least one library back in the day for DBC in ruby, but
I've never used any of them. You might want to check this one out:
Thanks all, I was on the fence but I think I'll check out DBC after all.
···
On 22 July 2014 14:57, Wayne Conrad <kf7qga@gmail.com> wrote:
On 07/22/2014 06:38 AM, Brian Knapp wrote:
In general, with stronger guarantees around input and output, you have to
write fewer tests.
I think that's true. Another way to look at it is that you've moved
some checks from the formal test into the code-under-test. You can also
view static type checking the same way: It moves some checks into the code
(but not just that: static type notations also aids in reading the code).
Not coincidentally, one of the DBC gems in this thread seems to be used
primarily to add type checking.
Wayne Conrad
--
== If you're doing it alone, you're probably doing it wrong ==
I got into Design By Contract with Obvious (http://obvious.retromocha.com)
in Ruby and ended up writing my own concept of contracts in Ruby. I find
them to be useful simply because they give you runtime type guarantees that
you don't get normally with Ruby.
Adding DBC to Ruby is quite a fundamental change. I'd say, if you feel
you need to retrofit DBC functionality to Ruby which does not even
feature static typing then you're using the wrong language; then you
are probably better off with Eiffel.
That does not mean DBC concepts cannot be used in Ruby. You can use
them for reasoning about code and even include them, e.g. as method
comments. Knowing the concept helps understand how methods interact
with each other and what are the critical things to reason about and
to define.
Without a stronger notion of interfaces in
Ruby, you have to lean harder on your unit tests to provide some kind of
guarantees about certain behaviors. With contracts, you actually write a lot
fewer tests because your contract specifies and ensures more correct input
and output.
I am not so sure whether that statement is actually true. You might
rid off some unit tests but "a lot" seems too optimistic to me.
Depending on the contract there may still be a lot of legal and
illegal variants of behavior that need verifying.
In general, with stronger guarantees around input and output, you have to
write fewer tests.
If you put it that way I agree.
Kind regards
robert
···
On Tue, Jul 22, 2014 at 3:38 PM, Brian Knapp <brianknapp@gmail.com> wrote:
I think that D also has something like DBC as part of the language.
···
On 22 July 2014 08:54, Adam Wenham <adamwenham64@gmail.com> wrote:
Thanks Daniel. Same questions to you
On 22 July 2014 08:50, Adam Wenham <adamwenham64@gmail.com> wrote:
Thanks Ryan. So it seems old, and not particularly widespread these days.
Is the technique still relevant? Or just a stepping stone on the way to
better TDD and BDD tools and techniques? The Wikipedia page says that it's
there to augment unit and integration testing, but is it really necessary
in creating robust software? Does it fill a niche that actually needs to be
filled?
On 22 July 2014 08:30, Ryan Davis <ryand-ruby@zenspider.com> wrote:
On Jul 22, 2014, at 0:12, Adam Wenham <adamwenham64@gmail.com> wrote:
> Hi all,
>
> I'm been reading The Pragmatic Programmer and have come across the
concept of 'Design by Contract' ( http://en.wikipedia.org/wiki/Design_by_contract\), which is a concept I
haven't come across before.
>
> It seems like quite a useful technique, so I was wondering what all of
your thoughts were on the technique in general, and also the benefits,
drawbacks and alternatives to it's application in Ruby programming
specifically.
I played with it back in the day when I was evaluating eiffel (DBC was
first popularized by Bertrand Meyer, designer of the eiffel language). I
know there was at least one library back in the day for DBC in ruby, but
I've never used any of them. You might want to check this one out:
Has anyone seen a tool that generates ERR diagrams and relationship lines, from a MySQL db that doesn't have foreign keys? I’m using MySQL and the standard ActiveRecord table naming conventions. This link is close, but doesn't quite work for the AR table name conventions: http://planet.mysql.com/entry/?id=26363
I've written (and subsequently thrown away) a couple. It's not hard. Use the graph gem + some simple file/text processing ruby to generate the structure.
···
On Jul 22, 2014, at 16:43, Bert Gregory Mcguirk <bert.mcguirk@gmail.com> wrote:
Has anyone seen a tool that generates ERR diagrams and relationship lines, from a MySQL db that doesn't have foreign keys? I’m using MySQL and the standard ActiveRecord table naming conventions. This link is close, but doesn't quite work for the AR table name conventions:http://planet.mysql.com/entry/?id=26363
Me too, e.g.: http://pivotallabs.com/dot-rake/ -- passed on more for
inspiration and the comment thread than as an actual recommendation. I
have no idea if it still works.
- A
···
On Tue, Jul 22, 2014 at 9:09 PM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
I've written (and subsequently thrown away) a couple. It's not hard.
Damn. You should look at the graph gem. It is a LOT friendlier than that code and you might like it better.
···
On Jul 23, 2014, at 12:29, Alex Chaffee <alex@stinky.com> wrote:
On Tue, Jul 22, 2014 at 9:09 PM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
I've written (and subsequently thrown away) a couple. It's not hard.
Me too, e.g.: http://pivotallabs.com/dot-rake/ -- passed on more for
inspiration and the comment thread than as an actual recommendation. I
have no idea if it still works.
Thanks for all the input guys. I ended up approaching this from a different angle. I used this gem to create foreign keys GitHub - jenseng/immigrant: Foreign key migration generator for Rails from our tablename_id fields, then the MySQL workbench Diagram generator was able to draw all my relationships. I dropped all the unneeded keys after this was done.
