A J2ME FAQ is an article by Kevin Boone on his personal website. Areas covered in this FAQ include: J2ME technologies, J2ME development procedures and tools, MIDP/CLDC programming, File and data management, and Networking and communications. The article is not too long and is good and concise.

It is an article from TheServerSide.com, written by Dan Moore, and posted in February 2005. Click this URL to read it.

A cell phone application can be a good fit for certain types of problems, especially those requiring timely data access away from typical internet connectivity. Java 2 Micro Edition (J2ME) is one of the leading platforms for developing such solutions.

This paper explores the various facets of building a J2ME application. It assumes a working knowledge of Java. The focus is on a MIDP 1.0/CLDC 1.0 application that depends heavily on network access. 

JUnit is a regression testing framework written by Erich Gamma and Kent Beck. It is used by the developer who implements unit tests in Java. JUnit is Open Source Software, released under the Common Public License Version 1.0 and hosted on SourceForge. (Source: JUnit.org)

Regression testing is testing that a program has not regressed; the functionality that was working yesterday is still working today. In other word, regression testing is to ensure that we do not introduce new bugs while removing existing bugs. A program still works correctly after changes were made to it. The JUnit testing framework makes it easy to create unit tests and to perform regression testing in Java programs.

Suggested introductory reading: 

• JUnit Automates Java Testing (David Morris, November 06, 2003)

This is a paper written by Everette R. Keith in December 2002. It introduces and discusses Agile Software Processes. It discusses several of the Agile Processes, the philosophy driving them and the challenges faced when implementing them. Includes good overviews of Adaptive Software Development, Crysta, Extreme Programming, and the Rational Unified Process.

The paper can be downloaded through Agile Alliance or using the following URL directly. Here is the abstract of the paper.

In software development there exists a tension between quality, cost, and time. Delivering cost competitive quality software in today’s time constrained market is a difficult task. Many traditional software processes are top heavy with documentation and rigid control mechanisms making it difficult applying them to different software projects. New families of processes, referred to as Agile Processes, are making headway into the software industry. These processes focus on code rather than documentation calling themselves agile because, unlike the traditional processes, they are adaptable, not rigid. This paper discusses several of these Agile Processes, the philosophy driving them and the challenges faced when implementing them.

From the Merriam-Webster Dictionary, the word ‘Agile’ is an adjective describing someone who (or something that) has a quick, resourceful and adaptable character and is marked by the ready ability to move with quick and easy grace. Therefore, the term ‘Agile software development’ or ‘Agile software methodologies’ is used to refer to a category of software development methodologies with the agile property — the processes can quickly switch direction or adapt to new information. In line with this, Highsmith (2002) gave a well-accepted definition of agility ‘the ability to both create and respond to change in order to profit in a turbulent business environment’. Extreme Programming (XP) is an example that happens to belong under the agile methodologies category. There are many others as well. However, they have not received as much popularity and attention as XP has.

The Agile Alliance is a non-profit organization formed in 2001 by the originators and practitioners of a number of methodologies that share the same values. The values they share are shown below.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Alliance — To satisfy the customer through early and continuous delivery of valuable software

Refactoring is the act of improving the design of existing code without changing the published API.

If you make refactoring (including testing!) a part of your normal programming practice, it will pay off in the simplicity and flexibility your system will have. William Wake shows you how. To learn more, please read What Is Refactoring? by William Wake.

Refactoring is the process of improving the design of code without affecting its external behavior. We refactor so that our code is kept as simple as possible, ready for any change that comes along.

We’ll start with some realistic code and work our way through several refactorings. Our code will become more clear, better designed, and of higher quality.

What do we need for refactoring?

• Our original code
• Unit tests (to ensure we haven’t unwittingly changed the code’s external behavior)
• A way to identify things to improve
• A set of refactorings we know how to apply
• A process to guide us