Why I chose Zend Framework for Enterprise
March 26, 2009
Why I went with Zend Framework for Enterprise
At Panasonic like most large companies we have a plethora of websites ranging from little one off reporting sites to full scale applications. A major problem arrises when these sites are left up to the discretion of the developers to choose their own styles, languages and frameworks(mostly custom to themselves). Site 1 could be in perl, Site 2 in ruby, Site 3 using CakePHP, Site 4 using a user built framework, etc.. When the developer of Site 1 leaves or moves on to another project now we have a maintenance nightmare. Who takes that over? Who really wants to maintain someone else's perl project when they are primarily a PHP developer? I'd rather see that person develop deeper PHP skills.
This was where we were 7 months ago. During that time I've been developing a Zend Framework based application that will house all these sub-apps as "modules" underneath the main Zend umbrella. Management has seen the light as to having a clear, concise codebase that all developers can be trained on and move in between applications with ease, eliminating ramp up time learning different code bases.
After a few weeks of evaluations I settled on Zend for a few reasons. #1 It has a company behind it. It means a lot to me to be able to pay out some budget money to get proper training for developers or have people on the ready for support issues. #2 It's flexible, I can adapt it to the way we work as opposed to being religiously stuck in a coding paradigm. I've been able to leverage the Framework for supporting CLI scripts that have made development insanely fast. #3 stability that there are paid developers actively maintaining, testing and releasing new features. #4 small footprint in the fact I can plug and play different pieces of the framework with ease. #5 there is plenty of documentation and reference book material out there to ramp up quickly which means I don't have to document as much. Some would argue that Zend is slow, however when you have money to budget for load balancers, clusters of servers, slaved DB servers, etc, opcode caching, memcached memory caching, etc... you can tune Zend for acceptable speed.
Since then I've borrowed the SQL migrations concept from rails for more elegant DB updates for all modules. Modules can now be dropped on the server and a "Migrate.php up" script can be run to patch the DB to the proper level. A custom ACL was built on top of Zend ACL to allow fine grained page and ad-hoc permissions. Consistent UI css structures that will allow users to reuse existing UI components and not have to worry about look and feel. Module discovery code for navigation building, as well as general module initializations as well as a host of other features.
I've had my ups and downs with Zend over the years (google: jim plush zend ) but I believe they're on the right track with the framework and we're dedicating all in house development to Zend Framework. If it's a web app it's either built in our Zend Framework infrastructure or it doesn't get built. We've also just contracted with Zend training to do some onsite framework training for all our developers to make the transition as smooth as possible. Upsides to this for developers is the fact you're getting trained for free on the most popular php framework out there and no longer will you have to spend your weekends learning someone's code who just quit.
Some things that will help us keep on the straight and narrow...
1. Code reviews.
NO new modules or releases can go to the test cluster without being approved by a module maintainer. This allows us to spot issues with consistency and security issues
2. Code inspector
I wrote a module code inspector that will check modules code for non-escaped view variables, not using prepared DB statements, leaving debug code in, not registering ACL resources properly, etc.. This helps spot issues before they hit a server
3. Unit tests
Mandating at least all business logic in the models directory have unit tests that hit all public methods.
We've invested heavily in Zend Code Audits, outside Penetration tests for security holes on the web app side as well as the network infrastructure side, scalability and disaster recovery. We'll chat more about those at a later time.
So far Zend Framework and jQuery on the front end are smooth sailing in my book.
At Panasonic like most large companies we have a plethora of websites ranging from little one off reporting sites to full scale applications. A major problem arrises when these sites are left up to the discretion of the developers to choose their own styles, languages and frameworks(mostly custom to themselves). Site 1 could be in perl, Site 2 in ruby, Site 3 using CakePHP, Site 4 using a user built framework, etc.. When the developer of Site 1 leaves or moves on to another project now we have a maintenance nightmare. Who takes that over? Who really wants to maintain someone else's perl project when they are primarily a PHP developer? I'd rather see that person develop deeper PHP skills.
This was where we were 7 months ago. During that time I've been developing a Zend Framework based application that will house all these sub-apps as "modules" underneath the main Zend umbrella. Management has seen the light as to having a clear, concise codebase that all developers can be trained on and move in between applications with ease, eliminating ramp up time learning different code bases.
After a few weeks of evaluations I settled on Zend for a few reasons. #1 It has a company behind it. It means a lot to me to be able to pay out some budget money to get proper training for developers or have people on the ready for support issues. #2 It's flexible, I can adapt it to the way we work as opposed to being religiously stuck in a coding paradigm. I've been able to leverage the Framework for supporting CLI scripts that have made development insanely fast. #3 stability that there are paid developers actively maintaining, testing and releasing new features. #4 small footprint in the fact I can plug and play different pieces of the framework with ease. #5 there is plenty of documentation and reference book material out there to ramp up quickly which means I don't have to document as much. Some would argue that Zend is slow, however when you have money to budget for load balancers, clusters of servers, slaved DB servers, etc, opcode caching, memcached memory caching, etc... you can tune Zend for acceptable speed.
Since then I've borrowed the SQL migrations concept from rails for more elegant DB updates for all modules. Modules can now be dropped on the server and a "Migrate.php up" script can be run to patch the DB to the proper level. A custom ACL was built on top of Zend ACL to allow fine grained page and ad-hoc permissions. Consistent UI css structures that will allow users to reuse existing UI components and not have to worry about look and feel. Module discovery code for navigation building, as well as general module initializations as well as a host of other features.
I've had my ups and downs with Zend over the years (google: jim plush zend ) but I believe they're on the right track with the framework and we're dedicating all in house development to Zend Framework. If it's a web app it's either built in our Zend Framework infrastructure or it doesn't get built. We've also just contracted with Zend training to do some onsite framework training for all our developers to make the transition as smooth as possible. Upsides to this for developers is the fact you're getting trained for free on the most popular php framework out there and no longer will you have to spend your weekends learning someone's code who just quit.
Some things that will help us keep on the straight and narrow...
1. Code reviews.
NO new modules or releases can go to the test cluster without being approved by a module maintainer. This allows us to spot issues with consistency and security issues
2. Code inspector
I wrote a module code inspector that will check modules code for non-escaped view variables, not using prepared DB statements, leaving debug code in, not registering ACL resources properly, etc.. This helps spot issues before they hit a server
3. Unit tests
Mandating at least all business logic in the models directory have unit tests that hit all public methods.
We've invested heavily in Zend Code Audits, outside Penetration tests for security holes on the web app side as well as the network infrastructure side, scalability and disaster recovery. We'll chat more about those at a later time.
So far Zend Framework and jQuery on the front end are smooth sailing in my book.
Louise says:
January 21, 2010 @ 14:16 — Reply
Comment pending moderation