|No such thing as a small change|
speeding up web developmentby dhoss (Vicar)
|on Jun 23, 2008 at 20:58 UTC||Need Help??|
dhoss has asked for the
wisdom of the Perl Monks concerning the following question:
I'm sure this question has been asked time and time again, but I've found that this process is somewhat of a stair-step one needing improvements and optimizations as one goes along.
I'm looking to speed up the time it takes me to develop web applications (ranging in scale from small-medium to large and beyond [hopefully]). As I've mentioned, stair stepping seems to be the appropriate approach to this, gaining experience and extremely valuable knowledge the whole way.
I've already taken to Catalyst as my web framework darling, but there are still a number of customizations I find myself having to do with each application I build. I'm attempting to put together a small "library" or "engine" that I can consistently re-use per project with minimal alterations. However, building this codebase
I come to you monks asking for wisdom about how I could speed this process up? "This process" being the one that includes creating a consistent codebase to use from client to client and site to site, including (and figuring out which tests and what tests I need to implement in the foundation code and final product) and I think a large factor would also be database "migrations" (regarding the latter, I've taken a look at DBIx::Class::Schema::Versioned, but would really like to find or put something together that's somewhat like a common ground between RoR's database handling and Jifty's database schema control.
I have a feeling this node will have multiple parts, but I've got to get my shovel in the ground somewhere and decide how far I need to dig after that.
UPDATE: as I suspected it would, this got the gears turning and produced more questions in my head :-)
First of all, I'd also like to ask about a fairly system independent (and host independent) caching method. Cache::Memcached is super awesome, but I don't know how many shared hosts will support that. What's next best? Cache::File or some such? And begging yet another question, what's to be cached? Yes, Google Ads surely, mostly static front/splash pages, login pages, the obvious, but what else can I cram into that little treasure box to speed things up
I'd also like to address the idea of extendability through something like JSON (SOAP isn't so good nowadays I hear), but do I do it with AJAX? RESTfully? Or as I mentioned JSON? So many to choose from, how do I decide?
WARNING: NOT NECESSARILY PERL SPECIFIC I'd also like to mention I've got an OK method for updates that at least allows for stability in the sense that I can roll back to a previous version if something breaks; I use a central SVN repo for a given project, check it out into my local box, and check it out onto the host (given they support SVN, which brings up another point), and svn update on the production host when updates are running smoothly. But, what if the production host doesn't allow/support SVN? Do I create a whole separate directory on my local box for "stable/production" versions that I svn update as I would on the production box running SVN, and just FTP the files?
Please forgive the incompleteness of this thread, I'm coming up with new questions and ideas as things tumble around in my head.
UPDATE: I'm all about learning and posting what I've learned, and I came across this reply and parent node. I liked the idea.