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
