I have been an avid Java developer and advocate for about two and a half years now.
It was sometime in the fall of 1995 that I saw the light that was Java and got sucked
in to it. Today, what seems to be a lifetime later, Java seems to have been responsible
for catalyzing several changes in my life, to the extent that I am now running my own
company founded on the basis of the ideals of Java.
I can look back at this time and reflect upon the learning stages, the stages of
developing real projects in Java what development problems were faced and how those
problems were resolved (or what caused them to not be resolved). In this brief article
I would like to talk about some of these experiences and then propose some ways they
could have been handled if the proper developer resources were available.
The biggest Java development "hurdle" is working within the constraints of
"Internet-Time" It is difficult to share information with other developers who worked
on similar projects. Don't get me wrong here, Java has done things which no other
language/platform has been able to achieve in the past; or at least achieve it to the
same scale. However, imagine how much faster this growth and evolution process would be
if the developers wouldn't have to re-invent the wheel each time? If the developers
could share the tips to avoid the pitfalls which can consume several man-hours?
I think by now some of you should have an idea of where I am going with this, but
let me explain. A few weeks ago I got an email message from the editors of IBM's Java
Web site saying that they wish to make their site more focused on developers needs and
become an invaluable resource for developers. The immediate thing that came to mind
was to set up a site which not only provided "resources" and "information" to the
developers but also enabled "communication between the developer -- " the "sharing
of information" among the developers.
Those of you who remember the book "War Games," will recall the DefCon levels 1-5.
I say let us take Java to DevCon 24.
Sure, there is JavaOne, Java Internet Business Expo, Internet World, and a whole slew
of other conferences. But anyone who is doing real work in Java doesn't have the time
to go off and attend a 3-5 day conference find useful information when all they really
get out of it is a bunch of marketing hype and propaganda from the companies sponsoring
the conference.
DevCon 24 is the Java Developers Conference -- 24 hours a day, seven days a week.
DevCon 24. Not a conference that is going to chew up all your time and get you
nothing in return. But a conference where you do not need to step out of your office.
You only need to attend if the topic under discussion is one that interests you.
You don't have to pay through your nose to actually attend the conference and interact
with the people who are doing some real design and development with Java.
For over a year now my company -
Sneakerlabs -- has been developing frameworks and
tools to enable the development and deployment of collaborative applications over the
Net using pure Java technologies. The technology we have developed allows application
developers to build any application which meets the requirement of having multiple
people in multiple locations communicating with each other in real-time over the net
and sharing information. It is my research in this arena which is the basis for my
DevCon24 proposal.
DevCon24 is the Java developer's online oracle. A place where you can go to find
immediate solutions to find immediate solutions to all of your Java-related problems.
But how is this "oracle" powered? What is the source of information? What really makes
it useful? The key to the omniscient DevCon24 is its ability to bring together
developers in real-time -- to allow developers to communicate with each other in real
time and share information.
For instance, let's say that it is 4 am. You are trying to make an early deadline
and you run across the infamous modal dialog bug in JDK 1.0.2.
Your choices are the following:
- Stay awake for the rest of the night and try to figure out what the problem is by yourself
- Hope and pray that while you reboot your machine for the millionth time that the little elves inside (did they say that it was Intel inside? Nah....it's the little Elves) will magically fix all the problems you are having.
- You could spend the next 3-4 hours searching the various newsgroups and Web sites out there
- Or, you could simply go to DevCon24 where you can immediately speak with REAL people, describe your problem and have your query answered immediately. Not only that, while you are interacting with the alive and kicking people at the other end of the Net, you could display snippets of your code and point out the sections you are having trouble with. Perhaps someone can actually show you a piece of code which works or a design that can work around the problem you are facing.
Of course this does not rely on the fact that there would be someone at DevCon24 who has dealt with the problem you are having before.
The bottom-line is to create an online environment consisting of "live" and "real" developers. Staffing the environment is of course an issue,
but with the exponential growth in the population of Java developers and with the proper sponsorship and incentives from the companies
wishing to take Java development to the next level, this problem is surmountable.
One thing we developers all have in common is the wish and desire for our work to be acknowledged. We revel in instant gratification.
And instant gratification is exactly what DevCon 24 promises to deliver. Instant gratification for a person seeking
the answer to a question and instant gratification for the person answering the question or providing the solution.
The big question remains as to how one goes about developing such an environment. In theory, the interaction in DevCon 24
should be similar to that of a research lab/university where people can pose questions and seek answers freely. The interaction
should be conducted in a spatially and temporally distributed environment -- an environment which surpasses geographical constraints
and allows not only real-time interaction but also the ability to share information over time. The environment must itself be capable
of recording information and creating a knowledge base which learns from the interactions of people over a period of time.
In order to better explain this virtual environment, I would like to introduce some research that was conducted a while ago on
analyzing a traditional classroom interaction and mapping it to a virtual environment. In the subsequent section I will proceed to
build a mapping from this traditional classroom to our virtual learning environment.
Analysis of the Conventional Classroom
This section includes a detailed analysis of the conventional classroom. The conventional classroom includes all activities and
interactions in and out of class which occur within the time span of an academic course.
In Class Activities and Interactions
The course professor, students, and the teaching assistant (TA) all typically participate in each class session.
(Not all courses have separate persons filling the professor and TA roles, but I chose to model the classroom activities with
these roles played by separate individuals.) Each course consists of basically three phases, each with a set of possible
interactions and activities: the pre-class phase, the during-class phase, and the post-class phase. While the first and last
phases are typically ad-hoc and informal in nature, the during-class phase typically has the most structure and formality of the three.
Pre-Class Activities and Interactions
The following are likely to occur prior to the official beginning of a class session:
- students arrive; professor arrives; TA arrives
- distribution of slides, handouts, other class materials to students
- students turn in complete homework or other assignments
Post-Class Activities and Interactions
- distribution of next homework or other assignment
- informal discussions with professor, TA, other classmates
- students ask professor or TA follow-up questions regarding lecture material
During Class Activities and Interactions
The core activity in this section is the presentation of the lecture material by the professor. The two most commonly
used media for this are slides (overhead projector or computer protection) and the blackboard / whiteboard. In general, the
professor shows the slide or writes material on the board and then proceeds to provide more detailed explanations. In a
highly interactive class, the professor may not use slides or a blackboard / whiteboard. Instead s/he may conduct the class
solely by interacting with the students.
Please click on Figure 1. Classroom Information Flows Diagram
for a graphical representation of the information flow between participants during a class session.
This representation models how different participants can interact during a class session.
For example, a professor may ask a question; this question may be open to the entire class,
or directed at a particular student; in either case a student may be selected
to respond; the student may provide an answer that results in a follow-up question, or may
sufficiently answer the question asked. On the other hand, a student may ask a question of the professor,
who in return may respond by answering the question, or reverse the question upon the student by
asking a refined question. In both cases, the questioning process may
proceed iteratively until a suitable conclusion is reached, at which time the
structured lecturing may resume.
There may be additional components found during class sessions. These include, but are not limited to, the following:
- teaching aids: the use of props, audio/video materials, use of the whiteboard/chalkboard in answering questions,
or product demonstrations
- guest-lecturing: the invitation of another professor/lecturer to lead a particular discussion during class
- note taking: students recording personal observations either free-form or by annotating handout materials distributed for the class
- feedback: often professors seek confirmation from students that the material being discussed makes sense, and that the
students have gained some understanding of the subject matter.
Out of Class Activities and Interactions
The following are likely to occur in conventional academic environments, outside of the class session setting:
- interactions with classmates
- interaction with professor/TA: by phone, by email
- tutoring session with professor/TA: appointments between a particular student to receive additional individual instruction
outside of class on the material being taught
- study-group sessions: appointments between students to get together to study the material offered by the course
- self-study: the individual student studying the material offered by the course on their own
- homework/assignments: the individual student working on assignments required for the course
- group project work: assigned teams of students working in cooperation to complete a group assignment required for the course
The Virtual Learning Environment
The above analysis of the traditional classroom and the preceding introduction to what I called "DevCon 24" helps us to put
together a list of requirements for a virtual environment which can help to bring people together (in our case these people are developers)
through a medium which is conducive to collaboration and sharing. A major point to be noted is that the goal of this virtual learning
environment is not to emulate the traditional learning experience. The goal here is to seek ways in which the value derived from a
virtual learning environment can be made to be as close as possible to the value derived from a traditional classroom scenario.
I recognize however that it may not be possible to achieve a 1-1 correspondence between the conventional classroom and the
virtual learning environment. However, the attempt is to maximize the benefits attainable from the distributed classroom.
At the same time, there are some things that may be possible in this new environment that are not possible in the traditi
onal environment. The bottom line is, be skeptical, but keep an open mind.
Though the analogy I drew above is to a traditional classroom, it should be noted that one of the key differences between the
traditional classroom and a distributed classroom is the level of motivation of the students/participants. A distance learning
approach is only effective for those people who are actually interested in learning the issues at hand. This is not a technology
or method (depending on how you look at it) which can be expected to work for students who are not motivated to learn in the first place.
The Java developer population fits into this demographic well. Each developer has a problem they are dealing with and wish
that they could get it resolved as soon as possible.
So now that I have established a goal and an audience for our "environment," let us proceed to actually look at what the
requirements are for DevCon24.
First and foremost, the environment must be easy to use. No one today has the time or patience to learn a whole new working
environment. We want to get in get our answers and get out. The simplicity of use include several sub-factors. Like zero-installation
(no download and install cycles... hint hint.. Java), zero-learning curve, immediate response, immediate access to information.
The environment must encourage healthy collaboration amongst individuals keeping in mind issues regarding respect, privacy,
security, intellectual property issues.
Contributing to the environment must be easy. The key to the success of such a system is that it is not built by any single
entity, but evolved over time. It has to develop a life and entity of its own in order to be truly useful. The effect we wish to
generate is that when a developer runs into a problem, and when the developer wishes to bounce his ideas of off other real
live people, he goes to DevCon 24.
Furthermore, the environment must have a set of etiquette rules and a preset schedule. Though entropy is a natural phenomena,
reducing entropy and bringing order to a system is what allows it to be truly useful.
In the introductory paragraphs I mentioned that the environment must record information and build a knowledge-base which can
provide easy access to the information which has passed through the system during previous interactions. Though, this sounds
like an incredibly complex thing to achieve, it really isn't. All I really mean is that the environment must make it conducive for people
to somehow record the history of their interactions so that they and others may have the chance to retrieve information without it ever
getting lost into never-never land. This requirement comes from one of the Key Process Areas of the Capability Maturity Model
proposed by the Software Engineering Institute at Carnegie Mellon University. But all the academia aside, the essence is to learn
from your mistakes, learn from other people's mistakes as well!
The somewhat sketchy requirements (more on the lines of a wish-list) for this virtual learning environment would lead most tech-heads
to think that I am talking about developing something of great technical complexity. Maybe even close to HAL. To all those who tread
down that path... I request you to please come back down to earth and drink some coffee ... after all we are talking about Java!
The key to this DevCon24 is the people not the technology. I have personally looked at this problem in great detail and also worked
on it through my company. And what we have found is that developing such an environment is really a question of putting together a
few simple pieces of technology which already exist. In fact we have gone to the extent of analyzing the interactions in most collaborative
discussions and isolating the lowest common denominator primitives which must exist to hold a spatially and
temporally distributed collaborative session. And we have packaged these primitives into our Collaboration API's which
allow the development of applications that form the pieces of the environment I have described above.
Our work in this area started originally in the field of online virtual meetings and distance learning classes. And as a developer/architect
working on designing systems for such use, it also seems to me to be the ideal "resource" for other developers/architects to meet and
share their information and experiences and learn from each other.
A full analysis of the results from our work in this area would be beyond the scope of this article and may also reveal information
that is confidential to our work at SneakerLabs. However, I would encourage developers who are interested in this issue or have
comments on the issue to email me directly at sneaker@sneakerlabs.com
to continue this discussion off-line.