From josjr69 at gmail.com Tue Jul 6 15:22:49 2010 From: josjr69 at gmail.com (James Smith) Date: Tue, 6 Jul 2010 17:22:49 -0500 Subject: [Mpls-pm] Perl Gezzer Musings on "Modernization" Message-ID: Not a lot of traffic here, so I figured I'd ramble a bit on Perl Modernization and get some feedback on my evolving strategy to do that. Since it will be twenty years this fall that I started using Perl, and since there is an urgent need for me to (once again) refactor my Perl-career perspective, I have been looking back over the many large projects that I have designed and implemented in Perl, from the early, completely non-object oriented days of Perl 4, through the early object oriented efforts of early Perl 5, to my current efforts to absorb the strongly abstracted, object focused frameworks of "modern" Perl. Initially, I needed to better understand what had happened while I was working in my own trench at the University over the past eight years. With the help of comments from members of this list, and the comments of many hiring managers, I was able to ferret out the requisite skills and determine what resources i would need to start climbing that and eventually convice some hiring manager that I am sufficiently "modern". But then I needed to better understand how my Perl Past and Perl Experience and Perl Knowledge was going to "fit" in this "Modern Perl" world. In previous re-tooling efforts process was more of a process of adding on to the knowledge and experience that I had at the time, sort of like adding rooms to the original homestead. This time, however, this approach is not sufficient. The changes to Perl, to the web and the world of software in general has shifted in surprising and significant ways that diverge from the somewhat linear manner that occurred from the time I wrote my first Fortran program in 1974 to when I designed my Perl-Lamp MVC web framework at the University in the 2000-2002 time frame. "Adding on" to that experience and knowledge foundation and infrastructure would have been a disservice to the Perl-based module libraries and programming methodologies that have evolved, almost exponentially, since 2002. Although the "old" Perl is still there, underneath, and one can continue to write code, even large systems with integrated, reusable libraries, perhaps even a few object oriented modules, the simple fact is that "Modern" Perl is structured entirely differently, with an entirely different level of abstraction brought into play and significantly more demanding expectations and assumptions directed at it. Today, before the first line of code is written, there is an urgent need to know available frameworks and the plugins that can be called upon to "extend" the framework. Even Perl itself has been radically "extended", to the point where an "old school" Perlite (i.e. me) won't even recognized many of the linguistic features, simply because they did not exist five, ten, fifteen, twenty years before. Once I realized that Catalyst was the mountain that I needed to climb, and that JavaScript had become the front-end user-interface that gleamed at the top of that mountain, I realized that I needed to start at the bottom, in Dante's Interno, "old" Perl and work my way up to the mountain of Purgatory that would lead to the Paradise of sparkling (bling) of JavaScript-enable user interactions. there was no other path. I started off with the installation os Catalyst itself and worked through some of the tutorials, but then I realized that, with the advent of Moose, DBIC, Perl Template Toolkit, Test::Harness, and many more modules and extensions to Perl, that I really didn't have a strong, gut-level feeling for the internals of Perl, Perl Modules and Perl Object, even though I had been using them for years. Ten years ago, Perl Objects were something one designed after there was some critical mass of functions that fit discernible patterns to justifying going the extra, somewhat exotic, step of defining and implementing a module that quickly squirreled away into the library used from then on out. Today, knowledge of the internal workings of objects, autoloading, packages, scoping, etc are no longer optional, but mandatory, dailing tasks that one has to think about continuously from the moment the first line of code is written. So, I started over, because it was difficult to sort out when a particular feature worked its way into the Perl world over the past twenty years.. When you learn a language on the fly, on the job, in the line of fire, you look until you find something useful, or you write function, put it into a module and move on. There is little time to put all of the available components on the table and learn how to use it all in some systematic way. It's kind of like tearing down the incrementally-evolving homestead in order reconstruct the house one really want's to build, rather than simply "settling" for another addon. I didn't want to follow recipies and construct a Perl/Catalyst system without understanding the components, how they worked and why they worked. that being the case, I am building a Perl/Catalyst system from the bottom, piece-by-piece, from the the Components of Test, DBIx::Class, Perl::TemplateToolkit, etc, using all of the most recent Object Oriented methodologies. Life is hard, down here in the Inferno, but at least the direction is "up" now, rather than "down". Later... The not-quite "modern" Perl geezer... Jim josjr69 at gmail.com -- James Oliver Smith, Jr josjr69 at gmail.com www.cyberpoet.com From chris at prather.org Tue Jul 6 17:19:40 2010 From: chris at prather.org (Chris Prather) Date: Tue, 6 Jul 2010 20:19:40 -0400 Subject: [Mpls-pm] Perl Gezzer Musings on "Modernization" In-Reply-To: References: Message-ID: While I don't quite have the same depth of experience as you I do feel your pain. Technically my first computer science course was a 1977 Operating Systems Design course which I attended in-utero. I took a small break from computers after that for about 17 years while I focused instead on things like eating, walking, talking and dealing with general "Real Life" issues. I came back to computers in the mid 90s because of the Web, I knew then that this was something I would be interested in doing with my life. I started teaching myself Perl. This is roughly where we started diverging. I was re-introduced to computer programming well after the explosion of Object Oriented programming which started with Simula '67. I knew that Object Oriented programming was going to be important and I spent a lot of effort to learn OO design early. Perl for the first ten years was a language that "supported" object orientation in a very rudimentary way. You sum it up well when you said: > Ten years ago, Perl Objects were something one designed after there > was some critical mass of functions that fit discernible patterns to justifying > going the extra, somewhat exotic, step of defining and implementing a > module that quickly squirreled away into the library used from then on > out. This lack of support for OO, coming from a (admittedly self-taught) Object Oriented background, turned out to be quite a feature. I knew more about the theoretical underpinnings of *how* my system was put together than I could in any other language. To use the terms from the literature, the Meta-object protocol was exceedingly explicit because with every project you basically had to write it yourself. I went though a couple of Perl jobs where I dealt with plain old non-OO Perl4 and other such beasts until eventually I was pointed at Moose in late 2006. > Today, knowledge of the internal workings of objects, > autoloading, packages, scoping, etc are no longer optional, but > mandatory, dailing tasks that one has to think about continuously from > the moment the first line of code is written. I'm not sure I entirely agree with you here though. Knowledge of Packages and Scopes are I would agree essential to "Modern Perl", but I've managed to forget much of what I know about autoloading, and the esoterica about Perl's object system. I still need to know about Object Design, but now instead of needing to remember the details for how to implement a rational object system (should I use a blessed hash or array? do I really want to write accessors for all of these? how much validation should I put in to this method?) I can rely upon external tools and the knowledge I've been adding on has been more universally applicable to languages and issues beyond Perl. I'm sure of it's universal applicability because recently a good bit of it has been coming from non-Perl languages that I've been applying *to* Modern Perl projects I'm involved with. That said: > It's kind of like tearing down the > incrementally-evolving homestead in order reconstruct the house one > really want's to build, rather than simply "settling" for another > addon. I didn't want to follow recipies and construct a Perl/Catalyst > system without understanding the components, how they worked and why > they worked. I fully appreciate your pain here. I went through this same process in 2006 when I had to tear down all the assumptions I had about how Objects work and re-learn how they applied to Moose. Someone recently accused Moose of being a totally seperate language built into Perl, and in many ways they are right. I personally think that this is a wonderful thing though. I can keep most of what I loved about Perl (it's flexibility and relaxed nature, as well as the way it fits the way I think) but expand in new directions that many languages simply aren't capable of yet (for example outside of Moose, Scala is the only reasonably widely adopted language I can think of that has features similar to Roles). Sometimes it is important to tear down the old structures and rebuild based on the acquired knowledge of both. I've found that the process has made me a better developer and architect. I'm currently going through the process again while I learn this funky thing called "Business". -Chris From Vince_Amela at symantec.com Fri Jul 23 18:04:28 2010 From: Vince_Amela at symantec.com (Vince Amela) Date: Fri, 23 Jul 2010 18:04:28 -0700 Subject: [Mpls-pm] Symantec - Software Engineer - Roseville Message-ID: Company Overview Symantec is a global leader in providing security, storage and systems management solutions to help our customers - from consumers and small businesses to the largest global organizations - secure and manage their information-driven world against more risks at more points, more completely and efficiently. Our software and services protect completely, in ways that can be easily managed and with controls that can be enforced automatically - enabling confidence wherever information is used or stored. Department Overview Symantec's Information Management Group, with industry leading products that ensure successful backup, recovery and archiving of information and systems for organizations, is looking for exceptional individuals. If you would like to play a part in the success of market leading product teams such as NetBackup, PureDisk, Backup Exec, Backup Exec System Recovery and Enterprise Vault, then please apply today. Responsibilities * Software Engineer responsible for producing reliable and predictable tools for build automation on multiple platforms. * Candidate will be responsible for working with these tools to design, develop, manage, and execute software release builds for a large enterprise application. * Work closely with development teams around the world to provide support for production builds. * On an ongoing basis, will need to test changes made to the build system, document those changes, interface with others on the build team, and continually research new ways to improve efficiency of the development community. Qualifications * 3 to 5 years of experience with developing, maintaining, and optimizing multi-platform builds * Ability to troubleshoot make (or equivalent) and accompanying build systems * Experience with the Microsoft Visual Studio C/C++ compiler * Experience with Perl, MS-DOS batch file scripting, and CVS (or equivalent) * Strong understanding of SCM concepts, practices and procedures * Flexibility and ability to learn on the job and a proven ability to juggle multiple tasks * Experience with scripting languages a plus * Experience with multi-platform build environments is a plus * Bachelor's Degree (or its equivalence) How To Apply To be considered for a position, please submit your resume/CV on the Symantec Careers site.(http://www.symantec.com/about/careers/search.jsp) JOB ID 590808 Symantec staffing professionals will review your qualifications against open positions. Equal Employment Opportunity Symantec Corporation is an Equal Opportunity Employer and welcomes diversity. NOTE: To all recruitment firms: Symantec is not accepting agency/search firm referrals for this posting, or other postings, without prior written permission from Symantec's Staffing organization. Symantec is not responsible for any fees related to unsolicited resumes. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 67 bytes Desc: image001.gif URL: