headers
Matteo Canessa | 1 Apr 2003 08:44
Picon
Favicon

(unknown)

4th International Conference on eXtreme Programming and Agile Processes 
in Software Engineering - XP2003 

Week of May 26, 2003, Genova, Italy 

www.xp2003.org 

Call for Submission of Practitioner's Reports 

DATES - Deadline for submission postponed
**April 10, 2003 for Practitioner's Reports submission.** 
April, 15, 2003 for acceptance notification. 
May 1, 2003 for final manuscript submission.

GOAL AND SCOPE 
Practitioners' Reports provide a lightweight format for presenting minor

results or late-breaking work that is not developed enough for a full 
paper. For example, this might include an account of a project with a 
discussion of the significant lessons to be drawn from the experience. 

PhD candidates are particularly encouraged to submit reports describing 
their ongoing work, in addition to attending the PhD symposium. 

Submissions are sought in all relevant areas of XP and Lightweight 
Methodologies. 

Accepted Practitioners' Reports will be presented as posters during 
interactive sessions.
(Continue reading)

Permalink | Reply | 0 comments |
headers
June Clarke | 2 Apr 2003 02:44
Picon
Favicon

ANN: XPSD April 3rd meeting - reminder

This is a reminder that the XPSD meeting is this
Thursday from 6 - 8PM. 

This week, Peter Merel will be conducting an "Extreme
Hour". 

An Extreme Hour is an hour-long presentation in which
ExtremeProgramming is demonstrated using a sample
project and involving the audience. Basically, the
audience gets one hour to completely develop (and
test!) a product using XP principles such as Pair
Programming, Refactoring, and Iteration Planning. The
presentation creates a clear picture of how XP works
as a whole. It serves as a great introduction to XP,
and a means for experienced XP practitioners to spike
innovations and variations in their process.

About Peter Merel:
Peter has served as lead, director, and architect for
software projects at HP, GMAC, Fujitsu, Foxboro,
Telstra, and AC Nielsen. He was principal architect of
Foxboro's "I/A Series Intelligent SCADA" product, now
the world's leading shrink-wrapped SCADA toolset. Over
the last 5 years Peter has coached XP development
teams at GMAC, Websense, and Omnigon. In 2001 his
XP2000 paper "The Tao Of XP" was published as part of
Addison Wesley's "XP Examined". He's now CTO of the
Caldev consultancy (http://www.caldev.com), consulting
on project and product management methods including
XP, CMMI, and OBM.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kathy Van Stone | 2 Apr 2003 06:29
Picon
Favicon
Gravatar

Re: Rice's Theorem

At 11:03 AM 3/30/2003 +0000, you wrote:
>Gang,
>
>Since being unable to sleep since about 4am, I have been making my
>best attempt to understand the proof of he theorem from the wiki link:
><http://www.wikipedia.org/wiki/Rices+theorem>http://www.wikipedia.org/wiki/Rices+theorem
>(found by google.)
>
>I think I answered my initial questions on the proof:
>1.) What is a "non-trivial" property?  The nature of halt (versus no-
>halt) is an example of a property of algorithms that another
>algorithm is meant to detect.

Non-trivial simply means that there is an algorithm x such that P(x) is 
"yes" and another algorithm y such that P(y) is "no" (i.e, P does not 
always return true or always return false. Such properties are clearly 
decidable).

>2.) What does the use of "decides" mean in the first paragraph?  I
>later replaced this with "determines" or "detects" and everything
>made more sense.

Decidable is a technical term in computability that means there is a 
computer program that emulates the property.  Another word for it is 
"computable" (a mathematical term is "recursive").

>3.) It seems that the symbol 'a' is reused in places with sometimes
>different meanings; this took me a little bit to get past.  The first
>use is in the second paragraph, and it means an algorithm that
>doesn't halt; it is used again in H(a,i) where I think it has a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Breton | 2 Apr 2003 14:44
Picon
Favicon

RE: Auto importing


> (which we e.g. had to do when java.util.Currency 
> conflicted with our own
> Currency class, used almost everywhere)

I find this darkly amusing; packages are supposed to
shield you from namespace conflicts, so you *can* have
both java.util.Date and java.sql.Date, and
java.util.Currency and your own currency class... but
in practice it's easiest to use a unique name (eg the
MfDate class in the Refactoring book).

Carrying this to its logical extreme (no, I am not
seriously suggesting this ;), you should prefix every
class you write, and then you'll never conflict with
anything! (BTW, this is exactly what the Lisp packages
in Emacs do).

One other, mostly unrelated thing that I find amusing:
on my current project we have long declarations of
constants. Does anyone else feel foolish writing
things like:

public static final String BACK = "Back";
public static final String FORWARD = "Forward";

over and over and over?

In my own code I tend to use either named methods, or,
if the String's value is needed, then the String
(Continue reading)

Permalink | Reply | 535 comments |
headers
Ilja Preuss | 2 Apr 2003 14:56
Favicon

RE: RE: Auto importing

> if
> (request.getParameter("task").equals(IApplicationConstants.BACK))
> 
> instead of:
> 
> String task = request.getParameter("task");
> if ("BACK".equals(task))
> 
> What to do til Enums (in Java 1.5) arrive?

Why don't you declare the constant in the class it is used in?

Curious, Ilja

------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get 128 Bit SSL Encryption!
http://us.click.yahoo.com/W7NydA/hdqFAA/VygGAA/umvwlB/TM
---------------------------------------------------------------------~->

To unsubscribe from this group, send an email to:
refactoring-unsubscribe <at> yahoogroups.com

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
Permalink | Reply | 0 comments |
headers
DeWitt Clinton | 2 Apr 2003 15:14
Gravatar

Re: RE: Auto importing

On Wed, Apr 02, 2003 at 04:44:34AM -0800, Peter Breton wrote:

> What to do til Enums (in Java 1.5) arrive?

Use the strongly typed "Replace Enum Constructs with Classes" pattern
Joshua Bloch recommends in _Effective Java_.  Not a formal
refactoring, but very relevant.

Fortunately, that chapter is available online for free:

  http://developer.java.sun.com/developer/Books/effectivejava/Chapter5.pdf

The link to the page for the book itself is here:

  http://java.sun.com/docs/books/effective/

To use his example verbatim, you could write:

  public class Suit {
      private final String name;

      private Suit(String name) { this.name = name; }
      public String toString( ) { return name; }

      public static final Suit CLUBS = new Suit( "clubs" );  
      public static final Suit DIAMONDS = new Suit( "diamonds" );  
      public static final Suit HEARTS = new Suit( "hearts" );  
      public static final Suit SPADES = new Suit( "spades" );  
  }
(Continue reading)

Permalink | Reply | 536 comments |
headers
Andrew McDonagh | 2 Apr 2003 15:19
Favicon

RE: RE: Auto importing


> -----Original Message-----
> From: DeWitt Clinton [mailto:dewitt <at> unto.net]
> Sent: 02 April 2003 14:15
> To: refactoring <at> yahoogroups.com
> Subject: Re: [refactoring] RE: Auto importing
>
>
> On Wed, Apr 02, 2003 at 04:44:34AM -0800, Peter Breton wrote:
>
> > What to do til Enums (in Java 1.5) arrive?
>
> Use the strongly typed "Replace Enum Constructs with Classes" pattern
> Joshua Bloch recommends in _Effective Java_.  Not a formal
> refactoring, but very relevant.

[Snipped excellent advice on using the cracking pattern]

> Bloch goes on to discuss how to write these classes properly for
> extension and serialization as well.  I use this pattern so often I
> have a tool that automatically generates the source code.

I've been toying with the idea of knocking up just such a tool - any chance
of yours becoming open source?

>
> A very highly recommended book.  Almost essential reading, really.
>
> Cheers,
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
DeWitt Clinton | 2 Apr 2003 15:53
Gravatar

Re: RE: Auto importing

On Wed, Apr 02, 2003 at 02:19:12PM +0100, Andrew McDonagh wrote:

> I've been toying with the idea of knocking up just such a tool - any
> chance of yours becoming open source?

I'd like that.  This type of tool lends itself to being open sourced.
I simply need to convince the business that it has more value when
opened to the community.  It is part of a much larger suite of source
generation tools developed for my company.  Everything is XML driven
and invoked via Ant during the compilation phase.

Attached are some examples of what it can do.  StatusCode.xml provides
input to generate a marker interface in StatusCode.java that will be
implemented by concrete enumerated type classes.  CommonStatusCode.xml
is an example of one of the concrete enumerated type classes.  The
third example CacheObject.xml is an example of a concrete datatype
class.  I.e., the XML is the input, the Java is what this tool
outputs.

During the compilation phase, and Ant task tracks down the XML files
and automatically generates the source code, resolving dependencies
where necessary.  This tool has worked out incredibly well for us, and
we've already built a half million line application around it.

I'm posting this here because a positive response (and volunteers to
help) from this list would be great ammunition to bring to the
business explaining that we would get a return on the investment in
opening up this part of our code.

Cheers,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael J. Lee | 2 Apr 2003 16:57
Picon
Favicon

Re: RE: Auto importing

Have you looked into XDoclet?

< http://xdoclet.sourceforge.net/ >

They call it 'Attribute Oriented Programming'.  It is primary used for EJB but I stumbled
onto it while experimenting with 'Hibernate'.

We may able to leverage it - it looks mature.

One main problem I see with the document/configration based programming is where to store
the complex logic/algorithm.  Where do we describe it - in the document or generated stub
sourcecode.  Plus, the documentat syntax starts to become like another language I have to
learn.  [ I'm still struggling with XML configuration for web deployment, struts,
hibernate ]

mj lee

--- DeWitt Clinton <dewitt <at> unto.net> wrote:
> On Wed, Apr 02, 2003 at 02:19:12PM +0100, Andrew McDonagh wrote:
> 
> > I've been toying with the idea of knocking up just such a tool - any
> > chance of yours becoming open source?
> 
> I'd like that.  This type of tool lends itself to being open sourced.
> I simply need to convince the business that it has more value when
> opened to the community.  It is part of a much larger suite of source
> generation tools developed for my company.  Everything is XML driven
> and invoked via Ant during the compilation phase.
> 
> Attached are some examples of what it can do.  StatusCode.xml provides
(Continue reading)

Permalink | Reply | 0 comments |
headers
harald.m.mueller | 2 Apr 2003 17:13
Picon

Re: RE: Auto importing

> On Wed, Apr 02, 2003 at 04:44:34AM -0800, Peter Breton wrote:
> 
> > What to do til Enums (in Java 1.5) arrive?
> 
> Use the strongly typed "Replace Enum Constructs with Classes" pattern
> Joshua Bloch recommends in _Effective Java_.  Not a formal
> refactoring, but very relevant.

However, you are strongly encouraged to read Javaworld Tip 122, called 

"Java Tip 122: Beware of Java typesafe enumerations" 

at http://www.javaworld.com/javaworld/javatips/jw-javatip122.html before
believing that this is a use-always-no-problem pattern. Here is the conclusion
arrived at in that article:

"The typesafe enum pattern may require too much work to be truly safe in all
situations, especially if your runtime involves serialization or a complex
classloader structure -- typical elements of Java 2 Platform, Enterprise
Edition (J2EE) applications. In certain cases, it won't work at all. As such, the
pattern is an unreliable substitute for a basic feature that the Java
language lacks: a compiler-supported enum feature. In many cases, you're better off
using the good old set-of-static-primitive-values enumeration."

Regards

Harald M. Mueller
Germany

--

--
(Continue reading)

Permalink | Reply | 7 comments |

Gmane