Re: [Catalyst] upstart script for Starman-based app?

2012-05-07 Thread Dave Rolsky

On Mon, 7 May 2012, Octavian Rasnita wrote:


With Starman, the parent stays active, and it's what should be killed when
you want to stop the process.


I see that this is not happening, at least if starman receives the --user and 
--group parameters.

I have use --user teddy --group teddy in the upstart config, and even though I execute start 
prg and stop prg from the root account, all the starman processes are owned by 
teddy account. And there are 11 processes, even though I asked starman to run 10 children, so the 
master process is also owned by teddy account.


Hmm, weird. Maybe I'm wrong, in which case I have no idea how my config 
file works without expect fork.



I've seen that not all the processes started automaticly use upstart under 
Ubuntu.
For example, I can manage apache2 process using
service apache2 status
but not
status apache

because apache2 uses a SystemV script.

I read somewhere that upstart can work somehow with upstart scripts, but 
that the old SysV init scripts are also executed... but I don't know if 
it can also work in the same way with SysD scripts...


Ubuntu is in the process of moving things from SysV to Upstart. In 10.04, 
very few daemons use upstart. I expect that's changed in 12.04.


Regardless, using systemd doesn't seem feasible.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] upstart script for Starman-based app?

2012-05-06 Thread Dave Rolsky

On Fri, 4 May 2012, Octavian Rasnita wrote:


expect fork


I'm not sure why you need this. There's no fork happening with your config, 
AFAICT.


But isn't Starman doing a fork?


Yes, but the expect fork is telling upstart to expect the process to 
fork once and create a single child, letting the parene exit. Upstart will 
track the pid of the child and kill that when you stop the process.


With Starman, the parent stays active, and it's what should be killed when 
you want to stop the process.


To be honest, I kind of hate upstart. It's really freaking inscrutable and 
the docs suck. I've gotten some info out of it by putting it into debug 
mode and watching /var/log/daemon.log


I really wish Ubuntu would just kill upstart and switch to systemd.


I have never used nor seen a systemd script although I heard about it.
I was able to compare just the huge and complicated systemv init scripts and 
upstart, and upstart is better (if it works:)


Isn't OK to install systemd using apt-get?

I've found that there is a systemd package available for Ubuntu:
p   live-config-systemd   - Debian Live - 
System Configuration Scripts (systemd backend)


That won't magically make all the other packages use systemd instead of 
upstart, and I don't think trying to run two init daemons is a great idea 
;)



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] upstart script for Starman-based app?

2012-05-03 Thread Dave Rolsky

On Thu, 3 May 2012, Octavian Rasnita wrote:


Does anyone have an upstart script that can be used for automaticly starting a 
Cat app using Starman?

I use Perlbrew and local::lib and I start the app in my own account and not as 
root and I don't know how to make upstart start the app under my account.
Maybe it will be helpful to see an upstart script that works, and try to adapt 
it.


Here's an upstart script I use for vegguide.org. Note that I have root 
access to my server, so you'll need to adjust a bit.


  description VegGuide starman server

  start on (local-filesystems and net-device-up IFACE!=lo)
  stop on runlevel [016]

  respawn
  limit as 524288000 524288000

  pre-start script
  mkdir -p /var/run/vegguide
  chown www-data:www-data /var/run/vegguide

  mkdir -p /var/log/vegguide
  chown www-data:www-data /var/log/vegguide
  end script

  exec /opt/perl5.14.2-no-threads/bin/starman --listen 127.0.0.1:8088 --workers 12 
--preload-app --user www-data --group www-data 
/opt/perl5.14.2-no-threads/bin/vegguide.psgi 2 /var/log/vegguide/error.log

This code base is in a git repo at git://git.urth.org/VegGuide.git

I also have a log monitor script which was watches this error log and 
emails me when there are errors. I start that via upstart too, and it's 
dependent on this job.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] RESTful response codes.

2012-02-23 Thread Dave Rolsky

On Fri, 24 Feb 2012, Bill Moseley wrote:

This consumer of he API is arguing that the 2xx HTTP response are not 
enough of a status -- that every request needs a status (and that 
should not mix HTTP transport codes with business logic).  But, I 
cannot think of an example where this would be the case.


So you do GET /user/1234 and it returns a 200 with a status saying { 
status = here's the user you asked for, but I was not able to look up 
their LDAP id because the server was down.  Hope you don't mind the 
omission. }.  That's a scary road to head down, no?


I cannot think of a POST, GET, PUT, or DELETE on a resource where the 
status cannot be represented with HTTP response status -- because that's 
how it is designed.


I think part of this comes down to your choice of URI and what represents 
a thing in your web app.


If you're able to separate each thing into a sane URI and support PGPD as 
appropriate on every URI, then the HTTP statuses should just work, for 
some value of just.


One thing that can be a bit though is some sort of batch update, where you 
want to update more than one thing at once for efficiency. What do you do 
if part of the batch succeeds and part fails? Maybe you just run 
everything in a transaction so this isn't possible.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/___
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 generating emails -- how to buffer large attachments?

2011-12-26 Thread Dave Rolsky

On Fri, 23 Dec 2011, will trillich wrote:


We switched to Mail::Sender -- it opens a connection to the SMTP server 
immediately, and pipes the output generating on -the-fly, instead of
accumulating beaucoup megabytes in RAM to then ship off the whole thing at once.


This is really not a great idea. The sendmail binary will take the message 
and queue it if the SMTP server isn't available immediately, so uses it 
helps make your app less sensitive to problems with the mail daemon. If 
you don't do this then you're stuck handling retrying logic in your app.


There's no reason not to just stream the output to the sendmail binary.

Rjbs has talked about adding a stream_to interface to Email::Abstract (and 
Email::{Simple,MIME}) which would make this a lot cleaner. I'm sure he'd 
welcome patches.


Courriel already supports a stream_to() API, but you'd need to write your 
own implementation of email parts which are stored on disk. This probably 
wouldn't too hard to implement, though.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Moose Upgrade

2011-04-18 Thread Dave Rolsky

On Mon, 18 Apr 2011, John M. Dlugosz wrote:



On 4/17/2011 9:55 PM, Dave Rolsky autarch-at-urth.org |Catalyst/Allow to 
home| wrote:


Running moose-outdated | cpanm should upgrade everything that needs 
upgrading.


I don't have cpanm, but moose-outdated is good to know about!  Thanks.


cpan App::cpanminus


/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Moose Upgrade

2011-04-17 Thread Dave Rolsky

On Sun, 17 Apr 2011, John M. Dlugosz wrote:

I just updated Moose to 2, on my development system, prepatory to doing some 
Moose explorations.
Catalyst didn't like it one bit.  I'm still installing other updates based on 
things mentioned in errors, when I try and run script/myapp_server.


Any specific advice?


You probably have a bunch of conflicting MooseX modules installed. 
Unfortunately, the warnings from Moose's Makefile.PL are easy to miss (and 
I think cpanm hides them entirely :(


Running moose-outdated | cpanm should upgrade everything that needs 
upgrading.


I see the latest Catalyst::Runtime is marked TRIAL.  Should I use a different 
one on the server?


I've been using this one for dev for a while, and it works fine. If by 
server you mean production, then conservatism is not a bad thing.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Re: General API question: REST + SOAP

2011-04-06 Thread Dave Rolsky

On Thu, 7 Apr 2011, Aristotle Pagaltzis wrote:


This is a very bad idea. No matter what problem you have,
a custom HTTP header is very nearly certainly the wrong solution.
For API versioning it definitely is.


My understanding of REST, at least, is that versioning should be done by 
specifying different Accept and Content-Type headers, like 
x-application/x-myapp-auction-item-v1.


This makes sense with REST, since the URI for a thing should always stay 
the same, but it's representation can vary. The API version is part of 
that representation.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Requesting example code for postfix and Email::Sender

2011-03-21 Thread Dave Rolsky

On Mon, 21 Mar 2011, Kutbuddin Doctor wrote:

I am looking for an example of how to configure catalyst to use postfix on 
localhost to send email (mostly application notifications) via catalyst.


And especially example code from someone who has done this successfully. I 
have seen several recommendations for using Email::Sender with catalyst but 
no examples of how to do this with postfix running locally. All of the 
Transport examples are either SMTP or sendmail. The rest of 
Email::Sender::Transport CPAN documentation is very sparse.


As Will pointed out in his email, you're overthinking this.

However, I think his suggestion that you connect to port 25 is a poor 
choice. The problem here is that this assumes that the server will always 
answer and be able to process the SMTP request.


That's a bad assumption. You could check the SMTP request status and 
retry, or you could make your life a lot easier, and use the sendmail 
binary. This isn't Sendmail specific since basically every mail server 
provides the same implementation of a binary called sendmail.


Usually, this will be implemented as something that just writes a file to 
the server's mail queue, without relying on the server actually running. 
The server will pick it up when it runs, and will handle it from there.


TL;DR - Use Email::Sender::Transport::Sendmail unless you have a really 
good reason to use something else.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] [ANNOUNCE] Catalyst-Runtime-5.89002-TRIAL PSGI Catalyst - third development release

2011-03-03 Thread Dave Rolsky

On Thu, 3 Mar 2011, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:


Apart from less code for each framework, there is the other advantage that
adding support for a new Web server (e.g. Plack::Handler::Mongrel2)
automatically enables this Web server for any PSGI-compliant framework.

While it has been possible to run Catalyst 5.8 on top of PSGI-enabled Web
servers with Catalyst::Engine::PSGI, Catalyst 5.9 goes native and cuts out one
layer of indirection.


The other advantage is that you can put functionality in the interface 
layer (Plack middleware), which means that you have an ecosystem of 
plugins _shareable across frameworks_.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/___
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] Sanity Check -- requesting feedback on chaining approach

2011-02-17 Thread Dave Rolsky

On Wed, 16 Feb 2011, will trillich wrote:


Hmm. Curious about the inline comment there -- how do you do CSV based on
accept-header?


You look for an Accept header that specifies text/csv (or whatever the 
content type is) vs text/html.


Or, if you're using a regular browser, you use a hack where you put 
something like content-type=text/csv in the query string.


Catalyst::Action::REST provides basically everything you need to make this 
all work.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Sanity Check -- requesting feedback on chaining approach

2011-02-17 Thread Dave Rolsky

On Thu, 17 Feb 2011, will trillich wrote:


Okay, so there's a link in a web page that the browser sees that tells it
when following *this* link, ask for a CSV file, as opposed to that normal
HTML hooey you usually ask for. How do we do that, if not thru a URL?


  /path/to/xyzzy?content-type=text/csv


Or maybe I'm missing something really obvious...


You need to read the Cat::Action::REST docs.

Basically, it implements proper REST semantics, and then adds a bunch of 
hacks to get around the fact that browsers suck ;)


The nice thing about the hacks is that they're mostly transparent when you 
write your own controller code, so you can just pretend that every request 
came from a properly RESTful client. In my experience, this makes for 
_much_ cleaner controller code, even if you never actually add support for 
any client besides browsers.


I should blog about this some time.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Sanity Check -- requesting feedback on chaining approach

2011-02-16 Thread Dave Rolsky

On Tue, 15 Feb 2011, will trillich wrote:


Does this seem like a best practice? Comments welcome.


Personally, my take on best practices for chaining is basically make sane 
RESTful URIs.


I like to name my non-public chain point with private subs, and I like
my end points to be descriptive. So given that, I'd probably do
something like:

  package MyApp::Controller::Xyzzy;

  sub _set_xyzzy  : Chained   PathPart('xyzzy') CaptureArgs(0) {  }
sub list  : Chained('_set_xyzzy') PathPart('')  Args(0){  }
# CSV dispatch based on Accept header, not URI!
sub _set_item : Chained('_set_xyzzy') PathPart('')  CaptureArgs(1) {  }
sub item  : Chained('item')   PathPart('')  Args(0){  }

Although nowadays I've started using CX::Routes, which lets me _not_
name the subs themselves. I actually like this, since the subroutine
names don't participate in routing when you use chaining.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Re: Moose/Object error in Catalyst

2010-10-13 Thread Dave Rolsky

On Wed, 13 Oct 2010, Sir Robert Burbridge wrote:


I notice that the relevant bit of Moose::Object (line 39 from the error you 
got) says:
   28 sub BUILDARGS {
   29 my $class = shift;
   30 if ( scalar @_ == 1 ) {
   31 unless ( defined $_[0]  ref $_[0] eq 'HASH' ) {
   32 Class::MOP::class_of($class)-throw_error(
   33 Single parameters to new() must be a HASH ref,
   34 data = $_[0] );
   35 }
   36 return { %{ $_[0] } };
   37 }
   38 else {
   39 return {...@_};
   40 }
   41 }

Based on that, it looks like some object is trying to instantiate with an odd 
number of args, but not just one arg.  Something like
  my $obj = My::Awesome::Moose::Class-new(a=1, b=2, 'c');

The check in line 30 checks if there was just one arg.  Probably, it should do 
something more like
  --- Object.old.pm    2010-10-13 11:03:48.0 -0400
  +++ Object.new.pm    2010-10-13 11:07:15.0 -0400
  @@ -35,9 +35,11 @@
   }
   return { %{ $_[0] } };
   }
  -    else {
  -    return {...@_};
  +    elsif (scalar @_ % 2) {
  +    warn all args should be paired values (e.g. a=1), not: @_;
   }
  +   
  +    return {...@_};
   }
   
   sub BUILDALL {

or maybe croak or something.


This seems like a reasonable idea. Would you mind discussing this on the 
Moose list (mo...@perl.org) or in Moose IRC (irc://irc.perl.org/#moose). 
Or you can just send the patch to our RT queue, bug-mo...@perl.org



Thanks,

-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/___
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] Best practice for setting up database in a complex project?

2010-07-16 Thread Dave Rolsky

On Fri, 16 Jul 2010, Matija Grabnar wrote:

Do you write the database definition mysql/postgresql format, and then dump 
schema to get the Perl classes, or do you write Perl class definitions and 
use something else to output the table creation statements for the

database of your choice?


Personally, I like to write the schema in SQL.

My _reason_ for this is that I actually intend to fully use the database. 
That means defining custom types, adding table constraints, triggers, etc.


The SQL schema file is the primary definition for the database.

And what do you do when the structure of the database changes (new tables, 
new columns, new indexes or foreign keys) - do you use a DB versioning thing, 
or do you do it by hand? If you do use a DB versioning tool,

which do you recommend?


If you're using things like constraints, triggers, etc., then you'll 
almost certainly need to do this stuff by hand.


I've written some tools to help with this as part of a wiki I'm working 
on. You can see it on CPAN (http://search.cpan.org/dist/Silki) or in my 
mercurial repo (http://hg.urth.org/hg/Silki).


I'm pretty happy with how this works, and I've even written a framework to 
do automated tests of my migrations, which is very helpful. It's very easy 
to make mistakes when writing migrations, so tests are pretty valuable 
here.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] How to reduce the memory footprint?

2009-11-23 Thread Dave Rolsky

On Mon, 23 Nov 2009, Julien Sobrier wrote:


I run 5 instances of FastCGI. Each instance was taking about 90MB of memory.
I tried to reduce the memory fooprint by reducing the number of libraries I
used. The memory usage is now 120MB per instance! The memory increase is
probably due to other changes.


If you can, take a look at smem (http://www.selenic.com/smem/) to see how 
much memory these procs are _really_ using.


This tool looks at how much memory is shared between procs and gives you a 
much better sense of how much memory it costs _per process_.


But you need to be on a relatively recent Linux kernel to use it.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Re: Deployment in practice

2009-10-09 Thread Dave Rolsky

On Fri, 9 Oct 2009, Mesdaq, Ali wrote:

At least with the first issue you can roll back the change and get back 
to stable instantly. With the other issue you could be troubleshooting 
for a long time.


But I think the OP (other poster) mentioned packages. Presumably you can 
roll back to an earlier package as easily as rolling back to an earlier 
state of the tree.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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 benchmark 5.7 VS 5.8

2009-09-29 Thread Dave Rolsky

On Tue, 29 Sep 2009, Carl Johnstone wrote:


What everybody else in this thread is referring to as shared memory is
actually the amount of memory that hasn't needed to be duplicated because of
the copy-on-write semantics within the Linux kernel. Unfortunately there's
currently no easy way I know of to get these figures on Linux.


http://www.selenic.com/smem/

This can give you some good numbers on shared memory.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Polymorphism?

2009-07-06 Thread Dave Rolsky

On Mon, 6 Jul 2009, J. Shirley wrote:


Moose method modifiers work just fine on Catalyst code, which I find to
really help with using inheritance upstream.  You'll probably want to


As do Moose roles. I've found using roles in controllers incredibly 
helpful, since I often have similar/same process this data and invoke a 
-search method, where the only thing that varies is what is being 
searched and/or the way the results are being displayed.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] How to use local::lib

2009-06-23 Thread Dave Rolsky

On Tue, 23 Jun 2009, Tobias Kremer wrote:


Cool, but what I really meant to ask was: Is it possible to require a
specific version in your Makefile.PL and have only this version
installed during make installdeps? :) This would possibly solve most
of the CPAN-related deployment problems.


FWIW, Module::Build does support this sort of specificity:

  prereqs = { 'Test::More', '== 0.55',
   'Moose',  ' 0.81, != 0.82',
 }


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Mason + DBI + Catalyst?

2009-05-25 Thread Dave Rolsky

On Mon, 25 May 2009, J. Shirley wrote:


Rather than Catalyst being geared towards TT, I would say Mason is geared
towards being a framework :)


Well, sort of. Mason is quite usable as a pure templating system. I use 
Mason with Catalyst for all my new projects, and the framework parts of 
Mason really don't matter to me.



The view should just be thin templates, in that regard I would recommend
using Catalyst::View::MicroMason (
http://search.cpan.org/~jrockway/Catalyst-View-MicroMason-0.05/lib/Catalyst/View/MicroMason.pm)
which wraps Text::MicroMason (Mason template syntax without the
framework).


Except you also lose really useful non-framework features like 
autohandlers, which are like TT's WRAPPER (but better, IMO).



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] New restarter code in Catalyst::Devel 1.14_01

2009-05-24 Thread Dave Rolsky

On Mon, 25 May 2009, Rodrigo wrote:


Shame we can't use the new pre-loading functionality on Windows though. I
tested with different versions of things and errors just got nastier and
nastier.

IMO, to be able to pick restarter engines via %ENV was also a necessary
change anyway. Say, in the future we could have a threaded implementation,
and that would be a whole new ballgame for the restarter.


For the record, I did try a threaded version, and saw the same weird 
errors on Windows. That's not entirely surprising since Perl uses threads 
for fork() on Windows.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] New restarter code in Catalyst::Devel 1.14_01

2009-05-23 Thread Dave Rolsky

On Tue, 19 May 2009, Rodrigo wrote:


Since I needed to have the restarter working badly on that machine in
particular, I quickly patched the code with Proc::Background. Something like
this:


I implemented something like this in the latest Catalyst::Devel. I did 
more thorough testing on Windows and it seems to really work now.


Please give it a shot on your system.


-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] New restarter code in Catalyst::Devel 1.14_01

2009-05-19 Thread Dave Rolsky

On Tue, 19 May 2009, Rodrigo wrote:


Since I needed to have the restarter working badly on that machine in
particular, I quickly patched the code with Proc::Background. Something like
this:

sub _fork_and_start() {
  my $proc = new Proc::Background(perl $0);  # I'm writing this from
memory; not this exactly, there were more args...
  my $pid = $proc-pid;
...}


Doing this pretty much defeats the point of the new restarter code, which 
was to avoid starting the app from scratch each time.



I think I put threads / async { } somewhere in there before using
Proc::Background but I got an error... and don't recall which. Killing the
thread requires it to die from the inside, sending it a signal of some sort.


Right, that's where I got stuck.


Couldn't the restarter be subclassed then changed in myapp_script.pl through
an %ENV variable?


Sure, but the trick is to come up with something that works reliably on 
Windows, and ideally, has the benefits of the new restarter code.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] New restarter code in Catalyst::Devel 1.14_01

2009-05-10 Thread Dave Rolsky
I recently did some work to rewrite the Catalyst restarter code and make 
it both simpler and less fragile.


The restarter no longer attempts to reload changed modules in an existing 
process. This was fragile, and tended to produce a lot of bogus 
compilation failures.


The new restarter just _tries_ to restart on every change. If the restart 
fails, the server dies, rather than continuing to run with the old code. 
However, the restarter keeps watching for changes, and will attempt to 
start the server on the next change.


I think this makes for a much saner development process. I always found it 
very confusing to make a change, reload a web page, and not see the change 
reflected, only to realize that the server didn't actually reload.


Restarting is also much faster. All of the Catalyst core code is preloaded 
in a parent process, and the server runs in a child. That means that when 
the child is killed and a new child spawned for a new server, it does not 
need to load all that Catalyst code again, just your application.


The new restarter has been moved from Catalyst-Runtime, where it lived as 
a weird bastardized Engine subclass, to Catalyst-Devel, where it lives as 
a standalone Catalyst::Restarter module.


I also switched the actual file monitoring away from the existing 
File::Modified implementation. The new implementation uses a new module I 
wrote called File::ChangeNotify. This module is much better suited to 
Catalyst's needs, as it simply reports on relevant filesystem changes.


File::ChangeNotify is designed so that it is easy to implement per-OS 
subclasses to do file monitoring. It currently comes with an Inotify 
subclass that uses the Linux inotify interface, as well as a fallback that 
is just written in Perl.


I'm hoping that in the future we'll see other OS-specific implementations.

I'd appreciate if people would test out the new code. You'll need to 
regenerate your myapp_server.pl script to actually see the changes. Old 
scripts will of course continue to work, since the old restarter code is 
still in Catalyst-Runtime.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] script/myapp_server -r Can't exec /usr/bin/perl every 3 or 4 restarts

2009-04-30 Thread Dave Rolsky

On Thu, 30 Apr 2009, Matt S Trout wrote:


On Thu, Apr 30, 2009 at 02:44:05PM +0200, Erik Wasser wrote:

On Tuesday 28 April 2009, Matt S Trout wrote:


Two possibilities:

(1) exec a $^X to print @INC to get the normal @INC

(2) use $Config{arch} and /^5.\/ to strip off the extra ones.

Thoughts?


I think (1) is more bulletproof. I think a restart costs a lot of time
and an additional call of $^X doesn't matter here.


I think I agree. Fancy having a go at a patch? I -still- don't use -r so
I -still- can't really shake such a patch out in real world usage :)


My new restarter code avoids this issue entirely. It doesn't actually 
re-execute the initial script (which runs forever), it just restarts the 
web server piece (and reloads the app itself).



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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-02-17 Thread Dave Rolsky

On Tue, 17 Feb 2009, bill hauck wrote:

I'm trying to put together a project to rewrite a job tracking database 
currently running in FileMaker.  The functionality and scope of the job 
tracking system has changed so instead of throwing more money in a 
proprietary, closed system that requires a costly application on each 
desktop I'm suggesting writing it as a web application with Perl  
Catalyst.  The only problem is that I've been told we would have to use 
Java  Struts since it's our corporate standard for web applications. 
Perl, ironically, is used in quite a few places in the company, mainly 
in utility scripts.  However, since we don't have anyone whose job title 
is Perl developer we can't use it for web applications.


This is hardly unreasonable.

I've worked at a number of smaller shops where we were developing a 
Perl-based app. If a developer had decided that they wanted to throw 
together some important tool in Java (or Python or Haskell or Smalltalk or 
...), that would have been problem.


The investment in a language is bigger than just the programmers, even. 
You have build  deployment tools, automated testing setups (you do, don't 
you? ;), sysadmin knowledge, packaging infrastructure, and so on.


Some of that may be language-agnostic, but often a lot of it ties into the 
language and its tools.


Once you've made that investment, it makes sense to stick with it. Just 
because Catalyst and Perl are great tools for webapps doesn't mean that 
they're the _right_ tool at your job.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Re: OT: Use the CPAN, Luke?

2008-11-27 Thread Dave Rolsky

On Fri, 28 Nov 2008, Johan Lindstr?m wrote:


At 06:58 2008-11-27, Aristotle Pagaltzis wrote:

 According to the Mouse docs, Mouse supports the most commonly
 used  features of Moose, but runs in 25% of the time. I'm happy


I think that may be referring to startup time (and the Mouse POD refers to 
compile time actually).


In the context of web apps, if you're interested in performance at all, 
you're obviously not going to use CGI. It's gonna be a persistent 
environment. So in that scenario, startup cost is irrelevant.


I benchmarked a few OO/accessor modules, and Mouse was amongst the slowest 
ones. IIRC there's a 4:1 performance difference between Mouse and immutable 
Moose classes (mutable Moose classes is a disaster, a few percent slower than 
Mouse I think it was). So you make Moose classes immutable.


The benchmark wasn't scientific or anything, basically just a new() with some 
of the default values overridden in the call + a getter access. I think Moose 
was something like 20% behind Class::Accessor::Fast and Spiffy was really 
fast.


Like the Moose docs say, you pay for what you use. In this case, when I added 
type constraints they became the most expensive things beyond the basics, but 
still as performant as hand coding the validation.


I'm pretty sure that Moose (especially when making one's classes 
immutable) has a much bigger _compile_ time hit than Mouse. OTOH, Moose's 
immutabilized constructor is faster than Mouse's.


I think the optimal use case for Mouse is something in a process that gets 
started a lot (a CLI app, for example). In that case, the compile time 
savings can easily outweight the runtime loss.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] Making proxy requests cooperate with uri_for

2008-11-13 Thread Dave Rolsky

On Thu, 13 Nov 2008, Matt S Trout wrote:


On Mon, Oct 20, 2008 at 12:23:38PM -0700, Ashley wrote:

This might be a simple question but I've never had to do it before,
Googling for it is difficult, and none of the main docs seems to have
the info.

I want to run myapp_server.pl script as a proxy as if it were from a
dir.

This is easily accomplished with

ProxyPass /from_dir http://localhost:8080/
ProxyPassReverse /from_dir http://localhost:8080/

The problem then is $c-uri_for(/) returns http://localhost/ when
http://localhost/from_dir is what is really needed.


Dave Rolsky (autarch) had a proxystuff branch that handled this at one
point, but I'm unsure what happened to it.


Nor am I ;)

There was talk of someone (not me) writing more Engine tests before it was 
merged, but I don't think that ever happened. FWIW, I did write tests for 
the bits I changed, IIRC.



-dave

/*
http://VegGuide.org   http://blog.urth.org
Your guide to all that's veg  House Absolute(ly Pointless)
*/

___
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] [Fwd: [rt-users] Security vulnerability in RT 3.0 and up]

2008-07-20 Thread Dave Rolsky

On Sun, 20 Jul 2008, Matt S Trout wrote:


On Mon, Jun 23, 2008 at 01:17:15PM -0400, Lance A. Brown wrote:

H.   Is this something Catalyst needs to worry about?


StackTrace only activates for Catlyst in debug mode.


But if you're writing Mason views, Mason uses Devel::StackTrace 
internally.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] [Fwd: [rt-users] Security vulnerability in RT 3.0 and up]

2008-06-24 Thread Dave Rolsky

On Mon, 23 Jun 2008, Lance A. Brown wrote:


H.   Is this something Catalyst needs to worry about?


The case to tickle this particular bug is that you need to pass bad UTF8 
to a sub that's in the call chain and then generate a Devel::StackTrace 
object and then try to stringify that object.


Also, this only affects some versions of Perl.

So, the short answer is that this is unlikely to be a problem for most 
applications out there. RT, amazingly, happened to do exactly the sequence 
of things I described above.


It certainly will not hurt to upgrade your copy of Devel::StackTrace, 
however.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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 site design drafts feedback thread

2008-06-11 Thread Dave Rolsky

On Wed, 11 Jun 2008, Matt S Trout wrote:


Simon Elliott:

(1) http://www.browsing.co.uk/cat


Overall my favorite. The white text against the bottom of the grey 
gradient starts to fade, but I'm sure that's easily fixed. I wouldn't mind 
making all the non-tab text a little larger, but maybe my eyes are a 
little older than our target audience ;)



Mark Keating:

(2) http://agaton.scsys.co.uk/~matthewt/catsite/cat_mock_web_001.png


The crop circle is great. The colors, particularly in the tabs up top, 
make the text hard to read (not enough contrast). Also, all the fonts seem 
way too small, but maybe that's because this is a screenshot, and it might 
work better in the real version.


It's also a little tough to evaluate, because it's harder to imagine a non 
front page. Presumably we wouldn't want that giant graphic on every page.



Scott Ladzinski:

(3) http://ion0.com/hx/cat/new-version-2-26.jpg


I like the basic idea, I'd like to see it with some real text. It's hard 
to imagine it being better than #1 though.



(4) http://ion0.com/hx/cat/catalystSiteDesign3.jpg


The colors are very jarring (lilac and blue in particular). Too many 
colors, not enough white. Mostly white backgrounds are good ;)



Mike Whitaker:

(5) http://agaton.scsys.co.uk/~matthewt/catsite/catsite-Penfold.pdf


I like the simplicity. It's very similar to #1 though, and I think #1 has 
a bit more panache.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Re: RFC: Catalyst::Controller::REST::DBIC

2008-05-16 Thread Dave Rolsky

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:


- a search


I tend to prefer expressing searches with query parameters… hm.


I understand that what you propose is '/cd?year=1968', is that right?
I really don't know - but some people would prefer to do the search by
POST, or might just like to have the uri as '/cd/search?year=1968'.


Why would anyone care about GET vs POST? I guarantee most users don't 
care.


If you mean they want to use a form, that has nothing to do with the 
method. Forms can submit GET requests.


The URI you propose could be RESTful, if you think of search as a noun, 
maybe short for search results.



Example? I can't quite imagine what you would want to do here.


Hmm - how about a help screen - conveniently at '/cd/help'?


Again, could be RESTful.

One part of REST is that URIs contain nouns, period. The type of nouns, 
the path hierarchy, all that is irrelevant, the key is that the URI never 
contains a verb like submit or edit. Note that edit_form is a noun, 
and is perfectly RESTful, and _necessary_ if you plan to have browsers 
interact with a set of RESTful URIs.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/___
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] Re: RFC: Catalyst::Controller::REST::DBIC

2008-05-16 Thread Dave Rolsky

On Fri, 16 May 2008, Zbigniew Lukasiak wrote:


Why would anyone care about GET vs POST? I guarantee most users don't care.

If you mean they want to use a form, that has nothing to do with the method.
Forms can submit GET requests.


It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).


I think you mean _upload_, right?


The URI you propose could be RESTful, if you think of search as a noun,
maybe short for search results.


OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).


I have no strong opinion on this. I was just pointing out which URIs were 
RESTful and which weren't.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Re: So, what do we want in the -next- book?

2008-04-27 Thread Dave Rolsky

On Mon, 28 Apr 2008, Aristotle Pagaltzis wrote:


I’m not talking about COMPONENT. I’m talking about classes with
accessors for which they never set a value themselves. I don’t
remember specific examples since it was two or three weeks ago,
but it had to do with the dispatcher, and I stumbled this way in
two or three places when I didn’t have time to read the entire
source, so I gave up and switched to a different approach.


A good example is Catalyst::Request. Several other classes poke into it's 
internal hashref, including Catalyst.pm and Catalyst::Engine. It's pretty 
nasty.


I think the Catalyst 5.8x+Moose branch has improved this a bit.


-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/___
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] Multi-language and REST

2008-04-25 Thread Dave Rolsky

On Fri, 25 Apr 2008, Ian Docherty wrote:


http://www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z12

Yes, I have done this previously, it is elegant, but not RESTful and does not 
make it easy for users to change their settings on a site-by-site basis 
dynamically, as you could if you provided a language selection box on each 
page.


Why do you say it's not RESTful?

I think it's very RESTful, but it depends on how you think about it. If 
the language of the content is basically an issue of formatting, then 
switching language based on a header is perfect. The client provides 
sufficient information to produce a correct response _on each request_ as 
part of HTTP. This is basically the essence of REST.


OTOH, if you consider each language's content fundamentally separate 
things, then each language should have its own set of URIs.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Re: Multi-language and REST

2008-04-25 Thread Dave Rolsky

On Fri, 25 Apr 2008, Aristotle Pagaltzis wrote:


* Ashley [EMAIL PROTECTED] [2008-04-25 22:20]:

I like PUT and DELETE too but I'm not going to abandon POST as
their stand-in (or fall-back) any time soon.


http://search.cpan.org/dist/Catalyst-Request-REST-ForBrowsers/

autarch++


Thanks.

This module illustrates what I'm trying to adopt as a general principle of 
my REST development. Browsers suck, but that doesn't mean the internals of 
my app need to suck as well. You can design the core of your app using 
strict REST principles, and then put some shims around the edges to 
handle the real world.


This has the side benefit of giving your app a nice clear internal 
structure. In my controllers, I still have methods like user_PUT, 
user_DELETE, users_POST, etc. If you know REST, you probably have a 
_really_ good idea of what those do.


For the language stuff, you could do something like have a plugin that 
stripped out a language prefix from the URI early on, and then set 
something in the request.


Better yet, you might do something like this:

* check for a URI prefix
* then check Accept-Language

Of course, any sort of URI fixup scheme involves some burden on the part 
of the application to generate the right URIs.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Unit Testing

2008-04-19 Thread Dave Rolsky

On Sat, 19 Apr 2008, John Romkey wrote:

I suspect that most Catalyst users build their applications so that the 
controllers do too much work. I certainly did, and I'm gradually rewriting 
mine to move most of the work into the model. Where before my controllers


A good way to approach a webapp is to think of the Controller as a thin 
shim between the the web/HTTP environment and your model.


The controller code should handle web/HTTP-specific things like URIs, form 
submissions, etc. and translate that into API calls on model classes. It 
also might handle something like authentication, since the way you 
authenticate a user via the web is different than how you'd do it via the 
command line.


Besides the testability benefits, another benefit is that it makes it easy 
to reuse this business logic in things like cron jobs, daemons, and 
command line driven code. Invariably, any app of a certain size will need 
this flexibility.


Of course, the ultimate benefit is that it's the only sane way to write an 
application ;)



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Sending email safely with Catalyst

2008-04-11 Thread Dave Rolsky

On Fri, 11 Apr 2008, Jonathan Rockway wrote:


In an ideal world, you should be able to dump the messages into your
mail system's queue as quickly as you can dump them into a database
table (adding to the mail queue is a disk write, adding to a database is
a disk write, unless you've turned off data integrity).

I could see how calculating the text of 1 mail messages during a
request would be slow, but why would you want to do that?  Usually
you'll just want to say Your account was created, [% name %]! and
queue that.  The template rendering and the mail system's queue should
be more than fast enough to handle that during a request.

As for bulk emails, you probably have a process that calculates those
outside of your Catalyst app anyway (running from cron), so calculate
them, dump them into the mail queue, and let your mailer daemon figure
out what to do.  Much better than putting a queue in front of a queue,
IMHO.  This is UNIX after all.


The big problem I've run into when sending lots of emails from a web app 
(just hundreds, in this case), is that it can be slow enough the browser 
times out.


Presumably you could have a similar problem with a work queue as well.

Ultimately, I suspect a solution that forks _immediately_ and then does 
its thing (whatever that thing may be) is going to be necessary past a 
certain scale.


Then the trick becomes monitoring that forked process.

Another solution might be to come up with a way to queue up the job with a 
single write and do the full email generation via cron. Either way, you 
have to add complexity to your app if you want to provide feedback on the 
job status to the user.


I'll be working on this soon for an app I'm creating, and I suspect I'll 
go the route of doing a single insert and processing via a cron job. The 
upside of this is that for a multi-user app, I won't end up forking a 
whole bunch of email sending processes and I can exercise some control 
over the rate that email is generated.



-dave

/*==
VegGuide.Org
Your guide to all that's veg
==*/

___
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] Malformed class Name Hidden files

2008-01-30 Thread Dave Rolsky

On Wed, 30 Jan 2008, Jonathan Rockway wrote:


I have traced this down to the fact that my text editor (TextMate)
likes to leave hidden files around with similar names as those being
edited. For example the above error says something about ._MyAppDB
where this a file named MyApp/lib/MyAppDB.pm AND a file MyApp/
lib._MyAppDB.pm

If i delete the ._* file the server will launch and everything works
fine.

My question is:
Is there a way I can tell the scripts to ignore hidden files?


This issue has come up at least 129387 times in the past.  Please read
the archives.


Yes, unfortunately it's never been freaking fixed, which is why it's come 
up 129387 times (at least). I did submit a patch to Simon Wistow for 
Module::Pluggable in September. It made Module::Pluggable ignore editor 
junk files by default, though it didn't catch ._* files (easy enough to 
add).


Unfortunately he never responded.

And yes, editors delete the files when they're closed, but in the case of 
Emacs, it creates such files _while_ you're editing a buffer, and it's 
easy to have your Cat dev server try to load these.


So maybe someone can either A) poke Simon or B) we could subclass 
Module::Pluggable and add the fix in there or C) yell at people who 
complain about it on the list because they expect the software to do the 
right thing.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] Malformed class Name Hidden files

2008-01-30 Thread Dave Rolsky

On Wed, 30 Jan 2008, Jonathan Rockway wrote:


* On Wed, Jan 30 2008, Dave Rolsky wrote:

Yes, unfortunately it's never been freaking fixed, which is why it's
come up 129387 times (at least). I did submit a patch to Simon Wistow
for Module::Pluggable in September. It made Module::Pluggable ignore
editor junk files by default, though it didn't catch ._* files (easy
enough to add).

Unfortunately he never responded.


I've also fixed this about 128745 times inside Catalyst (one of my first
ever posts to the mailing list, in fact), but it keeps getting reverted.
In fact, I think I applied your patch a while ago, but was asked to
revert it.


Yes, you did. My patch could probably be redone as a 
Module::Pluggable::Object subclass or something if that'd be more 
palatable. My original Catalyst patch was much more blunt.



I vote to hack around this in Catalyst until it's fixed upstream.  This
has gone on long enough.


++ for all the say I have ;)


-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] REST - like uri design for CRUD

2008-01-20 Thread Dave Rolsky

On Sun, 20 Jan 2008, Thomas L. Shinnick wrote:

They specifically allow that when PUT is not available or impracticable 
(clients, firewalls, and proxies can get in the way), you could 'overload' 
POST by, for example, adding a query parameter _method=PUT to pass-thru the 
real request method.  The idea is that the handler would pick off this 
parameter and dispatch as though the HTTP method had really been PUT.  But 
you try to use this request like you would a 'real' PUT, in what the data 
contains and how it is used.


But this is a question I have, whether the REST dispatching modules have an 
capability like this, interpreting overloaded POSTs?


I added this to a custom Catalyst::Request subclass I use for my app. It 
looks like this:


 sub method
 {
 my $self = shift;

 return $self-NEXT::method(@_)
 if @_;

 return $self-{__method} if $self-{__method};

 my $method = $self-NEXT::method();

 return $method unless $method  uc $method eq 'POST';

 my $tunneled = $self-param('x-tunneled-method');

 return $self-{__method} = $tunneled ? $tunneled : $method;
 }


-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] REST - like uri design for CRUD

2008-01-20 Thread Dave Rolsky

On Sun, 20 Jan 2008, Ashley wrote:

Clipped a bunch. This is great food for thought. I am missing in this scheme 
how you would know to serve the form for updating. That seems to be the real 
point of /class/id//update. I suppose that should be /class/id//edit 
instead and it would, if it could, properly PUT the form to /class/id/, 
yes?


What I've done is something like /user//edit_form

That makes it clear that the URI is a noun, the edit for for user . 
I still PUT to /user/ for the update. When I say PUT I really mean 
tunnel PUT via a POST, of course, because browser make this all so 
difficult.


For creation I'd have /user/create_form or /user/new_user_form and POST to 
/user



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] Re: Development environments and performance

2008-01-16 Thread Dave Rolsky

On Wed, 16 Jan 2008, kevin montuori wrote:


DR == Dave Rolsky [EMAIL PROTECTED] writes:


DR * dev is one box per dev, with the best hardware affordable - nowadays
DR * that means at least a dual core machine with 4GB of ram and decent
DR * disks.

at least 4 GB of ram?  crikey.


I'm thinking that a sane budget is $2,500 per developer machine (with 
monitor). Is that unreasonable? Do you really need to save a few hundred 
bucks on ram?



i'd have to disagree.  if you have a bunch of junior developers
writing code, a shared (to some extent) development environment can
aid in enforcing good development habits.  it also allows them to work
more on development than systems or database administration.  never
mind that it's asking a lot to make programmers (of any skill level)
DBA their own oracle instances, LDAP servers, or, god forbid,
siteminder installations.


This is what automation was invented for. At several past positions, I've 
set things up so that development consisted of checking out the source and 
running a set up my dev env script that created/updated the database, 
inserted test data, set up any servers needed, etc.


This doesn't require much of the individual dev, and if you have packages 
for your app, the installation part is pretty simple.


That said, I think good developers should have some minimal sysadmin 
skills, and should be comfortable setting up a DBMS or LDAP server on 
their own machine, and difficult installations can be scripted.



my suspicion is that in shops with poor shared development
environments, the systems administration is more to blame for the
suitability issues than the fact that the environment is shared.


Well, not if there's a _resource_ issue. If, as J Rockway described, you 
have 40 people sharing one machine, you're probably screwed no matter how 
good your sysadmins are.



catalyst allows for a particularly nice sandbox though, using the
devlopment httpd.  we're having a lot of luck providing a (robust, but
not 4GB per devloper!) shared dev/sandbox environment with each of 8
or so developers running a dev httpd.  we then releasing code to
integration for regression testing.  i'm certainly not seeing the
performance problems that have been reported on this list.


Presumably that depends on how many devs you have. However, I'd be going 
nuts if I had to deal with other devs changing the database schema, or 
even just changing the state of the data while I'm trying to develop 
against it.


I stand by my position that any place not providing individual 
environments is backwards.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] two Catalyst flaws

2008-01-03 Thread Dave Rolsky

On Thu, 3 Jan 2008, Peter Edwards wrote:


In the latter case there's still some work to do if you want to have a
shared config file but that's not too hard to figure out.


There's a Catalyst advent calendar article showing how to do this:

http://catalyst.perl.org/calendar/2007/14


I did something sort of similar for VegGuide.Org, except the config simply 
lives in a single module (VegGuide::Config) that is designed to be usable 
for Catalyst and outside of it.


Basically, it has lots of class methods that return various config items, 
and also a few methods for returning Catalyst-structured 
config, CatalystImports() and CatalystConfig().


http://svn.urth.org/filedetails.php?repname=RegVegpath=%2Ftrunk%2Flib%2FVegGuide%2FConfig.pmrev=0sc=0


-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] Launch of new (to Catalyst) site

2008-01-02 Thread Dave Rolsky
I finally was able to launch my first major project using Catalyst 
yesterday, the latest version of my VegGuide.Org site. This version uses 
Catalyst with Mason and Alzabo. One of the great things about this project 
was that I could use my existing model code as-is with basically no 
changes, while replacing the view (new UI) and controller (Catalyst 
replacing Mason + MasonX::WebApp).


If people are interested, the source is available (though no docs and not 
many tests :() here - http://www.vegguide.org/site/source



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] Session, DateTime and Storable

2008-01-01 Thread Dave Rolsky

On Mon, 31 Dec 2007, Christopher Laco wrote:


I've heard mention of this before, but I can't find the thread.
I have the latest DateTime, Storable and
Catalyst::Plugin::Session/Authentication and I've getting heap of these
in my logs:


Use of uninitialized value in subroutine entry at blib/lib/Storable.pm 
(autosplit into blib/lib/auto/Storable/_freeze.al) line 339.


This seems to be caused by storaing a DateTime object in the session. If
I store a string instead of a DT instance, the warnings go away.

Anyone have any ideas on this one?


It _should_ work. If you filed a bug report with a simple reproduction 
recipe (that just uses DateTime and Storable, not Catalyst), I'm sure it 
would be fixed.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
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] Beginner question: View directory

2007-11-08 Thread Dave Rolsky

On Thu, 8 Nov 2007, Ash Berlin wrote:

Similarly, I setup subs that I always want aviabale in the TT stash, such as 
format_datetime (which formats a DateTime object according do the currently 
logged in user's prefernce.) I also assing VMethods to 
$Template::Whatever::SCALAR_OPS here, since this seems like the place that 
such code belonds.


For Mason, this just involves importing subs that I want into the relevant 
package, but it's a similar thing. Yes, this obviously belongs in the view 
as well. Of course, if you had enough of this for TT you might want to put 
it in separate modules.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Beginner question: View directory

2007-11-07 Thread Dave Rolsky

On Thu, 8 Nov 2007, Kieren Diment wrote:

Good call, my mistake.  Goes to show that there's not usually much (or any) 
extra stuff that needs to be done in the View class.  I was actually 
struggling to think of code related things  (rather than config) which  you 
might want to put in there.   Personally I've always munged headers in the 
sub end : ActionClass(’RenderView’) {} subs (see perldoc 
Catalyst::Action::RenderView for details).


I have a few bits of code in my view class, but not much.

For the Mason view, I had subclass new() and chown() all the files created 
by the Mason Interp object to make things happy under mod_perl. Mason has 
this built-in to its mod_perl integration, but that doesn't get used with 
Catalyst.


I also have a method has_template_for_path() which does what it says. I 
call this from some controller auto() methods where the URI in question is 
basically static content that doesn't need a separate controller method.



-dave

/*===
VegGuide.Orgwww.BookIRead.com
Your guide to all that's veg.   My book blog
===*/___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/