elementary-dev-community team mailing list archive

[Dane Henson <dane@xxxxxxxxxxxxxxxx>]

I knew that would light a fire, but I didn't intend it to be hostile. I
have a full-time job (not programming), a 3-year-old and a pregnant wife
due in two weeks. I think I know a little about adult responsibilities and
time balance.

We do need to Skype/Hangout soon. I have a feeling you and I would get
along famously and maybe we can get something started instead of just
talking in circles.
On Aug 22, 2013 4:33 PM, "Craig" <weberc2@xxxxxxxxx> wrote:

> Hi Dane,
>
> Thanks for your reply. In a perfect world, I would have the time to do all
> of those things, unfortunately, the best I can offer is my experience and
> whatever coding time I have left over. Being an adult is a drag sometimes.
> I don't have time to learn a new application (and development environment)
> or drive its development. Moreover, I didn't "champion" (as you say) this
> email thread for my own benefit, but for the benefit of those who *have
> time* to develop elementary (because TDD is, after all, a tool to
> facilitate development).
>
> I am passionate about helping *developers*; however, I can only help
> those who want to learn. I don't have the resources to do more than coach;
> however, I don't think coaching is "giving up" or "passing the baton". It
> just isn't being the primary developer. Even if I could do the work, I can
> have a little impact by using TDD to work efficiently, but I can have a
> much broader impact by showing others how to use TDD to improve *their own
> * efficiency. I don't doubt that there's value in leading by example, but
> I don't see that being a possibility for some time.
>
> Regarding your app, I'm happy to help you find better ways to test. I'm
> sure we can work out a time to do a hang out. Just let me know when works
> for you.
>
> To anyone else who is interested, I'm happy to answer any questions about
> TDD or other matters pertaining to software development. If you would like
> to implement testing on any projects you're involved in, please hang me a
> line!
>
> Thanks again,
> Craig
>
>
> On Thu, Aug 22, 2013 at 7:38 AM, Dane Henson (elementary) <
> dane@xxxxxxxxxxxxxxxx> wrote:
>
>> Craig,
>> I don't think this is something you can just hand off.  You championed
>> this to a 60+ e-mail thread and you just expect someone else to pick up the
>> banner?
>>
>> My old pastor had a saying: "See the need, fill the need."
>>
>> If you feel this passionate about helping elementary, I know you can get
>> over your GoLang tendencies and jump on the Vala bandwagon to at least act
>> as a "project manager".
>>
>> Here are some practical examples that we can start with:
>> 1. The Vala language itself uses Unit testing without a framework, and
>> they use a bash script to run them.  Prolific Unit Test experts have said
>> that it doesn't matter if you use a framework or not, just test!
>> https://git.gnome.org/browse/vala/tree/tests
>>
>> 2. I pulled sources from all over the internet to create a half-baked
>> project with testing built in using GLib.Test and Gee.TestCase.  This has
>> appeared on this mailing list before and could be a reasonable beginning.
>> https://code.launchpad.net/~thegreatdane/+junk/agenda-tests
>>
>> 3. I'm working on a small project that I'll eventually put in a
>> repository.  It has the potential to be a good Unit Testing example.
>>
>> My problem is I need help knowing what is good to test, and what is
>> redundant or unnecessary.  We need practical knowledge, and you have it!  I
>> would be glad to do a hangout with you sometime (not today unfortunately)
>> and get this stuff going.  Don't give up or pass the baton.  You brought it
>> up, you need to follow through.
>>
>> On Thu, Aug 22, 2013 at 12:55 AM, Alex Lourie <djay.il@xxxxxxxxx> wrote:
>>
>> Craig
>> It seems we're running circles. No leader is needed now aside for someone
>> who starts writing code. How about you choose some an app you consider to
>> be a good start? We then find volunteers. And start coding.
>>
>> I'm sure that the moment it starts, everyone will be interested in
>> results.
>> On Aug 22, 2013 3:27 AM, "Craig" <weberc2@xxxxxxxxx> wrote:
>>
>>> I'm not opposed; however, every time I've delved into Elementary
>>> development, I've found myself fighting too many tertiary fires before I'm
>>> able to get any real work done (usually it's chasing down one obscure
>>> environment issue or another). So basically, I would like someone who is
>>> competent at Elementary development to "champion" the project (to serve as
>>> its leader) and I and a few other TDDevelopers can coach the development
>>> team as well as help develop ourselves.
>>>
>>> Furthermore, this exercise will be more productive if we have other devs
>>> who are interested in *learning* TDD to participate.
>>>
>>> So basically, if you can find a few elementary-proficient developers to
>>> help with the elementary-specific problems (including a project lead), the
>>> other TDDevelopers and I can coach and develop along side them.
>>>
>>> Thoughts?
>>>
>>>
>>> On Wed, Aug 21, 2013 at 4:50 PM, Kurt Smolderen <
>>> kurt.smolderen@xxxxxxxxxx> wrote:
>>>
>>>> What do you think of giving Footnote some love? I think it is currently
>>>> unmaintained (need to verify that), it's conceptually a rather simple
>>>> application but offers a good set of practices for TDD/ writing tests.
>>>>
>>>> We need to verify first of course what the intentions of the current
>>>> owner are, but I would personally like to see a new version of Footnote...
>>>>
>>>> Craig <weberc2@xxxxxxxxx> wrote:
>>>>>
>>>>>
>>>>> I have never heard a project die because they decided to move to TDD.
>>>>>> And I heard about lots of hits on the matter.
>>>>>
>>>>>
>>>>> This. I've heard (and witnessed) a lot of projects drop their defect
>>>>> percentage from 20% to 3%.  A lot of new-to-TDD developers don't like it at
>>>>> first because it feels slower, but I don't think those people remember how
>>>>> much time is spent bug hunting at the end of a release cycle.
>>>>>
>>>>> I think the next step is to find a pilot project and get the lead
>>>>> developer(s) to agree to work toward TDD. This will probably look like:
>>>>>
>>>>> 1) Modifying the project structure to include _test directories
>>>>> 2) Creating tests with GLib.Test or some such
>>>>> 3) Coaching/mentoring the developers at TDD
>>>>> 4) Performing code reviews in which insufficiently tested code is sent
>>>>> back for revision
>>>>>
>>>>> After testing it out for a few months, the community can see how they
>>>>> like it.
>>>>>
>>>>> Does this sound like a reasonable approach? If so, would any project
>>>>> leads like to volunteer their project? And who in the community would like
>>>>> to participate in such an experiment?
>>>>>
>>>>>
>>>>> On Wed, Aug 21, 2013 at 4:34 AM, Alex Lourie <djay.il@xxxxxxxxx>wrote:
>>>>>
>>>>>> Albert
>>>>>>
>>>>>> We don't need to exaggerate. Though TDD is, indeed, a development
>>>>>> methodology, it is not supposed to completely change the way everyone works.
>>>>>>
>>>>>> Just consider that writing a good test takes about 10 minutes, and
>>>>>> that each developer writes one or two tests for new stuff they add (or the
>>>>>> old one they fix) from time to time. Then, in time, you'll have part of
>>>>>> your code tested, which is exactly what we're aiming for. Beginning is
>>>>>> hard, continue something is easier.
>>>>>>
>>>>>> I have never heard a project die because they decided to move to TDD.
>>>>>> And I heard about lots of hits on the matter.
>>>>>>
>>>>>>
>>>>>>  On Tue, Aug 20, 2013 at 3:37 AM, Albert Palacios <
>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> Hi Craig,
>>>>>>>
>>>>>>> Thanks for your explanation and the linked video. I am still
>>>>>>> agnostic, but I don't want to be the only one who complained about the
>>>>>>> proposal.
>>>>>>>
>>>>>>> At this point I have more questions than answers, and those will
>>>>>>> probably be solved with a working example.
>>>>>>>
>>>>>>> But remember, *TDD is a development methodology* not a testing
>>>>>>> methodology. It will change our development work flow, and will probably
>>>>>>> move potential volunteers away from the project.
>>>>>>>
>>>>>>> TDD like every other development methodology does not fit every
>>>>>>> project or team. It can be a hit, and it can even the death of the project.
>>>>>>>
>>>>>>>  Albert
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Aug 20, 2013 at 12:50 AM, Craig <weberc2@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Hi Albert,
>>>>>>>>
>>>>>>>> Thanks for your response, you asked a lot of great questions. In
>>>>>>>> addition to Gufran's earlier response.
>>>>>>>>
>>>>>>>>  Can you prove that there will be huge benefits in time/resources?
>>>>>>>>
>>>>>>>>
>>>>>>>> Well, that depends on what you consider "proof". In the spring, my
>>>>>>>> company paid several thousand dollars to send me to a conference in San
>>>>>>>> Jose in which many software development authorities recited, "test driven
>>>>>>>> development pays itself off in iteration 0". That means the very first time
>>>>>>>> you write the code it has already paid for itself (because even before you
>>>>>>>> get the automatic-regression testing benefits, you've already got the
>>>>>>>> benefits of a better architecture and documentation--because the tests
>>>>>>>> _are_ the documentation!). I'm sure I can dig up lots of other resources,
>>>>>>>> but I think it should suffice to say that I've never heard an expert
>>>>>>>> comment on TDD except to say it's fastest way to develop quality software.
>>>>>>>> For more information addressing your specific concerns, se e the Wikipedia
>>>>>>>> article's "benefits" section (and read on to the "shortcomings" as it is
>>>>>>>> also relevant:
>>>>>>>> http://en.wikipedia.org/wiki/Test-driven_development#Benefits.
>>>>>>>> Even more importantly, this short video:
>>>>>>>> http://www.youtube.com/watch?v=DodJQyHsmHI
>>>>>>>>
>>>>>>>>
>>>>>>>> Can you prove that there will be less bugs? (looks like that if
>>>>>>>>> tests are not right, bugs will populate equally).
>>>>>>>>
>>>>>>>> It's pretty hard to write bad tests if you're practicing TDD,
>>>>>>>> because you write the test first, watch it fail, insert the code you need
>>>>>>>> to make it pass, and then hopefully watch it pass. If you wrote a bad test,
>>>>>>>> it very probably will pass before you've written the code to make it pass
>>>>>>>> (which serves to alert the programmer that his test is bad or his software
>>>>>>>> is doing something unexpected) or the test will fail after he has correctly
>>>>>>>> written the next line of code (which serves to alert the programmer to
>>>>>>>> review both the code and his test and identify the source of the problem).
>>>>>>>> For this reason alone, many, many bugs are eliminated.
>>>>>>>>
>>>>>>>> From what's been said, looks like there will be an extra effort on
>>>>>>>>> development, adding complexity and more tools to know (not to say maintain).
>>>>>>>>
>>>>>>>> Besides the initial learning curve, development actually goes
>>>>>>>> _faster_ with TDD (see the aforementioned Wikipedia article--I can provide
>>>>>>>> more resources on demand) because debugging time becomes exponentially more
>>>>>>>> expensive as time passes after the bug has been introduced. This is because
>>>>>>>> the bug can live anywhere in any code that has been added *since the last
>>>>>>>> time the tests were run* and because the programmer will have an
>>>>>>>> increasingly difficult time remembering the code he wrote at the time of
>>>>>>>> the bug as time progresses. With TDD, you are running the tests after every
>>>>>>>> change (generally you test every time you build), so as soon as you've
>>>>>>>> broken something you find out about it. This means that the bug is
>>>>>>>> guaranteed to live in the last change you made, which is a smaller sample
>>>>>>>> and fresher-in-your-mind than changes you made weeks ago. Regarding your
>>>>>>>> complexity concern, generally the process isn't complex (it's actually very
>>>>>>>> simple) and it _simplifies_ development once you learn how to do it. The
>>>>>>>> most complex part is figuring out how to integrate testing into the CMake
>>>>>>>> project, and that's only complicated because CMake is complicated.
>>>>>>>> Regarding tools, there are already testing tools available for Vala,
>>>>>>>> including GLib (so we don't have to maintain anything). Anyway, testing
>>>>>>>> tools don't take a terribly long time to learn.
>>>>>>>>
>>>>>>>>  Can we focus on the half done things before adding new projects?
>>>>>>>>> Granite is not ready, documentation is missing, not to talk about the bugs
>>>>>>>>> that survived Luna release ...
>>>>>>>>
>>>>>>>>
>>>>>>>> TDD is more valuable the sooner you start implementing it. Even if
>>>>>>>> you didn't write tests for old code and only started TDD with new code (and
>>>>>>>> existing defects), you would be doing yourself a huge favor. I'm not
>>>>>>>> suggesting that everyone stop what they're doing and go back and test every
>>>>>>>> line of code (although it would be a good thing to chip away at over time),
>>>>>>>> but practicing TDD on _new_ code can't hurt that much, can it?
>>>>>>>>
>>>>>>>> With that in mind, are there any arguments against TDD that
>>>>>>>> outweigh its merits?
>>>>>>>>
>>>>>>>> Thanks again for your questions! :)
>>>>>>>> Craig
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Aug 19, 2013 at 12:32 PM, Albert Palacios <
>>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Hi Craig and Gufran,
>>>>>>>>>
>>>>>>>>> I don't agree with TDD, and making a committee. Can you prove that
>>>>>>>>> there will be huge benefits in time/resources? Can you prove that there
>>>>>>>>> will be less bugs? (looks like that if tests are not right, bugs will
>>>>>>>>> populate equally). Can you prove that creating, modifying and fixing code
>>>>>>>>> is going to be easier?
>>>>>>>>>
>>>>>>>>> From what's been said, looks like there will be an extra effort on
>>>>>>>>> development, adding complexity and more tools to know (not to say
>>>>>>>>> maintain).  Can we focus on the half done things before adding new
>>>>>>>>> projects? Granite is not ready, documentation is missing, not to talk about
>>>>>>>>> the bugs that survived Luna release ...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Mon, Aug 19, 2013 at 7:27 PM, Gufran <dogabhai@xxxxxxxxx>wrote:
>>>>>>>>>
>>>>>>>>>> Count me in.
>>>>>>>>>> I cant really put forward any point on how should we proceed but
>>>>>>>>>> I'd definitely love to be with the team.
>>>>>>>>>> Yes, a *testing committee* is a good idea, maybe something
>>>>>>>>>> independent of dev community. We can write scripts to automate tests, and
>>>>>>>>>> we can do that in any language (Python for example), so it would be like a
>>>>>>>>>> Python coupling between software and tests.
>>>>>>>>>> Just my two cents :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Aug 19, 2013 at 10:43 PM, Craig <weberc2@xxxxxxxxx>wrote:
>>>>>>>>>>
>>>>>>>>>>> This is cool and important, but I don't think it should stop the
>>>>>>>>>>> discussion on test driven development. Perhaps this could be a separate
>>>>>>>>>>> thread? It doesn't sound as though anyone is opposed to TDD, so can we
>>>>>>>>>>> confirm that? And if no one is opposed, how can we proceed? Can we start
>>>>>>>>>>> some kind of a "testing committee" to help determine what testing steps are
>>>>>>>>>>> needed, what framework to use, and how to integrate testing into the
>>>>>>>>>>> existing project structure (i.e., using CMake)?
>>>>>>>>>>>
>>>>>>>>>>> Does this sound like a good plan? Thoughts?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 19, 2013 at 12:05 PM, David Gomes <
>>>>>>>>>>> david@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'll work on it, so far we only have this I made:
>>>>>>>>>>>> https://dl.dropboxusercontent.com/u/19899464/reviewstutorial.html
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 19, 2013 at 6:01 PM, Albert Palacios <
>>>>>>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Munchor,
>>>>>>>>>>>>>
>>>>>>>>>>>>> A contribution / bug fixing step by step guide is needed at
>>>>>>>>>>>>> the developers site. There was a .pdf before the new site change, but now
>>>>>>>>>>>>> it is impossible to find.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  The problem with the old guide is that it encouraged to
>>>>>>>>>>>>> create your own branch instead of using the ~elementary-dev-community one
>>>>>>>>>>>>> (this is totally new for me). Obviously, bazaar guides doesn't teach you on
>>>>>>>>>>>>> using the "elementary-dev-community".
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Mon, Aug 19, 2013 at 6:57 PM, David Gomes <
>>>>>>>>>>>>> david@xxxxxxxxxxxxxxxx> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I always tell people if they make their branches owned by
>>>>>>>>>>>>>> ~elementary-dev-community I will volunteer to fix the code style myself. I
>>>>>>>>>>>>>> have all the free time and the will to do it, just people always make their
>>>>>>>>>>>>>> branches owned by themselves.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ~David "Munchor" Gomes
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Aug 19, 2013 at 4:29 PM, Albert Palacios Jimenez <
>>>>>>>>>>>>>> optimisme@xxxxxxxxx> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Before talking about testing, and advanced development
>>>>>>>>>>>>>>> techniques for teams with resources, there is one easy and simple thing we
>>>>>>>>>>>>>>> can do to accelerate development.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sometimes (very often), bugs are stopped due spaces not
>>>>>>>>>>>>>>> following the "code style" guidelines. Adding a "code style" validator
>>>>>>>>>>>>>>> script before compiling, we can prevent uploads with spaces at the end of
>>>>>>>>>>>>>>> the lines ...  and save a lot of time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> For example, just executing the next line before compiling:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> find . -type f -print0 | xargs -0 sed -i 's/[ \t]*$//'
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We will remove every "white space" at the end of any line,
>>>>>>>>>>>>>>> including new lines with tab spaces.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This can sound stupid, but it is absurd to block bug fixes
>>>>>>>>>>>>>>> during several days due white spaces at the end of lines.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Mailing list:
>>>>>>>>>>>>>>> https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>>>>> Unsubscribe :
>>>>>>>>>>>>>>> https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Alex Lourie
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>>>>
>>>>>
>>>>>
>>>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>>>>
>>>>>
>>>>>
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~elementary-dev-community
>>> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~elementary-dev-community
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>