http://www.perlmonks.org?node_id=693615


in reply to speeding up web development

A couple of answers:

Catalyst doesn't really do anything application-specific. It maps URLs to method calls, period. The rest is up to you, so it makes perfect sense that you will develop your own set of reusable code for building your sites. It's a positive thing and you shouldn't try to avoid it.

There is no such thing as automatic migration between versions of a database schema and there never will be. If you change the name of a column, how will any program figure that out? It won't unless you tell it. You can use the various diff'ing tools like SQL::Translator (that's what DBIx::Class is using) to generate a starting point, but I've always found it to be a lot simpler and more foolproof to just use direct SQL. If you search this site, you'll see discussions on how to keep track of SQL scripts for upgrading your database and test them.

The cache framework you're looking for is CHI. What should you cache? Things that are slow. If nothing seems slow, don't cache. It's always a headache.

Your updating/svn question deserves a whole separate thread, but it has also been discussed before on the site, so I'd suggest some reading first.

Replies are listed 'Best First'.
Re^2: speeding up web development
by stonecolddevin (Parson) on Jun 24, 2008 at 00:04 UTC

    CHI looks a lot like Cache. From what I can see though it's goal is abstracted (by that I mean, "any" type of caching through this module) caching? Is this close to correct?

    I appreciate the to the point-ness of this thread, my big issue has been digging through all the cruft of "advice" I've found in the past.

    I agree in total with regards to Catalyst being a url->method call mapper. My question was geared more towards advice as far as spending time on creating my fairly completely customized code library or keeping it more general and using "standardized" things that are CPAN approved and such, if that makes any sense. I think it would probably come down to the needs of each application, or at least an average of each application's needs, so as to incorporate all that is needed. I doubt that will be something that anyone can answer one way, but I'm by no means a well versed web developer and I want to make sure my practices become practical and not detrimental to my work and building bad habits in the future.

    UPDATE: Durr, of course CHI looks like Cache::Cache. It's intended to be an evolution of it.

    I'd also like to clarify what I meant by migrations, and I'm sure I'll find something on here to do the dirty work that I'm speaking of, but I'm quite intrigued at how there's not much SQL directly involved in Ruby on Rails migrations and not having to open up a database editor and get dirty with SQL. God knows I love SQL, but I can only do so much at once without throwing things across the room. Hopefully this clarifies my wants a little

    meh.