November 2011 - Esug-list - lists.esug.org

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Stan Shepherd

Is this a fix to production? If so, has it also been backfilled to the development branch? ...Stan -- View this message in context: http://forum.world.st/Call-for-your-input-on-questions-you-ask-yourselves-d… Sent from the ESUG mailing list archive at Nabble.com.

Nov. 29, 2011

Re: [Esug-list] ESUG Video upload continuing...

by Sean P. DeNigris

Marcus Denker-4 wrote > > We are slowly, but steadily uploading videos to Youtube. > Will someone add a link from the ESUG 2011 page (like the one for 2010). Thanks. Sean -- View this message in context: http://forum.world.st/ESUG-Video-upload-continuing-tp3877544p4115797.html Sent from the ESUG mailing list archive at Nabble.com.

Nov. 28, 2011

Re: [Esug-list] fosdem smalltalk devroom

by Paolo Bonzini

On 11/28/2011 01:45 PM, Stephan Eggermont wrote: > No, not yet. Do we need a separate one or can we use one of the existing ones? > I'm following a.o. squeak-dev, pharo-dev, seaside FOSDEM gives a mailing list, right? I would like GNU Smalltalk to be represented, since I'll be attending FOSDEM too. Paolo

Nov. 28, 2011

Re: [Esug-list] fosdem smalltalk devroom

by Stephan Eggermont

No, not yet. Do we need a separate one or can we use one of the existing ones? I'm following a.o. squeak-dev, pharo-dev, seaside Stephan On 28 nov 2011, at 12:37, Paolo Bonzini wrote: > Hi all, is there a mailing list or website set up for discussing the program for the devroom? > > Thanks, > > Paolo > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 28, 2011

fosdem smalltalk devroom

by Paolo Bonzini

Hi all, is there a mailing list or website set up for discussing the program for the devroom? Thanks, Paolo

Nov. 28, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Tudor Girba

Hi, Besides the questions you asked, I would be interested in how changes are grouped together. In particular, when merging the work of multiple authors with changes stacked on top of each other, I would like to be able to group the differences in different ways. For example: - I would like to be able to group them by author, or - I would like to group them by time (such that commits on different packages get closer together when they are committed closer in time). Cheers, Doru On 23 Nov 2011, at 16:57, Stéphane Ducasse wrote: > Hi guys > > We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to merge some code in your project? > We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another branch of my software? > > Stef D., Andy K. and Veronica U. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org -- www.tudorgirba.com "Don't give to get. Just give."

Nov. 27, 2011

Re: [Esug-list] Antwort: Call for your input on questions you ask yourselves during merge

by stephane ducasse

On Nov 26, 2011, at 1:19 PM, Lukas Renggli wrote: > I suspect that the author is the best person to answer all of the > questions that come up so far. Ideally I would like to be able to > directly get into contact with the author in the context of a > particular code change line. I would like to ask him questions and/or > ask/suggest improvements. > > Ideally there should be no merging activities at all. Ideally whoever > wants the code in should bring it to a state i can just load and > understand: what does it do? is it tested? is it covered? ... in the > end it all boils down to: is it better? Nothing is so simple. There is the automatic part of merging and this is should be ok. The process can cover: is the code compliant with certain rules, runs the tests…. Now there are cases where you cannot access the author. And there are cases where you do not want a given features or its implementation. For example would you accept a code that add , on Object to concatenate objects or something like that. Now the question is also if you work on code you wrote or somebody else and that you do not really know. >From that perspectives I want tools that will help me asking queries as: - is the change I'm looking composed of different independent features? - did the change changed after? - how many time these methods got changed? - are the methods invoked in later change? - can I apply this change directly? - on what this change rely? - what is the spread of the changes? - what is the vocabulary of the changes? (if this is just changing Smalltalk by self environment….kind of). Stef > > Lukas > > > On 26 November 2011 10:50, Andy Kellens <akellens(a)vub.ac.be> wrote: >> Hello, >> >> Already many thanks for all the input we received. >> As a way to stimulate the discussion a bit, you can find my list of questions below. >> >> * Who made the changes? >> * How big are the changes? Are they local or do they touch a lot of stuff? >> * Was this method changed a lot of times in the past? Why did it change? >> (I noticed in my projects stuff that keeps on changing most of the times indicates that something is not really right in the design) >> * Is this change part of a whole series of changes? (when someone is working on a feature and commits intermittently, I sometimes prefer to wait loading their changes until I know they are done) >> * Why were the changes made? Bugfix? New feature? Refactoring? Cleanup? >> * Who wrote the original code that was changed? Was any of my old code changed? >> * Is the commit coherent? Do all the changes within the commit belong together or are they unrelated? >> (This also happens often I think: someone fixes a bug and decides to also rename a method or clean something up … very annoying to find out what really happened) >> * Is this change impacted/influenced by a change that happened in another branch of my software? >> * Did this change ever happen before? >> * Is this change reverting the code to an old state? >> (someone changes some code to actually roll back something; would like to know this since it might be by accident) >> * Did the person who made the change also update the tests? Was this necessary? >> * If I just load the change, what are the changes that it breaks my current system? >> * When multiple packages were committed at the same time: do I really need to load all of them now, or can I just load/merge with the version of the package I'm working on? >> >> Kind regards, >> >> Andy >> >> On 26 Nov 2011, at 08:56, Stéphane Ducasse wrote: >> >>> tx :) >>> >>> On Nov 24, 2011, at 1:38 PM, Thorsten.Seitz(a)deutschebahn.com wrote: >>> >>>> - When the version to be merged into the trunk is on a branch which I >>>> already did merge a couple of versions earlier I want to have to see/think >>>> about only those changes that are new (i.e. the changes between the version >>>> last merged and the current version to be merged and not all changes >>>> between the current version to be merged and the trunk version to be merged >>>> into) >>>> >>>> e.g. >>>> >>>> 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk >>>> \ / / ?? questions asked here >>>> \ / / >>>> -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch >>>> >>>> The branch version 2.2 has already been merged into trunk version 5.0 some >>>> time earlier. >>>> Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. >>>> I don't know what Pharo does but VisualWorksdisplays all changes between >>>> 2.4 and 7.0 while giving additional information about the last common >>>> version which is determined to be 2.0 because previous merges are not >>>> considered. >>>> This forces me to think about how to merge all changes up to version 2.2 >>>> once again. >>>> We fixed that in our tools, of course (in VW 7.6), offering an additional >>>> merge option which only merges the changes since a user selected common >>>> version. >>>> >>>> Regards >>>> Thorsten >>>> >>>> >>>> Thorsten Seitz >>>> Development Center Architekturkonzeption und -entwicklung (T.SVD 32) >>>> >>>> DB Systel GmbH >>>> Raum 5C.136, Alfred-Herrhausen-Allee 1, 65760 Eschborn >>>> Tel. 069 265-48245, intern 955- >>>> _________________________________________________________________________________ >>>> >>>> Der DB-Konzern im Internet >> http://www.deutschebahn.com >>>> >>>> Sitz der Gesellschaft: Frankfurt am Main >>>> Registergericht: Frankfurt am Main, HRB 78707 >>>> USt-IdNr.: DE252204770 >>>> Geschäftsführer: Detlef Exner (Vorsitzender), Dr. Burkhard Klanke, Dr. >>>> Klaus Rüffler >>>> Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel >>>> >>>> >>>> |------------> >>>> | Von: | >>>> |------------> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |Stéphane Ducasse <stephane.ducasse(a)inria.fr> | >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |------------> >>>> | An: | >>>> |------------> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |ESUG Members <esug-list(a)lists.esug.org> | >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |------------> >>>> | Datum: | >>>> |------------> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |23.11.2011 16:58 | >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |------------> >>>> | Betreff: | >>>> |------------> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |[Esug-list] Call for your input on questions you ask yourselves during merge | >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |------------> >>>> | Gesendet | >>>> | von: | >>>> |------------> >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> |esug-list-bounces(a)lists.esug.org | >>>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>>> >>>> >>>> >>>> >>>> >>>> Hi guys >>>> >>>> We are writing some articles on the work of veronica to support merging >>>> activities. We need your input great smalltalk community :) >>>> What are the questions that you ask yourselves when you are/want to merge >>>> some code in your project? >>>> We would like to do a compilation of questions and also evaluate how the >>>> solution of veronica solves them or part of them. >>>> >>>> Here are some typical questions we asked ourselves. >>>> - What other changes did this change require? >>>> - Can I integrate this change right now? >>>> - How large it is? >>>> - Who made it? >>>> - Is it still valid (when I'm working on an old change)? >>>> - Is this change impacted by a change that happened in another >>>> branch of my software? >>>> >>>> Stef D., Andy K. and Veronica U. >>>> >>>> >>>> _______________________________________________ >>>> Esug-list mailing list >>>> Esug-list(a)lists.esug.org >>>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 26, 2011

Fwd: [Pharo-project] INRIA Postdoc position: security in dynamic languages

by Mariano Martinez Peck

---------- Forwarded message ---------- From: stephane ducasse <stephane.ducasse(a)free.fr> Date: Sat, Nov 26, 2011 at 4:55 AM Subject: [Pharo-project] INRIA Postdoc position: security in dynamic languages To: An open mailing list to discuss any topics related to an open-source Smalltalk <Pharo-project(a)lists.gforge.inria.fr> Postdoc Position • Duration: 3 years • Starting date: end 2011 • Where: RMOD team at INRIA Lille Nord Europe http://rmod.lille.inria.fr • Salary: 55 Keuros net (before taxes) Keywords: dynamic languages, security, information flow, Smalltalk, Javascript The position will take place in the context of the Systematic Resilience project. We will focus on the following main tasks: • Identification and understanding of security problems in Javascript and other dynamic languages • Study and analyze existing approaches towards securing Javascript (Caja, isolates...) • Comparison of different approaches to secure dynamic applications (Zope model, ZTK), Ruby • Study of Mirrors/Capabilities as a basis for security in Javascript • Proposition of an safe architecture for Resilience Please contact Stephane Ducasse (Stephane.Ducasse(a)inria.fr) for more information. http://rmod.lille.inria.fr/ http://stephane.ducasse.free.fr -- Mariano http://marianopeck.wordpress.com

Nov. 26, 2011

Re: [Esug-list] Antwort: Call for your input on questions you ask yourselves during merge

by Michael Roberts

Hi Stef, I would just add that in a team environment, with some form of continuous integration, it is useful to know what other proposed changes are in flight. It could be interesting to reason about both an individual merge, and any concurrent merging. cheers, Mike

Nov. 26, 2011

Re: [Esug-list] Antwort: Call for your input on questions you ask yourselves during merge

by Lukas Renggli

I suspect that the author is the best person to answer all of the questions that come up so far. Ideally I would like to be able to directly get into contact with the author in the context of a particular code change line. I would like to ask him questions and/or ask/suggest improvements. Ideally there should be no merging activities at all. Ideally whoever wants the code in should bring it to a state i can just load and understand: what does it do? is it tested? is it covered? ... in the end it all boils down to: is it better? Lukas On 26 November 2011 10:50, Andy Kellens <akellens(a)vub.ac.be> wrote: > Hello, > > Already many thanks for all the input we received. > As a way to stimulate the discussion a bit, you can find my list of questions below. > > * Who made the changes? > * How big are the changes? Are they local or do they touch a lot of stuff? > * Was this method changed a lot of times in the past? Why did it change? > (I noticed in my projects stuff that keeps on changing most of the times indicates that something is not really right in the design) > * Is this change part of a whole series of changes? (when someone is working on a feature and commits intermittently, I sometimes prefer to wait loading their changes until I know they are done) > * Why were the changes made? Bugfix? New feature? Refactoring? Cleanup? > * Who wrote the original code that was changed? Was any of my old code changed? > * Is the commit coherent? Do all the changes within the commit belong together or are they unrelated? > (This also happens often I think: someone fixes a bug and decides to also rename a method or clean something up … very annoying to find out what really happened) > * Is this change impacted/influenced by a change that happened in another branch of my software? > * Did this change ever happen before? > * Is this change reverting the code to an old state? > (someone changes some code to actually roll back something; would like to know this since it might be by accident) > * Did the person who made the change also update the tests? Was this necessary? > * If I just load the change, what are the changes that it breaks my current system? > * When multiple packages were committed at the same time: do I really need to load all of them now, or can I just load/merge with the version of the package I'm working on? > > Kind regards, > > Andy > > On 26 Nov 2011, at 08:56, Stéphane Ducasse wrote: > >> tx :) >> >> On Nov 24, 2011, at 1:38 PM, Thorsten.Seitz(a)deutschebahn.com wrote: >> >>> - When the version to be merged into the trunk is on a branch which I >>> already did merge a couple of versions earlier I want to have to see/think >>> about only those changes that are new (i.e. the changes between the version >>> last merged and the current version to be merged and not all changes >>> between the current version to be merged and the trunk version to be merged >>> into) >>> >>> e.g. >>> >>> 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk >>> \ / / ?? questions asked here >>> \ / / >>> -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch >>> >>> The branch version 2.2 has already been merged into trunk version 5.0 some >>> time earlier. >>> Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. >>> I don't know what Pharo does but VisualWorksdisplays all changes between >>> 2.4 and 7.0 while giving additional information about the last common >>> version which is determined to be 2.0 because previous merges are not >>> considered. >>> This forces me to think about how to merge all changes up to version 2.2 >>> once again. >>> We fixed that in our tools, of course (in VW 7.6), offering an additional >>> merge option which only merges the changes since a user selected common >>> version. >>> >>> Regards >>> Thorsten >>> >>> >>> Thorsten Seitz >>> Development Center Architekturkonzeption und -entwicklung (T.SVD 32) >>> >>> DB Systel GmbH >>> Raum 5C.136, Alfred-Herrhausen-Allee 1, 65760 Eschborn >>> Tel. 069 265-48245, intern 955- >>> _________________________________________________________________________________ >>> >>> Der DB-Konzern im Internet >> http://www.deutschebahn.com >>> >>> Sitz der Gesellschaft: Frankfurt am Main >>> Registergericht: Frankfurt am Main, HRB 78707 >>> USt-IdNr.: DE252204770 >>> Geschäftsführer: Detlef Exner (Vorsitzender), Dr. Burkhard Klanke, Dr. >>> Klaus Rüffler >>> Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel >>> >>> >>> |------------> >>> | Von: | >>> |------------> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |Stéphane Ducasse <stephane.ducasse(a)inria.fr> | >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |------------> >>> | An: | >>> |------------> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |ESUG Members <esug-list(a)lists.esug.org> | >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |------------> >>> | Datum: | >>> |------------> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |23.11.2011 16:58 | >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |------------> >>> | Betreff: | >>> |------------> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |[Esug-list] Call for your input on questions you ask yourselves during merge | >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |------------> >>> | Gesendet | >>> | von: | >>> |------------> >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> |esug-list-bounces(a)lists.esug.org | >>>> --------------------------------------------------------------------------------------------------------------------------------------------------| >>> >>> >>> >>> >>> >>> Hi guys >>> >>> We are writing some articles on the work of veronica to support merging >>> activities. We need your input great smalltalk community :) >>> What are the questions that you ask yourselves when you are/want to merge >>> some code in your project? >>> We would like to do a compilation of questions and also evaluate how the >>> solution of veronica solves them or part of them. >>> >>> Here are some typical questions we asked ourselves. >>> - What other changes did this change require? >>> - Can I integrate this change right now? >>> - How large it is? >>> - Who made it? >>> - Is it still valid (when I'm working on an old change)? >>> - Is this change impacted by a change that happened in another >>> branch of my software? >>> >>> Stef D., Andy K. and Veronica U. >>> >>> >>> _______________________________________________ >>> Esug-list mailing list >>> Esug-list(a)lists.esug.org >>> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >>> >>> >>> >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > -- Lukas Renggli www.lukas-renggli.ch

Nov. 26, 2011

Re: [Esug-list] Antwort: Call for your input on questions you ask yourselves during merge

by Andy Kellens

Hello, Already many thanks for all the input we received. As a way to stimulate the discussion a bit, you can find my list of questions below. * Who made the changes? * How big are the changes? Are they local or do they touch a lot of stuff? * Was this method changed a lot of times in the past? Why did it change? (I noticed in my projects stuff that keeps on changing most of the times indicates that something is not really right in the design) * Is this change part of a whole series of changes? (when someone is working on a feature and commits intermittently, I sometimes prefer to wait loading their changes until I know they are done) * Why were the changes made? Bugfix? New feature? Refactoring? Cleanup? * Who wrote the original code that was changed? Was any of my old code changed? * Is the commit coherent? Do all the changes within the commit belong together or are they unrelated? (This also happens often I think: someone fixes a bug and decides to also rename a method or clean something up … very annoying to find out what really happened) * Is this change impacted/influenced by a change that happened in another branch of my software? * Did this change ever happen before? * Is this change reverting the code to an old state? (someone changes some code to actually roll back something; would like to know this since it might be by accident) * Did the person who made the change also update the tests? Was this necessary? * If I just load the change, what are the changes that it breaks my current system? * When multiple packages were committed at the same time: do I really need to load all of them now, or can I just load/merge with the version of the package I'm working on? Kind regards, Andy On 26 Nov 2011, at 08:56, Stéphane Ducasse wrote: > tx :) > > On Nov 24, 2011, at 1:38 PM, Thorsten.Seitz(a)deutschebahn.com wrote: > >> - When the version to be merged into the trunk is on a branch which I >> already did merge a couple of versions earlier I want to have to see/think >> about only those changes that are new (i.e. the changes between the version >> last merged and the current version to be merged and not all changes >> between the current version to be merged and the trunk version to be merged >> into) >> >> e.g. >> >> 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk >> \ / / ?? questions asked here >> \ / / >> -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch >> >> The branch version 2.2 has already been merged into trunk version 5.0 some >> time earlier. >> Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. >> I don't know what Pharo does but VisualWorksdisplays all changes between >> 2.4 and 7.0 while giving additional information about the last common >> version which is determined to be 2.0 because previous merges are not >> considered. >> This forces me to think about how to merge all changes up to version 2.2 >> once again. >> We fixed that in our tools, of course (in VW 7.6), offering an additional >> merge option which only merges the changes since a user selected common >> version. >> >> Regards >> Thorsten >> >> >> Thorsten Seitz >> Development Center Architekturkonzeption und -entwicklung (T.SVD 32) >> >> DB Systel GmbH >> Raum 5C.136, Alfred-Herrhausen-Allee 1, 65760 Eschborn >> Tel. 069 265-48245, intern 955- >> _________________________________________________________________________________ >> >> Der DB-Konzern im Internet >> http://www.deutschebahn.com >> >> Sitz der Gesellschaft: Frankfurt am Main >> Registergericht: Frankfurt am Main, HRB 78707 >> USt-IdNr.: DE252204770 >> Geschäftsführer: Detlef Exner (Vorsitzender), Dr. Burkhard Klanke, Dr. >> Klaus Rüffler >> Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel >> >> >> |------------> >> | Von: | >> |------------> >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |Stéphane Ducasse <stephane.ducasse(a)inria.fr> | >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |------------> >> | An: | >> |------------> >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |ESUG Members <esug-list(a)lists.esug.org> | >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |------------> >> | Datum: | >> |------------> >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |23.11.2011 16:58 | >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |------------> >> | Betreff: | >> |------------> >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |[Esug-list] Call for your input on questions you ask yourselves during merge | >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |------------> >> | Gesendet | >> | von: | >> |------------> >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> |esug-list-bounces(a)lists.esug.org | >>> --------------------------------------------------------------------------------------------------------------------------------------------------| >> >> >> >> >> >> Hi guys >> >> We are writing some articles on the work of veronica to support merging >> activities. We need your input great smalltalk community :) >> What are the questions that you ask yourselves when you are/want to merge >> some code in your project? >> We would like to do a compilation of questions and also evaluate how the >> solution of veronica solves them or part of them. >> >> Here are some typical questions we asked ourselves. >> - What other changes did this change require? >> - Can I integrate this change right now? >> - How large it is? >> - Who made it? >> - Is it still valid (when I'm working on an old change)? >> - Is this change impacted by a change that happened in another >> branch of my software? >> >> Stef D., Andy K. and Veronica U. >> >> >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >> > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 26, 2011

Re: [Esug-list] Antwort: Call for your input on questions you ask yourselves during merge

by Stéphane Ducasse

tx :) On Nov 24, 2011, at 1:38 PM, Thorsten.Seitz(a)deutschebahn.com wrote: > - When the version to be merged into the trunk is on a branch which I > already did merge a couple of versions earlier I want to have to see/think > about only those changes that are new (i.e. the changes between the version > last merged and the current version to be merged and not all changes > between the current version to be merged and the trunk version to be merged > into) > > e.g. > > 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk > \ / / ?? questions asked here > \ / / > -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch > > The branch version 2.2 has already been merged into trunk version 5.0 some > time earlier. > Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. > I don't know what Pharo does but VisualWorksdisplays all changes between > 2.4 and 7.0 while giving additional information about the last common > version which is determined to be 2.0 because previous merges are not > considered. > This forces me to think about how to merge all changes up to version 2.2 > once again. > We fixed that in our tools, of course (in VW 7.6), offering an additional > merge option which only merges the changes since a user selected common > version. > > Regards > Thorsten > > > Thorsten Seitz > Development Center Architekturkonzeption und -entwicklung (T.SVD 32) > > DB Systel GmbH > Raum 5C.136, Alfred-Herrhausen-Allee 1, 65760 Eschborn > Tel. 069 265-48245, intern 955- > _________________________________________________________________________________ > > Der DB-Konzern im Internet >> http://www.deutschebahn.com > > Sitz der Gesellschaft: Frankfurt am Main > Registergericht: Frankfurt am Main, HRB 78707 > USt-IdNr.: DE252204770 > Geschäftsführer: Detlef Exner (Vorsitzender), Dr. Burkhard Klanke, Dr. > Klaus Rüffler > Vorsitzender des Aufsichtsrates: Dr. Rolf Kranüchel > > > |------------> > | Von: | > |------------> >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |Stéphane Ducasse <stephane.ducasse(a)inria.fr> | >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | An: | > |------------> >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |ESUG Members <esug-list(a)lists.esug.org> | >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Datum: | > |------------> >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |23.11.2011 16:58 | >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Betreff: | > |------------> >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |[Esug-list] Call for your input on questions you ask yourselves during merge | >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |------------> > | Gesendet | > | von: | > |------------> >> --------------------------------------------------------------------------------------------------------------------------------------------------| > |esug-list-bounces(a)lists.esug.org | >> --------------------------------------------------------------------------------------------------------------------------------------------------| > > > > > > Hi guys > > We are writing some articles on the work of veronica to support merging > activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to merge > some code in your project? > We would like to do a compilation of questions and also evaluate how the > solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another > branch of my software? > > Stef D., Andy K. and Veronica U. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > >

Nov. 26, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Thorsten Seitz

- When the version to be merged into the trunk is on a branch which I already did merge a couple of versions earlier I want to have to see/think about only those changes that are new (i.e. the changes between the version last merged and the current version to be merged and not all changes between the current version to be merged and the trunk version to be merged into) e.g. 1.0 -> 2.0 -> 3.0 -> 4.0 -> 5.0 -> 6.0 -> 7.0 Trunk \ / / ?? questions asked here \ / / -> 2.1 -> 2.2 -> 2.3 -> 2.4 Branch The branch version 2.2 has already been merged into trunk version 5.0 some time earlier. Therefore I'd like to merge only the changes between 2.2 and 2.4 into 7.0. I don't know what Pharo does but VisualWorksdisplays all changes between 2.4 and 7.0 while giving additional information about the last common version which is determined to be 2.0 because previous merges are not considered. This forces me to think about how to merge all changes up to version 2.2 once again. We fixed that in our tools, of course (in VW 7.6), offering an additional merge option which only merges the changes since a user selected common version. Regards Thorsten Am 23.11.2011 um 16:57 schrieb Stéphane Ducasse: > Hi guys > > We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to merge some code in your project? > We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another branch of my software? > > Stef D., Andy K. and Veronica U. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 24, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Otto Behrens

Hi, > What are the questions that you ask yourselves when you are/want to merge some code in your project? 1. Are there any changes conflicting with my own? 2. If there are no direct conflicts (i.e. a merge worked), will the "baseline" changes combined with my own conflict? (i.e. are there implicit conflicts?) 3. Do all the tests pass after the merge? 4. How quickly can I get my changes published before someone else publishes and I have to merge again :-) To track / understand other people's changes, mostly for the purpose of resolving conflicts, I need information on the version that I'm merging with including all the versions in between. So, something like a summary of all the version comments (collected) and a summary of all the changes (that I can drill into if I need to). I suppose the kind of questions depend a lot on the way we work? My 2 cents Otto

Nov. 24, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Hernan Wilkinson

Hi, in a previous company I worked we had something very similar to what Carlos described. We used SmallLint to verify that no errors where in the code (we extended SmallLint to be able to document false positives), we had what we called programming rules that were run as SUnit tests before integration and after integration, and we also had something we called architecture tests. The programming rules included simple rules like checking the numbers of parameters, doing spell checking, that the initialize message is not send for other object but the class, etc. up to complex validations for patterns like the visitor, state, etc. The architecture rules were oriented towards dependencies between modules (applications in Envy), dependencies between systems, etc. We had a process that defined when to run each type of test (tests were categorized like functional, programming rules, architecture rules, etc using different suites). For example if you changed something, first you had to run the tests related to the changed module, then the functional tests of all the system (around 23.000 test, ran in 7 minutes) then the programming rules. After that the change was sent to the integrator who used an automatic integration tool and also the architecture tests where runned. Before closing the new release the version was uploaded to a fresh GemStone image, and all the functional tests where ran in GemStone. If everything ran correctly, the new version was released. The last steps (uploading code to gemstone, running the tests, etc) are currently done automatically in a build server using Jenkins. This process allowed us to be very confident in the code we produced. Of course that it took some time to do the whole integration cycle, that is why sometimes when the release was an internal one, we could avoid running the tests in gemstone, etc. Anyway, it feels really good to have a process like that and it is still in use. The programmers add new rules when they find mistakes they do, sometimes to prevent errors in the evolution of the code (that is very nice too... design decisions are made explicit through these tests), etc. So, at the same time is a very "reflective" process... Bye, Hernan. On Thu, Nov 24, 2011 at 5:49 AM, Joseph Pelrine <jplists(a)metaprog.com>wrote: > > > On 23.11.11 22:30, stephane ducasse wrote: > >> >>>> At my job we have several programming rules hat we check on pieces of >>> code before integrating. >>> Some of these checks could be automated, >>> >> >> like what? >> >> I integrated daily changes and I have a lot of simple questions. I'm >> quite sure that people would be interested by the answers >> to these questions. But for the moment I will not tell them but I want to >> know what you guys are asking yourselves. >> > > I've always considered it important to have a set of code quality tests > which would run before code was checked in and accepted into a common > baseline. Tests that were more than SUnit or functional acceptance tests, > but which then took a bit longer to run. I'd like to have these tests > automated and run when merging. SmallLint provides a number of these, and > there are surely some other quality and metric tools around. > > This may go a bit far, but since merging is part of a build process, I'd > also like to see whatever you do fit into a CRISP build: > > *Complete, i.e. scorched-earth build > *Repeatable, i.e. consistent and reproducable > *Informative > *Schedulable > *Portable > > FWIW > -- > Joseph Pelrine [ | ] > MetaProg GmbH > Email: jpelrine(a)metaprog.com > Web: http://www.metaprog.com > > As soon as you introduce people, things become complex. > > > ______________________________**_________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/**listinfo/esug-list_lists.esug.**org<http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org> > -- *Hernán Wilkinson Agile Software Development, Teaching & Coaching Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

Nov. 24, 2011

18 months Postdoc position in Reengineering available

by Stéphane Ducasse

> From: Stéphane Ducasse <stephane.ducasse(a)inria.fr> > Subject: 18 months Postdoc position in Reengineering available > Date: November 23, 2011 9:52:01 AM GMT+01:00 > To: ERCIM WG Software Evolution ERCIM WG Software Evolution Mailing List <evol(a)lists.inf.unisi.ch> > > http://rmod.lille.inria.fr/web/pier/blog/2011-05-22 > > Postdoc position in software engineering at University of Chile in cooperation with INRIA > > A post-doctoral research position is available with the Pleiad Lab (Universityof Chile) and the RMoD Group (INRIA Lille Nord Europe). The position is scheduled to start in January 2012, but earlier dates are possible. The phd should be defended no prior than 2010. > > The position is targeted for research on software maintenance and software visualization. Validation of research hypotheses will be carried out using the Pharo programming language. Experience with it, or any other Smalltalk dialect, is a plus (but not necessary). > > The postdoctoral researcher will be expected to develop independent research initiatives within the scope of the position, design and contribute to the research experiments conducted by Pleiad and RMoD. There is no teaching duty associated with this position. > > Both Pleiad and RMoD offer a creative, productive and multicultural staff and students, with many collaboration opportunities. Pleiad and RMoD have an extensive expertise and an advanced infrastructure related to software analysis, data mining, testing, meta-modeling and language semantics. > > The position is funded by INRIA for a period of 18 months. In order to foster the collaboration between France and Chili, the candidate will have to share his time between Lille, France and Santiago, Chile. > > The candidate must hold a PhD in computer science. > > Contact Persons: > > • Alexandre Bergel and Stéphane Ducasse > • http://pleiad.dcc.uchile.cl > • http://rmod.lille.inria.fr > • http://www.pharo-project.org > • http://www.moosetechnology.org

Nov. 24, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Joseph Pelrine

On 23.11.11 22:30, stephane ducasse wrote: >>> >> At my job we have several programming rules hat we check on pieces of code before integrating. >> Some of these checks could be automated, > > like what? > > I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers > to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves. I've always considered it important to have a set of code quality tests which would run before code was checked in and accepted into a common baseline. Tests that were more than SUnit or functional acceptance tests, but which then took a bit longer to run. I'd like to have these tests automated and run when merging. SmallLint provides a number of these, and there are surely some other quality and metric tools around. This may go a bit far, but since merging is part of a build process, I'd also like to see whatever you do fit into a CRISP build: *Complete, i.e. scorched-earth build *Repeatable, i.e. consistent and reproducable *Informative *Schedulable *Portable FWIW -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine(a)metaprog.com Web: http://www.metaprog.com As soon as you introduce people, things become complex.

Nov. 24, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Leandro Caniglia

If the tool only compares the new proposed version of a method with the current one, then you might miss something because sometimes the new version should be compared against a method with another selector. This is clearly the case when the change renames a selector. It also happens when the change extracts some lines from the body of a larger method. So, to put this in a question (as Stef is requesting) I would add the following: What's the method (or method fragment) that this new method modifies? leandro caniglia ph.d. | chief technologist | *caesar** systems *| *see clearly. decide smarter**.* lcaniglia(a)caesarsystems.com | t: +1.281.598.8810 +1.281.617.2972 +54.11.4389.0126 | petrovr.blogspot.com | www.caesarsystems.com This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. On Wed, Nov 23, 2011 at 7:24 PM, <mkobetic(a)cincom.com> wrote: > "Alan Knight"<knight(a)acm.org> wrote: > > Which parts of this are real changes and which are just because somebody > > felt it was important to reformat everything? :-) > > Reformatting is relatively easy, but it would be really nice if the > tooling could identify (at least some) refactoring too. Best I've seen so > far is barely identifying simple method renames, I'm fairly confident we > could do better than that. > > On top of that most tools make it difficult to compare bits of code that > don't reside in the exact same method. The fact of life is that code moves > around as responsibilities get reallocated. A good merge tool should let me > compare arbitrary bits of changes with ease. As it is the "art of merging" > is primarily being able to pick out slightest differences by simply > eyeballing chunks of code yourself. It seems that merge tools assume that > the person merging is the one who wrote the change, that is often not the > case. It's great that the obvious stuff can be merged automatically > nowadays, but any non-trivial merge case requires actual understanding of > the change. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Carlos E. Ferro

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by mkobetic＠cincom.com

"Alan Knight"<knight(a)acm.org> wrote: > Which parts of this are real changes and which are just because somebody > felt it was important to reformat everything? :-) Reformatting is relatively easy, but it would be really nice if the tooling could identify (at least some) refactoring too. Best I've seen so far is barely identifying simple method renames, I'm fairly confident we could do better than that. On top of that most tools make it difficult to compare bits of code that don't reside in the exact same method. The fact of life is that code moves around as responsibilities get reallocated. A good merge tool should let me compare arbitrary bits of changes with ease. As it is the "art of merging" is primarily being able to pick out slightest differences by simply eyeballing chunks of code yourself. It seems that merge tools assume that the person merging is the one who wrote the change, that is often not the case. It's great that the obvious stuff can be merged automatically nowadays, but any non-trivial merge case requires actual understanding of the change.

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by stephane ducasse

Thanks alan! We want more. Please log them next time you integrate something. I really a bunch of them. But I want to hear you guys! Stef > On 23/11/2011 12:57, Stéphane Ducasse wrote: >> Hi guys >> >> We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) >> What are the questions that you ask yourselves when you are/want to merge some code in your project? >> We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. >> > At my job we have several programming rules hat we check on pieces of code before integrating. > Some of these checks could be automated, some cannot. > > Besides, there is a more subtle analysis about two things: the alignment of the changes with the software design and politics; and a little cost-benefit considering added complexity as a cost (could yield negative when it is a refactoring, for instance) and additional functionality or enhancements or clarity or performance as benefits. > I don't think this could be automated, but it could be supported to some extent (we could measure the added complexity and raise hints about some design invariants). > > I think this goes to the line that Sean T Allen pointed: why do we want to integrate these changes. > > Regards > -- > carlos e. ferro | senior developer| caesar systems | see clearly. decide smarter. > > ceferro(a)caesarsystems.com | t: +1.281.598.8790 | t: +54.11.4389.0126 | blog.caesarsystems.com | www.caesarsystems.com > > This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Alan Knight

What does this relate to in the bug-tracking system? Did the tests pass before? Do the tests pass now? Which parts of this are real changes and which are just because somebody felt it was important to reformat everything? :-) What were those changes I just accepted/deleted because the cat was stepping on my keyboard? > ------------------------------------------------------------------------ > > Stéphane Ducasse <mailto:stephane.ducasse@inria.fr> > 23 November, 2011 10:57 AM > > > Hi guys > > We are writing some articles on the work of veronica to support > merging activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to > merge some code in your project? > We would like to do a compilation of questions and also evaluate how > the solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another branch > of my software? > > Stef D., Andy K. and Veronica U. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by stephane ducasse

>> > At my job we have several programming rules hat we check on pieces of code before integrating. > Some of these checks could be automated, like what? I integrated daily changes and I have a lot of simple questions. I'm quite sure that people would be interested by the answers to these questions. But for the moment I will not tell them but I want to know what you guys are asking yourselves. > some cannot. > > Besides, there is a more subtle analysis about two things: the alignment of the changes with the software design and politics; and a little cost-benefit considering added complexity as a cost (could yield negative when it is a refactoring, for instance) and additional functionality or enhancements or clarity or performance as benefits. > I don't think this could be automated, but it could be supported to some extent (we could measure the added complexity and raise hints about some design invariants). > > I think this goes to the line that Sean T Allen pointed: why do we want to integrate these changes. > > Regards > -- > carlos e. ferro | senior developer| caesar systems | see clearly. decide smarter. > > ceferro(a)caesarsystems.com | t: +1.281.598.8790 | t: +54.11.4389.0126 | blog.caesarsystems.com | www.caesarsystems.com > > This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Leandro Caniglia

I find the question *How Large is it* interesting because it can be easily enhanced to complexity metrics. Two simple ones are #loc and #sends (you don't need to compile a method to count the number of message sends it contains). If the change represents a Class definition you could measure the number of instance variables. Changes that remove classes or methods would subtract their complexity from the total. There are more metrics easy to calculate. The point is that with these considerations you could ask how much complexity the change set adds to/removes from the system. leandro caniglia ph.d. | chief technologist | *caesar** systems *| *see clearly. decide smarter**.* lcaniglia(a)caesarsystems.com | t: +1.281.598.8810 +1.281.617.2972 +54.11.4389.0126 | petrovr.blogspot.com | www.caesarsystems.com This message and any attached documents contain information from Caesar Systems LLC that may be confidential/trade secret and/or privileged. If you are not the intended recipient, you may not read, copy, distribute or use this information. If you have received this transmission in error, please notify the sender immediately by telephone or by reply e-mail and then delete this message. On Wed, Nov 23, 2011 at 12:57 PM, Stéphane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Hi guys > > We are writing some articles on the work of veronica to support merging > activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to merge > some code in your project? > We would like to do a compilation of questions and also evaluate how the > solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another > branch of my software? > > Stef D., Andy K. and Veronica U. > > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Carlos E. Ferro

Nov. 23, 2011

Re: [Esug-list] Call for your input on questions you ask yourselves during merge

by Sean T Allen

On Wednesday, November 23, 2011 at 10:57 AM, Stéphane Ducasse wrote: > Hi guys > > We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) > What are the questions that you ask yourselves when you are/want to merge some code in your project? > We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. > > Here are some typical questions we asked ourselves. > - What other changes did this change require? > - Can I integrate this change right now? > - How large it is? > - Who made it? > - Is it still valid (when I'm working on an old change)? > - Is this change impacted by a change that happened in another branch of my software? > > Number 1 question I always ask but is sort of implicit in the other questions is, why was this change made? which impacts on, is it still valid and is this change impacted by a change that happened in another brach of software.

Nov. 23, 2011

Call for your input on questions you ask yourselves during merge

by Stéphane Ducasse

Hi guys We are writing some articles on the work of veronica to support merging activities. We need your input great smalltalk community :) What are the questions that you ask yourselves when you are/want to merge some code in your project? We would like to do a compilation of questions and also evaluate how the solution of veronica solves them or part of them. Here are some typical questions we asked ourselves. - What other changes did this change require? - Can I integrate this change right now? - How large it is? - Who made it? - Is it still valid (when I'm working on an old change)? - Is this change impacted by a change that happened in another branch of my software? Stef D., Andy K. and Veronica U.

Nov. 23, 2011

Smalltalk job offer in Belgium

by Johan Brichau

Dear Smalltalker, It appears that the ESUG mailinglist has removed the pdf attachment in my previous email. Therefore, I am resending this message. My apologies. We have an exciting open position, detailed in the following pdf: http://www.yesplan.be/docs/vacancy-software-engineer.pdf Please do not hesitate to send in your resume! However, mind that applicants will be required to work on-site in Gent (Belgium). Best regards! -- Johan Brichau Software architect Yesplan -- Event Planning Software johan(a)yesplan.be

Nov. 22, 2011

Smalltalk job offer in Belgium

by Johan Brichau

Dear Smalltalker, We have an exciting open position, detailed in the attached pdf. Please do not hesitate to send in your resume. However, mind that applicants will be required to work on-site in Gent (Belgium). Best regards! -- Johan Brichau Software architect Yesplan -- Event Planning Software johan(a)yesplan.be

Nov. 22, 2011

STIC 2012 Student Volunteer Program

by Georg Heeg

Dear ESUG members, A few weeks ago STIC has invited STIC 2012 with a general call for participation. Yesterday we have announced our Student Volunteer Program in <http://www.stic.st/2011/11/student-volunteers-program/> http://www.stic.st/2011/11/student-volunteers-program/. We plan to send out a formal call for papers for our STIC Academic Workshop "Smalltalk Directions" the near future. This workshop will have a formal review process by a Program Committee from all over the world. Our Academic Advisory Council is confident that we will have a publication of the papers accepted in a medium which is recognized worldwide. Georg Heeg STIC - Smalltalk Industry Council Executive Director Phone +49-3496-214328, Fax +49-3496-214712

Nov. 10, 2011

Smalltalker looking for a job

by Stéphane Ducasse

Hi guys Hani Abdeen was in our group and he is now looking for a job Stef ====================================================== Hani Abdeen Dec. 1980 - Nat.: Syrian Tel: +49 176 312 090 76 Email: hani.abdeen(a)gmail.com Current address: Breaisacherstr. 23 - 79106 Freiburg - Germany Highlights ======== >> PhD in Software Engineering (RMod, INRIA Lille-Nord Europe): OO Software analysis and maintenance; Software visualization; Software metrics; Software modularization; Meta-Modeling; Moose. >> Experienced Smalltalker and OO Software maintainer: during my PhD, I participated in the maintenance and development of the Moose platform for Software and Data analysis. >> Excellent knowledge about: Software Development Process and Methodologies; Software Design and Software architecture; OO requirements specification and design. >> Programming: Smalltalk, Java, JSP, C#.NET, ASP.NET, HTML, XML, CSS, SQL, UML. >> IDE: VisualAge, Visual Works Cincom, Squeak, Netbeans, Microsoft Visual Studio, Php Mysql, SQL-Server, Dreamweaver, Magic Draw. >> Languages: English (excellent), French (fluent), Arabic (mother tongue), German (basic-knowledge). >> Availability: from 01 December 2011. >> Ideal position: Smalltalker, OO Software developer and designer. >> Publications in conferences and journals: ICSM’07, CSMR’08, WCRE’09, WCRE’2011, Information and Software Technology (IST) journal -2010. ====================================================== I am ========= I am excellent at programming in OO languages, particularly in Smalltalk language, and keep updating my knowledge with the latest Software development technologies. I am habitual of working independently, and set goals for myself if not assigned any by the organization. I set benchmarks for myself and achieve my goals in the decided time. I am completely dedicated to my job. I am energetic, a fast learner, and motivated with excellent communication skills. ====================================================== Experiences ========= >> 2006-2009 (INRIA Lille Nord-Europ, RMod): Smalltalker; OO Software Developer and Maintainer. I started my experience during my PhD studies at INRIA RMod team as a Smalltalker and a Software maintainer. During this experience, I have participated in the maintenance and development of the Moose platform for Software Re-Engineering, and the meta-modeling language FAMIX. I have developed new tools that help in understanding and in re-modularizing OO software systems. All my tools are developed over Moose in Smalltalk (Visual Works Cincom platform). I have developed two visualization tools that help in understanding large and complex OO software modularizations (the organization of classes and packages). I have developed an optimization tool that automatically re-modularizes OO Software applications (optimizes the existing modularization). The optimization process is based on the meta-heuristic technique Simulated Annealing, and it uses a set of Coupling & Cohesion metrics that I developed. With RMod team, we have used my tools for analyzing and understanding large OO open-source systems, such as Squeak. >> 2010- 15 Sep. 2011 (International University for Science and Technology, Damascus): Lecture in Software Engineering. In addition to my experience as adjunct-faculty instructor at several French academic institutes, I also worked as a full-time lecture in the Software engineering domain at IUST, Damascus. My experience as a teacher of university in the domain of Software Engineering provided me the following opportunities: -learning more and teaching different programming languages and platforms (such as C#.Net, ASP.Net, Java); -supervising Software development projects of junior and undergraduate developers; -teaching junior developers how to analyze system requirements and design them in order to build concrete Software solutions. The most important topics that I practiced, understood, and taught during this experience are: - Software Development Process and Methodologies; - Software Design and Software architecture; - OO requirements specification and design, and the UML formalism. - OO programming and testing. - Software maintenance; Reuse and reengineering. - Information Requirements Analysis: Sampling and investigating hard data; Interviewing; Using questionnaires; Observing decision-maker Behavior and the office environment; Prototyping and Rapid Application Development. - The Analysis process: Using Data Flow Diagrams; Analyzing systems using data dictionaries; Describing process specifications and structured decisions; Preparing the systems proposal. - User Interfaces Design; Components-Events Oriented Programming; C#.Net. - Web Technologies and Web Applications; HTML; CSS; XML; Javascript; APS.Net. - Relational Databases, SQL, php Mysql. ======================================================

Nov. 6, 2011