Code rot is everywhere, but some platforms suffer more than others. Even Simple C++ code suffers from code rot.

When I first got involved with MVC Web Frameworks like Maypole and Ruby on
Rails, a big selling point was the ability to generate CRUD (Create/Read/
Update/Delete) interfaces to your data model. Ruby on Rails does this through
a mechanism called scaffolding, where it adds a set of actions to your
controller. It soon became apparent that these CRUD frameworks did not live
up to their promise as a base for creating your own custom actions. Usually,
you spend more time customizing these controllers than you would just
implementing the features you require.

However, there is still a good use for these for giving your admins a
direct interface to your data model. There has been several iterations of
these tools for the Catalyst framework, but with Catalyst::Plugin::AutoCRUD,
I’ve finally found something easy to plug into your existing app, which
integrates well with most setups.

For most apps, all you need to do is plug it into the main application class
by adding AutoCRUD to your list of plugins. This will plug a complete CRUD
application, including controllers and view and templates into your app.
By default it will attach itself at ‘/autocrud’, but you can easily change
that in config. Just add this to your config file:

      basepath admin

and it will respond to /admin/* instead. Another common requirement is to
add authentication for the admin interface. One way to accomplish that is
by using Catalyst’s auto handler functionality. Add a method like this in
your Root controller

sub auto :Private {
    my ( $self, $c ) = @_;
    if ($c->action->reverse =~ /^autocrud\//) {
        $c->authenticate({},'users');
    }
    return 1;
}

Note that my example is using HTTP Basic auth. The actual authenticate call
needs to be customized for your realm.

AutoCRUD supports multiple DBIC Schemas, and if will automatically provide you
with a list to let you pick which one to work with. After that, you choose
a Result class, and you have access to an extensive AJAX-enhanched database
admin tool. You can search and browse data, as well as edit it and add new
rows easily. AutoCRUD also understands your DBIC relationships, so you can
easily see data related to the current rows.

Like it’s predecessors, I do not recommend trying to make this tool
into a generic ‘allweb’-application. However, if you use it for what it is,
you can save countless of development hours making trivial admin tools. Since
it works again your DBIC Schema, you’ll also get the advantage of keeping
your business logic in the data model. Things like DBIC timestamps will
Just Work.

There still might be some polishing left to do on AutoCRUD, but I already
find it a hugely useful tool. You can install it just like you would any other CPAN module using

$ cpan Catalyst::Plugin::AutoCRUD

For me, the strength of Catalyst’s Model layer has always been the immense glue layer that allows me to configure any model in a predictable way. Much like DBI gives me a unified way to talk to databases, the Catalyst model-layer gives us a unified way of configuring models. In addition, we are able to provide helpers to create these models from the command line, reducing the work needed to set up a new model.

I will grant Dave that the API for the model adapters could be better. It is my hope that we will accomplish as Catalyst takes advantage of more of the new stack that Moose provides. In particular I am excited about the work Devin Austin is doing for GSOC on improving the -Devel package. This is an area where we can significally improve without too much worry about backwards compability. For instance, the KiokuDB model already uses moose accessors for config.

Dave’s example only limits itself to talking to a SQL store via DBIx::Class. However, real world applications typically have several models. In some of my apps I talk to S3, or Queue servers, or LDAP stores for user management. This shows the true power of the Catalyst model layer.

I also hope that we can provide a different way to tie models to controllers. This should be part of the moosify branch of Catalyst-Runtime. I disagree that $schema->resultset(‘Person’) is a significant improvement on $c->model(‘DBIC::Person’). Controller code is not meant to run without a context anyways.

I hope that by looking at Moose Extensions, we will be able to find a more suitable API for this functionality. Of course, we have a lot of work ahead of us, but I am really starting to like what Catalyst has turned into.

So far though, I would say that the book is better than most programming books. Really, a lot of programming books need to be more like this, instead of focusing entirely on the arcana of one framework they should help you be a better programmer overall.

(permalink)

Suck on that, RoR :-)

Frank says “For the moment only private actions are graphed.”, hopefully, it can be extended to understand chained actions. I can’t wait to test it out on the iusethis code base. Now I can just hand this graph to Arne when he wants to know which template matches which action.

(permalink)

We operate one of the most visited Catalyst/DBIx::Class sites in the world with 90 million users and hundreds of millions of pageviews per day.

They are looking for contractors all over the world. No matter what you might think of the content, the stack they are using seems cool, pretty much the same libraries we use to power iusethis and our other sites.

(permalink)

(permalink)

---
- name: "iusethis-osx.server"
  nproc: 4
  scriptname: "/www/iusethis-osx/script/iusethis_fastcgi.pl"
  pidfile: "/var/run/iusethis-osx.pid"
  socket: "/var/run/iusethis-osx.sock"

with an entry for each server you want to run. (Note that the paths has been changed to protect the innocent.) Then you just create a simple perl script (See the FCGI::Engine::Manager SYNOPSIS for a sample), and you can easily start, stop and check the status for each application individually or every application in your config. If you have a system v style init, you can just stick the script in /etc/init.d/ and it will behave just like any of your other startup scripts.

There is one annoying detail. Each time you roll out code, you have to restart your fastcgi processes. Since Catalyst takes some time to initialize, the application is down, and end users gets 500 Internal Server Error responses, unless you have a load balancer in front and take the node out of the cluster before upgrading. It does not have to work like this. Since the fcgi workers use a non-exclusive lock on the socket, you can start a new set of processes before you kill the old ones. this way, no requests are lost.

I really wanted this feature, so I have spent some time today hacking on FCGI::Engine. Stevan accepted my patches, and released version 0.06, which supports this restart mode, via a new ‘graceful’ method added to FCGI::Engine::Manager + some bug fixes. Nginx already support On the fly upgrades, which means there is no need for us to drop a user connection when rolling out new code again.

In addition, it seems they have installed a broken Scalar::Utils, so after following his advice and installing IO manually to get a unbroken CPAN shell, I suggest running

cpan> force install Scalar::Util

To get a working weaken again. At least this fixes my stuff, but they might have broken more XS stuff. I’ll keep you posted if I discover anything else.

(permalink)