Hi,
Karsten Kusche and I are working for Georg Heeg eK to improve Smalltalk developers workflow while keeping flexibility. Ideas have to be grabbed to help average Smalltalk developers to make a good design and follow an established workflow.
We would like to finish our work with a tool that everybody can use for development. It should be an extension to the existing browser that displays more information.
Attention is being put in easing unit tests, making the comprehension of an existing system simpler, and giving lots of information about methods, classes and packages.
If you have ideas, publications or things that we can test or read, it would be interesting to share with us.
Thank you for your help, we hope we will be able to present something at ESUG 2006.
Bye
-- Damien Cassou
Ok, it's 5 minutes on your side and 3 months on mine... At the end, we can produce a very interesting browser for all of you.
Are you sure you don't have any links or ideas ?
Hi damien
here is a list:
- we need smart categories (where we can drop what we want, even to do items) cf starbrowser
- if would be good to have path in the browsed classes (like in the forest): the last time you came in the class you look at these methods
- multiple panes for simultaneous method browsing cf whisher
- support for refactoring and consistent key binding everywhere (in VW this is broken) you cannot extract a method from the debugger and some key binding do not work in different tools.
- Sometimes I would like to browse a class and all its collaborators (using dirrect reference to classes or typer result) and I do not want to see all the other classes in the same packages.
- We should always be able to see the superclass chain in any browser. In squeak this is really missing. Opening yet another browser is a bad idea.
Thank you for this ideas. They are helpful and we might base our work on such kind of ideas.
Thanks
Le Wednesday 28 June 2006 10:36, stéphane ducasse a écrit :
Hi damien
here is a list:
Hi Stephane
some of functionalities you are looking for are implemented in tamaris.
- we need smart categories (where we can drop what we want, even to
do items) cf starbrowser
cf tamaris
- if would be good to have path in the browsed classes (like in the
forest): the last time you came in the class you look at these methods
cf tamaris ?
- multiple panes for simultaneous method browsing cf whisher
cf tamaris
- support for refactoring and consistent key binding everywhere (in
VW this is broken) you cannot extract a method from the debugger and some key binding do not work in different tools.
- Sometimes I would like to browse a class and all its collaborators
(using dirrect reference to classes or typer result) and I do not want to see all the other classes in the same packages.
cf tamaris ?
- We should always be able to see the superclass chain in any
browser. In squeak this is really missing.
cf tamaris
Opening yet another browser is a bad idea.
alain
Hi Damien.
I am very interested in this kind of thing, unfortunately my understanding and/or point of view is fashioned via experience rather than any particular papers/publications/code, but I'll plough on regardless :)
Just to be clear on definition, by "workflow" I am thinking in terms of a developer's day-to-day development work (be that design, coding, writing of unit tests, whatever) and its integration with both a work/bug/whatever-tracking system and a source-control system.
A while ago I posted a rather large (and largely uninformed) email to the list about Monticello trying to get some answers up-front before I had ever used it in anger, with respect to integrating it into a model of developer workflow.
Too stop this turning into more of a tome then it already is, here's the gmane link to the email: http://shrunk.net/472063cf
In reply Avi came up with a suggestion of how to loosely (ie not restricted programmatically, just conventionally) model this workflow with Monticello here: http://shrunk.net/47742a1b (there were lots of other useful replies, sorry I can't quote them all).
These days I know MC much better - so I can understand his suggestion, and it's good. Of course, in an ideal world, the browser would provide a framework for the developer to support a workflow like this. This is where you guys step in :)
As an aside, it has always one of my primary requirements for any such tools and workflows has always been to absolutely minimise impact on design and development time.
So that's a coupling of development and source control workflow. But there are other things to consider that I am very interested in, too.
1. The explicit coupling of tools with the bug tracking system in smalltalk - this is currently completely unsupported. I have written PHP tools like this to integrate file-based development with svn and Mantis, and they work pretty well. I have held off doing tools like this in Smalltalk yet, though, because I've heard rumour of a very flexible and powerful bug (and other things) tracking system arriving in Squeak in the near future.
2. The integration of other steps of workflow - in fact perhaps the three most important: Design, Unit test development (ie "up-front" TDD rather than "when there's time" testing), and code review.
This coordinates interestingly with Agile methodoloies. In Scrum there needs to be a clearly defined value of "Done" for any bit of work, that ought to mean something like "well designed, cleanly coded, unit tested, refactored and peer code reviewed". Any tool that attempts to aid developer workflow would do well to aim to help a developer achieve this level of "doneness" in a well defined and repeatable manner.
A final note, regarding tools to aid code review: Cenqua are a company who write a very useful subversion/CVS analysis tool called Fisheye. They are also now in beta of a tool that integrates Fisheye with a code review framework called Crucible. It may be worth taking a look at that as an idea of how to model the code review part of developer workflow, as Cenqua traditionally (in my experience anyway) create well thought out and useful tools.
I meant this email as an open discussion of my ideas regarding developer workflow work, hence the length. I hope it can be of some use!
Cheers, Simon
Damien Cassou wrote:
Hi,
Karsten Kusche and I are working for Georg Heeg eK to improve Smalltalk developers workflow while keeping flexibility. Ideas have to be grabbed to help average Smalltalk developers to make a good design and follow an established workflow.
We would like to finish our work with a tool that everybody can use for development. It should be an extension to the existing browser that displays more information.
Attention is being put in easing unit tests, making the comprehension of an existing system simpler, and giving lots of information about methods, classes and packages.
If you have ideas, publications or things that we can test or read, it would be interesting to share with us.
Thank you for your help, we hope we will be able to present something at ESUG 2006.
Bye
-- Damien Cassou
Simon Kirk a écrit :
Hi Damien.
Hi Simon,
I am very interested in this kind of thing, unfortunately my understanding and/or point of view is fashioned via experience rather than any particular papers/publications/code, but I'll plough on regardless :)
Experienced Smalltalkers have full of ideas and I'm glad to hear your opinion. Thank you for answering.
Just to be clear on definition, by "workflow" I am thinking in terms of a developer's day-to-day development work (be that design, coding, writing of unit tests, whatever) and its integration with both a work/bug/whatever-tracking system and a source-control system.
Exactly
A while ago I posted a rather large (and largely uninformed) email to the list about Monticello trying to get some answers up-front before I had ever used it in anger, with respect to integrating it into a model of developer workflow.
Too stop this turning into more of a tome then it already is, here's the gmane link to the email: http://shrunk.net/472063cf
This discussion is very interesting ("Squeak, source control, subversion, versioning, monticello, all that good stuff")
In reply Avi came up with a suggestion of how to loosely (ie not restricted programmatically, just conventionally) model this workflow with Monticello here: http://shrunk.net/47742a1b (there were lots of other useful replies, sorry I can't quote them all).
These days I know MC much better - so I can understand his suggestion, and it's good. Of course, in an ideal world, the browser would provide a framework for the developer to support a workflow like this. This is where you guys step in :)
This is an interesting idea we could work on.
[...] 2. The integration of other steps of workflow - in fact perhaps the three most important: Design, Unit test development (ie "up-front" TDD rather than "when there's time" testing), and code review.
We would like to work on this too.
This coordinates interestingly with Agile methodoloies. In Scrum there needs to be a clearly defined value of "Done" for any bit of work, that ought to mean something like "well designed, cleanly coded, unit tested, refactored and peer code reviewed". Any tool that attempts to aid developer workflow would do well to aim to help a developer achieve this level of "doneness" in a well defined and repeatable manner.
I didn't know Scrum, thank you for this.
A final note, regarding tools to aid code review: Cenqua are a company who write a very useful subversion/CVS analysis tool called Fisheye. They are also now in beta of a tool that integrates Fisheye with a code review framework called Crucible. It may be worth taking a look at that as an idea of how to model the code review part of developer workflow, as Cenqua traditionally (in my experience anyway) create well thought out and useful tools.
I meant this email as an open discussion of my ideas regarding developer workflow work, hence the length. I hope it can be of some use!
It is, thank you
squeak-dev@lists.squeakfoundation.org
-
Alain Plantec -
Damien Cassou -
Simon Kirk -
stéphane ducasse