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" <webe...@gmail.com> 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.smolde...@empuly.net > > 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 <webe...@gmail.com> 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...@gmail.com> 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 >>>> <optimi...@gmail.com>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 <webe...@gmail.com> 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 < >>>>>> optimi...@gmail.com> 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 <dogab...@gmail.com> 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 <webe...@gmail.com> 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 < >>>>>>>>> da...@elementaryos.org> 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 < >>>>>>>>>> optimi...@gmail.com> 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 < >>>>>>>>>>> da...@elementaryos.org> 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 < >>>>>>>>>>>> optimi...@gmail.com> 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@lists.launchpad.net >>>>>>>>>>>>> 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@lists.launchpad.net >>>>>>>>>> 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@lists.launchpad.net >>>>>>>>> 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@lists.launchpad.net >>>>>>>> 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@lists.launchpad.net >>>>> 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@lists.launchpad.net >>> 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@lists.launchpad.net > 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~elementary-dev-community More help : https://help.launchpad.net/ListHelp
