QualityAssistant v0.4

> On 24 Apr 2015, at 8:41 , stepharo <[hidden email]> wrote:
>
> I understand the point of marcus but still it is unclear why certain tools should be in and not others.
> Now I would prefer that we have a process that
>
>    1 := take a miniimage AND load the tools
>        check that we can unload them (just to check)
>    and only then declare
>
>    pharo := 1.
>
>    Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread)
>    Read the Pharo vision paper.
>
> Stef

> On 24 Apr 2015, at 08:41, stepharo <[hidden email]> wrote:
>
> I understand the point of marcus but still it is unclear why certain tools should be in and not others.
> Now I would prefer that we have a process that
>
>    1 := take a miniimage AND load the tools
>        check that we can unload them (just to check)
>    and only then declare
>
>    pharo := 1.
>
>    Now we will face the problem of ok we do a change and it touches such loaded tools (see the other thread)
>    Read the Pharo vision paper.

>
> Stef
>
>
> Le 23/4/15 10:53, Yuriy Tymchuk a écrit :
>> I totally agree with Stef that we should be able to do a rock solid setup of what tools we want to use in our everyday image.
>>
>> But on the other hand we have to design what Pharo is. Because we can even go Ruby style and say that debugger is not a part of the main system, but I see that our strength is to provide people with ultimate tools for development (although we cannot put everything inside). And I think that dependency browser is important and I will continue to convince people that quality of code is important and that we should use quality tools in our daily work. Maybe now QualityAssistant is not mature enough, but at some point it will be :).
>>
>> Cheers.
>> Uko
>>
>>
>> P.S. at the moment we are loosing competition to JetBrains tools because they give you live feedback about code critics.
>>
>>
>>> On 23 Apr 2015, at 09:04, stepharo <[hidden email]> wrote:
>>>
>>>
>>>
>>> Le 23/4/15 09:05, Marcus Denker a écrit :
>>>> I do not understand how “having a modular tool in the image ” (that does not add dependencies to anything)
>>>> makes the system less modular.
>>> Then why the dependency Browser was not integrated? Why roassal for drawing dependencies
>>> and other aspects of the system? Because dependency browser as well as roassal are really useful,
>>> well packaged, What about pillar? Because it would be cool to have beautiful class comments in the future. The point is how and in which process.
>>> In addition what are the criteria? Feelings or criteria? Oh this tool is cool but this one less cool.
>>> Strange for scientific people no?
>>> I think that we should have a building process that load tools.
>>> We will not be able to put everything in the image:
>>> Did you look at the dependencies between RB, nautilus, history, EyeInspector?
>>> I did because it was getting the mess. My energy is cheap and infinite so I can spend 8 hours
>>> fixing configurations that nobody use or look at. But you see this period is ***over***.
>>>
>>>>> So to me it simply means that we are not serious and convinced about modularity.
>>>>>
>>>>> But this is great, I'm reconsidering what I will do in Pharo so you give me good indication
>>>>> that I should not continue the way I was thinking. And no need to think that I'm emotional
>>>>> I'm not. I'm thinking about why hell I'm doing all this.
>>>>>
>>>> You always directly go and argue by “I am now sad” purely emotional level.
>>>> This is not good.
>>> Read what you want to read. But my energy in neither cheap nor infinite anymore.
>>> This is not a feeling but just a mere fact.
>>>
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>
>>
>>
>
>