“Top 19″ best practices for J2EE

The list of the best of the best Java EE practices can be found at IBM web site:

1. Always use MVC.
2. Don’t reinvent the wheel.
3. Apply automated unit tests and test harnesses at every layer.
4. Develop to the specifications, not the application server.
5. Plan for using Java EE security from Day One.
6. Build what you know.
7. Always use session facades whenever you use EJB components.
8. Use stateless session beans instead of stateful session beans.
9. Use container-managed transactions.
10. Prefer JSPs as your first choice of presentation technology.
11. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
12. Take advantage of application server features that do not require your code to be modified.
13. Play nice within existing environments.
14. Embrace the qualities of service provided by the application server environment.
15. Embrace Java EE, don’t fake it.
16. Plan for version updates.
17. At all points of interest in your code, log your program state using a standard logging framework.
18. Always clean up after yourself.
19. Follow rigorous procedures for development and testing.

Study tips

In my opinion, there is no set timeframe like months or days to prepare for Java Certification. It depends entirely on how you want to approach the whole subject. If you are well versed with Java language it might take you little effort to prepare for the Java Certification or else if you are new to Java the efforts can double. The objective for passing the certification is totally different then objective for learning Java language. There are certain Java topics which are not covered in the certification objectives like Swing, EJB, Servlets, JDBC just to name few. When I started learning Java language I realized that it is kind of cumulative language, which means the new concepts are added to and build upon previous concepts. It is very important that the early material be mastered thoroughly. So.... do some initial homework, see where you stand in terms of your Java expertise and approach this issue accordingly.

Tips:
(1) Before you think of appearing for the certification, make sure that you are aware of Java language concepts, syntax and object oriented concepts. Lay special emphasis on the certification objectives. This will give you some directions as to what Sun(TM) is expecting from you for getting certified.

(2) Do some initial investment and buy a good Java book. I bought Ivar Hortan's Beginning Java 2.

Carefully read over the sections and look carefully at the sample problems. (One nice aspect of this book is that the author uses real life scenarios to explain Java concepts) .If you go to a school which teach Java or have joined a Java course, then decide if you benefit more by reading before or after the instructor covers the material. If you know which skill areas are the weakest, you can then work to improve yourself in those areas, and you'll have a far better chance to reach your full potential for higher scores.

(3) There is simply no excuse for this.. write lots of code. As you start developing code, you won't necessarily get it right the first time, but you can improve as you find more about the underlying details. You will realize the importance of this when you go in the examination hall and see the code intensive questions in the new SCJP format. Writing and executing code will fine tune your theoretical concepts and get rid of any ambiguities. Questions in the certification often test you on 'compile time error' and 'run time error' in the code and you are expected to know the difference between the two types of errors, which will not come to you unless and until you have made an conscious effort to write and compile the code.


(4) Start making notes on piece of paper. Every time you find a concept which relates to the certification objective, jot it down. Put together all the notes pertaining to a topic in same folder in one place, so that you can refer to them at the appropriate time.


(5) Identify your scoring topics. These are some of the topics where you stand a good chance of scoring 95% - 100%. Concentrate more on these.

(6) Once you are confident that your level of comfort with Java language is fairly good, start taking the mock exams. You may have to do the exams test for more than once. Try to get score over 90% in this mock exams. The questions that are in the real exam can be a lot trickier than those you solve in mock exams. One area which can be tricky is declarations and access control, Operators and assignments. In case of multiple choice questions, you can go thru the possible answers real quick and eliminate the wrong ones which seem obvious. This is the most difficult exercise, but once you crack it (by practice) you can get the answer fairly quickly.

It is very very important that you continually review and practice the java concepts you already know and the new concept you acquire in the process of learning. Best way to do so is visit a Java forums on the web. Try to answer the questions raised by the fellow programmers. I have listed some forums here on my website.

(7) Week before the exam collect all your notes which you have filed in Step (4) and start breaking them into one liners, just the gist. This way you have only the important points and concepts in hand. Use this material one final time one day before the exam and keep it in safe place.

(8) Take a good night sleep before the exam day and appear with fresh mind.

(9) When you approach a question try to understand why has the question come in the examination, what is that 'they' want to test by posing this question. In the real exam the questions are worded clearly and without any ambiguity (no tricky questions) , so spend some time reading them.

(10) Haste will only makes waste!!. Rushing thru the questions and trying to complete the test will not improve your test score.

(11) One very counter productive approach is to time your questions. You will end up spending more time looking at your watch and less time concentrating on the questions. You may want to get to the "easier" questions first and then revisit the remaining ones.

(12) Never get frustrated or discouraged by unfamiliar or "hard" questions which come can come in the beginning. Just keep concentrating and working on the remaining ones.

(13) Not failure but low aim is a crime....

My Web Application Development Process

The First Step - Analysis and Planning

The planning stage is where you meet with the client and get t know exactly what they need. If they have an existing system in place — either a paper-based system, existing web-based or desktop system, have then run through their typical daily tasks and show you exactly what they do, and why they do it. The point here is not to start making recommendations but to get really inside their current system and get a complete understanding of how the system helps them. Almost assume you’re being trained for their job and have to do each of the tasks that they’re doing and why they’re doing it so you can start thinking about the system from their perspective.
You might be thinking that a lot of clients don’t currently have anything in place, but I’ve had clients to wrote down all their service calls on paper and then wrote them on a big white board before I worked with them. That was their system, and that’s the first place we started. The goal of any web-based application is to improve employee work flow, and subsequently increase productivity. Otherwise, it’s hard to make a business case to the client to spend thousands of dollars on your custom software.

Once you have a clear understanding of their business and how their existing system works you can start planning and making recommendations for improvements to the system. Start brainstorming with the client and ask them what immediately comes to their mind in an effort to start improving their current work flow. Here is where the documentation starts as well. Start off with a functional specification of the system that clearly outlines, in a high-level description, what the proposed system will do and how it will improve efficiencies and productivity. This does a couple things: it helps define the exact scope of the project at the start to help reduce any scope creep and change requests throughout the project, and also helps you define the project to include in your contract or service agreement.
A Note on Documentation:You might be thinking to yourself, that it sounds like a lot of documentation, and a lot to do up front. However, I’ve found that it is quite rare for a client to truly understand themselves what they want in a system when it is being developed, and the more discussion, brainstorming, and documentation you put in place it helps develop further discussion on the system, and finalize on a complete and accurate system spec. The more details you include in your up front documentation, the less questions and changes you’ll have down the road. For large complex systems, a lack of documentation and planning can mean stalled projects, delays in delivery (and payment), and unhappy clients due to confusion about the project.

Interface Design

Yes, the interface is the second step. Part of the planning should include how the client wants the interface to work. This is arguably the most important aspect of the development project, since the interface will effectively determine whether the application is a success or not. Keeping the users of the system happy is the single most powerful tool in turning a web application client into a long-term business relationship. If the users are constantly complaining to their boss about how difficult it is to use, then you’re going to have more minor fixes, and headaches than you’ll want.

They won’t have a clue about the technical underpinnings of the system like how the database is setup or structured, or whether you’ve coded it well or not. Although database and coding is equally important to the interface on your end, the clients really could care less.

During the interface design, you need to design every single screen from the login, to the user’s dashboard, reports, and forms. Each and every module should be clearly defined including mock error messages and notices. The reason for doing this separately before the actual programming is that you won’t be in a programming state of mind while designing the system. If you do all your mock ups in Photoshop or Fireworks you’re not thinking about how you’ll code the HTML or structure the database - you’re solely thinking about how the system works. If you do leave these elements out, while you’re programming it, you won’t give them the required time and attention and the entire application will suffer.

This also gives your user a way of seeing what the application will look like and give you very important feedback. You don’t want to have to re-work the interface once you’ve already coded it. That can be a huge hassle, and changing it at this step is simple.

As I’m drawing up mockups, I like to label them with their proposed URL structure. Rather than trying to set this up in the development stage, start thinking about it here. Label each of your screens as domain.com/app/module/function ex: domain.com/app/calendar/view and domain.com/app/calendar/edit/434. It doesn’t mean you need to split these functions into different actual web pages - through the use of mod_rewrite you can create some great-looking URLs.

Database Design

Now we can begin the database structure. Look at the proposed screens for the application and start grouping fields, entities, and the data you’ll be storing and create some high-level Entity-Relationship Diagrams or ERDs. Then get more detailed and create a complete database structure including the relationships between each table. I like to reduce to Third Normal Form (3NF), but you can go deeper if you want. You’ll find that this step is quite easy now that you’ve already done the interface design, as well, from doing the interface design, you’ll also have the fields and other data clearly outlined so you won’t have as many surprise changes to the structure of the data. You probably don’t want to show this document to the client as they most likely won’t understand it.

Class and Application Structure

At this point I like to start outlining any classes and data objects I’ll need in the system. Object-oriented programming (OOP) is always the way to go, especially in large, complex web applications since you’ll be maintaining the system for some time as well. The goal is to have as much code reuse as possible, and to come up with a logical set of programming objects to reduce the complexity of programming the system as well as the maintenance.

This doesn’t mean just coming up with standard database connection objects, and other standards libraries, you want to look at objects specific to functions of the application. For example, if the system includes an inventory module, you want to create one or more inventory objects so if you need to use an edit form in multiple places within your application you don’t need to cut and paste code, its a simple function call.

Directory Structure

Now I start planning my directory structure. I like to group my directories in a similar manner as the applications function, and I keep my images, javascripts, css, etc grouped as well. Here’s a sample:
• .htaccess
• /images
• /javascript
• /css
• /conf
• /includes
• /class
• /modules
• /tmp
• /files
o /images
o /documents

I like to have a temp directory for file uploads contained within the web application rather than uploading files to a server’s general temp directory, and I also like to put all uploaded files within the files directory and organize them accordingly witihin. The conf directory holds any configuration files (which will include system options and database connection variables). The modules directory will include folders and the files for each module within the system. Finally, the .htaccess file includes any rewrite rules and server configurations.

Development

Now we can start the development of the site. This consists of converting my mockups to HTML/CSS and getting the templates uploaded, then building the database and finally connecting the HTML templates to the database with code. I always work off my local file server and then do periodic uploads of the system to a web server where the client can play around with it while I’m developing off my own internal server. This way they can look at the system and do some testing while I’m developing. It also keeps them in the loop during the entire development process to ensure that you don’t go off track on the system.

Also, ensure that you have some sort of backup in place for your system while it’s in development. This is critical for the obvious reason that you don’t want to lose it and have to start over, but you’ll often mess something up and want to start over from the beginning of the day or earlier. In fact, setting up some sort of version control system like CVS or Subversion is your best bet, I recommend Subersion.

Quality Assurance and Testing

You’ll be testing while you develop the site, but you want to put aside some time to try and break your system once you have a working BETA of the application. This means entering invalid data, trying to hack into login forms, etc. Have your clients try the same, as they’ll probably think of entirely different methods of using the system since they haven’t been so close to the development of the system like you have.
During the development phase you should also be putting together a test plan to help test the system. This is where you’ll refine it and then run through your test plan and track any bugs as they are found. I like to track bugs in a spreadsheet using Excel or iWork Numbers.

Launch

Finally, launch the application. You’ll want to give your client a notice that there may be some minor tweaks to work out in the first couple weeks or months of using the system. Just have them track any issues and report back to you for fixing. I typically give them a period of 1 or 2 months where I’ll fix any other bugs they find, but after that point any fixes are billable to the client.

Maintenance

Now that the project is initially complete, you’ll want to setup a maintenance agreement with the client to maintain the system. THis means ongoing support and bug-fixes, web hosting for the system, and regular backups.

Web applications can be a lucrative part of your web development business, they have been for me, and I really enjoy the challenge of planning, designing and implementing the systems. As well from a business point of view, they’re a great source of continual revenue, and also a great way to build stable, long-term clients, which are essential to the long-term plans for your business.