Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Semelhante a Le PERL est mort
Semelhante a Le PERL est mort (20)
Último
Último (20)
Le PERL est mort
- 1. Le PERL Est Mort Perl !r"gh # A$s
- 2. Ye Olde Perl
- 5. Ye Olde Perl CGI.pm mod_perl Matt's Script Archive
- 6. Ye Olde Perl CGI.pm mod_perl Matt's Script Archive Bring Your Own Everything
- 7. Ye Olde Perl CGI.pm mod_perl Matt's Script Archive Bring Your Own Everything Language warts
- 8. CGI.pm
- 10. CGI.pm Built-in HTML generation No separation of concerns
- 11. CGI.pm Built-in HTML generation No separation of concerns Slow (weird optimizations around this)
- 12. mod_perl
- 13. mod_perl API for Apache
- 14. mod_perl API for Apache Good for changing the request/response cycle
- 15. mod_perl API for Apache Good for changing the request/response cycle Subpar for writing actual applications— too low level
- 19. Matt's Script Archive Among the first popular places to find reusable bits of code
- 20. Matt's Script Archive Among the first popular places to find reusable bits of code Easy to deploy, fulfilled common tasks, so very popular
- 21. Matt's Script Archive Among the first popular places to find reusable bits of code Easy to deploy, fulfilled common tasks, so very popular Terribly buggy and insecure
- 22. Matt's Script Archive Among the first popular places to find reusable bits of code Easy to deploy, fulfilled common tasks, so very popular Terribly buggy and insecure But because of their popularity, they became the example of Perl code to the outside world
- 23. BYOE
- 24. BYOE Immature CPAN means few good choices for common tasks
- 25. BYOE Immature CPAN means few good choices for common tasks This means lots of DarkPAN reinvention of common tasks
- 26. BYOE Immature CPAN means few good choices for common tasks This means lots of DarkPAN reinvention of common tasks Additionally, this hastened adoption of Matt's "code".
- 27. Language warts
- 31. Less Icky 2000s Perl
- 32. Less Icky 2000s Perl Some best practices
- 33. Less Icky 2000s Perl Some best practices CPAN starting to mature
- 34. Less Icky 2000s Perl Some best practices CPAN starting to mature Still no PBP!
- 35. Less Icky 2000s Perl Some best practices CPAN starting to mature Still no PBP! Perl 6
- 37. Some Best Practices strict and warnings
- 38. Some Best Practices strict and warnings Tests
- 39. Some Best Practices strict and warnings Tests Toolchain
- 40. CPAN Starting to Mature
- 41. CPAN Starting to Mature POE
- 42. CPAN Starting to Mature POE DateTime
- 43. CPAN Starting to Mature POE DateTime Still too much TMTOWTDI in other areas
- 44. Still No PBP!
- 45. Still No PBP! It's very controversial
- 46. Still No PBP! It's very controversial Many of its suggestions suck
- 47. Still No PBP! It's very controversial Many of its suggestions suck But the important thing is it started a dialog.
- 48. Perl 6
- 49. Perl 6 Separate language to Perl 5, but still Perl
- 50. Perl 6 Separate language to Perl 5, but still Perl Rejuvenated Perl 5 dev
- 51. Perl 6 Separate language to Perl 5, but still Perl Rejuvenated Perl 5 dev Foreshadowing for future of Perl 5 OOP (dun dun dun!)
- 53. Modern Perl (2005-) Many names, same general idea
- 54. Modern Perl (2005-) Many names, same general idea TMTOWTDIBSCINABTE
- 55. Modern Perl (2005-) Many names, same general idea TMTOWTDIBSCINABTE Mature, disciplined use of CPAN, language features
- 56. Modern Perl (2005-) Many names, same general idea TMTOWTDIBSCINABTE Mature, disciplined use of CPAN, language features Typical app stack: Catalyst, Plack, Moose, DBIx::Class
- 57. Catalyst: MVC for Perl
- 58. Catalyst: MVC for Perl Pluggable, flexible
- 59. Catalyst: MVC for Perl Pluggable, flexible Great for large apps
- 60. Catalyst: MVC for Perl Pluggable, flexible Great for large apps Flexibility handles complexity
- 61. Plack/PSGI
- 62. Plack/PSGI Plack/PSGI is awesome middleware for connecting your app to your web server. Think of WSGI from Python or Rack from Ruby.
- 63. Plack/PSGI Plack/PSGI is awesome middleware for connecting your app to your web server. Think of WSGI from Python or Rack from Ruby. Lots of useful tools, too, like debugging tools and logging and session handling etc.
- 64. Moose
- 65. Moose Mature, flexible, powerful object system for Perl 5
- 66. Moose Mature, flexible, powerful object system for Perl 5 Large, mature community
- 67. Moose Mature, flexible, powerful object system for Perl 5 Large, mature community Based in solid research
- 68. Moose Mature, flexible, powerful object system for Perl 5 Large, mature community Based in solid research Evolved from Perl 6 development
- 69. DBIx::Class
- 72. DBIx::Class ORM that respects databases Resultsets! Easy to customize row classes with methods
- 73. Questions?
- 74. Colophon Title image: http://www.flickr.com/photos/caribb/4310691752/in/photostream/ Cave writing: http://www.flickr.com/photos/the-consortium/3057208323/in/ photostream/ Old machinery: http://www.flickr.com/photos/mon_oeil/438670665/in/ photostream/ Fail meter: http://www.flickr.com/photos/16854395@N05/2420602334/in/ photostream/ Light switch complicator: http://www.flickr.com/photos/lenore-m/510420532/in/ photostream/ Stone tools: http://www.flickr.com/photos/salsaboy/3228329709/in/photostream/ Perl Best Practices (c) 2005 O'Reilly Media
- 75. Colophon II Camelia TM Larry Wall: https://raw.github.com/ perl6/mu/master/misc/camelia.txt Moose: http://www.flickr.com/photos/ russosborne/1684252182/ Catalyst logo used under license. DBIx::Class logo (c) Mark Keating
Notas do Editor
- Perl's grown up a lot over the years. I'll be talking about how things were through a couple of stages in Perl's history, and then skip ahead to where we are now.\n\nTo be clear, I'll be talking about Perl as used in medium to large businesses. If you're just tinkering about, or your needs aren't that demanding, a lot of what I'll be talking about at the end of this talk will seem overkill. That's okay. There are other tools which fulfill less demanding needs. I'd be glad to point these out after the talk. \n
- This is the 1995 era, which you'll remember as the dot com bubble. There was a rush to get things done without much regard for keeping things going ten years down the line. As such there's a lot of ad hoc and ugly hacks. Thankfully things have moved on since this time.\n\nThere are many things about this era of Perl's history that I'm glad to see we've past. It's now easier than ever to install modules, and easier than ever to develop and maintain them. But I would be lying if I said that some of these things aren't haunting us still. \n
- Ah, CGI.pm. What a mess. It's slow, you mix your HTML and code and CSS and layout code and logic all together. Sigh. This is a bad thing because changes can affect unrelated parts of the code. And it's harder to give designers something they can use without being scared away by the business logic. \n\nAnd it's slow. CGI is most commonly implemented by forking a process for each request. Each and every request. perl startup is slow. So we have some weird optimizations happening here. This makes things harder to maintain (this is in the module itself).\n\nBut even with really fast quad-core boxes equipped with SSDs, the module still makes a mess of things. It has \n
- mod_perl is great for what it was meant to do—writing Apache modules in Perl. But what does this mean? If you want to access the request/response cycle directly, or write an authentication module for Apache in Perl, you'd use mod_perl. It's very fast, because the code is compiled once. So, used properly, this bit of software still has many uses. \n\nHowever, it's also very low-level, and this means that there's more coding needed to do common tasks than would be needed with higher level tools. \n
- Matt's Script Archive is, on its own, partly responsible for Perl having a reputation for being an unmaintainable mess of a language. It's a site containing a collection of Perl programs meant for usage on the Web. This would be okay on its own, but the programs are buggy in some spots and outright insecure in others. \n\nHowever, because they're freely available and fulfill common tasks, they became quite popular. And because they were (are?) popular, they served as examples from which many folks learned their Perl. As the code is rather terrible, this is rather undesirable. \n
- Matt's Script Archive is, on its own, partly responsible for Perl having a reputation for being an unmaintainable mess of a language. It's a site containing a collection of Perl programs meant for usage on the Web. This would be okay on its own, but the programs are buggy in some spots and outright insecure in others. \n\nHowever, because they're freely available and fulfill common tasks, they became quite popular. And because they were (are?) popular, they served as examples from which many folks learned their Perl. As the code is rather terrible, this is rather undesirable. \n
- Early in the history of Perl 5, we had CPAN. But it was the early days, before Moose and Catalyst and even Class::DBI. There were a few Getopt modules, a few basic modules for classes or objects, and ORMs were not really very common in any language. Two common modules that we did have at this time are DBI and POE, though they're generally the only exceptions. Even DateTime was only released in 2003 as an alpha. \n\nSo at this point we have a culture of reinvention, a culture that hasn't had the time to come into its own and fully realize or utilize the potential of CPAN. \n
- Sometimes language designers make mistakes. They're human. It happens. A few misfeatures which are thankfully going away or that have gone away are switch.pm and pseudohashes. I don't want to dwell on these since they're going away. The only thing you really need to know about these "features" is that you're better off without them. If you're really curious, you can look them up yourself. \n\nBeyond that, there are things like formats. They're still in the language, but are pretty much universally accepted as not the best way to do things these days. We have tools like tempting languages for the things we once used formats for. \n
- At this stage, things are starting to improve but Perl still hasn't really come into its own as a maintainable apps language. There's several important things happening here, some of which had unexpected results. \n
- Around the early 2000s we started to see experts in support communities guiding new folks to strict and warnings, language features that help the programmer write better code. This is important, as new folks need the guidance these features provide. \n\nIn addition, Perl's strong tradition for testing really started to take off around this time. It's still going strong, with the QA hackathon every year drawing some of Perl's brightest developers. \n\nIncidentally, the QA hackathon is also where a lot of work on the toolchain happens. By "toolchain" here I mean the tools for holding and installing Perl modules. As Perl became more popular, we needed more robust tools. And smart people stepped up to write them. Today their efforts are a large part of what makes Perl the mature apps language it is. \n
- Ah, CPAN. My favorite Perl feature. It's in the early 2000s that we start to see some awesome tools, tools that people still use today to do really common and basic things.\n\nChances are that if you did asynchronous programming in Perl at this time, you used POE. It's still going strong after more than 10 years of development (though these days it has a lot of competition). It does nearly everything, with modules for almost anything you can think of. \n\nConversely, it's maddeningly difficult to do date/time calculations correctly without DateTime. Another one of Perl's de facto standard modules, it's also one of the oldest and most mature. I and many other Perl hackers turn to it for all temporal work. \n \nHowever, we still had a long way to go at this point. CPAN was still young, so there were few de facto tools for various jobs. Competition is a good thing, indeed, but at the early stage CPAN was at it was more harm than good. \n
- Perl Best Practices is probably the singular example of a galvanizing book in the Perl community. Many developers love it, many hate it. The standards described in it are obligatory at many shops around the world, despite many developers wishing the book was never written. \n\nA lot of the suggestions it gives (particularly regarding CPAN modules) are outdated or just bogus. I wouldn't give it to a new developer and tell them to follow it to the letter. I don't know anyone who would. \n\nBut that's not the point. The point is the book got people really thinking about code standards in the Perl community, and inspired them to devise their own best practices, their own evolving set of standards. In a way, Perl Best Practices laid the groundwork for the modern Perl movement. So, despite being crazy in a lot of ways, PBP really helped the industry. \n
- To clear up some rumors: Perl 6 is not Perl 5. They are different languages in the same lineage, incompatible but complementary. Perl 6 is Larry's sixth Perl, no less Perl than the Perl 5 I've been talking about and will continue talking about for the remainder of this talk. \n\nSo what's it have to do with Perl 5, then? More than you would think. For one thing, it kickstarted and rejuvenated development on Perl 5. But what I'm going to focus on later is that through various circumstances, Perl 6's development directly led to a major revolution in Perl 5's support for OOP. This revolution is still going today, and it's televised on presentingperl.org. Consider it a bit of foreshadowing, if you're looking for a literary context in which to place this talk. \n
- There's a lot of names for the current movement happening in the Perl community: modern Perl, enlightened Perl, the Perl renaissance. They all basically refer to the same thing: a mature usage of CPAN combined with Perl's rich history of testing and documentation. All of these things bring Perl from "scripting language" to full apps language.\n\nOne of the mottoes of this era is TMTOWTDIBSCINABTE, or "Tim toady bicarbonate". It stands for "there's more than one way to do it, but sometimes consistency is not a bad thing either". It refers to all the choices available on CPAN, and the benefits in choosing the best tools to do a job.\n\nAs this movement is largely defined by the liberal application of CPAN libraries, it makes sense to cover a few important ones. A typical Web application stack uses Catalyst for MVC, Plack for app middleware (connects Catalyst to different Web servers, with some pluggable awesome in between), Moose as an object system, and DBIx::Class for the ORM. These aren't the only choices, but they're probably the most popular. If you want to hire a mature Perl dev, these are your best choices. They're what the community has standardized on. \n
- Catalyst grew out of older Perl Web frameworks. It's a framework that uses the MVC framework: model, view, controller. In this configuration, Catalyst represents the controller. A templating system like Template Toolkit or Mason is used for the view, and an ORM like DBIx::Class is used for the model. \n\nA major benefit of working with Catalyst is its flexibility. It's a very pluggable framework, partly due to its design and partly due to using Moose. All of this flexibility does make things mote complicated, though. So if you're wanting to write a small app with just a few pages, Catalyst isn't for you. \n
- PSGI is a protocol for connecting a Perl app and a Web server. It's server independent, and can work in many different configurations: CGI, mod_perl, FastCGI, etc.\n\nBut it's not just glue. The Plack namespace on CPAN has a growing collection of tools to make Web development in Perl easier and less horrible. Chances are if you're writing Web code with Perl these days and you're not using cGI.pm that you are using Plack in some way. \n
- Moose is Stevan Little's object system for Perl 5. Remember how I said that Perl 6 was instrumental in the development of Perl 5? This is what I was mostly referring to. Moose is one of the best things to happen in a long time for Perl, and the community has mostly adopted it as the de facto (bicarbonate) object system for Perl 5. \n\nWhat makes Moose so great? Usually I could not care less for computer science topics, as they very rarely translate into concepts directly applicable in a working programmer's life. However, Moose is very research-based, including the metamodel found in CLOS. This metamodel gives Moose much of its power, but it doesn't stop there. Moose also has awesome features like roles, or composable pieces of behavior. Roles are what most people really want when they (mis)use inheritance. But that's a subject for another talk. \n
- Much along the lines of Catalyst and Moose, DBIx::Class is an extremely flexible ORM, written and maintained by a team of developers who aren't afraid of SQL. It allows a developer to be completely abstracted from the database if they want, but at the same time grants the flexibility to give literal SQL queries that populate objects. \n\nBeyond this, it's capable of automatically reading the database schema, at runtime, and generating the necessary classes to allow you to get up and running as quickly as possible.\n\nIt has well-designed resultset support, only pulling data from the database when necessary. And when the built in methods don't do enough, it's trivial to add new methods to row objects, and these work just as well as the built in CRUD methods. \n
- \n\n
- \n\n
- \n\n