[Buffalo-pm] meeting topics

DANIEL MAGNUSZEWSKI dmagnuszewski at mandtbank.com
Thu Feb 23 13:04:08 PST 2006


>>> "keith tarbell" <ikeith at earthlink.net> 02/23/06 1:21 PM >>>

>>> Clearly, to bring in new people you will need to offer more basic
material (as has already been noted), 
>>> more so than would be of interest to the 'core' members.  

This is something that we have pondered for a while - how to have
meetings with people of diverse backgrounds and skill levels, yet keep
all of them interested. Essentially what we decided on is our current
format. The format includes any Perl topic that someone wants to present
(a module, a cool use of Perl, practical uses, best practices, etc), and
we will also present on a topic that is an essential base level skill
that all Perl programmers would use. Our last two meetings have included
these (last month we did map and grep functions, and this month we
discussed running external programs from Perl scripts). So I think we
are executing the plan pretty well.

>>> The other problem is the need to stay up-to date on other topics,
with so little time to do it.  Perhaps the 
>>> basic topics could not be limited to pure-Perl subjects but could
include some that address Perl's role in  
>>> other areas. The Bioinformatics talk is a good example (the speaker
admitted to saying very little about 
>>> Perl).  

We are open to any talks that relate to Perl. It's really just a matter
of people suggesting topics and finding people who can present on those
topics. If someone wants to hear something on a subject that somehow
involves Perl, then send a request to the list and we'll do what we can
to present on it. It's really just a matter of who volunteers to give a
talk. I totally agree that its good to have a wide range of topics that
span from very technical (how to write efficient regular expressions) to
high level (Perl is useful in this industry because of X, Y, and Z) -
it's just a matter of getting requests for those topics and those
speakers. 

>>> The recent Prolog/Perl talk as well, but, for example, we could
have seen more about Prolog and 
>>> then a basic treatment of Perl's role (e.g. does it replace or
augment).  

I thought I gave a good amount of high level information on logic
programming, Prolog, some of its uses, and how Perl can interact with or
use Prolog. The main point that I tried to make was how Perl and Prolog
are different types of programming languages. They can't necessarily
replace each other, but using the AI::Prolog module allowed you to use
(augment) the functionality of Perl to include logic programming. Were
you at the meeting or were you just looking over the slides (sorry for
the bad memory if you were at the meeting)? There may of been some
things that I mentioned or were discussed that are not on the slides -
the audio will be out soon :-)

>>> I'm using the Asterisk platform (PBX) on a project in
telecommunications.  Can anyone talk about Perl's 
>>> role in that area?  

The Toronto Perl Mongers have ;-)

http://to.pm.org/#052807
Slide:
http://ham.zonzorp.net:8080/tpm/slides/2005_07/Perl_and_Asterisk_v0.2.3.pdf
Audio: http://ham.zonzorp.net:8080/tpm/TPM_2005_07-Asterisk.mp3

...we can do something on this if anyone has the available hardware for
us to play with.

>>> Maybe most of us have some programing experience/expertise, but not
specifically in 
>>> Perl.  We can get that from other means, but the talks can perhaps
provide some insight for the basic 
>>> paradigms of Perl.  What are the classic applications, where does
it 'fit' best?  Can I use it for scientific 
>>> analysis or machine-control?  Or is it best only as a
text-processing tool?  Can Perl help with RSS, IM or 
>>> podcasting (or whatever new way someone has thought of burning
bandwidth)? (Rhetorical questions, 
>>> of course, until someone comes up with a talk.) 

Those are good topics for presentations (I'll add them to the list).

>>> Ok the other thing is scheduling.  Too much basic stuff and you'll
lose the interest of the more  
>>> experienced members.  How about alternating  meetings (or every
third) for a basic topic?  This seems 
>>> more workable than splitting a single meeting into a basic and
advanced topic, where more time may be 
>>> needed by one or the other and sticking to the split would
short-change both.

Like I said before, just because someone is not one of the more
advanced/fluent persons with Perl, seeing some of the "higher level"
talks can be good, even if 75% of it is going over their head. Its
exposing them to various things that Perl *can* do. Maybe they won't
remember exactly how to code or set something up, but they will say
"aha! I *know* that can be done in Perl!", at which point you can check
the slides from the presentation or ask a question to the list. Also,
when you get to the point of understanding more advanced topics, you can
think back and maybe some of the stuff that we were going over will make
sense. Like they say in a certain Computer Science department - "We're
not teaching you how to do X, we're teaching you the concepts". For this
reason, I think our current setup is beneficial to people that are new
to Perl. I may be wrong though. If there is a want for an "Intro To
Perl" meeting, then I'm sure we can get some volunteers to do a separate
meeting - I know that I would be able to volunteer some time.

One thing I'd like to do is add a "Learn Perl" section to the website.
I'd like it to be a kwiki where experienced members can go and give
examples, tutorials, and links to different introductory Perl topics.
Then new Perl users can have this as a teaching guide and a reference.

>>> One more thing,  how about meeting on campus for coffee before the
talk (say at 7, if the meeting will 
>>> start at 8 now)?  An opportunity to pre-discuss the topic
(formulate questions), network a bit (in the job 
>>> sense), or just shoot the breeze

Not a bad idea. We already do this in a way - although it's
unintentional. We generally start talking as we are waiting for the
talks to start, and there are always questions/discussions (both related
and unrelated to the evenings presentations) after the meeting is over.
We generally do social meetings a few times per year. The social
meetings are where we talk/network for a few hours (usually) without an
agenda. Perhaps we can do a social meeting every other month in addition
to the technical meetings (the meetings are starting to add up ;-)?

>>> ("yeah, I used Perl to analyze the Bills stats ....").

I actually did a lightning talk, a little over a year ago, on this
subject for a fantasy football program - which is still only 80%
complete :-(

Thoughts?

-Dan




More information about the Buffalo-pm mailing list