Study groups: <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office"
After attending (2)
AJUG meeting and observing the enthusiasm of group, I though would throw
this out and see what came back. AJUG attendees seem to come from a wide
range of shop sizes from the very small (5-10) to the very large. There
also seems be a large technical breath and understating of specific technical
areas.The AJUG meetings are a great
way to introduce new topics and generate enthusiasm.However,
if a topic is new to an attendee or if they want to take the topic to the
new level and beyond, the attendee is left to their own resources.Traditional
methods of exchange such as mailing lists are useful tools for digging
deeper into topics but can be slow, especially if the topic a new technology
or API for example.
Based on the sheer
number of APIs and the complexity of new technologies like JINI.I
wonder if there would be an interest from AJUG attendees in forming API
Study Groups.Here are some thoughts
- (please respond edit or just delete this part).
1) Study Groups seem
to work best when they are between (3) and (6) attendees.
2) Study Groups work
best when they meet often. (Each week for example).
3) Study Groups would
offer a way from people with busy schedules to structure their study time.
4) Study Groups offer
a more in-depth understanding of a topic in less time that an individual
can cover by their self.
5) Study Groups between
(3) and (6) would create a tighter AJUG community simply because, with
a small break out meeting frequently people will get to know one another
and there interests.
6) Study Groups need
to be relatively informal, they can simply meet at Starbucks in a central
location every Monday (whenever) at some time.
API's are evolving
rapidly and the vendor landscape is constantly changing.To
be successful you not only need to be creative and technically proficient,
you must also strategically use your study time.It's
a lot to juggle but based on what I have seen at AJUG with a little social
engineering it's manageable.
Currently I am tackling
JMX and approaching it as a framework to integrate small applications that
are littered across our organization.The
applications are mainly feeder apps that do dirty work such as parsing
spool files from legacy systems and feeding the results to a database used
for executive management interfaces. The time, locations of source files
and other variables change frequently and therefore need to be played with
on occasion. JMX is a great topic one that I wish I could explore with
others, with other approaches.
Please let me hear
One last ramble:
times are tight in all organizations, training when you can get is more
often times that not a vacation.Why
not take the shared enthusiasm and desire to become more skillful, structure
a plan and see where we end up.In
the end it will be cheaper and you just might get something for nothing