[Catalyst] Catalyst Advent Calendar

[will trillich]

On Thu, Dec 1, 2011 at 7:10 PM, Devin Austin <devin.austin at gmail.com> wrote:

> On Thu, Dec 1, 2011 at 10:00 AM, will trillich
> <will.trillich at serensoft.com> wrote:
> > I do appreciate the neat articles that talk about Facebook API's and
> Google
> > API's and other advanced stuff, but those often seem a bit esoteric and
> > beyond the daily grind of what we're developing. So it's also good to
> keep
> > the newbies in mind. I think if the advent series could showcase a
> couple of
> > basic articles (maybe even repackaging email threads?) it'd be great!
> > Concepts such as:
> > - how an insulated, personal perl library, instead of system-wide cpan,
> is
> > better for a Catalyst app,
> Hmm. Not sure I quite understand this one, internal dependencies never
> seem to be a better architectural decision over external, thoroughly
> tested ones.  Could you please elaborate?


In my head, the first item (above) and second item (below) are closely
related. That is, if you maintain your own $local::lib of CPAN wizardry
then you're better off in the long run when your app outlives your server,
or you migrate due to vendor concerns (or politics). Also, isn't it more
likely you'll run into problems using the system perl libraries instead of
a home-grown one? I think I've seen topics like that here on-list... would
be nice to see those concepts encapsulated as an advent article.

> - tricks and tips to keep in mind to make migrating a catalyst app from
> > system Q to system X easy,
> This could be interesting.  Do you have tips?  I personally don't
> migrate much from system to system, but others might find it useful.


I don't have any such tips, yet. I'm hoping I don't need them all at once
in the future in crash-bang mode when migration becomes a necessity,
hopefully a clear advent article beforehand can help newbies like me avoid
some of the pitfalls...


> > - strengths and weaknesses of and techniques for using
> revision-management
> > such as mercurial or subversion or git to track source code changes...
> > - using InstantCRUD or AutoCRUD in various contexts as a debugging tool
> or
> > data-mining aid
> There have been one or two a year on this sort of thing, and while I
> think it's beneficial, it's almost something that's been overdone.  If
> there is something groundbreaking in this area, sure, I'm all for it.
> I sure wouldn't mind seeing some more new ideas concerning this, but I
> think we need to look toward new things that haven't necessarily been
> covered yet, even if we're in dire need of articles.
>

:)

-- =

"The more you try to avoid suffering the more you suffer because smaller
and more insignificant things begin to torture you in proportion to your
fear of being hurt." -- Thomas Merton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20111202/c18ee=
7eb/attachment.htm