rspec users - Feb 2009 - exemplary way to show a list is sorted?

RSpeckers:

I''m asserting that a list should be sorted by affinity. The following
code is good enough for government work, but is there some more clever
way to show that each element is equal or less than the previous
element?

  it ''should rank posts by affinity'' do
    list = @map.sort_frobs_by_affinity

    list[1].affinity.should >= list[1].affinity
    list[2].affinity.should >= list[2].affinity
    list[3].affinity.should >= list[3].affinity
    list[4].affinity.should >= list[4].affinity
  end

Notice I could just write...

  list.map(&:affinity) == list.map(&:affinity)

...but it seems that the point of BDD is to make the business logic
obvious, not obscured in programming details, right?

-- 
 Phlip
 http://www.oreilly.com/catalog/9780596510657/
 ^ assert_xpath
 http://tinyurl.com/yrc77g  <-- assert_latest Model

On Sun, Feb 8, 2009 at 5:48 PM, Phlip <phlip2005 at gmail.com>
wrote:
> RSpeckers:
>
> I''m asserting that a list should be sorted by affinity. The
following
In BDD we say "expecting" instead of "asserting"
> code is good enough for government work, but is there some more clever
> way to show that each element is equal or less than the previous
> element?
>
>  it ''should rank posts by affinity'' do
>    list = @map.sort_frobs_by_affinity
>
>    list[1].affinity.should >= list[1].affinity
please use "should be >=" as "should >=" will
eventually be deprecated
and removed.
>    list[2].affinity.should >= list[2].affinity
>    list[3].affinity.should >= list[3].affinity
>    list[4].affinity.should >= list[4].affinity
>  end
>
> Notice I could just write...
>
>  list.map(&:affinity) == list.map(&:affinity)
>
> ...but it seems that the point of BDD is to make the business logic
> obvious, not obscured in programming details, right?
Right. I''ve done stuff like this before:

[b,d,a,c].sort_with_special_method.should == [a,b,c,d]

Any other patterns out there?

David
>
> --
>  Phlip
>  http://www.oreilly.com/catalog/9780596510657/
>  ^ assert_xpath
>  http://tinyurl.com/yrc77g  <-- assert_latest Model
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Tue, Feb 10, 2009 at 12:19 PM, David Chelimsky <dchelimsky at
gmail.com> wrote:
> Right. I''ve done stuff like this before:
>
> [b,d,a,c].sort_with_special_method.should == [a,b,c,d]
>
> Any other patterns out there?
That''s how I do it.

Pat

David Chelimsky wrote:
> 
> please use "should be >=" as "should >=" will
eventually be deprecated
> and removed.
> 
Removed? You are not seriously contemplating forcing people to go back 
and rewrite formally working specifications simply to tidy up the syntax 
are you?

-- 
Posted via http://www.ruby-forum.com/.

On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <lists at ruby-forum.com>
wrote:
> David Chelimsky wrote:
>
>>
>> please use "should be >=" as "should >=" will
eventually be deprecated
>> and removed.
>>
>
> Removed?  You are not seriously contemplating forcing people to go back
> and rewrite formally working specifications simply to tidy up the syntax
> are you?
Forcing people, eh? You don''t have to upgrade when that release is
made. No one is holding a gun to your head. You can always choose to
progress with the library, as it continues to evolve into new and
better ways of doing things.

Given the "should >=" to "should be >=" transition,
I''m sure you can
safely do a find and replace in merely a few seconds if you bust out a
little regexp-fu, or maybe a few minutes if you do separate searches
for each operator.

If the idea of change is that abrasive to you, go to github, and feel
free to fork it yourself. After all, the jamesbyrne-rspec library is
only a few minutes away,

-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

Zach Dennis wrote:
> On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <lists at
ruby-forum.com>
> wrote:
>> David Chelimsky wrote:
>>
>>>
>>> please use "should be >=" as "should >="
will eventually be deprecated
>>> and removed.
>>>
>>
>> Removed?  You are not seriously contemplating forcing people to go back
>> and rewrite formally working specifications simply to tidy up the
syntax
>> are you?
> 
> Forcing people, eh? You don''t have to upgrade when that release is
> made. No one is holding a gun to your head. You can always choose to
> progress with the library, as it continues to evolve into new and
> better ways of doing things.
There are enterprises in which the stability of development tools and 
the confidence that one will not be forced to redo work already 
completed is considered somewhat important, whatever your own situation 
might be.  Likewise, assuming the costs of maintaining a customized 
variant of a general tool or foregoing future improvements in same to 
maintain the value of existing work is not a choice savoured by many 
firms that I can bring to mind, even if yours might be exceptional in 
this regard.  At issue is something commonly referred to as 
cost/benefit, which ultimately turns into profit and loss.

I simply fail to see why evolving a tool in "better ways" necessarily 
requires that the formerly "better" but now depreciated method be 
removed.  Such action causes avoidable and pointless work. I consider my 
observation to be both reasonable and pertinent.
-- 
Posted via http://www.ruby-forum.com/.

On Tue, Feb 10, 2009 at 10:09 PM, James Byrne <lists at ruby-forum.com>
wrote:
> Zach Dennis wrote:
>> On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <lists at
ruby-forum.com>
>> wrote:
>>> David Chelimsky wrote:
>>>
>>>>
>>>> please use "should be >=" as "should
>=" will eventually be deprecated
>>>> and removed.
>>>>
>>>
>>> Removed?  You are not seriously contemplating forcing people to go
back
>>> and rewrite formally working specifications simply to tidy up the
syntax
>>> are you?
>>
>> Forcing people, eh? You don''t have to upgrade when that
release is
>> made. No one is holding a gun to your head. You can always choose to
>> progress with the library, as it continues to evolve into new and
>> better ways of doing things.
>
> There are enterprises in which the stability of development tools and
> the confidence that one will not be forced to redo work already
> completed is considered somewhat important, whatever your own situation
> might be.  Likewise, assuming the costs of maintaining a customized
> variant of a general tool or foregoing future improvements in same to
> maintain the value of existing work is not a choice savoured by many
> firms that I can bring to mind, even if yours might be exceptional in
> this regard.  At issue is something commonly referred to as
> cost/benefit, which ultimately turns into profit and loss.
>
> I simply fail to see why evolving a tool in "better ways"
necessarily
> requires that the formerly "better" but now depreciated method be
> removed.
Just like there is cost associated with you taking time to update your
software to work with changes in the libraries and tools you use,
there is cost that the developers and maintainers of those very
libraries and tools will incur in order to maintain backwards
compatibility for features that are no longer deemed necessary.

This will lead to large negative effects over time, like a snowball
rolling down a hill. When the snow is good for packing though--none of
that fluffy stuff that doesn''t stick.
> Such action causes avoidable and pointless work.
And to disprove this argument I will defer to the avoidable and
pointless work you will be causing those who maintain the software,

> I consider my
> observation to be both reasonable and pertinent.
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

On Tue, Feb 10, 2009 at 9:09 PM, James Byrne <lists at ruby-forum.com>
wrote:
> Zach Dennis wrote:
>> On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <lists at
ruby-forum.com>
>> wrote:
>>> David Chelimsky wrote:
>>>
>>>>
>>>> please use "should be >=" as "should
>=" will eventually be deprecated
>>>> and removed.
>>>>
>>>
>>> Removed?  You are not seriously contemplating forcing people to go
back
>>> and rewrite formally working specifications simply to tidy up the
syntax
>>> are you?
>>
>> Forcing people, eh? You don''t have to upgrade when that
release is
>> made. No one is holding a gun to your head. You can always choose to
>> progress with the library, as it continues to evolve into new and
>> better ways of doing things.
>
> There are enterprises in which the stability of development tools and
> the confidence that one will not be forced to redo work already
> completed is considered somewhat important, whatever your own situation
> might be.  Likewise, assuming the costs of maintaining a customized
> variant of a general tool or foregoing future improvements in same to
> maintain the value of existing work is not a choice savoured by many
> firms that I can bring to mind, even if yours might be exceptional in
> this regard.  At issue is something commonly referred to as
> cost/benefit, which ultimately turns into profit and loss.
>
> I simply fail to see why evolving a tool in "better ways"
necessarily
> requires that the formerly "better" but now depreciated method be
> removed.  Such action causes avoidable and pointless work. I consider my
> observation to be both reasonable and pertinent.
Keeping dead weight around has a cost as well, and has to be balanced
against the concerns you raise. As RSpec''s lead maintainer, I reserve
the right to introduce well documented but
backwards-compatibility-breaking-changes in major releases (i.e. 2.x,
3.x, etc) if I think it''s better for RSpec in the long run. This
change would be formally deprecated in a 1.x release and not removed
before the 2.0 release. I think you''ll find that other libraries in
our space (ruby/OSS) operate under the same principles.

General operating principles aside, we can certainly have a
conversation about the relative merits and cost/benefits of this
change. For me, the fact that we can say "should >=" in RSpec is
unfortunate. It is ugly, and should not exist. It is also duplication
of code elsewhere in the system, which has its own cost, so this is
not only about tidying up syntax. It''s about paying down technical
debt. It''s about lowering the barrier of entry to contribution so more
people play along.

I don''t want to make a bigger deal out of this than it is, but it
seems like we''re already passed that point.

FWIW,
David

Zach Dennis wrote:
> 
>> Such action causes avoidable and pointless work.
> 
> And to disprove this argument I will defer to the avoidable and
> pointless work you will be causing those who maintain the software,
> 
This is a completely illogical, and inherently contradictory, statement.

The issue is that a tool is supposed to be reliable.  Reliability 
includes the notion of preserving prior behaviour.  This ensures that 
people who invest their time in using the tool do not have their trust 
in it destroyed by avoidable changes.

Further, by its very nature, a tool is used by vastly more people than 
those that create the tool, otherwise it has little value.  The idea 
that a large number of people should be inconvenienced in order that a 
few people are not strikes me as rather selfish and frankly, 
unprofessional.  Have you ever dared to make that type of argument to 
your employer or client?

Yes, software evolves; and yes, there are many things we do in ignorance 
that experience reveals as both unfortunate and wasteful.  But, time is 
money and causing test suites to fail by removing parts of the API just 
because they appear ugly seems to me to break the contract that one 
makes with those who choose to use your tool instead of another.

Let use consider this construct:

  object.should be_close(value,delta)

why not

  object.should be_close_to(value,delta)

Or

  object.should be_near(value,delta)

Or

  object.should approximate(value,delta) instead?

Which is "better" then the others?  Which is "uglier"?  Who
cares?  Pick
one and stick with it; or, if one feels compelled to improve the style 
then at least keep that which already works, and is in use, working.


-- 
Posted via http://www.ruby-forum.com/.

On Wed, Feb 11, 2009 at 8:52 AM, James Byrne <lists at ruby-forum.com>
wrote:
> Zach Dennis wrote:
>
>>
>>> Such action causes avoidable and pointless work.
>>
>> And to disprove this argument I will defer to the avoidable and
>> pointless work you will be causing those who maintain the software,
>>
>
> This is a completely illogical, and inherently contradictory, statement.
>
> The issue is that a tool is supposed to be reliable.  Reliability
> includes the notion of preserving prior behaviour.  This ensures that
> people who invest their time in using the tool do not have their trust
> in it destroyed by avoidable changes.
>
> Further, by its very nature, a tool is used by vastly more people than
> those that create the tool, otherwise it has little value.  The idea
> that a large number of people should be inconvenienced in order that a
> few people are not strikes me as rather selfish and frankly,
> unprofessional.  Have you ever dared to make that type of argument to
> your employer or client?
>
> Yes, software evolves; and yes, there are many things we do in ignorance
> that experience reveals as both unfortunate and wasteful.  But, time is
> money and causing test suites to fail by removing parts of the API just
> because they appear ugly seems to me to break the contract that one
> makes with those who choose to use your tool instead of another.
>
> Let use consider this construct:
>
>  object.should be_close(value,delta)
>
> why not
>
>  object.should be_close_to(value,delta)
>
> Or
>
>  object.should be_near(value,delta)
>
> Or
>
>  object.should approximate(value,delta) instead?
>
> Which is "better" then the others?  Which is "uglier"? 
Who cares?  Pick
> one and stick with it; or, if one feels compelled to improve the style
> then at least keep that which already works, and is in use, working.
James,

Chill, please! This is not productive at all. You started this thread
with a condescending tone and you''ve already spent more time (and your
enterprise''s money) ranting about this than it''s going to take
you to
make this change when it comes, and you continue to be insulting with
comments about being selfish and unprofessional. If you''d like a civil
conversation, then drop the attitude.

I explained my position in another post in this thread, and I look
forward to your *respectful* responses to those thoughts.

Cheers,
David

On 10/02/2009, at 10:09 PM, James Byrne wrote:
> Zach Dennis wrote:
>> On Tue, Feb 10, 2009 at 6:22 PM, James Byrne <lists at
ruby-forum.com>
>> wrote:
>>> David Chelimsky wrote:
>>>
>>>>
>>>> please use "should be >=" as "should
>=" will eventually be
>>>> deprecated
>>>> and removed.
>>>>
>>>
>>> Removed?  You are not seriously contemplating forcing people to go
>>> back
>>> and rewrite formally working specifications simply to tidy up the  
>>> syntax
>>> are you?
>>
>> Forcing people, eh? You don''t have to upgrade when that
release is
>> made. No one is holding a gun to your head. You can always choose to
>> progress with the library, as it continues to evolve into new and
>> better ways of doing things.
>
> There are enterprises in which the stability of development tools and
> the confidence that one will not be forced to redo work already
> completed is considered somewhat important, whatever your own  
> situation
> might be.  Likewise, assuming the costs of maintaining a customized
> variant of a general tool or foregoing future improvements in same to
> maintain the value of existing work is not a choice savoured by many
> firms that I can bring to mind, even if yours might be exceptional in
> this regard.  At issue is something commonly referred to as
> cost/benefit, which ultimately turns into profit and loss.
>
> I simply fail to see why evolving a tool in "better ways"
necessarily
> requires that the formerly "better" but now depreciated method be
> removed.  Such action causes avoidable and pointless work. I  
> consider my
> observation to be both reasonable and pertinent.

I hear what you''re saying, James, and agree with you to a certain  
extent. However, one must keep a few things in mind:

1) The syntax in question will be valid, but deprecated, in all 1.x  
releases. This means that you can continue to use the old syntax.

2) If you''re willing to change which version of RSpec a project of  
yours uses, then you must be willing to change how the project uses  
RSpec. Change begets change.

3) When a new major version of a project is released, one must be  
prepared for major changes. If the changes are incompatible with you  
or your own software, several options exist:
3.1) Do not upgrade to the new major version.
3.2) Fork the new major version, add your desired modifications, then  
use that fork in your software.
3.3) Modify your software so that it becomes compatible with the new  
major version of the project in question.

4) Most free and/or open-source projects are run as democracies.  
However, they are overseen by the lead maintainer(s), who have the  
final say when it comes to making decisions. This is because they have  
the most knowledge of, and experience with, the project, and  
understand best the direction that the project should be going in.

Cheers,
Nick

David Chelimsky wrote:
> 
> I explained my position in another post in this thread, and I look
> forward to your *respectful* responses to those thoughts.
I regret if my initial observation was taken as anything other than 
that, an observation.  One might consider it the textual equivalent to a 
raised eyebrow, no more.  Being told to maintain my own fork of a 
project was not a response that I either expected or thought warranted.

Notwithstanding the heat that this issue appears to have raised, I 
assure you that I bear no ill will towards any. I simply believe that 
changes which introduce breakage to previously working code should be 
avoided wherever possible.  This did not seem to me condescending, 
abrasive, or particularly controversial.  Evidently I am wrong.
-- 
Posted via http://www.ruby-forum.com/.

On Feb 11, 2009, at 10:53 AM, James Byrne <lists at ruby-forum.com> wrote:
> David Chelimsky wrote:
>
>>
>> I explained my position in another post in this thread, and I look
>> forward to your *respectful* responses to those thoughts.
>
> I regret if my initial observation was taken as anything other than
> that, an observation.  One might consider it the textual equivalent  
> to a
> raised eyebrow, no more.  Being told to maintain my own fork of a
> project was not a response that I either expected or thought  
> warranted.
>
> Notwithstanding the heat that this issue appears to have raised, I
> assure you that I bear no ill will towards any. I simply believe that
> changes which introduce breakage to previously working code should be
> avoided wherever possible.  This did not seem to me condescending,
> abrasive, or particularly controversial.  Evidently I am wrong.
Cool. Now we can talk. For the record, the thing that struck me as  
patronizing was "You are not seriously ... simply to tidy up the  
syntax" which makes assumptions about the underlying motivations and  
positions your issues as more important than mine, or anybody else''s  
for that matter. There is a lot more to all of this than meets the  
eye. RSpec is a tool, but it is also a community project, which means  
it serves many masters and has to balance many forces.

As for the point you make about avoiding compatbility breaking  
changes, I agree that that carries some weight, but it is not the only  
concern.

One of the biggest problems rspec suffers as a community project is  
barrier to entry for contributors based on a public perception that  
rspec is bloated and difficult to understand. So I care about bloat,  
and this particular issue is about that as much as it is about syntax.

I have more to add, but I''m typing on my phone and my other fingers  
are beginning to get jealous of my thumbs. More later.

David

>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

On 11 Feb 2009, at 16:53, James Byrne wrote:
> David Chelimsky wrote:
>
>> I explained my position in another post in this thread, and I look
>> forward to your *respectful* responses to those thoughts.
>
> I regret if my initial observation was taken as anything other than
> that, an observation.  One might consider it the textual equivalent  
> to a
> raised eyebrow, no more.  Being told to maintain my own fork of a
> project was not a response that I either expected or thought  
> warranted.
This is the beauty of github: when someone complains about a project,  
you can just tell them to fork off!


Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

On Wed, Feb 11, 2009 at 6:52 AM, James Byrne <lists at ruby-forum.com>
wrote:
> Further, by its very nature, a tool is used by vastly more people than
> those that create the tool, otherwise it has little value.  The idea
> that a large number of people should be inconvenienced in order that a
> few people are not strikes me as rather selfish and frankly,
> unprofessional.
You are completely out of line even suggesting that David is selfish
or unprofessional.  Do you have any clue how many changes he HASN''T
made because it would break backwards compatibility?  How much effort
goes into sensibly deprecating stuff?  The work he does to keep RSpec
working with old versions of Rails (only very recently *announcing*
discontinued support of 1.2.x), as well as consistently keeping it
working with edge Rails even with all of its internal breakage.

The simple fact is that while RSpec owes a great deal to its community
as a whole, it would be nowhere near where it is today without David''s
hard work.  Look at the friggin commit logs and the lighthouse
tickets.  Do you seriously have a problem with making his life a bit
easier?  Didn''t think so.  And I can guarantee you that his real
motivation isn''t selfish in the least - cleaning up the internals
makes it easier to understand and modify, allowing more users to
become contributors.

Here''s a little tip that will save you THOUSANDS AND THOUSANDS OF
DOLLARS in the future:
gem install rspec rspec-rails --version=1.1.12

Pat

Pat Maddox wrote:
> 
> You are completely out of line even suggesting that David is selfish
> or unprofessional.  Do you have any clue how many changes he
HASN''T
> made because it would break backwards compatibility?  How much effort
> goes into sensibly deprecating stuff?  The work he does to keep RSpec
> working with old versions of Rails (only very recently *announcing*
> discontinued support of 1.2.x), as well as consistently keeping it
> working with edge Rails even with all of its internal breakage.
> 
I did not believe that what I understood from the choice of words used 
with respect to removing part of the RSpec API could be correct and so I 
asked whether or not I was mistaken.  Evidently because of my phrasing 
this was somehow turned into a slur on the people who work on RSpec.  I 
regret that but no insult was intended, it was just a statement of how I 
understood what I had just read incorporated with a request to have my 
interpretation corrected.  If this had been raised in person and not via 
email I venture that my question would have been answered directly and 
without rancor.

The initial response that I received from Mr. Dennis was uncalled for. 
It would have been enough to say that there exists a compelling 
technical reason to remove the item.  It would have been useful to 
outline briefly what that technical reason was.  Bear in mind please 
that those outside of the inner circle of contributors generally are not 
conversant with all of the issues facing a project.  We nonetheless may 
possess reasonable concerns with respect to its future development.

I am well aware that Rails is a moving target and that Ruby is about to 
go through the convulsions that will accompany the move to 1.9/2.x in 
the near future.  I expect that in consequence a vast amount of software 
presently in use will either have to be revised extensively or 
abandoned. I am not dogmatic about backwards compatibly.  On the other 
hand, I also have first hand experience with OSS projects where 
backwards compatibility appeared inconsequential.

Instead of advising people who raise issues like this to go fork their 
own project, perhaps a brief statement as to why the action is deemed 
appropriate might be better.  Compare the response from Mr. Dennis to 
that from Mr. Chelimsky.

You may now have the last word.


-- 
Posted via http://www.ruby-forum.com/.

On Thu, Feb 12, 2009 at 9:25 AM, James Byrne <lists at ruby-forum.com>  
wrote:
> Pat Maddox wrote:
>
>>
>> You are completely out of line even suggesting that David is selfish
>> or unprofessional.  Do you have any clue how many changes he
HASN''T
>> made because it would break backwards compatibility?  How much effort
>> goes into sensibly deprecating stuff?  The work he does to keep RSpec
>> working with old versions of Rails (only very recently *announcing*
>> discontinued support of 1.2.x), as well as consistently keeping it
>> working with edge Rails even with all of its internal breakage.
>>
>
> I did not believe that what I understood from the choice of words used
> with respect to removing part of the RSpec API could be correct and  
> so I
> asked whether or not I was mistaken.  Evidently because of my phrasing
> this was somehow turned into a slur on the people who work on  
> RSpec.  I
> regret that but no insult was intended, it was just a statement of  
> how I
> understood what I had just read incorporated with a request to have my
> interpretation corrected.  If this had been raised in person and not  
> via
> email I venture that my question would have been answered directly and
> without rancor.
>
> The initial response that I received from Mr. Dennis was uncalled for.
I have to take some responsibility for his initial response. Zach and  
I were chatting in IRC when I read your initial comment, to which I  
had a very strong and negative reaction. He was really just trying to  
take the heat off me at the moment.

If you take away the reactionary nature of it, however, he did have  
good points about the nature of open source, as did Nick Hoffman in  
this thread.
> It would have been enough to say that there exists a compelling
> technical reason to remove the item.  It would have been useful to
> outline briefly what that technical reason was.  Bear in mind please
> that those outside of the inner circle of contributors generally are  
> not
> conversant with all of the issues facing a project.  We nonetheless  
> may
> possess reasonable concerns with respect to its future development.
>
> I am well aware that Rails is a moving target and that Ruby is about  
> to
> go through the convulsions that will accompany the move to 1.9/2.x in
> the near future.  I expect that in consequence a vast amount of  
> software
> presently in use will either have to be revised extensively or
> abandoned. I am not dogmatic about backwards compatibly.  On the other
> hand, I also have first hand experience with OSS projects where
> backwards compatibility appeared inconsequential.
I hope you understand now that this is not the case with rspec.
> Instead of advising people who raise issues like this to go fork their
> own project, perhaps a brief statement as to why the action is deemed
> appropriate might be better.  Compare the response from Mr. Dennis to
> that from Mr. Chelimsky.
Again, I had the benefit of time to step back and try to be  
constructive. Zach''s response was reactionary, but he was channeling  
my reaction.

In accepting reappnsibility for this, btw, I''m not trying to dilute  
it. I still feel that there were some insults thrown at me, and I''m  
grateful to Zach and Pat for coming to my defense.

I also agree that this would all have been much smaller face to face,  
with pints of beer in our hands.
> You may now have the last word.
I think we''ve all said our piece at this point and would love to move  
on.

Are you clear now about the particular change that started this whole  
thing?

Cheers,
David