"Double, double, toil and trouble"... Shakespeare's words (Macbeth, Act 4, Scene 1) often cover circumstances beyond his wildest dreams. Toil and trouble accompany major computing transitions, even when people plan ahead. To calibrate "tomorrow's legacy today," we should study "tomorrow's legacy yesterday." Much of tomorrow's software will still be driven by decades-old decisions. Past decisions have unanticipated side effects that last decades and can be difficult to undo.
A look inside and extensible plug-in architecture
ECLIPSE is both an open, extensible development environment for building software and an open, extensible application framework upon which software can be built. Considered the most popular Java IDE, it provides a common UI model for working with tools and promotes rapid development of modular features based on a plug-in component model. The Eclipse Foundation designed the platform to run natively on multiple operating systems, including Macintosh, Windows, and Linux, providing robust integration with each and providing rich clients that support the GUI interactions everyone is familiar with: drag and drop, cut and paste (clipboard), navigation, and customization. You can think of Eclipse as a "design center" supported by a development team of 300 or more developers whom you can leverage when developing your own software.
Can agile development make your team more productive?
Keeping up with the rapid pace of change can be a daunting task. Just as you finally get your software working with a new technology to meet yesterday's requirements, a newer technology is introduced or a new business trend comes along to upset the apple cart. Whether your new challenge is Web services, SOA (service-oriented architecture), ESB (enterprise service bus), AJAX, Linux, the Sarbanes-Oxley Act, distributed development, outsourcing, or competitive pressure, there is an increasing need for development methodologies that help to shorten the development cycle time, respond to user needs faster, and increase quality all at the same time.
This month Queue tackles the problem of system evolution. One key question is: What do developers need to keep in mind while evolving a system, to ensure that the existing software that depends on it doesn’t break? It’s a tough problem, but there are few more qualified to discuss this subject than two industry veterans now at Sun Microsystems, David Brown and Bob Sproull. Both have witnessed what happens to systems over time and have thought a lot about the introduction of successive technological innovations to a software product without undermining its stability or the software that depends on it.
Time again companies moving to build large scale systems and networks stumble over the same problems. In an interview with ACM Queuecast host Michael Vizard, Jarod Jenson, the brains behind the Enron Online trading site, talks about the best practices he emphasizes now that he is the chief architect for Aeysis, a consulting firm that specializes on advising clients on how to build manageable high performance systems.
A new paradigm created to empower business system analysts by giving them access to meta-data that they can directly control to drive business process management is about to sweep the enterprise application arena. In an interview with ACM Queuecast host Michael Vizard, Oracle vice president of product development Edwin Khodabakchian explains how the standardization of service-oriented architectures (SOAs) and the evolution of the business process execution language (BPEL) are coming together to finally create flexible software architectures that can adapt to the business rather than making the business adapt to the software.
In this edition of the ACM Queuecast hosted by Mike Vizard, Oracle's chief architect for tools and middleware Ted Farrell talks about the role of IDEs in the Eclipse open source era, and why developers still need IDE tools to better leverage a wide variety of middleware assets and take a more modular approach to building complex business applications.
Chasing citations through endless, mislabeled nodes
Many are said to have said, "If I can't take it with me, I'm not going!" I've just said it, but that hardly counts. Who, we demand, said or wrote it first? It's what I call (and claim first rights on) a FUQ (frequently unanswerable question, pronounced fook to avoid ambiguity and altercation). Yogi Berra's famous advice was "You can look it up," meaning, in fact, "Take my word on this." He knew quite well that few had the means or patience to wade through the records. Nowadays, of course, as we quip in Unix, it's easier done than sed. The portmanteau wep for grepping the Web, now realized and refined in countless search engines, lets us take up Yogi's challenge at face value with a few simplistic keystrokes and mouse-clicks. Yet, as I aim to indicate, life - at least the life of serious scholarship - is not a bowl of Googles.