Hi Dane, I didn't take it hostilely :) And I didn't mean to say I was busier than anyone else; I'm just a lot busier than I used to be I suppose. Let's talk sometime. Email me off the list and we'll sort it out. With that, I think we can conclude this thread.
Have a good night everyone, Craig On Thu, Aug 22, 2013 at 6:48 PM, Dane Henson <d...@elementaryos.org> wrote: > 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" <webe...@gmail.com> 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) < >> d...@elementaryos.org> 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...@gmail.com> 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" <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