Mailing List Archive

Advent Calendar... Grant proposal...
From:
http://www.catalystframework.org/calendar/2014/21

"I've also considered making a request for a grant from the Perl Foundation
in order to work on these docs, and wonder what you all think of that :)"


I think that one of the main use of Perl is to create web apps.
And the best way of creating web apps is by using a web framework.
And the most developed web framework for Perl is Catalyst.
But those who prefer other frameworks do it because they consider Catalyst
too complex and hard to understand.
So yes, a more clear documentation for Catalyst should be very helpful.
Newbies might have the time and willing to write it, but they might not know
what to write. :)
So... applying for a grant to do it may be the solution.


--Octavian


_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: Advent Calendar... Grant proposal... [ In reply to ]
The catalyst docs could do with a substantial review, they haven't had much
attention lately. In particular there could do with being a good index.

I think the issue with people thinking catalyst is too big/complex is that
lots and lots of developers are used to a procedural approach to dealing
with web applications, and have troulble with a couple of things. These are:

1. Lots of people are in the habit of writing procedural web apps, and
don't feel that they want to shift over to a more OO style.

2. Some aspects of the dispatcher freak people out until they learn it
(and especially until they get comfortable with chained) and this is a bit
of a point of resistance.

3. Catalyst used to be hard to install (and catalyst had a lot of
influence on improving the cpan toolchain during the relatively early
days), but this isn't the case any more, but the perception lingers in
places.

Maybe the solution is in part for someone to write a
Catalyst::Manual::Unsweetened in the same sprit as
Moose::Manual::Unsweetened in order to gently guide people towards catalyst
from something they're less familiar with.
Re: Advent Calendar... Grant proposal... [ In reply to ]
umm from something they're *more* familiar with.

On Sun, Jan 4, 2015 at 7:43 AM, Kieren Diment <diment@gmail.com> wrote:

> The catalyst docs could do with a substantial review, they haven't had
> much attention lately. In particular there could do with being a good
> index.
>
> I think the issue with people thinking catalyst is too big/complex is that
> lots and lots of developers are used to a procedural approach to dealing
> with web applications, and have troulble with a couple of things. These are:
>
> 1. Lots of people are in the habit of writing procedural web apps, and
> don't feel that they want to shift over to a more OO style.
>
> 2. Some aspects of the dispatcher freak people out until they learn it
> (and especially until they get comfortable with chained) and this is a bit
> of a point of resistance.
>
> 3. Catalyst used to be hard to install (and catalyst had a lot of
> influence on improving the cpan toolchain during the relatively early
> days), but this isn't the case any more, but the perception lingers in
> places.
>
> Maybe the solution is in part for someone to write a
> Catalyst::Manual::Unsweetened in the same sprit as
> Moose::Manual::Unsweetened in order to gently guide people towards catalyst
> from something they're less familiar with.
>
Re: Advent Calendar... Grant proposal... [ In reply to ]
I find that getting involved in a project like Catalyst is much like
releasing your own CPAN module - possibly daunting at first, hence some
reluctance?

From my own experience only, it took years to finally find something I
was comfortable to release, but when I did, it then starts to flow.

To me, it's all about that initial involvement... that first step, and
making it as painless as possible.

Maybe I've been skipping things recently, do we have a roadmap? A
simple list of issues, bugs, and feature-requests? Something
Trello-esque maybe?
and as small as possible?

Do we have a documented workflow? Perhaps even down to copy & paste
commands to cut a branch, etc.

I'd personally love to pick up a simple documentation "fix" to get
involved. More to get a feel of actually contributing back to the
codebase, as simple as that sounds, I feel it may be a huge stumbling
block for most.

If we make simpler, we may have more success?

Just some random 2-cents...



On 03/01/15 20:08, Octavian Rasnita wrote:
> From:
> http://www.catalystframework.org/calendar/2014/21
>
> "I've also considered making a request for a grant from the Perl
> Foundation in order to work on these docs, and wonder what you all
> think of that :)"
>
>
> I think that one of the main use of Perl is to create web apps.
> And the best way of creating web apps is by using a web framework.
> And the most developed web framework for Perl is Catalyst.
> But those who prefer other frameworks do it because they consider
> Catalyst too complex and hard to understand.
> So yes, a more clear documentation for Catalyst should be very helpful.
> Newbies might have the time and willing to write it, but they might
> not know what to write. :)
> So... applying for a grant to do it may be the solution.
>
>
> --Octavian
>
>
> _______________________________________________
> List: Catalyst@lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive:
> http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
> Dev site: http://dev.catalyst.perl.org/


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
From: Kieren Diment


The catalyst docs could do with a substantial review, they haven't had much attention lately. In particular there could do with being a good index.


I think the issue with people thinking catalyst is too big/complex is that lots and lots of developers are used to a procedural approach to dealing with web applications, and have troulble with a couple of things. These are:


1. Lots of people are in the habit of writing procedural web apps, and don't feel that they want to shift over to a more OO style.


Yes, but shifting to OO style requires a very good knowledge of the entire module stack used. If these modules are too smart, the documentation should explain they very well.



2. Some aspects of the dispatcher freak people out until they learn it (and especially until they get comfortable with chained) and this is a bit of a point of resistance.


And I'd say that the fact that Catalyst uses method attributes which in general are discouraged and very rarely found in other projects is another obstacle. Probably some people might like to be able to write their own hello world script that also uses method attributes in order to see how they work and what are their limits in order to understand then a more complex system of attributes in Catalyst.


3. Catalyst used to be hard to install (and catalyst had a lot of influence on improving the cpan toolchain during the relatively early days), but this isn't the case any more, but the perception lingers in places.


:-)
I think that the last time I also installed Catalyst or a Catalyst component in a hurry by using --force.

I spent today a pretty long time trying to install RapidApp, which is a Catalyst extension, but finally I abandoned the idea.
I installed a few modules by using ActiveState's ppm and a few others after looking in the .log file with the errors generated by cpanm, but there are other modules required, like JSON::DWIW which don't appear to be made to work under Windows.

--Octavian
Re: Advent Calendar... Grant proposal... [ In reply to ]
Kieren Diment wrote on 1/3/2015 3:43 PM:
> 3. Catalyst used to be hard to install (and catalyst had a lot of
> influence on improving the cpan toolchain during the relatively early
> days), but this isn't the case any more, but the perception lingers in
> places.

Catalyst isn't nearly as difficult to install these days, but it still
feels like you're installing most of CPAN in order to get Catalyst. And
it still takes a frickin' long time.

--[Lance]

--
GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
CACert.org Assurer

_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
Is this something we can resolve, or simply make better as its install
process, that maybe needs explaining better?



On 03/01/15 22:26, Lance A. Brown wrote:
> Kieren Diment wrote on 1/3/2015 3:43 PM:
>> 3. Catalyst used to be hard to install (and catalyst had a lot of
>> influence on improving the cpan toolchain during the relatively early
>> days), but this isn't the case any more, but the perception lingers in
>> places.
> Catalyst isn't nearly as difficult to install these days, but it still
> feels like you're installing most of CPAN in order to get Catalyst. And
> it still takes a frickin' long time.
>
> --[Lance]
>


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
Robert Brown wrote on 1/3/2015 5:36 PM:
> Is this something we can resolve, or simply make better as its install
> process, that maybe needs explaining better?

I don't think it can be resolved unless Catalyst wants to move in the
same direction Mojolicious has taken, which I don't agree with.

I hesitate to call it a warning, but some kind of note in the
documentation and or at the beginning of the Catalyst install process to
let the user know it will take some time would be useful.

--[Lance]

--
GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
CACert.org Assurer

_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
I'm rather concerned with that statement, but will allow time for all of
us to sober up.



On 03/01/15 22:44, Lance A. Brown wrote:
> Robert Brown wrote on 1/3/2015 5:36 PM:
>> Is this something we can resolve, or simply make better as its install
>> process, that maybe needs explaining better?
> I don't think it can be resolved unless Catalyst wants to move in the
> same direction Mojolicious has taken, which I don't agree with.
>
> I hesitate to call it a warning, but some kind of note in the
> documentation and or at the beginning of the Catalyst install process to
> let the user know it will take some time would be useful.
>
> --[Lance]
>


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
My greatest concern is only that we keep this accessible, no strings, no
branches, etc.

how can we best do this?




On 03/01/15 22:44, Lance A. Brown wrote:
> Robert Brown wrote on 1/3/2015 5:36 PM:
>> Is this something we can resolve, or simply make better as its install
>> process, that maybe needs explaining better?
> I don't think it can be resolved unless Catalyst wants to move in the
> same direction Mojolicious has taken, which I don't agree with.
>
> I hesitate to call it a warning, but some kind of note in the
> documentation and or at the beginning of the Catalyst install process to
> let the user know it will take some time would be useful.
>
> --[Lance]
>


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
Installation is basically a one shot (especially if you have a
transportable perl compiled with perlbrew of Perl::Build). A framework is
for life not just for a 5 minute "write a blog engine" demo.

On Sun, Jan 4, 2015 at 9:44 AM, Lance A. Brown <lance@bearcircle.net> wrote:

> Robert Brown wrote on 1/3/2015 5:36 PM:
> > Is this something we can resolve, or simply make better as its install
> > process, that maybe needs explaining better?
>
> I don't think it can be resolved unless Catalyst wants to move in the
> same direction Mojolicious has taken, which I don't agree with.
>
> I hesitate to call it a warning, but some kind of note in the
> documentation and or at the beginning of the Catalyst install process to
> let the user know it will take some time would be useful.
>
> --[Lance]
>
> --
> GPG Fingerprint: 409B A409 A38D 92BF 15D9 6EEE 9A82 F2AC 69AC 07B9
> CACert.org Assurer
>
> _______________________________________________
> 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: Advent Calendar... Grant proposal... [ In reply to ]
But that really depends on the system, doesn't it? I can install the
usual parts of Catalyst by installing just a few packages on a Debian
(and Debian-derived) systems. It takes a few minutes (less than ten,
surely), but it's an easy process.

Isn't that the primary purpose of distribution packaging teams?
Assembling the various parts into a whole that is easily installed?

On 01/03/2015 11:44 PM, Lance A. Brown wrote:
> Robert Brown wrote on 1/3/2015 5:36 PM:
>> Is this something we can resolve, or simply make better as its install
>> process, that maybe needs explaining better?
> I don't think it can be resolved unless Catalyst wants to move in the
> same direction Mojolicious has taken, which I don't agree with.
>
> I hesitate to call it a warning, but some kind of note in the
> documentation and or at the beginning of the Catalyst install process to
> let the user know it will take some time would be useful.
>
> --[Lance]
>


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
> I think that one of the main use of Perl is to create web apps.
> And the best way of creating web apps is by using a web framework.
> And the most developed web framework for Perl is Catalyst.
> But those who prefer other frameworks do it because they consider Catalyst
> too complex and hard to understand.
> So yes, a more clear documentation for Catalyst should be very helpful.
> Newbies might have the time and willing to write it, but they might not
> know
> what to write. :)
> So... applying for a grant to do it may be the solution.
>
>
> --Octavian

Good documentation is clearly necessary, but I don't think that it will by
itself be enough to attract newbies. I am an interested newbie, so perhaps
I can add something to the conversation. My impression is that Catalyst is
not so complex by itself, but it sits at the top of a pyramid of knowledge
domains that are both broad and deep. MVC (each letter is a book in
itself), Perl/CPAN, OO, web servers, security, web hosting (your shared
hosting won't work), etc. What did I miss?

The loosely coupled Catalyst approach to web frameworks therefore benefits
from a loosely coupled approach to Catalyst training. What's the minimum
required knowledge to create a "best practice" web application using
Catalyst? Each area requires a loosely coupled learning module, that both
stands on its own, and directly supports a minimal, yet "best practice"
prerequisite understanding necessary for integration into a Catalyst
application.

I'd like to point out Andrew Solomon's excellent Geekuni courses. I'm just
finishing up the Perl Essentials course, which I enrolled in primarily as
an on-ramp to the Dancer course. The combination of carefully designed
tasks, instant feedback, and mentoring provides a holistic learning
experience that I couldn't achieve from months of reading books, online
tutorials, and writing my own perl scripts. Yes, I was able to write many
useful scripts without fully understanding many of the concepts I was
using. I'm anticipating that the Dancer course will be equally effective.

I recommend that the Catalyst community work with Andrew Solomon and
Geekuni to create and promote courses that would support Catalyst (and
prerequisites) training.

Full Disclosure - I'm a perl newbie, and I'd love to learn to build useful
web applications with Catalyst. :)





_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
From: <rick@hiranyaloka.com>

>> I think that one of the main use of Perl is to create web apps.
>> And the best way of creating web apps is by using a web framework.
>> And the most developed web framework for Perl is Catalyst.
>> But those who prefer other frameworks do it because they consider
>> Catalyst
>> too complex and hard to understand.
>> So yes, a more clear documentation for Catalyst should be very helpful.
>> Newbies might have the time and willing to write it, but they might not
>> know
>> what to write. :)
>> So... applying for a grant to do it may be the solution.
>>
>>
>> --Octavian
>
> Good documentation is clearly necessary, but I don't think that it will by
> itself be enough to attract newbies.

What else do you think that it may attract you?

I am an interested newbie, so perhaps I can add something to the
conversation. My impression is that Catalyst is
> not so complex by itself, but it sits at the top of a pyramid of knowledge
> domains that are both broad and deep. MVC (each letter is a book in
> itself), Perl/CPAN, OO, web servers, security, web hosting (your shared
> hosting won't work), etc. What did I miss?
>
> The loosely coupled Catalyst approach to web frameworks therefore benefits
> from a loosely coupled approach to Catalyst training. What's the minimum
> required knowledge to create a "best practice" web application using
> Catalyst? Each area requires a loosely coupled learning module, that both
> stands on its own, and directly supports a minimal, yet "best practice"
> prerequisite understanding necessary for integration into a Catalyst
> application.


Imho a beginner should not start by creating "best practice" apps, but apps
which help him/her to understand each step as easy as possible. She or he
just need to know that there are better ways that will be learned later.

When we say that Catalyst is hard/easy or elegant/confusing for beginners we
compare it with other web frameworks, but the apps made with all web
frameworks need to interact with a web server, use OO, CPAN modules, should
take care of security, should be installed on a remote server etc, so it is
not a big difference.

Dancer examples are nice and sweet, much more elegant than Catalyst's
examples, most of them in just a single file, but in real world applications
we may want to split the web apps in more modules for a better
maintenability, we might need to access more databases, we might want to use
more complex URL dispatching styles, and in that case we would see that if
we would do those things in a Dancer app, that app might not be so elegant
anymore.

It sounds very good that Mojolicious doesn't require other CPAN modules but
it offers its own modules for many things, and it looks like it would be
much easier to install a Mojolicious app, but unless the app is simple
enough we may still need to use other CPAN modules, so we should still need
to be able to use cpan or cpanm. And in that case, it wouldn't be a big
problem to install a large distribution like Catalyst either.

"Beginner" may mean many things, so it is not very clear what
recommendations you are searching for. For a Perl - beginner level it is
recommended to use the common Perl best practices regarding the
variables/subroutine naming, indentation etc, for a web developer beginner
is recommended to learn about HTTP and CGI protocols, how web servers work,
about security in web apps, for a Catalyst beginner is recommended to read:

http://dev.catalystframework.org/

and the POD docs in Catalyst::Manual, trying to concentrate on Catalyst -
related code and not DBIx::Class or Template-Toolkit or different form
processors if you haven't used them yet.

The Catalyst docs are not very good for real beginners that have never used
a web framework and also never used an ORM or templating system. Many of
them give "best practice" examples which may be harder to understand by a
beginner because they contain Catalyst code intermixed with code from
different other modules and a beginner may not know where ends Catalyst and
starts DBIx::Class for example.
This is why is said that Catalyst has a steap learning curve.
It may be very helpful if the beginner first starts by learning to use a
simple RDBMS like MySQL or SQLite and DBIx::Class ORM which is the prefered
ORM by most and also Template-Toolkit which is the preferred templating
system, even only superficially, and only after that start learning to use
Catalyst because then it would be much easier to see that Catalyst is just a
glue between other modules and that it is not hard to use it.

--Octavian


_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: Advent Calendar... Grant proposal... [ In reply to ]
Octavian said:
> Imho a beginner should not start by creating "best practice" apps, but
> apps
> which help him/her to understand each step as easy as possible. She or he
> just need to know that there are better ways that will be learned later.
>

Your 2012 Catalyst Advent Calendar articles "Catalyst in 9 Steps" embodied
that principle nicely. I'd like to see those articles extended further,
and have them linked in the official documentation.

Why not set a documentation goal that would allow a perl newbie with Perl
Beginner/(Intermediate) under his/her belt, be able to start hacking on a
Catalyst app, with relevant documentation to take them all the way to a
production ready, best practice site?

That is where those 2012 Advent articles were heading, I think that is a
great idea. IMHO :)


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
There is at least one other potential newbie entrance point into Catalyst.
That is where he/she installs a fully functional application (generally a
blog, CMS, forums, etc.), then slowly begins contributing within a plugin
architecture, then full applications, as his/her understanding of how the
parts work expands.

Or at least, the Catalyst app user will hire someone to work on his
application. :)

> Octavian said:
>> Imho a beginner should not start by creating "best practice" apps, but
>> apps
>> which help him/her to understand each step as easy as possible. She or
>> he
>> just need to know that there are better ways that will be learned later.
>>
>
> Your 2012 Catalyst Advent Calendar articles "Catalyst in 9 Steps" embodied
> that principle nicely. I'd like to see those articles extended further,
> and have them linked in the official documentation.
>
> Why not set a documentation goal that would allow a perl newbie with Perl
> Beginner/(Intermediate) under his/her belt, be able to start hacking on a
> Catalyst app, with relevant documentation to take them all the way to a
> production ready, best practice site?
>
> That is where those 2012 Advent articles were heading, I think that is a
> great idea. IMHO :)
>
>
> _______________________________________________
> 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/
>


_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
Hi,

i'm currently building a catalyst-based CMS - it is fully working, but
needs some help to make it open source and add some more features.

Based on Catalyst, Template Toolkit, DBIx::Class, and some more great
Perl-Modules. Multiple Rights and Roles - combined with a great
Drag-n-Drop-Interface for custom elements.

Currently i'm searching for contributors, those who will understand my
English ;) and helping to make it open source! I also have paying
customers for a long list of features!

For those who are interested in, i will gave a online presentation.
Please contact me if you like to contribute!

Best regards,
Jens





Am 18.01.2015 um 19:36 schrieb rick@hiranyaloka.com:
> There is at least one other potential newbie entrance point into Catalyst.
> That is where he/she installs a fully functional application (generally a
> blog, CMS, forums, etc.), then slowly begins contributing within a plugin
> architecture, then full applications, as his/her understanding of how the
> parts work expands.
>
> Or at least, the Catalyst app user will hire someone to work on his
> application. :)
>
>> Octavian said:
>>> Imho a beginner should not start by creating "best practice" apps, but
>>> apps
>>> which help him/her to understand each step as easy as possible. She or
>>> he
>>> just need to know that there are better ways that will be learned later.
>>>
>>
>> Your 2012 Catalyst Advent Calendar articles "Catalyst in 9 Steps" embodied
>> that principle nicely. I'd like to see those articles extended further,
>> and have them linked in the official documentation.
>>
>> Why not set a documentation goal that would allow a perl newbie with Perl
>> Beginner/(Intermediate) under his/her belt, be able to start hacking on a
>> Catalyst app, with relevant documentation to take them all the way to a
>> production ready, best practice site?
>>
>> That is where those 2012 Advent articles were heading, I think that is a
>> great idea. IMHO :)
>>
>>
>> _______________________________________________
>> 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/
>>
>
>
> _______________________________________________
> 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/
>

--
Freiberuflicher Software-Entwickler
Büro: 02271/462009 Skype: jens.gassmann E-Mail: jens.gassmann@atomix.de

_______________________________________________
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: Advent Calendar... Grant proposal... [ In reply to ]
From: <rick@hiranyaloka.com>

> Octavian said:
>> Imho a beginner should not start by creating "best practice" apps, but
>> apps
>> which help him/her to understand each step as easy as possible. She or he
>> just need to know that there are better ways that will be learned later.
>>
>
> Your 2012 Catalyst Advent Calendar articles "Catalyst in 9 Steps" embodied
> that principle nicely. I'd like to see those articles extended further,
> and have them linked in the official documentation.


Yes, my intention was to show a few really simple ways of using Catalyst
without an ORM or other CPAN modules as first steps of learning Catalyst by
a beginner, even most of those steps are not intended to be used in
production.
It would have been very good to have the time to continue the serial and
show more and more advanced steps by adding one by one more CPAN modules or
Catalyst components, show different URL dispatching types from the most
simple to the most complex, show how to use REST etc.


> Why not set a documentation goal that would allow a perl newbie with Perl
> Beginner/(Intermediate) under his/her belt, be able to start hacking on a
> Catalyst app, with relevant documentation to take them all the way to a
> production ready, best practice site?


The people who know Catalyst the best are very occupied so they probably
don't have the time to also maintain the documentation very well.
Catalyst is mainly used for serious projects and they are probably thinking
that the main target audience are the advanced developers, so a
documentation/book for beginners probably was not considered a priority.

--Octavian


_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: Advent Calendar... Grant proposal... [ In reply to ]
Hi Jens,

On Sun, 2015-01-18 at 20:16 +0100, Jens Gassmann wrote:
> i'm currently building a catalyst-based CMS - it is fully working, but
> needs some help to make it open source and add some more features.
[...]
> For those who are interested in, i will gave a online presentation.
> Please contact me if you like to contribute!

I'm the main author of ShinyCMS*, which is also an open source
Catalyst-based CMS with a variety of features (pages, blogs, shop,
forums, mailshots, etc etc). I'd love to learn more about your CMS and
see if there are any useful ways we can work together, maybe even re-use
some of each other's code! :)

Regards,
Denny

* http://shinycms.org / https://github.com/denny/ShinyCMS



_______________________________________________
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/