We describe the origin of wiki technology, which has become widely influential, and its relationship to the development of pattern languages in software. We show how the relationship is deeper than previously understood. The deep shared logic points to unrealized potential, with expanded capability for wikis -- including a new generation of "federated" wiki. We draw conclusions about the use of this and related technology to "curate" (collectively gather and refine) knowledge systems.

Wikis are a collaborative technology that allows for new ways of working and sharing knowledge. While most firms today have been experimenting with wikis, an important element of the use of wikis that has generally been ignored is the role of the people who shape the wiki pages. Shapers ensure the sustainability of a wiki community by helping to ensure that new ideas and contributions are made and organized. This panel consists of four practitioners who play critical shaping roles in their wiki communities, and two academics who will begin, moderate, and summarize the session. The panel of practitioners will share their thoughts on why they shape, how they shape, and how other communities can help to encourage participants to adopt the shaping role.

Corporations have finally realized the value of collaboration tools for knowledge sharing and Wiki is the open source technology for creating collaborative Web sites, as either a public site on the Internet or on a private intranet site Shows readers how to set up Wikis in a corporate setting or on a personal site so that users can retrieve information, post information, and edit the content Covers everything from choosing a Wiki engine to administration and maintenance Discusses the advantages of using Wiki in a corporate environment, which companies such as Microsoft, Boeing, Disney, and Motorola have already discovered

Every half-decade or so, the computing world is infected by a meme that energizes IT and stimulates architectural thinking but also distorts discussion and clouds judgment. A few generations ago it was objects; now it's services. As every developer has noticed, SOA is everywhere--even, perhaps, in some places it shouldn't be. What has this focus on services done to the role of objects? Some of the more extreme SOA proponents maintain that service-reuse replaces object-reuse across the board. More mainstream architects view these two models as complementary reuse strategies at different levels of scale. There are even object diehards who think that services can't come close to the flexibility and durability of objects. This panel will represent the full range of opinions. Specifically, panelists and attendees will be challenged to explore such topics as: Where is the scalability boundary between object responsibilities and service responsibilities? Do we have to conceptualize, design, or implement differently at different levels of scale? Where and how do binary components such as RMI, EJB, or CORBA fit in alongside more loosely-coupled interfaces such as web services? Panelists will also be invited to comment on whether some of the new concepts defined into SOA--orchestration and discovery, for example--can be profitably fed back into the object world.

We describe "Swim", an agile functional testing system inspired by FIT, the Framework for Integrated Test, and exceeding FIT's capabilities through the inclusion of an end-user-accessible results-rendering engine. Its output allows developers, testers and end-users to explore business logic and consequent output from multiple points of view and over extended periods of time. We've incorporated this engine in the Eclipse Foundation portal to support situated reasoning about foundation processes and their automation. The “Swim” System for User-Oriented Presentation of Test-Case Results Ward Cunningham, AboutUs Bjorn Freeman-Benson, Eclipse Foundation Karl Matthias, Eclipse Foundation

This talk discusses the fundamental principles on which the first wiki was built, what we learnt from it, and how we believe future wikis are best set up.

Storytests in storytest driven development serve two interrelated goals. On the one hand, they are used to formulate and communicate business rules. On the other, they are used to verify that a story has been completed and that it hasn’t been subsequently broken. There is a small conflict between these views. For their communicative role, storytests are better to be concise and independent. For automated testing, speed is important in providing fast feedback, and so it makes sense to combine storytests. We show how this conflict can be avoided by automatically combining storytests. Hence the value of storytests for defining the needs of the system is not diminished when it comes to automated testing.

"Self-directed team" is one of the mantras of Agile Methodologies. Self-direction means that the team's manager is relegated to a facilitator role with little or no influence over day-to-day activities. For example, Kent Beck has written that the manager of an XP project can do four things: ask for estimates on cost and results, move people around among projects, ask for status reports, and cancel the project. Agile literature in general says that managers shouldn't be directly involved in analysis, design, coding, testing or integration. They may (but only occasionally!) facilitate the process between the customer and the developers - and it would be nice if they provided food and toys to keep the team happy. It appears, then, that the agile manger is expected to hover on the fringes of a project asking a few questions and throwing in goodies - but with ultimate power (cancellation) in her hip pocket.This scenario makes one wonder. Do managers really matter to the success of an agile project? Are they superfluous? What happens when managers step over the prescribed line - does it mean that the end of Agile Methodology as we know it and as handed down by the Agile Manifesto? The panel will explore this ticklish terrain by answering the following questions.

The two previous XP/Agile Universe conferences have included an XPFest, where XP practitioners and people new to XP could experience using all the practices. This tradition is continued. This year’s XPFest is similar to the ones in previous years. We will still use and explore all the practices. But our primary goal this year is to focus more on customer testing. Customer testing is a challenge for most teams, partially due to lack of understanding, partially due to lack of tools. We hope to help participants with both.

ABSTRACT"Self-directed team" is one of the mantras of Agile Methodologies. Self-direction means that the team's manager is relegated to a facilitator role with little or no influence over day-to-day activities. For example, Kent Beck has written that the manager of an XP project can do four things: ask for estimates on cost and results, move people around among projects, ask for status reports, and cancel the project. Agile literature in general says that managers shouldn't be directly involved in analysis, design, coding, testing or integration. They may (but only occasionally!) facilitate the process between the customer and the developers - and it would be nice if they provided food and toys to keep the team happy. It appears, then, that the agile manger is expected to hover on the fringes of a project asking a few questions and throwing in goodies - but with ultimate power (cancellation) in her hip pocket.This scenario makes one wonder. Do managers really matter to the success of an agile project? Are they superfluous? What happens when managers step over the prescribed line - does it mean that the end of Agile Methodology as we know it and as handed down by the Agile Manifesto? The panel will explore this ticklish terrain by answering the following questions.Why Agile Methods and managers don't mix. Or do they?What can/should managers do in an agile environment?Under what conditions are managers an absolute requirement in an agile environment? (e.g. Government applications?)Do good management techniques apply to both Agile and non-Agile environments?Is management a dead-end profession in an Agile world?

As eXtreme Programming grows in popularity and acceptance within the software development community interesting questions arise on whether XP practices can be applied effectively beyond their assumed limitations. For example, as team size and system complexity increase - is XP automatically out of the picture or are there mechanisms now available to scale XP? Panelists will discuss and debate the threshold for XP suitability based on organization/ infrastructure characteristics, project complexity, team size, legacy issues and other relevant topics.

Foreword. Preface. Why This Book? Why You Want to Read This. Book Structure. The Authors. Contributors and Colleagues. Errata and Omissions. Contacting Us. Read the Book, Use the Wiki! I. FROM CONCEPTS TO USING WIKI. 1. Introduction to Discussion and Collaboration Servers. In this Chapter. Collaboration and Discussion Tools. Collaboration Models. Who Uses Collaborative Discussion Servers? Whatever For? Features of a Web-Based Collaboration. On the Horizon: WebDAV. Comparing Wiki to Other Collaboration Tools. 2. What's a The Wiki Concept. The Essence of Wiki. The User Experience. Usefulness Criteria. Wiki Basics. Wiki Clones. Wiki Implementations by Language. Other Wiki Offerings. Non-Wiki Servers. Wiki Application. Pros and Cons of a Wiki-Style Server. Why Consider Setting Up a Wiki? Other Issues. 3. Installing Wiki. QuickiWiki--Instant Serve. Installing Perl. Installing QuickiWiki. Multiple Instances. Wiki and Webserver. Wiki on IIS or PWS. The Apache Webserver. Installing Apache. Reconfiguring Apache. Testing Webserver Wiki. Wrapper Scripts. General Security Issues. Security and Database Integrity. Server Vulnerabilities. Addressing wiki Vulnerabilities. Configuring Your Browser Client. Fonts, Size and Layout. 4. Using Wiki. In this Chapter. Quicki Quick-Start. A Virtual Notebook. Making Wiki Notes, A Walkthrough. Wiki as PIM. A Working Example. The Content Model. Internal and External Hyperlink Models. Browsing Pages. Editing Pages. The Browser Editing Model. Building Wiki Content. Editing and Markup Conventions. 5. Structuring Wiki Content. In this Chapter. Wiki Structure. Structure Types. Only a Click Away. How Hard to Try. When to Impose Structure. When Not to Impose Structure. What is the Purpose of the Wiki? Structure Patterns. When to Spin Off New Wiki Servers. II. UNDERSTANDING THE HACKS. 6. Customizing Your Wiki. In this Chapter. Hacking Your Wiki Source. Copyright and Open Source License Policy. Why Customize? What to Customize. 7. Wiki Components Examined. In this Chapter. Dissecting QuickiWiki. QuickiWiki Component Model. Core QuickiWiki Modules. Sever Component. Optional Extended Components. Analyzing Page Content. Managing User Access. 8. Alternatives and Extensions. Parsing the Requests. ClusterWiki Component Model. The Library Module. Special Features. Spell Checking. Uploading Files. A Standard Wiki? 9. Wiki Administration and Tools. In this Chapter. Events History. Tracking Page Edits. Usage Statistics. Abuse Management. Access Management. Permission Models. Adding Authentication and Authorization. Administering the Database. Page Conversions. Page Management. Backup Issues. Server Resources and Wiki Loading. Avoiding User Waits. Implementing Wiki Constraints. Debugging a Wiki. Programming Resources. Backups. Low-Tech Debugging. Higher-Level Debugging. III. IMAGINE THE POSSIBILITIES. 10. Insights and Other Voices. In this Chapter. Wiki Culture. Wiki as Open Community. Writing Style Contention. Why Wiki Works. The Open-Edit Issue. When Wiki Doesn't Work. Public Wiki Issues. Wiki Style Guidelines. Notifying About Update. Design and Portability. Wiki Trade-Offs. Portability. The Future of Wiki. 11. Wiki Goes Edu. In this Chapter. CoWeb at Georgia Tech. Introduction to CoWeb. CoWeb Usage. Supported CoWeb User Roles. CoWeb Open Authoring Projects. Overall Conclusions. 12. Wiki at Work. In this Chapter. Case Studies. WikiWikiWeb. New York Times Digital. TWiki at TakeFive. TWiki at Motorola. Kehei Wiki Case Studies. A Rotary Wiki. Wiki Workplace Essentials. Why a Workplace Wiki? Planning the Wiki. Selection Stage. Implementation Stage. Day-to-Day Operations. Appendix A: Syntax Comparisons. Hyperlink Anchors. Markup Conventions. Escaped Blocks. HTML Tag Inclusion. Other Syntax Extensions Seen. Appendix B: Wiki Resources. Book Resources. Internet Resources. Appendix C: List of Tips. Index. 020171499XTO5232001

The tools in a literate programming environment need to accept additional responsibility to support the programmer's communication with other programmers. 1. The Expanded Role of Programmers

Pair programming has been practiced in industry with great success for years. Yet, most who have nut tried and tested pair programming reject the idea immediately as a redundant, wasteful use of programming resources. This article demonstrates that incorporating pair programming into a software development process will help yield software products of better quality in less time with happier, more confident programmers.

From the Publisher:Kent Beck's Guide to Better Smalltalk, is a collection of his best work from Object Magazine, The Smalltalk Report, Dr. Dobbs Journal, and more. Each article has a new introduction that takes a retrospective view of the writing. Topics include: idioms and environments, methods and metamodels, architecture and pattern languages, objects, classes, inheritance, and all things Smalltalk! While demonstrating the elegance of Smalltalk and how some of its most powerful features can be exploited profitably, this collection also illuminates breakthrough concepts in object-oriented development. This book is for Smalltalk programmers and anyone working in object-oriented software development.