Experience Guides

The theory is that an experience that leads to an "ah-ha" moment is an experience that is worth duplicating. As such, we have asked experienced Eclipse developers to remember the ah-ha moments that lead to their mastery of Eclipse.

Ottawa Committer Meeting

Ah ha!s from the Ottawa Committer Meeting Ah ha: discovery of the power of something not simply the discovery of the thing.

XXX (multiple X means multiple similar responses) Extension-point concept and plug-in concept. After the fact extension by other people. Into another domain. (Mash-ups).

Extensions interact with each other as instances of Java objects.

Plug-ins versus features. Features are the real thing. Feature.xml versus plugin.xml versus site.xml

Componentization. Formal componentization leads to � better coding � somehow. Similar to telephone switching hardware?/software? Also valid in Eclipse components.

XXXX There's not just one boundary of extensibility: plug-ins that extend APIs can themselves have extension points. Self describing models ~ meta-modeling ~ I build a platform for my customers to build a platform for their customers to build a platform, etc.

IResources - just handles to the underlying operating system resource (that's why the exists() method).

API First ~ API Boundaries First.

Bug Writing. Test first as part of bug reports.

Keeping the two IDE instances separated; where is the code running.

XX Plug-in class loaders. Platform plug-in URIs. Control over dependencies (using dependencies and access constraints/rules in plug-ins).

XXXXX Source coding efficiency. Source clean-up menu items and key bindings - c-s-O and c-s-F, etc. Source code consistency to allow useful diffs between authors. Easier to read code across the team. Syntactic but also a level above that - naming? How long a method should be? Things that are about code but not about the domain. Templates and ctrl-space for, etc. (Combining speed of typing with team collaborative reading and writing. Perhaps break into two items.) Quick fix.

Refactoring. Using the tools. Using refactoring tools to do design (extracting a method and noticing "that's not the right arguments")

XXX Debugging; symbolic debugging; debugging skills in general; scientific principle; debugging binary code with associated source code; �; add a little code so that the computer tells you what it is doing. Hot swap.

CVS integration - location doesn't matter.

Patch (might be part of CVS) generation and application.

UML visualization for dependency and API analysis. (?)

Command == function pointer.

IAdaptable.

?RetargettableAction.

Learning to compose from the plug-ins that are available; the familiar plug-ins. There are 100s, the IDE is one subset; "RCP" is the practice of selecting plug-ins; the optimal of plug-ins for a given application. May be more or fewer than the "IDE" set. Art of designing plug-ins that are easily selectable/composable/used in a collection with other plug-ins.

XX Understanding downloading versus zip installs versus update sites. "Update manager support in non-self hosting."? Installs in non-standard locations. (plug-ins installed by references instead of being copied into the plugins/ directory)

Anonymous classes by reading the JDT code.

Learning non-?GridData SWT layouts by reading SWT code.

Jobs as an abstraction of Threads.

Open source thinking. Open, transparent, permeable.

Build path versus runtime path - the difference between compile time and run time.

Find references versus Call hierarchy. (Bjorn disagrees.)

Delayed loading for scalability in Eclipse.

UI Model (standard event-window based UI technology; don't do window things except on the UI thread; etc)