Re: [Catalyst] RFC: The paradox of choice in web development
From: Jay Kuri j...@ion0.com I've been watching this discussion and I have ranted my less than constructive ravings in #catalyst. My more constructive ravings are below... First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' around perl anymore... If you look at actual jobs stats: http://tiny.cc/kkcCM (or http://www.indeed.com/jobtrends?q=+perl+engineer%2C+perl+developer%2C+php+engineer%2C+php+developer% 2C+ruby+developer%2C+python+developer%2C+l= ) Perl is above all the others by some margin. It's hard to see all these other languages getting the buzz, when the one we all love is practically ignored in the press... but that doesn't make it any less good and though it's hard to tell right now, buzz does not equal real world usage. In my country there are no jobs for perl developers. There are jobs for Java, C#, C++ and PHp developers. The knowledge of perl is considered as an advantage in very few job announcements, but it is wanted mostly for administrative tasks, not for web development, and there are very few programmers that even heard about Catalyst. Maybe that's why I wrongly thought that this is the same in other countries. Overall, though, I think that most of us who have used Catalyst for any period of time know that it is not a beginners platform. It is a powerful set of tools to solve difficult and complex problems. I think we need to take a page out of the old Unix'ers handbook.Stop looking to be as accessible to newbies as the other options, and embrace our true position... which is simply Catalyst is better. Not because it's easier to learn, and certainly not because it forces you into one (easy or not) way of doing things but because you can bend it to whatever form you need to solve whatever problem you have, even the ones that are less computer science-y and more computer-room- in-the-office-y. (though we can certainly do the former as well) In my opinion, we should embrace the fact that Catalyst is bigger, more complex, and more able. When someone says 'well, Why isn't catalyst as clear-cut and simple to use like Rails?' we should encourage them... tell them 'Go... Go play with rails... and when you grow out of it, we'll be waiting for you.' We should position Catalyst as the big-sister framework, the one whose there for you when you are ready to take on big problems that can't be solved by a bit of automatic CRUD, the ones that can't be stuffed into the channels that someone else has already dug. We should communicate an attitude of 'yes, we can solve easy problems too, but we are particularly good at solving the harder ones.' If we want to compete for the niche of big sites, we should see why Google, Yahoo, Amazon, Ebay and other big sites like these don't use Catalyst, what they are using and why. Maybe they also have some reasons, because I guess they have developers that know very well about all the possible options. Catalyst shouldn't compete for the low end sites not because it wouldn't be nice, or because Catalyst can't be used for simple web apps, but because it uses perl and it requires shell access to install it and third party modules, and this option is not available for most low end sites, so it is not an option for everyone. The fact is that Oracle does not try to compete for the low end of the market with MySQL. They don't want it. They never did. Why do we? The comparison is good, but not very exact. I know companies which don't use PostgreSQL but Oracle, because Oracle is better known (because it offers discounts to the software companies that distribute it, so they have the interest of promoting it), and because Oracle offers tech support. The big companies usually want to pass the responsability to others, even if they need to pay some more. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' around perl anymore... If you look at actual jobs stats: http://tiny.cc/kkcCM Perl is above all the others by some margin. Short version: that graph is misleading. Click the Relative link. Longer version: Yes, Perl is above the rest by some margin, thanks to its history. There are existing Perl applications that need to be maintained, and some momentum that keeps the demand for Perl jobs going. But click the Relative link in the graph, and see the percentage growth for Ruby jobs. It skyrockets when compared with both PHP and Perl. There are two problems I see, really. One problem I think David points out correctly... there is precious little 'easily accessible' means to learn about catalyst and what the conventional 'preferred' pieces are... so those that learn it are those that really need it's power, and have come searching for it. Those that are just trying to pick something and go will piss off to some more spoonfeed-easy-to-learn framework. I'm not convinced that's a bad thing. The second problem I see is that we don't seem to know who we want to market Catalyst to. We look over and see Rails and Django getting a lot of press and raves and such, and think 'I want to go to there.' Overall, though, I think that most of us who have used Catalyst for any period of time know that it is not a beginners platform. It is a powerful set of tools to solve difficult and complex problems. I think we need to take a page out of the old Unix'ers handbook. Stop looking to be as accessible to newbies as the other options, and embrace our true position... which is simply Catalyst is better. Not because it's easier to learn, and certainly not because it forces you into one (easy or not) way of doing things but because you can bend it to whatever form you need to solve whatever problem you have, even the ones that are less computer science-y and more computer-room-in-the-office-y. (though we can certainly do the former as well) When someone says 'well, Why isn't catalyst as clear-cut and simple to use like Rails?' we should encourage them... tell them 'Go... Go play with rails... and when you grow out of it, we'll be waiting for you.' After someone makes the decision to learn Rails (at the expense of Catalyst - this is important), and the investment to keep learning, then build a web application, and maintain it for a year or two, what happens if they run into issues? They'll ask for support. And they'll find a way to solve the problem. It may be an ugly solution, but in the vast majority of cases, the issues will not be serious enough to warrant ditching Rails, picking up Catalyst, learning its quirks, then rewriting the web application from scratch in a framework they won't be nearly as familiar with. In other words, I estimate the deconversion rate from almost any web framework to Catalyst to be very low. When that happens, it will most likely be in the form of the same developer taking on a new project, but the old app won't be rewritten. We should position Catalyst as the big-sister framework, the one whose there for you when you are ready to take on big problems that can't be solved by a bit of automatic CRUD, the ones that can't be stuffed into the channels that someone else has already dug. We should communicate an attitude of 'yes, we can solve easy problems too, but we are particularly good at solving the harder ones.' The fact is that Oracle does not try to compete for the low end of the market with MySQL. They don't want it. They never did. Why do we? I think I can agree with that. What I'm saying is that there's simply too much useless choice. Random example: Data::Dumper vs. Data::Dump. I've just discovered Data::Dump but it appears to beat the crap out of Data::Dumper. Yet does it say anywhere Hey, if you're getting started with Perl and need to dump variables, use Data::Dump, and don't waste your time investigating other modules? If I were the author of Data::Dumper, I'd somehow retire the module, or plaster a note in the POD redirecting people to Data::Dump. Imagine a programmer new to Perl picks up an example that uses Data::Dumper. Will they find out about Data::Dump? No. Someone picks up the Catbook and learns about FormBuilder. Does http://www.formbuilder.org/ mention FormFu anywhere? No. It mentions its last update, March 2007. Positive feedback (does it count as feedback if it's from the author? :) idea #1: module conflation. Kinda hard to do because people tend to feel strongly for their pet projects even when there are clearly better alternatives. The list goes on. As Octavian noted, the wheel is reinvented and solutions are forked off all the time. Mojolicious - yet another Perl web framework. I remember wasting a few hours looking into it a while ago, trying to figure out how it's different from Catalyst and if there are grounds to reconsider my
[Catalyst] (Catalyst as Communicate tier) XML MODEL
Hi all,
I decided to use Catalyst as communicate layer of a project, I need read xml
and then, serve the data with REST {json} to other.
How I can define a xml model thro socket or every IPC?
Actually catalyst placed on middle of an engine and web interface.
Thanks in advance.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Sunday 15 February 2009 03:04:04 am Dan Dascalescu wrote: First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' around perl anymore... If you look at actual jobs stats: http://tiny.cc/kkcCM Perl is above all the others by some margin. Short version: that graph is misleading. Click the Relative link. Longer version: Yes, Perl is above the rest by some margin, thanks to its history. There are existing Perl applications that need to be maintained, and some momentum that keeps the demand for Perl jobs going. But click the Relative link in the graph, and see the percentage growth for Ruby jobs. It skyrockets when compared with both PHP and Perl. Of course it does. Look at the absolute graph. The 2005 figure for Ruby is, to within the resolution of the graph, zero. It's not hard to have ten thousand percent growth from zero! The absolute graph would have you believe that the huge threat is from Ruby which has gone from zero to perhaps a quarter as big as perl, while the absolute graph makes it clear that the real competition is from the black line representing PHP. And yet if everyone were to abandon PHP tomorrow in favor of Perl it *still* wouldn't make a blip on the relative graph. Why? Because the relative graph is braindead. Andrew ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: template design issue: varibales stand-alone components
* Gene Selkov selko...@observercentral.net [2009-02-05 00:30]: I understood as much. The problem I am grappling with is the complexity of the web pages I have to present, with many different states and transitions. There is no way I can code for that with a single template. Use Chained dispatch in Catalyst to accumulate all the necessary data in the stash, go to a specific template, and then implicitly use wrapper templates to build out the surrounding bits. Mason gives you tools to build a page outside-in (going from generic to specific parts). In Catalyst you use Chained dispatch for that. Your templates should build up the page inside-out, and they should not be calling *any* methods in your model. As far as possible they should only be using stashed variable values. If you call any methods they should only be helper methods from the context like `uri_for`. There should be no application logic in the templates, only display logic. We all know that, right? Well, selecting which component template or which block to use for rendering is more often application logic than display logic. You should be very suspicious every time you put a conditional in your templates. I’m not saying display logic has no conditionals, there are plenty, but stare long and hard at your boolean expressions. Should they really be calculated in the template or should they be passed in through the controller via the stash? Think about coupling; consider how much infrastructure you would have to mock up in order to unittest a template. If you need the whole app set up and running for the template to work, you’re doing it wrong. (I’m not perfect at this by a long shot yet. Short-sighted pragmatism is easier than forethought, and much that is claimed to be forethought is really empty dogmatism.) Basically, to design your Catalyst app properly you need to disregard about 90% of Mason. Imagine it like zoom-in/zoom-out sequence. Chained dispatch zooms in on the most specific part of the page, then wrapper templates zoom out to the full picture. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: Dan Dascalescu ddascalescu+catal...@gmail.com I've just discovered Data::Dump but it appears to beat the crap out of Data::Dumper. Yet does it say anywhere Hey, if you're getting started with Perl and need to dump variables, use Data::Dump, and don't waste your time investigating other modules? If I were the author of Data::Dumper, I'd somehow retire the module, or plaster a note in the POD redirecting people to Data::Dump. Imagine a programmer new to Perl picks up an example that uses Data::Dumper. Will they find out about Data::Dump? No. Someone picks up the Catbook and learns about FormBuilder. Does http://www.formbuilder.org/ mention FormFu anywhere? No. It mentions its last update, March 2007. I also agree, but unfortunately I don't know what should be the solution for this kind of problems. One of the biggest issues for the perl programmers, Catalyst users or not, is to choose the right module for sending email, because I guess there are tens of modules for this task. And to increase the confusion, I have also added one more (Mail::Builder::Simple) and a helper for Catalyst (Catalyst::Helper::Model::Email) that helps using it in a Catalyst app. This is because I wanted to have a perl module that can send email which automaticly encodes the body and headers to UTF-8, in order to be able to include special chars in them, to be able to add attachments, inline images, to create a multipart with a text and html version without needing to create those parts manually, to be able to create the body of the message and the attachments by using templates, and I couldn't find a perl module that can do this. So a Catalyst beginner will hear that he can send email from Catalyst by using a View, then he will find that he can also send email by using a model, and after a few experiences like these, he won't be sure that he uses the right tool. I would be very glad to hear that there is a better module for sending email than the one I wrote, that would be higher level, that would require less code, that would be able to send email using more types of servers, and when I'd find it, I would surely specify in the POD documentation of that module that I recommend the other, and I will surely start using it myself. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html David ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 09:58, Kieren Diment wrote: On 15/02/2009, at 7:50 PM, Russell Jurney wrote: Yahoo has posted some Catalyst specific job listings, so presumably they use Catalyst for something. I can't say much because of confidentiality, but from the Catalyst survey late last year, I can say that there are some pretty high profile places using Catalyst around about. It's public knowledge that two of the biggest streaming media websites in the world use Catalyst. Maybe we can get permission from the respective companies to publicly state that they're using Catalyst? For now, a good starting place would be the Sites using Catalyst page in the wiki (which by the way really should become a featured, maybe even standalone page on the all new Catalyst site which Jay is working on AFAIK). Having popular companies on your side is always a big plus - especially for undecided, buzzword-aware managers :) RoR has a lot of high-profile sites on its site, too ... --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 09:40, Octavian Râsnita wrote: In my country there are no jobs for perl developers. There are jobs for Java, C#, C++ and PHp developers. The knowledge of perl is considered as an advantage in very few job announcements, but it is wanted mostly for administrative tasks, not for web development, and there are very few programmers that even heard about Catalyst. Maybe that's why I wrongly thought that this is the same in other countries. Same here in Germany! The big companies mostly choose Java for whatever, whereas the agile new web startups go with either PHP or RoR. I can only think of one important (German) site from recent times that is built with Perl and AFAIK they're in the process of transitioning to RoR, too. Apart from the US and UK there aren't many countries in the world still using Perl for big web development projects and high-profile sites. I'm already starting to get angry every time somebody pulls out another chart or statistic which is supposed to show that Perl is as strong as ever because this simply is NOT true - at least not for every place in the world. --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
2009/2/15 Dan Dascalescu ddascalescu+catal...@gmail.com: I think I can agree with that. What I'm saying is that there's simply too much useless choice. Random example: Data::Dumper vs. Data::Dump. I imagine there is some kudos in getting a module on CPAN hence there is a lot of overlap. Rather that developers extending or maintaining existing module, there may be a number of reasons for starting from scratch, original maintainer has moved on, new libraries become available, or they simply did not like the way the first worked. In this case Dumper is a core module which opens another issue, on what basis do you decide if a module should be core at the expense of another or worse still, have 2 modules that achieve the sames ends which would be taking TIMTOWTDI to the extreme. Dp. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 15.02.2009, at 13:39, Dan Dascalescu wrote: Aye, that it is: http://www.bbc.co.uk/blogs/bbcinternet/2008/12/iplayer_day_performance_tricks.html Thanks for the link. I added it as a support URL to http://www.appliedstacks.com/website/Bbc_Iplayer Cool, I've updated the Sites using Catalyst page in the wiki. --Tobias ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] (Catalyst as Communicate tier) XML MODEL
joel thanks a lot. Yes, I got my answer [Catalyst::Model::Adaptor]. I already have not a standalone class which acts as a client for the webservice. I have a project that contains two main layer. one of them is engine and other is web interface. I want to know what is your idea and or catalyst's library solution for making communication layer between these two layer. For example engine can configure system's ip addr and the result post back to interface. I think one way is engine generate xml for Catalyst model. Catalyst's model handle this xml and serve as rest. I need a tutorial links. :( Thanks in advance. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] TT Latex Experiences with Catalyst
Hi, Just wondering if there are experiences or recommended patterns to use Template::Plugin::Latex with Catalyst. The idea is to generate hardcopy output from the web app directly to a printer via ipp, lpr, etc. or download as PS or PDF. My question is if anyone is doing such a thing could provide a general idea on how it was accomplished. Thanks, Alejandro Imass ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
I think a lot of folks make good points. I am not arguing that we do not promote things. I am arguing that A) it's not as bad as it first seems. -- and -- B) before we can promote Catalyst / Perl, we have to know where we want to position ourselves. I think it's a mistake to try to compete with Rails for the newbie. Some large percentage of newbies will never do anything more than occasional tinkering if they stick with web development at all. We have limited resources and we don't want to waste our time there. To make Catalyst accessible to the rails-like newbie, we have a TON of work to do and it's the wrong direction, in my opinion. Catalyst is a solid framework with lots of available options, I don't think we should hide that fact. I've worked with Rails, it is what led me to Catalyst in the first place. Rails is great for greenfield projects. Using Rails to replace an existing system is a nightmare. Their 'framework' requires too many adjustments to the problem space (db changes, changes to how authentication occurs, etc.) To be sure, Catalyst works easier if you can make those kinds of decisions / changes. Catalyst has the advantage, though, in the existing system space because it can be made to fit, and in most cases, rather easily. I just went through this process with a client. I had to explain why we chose Catalyst and Robert is correct here. In the enterprise, it's a hard sell. It really comes down to total cost and maintainability. I sold them on Catalyst for a few reasons: 1) There are other perl programmers out there. 2) There are other big companies using perl / Catalyst (iplayer, etc.) 3) Speed of development will increase dramatically. 4) There is commercial support outside of my organization. 5) Catalyst is maintainable and there is a focus on remaining compatible with past deployments. It was not an easy sell by any means, but the biggest issue was not Framework related, but language related. In my opinion, these are the things we need to highlight. We have two markets we are selling to, the developers and the executives / decision makers. The executives need to see the above. A failed project means their job, and that's what they are looking to ensure doesn't happen.This is the information that needs to be out there front and center. We also have to sell to the developer. This is an easy sell for the clueful, but we I agree we don't do a very good job of promoting what Catalyst can do for a developer. I think the key points here are: 1) Catalyst can do greenfield apps very easily, but can also be made to fit in to an existing system. 2) There is a ton of integration to various systems (Authentication, Databases, other sources) that save you huge amounts of time when developing. 3) There are a number of 'helpers' that make it easy to get a basic app up and running. 4) A premium is put on keeping backwards compatibility. Though Catalyst is moving forward all the time, once you build it, it will stay working. 5) We have a hugely helpful community. While they expect you to have a basic clue, beyond that they will go out of their way to help you figure things out. The irc channel should be showcased here. Perhaps even a #catalyst-help should be created with a focus on helping newbies (a web interface to #catalyst-help would be good) If we can communicate these things to newcomers (both developer and executive) we will be in good shape. Again - I don't think we should compete with Rails for the newbie, Catalyst requires some clue and we don't have the time / resources to guide people in learning perl. Again, I think if we really want to compete we should focus on what Catalyst is... and that is more flexible and capable than other systems. Jay On Feb 15, 2009, at 8:12 AM, Robert L Cochran wrote: The fact is that Oracle does not try to compete for the low end of the market with MySQL. They don't want it. They never did. Why do we? The comparison is good, but not very exact. I know companies which don't use PostgreSQL but Oracle, because Oracle is better known (because it offers discounts to the software companies that distribute it, so they have the interest of promoting it), and because Oracle offers tech support. The big companies usually want to pass the responsability to others, even if they need to pay some more. Octavian Well said. Availability of support, tons of free documentation, very flexible pricing options, plus extremely good education and certification programs, is what puts Oracle ahead. There is a huge mass of getting-started type documentation in favor of Oracle, and they make it freely available on the web. They have excellent formal certification programs. I can speak from actual experience -- I've taken several Oracle University classes. In my company, the selection of programming languages is determined by what is specified in our Enterprise Architecture. That specification does not include perl or
[Catalyst] Re: Model Helper and PostgreSql Schemas
Solved.
After hacking the helper classes and dbic loader, I was happy to
discover that the Catalyst folks have though of this. You can pass
anything after user, pass and will get evaled and passed to the
subclasses, so if you do this:
script/inventory_create.pl model [MODEL_HERE] DBIC::Schema
[PATH_TO_SCHEMA] create=static dbi:Pg:dbname=[DB_NAME] [USER] [PASS]
{loader_options={db_schema='[DB_SCHEMA]'}}
This optional hash at the end finds it's way all the way down to the
specific driver implementation of
DBIx::Class::Schema::Loader::DBI::XXX
Just for the record:
Time taken: a bit more than an hour
Tools used: warn, Data::Dumper
On Mon, Feb 16, 2009 at 12:28 PM, Alejandro Imass
alejandro.im...@gmail.com wrote:
Hi,
I am starting a new project that uses database schemas. The Model
helper script does not pass down parameters to
DBIx::Class::Schema::Loader which in turn should pass them down to the
actual DBD implementation in this case,
DBIx::Class::Schema::Loader::DBI::Pg which has code like so:
sub _setup {
my $self = shift;
$self-next::method(@_);
$self-{db_schema} ||= 'public';
}
From the DBIC docs and code, this param can be passed with a hash that
has a key named loader_options, where I can supposedly set
db_schema and should trickle down to the specific driver. But I
really don't know much more at the moment since I've never used the
DBIC::Schema:.Loader outside of Catalyst.
Before I dive further into this and re-invent the wheel, the question
is if anyone here is working with database schemas with Catalyst and
has hacked their own version of the helper script, or perhaps the
helper script actually supports schemas somehow?
Best,
Alejandro Imass
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 15, 2009, at 1:04 AM, Dan Dascalescu wrote: First: Perl jobs are not decreasing. While there is not a ton of 'Buzz' around perl anymore... If you look at actual jobs stats: http://tiny.cc/kkcCM Perl is above all the others by some margin. Short version: that graph is misleading. Click the Relative link. You had some great points below this but I think this one isn't. The relative graph is the misleading one and something so put in print and in conversations with tech managers. The relative graph makes it look like there are tons of RoR jobs. There aren't. Job seekers who need a job now outweigh those that like to gamble on trends and getting hired in the future. A lot of devs, most(?), today are not CS guys. It's not just the kit they'd be investing in but the language. It's not Cat or RoR, it's Perl or Ruby. Perl is simply a better choice for tech work if you're only able to handle one and I personally don't see that changing for a long time. Maybe more important than a user case is a dev case. I've been brought into two projects to do Catalyst and the big concern in both was that there weren't enough developers who knew the framework. And while others have made good points there were many that weren't so hot. Using a big company as an example of a place that picks the best is ridiculous; their size and bureaucracy often mean they can't. When I was at Amazon I watched them burn millions of dollars on dead end projects because they picked the wrong tool for the job. They picked Java to create a highly agile customer service tool. It was an unmitigated disaster that was abandoned for a Perl rewrite 18 months after it was still too slow, too buggy, and incomplete. It's my understanding, though I wasn't there for this one, that they did a project with Ruby to do employee reviews where the whole thing was ditched for the legacy version the day it was to go live because it didn't work outside the dev env. There's some good FUD: Java and Ruby lead the failure of Amazon.com projects and the loss of millions of dollars. I liked everything Jay said about it. My own 2¢ would be that we should each take as much time to make Cat developer-friendly (docs, examples, blog posts) as we can; and some of you are doing a great job at this already. We have a great kit, a great community, and the more obvious and accessible it is, the more we ensure continued success. -Ashley ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: Jay Kuri j...@ion0.com I think it's a mistake to try to compete with Rails for the newbie. Some large percentage of newbies will never do anything more than occasional tinkering if they stick with web development at all. We have limited resources and we don't want to waste our time there. To make Catalyst accessible to the rails-like newbie, we have a TON of work to do and it's the wrong direction, in my opinion. I think most of Catalyst users agree with this. I think Catalyst shouldn't target the market of small personal web sites stored on free web servers, or on $5/month web servers. But I also think Catalyst shouldn't target only the very big sites like Amazon or Ebay, but all the software companies that create web applications for their clients, but of course, the serious software companies, not those that have 1 or 2 developers. We should find why those companies prefer using DotNet and Java even for web sites, and try to show them that Perl/Catalyst is better. Most of them prefer Java/DotNet because they can find more programmers that know those languages, and we can't do anything to show them that there are many Perl programmers also, because there aren't, but we can show them that the productivity of Perl/Catalyst is much bigger than of Java/DotNet, so they won't need to hire so many programmers and finally they will be more efficient. Most of the software companies, or simple programmers know very well that Perl is a language very hard to maintain, because it is not strict, and each programmer can have its own way of doing things, and this is true. But at least we can show that Catalyst is not Perl, like that kind of Perl used in CGI scripts, but it is a language object oriented, it can reuse the code very easily and it is very clear and because of this... easy to maintain. It wouldn't be bad if the next Catalyst book would have a section for Good practice and for Recommended modules, or even better, if these sections would be promoted on the Catalyst's web site. That section shouldn't list a single module for a single operation, but there could be 2, or 3 modules with clarifications for when it is helpful to use one of them and when to use the another, but not let the users to choose from tens of modules of the same kind on CPAN. Another advantage of using Java/DotNet is that now most of the existing software companies already have their own created libraries that can be used on all their projects, so the productivity would be bigger if they would continue to use those languages. But we can show that most of the modules they've made, probably higher level libraries that help them to connect to HTTP and FTP servers, send email, do authentication, and other things, already can be done with modules from CPAN. But if we just tell the world about how great CPAN is and nothing more, it would be a disadvantage, because they will really see how great CPAN is, and they won't know what's good for them in there, and if the combination of modules they found is a good one that really works without having problems in the future. I know a few people that started to learn perl very few years ago, but they've started to learn to create CGI scripts, of course, because almost all the Perl books teach that, at least as an example, and this is not ok, because if they'll pass to Ruby, they would start immediately to create Ruby on Rails apps, and if we compare Perl's CGI with Ruby on Rails... it is very clear who wins. Maybe what I think it would be a good idea might be too aggressive, but I think we should also tell the potential Perl/Catalyst programmers what to not do, something like: The list of books that you should not read, because they are outdated: and The list of CPAN modules you shouldn't use because they are not good: or Don't create CGI scripts, because they are slow, hard to maintain and require too much work and put a very short explanation about why it is not good for them to do those things (and others). And of course, we should also show what the users should preferably do. This way, there are bigger chances that there will appear if not just a single way, at least a limited numbers of ways to create programs with perl, and not an infinite number like now, and if someone will see that a certain site made with Perl is not working fine, he might also see that there was a warning for not making the site that way, because it is not recommended, and the site doesn't work fine not because it is made in Perl, but because it doesn't follow some recommendations. I think that this way of using negative and positive recommendations is the only good way, because otherwise, nobody will convince all the perl programmers not to create new CPAN modules, and reinvent the wheel. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo:
Re: [Catalyst] RFC: The paradox of choice in web development
On Feb 15, 2009, at 12:31 PM, Octavian Râsnita wrote: The list of CPAN modules you shouldn't use because they are not good: Everyone should consider writing more reviews on the CPAN reviews site too. It's directly connected with them. It wouldn't carry the same sort of authority as a formal list from a group but I make my choices of what to at least try first based on reviews somewhat often. See also: http://www.perlfoundation.org/perl5/index.cgi? recommended_cpan_modules -Ashley ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
From: Ashley a...@sedition.com And while others have made good points there were many that weren't so hot. Using a big company as an example of a place that picks the best is ridiculous; their size and bureaucracy often mean they can't. When I was at Amazon I watched them burn millions of dollars on dead end projects It might not be a good example for developers, but it surely is a good example for the managers. All the managers want to use the same tools used by the important companies, because they can trust the big companies much more than the smaller and unknown ones, and if they would hear that Google uses Catalyst, Ebay uses Catalyst, Amazon uses Catalyst, and successfully, they will trust Catalyst more. Octavian ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] RFC: The paradox of choice in web development
On 16/02/2009, at 7:31 AM, Octavian Râsnita wrote: From: Jay Kuri j...@ion0.com I think it's a mistake to try to compete with Rails for the newbie. Some large percentage of newbies will never do anything more than occasional tinkering if they stick with web development at all. We have limited resources and we don't want to waste our time there. To make Catalyst accessible to the rails-like newbie, we have a TON of work to do and it's the wrong direction, in my opinion. I think most of Catalyst users agree with this. I think Catalyst shouldn't target the market of small personal web sites stored on free web servers, or on $5/month web servers. But I also think Catalyst shouldn't target only the very big sites like Amazon or Ebay, but all the software companies that create web applications for their clients, but of course, the serious software companies, not those that have 1 or 2 developers. I've written two single-user run-the-dev-server-to-get-the-front-end apps with Catalyst in the last 4 months or so (using Catalyst rather than a gui toolkit because 1. I don't know how to program a real gui, and 2. the apps functions are both very closely coupled with the www). One is a simple web publishing tool that once I've written the developer docs I will open source this week. The second is a text mining tool that integrates with Zotero ( http://zotero.org whose 45 table database schema I have to interrogate, and integrate with a much smaller metadata-database) I need to polish this a little bit more before I can release it into the wild. Oh yeah, both these apps work on OS X, Windows and Linux systems, and as the user base are windows users on managed desktops, I've even got an installer that will reliably get my apps deployed without bugging the administrators. So my point is that Catalyst scales well at both ends. 9 million requests per day? Make sure you've got some competent systems architects on your team. Single user app? That's a pretty simple deal if you have a developer or small team who understand the problem space properly (as a lone gun I've found that feature creep is my biggest enemy). Once you're through the learning curve, Catalyst's flexibility is a sunk cost, and the subsequent learning that you have to do is generally much more closely related to the problem space for your app than the mechanics of the framework ( I think this is noticably different with other less flexible frameworks). So the goal of the book we're writing at the moment isn't a walk-through tutorial, but a set of materials designed to get you from raw beginner through the entire catalyst learning curve as quickly as possible - i.e. minimising the cost of the learning curve. My experience watching IT projects (I am not a real programmer) is that project success is frequently a function of the size of the team - there's a sweet spot or somewhere between 3 to 5 developers where productivity is maximised. Once you get over 10 develoers then it seems to me that there are too many parts in the system, and you get bogged down by friction. I think java, .net and maybe python are probably more suitable for large teams due to the relative inflexibility of the syntax, and the verbose approach to semantics - this provides some compensatory lubricant for large teams. OTOH I think that perl can't be beat for teams at the ideal size - Ruby is competing in this space, and we'll see how they go over the next decade. Oh if you have a large project + high levels of political input + not directly related to government revenue collection activities = FAIL :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
