Monday, February 15, 2010

Submission guideline

For the Iteration#1 submission, I went through some hard times as I built, ran and executed your acceptance tests. Most submissions had some kind of documents explaining the situation, but it still took some time to get the project built and run. To make it conforming lets try one of the two following alternatives:
  1. Submit an Eclipse project. Ensure that, i) Run > Run As > Java Application runs your application and ii) Run > Run As > JUnit test runs all the tests in your application.
  2. Submit a project that has the following structure
  • Project Root
    • run - a command file (preferably unix shell or windows cmd) that loads your application.
    • test - a command file that runs all the tests.
    • All other folders, files as you may have
Also Important are:
  1. All other files, such as time spent, log files and diagrams should be sent using PDF/Word/Excel/Text/PNG/JPG only. Othewise, I might not have the software to open your submission.
  2. Submission should be emailed in a single email, instead of in parts. Otherwise, I may not see one of your submissions.
Large scale software development projects usually follow some standards for deploying their product frequently and frictionlessly. Thats why I mentioned using Eclipse or Maven could help you in conforming to shared standards. Lets see a few standards here:
  1. When built, your .class files should be separated from your .java files so that it is easy to deploy only the .class files. I know using some commands you can easily extract the class files from the source files, however, the target is to simplify the process as much as possible.
  2. Your acceptance and all test class files should be in a separate folder than your application class files. So that, when you deploy your application, you don't waste space in deploying the test classes.
  3. Most java applications are deployed as Jar files instead of a lot of class files. So, when you build one, its a good practice to make the final build output is archived to a jar file, which is easy to transport and manage.
Please comment here if I am missing something.

Wednesday, February 10, 2010

ArgoUML - for UML diagrams

You can download and use ArgoUML from this link. It will help you with diagramming UML class diagrams and managing it over time.

Monday, February 8, 2010

A sample application to try logger

A sample application to show the built in java logger in action:
https://docs.google.com/leaf?id=0B6pf6btYtM3IYWIzN2E2NmItYmYyMS00ZTRkLThhOGQtMDMxNjYyNzEyNGZk&hl=en
To run this, compile and then use:
java -Djava.util.logging.config.file=logger.properties MainClass

Log4J

I took this presentation from www.ltn.lv/~apsitis/java-eim/.../Lekcija02%20-%2002_Log4J.ppt





Wednesday, February 3, 2010

Apache MAVEN - to help you manage your code and tests

Apache Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information.
Find more at http://maven.apache.org/

Guice - a light-weight DI framework from google

Dependency Injection helps you to write loosely coupled object oriented code. As a side-effect, you will be able to write a better testable code. A good discussion is found at http://en.wikipedia.org/wiki/Dependency_injection

For Java there are a few alternatives when it comes to using frameworks to help you with implementing dependency injection. I found the Java community likes the Guice framework from google for this purpose. If you have some time, you can try this.

Tuesday, February 2, 2010

A few object oriented principles that you might enjoy reading about

This principles are most often called SOLID principles taking the acronym from the following five:

  1. Single responsibility principle.
  2. Open-closed principle.
  3. Liskov's substitution principle.
  4. Interface segregation principle.
  5. Dependency inversion principle.
Correction: Just fixed the wrong hyperlink at the Single Responsibility Principle.

Monday, February 1, 2010

Review topics

We will review the following in particular when developing our projects (and of course in marking!)
Naming
  1. Packages
  2. Files
  3. Classes
  4. Methods
  5. Variables
  6. Interfaces
Design
  1. Object orientation (Encapsulation, Inheritance, Polymorphism)
  2. Use of Interfaces and
  3. Use of Abstract classes
Testing
  1. Acceptance tests
  2. Unit tests
Coding
  1. Use of private methods
  2. Comments
  3. Readability