|
|
|
|
News - Articles/Tutorials/Code/Reviews - JSP/Servlet Hosting Companies - Links |
|
http://www.JspInsider.com/ .
***** IN THIS ISSUE **************************************************
News
1:Leaders Emerge In Java Server Market
2:Microsoft brewing Java-like language
3:Know your Beans
4:New Java tool WebCream released.
Rambles
1: Getting involved in an open source project.
Links
1:JSP Architectures
2:Using JavaScript's OO Capabilities for Advanced Client-Side Validation
3:Consistency with JSP
4:Open Source Java Code
5:Java IDEs: What people are saying about each one.
Main Topic:
Testing your JSP Web Application.
**********************************************************************
===========================================
THE LATEST NEWS
===========================================
1) Leaders Emerge In Java Server Market (June 22, 2000)
It appears that IBM and BEA Systems have roughly 24% of the
Java Server market now and they both are here to stay. The battle still
rages to see who will hold the number three slot. Smaller vendors are
shuffling to find specialized niches.
2) Microsoft brewing Java-like language(June 22, 2000)
Microsoft is releasing C# sometime next week. C# will have features
similar to most of the popular features of the Java platform.
3) Know your Beans (June 19, 2000 )
Knowing Java is just plain good for your pocketbook. Programmers who
are skilled at Enterprise Java Beans are in especially high demand.
The Gartner Group predicts in roughly 5 years time. Java will as
common as COBOL.
4) WebCream released.
WebCream is a Java tool, which automates the web-enabling for GUI based
Java applications and applets. Basically you can take any applet
or Java frame and convert it to HTML on the fly. There didn't seem to be
any JSP or Servlet support in the tool.
===========================================
Rambles
===========================================
1) Getting involved in an open source project.
Open source software is becoming one of the wonders of our times. When
apache can achieve 60% market share as a open source software, that's
amazing. Using the open source model, some great programs have been
developed by taking advantage of the collective talents of many
programmers. In Java and JSP there are several such projects aimed at
the greater good for the developing community. In addition many of these
projects are actively looking for people to help. For example :
All interested developers are welcome to join and participate in the
Jakarta project
Jcorporate has several projects where they are actively
seeking people to help them produce various open source projects.
The Esperanto group is looking for people to help write a JSP Book.
(Ok, not open source software, but it is a group effort for JSP)
Over the past week alone, JspInsider has seen 5 projects where there
was room for people to join. Now, we are not saying every open source project
is looking for help, but there are projects which can use help. This as an
idea for people currently trying to figure out how to use their Java and
JSP skills. Its a great learning opportunity, it gets you visibility and
it's fun. OK, we might be strange saying it's fun, but having just
started an open source project (JspKit) we can say it has been a great experience.
==========================================
Links of Interest
==========================================
[article] (No official date) (Author: Lance Lavandowska)
JSP Architectures
Lance Lavandowska writes a description of the "Model I" and
"Model II" style of JSP Development. He includes several examples of how
each model can be implemented by using a simple page displaying a time zone.
[article] (Mar 28, 2000) (Author: Luke Boucher)
Using JavaScript's OO Capabilities for Advanced Client-Side Validation
Instead of using negative feedback, telling a user they have entered
wrong data, Luke concentrates on rewriting the user's entry in some
pre-defined format to show that the value has been understood. He has
put together an excellent example which really shows the strength of
JavaScript with step by step details for you to follow.
[article] (July, 2000)(Author: Al Williams)
Consistency with JSP
Al talks about JSP on a high level describing why JSP is an great web
development tool. He then shows a simple example page, which builds web
pages from content stored in another text page.
[Site]
Open Source Java Code
Interested in finding out more about open source Java software?
Open Source Java is a web ring dedicated to Java software.
On it are links to over a hundred sites with information on java open
source code, or which are actively building open source Java projects.
[Discussion]
Java IDEs: What people are saying about each one.
Over the past month we used 5 Java IDE's. We still haven't settled on any
single Java IDE. Check out this lively discussion
to see what other people are saying about the various IDE's .
==========================================
MAIN TOPIC by Casey Kochmer
==========================================
1) Testing your JSP Web Application.
One of my pet peeves is poor testing of released web sites. I can no longer
count how many times I have gotten a message box popping up, asking if
I want to debug a web site when it errors. (Developers on Internet
Information Server: PLEASE turn OFF the remote debugging on your production
site!) Anyway this not acceptable. A web site reflects upon you as a
programmer and a bug isn't a nice reflection to see in the morning. It's
not very hard to set up a simple testing schedule. You don't need large
numbers of users. From my experience you need 3 to 6 user testers to perform
an adequate testing job. The secret to using 3 to 6 testers are the
following:
* Don't only test once. You should test many times. On average for my web
site, I go through 4 testing cycles.
* Set up the first test 2/3rds of the way through your development. If your
first test is after all the development is done, it's too late. You want a
test about 2/3 of the way in the project. This is late enough in the project
to actually have enough screens finished to actually test, but early enough
to correct any major issues found.
* You want 75% of your testers to be actual users.
* Your remaining testers should be a programmer or technical person not part
of the actual programming staff of the project. This should be a person to
which you have easy access to. Being outside the project this person will
have insights when you are stuck and will test your web site differently
from people living the project.
* Find the user who has the least skill using computers. This person will
quickly become your best tester (9 times out of 10). This will be the user
who breaks your system once it goes into production so you might as well get
them involved earlier.
* (optional) Find the user who will grumble the most when the system goes
into production. By getting this user involved in your testing phase,
he/she will gain a sense of ownership of the final product and will
quickly become one of the systems greatest allies. Also initially this
person will find the most bugs since they usually have a personal reason
for wanting to find bugs. Motivated testers are always good testers no
matter what the reason for the motivation.
* Make sure your testers understand they are testing. They are not
designing a system! Many time testers are users who want to slip in
undocumented system features. If you add these features they can
introduce new bugs. Instead, document all requested changes and save
them for the next version of the web site! This offers the best solution.
* Make sure your testers are armed with pen and paper. Have them write
everything down. Have them write down suggestions for upcoming releases.
Have them print screens for any error. Have them write down what they
were doing when the bug happened. Never, never, never rely on memory for
bugs. Then when you fix the bug, have the same tester who found the bug
confirm the bug is really gone.
This rule should also be followed by all the programmers.
These are my basic rules of testing. There are others, but this forms my
core. While many of these are common sense, it's amazing how many times no
testing is performed, or the only testers are the people programming the
site. When this happens you will have a high chance of failure in addition
to plenty of uncaptured bugs.
Testing is often dropped due to tight schedules. This is a poor
reason to drop testing. Adding 3-6 user testers actually helps to free up
your programmers to concentrate their time on coding and not testing.
The secret in really tight projects is to merge testing into other
portions of the project. In several projects, I have combined the training
and pilot portions with testing. If you do this, make sure your users
understand this is happening. When the users know training and bug spotting
has been combined then they take a vested interest in finding bugs since
it helps them get a better product. Otherwise, any bug found just gives
your user a lower confidence in your product before final implementation.
Usually testing is dropped due to cost. But if this happens you
must ask yourself which is costlier: a failed site or testing? Ironically,
when done correctly testing isn't that costly. This is due to the fact you
only need a minimal testing crew (3 to 6 users). In addition, when examined
in the light that testing produces a more stable product that needs less
work over the long term, costs are actually reduced over a long term.
I have found testing provides the most critical link between the users and
the programmers. Getting a small user set involved usually both guarantees
the users will feel ownership of the web site once it's published and the
users will enjoy using your web site. This also gives the programmers a
chance to really know the users for whom they are making the site
and helps the programmers polish what they make to a greater degree.
Finally it makes sure your site has a minimal number of bugs.
Check out: The Alertbox by Jakob Nielsen.
He has a very good article called "Why You Only Need to Test With 5 Users"
Browse all of the JSP Insider source-code.
Questions or comments? Contact support@jspinsider.com.
Copyright © 2002 Amberjack Software LLC.