- Esug-list - lists.esug.org

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