elementary-dev-community team mailing list archive

[Alex Lourie <djay.il@xxxxxxxxx>]

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
>
>