From atrodo at atrodo.org Fri May 8 08:59:07 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Fri, 8 May 2020 11:59:07 -0400 Subject: [Cincinnati-pm] May cinci.pm status Message-ID: Good Morning, Hope everyone is doing well. Because of the current situation, we will be unable to host May's cinci.pm in person next Wednesday. However, I am in the process of investigating if we can instead meet virtually the following Wednesday May 20th. I'm looking for ideas for an activity to do together to see if this idea is viable. Ideally it is something we can do as a group in about an hour. Some starter ideas: work on a CPAN module together to come up with some fixes for it; create a quick web app; play a group game. If you have an idea for a specific module, game or app, please share. If you have another idea, I'd love to hear it. I'll make a decision next week about if we're meeting, but we need your input in order to schedule it. Thank you, and have a good day. -Jon Gentle From Kevin.Ernst at cchmc.org Fri May 8 09:27:41 2020 From: Kevin.Ernst at cchmc.org (Ernst, Kevin) Date: Fri, 8 May 2020 16:27:41 +0000 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: Message-ID: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Hi Jon, Hope you're well. I'm not a professional Perl developer by trade (just professionally-frustrated by Perl on a regular basis is all), so this might seem like a fatuous proposition to everyone else, but what would be immensely helpful for me is to see the process of creating a CPAN module in the first place. I mean all the MakeMaker and the Dist::Zilla and the Makefile.PL stuff that always seemed like eldritch magical incantations to me. I want to love Perl, and CPAN, but I think I don't "get" it, and watching someone proficient in the language and the surrounding toolchain would probably do a lot to ameliorate that situation. ?Kevin On 08.05.20 at 11:59, Jon Gentle wrote: I'm looking for ideas for an activity to do together to see if this idea is viable. Ideally it is something we can do as a group in about an hour. Some starter ideas: work on a CPAN module together to come up with some fixes for it; create a quick web app; play a group game. If you have an idea for a specific module, game or app, please share. If you have another idea, I'd love to hear it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott at ties.org Fri May 8 09:55:26 2020 From: scott at ties.org (Scott R. Corzine) Date: Fri, 8 May 2020 12:55:26 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: Hi Folks, I would echo Kevin and add that I would like to see that and see what is essential, what's a good idea, and the nice but not necessary category. I did the PRC (Pull Request Challenge) years ago and it seemed like a lot of the modules had files for a bunch of different modules/management tools. In a few cases it looked like that control code/files was larger than the actual functional code. It left me uncertain what additional things I would have to learn and do to submit a "proper" CPAN module. -Scott- On Fri, May 8, 2020 at 12:27 PM Ernst, Kevin wrote: > Hi Jon, > > Hope you're well. > > I'm not a professional Perl developer by trade (just > professionally-frustrated by Perl on a regular basis is all), so this might > seem like a fatuous proposition to everyone else, but what would be > immensely helpful for me is to see the process of *creating* a CPAN > module in the first place. > > I mean all the MakeMaker and the Dist::Zilla and the Makefile.PL stuff > that always seemed like eldritch magical incantations to me. > > I *want* to love Perl, and CPAN, but I think I don't "get" it, and > watching someone proficient in the language and the surrounding toolchain > would probably do a lot to ameliorate that situation. > > ?Kevin > > > On 08.05.20 at 11:59, Jon Gentle wrote: > > I'm looking for ideas for an activity to do together to see if this > idea is viable. Ideally it is something we can do as a group in about > an hour. Some starter ideas: work on a CPAN module together to come up > with some fixes for it; create a quick web app; play a group game. If > you have an idea for a specific module, game or app, please share. If > you have another idea, I'd love to hear it. > > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmcgowan9990 at gmail.com Fri May 8 16:49:19 2020 From: cmcgowan9990 at gmail.com (splatt9990 .) Date: Fri, 8 May 2020 19:49:19 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: Sounds good to me. I'm pretty interested in this topic as well. Chris McGowan On Fri, May 8, 2020, 1:10 PM Scott R. Corzine wrote: > Hi Folks, > > I would echo Kevin and add that I would like to see that and see what is > essential, what's a good idea, and the nice but not necessary category. > > I did the PRC (Pull Request Challenge) years ago and it seemed like a lot > of the modules had files for a bunch of different modules/management > tools. In a few cases it looked like that control code/files was larger > than the actual functional code. > > It left me uncertain what additional things I would have to learn and do > to submit a "proper" CPAN module. > > -Scott- > > > On Fri, May 8, 2020 at 12:27 PM Ernst, Kevin > wrote: > >> Hi Jon, >> >> Hope you're well. >> >> I'm not a professional Perl developer by trade (just >> professionally-frustrated by Perl on a regular basis is all), so this might >> seem like a fatuous proposition to everyone else, but what would be >> immensely helpful for me is to see the process of *creating* a CPAN >> module in the first place. >> >> I mean all the MakeMaker and the Dist::Zilla and the Makefile.PL stuff >> that always seemed like eldritch magical incantations to me. >> >> I *want* to love Perl, and CPAN, but I think I don't "get" it, and >> watching someone proficient in the language and the surrounding toolchain >> would probably do a lot to ameliorate that situation. >> >> ?Kevin >> >> >> On 08.05.20 at 11:59, Jon Gentle wrote: >> >> I'm looking for ideas for an activity to do together to see if this >> idea is viable. Ideally it is something we can do as a group in about >> an hour. Some starter ideas: work on a CPAN module together to come up >> with some fixes for it; create a quick web app; play a group game. If >> you have an idea for a specific module, game or app, please share. If >> you have another idea, I'd love to hear it. >> >> _______________________________________________ >> Cincinnati-pm mailing list >> Cincinnati-pm at pm.org >> https://mail.pm.org/mailman/listinfo/cincinnati-pm >> > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atrodo at atrodo.org Fri May 8 20:16:50 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Fri, 8 May 2020 23:16:50 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: On Fri, May 8, 2020 at 7:49 PM splatt9990 . wrote: > > Sounds good to me. I'm pretty interested in this topic as well. > > Chris McGowan > > On Fri, May 8, 2020, 1:10 PM Scott R. Corzine wrote: >> >> Hi Folks, >> >> I would echo Kevin and add that I would like to see that and see what is essential, what's a good idea, and the nice but not necessary category. >> >> I did the PRC (Pull Request Challenge) years ago and it seemed like a lot of the modules had files for a bunch of different modules/management tools. In a few cases it looked like that control code/files was larger than the actual functional code. >> >> It left me uncertain what additional things I would have to learn and do to submit a "proper" CPAN module. >> >> -Scott- >> >> >> On Fri, May 8, 2020 at 12:27 PM Ernst, Kevin wrote: >>> >>> Hi Jon, >>> >>> Hope you're well. >>> >>> I'm not a professional Perl developer by trade (just professionally-frustrated by Perl on a regular basis is all), so this might seem like a fatuous proposition to everyone else, but what would be immensely helpful for me is to see the process of creating a CPAN module in the first place. >>> >>> I mean all the MakeMaker and the Dist::Zilla and the Makefile.PL stuff that always seemed like eldritch magical incantations to me. >>> >>> I want to love Perl, and CPAN, but I think I don't "get" it, and watching someone proficient in the language and the surrounding toolchain would probably do a lot to ameliorate that situation. >>> >>> ?Kevin I think it'd be fun to do a live, collaborative session of creating a CPAN module. I would rather have an idea of what we were writing before we start so we aren't deciding what to write that night; it seems that we could easily spend more time deciding what to write instead of writing. I don't have any ideas off hand so I'm open to suggestions for a simple, usable module idea that we can do. -Jon Gentle From scott at ties.org Fri May 8 21:12:08 2020 From: scott at ties.org (Scott R. Corzine) Date: Sat, 9 May 2020 00:12:08 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: I think what most of us were talking about was all the stuff that goes around a module more than the core of the perl module itself. Jon, it sounds like you're talking about a hackathon style session where we're focused on collaboratively writing the core perl module itself, which is also an idea I like if we can do it in our meeting timeframe (which is a little more flexible when done remotely). Why don't we do both: this month start that collaborative basic perl module and next month do all of the bits and pieces around it needed to turn it into a respectable perl module. If there's interest, we could have a third month session (not necessarily contiguous) where we go into writing tests and setting up the glue for them to run in. Those three wouldn't have to run in consecutive months, it would probably be good to alternate them with other content anyway. But we're always looking for good content and this would take care of a quarter of the year (or half of a half). Thoughts? -Scott- On Fri, May 8, 2020 at 11:17 PM Jon Gentle wrote: > On Fri, May 8, 2020 at 7:49 PM splatt9990 . > wrote: > > > > Sounds good to me. I'm pretty interested in this topic as well. > > > > Chris McGowan > > > > On Fri, May 8, 2020, 1:10 PM Scott R. Corzine wrote: > >> > >> Hi Folks, > >> > >> I would echo Kevin and add that I would like to see that and see what > is essential, what's a good idea, and the nice but not necessary category. > >> > >> I did the PRC (Pull Request Challenge) years ago and it seemed like a > lot of the modules had files for a bunch of different modules/management > tools. In a few cases it looked like that control code/files was larger > than the actual functional code. > >> > >> It left me uncertain what additional things I would have to learn and > do to submit a "proper" CPAN module. > >> > >> -Scott- > >> > >> > >> On Fri, May 8, 2020 at 12:27 PM Ernst, Kevin > wrote: > >>> > >>> Hi Jon, > >>> > >>> Hope you're well. > >>> > >>> I'm not a professional Perl developer by trade (just > professionally-frustrated by Perl on a regular basis is all), so this might > seem like a fatuous proposition to everyone else, but what would be > immensely helpful for me is to see the process of creating a CPAN module in > the first place. > >>> > >>> I mean all the MakeMaker and the Dist::Zilla and the Makefile.PL stuff > that always seemed like eldritch magical incantations to me. > >>> > >>> I want to love Perl, and CPAN, but I think I don't "get" it, and > watching someone proficient in the language and the surrounding toolchain > would probably do a lot to ameliorate that situation. > >>> > >>> ?Kevin > > I think it'd be fun to do a live, collaborative session of creating a > CPAN module. I would rather have an idea of what we were writing > before we start so we aren't deciding what to write that night; it > seems that we could easily spend more time deciding what to write > instead of writing. I don't have any ideas off hand so I'm open to > suggestions for a simple, usable module idea that we can do. > > -Jon Gentle > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wagnerc at plebeian.com Fri May 8 23:03:12 2020 From: wagnerc at plebeian.com (Chris Wagner) Date: Sat, 09 May 2020 02:03:12 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: <6aa68c0a390a2682bb8b143b12d05ec2@plebeian.com> This module should clearly be under Acme::. I would also be amenable to making it a Rube Goldberg. -Chris On 2020-05-08 11:16 pm, Jon Gentle wrote: > I think it'd be fun to do a live, collaborative session of creating a > CPAN module. I would rather have an idea of what we were writing > before we start so we aren't deciding what to write that night; it > seems that we could easily spend more time deciding what to write > instead of writing. I don't have any ideas off hand so I'm open to > suggestions for a simple, usable module idea that we can do. > > -Jon Gentle > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm From Kevin.Ernst at cchmc.org Sat May 9 08:24:38 2020 From: Kevin.Ernst at cchmc.org (Ernst, Kevin) Date: Sat, 9 May 2020 15:24:38 +0000 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <0940f0d1-d15c-f333-32c7-1c3b8ad1089d@cchmc.org> Message-ID: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> On 09.05.20 at 00:12, Scott R. Corzine wrote: > Why don't we do both: this month start that collaborative basic perl > module and next month do all of the bits and pieces?around it needed > to turn it into a respectable perl module. Agreed, this sounds great. Especially the "respectable" part. All I've been able to discern about Perl modules is that there's a 'package' somewhere in the middle, and they have to have '1;' at the end, and that is so just Perl in a nutshell. Look, I'm 50% joking here; I /have/ written Perl modules in a work context. I just never felt like I was doing it right. Maybe I'm just a weak/inexperienced developer who needs the hand-holding, but just seeing how someone who knows what they're /doing/ would structure a module from scratch would still be super-helpful. Even if it's something facile and completely throwaway, like Yet Another Template Processor, or Yet Another Command-line Weather-fetching Client. Where to *put* them on a local system or shared server environment is a whole other question. Like, should they go in /usr/local/perl5/lib/perl5/5.28.1/site_perl, or /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw hell. Where are they /supposed/ to go? Where do I put a module that will just *work* with Perl 5.something? ?Kevin From mike at nrdvana.net Mon May 11 09:47:52 2020 From: mike at nrdvana.net (Michael Conrad) Date: Mon, 11 May 2020 12:47:52 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> Message-ID: <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> If you?re going virtual, I can join! I have a pretty minimal effort sequence I use when creating new modules: * write a package in a lib dir, with a nice pod synopsis and description * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions) * copy dist.ini from a previous project * edit the names in dist.ini to match the new project * check into git (because my dist.ini depends on git) * dzil test * dzil release The effort of getting that first dist.ini is mostly about deciding what workflow you want to use and what workflows Dist::Zilla can support. My prefs are to have dzil rewrite the pod and version of the module before packaging it, and use git tags to track versions, and various other opinions. > On May 9, 2020, at 11:24 AM, Ernst, Kevin wrote: > > ?On 09.05.20 at 00:12, Scott R. Corzine wrote: >> Why don't we do both: this month start that collaborative basic perl >> module and next month do all of the bits and pieces around it needed >> to turn it into a respectable perl module. > > Agreed, this sounds great. Especially the "respectable" part. > > All I've been able to discern about Perl modules is that there's a > 'package' somewhere in the middle, and they have to have '1;' at the > end, and that is so just Perl in a nutshell. > > Look, I'm 50% joking here; I /have/ written Perl modules in a work > context. I just never felt like I was doing it right. Maybe I'm just a > weak/inexperienced developer who needs the hand-holding, but just seeing > how someone who knows what they're /doing/ would structure a module from > scratch would still be super-helpful. > > Even if it's something facile and completely throwaway, like Yet Another > Template Processor, or Yet Another Command-line Weather-fetching Client. > > Where to *put* them on a local system or shared server environment is a > whole other question. Like, should they go in > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw hell. > Where are they /supposed/ to go? Where do I put a module that will just > *work* with Perl 5.something? > > ?Kevin > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm From atrodo at atrodo.org Wed May 13 08:37:07 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Wed, 13 May 2020 11:37:07 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> Message-ID: Good Morning, That is generally the process I use as well, so I'm thinking we can use it as a general flow of how to structure the virtual meeting. I am thinking that we could go through the whole module creation process, from start to finish, as a collaborative effort during this virtual meeting. Creating an Acme module would be great for that, so we can spend our time on the module creation process instead of the code itself. It sounds like answering the question of how do you create a proper perl module has enough interest for us to meet next Wednesday. I'll get that scheduled and let everyone know how to join. Does that sound good to everyone? In the meantime, if anyone has any ideas for a good Acme module to create, I'd love to hear the idea. -Jon Gentle On Mon, May 11, 2020 at 12:54 PM Michael Conrad wrote: > > If you?re going virtual, I can join! > > I have a pretty minimal effort sequence I use when creating new modules: > * write a package in a lib dir, with a nice pod synopsis and description > * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions) > * copy dist.ini from a previous project > * edit the names in dist.ini to match the new project > * check into git (because my dist.ini depends on git) > * dzil test > * dzil release > > The effort of getting that first dist.ini is mostly about deciding what workflow you want to use and what workflows Dist::Zilla can support. My prefs are to have dzil rewrite the pod and version of the module before packaging it, and use git tags to track versions, and various other opinions. > > > On May 9, 2020, at 11:24 AM, Ernst, Kevin wrote: > > > > ?On 09.05.20 at 00:12, Scott R. Corzine wrote: > >> Why don't we do both: this month start that collaborative basic perl > >> module and next month do all of the bits and pieces around it needed > >> to turn it into a respectable perl module. > > > > Agreed, this sounds great. Especially the "respectable" part. > > > > All I've been able to discern about Perl modules is that there's a > > 'package' somewhere in the middle, and they have to have '1;' at the > > end, and that is so just Perl in a nutshell. > > > > Look, I'm 50% joking here; I /have/ written Perl modules in a work > > context. I just never felt like I was doing it right. Maybe I'm just a > > weak/inexperienced developer who needs the hand-holding, but just seeing > > how someone who knows what they're /doing/ would structure a module from > > scratch would still be super-helpful. > > > > Even if it's something facile and completely throwaway, like Yet Another > > Template Processor, or Yet Another Command-line Weather-fetching Client. > > > > Where to *put* them on a local system or shared server environment is a > > whole other question. Like, should they go in > > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or > > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw hell. > > Where are they /supposed/ to go? Where do I put a module that will just > > *work* with Perl 5.something? > > > > ?Kevin > > _______________________________________________ > > Cincinnati-pm mailing list > > Cincinnati-pm at pm.org > > https://mail.pm.org/mailman/listinfo/cincinnati-pm > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm From cmcgowan9990 at gmail.com Wed May 13 15:39:52 2020 From: cmcgowan9990 at gmail.com (splatt9990 .) Date: Wed, 13 May 2020 18:39:52 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> Message-ID: Re: Acme module, how about a python minifier? Guaranteed to make your python code run faster! On Wed, May 13, 2020, 11:37 AM Jon Gentle wrote: > Good Morning, > > That is generally the process I use as well, so I'm thinking we can > use it as a general flow of how to structure the virtual meeting. I am > thinking that we could go through the whole module creation process, > from start to finish, as a collaborative effort during this virtual > meeting. Creating an Acme module would be great for that, so we can > spend our time on the module creation process instead of the code > itself. It sounds like answering the question of how do you create a > proper perl module has enough interest for us to meet next Wednesday. > I'll get that scheduled and let everyone know how to join. > > Does that sound good to everyone? In the meantime, if anyone has any > ideas for a good Acme module to create, I'd love to hear the idea. > > -Jon Gentle > > On Mon, May 11, 2020 at 12:54 PM Michael Conrad wrote: > > > > If you?re going virtual, I can join! > > > > I have a pretty minimal effort sequence I use when creating new modules: > > * write a package in a lib dir, with a nice pod synopsis and > description > > * write a test case in a t dir (maybe just loading the module to > check for syntax erors, or call a few simple functions) > > * copy dist.ini from a previous project > > * edit the names in dist.ini to match the new project > > * check into git (because my dist.ini depends on git) > > * dzil test > > * dzil release > > > > The effort of getting that first dist.ini is mostly about deciding what > workflow you want to use and what workflows Dist::Zilla can support. My > prefs are to have dzil rewrite the pod and version of the module before > packaging it, and use git tags to track versions, and various other > opinions. > > > > > On May 9, 2020, at 11:24 AM, Ernst, Kevin > wrote: > > > > > > ?On 09.05.20 at 00:12, Scott R. Corzine wrote: > > >> Why don't we do both: this month start that collaborative basic perl > > >> module and next month do all of the bits and pieces around it needed > > >> to turn it into a respectable perl module. > > > > > > Agreed, this sounds great. Especially the "respectable" part. > > > > > > All I've been able to discern about Perl modules is that there's a > > > 'package' somewhere in the middle, and they have to have '1;' at the > > > end, and that is so just Perl in a nutshell. > > > > > > Look, I'm 50% joking here; I /have/ written Perl modules in a work > > > context. I just never felt like I was doing it right. Maybe I'm just a > > > weak/inexperienced developer who needs the hand-holding, but just > seeing > > > how someone who knows what they're /doing/ would structure a module > from > > > scratch would still be super-helpful. > > > > > > Even if it's something facile and completely throwaway, like Yet > Another > > > Template Processor, or Yet Another Command-line Weather-fetching > Client. > > > > > > Where to *put* them on a local system or shared server environment is a > > > whole other question. Like, should they go in > > > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or > > > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw > hell. > > > Where are they /supposed/ to go? Where do I put a module that will just > > > *work* with Perl 5.something? > > > > > > ?Kevin > > > _______________________________________________ > > > Cincinnati-pm mailing list > > > Cincinnati-pm at pm.org > > > https://mail.pm.org/mailman/listinfo/cincinnati-pm > > _______________________________________________ > > Cincinnati-pm mailing list > > Cincinnati-pm at pm.org > > https://mail.pm.org/mailman/listinfo/cincinnati-pm > _______________________________________________ > Cincinnati-pm mailing list > Cincinnati-pm at pm.org > https://mail.pm.org/mailman/listinfo/cincinnati-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From atrodo at atrodo.org Tue May 19 20:59:04 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Tue, 19 May 2020 23:59:04 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> Message-ID: Good Evening, I apologize, last week got away from me and I was unable to finish getting this scheduled. Because I felt there was not enough time between announcement and this Wednesday, I have decided to push this virtual cinci.pm to next Wednesday, May 27th. I have decided to use Google Meet for this meeting and have included the link to the meeting below, and have verified that no login is required to join. As discussed in this thread, we will be going over the start-to-finish process of creating a perl module that is able to be uploaded to cpan. I've scheduled the talk to start at 7:00pm, but I will be getting on early if you'd like to chit-chat a little before we get started. I hope to see or hear everyone then. Details: * What: Module from start-to-end * When: Wednesday, May 27th; discussion @ 7:00pm - 8:00pm * Where: Google Meet https://meet.google.com/kcq-qfkz-ars * Meetup: https://www.meetup.com/Cincinnati-Perl-Mongers-Meetup/events/270760043/ On Wed, May 13, 2020 at 11:37 AM Jon Gentle wrote: > > Good Morning, > > That is generally the process I use as well, so I'm thinking we can > use it as a general flow of how to structure the virtual meeting. I am > thinking that we could go through the whole module creation process, > from start to finish, as a collaborative effort during this virtual > meeting. Creating an Acme module would be great for that, so we can > spend our time on the module creation process instead of the code > itself. It sounds like answering the question of how do you create a > proper perl module has enough interest for us to meet next Wednesday. > I'll get that scheduled and let everyone know how to join. > > Does that sound good to everyone? In the meantime, if anyone has any > ideas for a good Acme module to create, I'd love to hear the idea. > > -Jon Gentle > > On Mon, May 11, 2020 at 12:54 PM Michael Conrad wrote: > > > > If you?re going virtual, I can join! > > > > I have a pretty minimal effort sequence I use when creating new modules: > > * write a package in a lib dir, with a nice pod synopsis and description > > * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions) > > * copy dist.ini from a previous project > > * edit the names in dist.ini to match the new project > > * check into git (because my dist.ini depends on git) > > * dzil test > > * dzil release > > > > The effort of getting that first dist.ini is mostly about deciding what workflow you want to use and what workflows Dist::Zilla can support. My prefs are to have dzil rewrite the pod and version of the module before packaging it, and use git tags to track versions, and various other opinions. > > > > > On May 9, 2020, at 11:24 AM, Ernst, Kevin wrote: > > > > > > ?On 09.05.20 at 00:12, Scott R. Corzine wrote: > > >> Why don't we do both: this month start that collaborative basic perl > > >> module and next month do all of the bits and pieces around it needed > > >> to turn it into a respectable perl module. > > > > > > Agreed, this sounds great. Especially the "respectable" part. > > > > > > All I've been able to discern about Perl modules is that there's a > > > 'package' somewhere in the middle, and they have to have '1;' at the > > > end, and that is so just Perl in a nutshell. > > > > > > Look, I'm 50% joking here; I /have/ written Perl modules in a work > > > context. I just never felt like I was doing it right. Maybe I'm just a > > > weak/inexperienced developer who needs the hand-holding, but just seeing > > > how someone who knows what they're /doing/ would structure a module from > > > scratch would still be super-helpful. > > > > > > Even if it's something facile and completely throwaway, like Yet Another > > > Template Processor, or Yet Another Command-line Weather-fetching Client. > > > > > > Where to *put* them on a local system or shared server environment is a > > > whole other question. Like, should they go in > > > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or > > > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw hell. > > > Where are they /supposed/ to go? Where do I put a module that will just > > > *work* with Perl 5.something? > > > > > > ?Kevin > > > _______________________________________________ > > > Cincinnati-pm mailing list > > > Cincinnati-pm at pm.org > > > https://mail.pm.org/mailman/listinfo/cincinnati-pm > > _______________________________________________ > > Cincinnati-pm mailing list > > Cincinnati-pm at pm.org > > https://mail.pm.org/mailman/listinfo/cincinnati-pm From mike at nrdvana.net Thu May 21 18:46:22 2020 From: mike at nrdvana.net (Michael Conrad) Date: Thu, 21 May 2020 21:46:22 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> Message-ID: <7020ad37-5859-e19a-f4f2-1469c9e160e0@nrdvana.net> On 5/19/20 11:59 PM, Jon Gentle wrote: > Good Evening, > > I apologize, last week got away from me and I was unable to finish > getting this scheduled. Because I felt there was not enough time > between announcement and this Wednesday, I have decided to push this > virtual cinci.pm to next Wednesday, May 27th. I have decided to use > Google Meet for this meeting and have included the link to the meeting > below, and have verified that no login is required to join. As > discussed in this thread, we will be going over the start-to-finish > process of creating a perl module that is able to be uploaded to cpan. > I've scheduled the talk to start at 7:00pm, but I will be getting on > early if you'd like to chit-chat a little before we get started. I > hope to see or hear everyone then. > > Details: > * What: Module from start-to-end > * When: Wednesday, May 27th; discussion @ 7:00pm - 8:00pm > * Where: Google Meet https://meet.google.com/kcq-qfkz-ars > * Meetup: https://www.meetup.com/Cincinnati-Perl-Mongers-Meetup/events/270760043/ I had an idea for what module to write.? (related to a project I'm tinkering with, of course) The module "Data::Faker" generates mock data.? It supports an easy plugin system (just add modules to that namespace) and the modules are extremely simple to write.? So, we could just bring lists of mad-lib patterns to the meeting, and construct a module that adds new data types to Data::Faker.? Such as, band names, album names, release dates, fortunes, horoscopes, mission statements, and anything else you can think of. Meanwhile, I am working on a module "Mock::RelationalData" which does a similar thing but on a multi-table relational scale. Data::Faker hasn't been updated since 2013, and has blocking bugs for Win32, so I was considering stealing the template system it uses to essential fork it, and make my own plugin hierarchy, in which case (assuming I finish this weekend) we could write plugins for my module. Sound fun? From atrodo at atrodo.org Fri May 22 17:49:05 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Fri, 22 May 2020 20:49:05 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: <7020ad37-5859-e19a-f4f2-1469c9e160e0@nrdvana.net> Message-ID: Looking quickly at Data::Faker, I think we could make a Data::Faker::Cinci or Mock::RelationalData::Cinci . Anyone have any other thoughts? -Jon Gentle ? Original Message ? From: mike at nrdvana.net Sent: May 21, 2020 9:46 PM To: cincinnati-pm at pm.org Subject: Re: [Cincinnati-pm] May cinci.pm status On 5/19/20 11:59 PM, Jon Gentle wrote: > Good Evening, > > I apologize, last week got away from me and I was unable to finish > getting this scheduled. Because I felt there was not enough time > between announcement and this Wednesday, I have decided to push this > virtual cinci.pm to next Wednesday, May 27th. I have decided to use > Google Meet for this meeting and have included the link to the meeting > below, and have verified that no login is required to join. As > discussed in this thread, we will be going over the start-to-finish > process of creating a perl module that is able to be uploaded to cpan. > I've scheduled the talk to start at 7:00pm, but I will be getting on > early if you'd like to chit-chat a little before we get started. I > hope to see or hear everyone then. > > Details: > * What: Module from start-to-end > * When: Wednesday, May 27th; discussion @ 7:00pm - 8:00pm > * Where: Google Meet https://meet.google.com/kcq-qfkz-ars > * Meetup: https://www.meetup.com/Cincinnati-Perl-Mongers-Meetup/events/270760043/ I had an idea for what module to write.? (related to a project I'm tinkering with, of course) The module "Data::Faker" generates mock data.? It supports an easy plugin system (just add modules to that namespace) and the modules are extremely simple to write.? So, we could just bring lists of mad-lib patterns to the meeting, and construct a module that adds new data types to Data::Faker.? Such as, band names, album names, release dates, fortunes, horoscopes, mission statements, and anything else you can think of. Meanwhile, I am working on a module "Mock::RelationalData" which does a similar thing but on a multi-table relational scale. Data::Faker hasn't been updated since 2013, and has blocking bugs for Win32, so I was considering stealing the template system it uses to essential fork it, and make my own plugin hierarchy, in which case (assuming I finish this weekend) we could write plugins for my module. Sound fun? _______________________________________________ Cincinnati-pm mailing list Cincinnati-pm at pm.org https://mail.pm.org/mailman/listinfo/cincinnati-pm From atrodo at atrodo.org Tue May 26 06:37:38 2020 From: atrodo at atrodo.org (Jon Gentle) Date: Tue, 26 May 2020 09:37:38 -0400 Subject: [Cincinnati-pm] May cinci.pm status In-Reply-To: References: <1533125b-bbc2-85dd-91a2-320afeb01d18@cchmc.org> <93EC23FF-446F-458E-ADDB-8538AC2B0A9E@nrdvana.net> Message-ID: Good Morning, Just as a reminder, we will be meeting tomorrow right, Wednesday May 27th, virtually for Cinci.pm. Hope to see or hear everyone there! -Jon Gentle On Tue, May 19, 2020 at 11:59 PM Jon Gentle wrote: > > Good Evening, > > I apologize, last week got away from me and I was unable to finish > getting this scheduled. Because I felt there was not enough time > between announcement and this Wednesday, I have decided to push this > virtual cinci.pm to next Wednesday, May 27th. I have decided to use > Google Meet for this meeting and have included the link to the meeting > below, and have verified that no login is required to join. As > discussed in this thread, we will be going over the start-to-finish > process of creating a perl module that is able to be uploaded to cpan. > I've scheduled the talk to start at 7:00pm, but I will be getting on > early if you'd like to chit-chat a little before we get started. I > hope to see or hear everyone then. > > Details: > * What: Module from start-to-end > * When: Wednesday, May 27th; discussion @ 7:00pm - 8:00pm > * Where: Google Meet https://meet.google.com/kcq-qfkz-ars > * Meetup: https://www.meetup.com/Cincinnati-Perl-Mongers-Meetup/events/270760043/ > > On Wed, May 13, 2020 at 11:37 AM Jon Gentle wrote: > > > > Good Morning, > > > > That is generally the process I use as well, so I'm thinking we can > > use it as a general flow of how to structure the virtual meeting. I am > > thinking that we could go through the whole module creation process, > > from start to finish, as a collaborative effort during this virtual > > meeting. Creating an Acme module would be great for that, so we can > > spend our time on the module creation process instead of the code > > itself. It sounds like answering the question of how do you create a > > proper perl module has enough interest for us to meet next Wednesday. > > I'll get that scheduled and let everyone know how to join. > > > > Does that sound good to everyone? In the meantime, if anyone has any > > ideas for a good Acme module to create, I'd love to hear the idea. > > > > -Jon Gentle > > > > On Mon, May 11, 2020 at 12:54 PM Michael Conrad wrote: > > > > > > If you?re going virtual, I can join! > > > > > > I have a pretty minimal effort sequence I use when creating new modules: > > > * write a package in a lib dir, with a nice pod synopsis and description > > > * write a test case in a t dir (maybe just loading the module to check for syntax erors, or call a few simple functions) > > > * copy dist.ini from a previous project > > > * edit the names in dist.ini to match the new project > > > * check into git (because my dist.ini depends on git) > > > * dzil test > > > * dzil release > > > > > > The effort of getting that first dist.ini is mostly about deciding what workflow you want to use and what workflows Dist::Zilla can support. My prefs are to have dzil rewrite the pod and version of the module before packaging it, and use git tags to track versions, and various other opinions. > > > > > > > On May 9, 2020, at 11:24 AM, Ernst, Kevin wrote: > > > > > > > > ?On 09.05.20 at 00:12, Scott R. Corzine wrote: > > > >> Why don't we do both: this month start that collaborative basic perl > > > >> module and next month do all of the bits and pieces around it needed > > > >> to turn it into a respectable perl module. > > > > > > > > Agreed, this sounds great. Especially the "respectable" part. > > > > > > > > All I've been able to discern about Perl modules is that there's a > > > > 'package' somewhere in the middle, and they have to have '1;' at the > > > > end, and that is so just Perl in a nutshell. > > > > > > > > Look, I'm 50% joking here; I /have/ written Perl modules in a work > > > > context. I just never felt like I was doing it right. Maybe I'm just a > > > > weak/inexperienced developer who needs the hand-holding, but just seeing > > > > how someone who knows what they're /doing/ would structure a module from > > > > scratch would still be super-helpful. > > > > > > > > Even if it's something facile and completely throwaway, like Yet Another > > > > Template Processor, or Yet Another Command-line Weather-fetching Client. > > > > > > > > Where to *put* them on a local system or shared server environment is a > > > > whole other question. Like, should they go in > > > > /usr/local/perl5/lib/perl5/5.28.1/site_perl, or > > > > /usr/local/perl5/lib/perl5/5.28.1/linux-x86_64/lib/perl5/?, or, aw hell. > > > > Where are they /supposed/ to go? Where do I put a module that will just > > > > *work* with Perl 5.something? > > > > > > > > ?Kevin > > > > _______________________________________________ > > > > Cincinnati-pm mailing list > > > > Cincinnati-pm at pm.org > > > > https://mail.pm.org/mailman/listinfo/cincinnati-pm > > > _______________________________________________ > > > Cincinnati-pm mailing list > > > Cincinnati-pm at pm.org > > > https://mail.pm.org/mailman/listinfo/cincinnati-pm