From carlushenry at sagetech-llc.com Thu Jul 5 05:48:30 2007 From: carlushenry at sagetech-llc.com (Carlus Henry) Date: Thu, 5 Jul 2007 08:48:30 -0400 Subject: [grand-rapids-pm-list] Model View Presenter Message-ID: For those of you that did not come to the last Perl User Group meeting, you missed a great presentation which prompted a wonderful discussion on the Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and with many years of experience with the Struts Framework, I am very familiar with the Model-View-Controller (MVC). I was very interested, however, in this MVP pattern. This is mostly due to the thick client application development that I have been doing lately. During the meeting, a lot of questions were raised regarding this pattern, and Jason Porrit was very patient with all of us (touche'). After the meeting, I decided to do a little more investigation, and found the following: Martin Fowler Retires Model View Presenter Pattern Yes. Believe it or not, this pattern has been retiredby Martin Fowler. Well, I don't know if retired is the correct 'r'-word. Maybe it should say 'R'efactored instead. He has split up the pattern into the Supervising Controllerand the Passive View . After reading both of the patterns, they sound very similar in detail and in practice. In the Passive View you put all of the widget population logic into the Presenter. All logic is pushed on the Presenter including the population of text fields or any other widgets available on the View. In the Supervising Controller, you push most of the logic onto the Presenter, but leave some of the logic of populating widgets in the View. Martin states: "...the essence of a good *Supervising Controller* is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved." Atomic Object Presenter First On a related note, Atomic Object also has their own variation of the MVP Design pattern called Presenter First (PF). After reading an article from Better Software magazine (referenced from their PF resources ), I find this design pattern very attractive as well. What most attracts me is the concept of linking different PF triads in order to orchestrate behavior and a process. Please refer tot he Better Software article for more information on this. Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more about this design pattern. I look forward to hearing him present in the future. -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070705/bba8807c/attachment.html From jasonmtu at yahoo.com Wed Jul 11 11:53:54 2007 From: jasonmtu at yahoo.com (Jason Porritt) Date: Wed, 11 Jul 2007 11:53:54 -0700 (PDT) Subject: [grand-rapids-pm-list] Model View Presenter Message-ID: <211425.88961.qm@web50708.mail.re2.yahoo.com> Thanks for the follow-up, Carlus. Atomic Object's Presenter First pattern is indeed very interesting, and I kind of wish we had jumped into that during the MVP discussion but we probably would have run out of time for the Perl testing section. Here are a few other links related to the meeting I meant to share with the group at the end: UI Design Patterns (Martin Fowler) GUI Architectures Inversion of Control Containers and the Dependency Injection pattern Perl Testing Test::More Test::MockObject And to answer one of Carlus' other questions about IoC (Inversion of Control) containers for perl I did find two that look interesting: IOC Peco::Container My initial impression is that Peco::Container is a bit simpler than IOC. I haven't used either of them yet so I don't have much but the documentation to base that on. Neither of them do anything other than IoC, so a fair comparison may be between these two and Java's PicoContainer instead of Spring which is a full application framework in addition to an IoC container. Thanks, Jason Porritt ----- Original Message ---- From: Carlus Henry To: grand-rapids-pm-list at pm.org Sent: Thursday, July 5, 2007 8:48:30 AM Subject: [grand-rapids-pm-list] Model View Presenter For those of you that did not come to the last Perl User Group meeting, you missed a great presentation which prompted a wonderful discussion on the Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and with many years of experience with the Struts Framework, I am very familiar with the Model-View-Controller (MVC). I was very interested, however, in this MVP pattern. This is mostly due to the thick client application development that I have been doing lately. During the meeting, a lot of questions were raised regarding this pattern, and Jason Porrit was very patient with all of us (touche'). After the meeting, I decided to do a little more investigation, and found the following: Martin Fowler Retires Model View Presenter Pattern Yes. Believe it or not, this pattern has been retired by Martin Fowler. Well, I don't know if retired is the correct 'r'-word. Maybe it should say 'R'efactored instead. He has split up the pattern into the Supervising Controller and the Passive View. After reading both of the patterns, they sound very similar in detail and in practice. In the Passive View you put all of the widget population logic into the Presenter. All logic is pushed on the Presenter including the population of text fields or any other widgets available on the View. In the Supervising Controller, you push most of the logic onto the Presenter, but leave some of the logic of populating widgets in the View. Martin states: "...the essence of a good Supervising Controller is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved." Atomic Object Presenter First On a related note, Atomic Object also has their own variation of the MVP Design pattern called Presenter First (PF). After reading an article from Better Software magazine (referenced from their PF resources), I find this design pattern very attractive as well. What most attracts me is the concept of linking different PF triads in order to orchestrate behavior and a process. Please refer tot he Better Software article for more information on this. Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more about this design pattern. I look forward to hearing him present in the future. -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ _______________________________________________ grand-rapids-pm-list mailing list grand-rapids-pm-list at pm.org http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070711/8d0f5375/attachment.html From Sean.McMillan at priorityhealth.com Wed Jul 11 12:28:31 2007 From: Sean.McMillan at priorityhealth.com (Sean McMillan) Date: Wed, 11 Jul 2007 15:28:31 -0400 Subject: [grand-rapids-pm-list] World's shortest perl program Message-ID: <58D360B0526CC94C925543AAB1A73B020154247A9E@PING.ad.priority-health.com> I mentioned this in the last meeting. The world's shortest perl script. From the 0th obfuscated perl contest: (http://www.foo.be/docs/tpj/issues/vol1_3/tpj0103-0010.html) 2nd Place: Gordon Lack. Here's Gordon's entire program: #!/usr/bin/perl l -w015l12pi.bak. Which, as you can plainly see, converts Mac-format text files into UNIX-format text files. --Sean ** ** ** PRIVILEGED AND CONFIDENTIAL ** ** ** This email transmission contains privileged and confidential information intended only for the use of the individual or entity named above. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please delete the email and immediately notify the sender via the email return address or mailto:postmaster at priorityhealth.com. Thank you. - end - From carlushenry at sagetech-llc.com Thu Jul 12 07:06:51 2007 From: carlushenry at sagetech-llc.com (Carlus Henry) Date: Thu, 12 Jul 2007 10:06:51 -0400 Subject: [grand-rapids-pm-list] Fwd: Model View Presenter In-Reply-To: References: <211425.88961.qm@web50708.mail.re2.yahoo.com> Message-ID: Meant to send this message to everyone.....What do you guys think? Carlus ---------- Forwarded message ---------- From: Carlus Henry Date: Jul 12, 2007 10:06 AM Subject: Re: [grand-rapids-pm-list] Model View Presenter To: Jason Porritt Hey bud.... In your work with MVP, does when the presenter delegates to the model, who owns the transactions when doing commits? I am thinking that the model should own the commits....but what happens if the work that needs to be done is happening across two seperate model calls. When the second model operation fails it should roll back the first. But you are not able to do this unless the transaction is being controlled at the presenter level, which just feels awkward. What have you done? Thanks Carlus On 7/11/07, Jason Porritt wrote: > > Thanks for the follow-up, Carlus. Atomic Object's Presenter First pattern > is indeed very interesting, and I kind of wish we had jumped into that > during the MVP discussion but we probably would have run out of time for the > Perl testing section. Here are a few other links related to the meeting I > meant to share with the group at the end: > > UI Design Patterns (Martin Fowler) > GUI Architectures > Inversion of Control Containers and the Dependency Injection pattern > > Perl Testing > Test::More > Test::MockObject > > And to answer one of Carlus' other questions about IoC (Inversion of > Control) containers for perl I did find two that look interesting: > IOC > Peco::Container > > My initial impression is that Peco::Container is a bit simpler than IOC. > I haven't used either of them yet so I don't have much but the documentation > to base that on. Neither of them do anything other than IoC, so a fair > comparison may be between these two and Java's PicoContainerinstead of Spring which is a full application framework in addition to an > IoC container. > > Thanks, > Jason Porritt > > ----- Original Message ---- > From: Carlus Henry > To: grand-rapids-pm-list at pm.org > Sent: Thursday, July 5, 2007 8:48:30 AM > Subject: [grand-rapids-pm-list] Model View Presenter > > For those of you that did not come to the last Perl User Group meeting, > you missed a great presentation which prompted a wonderful discussion on the > Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and > with many years of experience with the Struts Framework, I am very familiar > with the Model-View-Controller (MVC). I was very interested, however, in > this MVP pattern. This is mostly due to the thick client application > development that I have been doing lately. > > During the meeting, a lot of questions were raised regarding this pattern, > and Jason Porrit was very patient with all of us (touche'). After the > meeting, I decided to do a little more investigation, and found the > following: > > Martin Fowler Retires Model View Presenter Pattern > > Yes. Believe it or not, this pattern has been retiredby Martin Fowler. Well, I don't know if retired is the correct 'r'-word. > Maybe it should say 'R'efactored instead. He has split up the pattern into > the Supervising Controllerand the Passive > View . After > reading both of the patterns, they sound very similar in detail and in > practice. In the Passive View you put all of the widget population logic > into the Presenter. All logic is pushed on the Presenter including the > population of text fields or any other widgets available on the View. In > the Supervising Controller, you push most of the logic onto the Presenter, > but leave some of the logic of populating widgets in the View. Martin > states: > > "...the essence of a good *Supervising Controller* is to do as little as > possible. Let the view handle as much as possible and only step in when > there's more complex logic involved." > > Atomic Object Presenter First > On a related note, Atomic Object also has their > own variation of the MVP Design pattern called Presenter First (PF). After > reading an article from Better Software magazine (referenced from their PF > resources ), I find this > design pattern very attractive as well. What most attracts me is the > concept of linking different PF triads in order to orchestrate behavior and > a process. Please refer tot he Better Software article for more information > on this. > > Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more > about this design pattern. I look forward to hearing him present in the > future. > -- > Carlus Henry > SageTech L.L.C. > www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ > _______________________________________________ > grand-rapids-pm-list mailing list > grand-rapids-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list > > > ------------------------------ > Looking for a deal? Find great prices on flights and hotelswith Yahoo! FareChase. > > _______________________________________________ > grand-rapids-pm-list mailing list > grand-rapids-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list > -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070712/758b1706/attachment.html From sdeyoung at select-resources.com Thu Jul 12 07:54:14 2007 From: sdeyoung at select-resources.com (Shannon ) Date: Thu, 12 Jul 2007 10:54:14 -0400 Subject: [grand-rapids-pm-list] Model View Presenter In-Reply-To: Message-ID: <00a301c7c494$84671320$6401a8c0@COMPAQ> Good morning!! My name is Shannon DeYoung and I am the Recruiting Manager for Select Resources, a local Information Technology Recruiting Firm. I am currently recruiting for a client in the Grand Rapids area and hoped that you may be able to lend me some assistance. My client is an industry leader and they are seeking experienced Perl Developer to join their team on a contract basis. This is a great company to work for and the projects they are working on are very challenging. I would love to speak with you any of you about this in hopes that you or possibly someone you know may be interested. Thank you for your time and assistance. Best Regards, Shannon DeYoung Recruiting Manager Select Resources, LLC sdeyoung at select-resources.com 616-874-7550 (home office) 616-723-3511 (mobile) -----Original Message----- From: grand-rapids-pm-list-bounces+sdeyoung=select-resources.com at pm.org [mailto:grand-rapids-pm-list-bounces+sdeyoung=select-resources.com at pm.or g] On Behalf Of Carlus Henry Sent: Thursday, July 05, 2007 8:49 AM To: grand-rapids-pm-list at pm.org Subject: [grand-rapids-pm-list] Model View Presenter For those of you that did not come to the last Perl User Group meeting, you missed a great presentation which prompted a wonderful discussion on the Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and with many years of experience with the Struts Framework, I am very familiar with the Model-View-Controller (MVC). I was very interested, however, in this MVP pattern. This is mostly due to the thick client application development that I have been doing lately. During the meeting, a lot of questions were raised regarding this pattern, and Jason Porrit was very patient with all of us (touche'). After the meeting, I decided to do a little more investigation, and found the following: Martin Fowler Retires Model View Presenter Pattern Yes. Believe it or not, this pattern has been retired by Martin Fowler. Well, I don't know if retired is the correct 'r'-word. Maybe it should say 'R'efactored instead. He has split up the pattern into the Supervising Controller and the Passive View . After reading both of the patterns, they sound very similar in detail and in practice. In the Passive View you put all of the widget population logic into the Presenter. All logic is pushed on the Presenter including the population of text fields or any other widgets available on the View. In the Supervising Controller, you push most of the logic onto the Presenter, but leave some of the logic of populating widgets in the View. Martin states: "...the essence of a good Supervising Controller is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved." Atomic Object Presenter First On a related note, Atomic Object also has their own variation of the MVP Design pattern called Presenter First (PF). After reading an article from Better Software magazine (referenced from their PF resources ), I find this design pattern very attractive as well. What most attracts me is the concept of linking different PF triads in order to orchestrate behavior and a process. Please refer tot he Better Software article for more information on this. Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more about this design pattern. I look forward to hearing him present in the future. -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070712/29c5fd0c/attachment-0001.html From jasonmtu at yahoo.com Thu Jul 12 10:59:10 2007 From: jasonmtu at yahoo.com (Jason Porritt) Date: Thu, 12 Jul 2007 10:59:10 -0700 (PDT) Subject: [grand-rapids-pm-list] Fwd: Model View Presenter Message-ID: <604681.42550.qm@web50704.mail.re2.yahoo.com> That is a good question, but one I haven't worked through myself :) I'll offer my thoughts anyway, and I think you're right that the Model should, in some way, own the transaction management. Here are two ideas that I think would keep things in line with the goals of Presenter First. Manage transactions in the Presenter through the Model. Create methods on the Model that wrap your database transaction functions like (in perl) begin_work, commit, and rollback with more end-user oriented names like start_changes, save_changes, and abort_changes. Call those methods from the Presenter like: $model->start_changes(); $model->abort_changes() unless $model->save_new_username($username); $model->abort_changes() unless $model->save_new_address($address); $model->save_changes(); I know this is a trivial exmple, but I think that sort of logic does still sound reasonably like the story of the application from the user's perspective. Include all elements of a transaction in a single method. In other words, don't spread transactions across multiple Model methods :) I think I would prefer to keep the Presenter in the dark about transactions and let the Model handle it. This also goes along with the "Finish what you start" idea from Dave Thomas' book The Pragmatic Programmer, which I've found to be good advice. (I am willing to accept that there may be situations where this doesn't make sense) Conclusion As I said, I haven't worked through this myself so these are just unproven, untested ideas. This might be a good discussion to carry over to the XP West MI mailing list. Hope that helps, Jason Porritt ----- Original Message ---- From: Carlus Henry To: grand-rapids-pm-list at pm.org Sent: Thursday, July 12, 2007 10:06:51 AM Subject: [grand-rapids-pm-list] Fwd: Model View Presenter Meant to send this message to everyone.....What do you guys think? Carlus ---------- Forwarded message ---------- From: Carlus Henry < carlushenry at sagetech-llc.com> Date: Jul 12, 2007 10:06 AM Subject: Re: [grand-rapids-pm-list] Model View Presenter To: Jason Porritt Hey bud.... In your work with MVP, does when the presenter delegates to the model, who owns the transactions when doing commits? I am thinking that the model should own the commits....but what happens if the work that needs to be done is happening across two seperate model calls. When the second model operation fails it should roll back the first. But you are not able to do this unless the transaction is being controlled at the presenter level, which just feels awkward. What have you done? Thanks Carlus On 7/11/07, Jason Porritt < jasonmtu at yahoo.com> wrote: Thanks for the follow-up, Carlus. Atomic Object's Presenter First pattern is indeed very interesting, and I kind of wish we had jumped into that during the MVP discussion but we probably would have run out of time for the Perl testing section. Here are a few other links related to the meeting I meant to share with the group at the end: UI Design Patterns (Martin Fowler) GUI Architectures Inversion of Control Containers and the Dependency Injection pattern Perl Testing Test::More Test::MockObject And to answer one of Carlus' other questions about IoC (Inversion of Control) containers for perl I did find two that look interesting: IOC Peco::Container My initial impression is that Peco::Container is a bit simpler than IOC. I haven't used either of them yet so I don't have much but the documentation to base that on. Neither of them do anything other than IoC, so a fair comparison may be between these two and Java's PicoContainer instead of Spring which is a full application framework in addition to an IoC container. Thanks, Jason Porritt ----- Original Message ---- From: Carlus Henry To: grand-rapids-pm-list at pm.org Sent: Thursday, July 5, 2007 8:48:30 AM Subject: [grand-rapids-pm-list] Model View Presenter For those of you that did not come to the last Perl User Group meeting, you missed a great presentation which prompted a wonderful discussion on the Model-View-Presenter Pattern (MVP). Primarily being a J2EE developer and with many years of experience with the Struts Framework, I am very familiar with the Model-View-Controller (MVC). I was very interested, however, in this MVP pattern. This is mostly due to the thick client application development that I have been doing lately. During the meeting, a lot of questions were raised regarding this pattern, and Jason Porrit was very patient with all of us (touche'). After the meeting, I decided to do a little more investigation, and found the following: Martin Fowler Retires Model View Presenter Pattern Yes. Believe it or not, this pattern has been retired by Martin Fowler. Well, I don't know if retired is the correct 'r'-word. Maybe it should say 'R'efactored instead. He has split up the pattern into the Supervising Controller and the Passive View. After reading both of the patterns, they sound very similar in detail and in practice. In the Passive View you put all of the widget population logic into the Presenter. All logic is pushed on the Presenter including the population of text fields or any other widgets available on the View. In the Supervising Controller, you push most of the logic onto the Presenter, but leave some of the logic of populating widgets in the View. Martin states: "...the essence of a good Supervising Controller is to do as little as possible. Let the view handle as much as possible and only step in when there's more complex logic involved." Atomic Object Presenter First On a related note, Atomic Object also has their own variation of the MVP Design pattern called Presenter First (PF). After reading an article from Better Software magazine (referenced from their PF resources), I find this design pattern very attractive as well. What most attracts me is the concept of linking different PF triads in order to orchestrate behavior and a process. Please refer tot he Better Software article for more information on this. Overall, I owe a big thanks to Jason Porrit for inspiring me to learn more about this design pattern. I look forward to hearing him present in the future. -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ _______________________________________________ grand-rapids-pm-list mailing list grand-rapids-pm-list at pm.org http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. _______________________________________________ grand-rapids-pm-list mailing list grand-rapids-pm-list at pm.org http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ _______________________________________________ grand-rapids-pm-list mailing list grand-rapids-pm-list at pm.org http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list ____________________________________________________________________________________ Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games. http://sims.yahoo.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070712/acaf11a5/attachment.html From carlushenry at sagetech-llc.com Mon Jul 23 12:06:57 2007 From: carlushenry at sagetech-llc.com (Carlus Henry) Date: Mon, 23 Jul 2007 15:06:57 -0400 Subject: [grand-rapids-pm-list] Environment Variables and/or Properties Message-ID: Good afternoon everyone, I am currently working on a couple of Perl scripts and thought that I would post a question that I seem to run into all of the time. It is regarding environment variables and/or properties. I am sure that we have all faced the problem before, but I was curious to see how you may have resolved the issue. Let me first set the stage: You are working on a program with variables whose values depend on the environment that you are in. For example, the database connection, dsn, user id, password. When you are in the development environment, you want to connect to the dev database with development credentials. When you are in test...test and prod....prod. In what ways are you specifying these different values in each environment? What has worked best for you? Thanks and looking forward to the feedback. -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070723/96076747/attachment.html From Sean.McMillan at priorityhealth.com Mon Jul 23 12:20:48 2007 From: Sean.McMillan at priorityhealth.com (Sean McMillan) Date: Mon, 23 Jul 2007 15:20:48 -0400 Subject: [grand-rapids-pm-list] Environment Variables and/or Properties In-Reply-To: References: Message-ID: <58D360B0526CC94C925543AAB1A73B0201543451B3@PING.ad.priority-health.com> > You are working on a program with variables whose values > depend on the environment that you are in. For example, the > database connection, dsn, user id, password. When you are in > the development environment, you want to connect to the dev > database with development credentials. When you are in > test...test and prod....prod. In what ways are you > specifying these different values in each environment? What > has worked best for you? So, in the past, what I've done is create a perl module (.pm) that connected to the database and made the $dbh variable available globally. I checked the hostname (I believe that's $ENV{hostname}, but double check before you use it,) and if it was in a list of production boxes, I connected to the production database. Otherwise, I connected to my development database. That meant that I needed to modify Connection.pm when they added a new production host. I also set some other useful variables, like email server name and person to contact on error. This was on Oracle, which allows you to have multiple simultaneous statements. SQL Server only allows one statement at a time, so I wrote a function that would return a new $dbh in case you needed more than one. It was also a web interface under CGI, not mod_perl, so the handles were not shared between script instances. Where I work now, we have a standard DB Connect module which does approximately the same thing, but also looks up passwords for you. That way developers don't have access to the production passwords, so we can pass our audits. I don't think there's much more underneath it though. --Sean ** ** ** PRIVILEGED AND CONFIDENTIAL ** ** ** This email transmission contains privileged and confidential information intended only for the use of the individual or entity named above. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please delete the email and immediately notify the sender via the email return address or mailto:postmaster at priorityhealth.com. Thank you. - end - From mheusser at charter.net Tue Jul 24 06:55:37 2007 From: mheusser at charter.net (mheusser at charter.net) Date: Tue, 24 Jul 2007 6:55:37 -0700 Subject: [grand-rapids-pm-list] Environment Variables and/or Properties Message-ID: <1447742020.1185285337534.JavaMail.root@fepweb04> Sean covered it pretty well for our current company. I believe there is a config file hidden somewhere that stores the passwords in some encrypted format. So, from the dev to test to prod, the perl code is the same, but the password file is different. Thus, even if developers hack the config file, all they get in dev and test are the dev and test pwds. (Not that we would ever do that, Tim) We also have a way of connecting to the appropriate db. For example, you have the same dbname in dev, test, and prod. Or you could just connect directly to the 'real' dev db. This can be helpful when you are developing in test or testing in dev - and yes, we do that on occasion. For example, if a project is in the dev phase, and the dev db goes down for two days for a refresh, and we don't want to stop working. But that's just me talking. Hey, I'm curious - is anybody on this list from Luddington or Traverse City? --heusser From mheusser at charter.net Tue Jul 24 06:55:44 2007 From: mheusser at charter.net (mheusser at charter.net) Date: Tue, 24 Jul 2007 6:55:44 -0700 Subject: [grand-rapids-pm-list] Environment Variables and/or Properties Message-ID: <1605845744.1185285344894.JavaMail.root@fepweb04> Sean covered it pretty well for our current company. I believe there is a config file hidden somewhere that stores the passwords in some encrypted format. So, from the dev to test to prod, the perl code is the same, but the password file is different. Thus, even if developers hack the config file, all they get in dev and test are the dev and test pwds. (Not that we would ever do that, Tim) We also have a way of connecting to the appropriate db. For example, you have the same dbname in dev, test, and prod. Or you could just connect directly to the 'real' dev db. This can be helpful when you are developing in test or testing in dev - and yes, we do that on occasion. For example, if a project is in the dev phase, and the dev db goes down for two days for a refresh, and we don't want to stop working. But that's just me talking. Hey, I'm curious - is anybody on this list from Luddington or Traverse City? --heusser From carlushenry at sagetech-llc.com Tue Jul 24 07:12:31 2007 From: carlushenry at sagetech-llc.com (Carlus Henry) Date: Tue, 24 Jul 2007 10:12:31 -0400 Subject: [grand-rapids-pm-list] Environment Variables and/or Properties In-Reply-To: <1605845744.1185285344894.JavaMail.root@fepweb04> References: <1605845744.1185285344894.JavaMail.root@fepweb04> Message-ID: Hey....thanks for the feedback. Unfortunately, the infrastructure of where I am does not support the maintenance of encrypted passwords or a configuation file that is solely owned by the administrators. Because of that, the solutions that you are suggesting, which seems to me to be the right way to go, will not work. However, we did decide to address the situation by requesting the user executing the script to provide a password. That way, the password is not stored on disk. Luckily, this is an interactive program. If this was a backend program, this solution would not work, and I would advise the administrators to start looking into the solutions that you suggested. Thanks for participating in this discussion. That is the thing that I love about community - participation and free flowing knowledge. Useful Perl Tip When implementing this interactive application, I didn't want the password to end up in the clear on the screen. I did some googling, and I found a way to hide text that is entered through the STDIN. By executing the following, I was able to prevent the password from showing up on the command prompt: system('stty', '-echo'); chop($passwd = ); system('stty', 'echo'); Thanks Carlus On 7/24/07, mheusser at charter.net wrote: > > Sean covered it pretty well for our current company. I believe there is a > config file hidden somewhere that stores the passwords in some encrypted > format. > > So, from the dev to test to prod, the perl code is the same, but the > password file is different. Thus, even if developers hack the config file, > all they get in dev and test are the dev and test pwds. (Not that we would > ever do that, Tim) > > We also have a way of connecting to the appropriate db. For example, you > have the same dbname in dev, test, and prod. Or you could just connect > directly to the 'real' dev db. This can be helpful when you are developing > in test or testing in dev - and yes, we do that on occasion. For example, > if a project is in the dev phase, and the dev db goes down for two days for > a refresh, and we don't want to stop working. > > But that's just me talking. > > Hey, I'm curious - is anybody on this list from Luddington or Traverse > City? > > --heusser > _______________________________________________ > grand-rapids-pm-list mailing list > grand-rapids-pm-list at pm.org > http://mail.pm.org/mailman/listinfo/grand-rapids-pm-list > -- Carlus Henry SageTech L.L.C. www.sagetech-llc.com | http://jdcarlflip.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.pm.org/pipermail/grand-rapids-pm-list/attachments/20070724/82d41ab4/attachment.html From Ed.Eddington at priorityhealth.com Thu Jul 26 06:58:08 2007 From: Ed.Eddington at priorityhealth.com (Ed Eddington) Date: Thu, 26 Jul 2007 09:58:08 -0400 Subject: [grand-rapids-pm-list] Perlmongers Message-ID: GR Perlmongers, There will be no formal gr-pm meeting this month. I will be out of town tomorrow. But if anyone wants to gather for a social lunch, feel free to reply to the list and arrange it. See you in August for Catalyst (see below)! I'd like to hold the September talk at a different location and time than usual. If someone would like to help arrange this, please contact me. Has anyone outside of PriorityHealth had the problem where they do not receive the original message posted to the mailing list, but do receive any replies? If so, please let me know. -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Upcoming Events: Fri, Aug 31 - 11:30 - 1:00 PM Johnathan Rockway - Catalyst (Perl's "Ruby on Rails" environment) Priority Health Conference Center September (tbd) Andy Lester - Things you may not know about Perl October (tbd) Matt Heusser - Intro to Perl -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- "Where have all the young hackers gone?" This topic was recently discussed on the pm_groups mailing list. The following questionnaire was forwarded and responses came from various pm groups around the world. Here are a couple of the more interesting ones (Portugal; Ruhrgebiet, Germany; Barcelona, Spain; Tokyo, Japan). ------ Forwarded Message From: Edgar Bering Date: Fri, 20 Jul 2007 14:25:39 -0400 To: Conversation: [pm_groups] Where have all the young hackers gone? Subject: [pm_groups] Where have all the young hackers gone? Dear PM leaders, At YAPC::NA I brought up the issue that the Perl community lacked members under 22 or so, and several reasons for this were discussed. I would like to get more information regarding the issue, so I have a few questions that I would like answered about every PM group: 1) At a typical meeting what percent of your members are under 25? 2) Are meetings typically held at open venues? (not bars or clubs that card) 3) Is there a college or university in your town? If yes I have extra questions ! 4) How far is the university from your meeting place ? 5) Does the university have a Computer Science program ? Thank you for the replying, once I have the data I'll report and try and find ways to recruit a new generation of Perl users. ------ End of Forwarded Message ------ Forwarded Message From: Alberto Simoes Reply-To: Date: Fri, 20 Jul 2007 14:38:20 -0400 Cc: Conversation: [pm_groups] Where have all the young hackers gone? Subject: Re: [pm_groups] Where have all the young hackers gone? Edgar Bering wrote: > Dear PM leaders, Hi > 1) At a typical meeting what percent of your members are under 25? On Tech-Meetings I would say, 50% (more should be said: about 10-15 persons attend) > 2) Are meetings typically held at open venues? (not bars or clubs that card) Yes > 3) Is there a college or university in your town? Yes > If yes I have extra questions ! > > 4) How far is the university from your meeting place ? Same place :) > 5) Does the university have a Computer Science program ? Two, in fact. And there are two (optional) courses that use Perl. A "scripting" approach to programming course, and a Natural Language Processing course. Cheers ambs (braga.pm, Portugal) ------ End of Forwarded Message ------ Forwarded Message From: Veit Wahlich Date: Fri, 20 Jul 2007 19:34:41 -0400 To: Edgar Bering Cc: Conversation: [pm_groups] Where have all the young hackers gone? [scanned] Subject: Re: [pm_groups] Where have all the young hackers gone? [scanned] Hi Edgar && list, this is for Ruhr.pm, Germany: Am Freitag, den 20.07.2007, 20:25 +0200 schrieb Edgar Bering: > 1) At a typical meeting what percent of your members are under 25? 33% average for the last 12 months and 27% of the persons who were present for at least 10 of those 12 meetings. > 2) Are meetings typically held at open venues? (not bars or clubs that card) No. > 3) Is there a college or university in your town? Yes, University of Duisburg-Essen, campi Essen. > 4) How far is the university from your meeting place ? Within walking distance or using public transports: - from main campus closest edge: ~1.2 km/~0.8 miles (~10 minutes on foot) - from main campus opposed edge: ~2.5 km/~1.6 miles (~12 minutes by underground, tram and on foot) - from Engineering campus && computer centre: ~0.8 km/~0.5 miles (~7 minutes on foot) - from Computer Science outpost: ~3.5 km/~2.2 miles (~10 minutes by tram and on foot) - from Experimental Mathematics and Systems Engineering outpost: ~4.0 km/2.5 miles (~10 minutes by tram and on foot) > 5) Does the university have a Computer Science program ? Yes, several. Besides, Perl is also used for research in Bio Informatics, Bio Engineering and Medical Informatics. Best regards, // Veit -- Ruhr.pm Perl Mongers im Ruhrgebiet http://ruhr.pm.org/ ------ End of Forwarded Message ------ Forwarded Message From: Joel Pinckheard Date: Sun, 22 Jul 2007 16:53:24 -0400 To: Edgar Bering Cc: Conversation: [pm_groups] Where have all the young hackers gone? Subject: Re: [pm_groups] Where have all the young hackers gone? Responding for Barcelona.PM > 1) At a typical meeting what percent of your members are under 25? 33% 2-3 out of 7-9. > 2) Are meetings typically held at open venues? (not bars or clubs that card) Yes. > 3) Is there a college or university in your town? Three major ones and several smaller ones plus the UOC.es (distance learning) One of the major ones is more technical (UPC.es) than the other two (ub.es and uab.es). > 4) How far is the university from your meeting place ? UB has a campus next door. UPC is about two km away. UAB is about 45 minutes away by train. > 5) Does the university have a Computer Science program ? All three of the major ones have at least one course, UPC has several and they use perl in at least one. -- Joel Pinckheard http://www.pincky.com ------ End of Forwarded Message ------ Forwarded Message From: Tatsuhiko Miyagawa Date: Mon, 23 Jul 2007 21:47:59 -0400 To: Conversation: [pm_groups] Where have all the young hackers gone? Subject: [pm_groups] Where have all the young hackers gone? Based on my 4 years expericne as Shibuya.pm (Tokyo, JAPAN) chair ... On 7/20/07, Edgar Bering wrote: > 1) At a typical meeting what percent of your members are under 25? I don't have an accurate number but it'd be 30-40% out of 120-150 people. > 2) Are meetings typically held at open venues? (not bars or clubs that card) Yeah, but because our tech meeting is very popular, we do RSVPs and it gets full in a few days. > 3) Is there a college or university in your town? Sure we do. Tokyo is a small town full of people, bunch of schools. > 4) How far is the university from your meeting place ? In an hour of commuting you can go to any universities/colleges in Tokyo from anywhere. > 5) Does the university have a Computer Science program ? Obviously. One interesting news that might get attention would be the University of Tokyo, one of the most well-known University (where I'm actually from) is going to adopt Ruby as their programing language to train their 1st grade newbies, starting 2008 or something. -- Tatsuhiko Miyagawa ------ End of Forwarded Message Sincerely, Ed Eddington President GR Perlmongers email: ed.eddington at priorityhealth.com Ph 616.566.2462 ** ** ** PRIVILEGED AND CONFIDENTIAL ** ** ** This email transmission contains privileged and confidential information intended only for the use of the individual or entity named above. Any unauthorized review, use, disclosure or distribution is prohibited and may be a violation of law. If you are not the intended recipient or a person responsible for delivering this message to an intended recipient, please delete the email and immediately notify the sender via the email return address or mailto:postmaster at priorityhealth.com. Thank you. - end - From andy at petdance.com Mon Jul 30 09:00:26 2007 From: andy at petdance.com (Andy Lester) Date: Mon, 30 Jul 2007 11:00:26 -0500 Subject: [grand-rapids-pm-list] Help the Perl community better understand its users at perlsurvey.org Message-ID: (Please feel free to forward this to anyone who might be able to help, such as other mailing lists. -- Andy) What sort of programmer uses Perl? Do most Perl programmers use it as a primary language, or just write the occasional script? And are there really as few women as conventional wisdom says? Kirrily Robert wants to know, and wants anyone around the world who uses Perl to help by answering a simple five-minute survey at perlsurvey.org. Kirrily's goal is to "take a snapshot of the Perl world as it currently stands." As an active member of the Perl community, she's often asked questions about Perl's users and is only left to "hypothesise, generalise, and hand-wave." Further, software communities can often be an echo chamber where people only hear from like-minded people. The Perl Survey is an attempt to break out of that echo chamber and hear from all Perl users around the world, regardless of skill level, not just the core users most active in vocal communities. An interesting part of the survey is asking the respondent's salary, if they choose to release it. "I hear a lot of talk about the going rate for Perl programmers," Kirrily says, "and whether organizations that claim they can't hire Perl programmers simply aren't paying enough." Correlating results with job experience and types of languages known could shed light on the topic. The survey's reach could help users around the world. "Salary information can be very hard to find out for anywhere other than the US," says Kirrily, an Australian. The survey will be open until September 30, 2007. Then, in October, Kirrily will be announcing the results and releasing the raw data, minus email addresses, under a Creative Commons "CC-BY" license. Her hope is that other interested people will provide their own analyses of the results. For further information, and to participate if you use Perl at all, visit perlsurvey.org. Thanks, xoxo, Andy -- Andy Lester => andy at petdance.com => www.petdance.com => AIM:petdance