Re: decline and fall of modperl?
> Perrin Harkins wrote: >> On Mon, Mar 23, 2009 at 11:30 AM, Octavian Râsnita >> wrote: > ...and in most parts of the >>> world it is hard to find competent perl programmers. >> >> ...The job >> listings for Perl are strong. They're huge compared to those for >> Ruby. Of course Java is massively more popular than either of them, >> but that doesn't make the perl market small. > > I wouldn't use the word 'most', but here in Southeast Asia it's a real > challenge to find a Perl developer with significant experience in Perl/ > modperl. Those who do use it as a minor scripting tool in their unix > administration. > Having run a Perl and Java based technology company in Singapore myself for a chunk of time in the early 2000s, I agree that there is some truth to that. We did run into that as an issue and did end up importing Perl and mod_perl talent overseas including some people who post here relatively regularly who were able to enjoy a stay in SE Asia. However, some markets are going to be a bit different. I think what you are saying reflects also what a search of a Singaporean jobs database has in it. Whereas in USA and Europe PHP = Perl in # of jobs, even in Singapore, the number of Perl jobs is less than half of PHP and both small than Java. From jobstreet.com.sg, Perl:18, PHP:51, Java: 210 With that said, that forms a relatively small n looking at one country -- although I imagine there should be little difference in Malysia etc. At the risk of sounding American-centric, the number of jobs in America and Europe is nonetheless a good chunk of the technology development in the world so I believe the statistics are still compelling on those job sites about relative use of the technology -- Gunther
Re: decline and fall of modperl?
> Alright, I don't want to quibble, but I would question any conclusions > you can draw from the numbers based upon the sole fact that it is > based upon how developer self-identify. > Every language has it's own sub-languages or frameworks that they identify themselves as. So I suspect the statistics Lupe posted are OK on average and reflecting the general reality and representation of job availability. Adding onto what Lupe has posted, I can confirm my own quick search on www.monster.com (nationwide). Keywords: Perl, PHP, Java, Ruby yield the following as of 5 minutes ago. Perl (1795), PHP (1145), Java (4940), and Ruby (318) If you wish to add Drupal or other keywords, you may want to consider doing so rather than leaving open speculation. If PHP is a skill needed for the job, I suspect it will appear *somewhere* in the job description. If you search Drupal on monster.com for example you will see a lot of PHP overlap. Addressing some other themes I've seen here (not a direct response to you) - Perl has been around a long time without much change I am not sure why anyone thinks that is a bad thing. The fact that it is a stable language seems 'good' to me. It hasn't changed because it does it's job really well for what it does. - That the amount of tools that exist for Perl are 'confusing' I am not sure that is the case. The # of tools that exist does offer choice and it can be a bit difficult to weed through the bad stuff to get to the more useful tools, but that's what a mailing list like this can help with. Someone can easily post saying "I need something to do X Y and Z and I am interested in the underlying power of mod-perl or perl, can you guys help me" and there's always posts where people do help guide. Still though, it's not like it's really that hard. People here on the mailing list like Perrin have written up talks comparing different toolkits which can inform the community as well. And even without those resources, if you are used to working with open source tools you can usually visit and website and within 5 minutes figure out if it's active and booming community or a dead horse. So I see little problem really. In fact, the choice is a great thing. As Perrin I think said earlier (I'm paraphrasing liberally I suspect), if a company has already made up their mind ahead of time to use or not use a technology, it's pretty easy to bash whatever you want. That's why I liked Lupe's statistics on German job market, and I can back up the ratios of jobs with the USA www.monster.com website which makes me comfortable that his #s are probably reasonable representation of job market reality without FUD getting in the way. Best regards, Gunther
PerlEx and mod_perl
I apologize if this has been posted here before, but I don't recall seeing it. The ActiveState guys recently posted that they are stopping all development (although support will continue through March 2005) on PerlEx. http://www.activestate.com/Products/PerlEx/ For those that are not aware, PerlEx is very similar to mod_perl and even uses a modified version of Apache::Registry to manage scripts run through it. I mention this news in case anyone who has experience in mod_perl and Windows versions of Perl is interested in helping the newly orphaned come over to the mod_perl side as a natural, eventual course of migration. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: velocigen
The following talk link discusses how to do something similar to what you ask http://conferences.oreillynet.com/cs/os2001/view/e_sess/1262 I am not sure if Oreilly allows the presentations to be downloaded for old conferences somewhere on their website. If not, email me privately and I will dig up the slides for you. In summary, you will probably do well by replacing start() and end() fnctions with BEGIN, END blocks instead and using Apache::PerlRun instead of Apache::Registry since Velocigen is more similar to PerlRun. Try Apache::Registry though because Apache::Registry is even better (but more finicky about how you write your code). Anyway, I am 95% sure that this would let you run your velocigen scripts mostly in mod_perl with minimal hassles. AxKit is really a tool on top of mod_perl, so migrating velocigen scripts to AxKit is really another issue entirely. Good Luck flav wrote: Hello I'm trying to migrate some velocigen script to mod_perl did someone do it before ?? I'm trying to use axkit If someone knows some tools... Thanks -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Domain Name PR was Re: mod_perl presence at OSCON (and other CONs) is at danger
Chris Shiflett wrote: --- gunther <[EMAIL PROTECTED]> wrote: www.mod_perl.com (doesn't exist) www.mod_perl.org (doesn't exist) A small point, and I would have to double-check, but I don't believe underscores are allowed in domain names. You'd want to replace those with hyphens. Right, and that brings up another thing I want to change! :) Actually you are right. Technically underscores are not allowed although I think some DNS servers and clients may support it (esp. from the microsoft world?). Even though the original? DNS RFC supports hyphens, I remember that many years ago when I worked for red-cross.org, the hyphen worked OK on the server and many clients, but some email clients didn't like the hyphen at all and said it was an invalid domain name if someone wanted to send email to us. So eventually it was changed to redcross.org. But if some clients do support underscore, since mod_perl is frequently written with an underscore, may as well get that domain name too in case the client supports it and someone actually types www.mod_perl.com or www.mod_perl.org. But still having modperl.com as a primary project-name related domain name would be there for people who can't type _. Regardless, this part (as I think you meant) is just a detail where the main point shouldn't necessarily be lost as discussed below. A Google search for mod_perl gives me the mod_perl Web site, the user guide, Stas's book, and Geoff's book, in that order. Those are all pretty good resources, and this is where people looking for mod_perl information are likely to end up. I think the more important issue is making mod_perl something for which people search for information, because they've already heard about it through other means. You are right, but the point is to improve the PR. I am not contending that people cannot find what they are looking for. I could find pubmed's real URL by searching on google also (following my example of www.pubmed.com instead of the long national library of medicine URL). But the point is one of convenience and perception. [Convenience] It's convenient to remember that major projects or entities generally have a domain name that links to them. Do you think www.newegg.com would be satisfied as www.web66.com/~newegg? (or substitute whatever you like bestbuy.com, pizzahut.com, and even... perl.com etc...) The fact that you have to remember perl.apache.org instead of modperl.com is not so convenient unless you go to the site all the time or have it bookmarked. Most people on this mailing list probably do both so maybe you don't see this being a problem, but to the infrequenters, it's nicer to not have to remember what the "trick" was (Oh yeah, mod_perl is an apache project, so it's not it's own domain name, it's perl.apache.org). I am also not saying to give up perl.apache.org. www.modperl.com could simply redirect to perl.apache.org. [Perception] I could be wrong, but I think the message of key www.modperl.com URL belonging to a mere single book on the market sends a message that is not optimal to how the mod_perl community should present itself.. I perceive a project where a couple people (even if they are people without whom mod_perl wouldn't exist! :) ) taking the www.modperl.com domain name for a book rather than allowing the project itself to utilize that domain name is not serving the community at large. At best it is not convenient for the community at large, at worst, it sends a message of fragmentation that the project couldn't even get it's own domain name and "looks like" some private couple of people took it out from under the community (regardless of whether this is true or not). I could understand why the authors would want to take the domain name for themselves because it will give them a lot more hits (which arguably increases the sale of their book), but I would argue that mod_perl books as a whole will sell better in general if the project itself has the added convenience of it's own primary domain name. Enhancement of PR of mod_perl is good for everyone who sells a mod_perl book including the original authors (I would think). [How Important Is This...Really?] Anyway, I am talking PR here. Many PR things are actually unnecessary to do. You could spend the next 5-10 years without www.modperl.com pointing to the real mod_perl website and it probably would only make a small difference, but still I think it would be a difference so I added it to the "to do list" of what I personally believe should happen to enhance mod_perl PR. It's OK if people disagree with me of course. :) :)
Re: mod_perl presence at OSCON (and other CONs) is at danger
free Perl apps out there, but mod_perl apps on perl.apache.org tI count about 15 apps total (not counting "toolkits" or core "tools" like CMS systems). This is part of a chicken and egg problem. On the one hand, if you have a lot of apps, you are more likely to see adoption of the technology and if the technology is well adopted, you are likely to see a lot more apps. Along with the apps is the convincing of the ISPs to support mod_perl. How many support PHP (A lot I would gather?) and how many support mod_perl? I gather it's about 50 from the directory of ISPs on the mod_perl site, but how actively do they really support mod_perl? Do they support it? Or does it come by default along with PHP with every single shared user www account someone gets for the going rate of 9.99$/month? Another issue... has anyone gone to the following URLs: www.modperl.com -- a website for the "first" book but the link to the real modperl site is actually buried way down as one of the links www.modperl.org (some consulting firm called powerdata?) www.mod_perl.com (doesn't exist) www.mod_perl.org (doesn't exist) For PR, I would think it would be nice for common URLs such as these to be freed up and appropriately used or redirected to perl.apache.org As an only semi-frequent user of perl.apache.org, I really prefer typing www.modperl.com or .org and not having to remember the *.apache.org convention. Call me crazy, but even though I use pubmed several times a week, I still find myself just typing www.pubmed.com instead of the real url: http://www.ncbi.nlm.nih.gov/entrez/query.fcgi. Similar concept. Gosh, I guess I am being very negative in this email. Sorry if I come across that way. I could be wrong, but I suppose a positive way moving forward would be to resolve the following issues to generate more positive PR for mod_perl in the following summary: 1) Promoting classes of applications that use mod_perl eg Success stories for classes of applications that use mod_perl (maybe even bioinformatics) a once a month "interview" with someone using mod_perl successfully would make a nice repetoire of more stories. 2) Promoting applications that use mod_perl If you've written a useful app that uses mod_perl at your workplace, please see if your employer would consider allowing it to be open sourced. 3) Let's get the domain names in order. eg It's nice that Lincoln and Doug have had modperl.com all these ages, but now that their book has been out for years, it would be nice to give the URL back to the community and instead have their book use a more appropriate URL like modperlbook.com. Likewise for other URLs. 4) ISPs That support mod_perl This is a tough one but I think it would be interesting to know what supporting mod_perl means for the 50 ISPs on the list. Is there a way that they can share their secrets (ala #1) to encouraging other ISPs to support mod_perl. Can people evangelize the use of mod_perl on their servers? I suppose this may only happen if there are enough apps in #2 to force the ISPs to want to enable mod_perl by default though... 5) Create a google bomb whereby when "web apps of mass domination" is searched, perl.apache.org comes up. Then report the google bomb as a news item on slashdot. I guess I should stop my spewing now. I wish everyone here luck in promoting mod_perl. Thanks, Gunther
Re: Comments on Struts-like mod_perl module
Stuart Moffatt wrote: All, About a month ago, I was put on a project that was perl-based, but with no framework. As our GUI team develops mostly in java, and now mostly with struts, I came to love the MVC architecture. Simple to estimate, design, and maintain. I loved struts mvc so much that I implemented a struts-like framework in plain old CGI. I used it for the perl project with great success: quick, modular development from the client to the API. I like this as well. How is the performance under CGI though? Do you support an identical config to struts? Which version of struts do you support? Do you sit on top of wombat? The Perl Servlet API? I called it Straps (STRuts - A Perl Substitute). [Struts-developers: Let me know if I've broken the rules for embedding Struts in the nickname]. It is a bit of a cutesy name, but I didn't want to assume I could use Struts.pm -- and it really isn't just an interface to a struts-ish servlet, it actually replaces one. Sounds good to me. The main controller, rather than a java servlet, is a cgi installed in the docroot at /straps/servlet.cgi All requests go through this cgi, fire off Actions and ActionForms (just like struts), store data in the session. and then land on a resulting cgi page that would get the data out of the session and load up an HTML::Template for the view. The ActionForms contain our application data models. Interesting! Do you emulate the Struts widgets in HTML::Template? All in all, a rudimentary, but working version of a perl implementation of struts. But like most CGI apps, there were failings (performance, URI control, etc) In the last two weeks, I've converted the "servlet" cgi to mod_perl, and made it look like a real struts servlet. I have not ported the application yet, but I have a new project that is also perl so I will build this app on top of the mod_perl version of Straps, which I am tentatively calling Apache::Straps. You all know the kinds of speed improvements I've seen (100-150x on the loading of the framework alone with a small test application), not to mention the hooks into the URI-mapping and request cycle that I am ecstatic about. I think the Apache-specific one should be Apache::App::Straps (similar to Chris' thing) but that you should make this module as Apache-specific as possible but require CGI::Straps or Straps or CGI::App::Straps as the core set of modules that defines straps. If you put this project primarily under the Apache::* namespace, it will be mistakenly branded as being Apache-specific which it shouldn't be IMHO. The best two examples of modules that were created under Apache::* namespace and still (I believe) confuse people into thinking they are only for mod_perl is Apache::Session (which can be used for CGIs) and Apache::DBI (which can be used for other persistent Perl environments). I personally believe you should avoid this problem. In addition, there are many other mechanisms for improving performance of CGI from SpeedyCGI and I think Matt Sergeant has a PersistentPerl interface, and then there is ActiveState's PerlEx (Not greatly supported these days but it does exist )for IIS and Velocigen as a commercial product to embed Perl in Netscape And ISAPI Servers like IIS... etc.. So I think if a group of people used SpeedyCGI, you might find your CGI version of Straps having reasonable performance. Anyway, I thought the Right Thing To Do was get the idea out on this list before any upload to CPAN, etc. I suppose at some point I'd have to talk to the Struts people to find out if they mind as the framework and config file uses the same naming conventions as struts. Comments? Where is the website? straps.sourceforge.com? :) Is there a mailing list I can subscribe to? You might want to also cross post to the p5ee mailing list ... as servlet API to some degree falls a little bit under p5ee (servlets being a part of j2ee). Good Luck! Gunther -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
