Start with a trivial improvement!
One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements. This is especially nice as a "starter" when you never contributed any change to Pharo. And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later Taken in itself, single changes like these have no influence, but: -> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it". The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too. Marcus
+100 On 10 Oct 2013, at 13:21, Marcus Denker <marcus.denker@inria.fr> wrote:
One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements.
This is especially nice as a "starter" when you never contributed any change to Pharo.
And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later
Taken in itself, single changes like these have no influence, but:
-> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it".
The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too.
<wtfm.jpg>
Marcus
Thank you, Marcus! Could you post this on the Pharo blog? Doru On Thu, Oct 10, 2013 at 1:36 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
+100
On 10 Oct 2013, at 13:21, Marcus Denker <marcus.denker@inria.fr> wrote:
One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements.
This is especially nice as a "starter" when you never contributed any change to Pharo.
And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later
Taken in itself, single changes like these have no influence, but:
-> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it".
The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too.
<wtfm.jpg>
Marcus
-- www.tudorgirba.com "Every thing has its own flow"
good idea yes for the blog entry On Oct 10, 2013, at 1:42 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you, Marcus!
Could you post this on the Pharo blog?
Doru
On Thu, Oct 10, 2013 at 1:36 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote: +100
On 10 Oct 2013, at 13:21, Marcus Denker <marcus.denker@inria.fr> wrote:
One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements.
This is especially nice as a "starter" when you never contributed any change to Pharo.
And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later
Taken in itself, single changes like these have no influence, but:
-> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it".
The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too.
<wtfm.jpg>
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
I like it Marcus. Good start point. Thanks On Thu, Oct 10, 2013 at 12:25 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
good idea yes for the blog entry
On Oct 10, 2013, at 1:42 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
Thank you, Marcus!
Could you post this on the Pharo blog?
Doru
On Thu, Oct 10, 2013 at 1:36 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:
+100
On 10 Oct 2013, at 13:21, Marcus Denker <marcus.denker@inria.fr> wrote:
One nice way to get in the mood of doing (and at the same time testing the system) is to start with trivial improvements.
This is especially nice as a "starter" when you never contributed any change to Pharo.
And by trivial I mean *really* mean trivial: -> a typo in a comment -> remove a temp not accessed -> clean out some trivial dead code -> do a simplistic refactoring of a bad smell, even inside a single method -> document something -> structure bad stuff better so it is easier to replace later
Taken in itself, single changes like these have no influence, but:
-> they get you in a mood of doing. -> they make you feel that Pharo is "owned" by you. -> take 1000 of those trivialities and they *do* make a difference. -> next time something bothers you, you will have the context of "I can just fix it".
The critic tools is one way of finding these places, another is to just note down every time you see a triviality and later go through that list. The bug tracker can be source, too.
<wtfm.jpg>
Marcus
-- www.tudorgirba.com
"Every thing has its own flow"
This is something I was contemplating lately for my project Ephestos. The problem I see with your approach is that it takes a long time to see those changes integrated into Pharo cause AFAIK there are not many people to check out those "fixes" approve them and then integrate them. Now multiple that by 1000. Yeah right ! So I decided to follow the external library route. My initial concern about my project was that I want a better Morphic. Now the sensible start would be to do what you suggested, start small , fix morphic problems here and there, tiny clean ups to the code etc. But I realised that if someone pings me back months later about a fix he does not like and I am way forward in the development process that could seriously mess with my code and even make it hard to change the fix. So it was a great news indeed that morphic is entirely (or almost entirely ?) written in smalltalk. I am back at studying opengl since I want to make an opengl implementation of moprhic , but also I would also like to get rid of things I dont like about morphic. Making it into an external lib also makes sure I dont brake people's code but also I am tied into things I dont like and need the approval of the community to fix. So yes I agree that what you say sounds ideal in theory, but its not ideal in practice. -- View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4713655.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Oct 10, 2013, at 2:22 PM, kilon <thekilon@yahoo.co.uk> wrote:
This is something I was contemplating lately for my project Ephestos. The problem I see with your approach is that it takes a long time to see those changes integrated into Pharo cause AFAIK there are not many people to check out those "fixes" approve them and then integrate them. Now multiple that by 1000. Yeah right !
So I decided to follow the external library route. My initial concern about my project was that I want a better Morphic. Now the sensible start would be to do what you suggested, start small , fix morphic problems here and there, tiny clean ups to the code etc. But I realised that if someone pings me back months later about a fix he does not like and I am way forward in the development process that could seriously mess with my code and even make it hard to change the fix.
So it was a great news indeed that morphic is entirely (or almost entirely ?) written in smalltalk. I am back at studying opengl since I want to make an opengl implementation of moprhic , but also I would also like to get rid of things I dont like about morphic. Making it into an external lib also makes sure I dont brake people's code but also I am tied into things I dont like and need the approval of the community to fix.
So yes I agree that what you say sounds ideal in theory, but its not ideal in practice.
but we are not talk ing about theory. if nobody take care about little glitches them you will have a house full of little borken glasses and dirt everywhere. And I do not work to live there. My house is cosy warm and really cool and everyday I clean it. I fix a door handle as soon as I see it having a problem not waiting that the door falls on the floor.
-- View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4713655.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Stéphane Ducasse wrote
On Oct 10, 2013, at 2:22 PM, kilon <
thekilon@.co
> wrote:
but we are not talk ing about theory. if nobody take care about little glitches them you will have a house full of little borken glasses and dirt everywhere. And I do not work to live there. My house is cosy warm and really cool and everyday I clean it. I fix a door handle as soon as I see it having a problem not waiting that the door falls on the floor.
You make a valid point here, I see now my post again and I dont like the way I phrased it. What I meant to say is that if the integration process is too slow , then people will more likely choose to create their own solutions than bug fix the old ones, because it would be easier for them to maintain those solutions than wait for the integration process. And I was wondering if that's true and how it could be avoided . I did not mean to imply that this is a good thing, of course its not a good thing and of course we all must help to make pharo more stable and faster. Marcus Denker-4 wrote
On Oct 12, 2013, at 6:33 AM, kilon <
thekilon@.co
> wrote:
There is right now no problem to review and integrate more simple changes⦠it's the complex stuff that sometimes takes a while.
For simple things we are at <24 hours.
The other thing: if there are multiple people submitting simple fixes, these will very quickly start to *review* simple fixes, too. One just needs to start.
Marcus
signature.asc (210 bytes) <http://forum.world.st/attachment/4713991/0/signature.asc>;
I am happy you prove me wrong. 24 hours sounds very fast to me, I did not realize that integration was so fast. I have to say that was the one thing that was holding me back, I just did not want to invest an effort to see my bug fix die in oblivion. And yes I agree , this will make it more inviting for the people to bug fix. I will try to have a go in a couple of "easy" bug fixes. Lets put your theory into practice , shall we ? -- View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4714014.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Just to add a little element: I do not know of any programming system (language, libraries, IDE) where it is possible for normal users to contribute changes like in Pharo. In most well known languages it takes years and committee decisions to make any change. In many open source projects you have to be part of an inner circle to get anything accepted. Sven On 12 Oct 2013, at 10:15, kilon <thekilon@yahoo.co.uk> wrote:
Stéphane Ducasse wrote
On Oct 10, 2013, at 2:22 PM, kilon <
thekilon@.co
> wrote:
but we are not talk ing about theory. if nobody take care about little glitches them you will have a house full of little borken glasses and dirt everywhere. And I do not work to live there. My house is cosy warm and really cool and everyday I clean it. I fix a door handle as soon as I see it having a problem not waiting that the door falls on the floor.
You make a valid point here, I see now my post again and I dont like the way I phrased it. What I meant to say is that if the integration process is too slow , then people will more likely choose to create their own solutions than bug fix the old ones, because it would be easier for them to maintain those solutions than wait for the integration process.
And I was wondering if that's true and how it could be avoided . I did not mean to imply that this is a good thing, of course its not a good thing and of course we all must help to make pharo more stable and faster.
Marcus Denker-4 wrote
On Oct 12, 2013, at 6:33 AM, kilon <
thekilon@.co
> wrote:
There is right now no problem to review and integrate more simple changes⦠it's the complex stuff that sometimes takes a while.
For simple things we are at <24 hours.
The other thing: if there are multiple people submitting simple fixes, these will very quickly start to *review* simple fixes, too. One just needs to start.
Marcus
signature.asc (210 bytes) <http://forum.world.st/attachment/4713991/0/signature.asc>;
I am happy you prove me wrong. 24 hours sounds very fast to me, I did not realize that integration was so fast. I have to say that was the one thing that was holding me back, I just did not want to invest an effort to see my bug fix die in oblivion.
And yes I agree , this will make it more inviting for the people to bug fix. I will try to have a go in a couple of "easy" bug fixes. Lets put your theory into practice , shall we ?
-- View this message in context: http://forum.world.st/Start-with-a-trivial-improvement-tp4713648p4714014.htm... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
On Oct 12, 2013, at 6:33 AM, kilon <thekilon@yahoo.co.uk> wrote:
This is something I was contemplating lately for my project Ephestos. The problem I see with your approach is that it takes a long time to see those changes integrated into Pharo cause AFAIK there are not many people to check out those "fixes" approve them and then integrate them. Now multiple that by 1000. Yeah right !
There is right now no problem to review and integrate more simple changes⦠it's the complex stuff that sometimes takes a while. For simple things we are at <24 hours. The other thing: if there are multiple people submitting simple fixes, these will very quickly start to *review* simple fixes, too. One just needs to start. Marcus
participants (6)
-
Facundo Vozzi -
kilon -
Marcus Denker -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba