Effective tools, gates, and accountability can help ensure your system’s success

any people incorrectly judge Java/J2EE-based systems on problems associated with maintaining the codebase, the number of bugs or inconsistencies in functionality, or poor performance. Fortunately, these problems have less to do with the Java/J2EE technology itself and more to do with the lack of a process focused on the quality of the system. To ensure success of large-scale Java/J2EE projects developed by a sizeable team, or across multiple teams, a team lead must:

• Use tools that can measure quality
• Define a set of gates and artifacts derived from the tools
• Stress accountability to deliver, monitor, and enforce the results

This article explains how incorporating these three tactics into your development strategy can ensure that your team consistently produces quality projects.

Importance of tools
Have you ever heard of a construction company attempting to build a house without a power saw, electric drill, or a tool as fundamental as a hammer? True, a house could be built without today’s new-fangled equipment, however, construction would take much longer, and the same level of quality would prove nearly impossible to achieve. You could build a hut with your bare hands, but you could build a mansion with the right tools.

Today’s developers are no different than a person attempting to build a house. The tools are essential to the developer, both for increasing productivity and for enhancing quality. The tools developers use must enable them to produce the highest quality code possible in the shortest amount of time, which means that today’s IDE is no longer simply a tool used to write, debug, and compile code. Instead, an IDE must help developers identify whether they are following proper coding conventions and known design patterns, if they are in compliance with industry standards such as Web services, if their code adheres to its contract, and if it performs per the requirements. In addition, when developers are not given the environments necessary to achieve continuous builds and automated testing, an IDE’s capabilities become even more important to ensuring the system’s quality.

Enter the Eclipse IDE, which provides built-in capabilities that, when used with several plug-ins, can aid in increasing the quality of both the codebase and the system. Eclipse is an open, extensible IDE built for anything and nothing in particular. Eclipse’s Java development environment is open source, free, and fully customizable. Eclipse both enables and promotes the addition of new capabilities via open source and commercially available custom-built plug-ins. By utilizing Eclipse, along with a key set of plug-ins illustrated in the Eclipse plug-in matrix shown in Figure 1, it is possible for a developer, and a team, to measure the quality of any J2EE- or Java-based system.

Figure 1. Eclipse plug-in matrix

Controlling the quality of a system is impossible if you cannot measure and monitor it. It is important to understand key areas in a system that warrant measurement. These areas include a system’s maintainability, reliability, and performance. While this list is obviously not all-inclusive, these three items are highly suited as the basic building blocks for ensuring the quality of a system.

Maintainability involves the complexity associated with understanding the code or modifying the code, whether it is a bug fix or an enhancement. Well-documented code that follows known coding standards and industry design standards is easier to maintain than code with sparse documentation that doesn’t follow any known standard development practices. Highly maintainable code allows changes to be introduced more quickly, thereby permitting the business to respond more rapidly to new requirements or change requests, and ultimately reducing the overall cost of both new features and ongoing maintenance.

Reliability indicates whether a method adheres to its contract and can be executed successfully. Unit tests are used to exercise a method’s contract, thus verifying the reliability of the code segment. The quality of the unit tests, in turn, is verified via code coverage analysis. Many approaches are available for measuring code coverage, including, but not limited to, statement, decision, condition, path, and call analysis. The type and amount of coverage necessary to provide absolute reliability of a method is a popular discussion topic. For this article’s purpose, simply note that reliability increases as the amount of code coverage increases.

Method reliability within a system is of the utmost importance as it represents, to some extent, a system’s stability. Other problems, such as performance or scalability issues, could arise, which may not be as readily found even with extensive unit testing and coverage analysis. Thus, unit testing and coverage analysis are by no means a be-all, end-all solution to ensuring system stability; however, the ability to reliably execute methods consistently represents a good measuring stick of the system’s reliability.

Performance is typically measured on a per-unit-of-time basis. A system’s ability to process numerous requests, to the amount of information sent over the wire, to the response time of a particular system call, are all performance criteria measured based on a unit of time. It is important to know, to some extent, how the system will perform. To ensure this understanding, one could measure all major service methods or potential problem areas with expected high usages, long call stacks, or those pieces that represent the most common paths through the core architecture. Each approach provides a varying level of comfort with regard to performance. For large-scale systems, performance should be continually maintained and monitored during development to identify snags early and avoid unforeseen problems in production environments.

Let’s now examine how the use of Eclipse and its plug-ins can help a development team, measure the maintainability, reliability, and performance of any Java- or J2EE-based system.

Code generation: Maintainability
Code generation is one of the best ways to ensure consistency and quality for repeatable code that differs based on type. XDoclet is currently the industry standard for generating Java source code. XDoclet is an open source, free library that parses the codebase, looking for custom Javadoc tags (metadata) that it then uses to generate other Java source files. XDoclet contains a set of Javadoc tags that may be used to generate most of the repeatable code found in the majority of Java/J2EE-based systems, such as JavaBeans and home and remote classes for Enterprise JavaBeans, even providing specific information for Borland Enterprise Server, JBoss, Orion, Resin, Sun Java System Application Server, WebLogic, and WebSphere. It also supports many other technologies such as Hibernate, JDO (Java Data Objects), and Castor. If that isn’t enough, XDoclet is extensible, allowing developers to create their own custom tags for generating homegrown code. By employing XDoclet and letting it generate code for you, you can reduce unnecessary coding errors and bugs found in repetitive code.

Code metrics: Maintainability
Due to the large size of codebases, visually monitoring the entire codebase is unachievable. Instead of walking through every line of code, metrics may be used to identify both existing and potential problems. The Metrics plug-in for Eclipse is an open source, free tool that can generate metrics on a per-class, per-package, or per-project level. The results may be exported to an XML file for historical purposes. It also contains an Ant task that can be used to generate the XML file at build time.

The Metrics Eclipse plug-in provides more than 23 types of metrics. Some of the most important metrics include number of interfaces, depth inheritance tree, number of overridden methods, McCabe’s cyclomatic complexity, afferent coupling, efferent coupling, and abstractness. By default, the Metrics view displays the compliant metrics in blue and the outliers in red. Anything in red represents a possible problem in the code that should be reviewed. The plug-in has its own view and runs in the background; thus, it can not only be used by a team lead at the end of an iteration, but also by developers as they code.

Code reviews: Maintainability
A code review is a useful exercise that helps ensure code quality, while also training and mentoring developers on coding style and coding best practices. Jupiter is an open source, free tool that allows team-based code reviews. Jupiter uses XML files to track individual team member reviews with a review ID and a reviewer ID (the review ID is shared for team-based reviews). These files are then checked into source control and made available to other developers, allowing for multiple reviews to occur simultaneously, without a server managing the reviews.

Each team member uses an XML file to check in and out of source control and see what needs fixing as well as what has been fixed by other team members. The use of Jupiter is a great way to tag required fixes without enduring the rigor that normally surrounds bug-tracking policies during new development. Jupiter frees team members to review code at their convenience, instead of forcing them to stop development at a time when they might be solving a problem to attend a code review meeting.

Standards adherence: Maintainability
Development standards exist to ensure past mistakes are not repeated. In addition, they ensure the code is consistent and more readable for the developer who must later maintain the code. Eclipse comes with a built-in code formatter that adheres to Java coding conventions. While this is a great feature, a code formatter is not enough to ensure the production of quality code.

Checkstyle builds upon Eclipse’s code-formatting capabilities, adding more than syntactical checks. It can identify noncompliant code blocks, coding problems, duplicate code, and some metrics violations. Even better, Checkstyle is extremely customizable, allowing the user to tailor the types of checks and their level of severity per the development standards within the organization. The default configuration file that comes with the Checkstyle plug-in is extremely comprehensive. Even so, I suggest developers invest their own time to customize this plug-in to match their organization’s development needs. Once customized, the Checkstyle configurations may be exported and used from project to project. The results of Checkstyle are displayed in the Problems view, which may be filtered and sorted. Results may be viewed at the folder, working-set, or resource (file) level, allowing developers to understand the quality of the overall codebase, subsystem, or individual class.

If your team is engaged in Web services development, then WSVT (Web Services Validation Tools) is a must-have plug-in. WSVT can determine if a Web service conforms to the guidelines and requirements defined in the WS-I (Web Services Interoperability) Basic Profile. Developers can right-click on a WSDL (Web Services Description Language) file, and it validates the WSDL and generates a report in a custom view that displays any violations. As an added bonus, the WSVT plug-in monitors TCP/IP traffic and observes, captures, and validates SOAP messages. The WSVT plug-in thus ensures compliance both at the interface and message level.

Functional testing: Reliability
Eclipse ships with both Ant and JUnit. Ant is the de facto industry standard for building Java-based applications. JUnit is a Java-based framework for creating unit tests.

Developers can set up individual JUnit tests to run in Eclipse, which provides a special view for the JUnit results, or use the Ant JUnit or JUnitReport task. The JUnitReport Ant task generates an HTML viewable report that may be used to represent the entire system’s tests, or specific tests, depending upon the customization. The HTML report is an excellent report to save for historical purposes as it can be used to gauge the project’s quality. By using JUnit for unit testing, developers can ensure their methods adhere to their contract, thus avoiding bugs that arise due to noncompliance.

Code coverage: Reliability
When developers write unit tests, they should understand how much codebase coverage their unit tests provide. GroboCodeCoverage is an open source coverage tool that integrates with Ant by providing an Ant task that can generate coverage reports. Individual reports may be generated, such as the Line Count Report and Function Count Report, which provide coverage percentages at the line and method level, respectively. However, the cornerstone of the tool is its Source Summary Coverage Report. This report mimics the Javadoc structure and provides a quality professional report that may be stored for historical purposes. As the project progresses, the report can be referenced to understand whether code coverage increases or decreases over time. By using GroboCodeCoverage, developers can ensure their most critical code pieces are fully exercised and pinpoint areas that lack coverage. Using this information, they may add or update existing JUnit tests, thus increasing system reliability.

Profiler: Performance
As projects near the end of the construction phase, developers tend to start thinking more about performance. Profiler for Eclipse is an open source, free profiler that provides many of the features that a developer needs for solving common performance issues. It shows the threads, the heap size, heap dump, method calls, method times, calls per package, and thread call-trees that allow a developer to see where time was spent through the flow of a call. Profiler for Eclipse helps developers understand where the application’s bottlenecks are occurring, allowing them to correct problems before releasing the application to the QA (quality assurance) department or production.

Next page >

Search is important! All too often search looks like where thing like ‘%that%’. Users know google, and quite a few even know its query language at this point. Aside from wanting to provide more functionality in search, users are expecting it. Google seems simple, doesn’t it?Enter Lucene. I’ll presume you’ve heard of it at least, if not used it. Lucene does full text indexing, and that is it. It does this really well. The beauty (well, one) is that you can index anything. In this case, I’ll index an object being persisted by OJB. The key is to embed information required to retrieve the document being indexed.

Take a gander at a fairly simple Student class (this is frmo an app I am doing for my little brother, who is a professor (of such terrible subjects as rock climbing and white water kayaking, don’t get me started)).

The primary use case for this application is for a student coop employee to be finding a student in the system, then finding gear and checking the gear out for the student. Finding the student is key, and that is best served by… searching! So we have a database record for each student, and want to have a convenient search facility, which can search based on name, student id (idNumber), phone number, even address. Lucene makes this is a snap. To do it, we just store the id (internal/pk id) in an unindexed field when we add a student in the StudentIndexer:

public void add(final Student student) throws ServiceException {
final Document doc = new Document();
doc.add(Field.Text(NAME, student.getName()));
doc.add(Field.Text(ID_NUMBER, student.getIdNumber()));
doc.add(Field.Text(ADDRESS, student.getAddress()));
doc.add(Field.Text(PHONE, student.getPhone()));
doc.add(Field.UnIndexed(IDENTITY, student.getId().toString()));
try {
synchronized (mutex) {
final IndexWriter writer = new IndexWriter(index, analyzer, false);
writer.addDocument(doc);
writer.optimize();
writer.close();
}
}
catch (IOException e) {
throw new ServiceException("Unable to index student", e);
}
}

Notice the UnIndexed field on the Document? This tells Lucene to store this field with the record, but don’t index it or search on it. When you retrieve the document you will get the field though. Perfect place to stash the primary key.

When we look for the students, we don’t want to get back Lucene Document instances, though, we want to go ahead and get the nice domain model instances of Student. What we’ll do is query against the index, pull all the pk’s for the hits out, then select for the domain objects using those pks (from the StudentIndex:

public List findStudents(final String search) throws ServiceException {
return this.findStudents(search, Integer.MAX_VALUE);
}

public List findStudents(final String search, final int numberOfResults) throws ServiceException {
final Query query;
try {
query = QueryParser.parse(search, StudentIndexer.NAME, analyzer);
}
catch (ParseException e) {
throw new ServiceException("Unable to make any sense of the query", e);
}
final ArrayList ids = new ArrayList();
try {
final IndexReader reader = IndexReader.open(index);
final IndexSearcher searcher = new IndexSearcher(reader);
final Hits hits = searcher.search(query);
for (int i = 0; i != hits.length() && i != numberOfResults; ++i) {
final Document doc = hits.doc(i);
ids.add(new Integer(doc.getField(StudentIndexer.IDENTITY).stringValue()));
}
searcher.close();
reader.close();
}
catch (IOException e) {
throw new ServiceException("Error while reading student data from index", e);
}
final List students = dao.findStudentsWithIdsIn(ids);
Collections.sort(students, new Comparator() {
public int compare(final Object o1, final Object o2) {
final Integer id_1 = ((Student) o1).getId();
final Integer id_2 = ((Student) o1).getId();
for (int i = 0; i != ids.size(); i++) {
final Integer integer = (Integer) ids.get(i);
if (integer.equals(id_1)) {
return -1;
}
if (integer.equals(id_2)) {
return 1;
}
}
return 0;
}
});
return students;
}

The findStudents(string, string, int): List method is a little bit more complex than I like as it does a few things: query against the lucene index, extract the primary keys for the hits, query for the students matching those pk’s (via the StudentDAO), and finally sorts the results (no way to specify the sort order in the query, it is dependent on the order of the hits from the lucene query). With that though, we support queries such as Tiffany, which is simple, or a more fun one, name: Aching phone: ???-1234 or what not. Go look at the Lucene query parser syntax. It is worth noting that the above query defaults to searching on the name field if no specific field is specified. This seems to make sense to me =)

If you look at the StudentIndex and StudentIndexer you will see there are also facilities for adding and removing documents from the lucene index. This gets important on any insert/update/delete operation. The update is important to catch as you need to remove the old entry and insert a new one in the index. Doing this is best done (my opinion) via an aspect which picks these operations out. That is outside the scope of this article though

For a larger application with more things being indexed (this just has two searchable domain types) I might generalize the search capability via a DocumentFactory such as:

public class BeanDocumentFactory implements DocumentFactory {
public Document build(Object entity) {
final Document document = new Document();
try {
final BeanInfo info = Introspector.getBeanInfo(entity.getClass());
final PropertyDescriptor[] props = info.getPropertyDescriptors();
for (int i = 0; i != props.length; ++i) {
final PropertyDescriptor prop = props[i];
final String name = prop.getName();
final Method reader = prop.getReadMethod();
final Object value = reader.invoke(entity, new Object[]{});
final Field field = Field.Text(name, String.valueOf(value));
document.add(field);
}
}
catch (Exception e) {
throw new RuntimeException("Handle these in real application", e);
}
return document;
}
}

But I have not needed to generalize it for a real project yet =)

Speaking of Lucene (which rocks) I am eagerly anticipating Erik Hatcher’s new book, Lucene in Action. If it is anything like Erik and and Steve Loughran’s Java Development with Ant Lucene will be a lucky project to have it in circulation.

About the author

Brian McCallister
Blog: http://kasparov.skife.org/blog/

[转]IBM CEO致员工的关于联想收购IBM个人计算机部门的信
2004-12-17 12:59:04　Dear IBMer:
　　
　　I have important news to share with you.
　　
　　Today we announced a definitive agreement with the Lenovo Group, China’s largest manufacturer and distributor of personal computers. Lenovo will acquire IBM’s Personal Computing Division, creating the third-largest PC business in the world. Headquartered in New York, Lenovo’s new PC business will be our preferred supplier of IBM- and Think-branded PCs. This will allow us to continue to provide our clients with end-to-end integrated solutions — but with the advantages of a PC business with unique and powerful capabilities: significant economies of scale, global distribution channels, strong brand recognition, an experienced and expert management team and workforce, and number one market position in the world’s fastest growing IT market. In addition, IBM will be Lenovo’s preferred services and financing provider. IBM will hold an 18.9 percent equity stake in Lenovo.
　　
　　Today’s announcement is the latest action we have taken in recent years to reposition IBM for leadership in a rapidly changing industry. For some time we have said that there are two ways to create long-term value for clients and shareholders in the IT industry: Invest heavily in R&D and be the high-value innovation provider for enterprises, or differentiate by leveraging vast economies of scale, high volumes and price.
　　
　　IBM is an innovation company. We are committed to being the premier IT solutions partner for enterprises of all sizes, in all industries. This business model requires that we continuously create intellectual capital and that we reinvent everything we do — our technologies, products and services, our culture and our portfolio of businesses. This has been the hallmark of our company and has enabled IBM to grow and to lead countless product and technology cycles over many decades.
　　
　　Today, computing and its uses are again changing radically — to what we’ve been describing as on demand business. This is opening up tremendous opportunities for IBM, and it’s why we have invested billions of dollars in recent years to strengthen our capabilities in hardware, software, services and core technologies focused on transforming the enterprise. At the same time, the PC business is rapidly taking on characteristics of the home and consumer electronics industry, which favors economies of scale, pricing power and a focus on individual users and buyers. These are very different business and economic models, and they will diverge even further in the years ahead.
　　
　　By combining our personal computing division with its own, highly complementary business, Lenovo will be much better positioned to capture the opportunities in the PC industry. Lenovo is committed to investing in, growing and winning in PCs. Lenovo will be a formidable competitor, and our alliance gives IBM an even stronger position in China, while strengthening our brand presence there.
　　
　　Of course, IBM will continue to play a significant role in creating innovations for individuals — and not only through the broad PC alliance we are announcing today. As you know, our company is investing heavily to create the computing platform of the future. Our microprocessors and open software technologies underpin the next-generation on demand infrastructure, which will extend from the enterprise to the home to the mobile product to an expanding array of connected devices. In just the past couple of weeks, we’ve made significant announcements about advanced microprocessors we are developing in partnership with some of the world’s leading consumer electronics companies, as well as initiatives to broaden adoption and support for these open platforms.
　　
　　We are excited by today’s announcement and how it further positions IBM for leadership in the days and years ahead.
　　
　　
　　Sam Palmisano
　　Chairman and Chief Executive Officer

DocBook XSL:The Complete Guide

Chapter 2. XSL processors

An XSL processor is the software that converts an XML file into formatted output. There is a growing list of XSL processors to choose from. Each tool implements parts or all of the XSL standard, which actually has several components:

To publish HTML from your XML documents, you just need an XSLT processor. It will include the XPath language since that is used extensively in XSLT. To get to print, you need an XSLT processor to produce an intermediate formatting objects (FO) file, and then you need an XSL-FO processor to produce PostScript or PDF output from the FO file. A diagram of the DocBook Publishing Model is available if you want to see how all the components flow together.