Books Index

Management

The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition
by Frederick P. Brooks, Jr.

SITE1 Read: PDF
SITE2 Download: PDF

Set up Java Development Environment on Ubuntu Linux

System Requirements:

• Ubuntu 8.04
• NetBeans IDE 6.1
• GlassFish V2 UR2

Install JDK on Ubuntu Linux

1. Download Java SE 6 Documentation(jdk-6-doc.zip) from http://java.sun.com/javase/downloads/index.jsp
2. Copy the file jdk-6-doc.zip to /tmp
   
3. Open the "Synaptic Package Manager".
4. Install the sun-java6-jdk, sun-java6-source, sun-java6-doc and sun-java6-demo packages.
5. You can now delete jdk-6-doc.zip, if you wish.
   

Install NetBeans and GlassFish

1. Download NetBeans IDE 6.1 All Bundles edition (include Base IDE, Java SE, Web & Java EE, Mobility, UML, SOA, Ruby, C/C++, GlassFish V2 UR2 and Apache Tom) from www.netbeans.org
2. Run ./netbeans-6.1-ml-linux.sh to start NetBeans installer wizard.
3. Click the "Customize" button on the first screen of the installer wizard and check the Apache Tomcat 6.0.16.
4. Install the NetBeans IDE to: /usr/local/netbeans-6.1
   JDK for the NetBeans IDE: /usr/lib/jvm/java-6-sun
5. GlassFish V2 UR2 Installation
   Install GlassFish to: /usr/local/glassfish-v2ur2
   JDK for GlassFish application server: /usr/lib/jvm/java-6-sun
   Admin Username: admin
   Admin Password: adminadmin
   HTTP Port: 8080
   HTTPS Port: 8181
   Admin Port: 4848
   
6. Install Apache Tomcat to: /usr/local/apache-tomcat-6.0.16
7. Finish
   

Uninstall NetBeans and GlassFish

1. Shut down the IDE.
2. In the IDE installation directory, run the uninstall.sh file.
3. To uninstall GlassFish/Tomcat together with the IDE, at the Summary page make sure that the correct versions are listed and check the appropriate checkboxes.
4. At the Summary page, click Uninstall.
5. After uninstallation completes, click Finish.

Start JavaDB

1. NetBeans IDE > Services > Databases > Java DB
2. Right-click > Start Server
   

References

• NetBeans IDE 6.1 Installation Instructions http://www.netbeans.org/community/releases/61/install.html

JavaServer Faces Books

JavaServer Faces in Action
PDF

Java SE Books

Core Java™ 2 Volume I - Fundamentals, Seventh Edition
by Cay S. Horstmann, Gary Cornell
Read
Download

Effective Java: Programming Language Guide
by Joshua Bloch
SITE1 Read: PDF
Internet Download: ZIP
SITE2 Download: PDF

Apache Commons Books

Apache Jakarta Commons: Reusable Java™ Components
by Will Iverson

Download

Jakarta Commons Cookbook
by Timothy M. O'Brien

Download

Pro Jakarta Commons
by Harshad Oak

Download

JUnit Recipes: Practical Methods for Programmer Testing

Download

Extract

The tests are the specification!—If add() and contains() contain defects that cancel one another out, then the test passes and we can argue that the behavior is correct. We hope that future tests will uncover the defects, but if that never happens then we have incorrect code that exhibits correct behavior. If code does the wrong thing but no test fails, does it have a defect? More and more JUnit users say, “No.” They say that “The tests are the specification,” which means that we describe what our code does by providing the tests our code passes. A feature is not present unless there are tests to verify it. Each test is a claim that the code behaves a certain way, so if no test exists to verify that we can add an object twice to the same List, then we cannot assume that that would work. This certainly puts pressure on the programmer to write enough tests!

Just for testing—It is most common to test classes entirely through their public interface. If you adopt this approach as a rule, then you will encounter some cases where you need to add a public method to your class’s interface—often a getter—in order to gain access to the data you need to verify a given behavior. This is a controversial issue among programmers: adding the method seems to break encapsulation “just for testing,” which introduces a trade-off that different people evaluate differently. As with any such situation, it is up to you to try both options and measure the difference.

If your class does not expose readable properties, then you must build some other observable side effect that you can use to verify the correctness of the constructor. It is possible to write a method named isValid() to help verify the sanity of your object without violating the data-hiding principle.

The rule of thumb is this: if the get method simply answers the value of a field, then consider not writing a test for it; however, if the method does anything more complex than that, consider writing the test.

Test-Driven Development By Example

Test-Driven Development By Example
by Kent Beck
SITE1 Read: PDF
SITE1 Download: PDF

Extract

Failure is progress. Now we have a concrete measure of failure. That's better than just vaguely knowing we are failing.

Remember, the cycle is as follows.
1. Add a little test.
2. Run all tests and fail.
3. Make a little change.
4. Run the tests and succeed.
5. Refactor to remove duplication.

The general TDD cycle goes as follows.
1. Write a test. Think about how you would like the operation in your mind to appear in your code. You are writing a story. Invent the interface you wish you had. Include all of the elements in the story that you imagine will be necessary to calculate the right answers.
2. Make it run. Quickly getting that bar to go to green dominates everything else. If a clean, simple solution is obvious, then type it in. If the clean, simple solution is obvious but it will take you a minute, then make a note of it and get back to the main problem, which is getting the bar green in seconds. This shift in aesthetics is hard for some experienced software engineers. They only know how to follow the rules of good engineering. Quick green excuses all sins. But only for a moment.
3. Make it right. Now that the system is behaving, put the sinful ways of the recent past behind you. Step back onto the straight and narrow path of software righteousness. Remove the duplication that you have introduced, and get to green quickly.

Principles for Index Creation

MySQL 5 Certification Study Guide > Chapter 22. Basic Optimizations > 22.2. Using Indexes for Optimization > 22.2.2. Principles for Index Creation
An index helps MySQL perform retrievals more quickly than if no index is used, but indexes can be used with varying degrees of success. Keep the following index-related considerations in mind when designing tables:

• Declare an indexed column NOT NULL if possible. Although NULL values can be indexed, NULL is a special value that requires additional decisions by the server when performing comparisons on key values. An index without NULL can be processed more simply and thus faster.
• Avoid over indexing; don't index a column just because you can. If you never refer to a column in comparisons (such as in WHERE, ORDER BY, or GROUP BY clauses), there's no need to index it.
• Another reason to avoid unnecessary indexing is that every index you create slows down table updates. If you insert a row, an entry must be added to each of the table's indexes. Indexes help when looking up values for UPDATE or DELETE statements, but any change to indexed columns require the appropriate indexes to be updated as well.
• One strategy the MySQL optimizer uses is that if it estimates that an index will return a large percentage of the records in the table, it will be just as fast to scan the table as to incur the overhead required to process the index. As a consequence, an index on a column that has very few distinct values is unlikely to do much good. Suppose that a column is declared as ENUM('Y','N') and the values are roughly evenly distributed such that a search for either value returns about half of the records. In this case, an index on the column is unlikely to result in faster queries.
• Choose unique and non-unique indexes appropriately. The choice might be influenced by the data type of a column. If the column is declared as an ENUM, the number of distinct column values that can be stored in it is fixed. This number is equal to the number of enumeration elements, plus one for the '' (empty string) element that is used when you attempt to store an illegal value. Should you choose to index an ENUM column, you likely should create a non-unique index. A PRIMARY KEY would allow only as many rows as the number of distinct enumeration values. A UNIQUE index enforces a similar restriction, except that unless the column is declared NOT NULL, the index allows NULL values.
• Index a column prefix rather than the entire column. MySQL caches index information in memory whenever possible to avoid reading it from disk repeatedly. Shortening the length of key values can improve performance by reducing the amount of disk I/O needed to read the index and by increasing the number of key values that fit into the key cache. This technique is discussed in Section 22.2.3, "Indexing Column Prefixes."
• Avoid creating multiple indexes that overlap (have the same initial columns). This is wasteful because MySQL can use a multiple-column index even when a query uses just the initial columns for lookups. For more information, see Section 22.2.4, "Leftmost Index Prefixes."
• The index creation process itself can be optimized if you are creating more than one index for a given table. ALTER TABLE can add several indexes in the same statement, which is faster than processing each one separately. CREATE INDEX allows only one index to be added or dropped at a time.

For indexed MyISAM or InnoDB tables, keeping the internal index statistics up to date helps the query optimizer process queries more efficiently. You can update the statistics with the ANALYZE TABLE statement. See Section 38.3.2, "Keep Optimizer Information Up to Date."

Powered by ScribeFire.

MySQL Documentation

MySQL Documentation @ mysql.com
http://dev.mysql.com/doc/

MySQL 5 Certification Study Guide
Download

MySQL 5.1 Reference Manual
Read Download

The Best Practice of JUnit

JUnit Recipes > 1.3 A few good practices > 1.3.1 Naming conventions for tests and test classes

1.3.1 Naming conventions for tests and test classes

1.3.2 Test behavior, not methods

This brings us to another recommendation when writing tests: your tests should
focus on the behavior they are testing without worrying about which class is under
test. This is why our test names tend to be verbs rather than nouns: we test behavior
(verbs) and not classes (nouns).

... so we recommend focusing your test effort on
the object as a whole, rather than its parts.