Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] Re: Better Development Tools for Perl

Expand Messages
  • Ed Grimm
    ... You can t do this without writing something that will break my code. I believe it ll break Rob Kinyon s code even worse, if he uses object method calls in
    Message 1 of 107 , Jun 19, 2005
    • 0 Attachment
      On Saturday, June 18, 2005, at 05:41 PM, J Matisse Enzer wrote:
      > On Jun 18, 2005, at 12:08 PM, Rob Nagler wrote:
      >> No. There are a number of reasons why you don't want to do this.
      >> Firstly, you can't know that the following is your "foo".
      >>
      >> $o->foo();
      >
      > That's part of the problem with current tools. I want to see tools that
      > *can* figure out if $o->foo() is "my" foo, in most cases.

      You can't do this without writing something that will break my code. I
      believe it'll break Rob Kinyon's code even worse, if he uses object
      method calls in his dynamic code.

      Just because, in your code, $o->foo() is your foo, does not mean that
      someone using your module will be using your foo at that point. If
      they're not, the code is broken. If you make changes like this rename
      in a single release, without a period of deprecation, you will get a
      reputation among those people who use your modules of releasing
      unstable code.

      Note that, IMHO, when one deprecates code, one must indicate what to do
      instead, in addition to saying the code is deprecated, rather than
      simply reporting "don't do this any more, as we're about to break it."
      Poorly documented transitions can be nearly as frustrating as
      undocumented transitions.

      I suppose you could put a 'used downstream' flag in the module; this
      rename functionality would then be disabled if it was set to true.
      However, that is a very obvious barrier to improving skill, as it's a
      tool that only works for beginners - once one transitions into the role
      of module provider, it's gone.


      Regarding the ubiquitousness of unit and acceptance tests - if you are
      not doing these tests, and are not planning on doing these tests in the
      future, why are you here? (I ask, so that I might better understand
      your contributions.) Extreme programming is a set of practices, which
      do not necessarily work well apart.

      Most specific to this discussion, I have found that refactoring without
      unit tests can be very dangerous - sometimes, one thinks one has
      changed nothing, but one has, in fact, changed a great deal. This is
      actually the situation I was able to use to convince management to
      allow us to spend time on a proof of concept of writing automated
      tests. We had repeated instances of various people on our team
      releasing code that had repercussions sufficiently removed from where
      they'd made their changes that they hadn't thought to test the
      afflicted areas.

      I think that we would be better served documenting ways to make full
      extreme programming in perl easy than we would be making tools which
      facilitate incomplete extreme programming in perl.


      Incidentally, I'll reiterate more explicitly a point I made earlier -
      unit tests should be written before the code to satisfy the
      functionality. It may seem silly, but it sometimes comes in handy,
      such as the times I've found that the functionality already existed.
      Normally, its utility is more in pointing out exactly how the code
      currently behaves. Because programmers generally do not think about
      exception behavior, the behavior in the uncoded section may be quite
      different than the programmer thinks it is.

      Ed
    • Siegfried Heintze
      Since there was a helpful discussion some time ago on USB keyboards and mice for pair programming that was not specific to perl, I wanted to solicit the group
      Message 107 of 107 , Feb 13, 2006
      • 0 Attachment
        Since there was a helpful discussion some time ago on USB keyboards and mice
        for pair programming that was not specific to perl, I wanted to solicit the
        group for information on network software (also not specific to perl).



        I just set up openVPN on my openwrt/WRT54G router for pair programming with
        a headset and skype.



        (1) Can any point me to the documentation on sharing desktops on windows? I
        need to create accounts on Win2003 XP Server. When I created an account
        belonging only to the user group, my partner could not log in. He was
        receiving some error message about not being permitted to log in
        interactively. However, when I added the administrator group (reluctantly)
        to his account, he could log in. Is there a tutorial somewhere on the web
        for creating user accounts in windows for use with remote desktop logins on
        VPNs?



        (2) How do I share my remote desktop setting with a programming pair
        partner?



        (3) What about sharing sessions when I'm booted with linux? I think there is
        a vnc program out there, but I don't know how to use it. I'll need to learn
        how to create accounts and share linux desktops with remote VPN users. Is
        there a tutorial on this?



        (4) Are video cams very helpful for pair programming?



        It seems that this kind of knowledge would be very common for pair
        programmers.



        Thanks,

        Siegfried



        [Non-text portions of this message have been removed]
      Your message has been successfully submitted and would be delivered to recipients shortly.