php smart - Django o CodeIgniter para la aplicación web Turn-Key





admin template (4)


La implementación es claramente un problema para todas las aplicaciones web que no están basadas en PHP, pero creo que las cosas mejoran con los ISP de DreamHost / Engineyard que proporcionan Ruby / Python, etc. de fábrica. También parece que va a haber una gran cantidad de discusiones en PyCon esta semana sobre las formas de solucionar los problemas de implementación. El crecimiento en popularidad de Django, Turbogears y Pylons está impulsando la demanda de mejores soluciones de implementación.

Dicho esto, si su mercado objetivo son las personas que alojan un ISP de muy bajo costo de $ 12 al año, entonces no creo que tengan más opciones que PHP.

Finalmente, una cosa con la que estoy en desacuerdo es ejecutar PHP y Django en el mismo servidor. Estoy ejecutando algunas aplicaciones de PHP en mi servidor con Apache y docenas de sitios de Django con mod_wsgi en modo daemon. Ejecutarlo de esa manera significa que el intérprete de Python no usa RAM en los trabajadores de Apache y viceversa, el intérprete de PHP no está contaminando mis demonios mod_wsgi :)

Voy a construir una solución llave en mano para un mercado vertical, y me gustaría ofrecer ambas opciones: software como servicio, y darles la oportunidad de alojar la aplicación por su cuenta. En otras palabras, pretendo tener opciones de implementación similares a las de Joel's FogBugz.

Soy un programador de Python, y podría volar sobre el proyecto con Django. Aunque hay varias razones por las que prefiero PHP:

1) La instalación de Django y la configuración asumen que tienes acceso a un shell (mi objetivo no es el tipo de programador). Aunque podría ofrecer un servicio de instalación, pero no en sus servidores.

2) Django se ejecuta solo en algunos hosts específicos que deben tener especial cuidado para habilitarlo. Instalando mod_python / mod_wsgi, y muy probablemente la minoría de mis potenciales clientes tendría acceso de root, o incluso un panel de control.

3) Usar PHP significaría que podría ejecutarlo en su servidor existente. No tendría necesidad de moverlos a un servidor habilitado para Django, y no hay tiempo de inactividad para sus correos electrónicos, mientras el DNS se actualiza.

Por otro lado, tengo muy poca experiencia con PHP. Smarty como lenguaje de plantillas se ve bien, y funciona de manera similar a las plantillas de Django. Sin embargo, no ofrece una herencia de plantilla, excepto en una forma muy hackish en la que no deseo utilizarla, ya que podría romper la aplicación si el diseñador lo estropea. ¿Qué piensas? ¡Gracias por adelantado!




Basado en tus propias conclusiones, iría con CodeIgniter. Parece que habría mucho trabajo ayudando a sus clientes a instalar su aplicación web, y supongo que no quiere eso.

Cree una aplicación web fácil de instalar para que pueda concentrar sus esfuerzos en mejorarla y venderla, en lugar de trabajar como administrador de sistemas o escribir extensos tutoriales de instalación.

(Dicho esto, FogBugz no fue fácil de instalar en nuestro servidor Linux, aunque está escrito en PHP. Nos tomó a mí y a mi colega (¡ambos programadores!) Más de un día completo de trabajo para instalarlo. Así que creo que habrá siempre habrá problemas con la instalación de aplicaciones web alojadas en el servidor).




Si desea que su aplicación sea mainstream, entonces su casi obligado ir con PHP. Pasar de Django a PHP es mucho más fácil que ir de PHP a Django. Conoces los estándares, solo necesitas aprender la sintaxis y las funciones de PHP.

Definitivamente usaría un framework PHP. Symfony y akelos son muy similares a Rails (cerca de Django). Por otro lado, Code Igniter, que hace lo que debería, organiza tu código.




La biblioteca de clientes de Memcached se lanzó recientemente como estable. Está siendo utilizado por digg (fue desarrollado para digg por Andrei Zmievski, ahora ya no con digg) e implementa mucho más protocolo de memcached que el antiguo cliente de memcache. Las características más importantes que tiene memcached son:

  1. Cas tokens . Esto hizo mi vida mucho más fácil y es un sistema preventivo fácil para datos obsoletos. Cada vez que extraiga algo del caché, puede recibir con él un token de cas (un número doble). Puede usar ese token para guardar su objeto actualizado. Si nadie más actualizó el valor mientras su hilo se estaba ejecutando, el intercambio tendrá éxito. De lo contrario, se creó un token de cas más nuevo y se le obliga a volver a cargar los datos y a guardarlos nuevamente con el token nuevo.
  2. Leer a través de callbacks es lo mejor desde el pan rebanado. Se ha simplificado gran parte de mi código.
  3. getDelayed() es una buena característica que puede reducir el tiempo que tiene que esperar su script para que los resultados regresen del servidor.
  4. Si bien se supone que el servidor memcached es muy estable, no es el más rápido. Puede usar el protocolo binario en lugar de ASCII con el cliente más nuevo.
  5. Cada vez que guarda datos complejos en memcached, el cliente solía realizar la serialización del valor (que es lento), pero ahora con el cliente de memcached, tiene la opción de usar igbinary . Hasta ahora no he tenido la oportunidad de probar qué tan alto puede ser este aumento de rendimiento.

Todos estos puntos fueron suficientes para cambiarme al cliente más nuevo y puedo decirle que funciona como un encanto. Existe una dependencia externa de la biblioteca libmemcached , pero aún así hemos logrado instalarla en Ubuntu y Mac OSX, por lo que no hay problemas hasta ahora.

Si decides actualizar a la biblioteca más nueva, te sugiero que actualices a la última versión del servidor, ya que también tiene algunas características interesantes. Necesitará instalar libevent para compilarlo, pero en Ubuntu no fue mucho problema.

No he visto ningún framework que haya recogido al nuevo cliente de memcached hasta el momento (aunque no los rastro), pero supongo que Zend se incorporará pronto.

ACTUALIZAR

Zend Framework 2 tiene un adaptador para Memcached que se puede encontrar here





php python django codeigniter