[Catalyst] BBC's "Perl on Rails" nuttiness

Zbigniew Lukasiak zzbbyy at gmail.com
Sun Dec 2 10:25:49 GMT 2007


Is it possible that we go to the root of that and ask Siemens about
their policy for whitelisting modules?  I can understand that they
want to keep some control over this - but if we new what process they
use for that and what criteria - then perhaps we could help them in
some way?  In the age of social networking we should be able to find
someone from Siemens - what do you think?

--
Zbyszek

On Dec 2, 2007 12:06 AM, Ian Docherty <catalyst at iandocherty.com> wrote:
>
>  I have some first-hand knowledge that could throw some light on this.
>
>  I was aware that Catalyst was being used within the iPlayer team, and they
> were contributing many bug fixes back into Catalyst and DBIC. I was not
> aware of this 'Perl on Rails' work. There again the BBC is big so it is not
> surprising that one team does not always know what another team is doing.
>
>  Catalyst is being used only for back end systems, not customer facing. The
> BBC works almost exclusively on systems that publish HTML rather than
> providing dynamic content.
>
>  J. Shirley wrote:
> On Dec 1, 2007 11:29 AM, Jonathan Rockway <jon at jrock.us> wrote:
>
>
> >
> >
>  <snip>
>
>
>
> > I think that the 5.6 limitation was the main reason for not using
> > Catalyst.
> >
>
>
>  The insanity of a few of their points lead me to believe their Perl on
> Rails platform is probably not ever going to go anywhere:
>   - "we needed to expose any SQL queries we would make so they could be
> vetted by DBA's for optimization"
>   - "On the live environment we were told at the time we had Perl 5.6, and a
> few BBC approved perl modules."
>
>  I certainly believe that _some_ SQL queries should be optimized, or rather
> the database optimized for those queries, making every query that way is
> just madness.  It certainly isn't extensible.
>  To support the BBC on this, the SQL needs to be made visible for database
> optimisation, but mainly for the purpose of showing what indexes should be
> put on the tables. Since it is possible to cause the generated SQL to be
> output then this should be sufficient and is no reason to avoid an ORM.
>
>
>
>
>  The best way to tie developers hands and waste money is by giving them an
> immutable whitelist of modules.  I wonder how many "utility" methods are in
> this framework that should be broken out into separate modules -- and in
> reality, there are probably already 3 modules already doing their utility
> method.  People really need to get over NIH-Syndrome.
>  It is not a NIH Syndrome, the BBC live environment is supported and
> maintained by Siemens. You would not believe the time and effort involved in
> getting new modules approved and installed on the live system (I am talking
> months if not years). Is it surprising the developers lose patience and
> design their own ORM when they don't have any other option? The DBAs and
> support teams are also frustrated at this since it makes support so much
> more difficult having all these different ways of doing the same thing.
>
>  Regards
>  Ian Docherty
>
>
> _______________________________________________
> List: Catalyst at lists.scsys.co.uk
> Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
> Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
> Dev site: http://dev.catalyst.perl.org/
>
>



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/



More information about the Catalyst mailing list