Guías que debe seguir un 'PHP Senior'

Recorriendo el blog desde sus inicios puedo hacer el siguiente resumen de los artículos que sintetizan de alguna forma todo lo que nos falta a los desarrolladores PHP para poder empezar a considerarnos "Seniors".

Esto es lo que he aprendido con los años y he intentado compartir con ustedes, tratando de lograr consciencia de nuestras carencias y que no podemos quedarnos solo con aprender la sintaxis particular de un lenguaje. Tenemos que romper con el modelo clásico de "programador" ("dominio del lenguaje") y pasar a "desarrollador" ("dominio del sistema").

Los artículos fundamentales hasta la fecha
  1. Los desarrolladores debemos profesionalizarnos
  2. Buenas Prácticas de Desarrollo en PHP
  3. Code Smell - ¿A qué huele tu código?"
  4. Principios de Diseño Orientado a Objetos
  5. Programación Orientada a la Interface
  6. Herencia de clases y el "Principio de Liskov"
  7. Diseño en 3 capas
  8. Separar el código de la capa de presentación
  9. NO es necesaria la herencia múltiple
  10. NO es necesario crear un nuevo framework
  11. Capas de Abstracción
  12. Diferencias entre Lenguajes y Plataformas
  13. Estándares o muerte... para PHP
  14. Cómo traducir de UML a PHP5
  15. Los métodos "getter / setter"
  16. Standard PHP Library
  17. Patrones de Diseño
  18. Patrón Singleton en un entorno web con PHP
  19. Es fundamental contar con namespaces
  20. Migrar definitivamente a PHP5
  21. PHP Coding Standard (draft)
  22. Seven Steps to Better PHP code - part 1
  23. Seven Steps to Better PHP code - part 2

Si tuviera que resumir con un ejemplo qué me demostraría -casi sin dudar- que estoy ante un "Desarrollador PHP" que pasó al "siguiente nivel", sería ver usar correctamente las interfaces, implementando siempre una clase que ofrece un servicio y una interfaz para las clases que quieren usar el servicio, cumpliendo con el "Principio de Abierto / Cerrado", pasando de una programación "Orientada a la Implementación" a una "Orientada a la Interface".

PD: no vale si viene del mundo Java y entra esporádicamente al mundo PHP ;-). Esta forma de trabajo muy arraigada en arquitecturas debe ser nuestra misma forma de trabajo, "pensando en sistemas" y no en "páginas dinámicas con acceso a base de datos".

Actualizaciones a través de Twitter exclusivas de PHPSenior


Estaba usando mi twitter personal "enriqueplace" para hacer pequeñas actualizaciones que no necesariamente terminan en un post (microbloging), pero ahora creé un usuario específico "phpsenior" para solo notificar temas relacionados con PHPSenior, links a artículos interesantes, opiniones, si estoy leyendo o respondiendo los correos que me enviaron, opiniones en caliente cuando hay un debate por un post polémico ;-), etc.

En el lateral derecho aparecerá siempre las "últimas novedades" publicadas desde el twitter.

Quién quiera estar actualizado con lo último dentro de la temática de este blog, esta es la herramienta ;-)

Nota: si usas Firefox, con la extensión TwitterFox tendrás en tu navegador notificaciones al momento de cambios en el twitter.

Retomando viejos artículos...

Algunos nuevos lectores me han comentado que al encontrar por primera vez este blog, empezaron a recorrerlo desde sus inicios. Mi primer post, sin introducción alguna, es de mediados de mayo 2005 (aunque en realidad empecé con un blog llamado PHPCinco y luego migré todos los artículos aquí).

Gracias a ellos empecé a recorrer nuevamente mis pasos, y la verdad que muchas cosas han cambiado (por ejemplo, ya no uso regularmente Smarty ni Pear). Pero me estoy dando cuenta que dejé temas colgados por el camino, muy probablemente porque los post son muchas veces registros de estados de ánimo en un momento dado de nuestras vidas y no volvemos sobre nuestros pasos (bueno, por lo menos yo no lo hice ;-)).

Me voy a tomar un tiempo para revisar "mi pasado" y de alguna forma "cerrar" temas que quedaron inconclusos... como el siguiente artículo:

Programación: "Orientada a la Implementación" versus "Orientada a la Interface" - Parte 1

La verdad que imperdonable, así que en los próximos días voy a cerrar este tema con la publicación de la segunda parte (tengo que escribirla), como así también todos los patrones implementados en PHP que me restan publicar (tengo todos los ejemplos en código, me falta comentarlos: Observer, Composite, Proxy, etc) y relacionados con UML.

Novedades en los próximos días ;-)

Noticia: GeckoToolbox - PHP Toolbox based on Zend Framework

Christopher Valderrama (GatorV), estimado colega mexicano (con el cual intercambiamos regularmente información desde hace años) ha liberado su toolbox basado en Zend Framework.


Como no podía ser menos, los fuentes se encuentran disponibles bajo licencia GPL ("Software Libre").

La lista de funcionalidades es importante y creo que todos requerimos alguna vez disponer de ellas:
  • MVC Router:
    • Template Rendering
    • Config System using Zend_Config
    • DB Singleton using Zend_Db
  • Quick DB Authentification module using Zend_Auth
  • Advanced HTML Form Generation
    • Form Decorators, Renderers and Templates
    • Basic Form Controls
    • Advanced Form Controls:
      • Ajax Dependant Selects
      • Date Picker Control
    • Advanced Form Validation using Zend_Validate
    • Auto Form creation via independent Builders
  • Advanced DataGrid Control
    • Auto Sorting
    • Pagination
    • Cell Renderers
    • Grid Formatters
    • Independent DataSources (can show grid from a XML, Array, DB, Zend_Db_Table, etc.)
  • Request Input Filtering (GET, POST, COOKIE)
    • Filter Plugins:
      • Strip HTML
      • Magic Quotes
      • XSS Filtering
      • HTML Special Chars
  • Template System
    • PHP Code in templates
    • Template Helpers
  • XML Generation
  • HTML Helpers, OO Interface for HTML tags
  • Security checking vs a Access List (Zend ACL)
  • Paginator capable of paginating any DataSource
  • URL Generation Module
Recién estoy bajando el proyecto y en las próximas semanas iré estudiando el código y entendiendo su funcionalidad. Muy probablemente en algún momento lo incorporemos a los proyectos de SURFORCE.

S
ugerencia: que de a poco le vayamos tirando ideas y dudas para que pueda ir armando la documentación inicial y que sea fácil empezar a conocer la herramienta. Obviamente todo quién pueda colaborar será bienvenido.

Este tipo de iniciativas deben servir de ejemplo, ya que "no solo de frameworks vive el desarrollador", también se requieren este tipo de proyectos, de más alto nivel.

En hora buena my friend

Se viene la segunda edición de PHP&Beers (Argentina)


Nuevamente, segunda edición, organiza el colega argentino Pablo Rigazzi, invitación desde ZonaPHP. También es importante destacar que estará presente "cvander", el famoso creador de Maestros del Web y Foros del Web. También voy a intentar estar presente, pero no voy a firmar autógrafos en esta oportunidad (tal vez lleve alguna remera para la venta).

El lugar del encuentro:

Cervecería Antares
Armenia 1447, Palermo
Jueves 24 de Julio, a las 19:30 horas
.

Una invitación a conocernos y poder tratar en un ambiente descontracturado los temas que nos interesan, por ejemplo: por qué ya no es "cool" programar estructurado, cómo desapareció PHP4 y por qué Zend Framework es el "framework oficial" de PHP.

Estás invitado, no faltes.

Internet está lleno de charlatanes - parte 2

Volviendo -para algunos- a mi "caza de brujas" y buscando depurar un poco de conceptos que solo generan desinformación por gente que dice "saber de lo que habla".

Aclaro el siguiente punto: si quién escribe este artículo es un novato, procederé con mucha cautela y cariño (sin perder la firmeza), pero si el que escribe es un desarrollador que se auto-promociona como "Senior" y a su vez como "docente", seré "despiadado".

El siguiente artículo (del mismo autor) se titula "Devolviendo mas de un valor en un metodo" y dice lo siguiente:

"Hay caso que nuestro metodo necesitamos que devuelva mas de un valor (esto no deberia ser siempre, ya que un metodo solo hace una cosa y no mas). Esto generalmente se resuelve devolviendo un array. Pero hay otra forma un poco mas clara fuera de la clase, y esto es recibiendo los parametros en una lista, el metodo nos va a devolver un array pero el que recibe los datos va a devolverlo en variables, usando la funcion List."


Amén que todo el párrafo es inentendible, me voy a detener solo en lo resaltado:

"Hay caso que nuestro metodo necesitamos que devuelva mas de un valor (esto no deberia ser siempre, ya que un metodo solo hace una cosa y no mas)"


Volvemos a lo que comentaba en el artículo anterior. Aquí el autor está repitiendo una frase que debe haber escuchado de alguna otra persona o leído en algún otro escrito y lo repite mecánicamente sin razonarlo en absoluto.

Esto en realidad se llama (para más información ver un post antiguo):

SRP - Single Responsibility Principle (Principio de Responsabilidad Única)

Enunciado formal: "Una clase debería tener solo una razón para cambiar"


Por consiguiente, es correcto que una clase debe tener una sola responsabilidad, es correcto que un método debería tener una sola responsabilidad, pero esto no tiene nada que ver con que devuelva uno o más valores, ya que no tiene sentido y se demuestra que el concepto no se entendió en absoluto y lo que se repite es lisa y llanamente pura desinformación.

Intentando seguir el razonamiento, si no se pudiera devolver "más de un valor", nunca podríamos pedirle a una clase de persistencia que nos devuelva un array con el resultado de una consulta sql, ya que nos estaría "retornando más de un valor".

Ridículo, no tiene sentido, no importa por donde lo mires.

PD: nota complementaria, me tomé el trabajo de corregir la entrada de la wiki donde se apoyaba el anterior artículo criticado, ya que no era preciso y genera que personas sin experiencia copien y reproduzcan sin entender que lo que se dice no es correcto.

Internet está lleno de charlatanes



Hay un programa de radio en Uruguay llamado "Malos Pensamientos" que tiene un segmento que se llamaba "¿quién lo dijo?", en el cual el conductor leía una frase "errónea/incoherente/estúpida" y tenías que adivinar quién lo había dicho.

Bien, les paso la frase del momento:

"PHP tiene el problema que sus clases no son persistentes. La persistencia es uno de las caracteristicas del POO".


Es impresionante, una joya.

Explicación

Se entiende por persistencia en la Programación Orientada a Objetos como la acción de preservar la información de un objeto de forma permanente (guardar), pero a su vez también se refiere a poder recuperar la información del mismo (leer) para que pueda ser nuevamente utilizada.

La información que se persiste en la mayoría de los casos son los valores que contienen los atributos en ese momento, no necesariamente la funcionalidad que proveen sus métodos.

La persistencia no es ni una capacidad ni una propiedad de la POO, no tiene nada que ver con el paradigma en sí, solo es el mecanismo que se usa para persistir información de un determinado tipo (como pueder ser serializar, guardar los datos en una tabla, en un archivo plano, etc).

PD: hay que tener cuidado con lo que se lee en Internet, hoy día hay muchos charlatanes sueltos que copian y pegan contenidos de otros y los hacen propios o hasta llegan a transcribir frases que han escuchado pero que nunca llegaron a entender del todo, y obviamente, sin citar las fuentes.

Por suerte cuando empiezan a creer que son capaces de crear, salen con estas perlas.

"No sigas a nadie sin saber primero a quién sigue este"

Ya lo habíamos comentado: "PHP6 = PHP5 + Unicode"

Aunque no de una manera tan clara y tajante, pero lo habíamos comentado en varios intercambios en este blog y en foros, la principal ventaja técnica de la próxima versión de PHP es el soporte unicode.



En resumidas cuentas: vas a poder escribir en tu propio lenguaje, procesar en tu propio lenguaje, sin importar si codificas en inglés o en chino (obviamente, todo debería usar UTF-8, desde el formato del archivo, el editor, los servidores, etc).

El cambio técnico es indispensable (contar con este soporte unificado y dejar de lado el problema de "caracteres rotos"), pero comercialmente hablando, un fracaso, ya que la adopción de esta nueva versión será difícil, ya que el desconocimiento sobre el tema "charset" es enorme.

A partir del slice 31 los ejemplos son bastante contundentes.

Anexo

Habitación de Chat dentro de Google Lively

Para no ser menos y faltar a la costumbre, estoy haciendo el siguiente experimento: he creado una habitación dentro del nuevo producto de Google llamado Lively (una suerte de chat 3D con aspiraciones de Second Life).



Por lo pronto, un lugar de encuentro para probar discutir temas técnicos que tratemos en este blog y en paralelo ver cómo funciona esta nueva herramienta de Google.

Si quieres darte una vuelta a saludar, eres bienvenido ;-)

PD: preparé una isla al estilo "Lost" pero con un poco más de comodidades, ideal para juntarnos a debatir con un lindo paisaje de fondo ;-)

Estándares o muerte... para PHP

Luego de una acalorada discusión sobre el tema estándares y buenas prácticas, paso en limpio y hago un resumen de todo lo hablado, ya que veo que es un tema que los "Desarrolladores PHP" nos cuesta -aún- tomar conciencia.

Nuestros referentes obligados

Zend -la empresa- nos guste o no, debe ser siempre el referente a todo lo relacionado con PHP, ya que no solo desarrollan en la actualidad lo que puede considerarse el "Framework Oficial de PHP" (sin desmedro de ningún otro framework), también es la responsable de desarrollar el propio lenguaje PHP.

La importancia de los estándares

Los estándares nos permiten disminuir muchos costos que surgen a la hora de desarrollar sistemas que van desde la incorporación de nuevos recursos hasta el entendimiento de los sistemas "legacy" ("sistemas heredados") que existen en cualquier organización. Si todos los desarrolladores programan como quieren, o cualquiera inventa su "propio estándar" o toma el de "cualquier estándar que use otro proyecto", indudablemente esto significará caos.

Qué sucede con la empresa Sun y su lenguaje Java

Creo que está de más decir que a nadie de los profesionales que desarrolla bajo Java se le ocurriría no seguir el estándar de Sun Microsystems, y esta empresa a su vez, que es muy metódica y ordenada, tiene predefinidas especificaciones muy claras que explican cómo codificar, cómo programar, cómo usar tal o cual tecnología, para que todos los que usen la arquitectura sigan el mismo criterio.

Empresa Sun == Empresa Zend

Por lo tanto, es de sentido común tomar entonces las sugerencias de Zend como "estándar oficial" y empezar a usar sus criterios (nos gusten o no), sin importar si antes programabas estructurado en PHP con una nomenclatura y ahora quieres seguir usándola, o si no usas Zend Framework y quieres seguir el criterio de otros lenguajes.

Nota: a mi tampoco me gustó la primera vez que vi las llaves de las clases y los métodos contra el margen izquierdo, similar a C o C++, pero a las pocas semanas me acostumbré.

La Historia de PHP

PHP es un lenguaje que desde sus orígenes estuvo pensado para programar de forma estructura o "procedural" (uso de funciones y pasaje de datos a través de parámetros), pero con la evolución de los lenguajes este empezó a ser cada vez más Orientado a Objetos, tomando como referencia el lenguaje Java (en la mayoría de los casos, ya que no hizo lo mismo con el término "namespaces" que en sí lo sacan de .Net).

Aquí surge un híbrido, un lenguaje con una lista interminable de "funciones estructuradas" que empieza a evolucionar hacia los Objetos, que permite crear clases como en Java, pero que por un lado usa la nomenclatura "smallcase" (en todas sus funciones) y por otro sugiere la nomenclatura "camelcase".

"Camelcase Versus Smallcase"

"Camelcase" es un estándar en la mayoría (por no decir todos) los lenguajes POO, por lo que Zend sugiere, al igual que Java y .Net, seguir esta nomenclatura.

1  <?php
2  
3  
require_once 'Usuario.php';
4  
5  
$admin = new UsuarioAdmin();
6  
7  echo 
$admin->getNombre();
8  
9  
?>


Aquí es donde surge el problema (o la confusión), muchos desarrolladores PHP siguen usando el estándar viejo "smallcase" porque así es como inició PHP con la práctica estructurada y todas sus funciones siguen usando esa nomenclatura (ver Anexo a continuación).

1  <?php
2  
3  
require_once 'usuario.php';
4  
5  
$admin = new UsuarioAdmin();
6  
7  echo 
$admin->get_nombre();
8  
9  
?>


Pasando en limpio, para PHP la regla sería:

"Cuando es POO se usa camelcase, cuando es programación estructurada se usa smallcase"


Anexo: hacia donde debería evolucionar PHP7


Mi solución a este problema, buscando una "migración de paradigmas", sería que en PHP7 (ya que para PHP6 no hay miras de hacerlo) se implementen "Clases Wrappers" (envoltura / cáscara) que ocupen el lugar de las "Clases Base" (String, Integer, Boolean, etc) que existen en cualquier lenguaje 100% POO, logrando que cada método "esconda" la función "estructurada" correspondiente y mejorando notablemente la organización del lenguaje.

Por ejemplo, en vez de:

1  <?php
2  
3  $nombre 
'Enrique Place';
4  
5  
$cadena_en_mayusculas strtoupper$nombre );
6  
7  
?>


Debería ser:

1  
2  <?php
3  
4  $nombre 
= new String('Enrique Place');
5  
6  
$cadena_en_mayusculas $nombre->toUpper();
7  
8  
?>


Y también se debería poder hacer algo como:

1  <?php
2  
3  $cadena_en_mayusculas 
String::toUpper$nombre );
4  
5  
?>


Cuando tienes que buscar algo relacionado con "strings" solo deberías buscar los métodos dentro de la clase correspondiente.

Nota: hace algunos años había iniciado sobre este tema un proyecto experimental como parte de mi taller piloto de PHP.

En Resumen

Se sabe que Sun define todos los estándares de Java y a nadie se le ocurre no seguirlos, en nuestro caso están empezando a existir fuertes "sugerencias" de parte de Zend ("nuestra Sun") para seguir el criterio "camelcase", porque justamente, lo usan en la mayoría de los lenguajes 100% POO.

Aquí está el enlace hacia una presentación realizada por Zend sobre las Buenas Prácticas de Desarrollo en PHP y la documentación de Zend Framework donde explica el estándar de codificación del proyecto (indistintamente si usas o no este framework, la guía sirve para todo desarrollo POO bajo PHP).

Para cerrar, resumo la explicación del manual sobre el "objetivo" del estándar de codificación y una frase de la presentación de Buenas Prácticas:

"Buenas normas de codificación son importantes en cualquier proyecto de desarrollo, pero sobre todo cuando varios programadores están trabajando sobre el mismo proyecto. Usar normas de codificación ayuda a asegurar que el código es de alta calidad, tiene menos bugs, y es fácil de mantener."

"No eres tan especial como para necesitar inventar tu propio estándar"


Espero haber aportado un poco de luz sobre el tema.

El autor de Kumbia Framework me responde - Parte II (Actualización)

Bien, leyendo en los comentarios del post original de Andrés Felipe, autor de Kumbia Framework, le comentan:

El 2 de julio de 2008 08:17 AM, Fede?


Si no te gustan las críticas, para qué hacés público un proyecto así?

Saludos.


A lo cual responde:


El 2 de julio de 2008 11:50 AM, Andrés


Este tipo Enrique Place lo único que hace es hablar, nisiquiera trabaja demasiado en "sus emprendimientos", vive de los colaboradores y luego se llena la boca. Es un charlatán barato.


"¿Vive de sus colaboradores?" ;-)

Cualquiera puede ver los logs de los SVN de los proyectos. En un principio existieron un puñado activo y muy concreto de colaboradores (no más que el número de dedos de una mano), y luego por un tema de tiempos bajamos a un par, por lo que mayormente en la actualidad soy el principal desarrollador y cuando tienen tiempo algunos colegas cercanos participan (con los cuales estoy muy agradecido).

Por estas razones es que entiendo a los desarrolladores actuales de Kumbia (3, descontando al autor original que ya no participa, pero hace "márketing") ya que sé por experiencia que los colaboradores para los proyectos libres no se consiguen solo solicitándolo, generalmente uno lidera y a veces, con suerte, puede ser que consigas alguna colaboración.

Todo radicará en el interés que pueda generar en otras personas, como así también la documentación y facilidad para entrar al proyecto, ya que muchos erran al pensar que solo liberando el código es suficiente.

PD: con respecto a las pobres apreciaciones del autor, la verdad, quedaron por el camino. Esperaba un poco de más altura.

Actualización (2/7/2008 17hs):
  • Para variar, ahora "alguien" (andá a saber si el mismo autor) se hace pasar por mi en los comentarios de su post. Hasta el momento nunca comenté en el blog, solo hice referencias desde este blog.

El autor de Kumbia Framework me responde (pero de mala gana)

Cuando un proyecto se vuelve un tema de ego, suceden estas cosas. Lamentablemente cuando somos tan orgullosos no podemos soportar las críticas hacia un proyecto que de por sí fue abierto para acceso de todo el mundo y se solicita colaboración a diestra o siniestra.

Creo haber dejado claro en todo momento que estaba tratando de aportar un grano de arena.

No me voy a tomar más tiempo del que corresponde para responderle (más cuando el autor abandonó hace tiempo el proyecto y actualmente solo quedan 3 colaboradores reales), pero ya es obvio que se equivoca en varias partes:

Punto 1) Dice que mi crítica es "lo suficiente para ser vacía ó poco objetivo". Vacía no lo es porque cada punto que critico es fácilmente observable en el código fuente del framework. Poco objetivo, no sé, si habla de egos, no tengo nada contra Kumbia Framework (no busco su destrucción ni tengo competencia directa ni acciones en Zend).

Punto 2) "Me gustaría saber que métodos deberían ser públicos o cuales no, señor Enrique es usted un genio, en una revisión rápida pudo encontrar la funcionalidad de cada método, evaluar si debe funcionalmente ser publico o privado, luego hacer una estadística y poder concluir. Vaya, estoy lejos de tener esa capacidad."

Bien, si dejara de molestarse como un niño pequeño cuando le critican su juguete más preciado, se daría cuenta que hablo de "atributos públicos", nunca de "métodos públicos", y los mismos está "prohibidos" desde la base conceptual de la POO (creo que hasta cuando me enseñaron objetos en la universidad me dijeron que "los atributos públicos estaban prohibidos").

Punto 3) "A menos que deba reescribir PHPMailer ó SpreadSheet_Excel_Writer (compatibles con PHP4) y asi lucir un hermoso codigo PHP5 las cosas no cambiarán, sería mas objetivo revisar bajo el directorio library/kumbia ya que es una critica al framework "Kumbia"."

Cuando digo que el framework se apoya en clases de PHP4 y el resto está implementado en PHP5, es justamente eso, "debilita el diseño del framework". No más, no menos.

Punto 4) "Existen clases con html mezcladas con lógica de negocio por lo que no beneficia en absoluto la separación de capas", parece que el autor no lo entiende. Simplemente eso, literalmente, no se sugiere mezclar lógica de negocio con presentación. Sea la lógica que sea, sea la presentación que sea.

Punto 5) No sigue el estándar de facto (en todos los lenguajes POO) "camelcase" y usa "under_scores" porque aparece en un artículo de un blog. No se justifica. Sería más lógico tomar de Java o .Net, lo mismo que están haciendo en Zend.

Punto 6) La clase Object de Kumbia no aporta nada, la sugerencia era usar stdClass. El autor me referencia a la clase Object de Java, pero obviamente esta sí aporta algo, no la de kumbia (de ahí la sugerencia de usar stdClass propia de PHP) .

Punto 7) El autor dice (sobre el tema de iso y utf): "Tienes razón, pero hay que ser más objetivo, cambiar a UTF-8 es cambiar una linea de código y en concreto un framework usado casi un 100% por hispanohablantes para el mundo occidental, no verán mucho problema por ello, Pero así como lo dije antes si por una sola linea de código se puede hacer mejor este mundo."

Aquí demuestra desconocimiento con respecto al tema "juego de caracteres". Ya se lo respondí en un comentario a un colega de su proyecto:

"Creo que ustedes, por desconocimiento, están repitiendo este errado concepto... no es solo "con una función de filter lo soluciono"... todo el sistema tiene que estar en una sola codificación, es decir:

Todas las herramientas, Editor de textos, archivos php+css+js+html, base de datos, etc.

ISO, por decirlo de alguna forma, está "deprecated"."


Nota: lo de "poco objetivo" está bastante fuera de lugar.

Punto 8) Sobre mi comentario "Nombres de archivos de clases inician en minúsculas y no en mayúsculas: directorio "library", por ejemplo acl.php -> Acl.php" y su respuesta "El argumento aqui es? Ya sé, Zend lo hace así."

Sí, no solo Zend, pero bien podría ser un punto de referencia para "no reinventar la rueda", el universo no inicia en mi ombligo.

En Resumen

Bien podría decir que publicitan el framework con argumentos que no se ajustan a la realidad (extracto del sitio oficial):

"Kumbia es un web framework libre escrito en PHP5. Basado en las mejores prácticas de desarrollo web, usado en software comercial y educativo, Kumbia fomenta la velocidad y eficiencia en la creación y mantenimiento de aplicaciones web, reemplazando tareas de codificación repetitivas por poder, control y placer."

Nadie dice que deban hacer lo que yo diga ni lo que yo haga, es mi opinión personal y así fue pedida en su momento por el autor... ahora, bien no hace el autor con molestarse porque encuentre cosas a mejorar y sean dichas de forma constructiva y sin faltar el respeto al proyecto.

Cada uno saque sus propias conclusiones.

Entradas populares