elementary-dev-community team mailing list archive

[Craig <weberc2@xxxxxxxxx>]

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 <dane@xxxxxxxxxxxxxxxx> 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" <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
>>>>
>>>>
>>