Grant Rettke made this suggestion on the "FW: [MLUG] JRuby/Rails
webinar" topic: "Mason if you start the group again; then call it
'Dynamic Programming Language User Group' so that more people will
participate."
That idea has a lot of appeal to me, with modifications: the proposed
group rules out Scala, so I'd like to think of some other names, and I
wouldn't necessarily want to replace the MilwaukeeRuby group. It may
find its legs again.
So, here are some ideas for group names for a new Milwaukee umbrella
group for developers who want to learn about, try, and advance their use
of any programming language, "new" or "old".
Milwaukee Programming Language Enthusiasts
Milwaukee Programming Language Users Group
Milwaukee Bit Abstractors
It seems there are pros and cons of having a focus that is too general
or too specific. One way to temper that is ... [see P.S. below]
We could always have sub-groups or affiliated groups for specific
language types (dynamic, functional, OO), specific application types
(web), or other interests that sub-divide the larger group but that can
also still connect and feed back to the group.
Are you aware of existing groups that fulfill this role around Milwaukee?
P.S.
we could have members list their interests in a profile and use a
"probabilistic voting method" to pick meeting topics: 1 vote per member
per language, but members may vote for more than one language.
As an example, if the group's 10 members express their interests as 6
votes for Ruby, 3 for Clojure, 2 for Groovy, 4 for Python, 1 for Fan, 2
for Erlang, then these can be normalized (divide by total votes cast) to
create the following distribution: Ruby 33%, Clojure 17%, Groovy 11%,
Python 22%, Fan 6%, Erlang 11%.
So, 33% of the time the group will discuss Ruby, 17% of topics will
involve Clojure, etc.
We could also use this method (or geographical center of gravity?) to
choose meeting locations that spread the inconvenience of travel fairly.
-- Original Message --
I'll show up. I'd like to revive the group, too.
We could always do pair programming, if we run out of topics.
Some potential topics
- the new Rails 3.0 modular architecture and selected commits from Yehuda
- examine/contribute to the code for a project at
http://www.opensourcerails.com/
- alternatives to the modules Rails selects by convention for
object-database mapping (ActiveRecord) and other subsystems
- Ryan Singer's design and development flow (google for recent talks)
- alternatives to Rails for Ruby web frameworks
- Ruby test frameworks and testing philosophies / theory
- Databases with alternate paradigms (key-value pair, graph)
- Metaprogramming
- Refactoring: Ruby Edition (new book with Martin Foster)
- Design Patterns for Ruby
Tom Calloway
email *at* tomcalloway *dot* com
So as not to exclude anyone, "Milwaukee Programmers Club" would
probably do the trick.
> It seems there are pros and cons of having a focus that is too general
> or too specific. One way to temper that is ... [see P.S. below]
If you can find 12 people who are really passionate about what they
do/study/practice and they are all willing to present then you will
have a pretty fun group.
> Are you aware of existing groups that fulfill this role around Milwaukee?
No, none.
The Geek Book Club http://geekbookclub.org/ talks about interesting
stuff every two weeks, but it isn't set up like a user group that
meets monthly.
> we could have members list their interests in a profile and use a
> "probabilistic voting method" to pick meeting topics: 1 vote per member
> per language, but members may vote for more than one language.
The major problem to be solved is finding presenters. Without that the
group will expire quickly.
> I'll show up. I'd like to revive the group, too.
>
> We could always do pair programming, if we run out of topics.
>
> Some potential topics
>
> - the new Rails 3.0 modular architecture and selected commits
> from Yehuda
> - examine/contribute to the code for a project at
> http://www.opensourcerails.com/
> - alternatives to the modules Rails selects by convention for
> object-database mapping (ActiveRecord) and other subsystems
> - Ryan Singer's design and development flow (google for recent
> talks)
> - alternatives to Rails for Ruby web frameworks
> - Ruby test frameworks and testing philosophies / theory
> - Databases with alternate paradigms (key-value pair, graph)
> - Metaprogramming
> - Refactoring: Ruby Edition (new book with Martin Foster)
> - Design Patterns for Ruby
I've discussed the idea couple of times about restarting this group,
and James and I had decided BarCamp would have been the right venue
to relaunch it at Bucketworks, but then came the floods. So when
Bucketworks finds its new home, I'm still onboard for restarting it,
if there's room in the schedule. The tentative thought was something
like 4th Thursday of each month. There's a lot of web/computer stuff
at BW earlier in the month, so making it later, while it risks
holidays, adds some god variety.
We could also cast about for something local we could contribute to,
as well.
Have Fun,
Arlen
------------------------------
In God we trust, all others must supply data