Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: ModPerl

Re [OT]: mod_perl output filter and mod_proxy, mod_cache

 

 

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded


aw at ice-sa

Jul 14, 2011, 10:41 AM

Post #1 of 3 (453 views)
Permalink
Re [OT]: mod_perl output filter and mod_proxy, mod_cache

I'll have to watch my language here, as I might otherwise get ostracised on that other
list of mine.

Tim Watts wrote:
> On 14/07/11 14:38, André Warnier wrote:
>> Tim Watts wrote:
>> ...
>
>> "I think for this problem, I have to treat tomcat as a little, rather
>> inefficient, black box .."
>>
>
> They liked that quote then? ;->>>>
>
> <OT Rant>
>
> I'm sure it's a lovely development environment (there must be some
> reason people use it) - all I know is it's a resource hungry bitch
> that's never happy unless it has GB's RAM and at least 2, preferably 4
> fast cores. And if you p*ss it off, it will eat your swap and burn all
> your cores at 100%. Bane of my sysadmin life...

We should start a club.

>
> Don't get me started on the readability of its log files!!

Or worse, the logging configuration.

>
> That's across a wide range of applications including commercial stuff
> like Confluence.
>
> Bah - give me mod_perl (or even mod_wsgi+python) anyday...

+1

>
> I've got a lot done with HTML::Mason+mod_perl and very efficiently (for
> such a simple templating system) and I've considering Mojolicious for
> fun. Learning django too right now too for the cool forms+DB stuff.
>

We have been re-developing stuff that is based on ****, using mod_perl and TT2 for now.
It works faster, uses umpteen MB less memory, and may soon deliver us from the management
of that ****-based stuff too.


> Thankfully, our guys are making a switch to django away from **** and
> it is so much nicer to manage.
>
Don't know it, but will have a look.

[OT, ADVOCACY]

I am partial to perl and CPAN, because there are just so many things I have been able to
do with them over the years at little expense to solve real-world problems.
And despite the fact that I also use a lot of OO modules in perl, I just cannot get in
sympathy with a language like *****, where it seems that you have to mobilise a couple of
dozen classes (and x MB of RAM) just to print a date or so.
Never mind the time spent trying to find their documentations.

As a matter of fact, when I am confronted with a new kind of problem, in an area where I
know a-priori nothing, my first stop is usually not Google nor Wikipedia but CPAN, just to
read the documentation of the modules related to that area. Whether you need to parse
text, to process some weird data format, to talk to Amazon, to make credit-card payments,
to dig out and generate system statistics, to understand how SOAP works, to drive an
MS-Office program through OLE (and know nothing of OLE to start with), create a TCP
server, convert images, read or create and send emails, or whatever, you always find an
answer there. Even if in the end it turns out that the answer is not something in perl,
there is so much knowledge stored in CPAN that it is a pity that it is only consulted by
perl-centric types.

[IDEA]
Maybe creating a website named WikiPerl, containing just the CPAN documentation with a
decent search engine (KinoSearch/Lucy ?), would help restore perl's popularity ?

Or do we just keep that for ourselves, as the best job-preservation scheme ever designed ?


Ooops. I was just about to send this to the wrong list...


niels at genomics

Jul 14, 2011, 11:09 AM

Post #2 of 3 (436 views)
Permalink
Re: Re [OT]: mod_perl output filter and mod_proxy, mod_cache [In reply to]

Yes, CPAN has very, very useful things. I consider its biggest problems
1) too difficult to find things when not knowing what one wants, 2) a
huge undergrowth of modules that are either bad quality or unmaintained
or duplicated with a later module. The number of lingering bugs are an
obstacle, yet at the same time super-useful things are "hiding" in plain
view.

Apropos, Perl Dancer was "hiding" for me because I didn't see it here,
http://search.cpan.org/modlist/World_Wide_Web .. but many more such
discoveries in the past. A simple global ranking by popularity (the
number of times downloaded) and/or by size and maturity (time located
on CPAN) would expose many "new" things to many, I think. If other
modules depend on them, then that may speak to quality somewhat, and
much better rating could be done. MongoDB would probably make managing
the collection easier. But, I am grateful for what exists of course.

While watching the language certainly, I'm moving from Apache/mod_perl
to Dancer/Nginx for speed and memory reason.

Ok, back to lurk-mode,

Niels Larsen


> [OT, ADVOCACY]
>
> I am partial to perl and CPAN, because there are just so many things I have been able to
> do with them over the years at little expense to solve real-world problems.
> And despite the fact that I also use a lot of OO modules in perl, I just cannot get in
> sympathy with a language like *****, where it seems that you have to mobilise a couple of
> dozen classes (and x MB of RAM) just to print a date or so.
> Never mind the time spent trying to find their documentations.
>
> As a matter of fact, when I am confronted with a new kind of problem, in an area where I
> know a-priori nothing, my first stop is usually not Google nor Wikipedia but CPAN, just to
> read the documentation of the modules related to that area. Whether you need to parse
> text, to process some weird data format, to talk to Amazon, to make credit-card payments,
> to dig out and generate system statistics, to understand how SOAP works, to drive an
> MS-Office program through OLE (and know nothing of OLE to start with), create a TCP
> server, convert images, read or create and send emails, or whatever, you always find an
> answer there. Even if in the end it turns out that the answer is not something in perl,
> there is so much knowledge stored in CPAN that it is a pity that it is only consulted by
> perl-centric types.
>
> [IDEA]
> Maybe creating a website named WikiPerl, containing just the CPAN documentation with a
> decent search engine (KinoSearch/Lucy ?), would help restore perl's popularity ?
>
> Or do we just keep that for ourselves, as the best job-preservation scheme ever designed ?
>
>
> Ooops. I was just about to send this to the wrong list...


clint at traveljury

Jul 14, 2011, 11:11 AM

Post #3 of 3 (441 views)
Permalink
Re: Re [OT]: mod_perl output filter and mod_proxy, mod_cache [In reply to]

Hi Niels

On Thu, 2011-07-14 at 20:09 +0200, Niels Larsen wrote:
> Yes, CPAN has very, very useful things. I consider its biggest problems
> 1) too difficult to find things when not knowing what one wants, 2) a
> huge undergrowth of modules that are either bad quality or unmaintained
> or duplicated with a later module. The number of lingering bugs are an
> obstacle, yet at the same time super-useful things are "hiding" in plain
> view.

Check out http://metacpan.org - it's a GSOC 2011 project that aims to
improve cpan search. Tagging and user ranking (plus integration of
those into the search results) are next on the feature list

clint

ModPerl modperl RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.