Nuevos intercambios sobre el Proyecto Kumbia Framework

Hace pocos días hice una suerte de "review rápida" del proyecto "Kumbia Framework", a lo que derivó algunos comentarios en VivaPHP y posteriormente una publicación en el mismo sitio oficial.

Creo que vale la pena hacer un resumen en portada con el intercambio que estamos teniendo, ya que he visto en muchos proyectos y a muchos desarrolladores cometer los mismos errores, por consiguiente creo les puede ser útil.

En mi post anterior recibí el siguiente comentario de uno de los responsables del proyecto con lo siguente:

Blogger Deivinson Tejeda dijo...

Hola enrique bueno hay cosas que tomo para mejorar el framework y otras que desde mi modesto punto de vista(mas no malcriades) no vienen al caso o simplemente no pueden ser criticas.

Criticas que Acepto.

1->Clases con Atributos públicos iremos corrigiendo esto paulatinamente.

2->Métodos Extensos...

Critas que NO Acepto

1->Nomenclatura CamelCase solo lo utilizamos para las class, nadie dice q eso se debe utilizar tal y como comentas. Al momento de crearse el framework se decidio tomar para nombres de metodos la notacion small-case

2-> Chasert a pesar que el utf-8 es el mas utilizado no quiere decir que todos se van a regir por ese nuestro framework esta pensado para una comunidad hispana esto quiere decir que existen caracteres especiales por ende el mas idonio para para eso es ISO-8859-1 de paso el framework no te obliga a utilizarlo si el usuario que decide utilizar el framework le gusta mas utf-8 u otro charset lo puede cambiar sin problema...

Pero sin duda que tus criticas caen bien claro con las aclaraciones pertinentes...

25/6/08 10:51 AM

A lo cual le respondo párrafo por párrafo:

Blogger enrique_place dijo...

Estimado Deivinson Tejeda:

Gracias por tus comentarios, te respondo por puntos:

> Hola enrique bueno hay cosas que
> tomo para mejorar el framework y
> otras que desde mi modesto punto
> de vista(mas no malcriades) no
> vienen al caso o simplemente no
> pueden ser criticas.

Bien, está aclarado en mi post que "me tomo el atrevimiento de hacer la siguiente revisión rápida", pero de todas formas no comparto tu opinión (ahora te lo aclaro).

> Critas que NO Acepto

> 1->Nomenclatura CamelCase solo
> lo utilizamos para las class,
> nadie dice q eso se debe
> utilizar tal y como comentas.

Es un estandar en la mayoría (por no decir todos) los lenguajes POO, muchos desarrolladores siguen usando el estándar viejo porque así inició PHP con la práctica estructurada y todas sus funciones usan esa nomenclatura, pero no se debe seguir cuando se habla de objetos.

Por ejemplo, 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 la mayoría de los lenguajes POO (nuevamente, por no decir todos).

Por consiguiente es de sentido común hacerlo así.

Aquí te dejo un enlace de Zend hacia los estándares de codificación: presentación.

De la misma forma, está en la documentación de Zend, pero esto no tiene nada que ver por el framework, es en sí porque la programación que hacen dentro y fuera es siguiendo prácticas generalizadas de POO.

Lo que ustedes están haciendo es seguir las "malas prácticas" de toda la vida que se han realizado en PHP (y lamentablemente es muy común verlo en nuestro rubro).

> 2-> Chasert a pesar que el utf-8
> es el mas utilizado no quiere
> decir que todos se van a regir
> por ese nuestro framework esta

No es correcto, UTF-8 sustituye a ISO como una evolución hacia un sistema que resuelve los problemas del sistema anterior (justamente, los caracteres especiales).

Leer UTF-8

"Por supuesto, la ventaja más notable de cualquier Formato de Transformación Unicode sobre codificaciones heredadas es que este puede codificar cualquier carácter."

UTF-8 sustituye a ISO. Si usan todo UTF-8, pueden escribir cualquier carácter directamente y funcionará sin tener que hacer nada especial.

La única contra es que PHP5 aún no es compatible con UTF-8 a nivel de funciones, es decir, hay muchas funcines que devolverán ISO, pero para la mayoría de los casos es transparente (o a lo sumo usas funciones de encode y decode).

El 90% del desarrollo de PHP6 es migrar todas las funciones para que sean 100% compatibles con UTF-8.

En resumen a "grueso modo" se puede decir que "ISO casi desaparece a partir de PHP6".

Otro artículo de este blog sobre el tema

> pensado para una comunidad
> hispana esto quiere decir que
> existen caracteres especiales
> por ende el mas idonio para para
> eso es ISO-8859-1 de paso el

Falso, existe UTF-8 para cada uno de los idiomas existentes. Si te fijas, cuando creas una base de datos también te preguntará y le puedes decir "utf8_spanish"


> framework no te obliga a
> utilizarlo si el usuario que
> decide utilizar el framework le
> gusta mas utf-8 u otro charset
> lo puede cambiar sin problema...

La idea es que cuando se use un determinado tipo de charset, se use en todas las capas de forma uniforme, de lo contrario puedes tener problemas de "roturas" de caracteres.

Se debe grabar en utf-8, colocar en el cabezal html utf-8, y crear la base de datos en utf-8 (no así las tablas ni los campos, así queda todo estándar según la base).

> Pero sin duda que tus criticas
> caen bien claro con las
> aclaraciones pertinentes...

Las aclaraciones son erróneas, espero que se comprenda.

25/6/08 11:44 AM


A lo cual posteriormente anexo:


Blogger enrique_place dijo...

Adjunto anexo a la discusión, que me parece aporta y complementa:

Post: "¿La empresa cuenta con framework propio?"

Algunos puntos interesantes que comenta el autor:

- "A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas"

- "El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda."

- "En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente"

Con esto no quiero decir que esté de acuerdo o no con el desarrollo de un framework (como en este caso es Kumbia), sino todos los puntos que hay que tener en cuenta, tanto "en contra" como "a favor" a la hora de hacer un proyecto como este, que de por sí es una carrera que se hace "de atrás" y "perdiendo".

25/6/08 12:13 PM


En resumen:


En más de un blog he comentado antes que prefiero evitar reinventar la rueda (hay demasiadas para reusar) y construir "plataformas" que se apoyen sobre estas herramientas, así no perder el objetivo primario y esencial que es "desarrollar sistemas", no "frameworks" (si el objetivo es otro, obviamente esta sugerencia no se aplica).


Seamos pragmáticos. No se justifica los argumento de "si el autor de Ruby On Rails pensara así, no existiría el framework", ya que muy difícilmente estemos dentro de ese grupo de "iluminados" o estemos pensando en crear un framework masivo. Si quieres aprender a hacer uno, bienvenido, pero no se justifica perder el tiempo más allá de lo necesario cada vez que vas a iniciar un nuevo proyecto o cada vez que tienes un nuevo cliente.


Tu cliente o tus usuarios valorarán el proyecto terminado, no necesariamente con qué lo hiciste, si con Zend o con Ruby On Rails, sí que funcione y haga lo que promete.


Como dice la propia presentación de Zend sobre "buenas prácticas":


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


Yo diría que se puede extender también al tema de los "frameworks":


"no eres tan especial como para necesitar inventar tu propio framework".



Crítica: Proyecto Kumbia Framework


Todo empezó con un reciente post del blog VivaPHP, en el cual copian el anuncio de la nueva versión de este proyecto de framework latinoamericano llamado "Kumbia".

Luego de analizarlo, quedo un poco perplejo por tanta cantidad de márketing, y dado que alguna que otra vez hemos intercambiado comentarios con otros colegas en Foros de Web sobre errores conceptuales importantes a la hora de programar Orientado a Objetos, es que me tomo el atrevimiento de hacer la siguiente revisión rápida de esta última versión y encuentro que desde el código se puede ver que:

- Existen muchas clases con atributos públicos: por ejemplo acl/role/exception.php, kumbia.php, etc. Esta práctica es desaconsejable desde los inicios de la POO, por lo cual no hay excusa que valga (y hace un par de años fue un punto muy criticado cuando se nos pidió opinión a GatorV y a mi).

- Existen clases en PHP4 y funciones estructuradas: muchas ubicadas en "library", por lo cual rompe el diseño del framework.

- Existen métodos muy extensos: por nombrar algunos, "main" de kumbia.php, "generate" de report.php, lo que significa que los métodos implementan más de una funcionalidad, lo cual deberían partirse en más métodos o clases.

- Existen clases con html mezcladas con logica de negocio por lo que no beneficia en absoluto la separación de capas.

- No utiliza para los objetos la nomenclatura estándar "camelcase", algo muy usado en casi cualquier lenguaje POO (Java, PHP5 + Zend Framework, .Net, etc): por ejemplo kumbia::javascript_base() en vez de kumbia::javascriptBase()

- Existe una clase Object vacía que no aporta absolutamente nada, por lo cual se podría considerar la alternativa de usar stdClass de PHP.

- Se usa constantemente <?= cuando se sugiere por manual no usarlo por un tema de portabilidad y compatibilidad, por lo cual debería hacer uso de <?php echo $algo; ?>

- Usa charset iso-8859-1 y debería hacer uso de utf-8, estándar definido hace mucho tiempo.

- Nombre de archivos de clases inician en minúsculas y no en mayúsculas: directorio "library", por ejemplo acl.php -> Acl.php

En sí, a pesar que muchos detalles no son graves (aunque hay otros que sí y mucho) me da una sensación bastante encontrada al ver tan "buen márketing externo" por un lado y no condecirse con el interior del código fuente.

Tal vez sería mejor bajar un poco el perfil de los anuncios, hasta por lo menos haber corregido estos puntos.

Espero que esta crítica sea tomada en modo constructivo, principalmente por el autor, ya que una vez me preguntó cuando "le regalaba una crítica sobre su framework".

Aquí está.

"¿Cómo hacer un Twitter?" - versión 3


Está disponible la nueva versión 3, que permite crear libremente nuevos personajes para pasar el rato... veremos en qué termina todo esto ;-)

La idea, con un poco más de tiempo, es hacer un "surforce-twitter" enteramente con Zend, y avanzar en todo el manejo de usuarios, seguidores, etc.

"¿Cómo hacer un Twitter?" - versión 2

Visto el éxito entre los cómicos de siempre, me puse a hacer pequeñas modificaciones al twitter de ejemplo y cambié a una versión con un poco más de humor: en vez de poder darte de alta al sistema y contar qué haces, ahora es:



"¿Qué diría [personaje] en este momento?"

Y agregué algunas imágenes para jugar con la "pizarra pública".

PD: No es un sistema ni pulido ni robusto, es un simple ejemplo que modifiqué a las apuradas. Si luego alguien quiere jugar con él y agregarle funcionalidades, me avisa y le doy un usuario svn para hacerlo.

Los ex-alumnos de mi curso y que no quedaron conformes con su obligatorio, es imperativo que soliciten un usuario y limpien su nombre públicamente ;-)

Obligatorio de ejemplo: "¿Cómo hacer un Twitter?"

En los años que estuve dando clases en ORT sobre Desarrollo POO con PHP5 (folleto), traté de innovar todo lo que puede (y más), buscando adaptarme lo más posible a los alumnos y sus particularidades. Siempre busqué que tanto las clases teóricas delante de una pizarra como en los laboratorios fueran una "práctica" del mundo real. De la misma forma, busqué "contextualizar" los "trabajos obligatorios" para que además de aprender, pudieran tener confianza para realizar sus propios proyectos.

Entre todas las letras que hice, una de ellas fue "hacer un Twitter" (letra completa), por lo cual aproveché para contarles la historia del proyecto, cómo funcionaba el producto, sobre la era Web 2.0, y hacerles entender que perfectamente ellos podrían hacer un proyecto funcionalmente muy similar (nada es imposible) y que muchas veces algo muy simple se puede convertir en un emprendimiento de millones de dólares.


Revolviendo repositorios svn de ejemplo, encontré una versión (svn) (aún no terminada) que usé a modo de guía para las prácticas en los laboratorios. La dejé instalada en twitter.surforce.com y los fuentes accesibles para quién quiera bajarla y probarla.

No tiene nada del otro mundo, tampoco es puramente "una arquitectura en 3 capas" (ni siquiera usar templates), pero creo que a más de uno que esté empezando con Ajax le puede servir de ejemplo (para este caso se está usado prototype).

Nota: tengo pendiente, una vez deje medio congelado surforce-cms y avance con surforce-social, empezar a fabricar con Zend un surforce-twitter ;-)

Presentación: "Buenas Prácticas de Desarrollo en PHP"

Hace un tiempo que vengo recomendando esta presentación como punto de partida para definir un estándar de desarrollo en una empresa. En ambientes Java no se discute quién define los estándares, es la empresa Sun y a nadie se le ocurriría inventar el suyo propio. Además, en el mundo Java existen estándares para todo, desde la codificación, forma de programar, etc.

Read this document on Scribd: php development best practices



En el lado opuesto del mundo estamos nosotros, los del "Mundo PHP", donde cada cual tiene su propio estándar y programa "como quiere" (con todos los problemas que esto acarrea). Para evitarlo, lo mejor que podemos hacer es seguir los lineamientos generales que se desprenden de los documentos de Zend.

Y esta es una buena presentación por donde empezar.

En lo personal, al principio, me costó usar la "llave inicial" de clases y métodos al mismo nivel que la "llave de cierre" (al estilo programación "C"), pero como bien dice este material:

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


Así que me acostumbré. Mi consejo es: úsalo! y no pierdas el tiempo en definir cómo se hace tal o cual cosa, pierde el tiempo con "problemas nuevos".

Más material:

"Optimización aplicaciones PHP - Client side"

Leyendo el material de las ponencias del primer PHPBarcelona (por nuestras latitudes tendríamos que empezar a hacer este tipo de eventos) me encuentro con este buen material que recopila muchas sugerencias para optimizar del lado del cliente nuestras aplicaciones PHP.



De todas formas sugiero: antes de hacer "optimizaciones extremas" (tanto en el rendimiento del lado del cliente como del servidor) nuestra aplicación debe ser "funcional". Uno de los peores males que tiene cualquier proyecto es la "optimización temprana", empezar a optimizar desde el arranque, por lo cual nos olvidamos completamente la arquitectura de nuestro sistema y previendo el futuro crecimiento de la aplicación.

"La optimización temprana es la causante de todos los males"

-Sir Charles Antony Richard Hoare, computador científico británico, después parafraseado por Donald Knuth en su libro El Arte de Programar Computadoras


No será la primera vez que he visto desarrolladores que hacen un "++$a" porque "$a++" es más lento y evitan usar POO porque los "include" ó "requiere" consumen recursos y tiempo al tener que procesarlos.

Lo que nunca me terminan de explicar es (exagerando un poco):

"¿Cual es el costo de desarrollar una aplicación que está completamente metida en un index.php sin espacios, comentarios ni funciones?"


Sí, estamos de acuerdo, va a funcionar "muy rápido", ¿pero quién la desarrolla? ¿cuanto cuesta su mantenimiento? ¿la corrección de bugs? ¿el costo de agregar más desarrolladores al proyecto? ¿cualquier cambio impacta en cadena y afecta la estabilidad del sistema? ¿el efecto "un día después" (un dia funciona, mañana vuelves y dejó de funcionar)?

"la optimización temprana es un antipatrón que se manifiesta por optimizar aspectos de nuestra aplicación sin tener la certeza de que realmente afectan al rendimiento de la misma"

-post de "La masa, el ladrillo, la bota, el bocadillo..."


Nota: La "optimización extrema" es en sí misma un antipatrón, más información sugiero leer el post en Variable Not Found

Hay que tener en claro que la "optimización extrema" está en una punta y la "buena arquitectura" está en otra, pero aún los sistemas más rápidos deben tener definida una clara arquitectura y esta debe ser escalable de alguna forma.

Pero no optimizar tempranamente si aún no es necesario o el contexto de la aplicación aún no lo requiere.

Usando "mooRainbow" en SURFORCE-CMS

Está disponible en la última versión del proyecto (aprovechando que ahora cuenta con Mootools) una herramienta llamada mooRainbow (de 41 herramientas que estoy revisando para usarlas en el proyecto ;-)) que permite abrir una ventana con la selección de colores, lo cual convierte luego a su correspondiente número hexadecimal.

En concreto esta funcionalidad se aplica en la opción "ABM Configuración General" (hay que estar logueado con el usuario "admin" y clave "admin"):

Aquí se puede visualizar (no presten atención a lo estético, por ahora nos vamos a concentrar en lo funcional) los tres campos y una imagen de "arco iris" (?) que si presionamos sobre ella aparecerá lo siguiente:

Ya aprovecho a comentar un error extraño: si lo pruebo en un entorno Win XP + Xampp, los "arco iris" se ven, pero en el hosting de Dreamhost que es GNU/Linux + Apache, las imágenes no aparecen. Si alguien descubre el detalle que me debo estar pasando por alto, ya tendrá acceso al repositorio del proyecto como usuario del mismo para corregirlo (y así podrá alardear con sus colegas y amigos ;-)).



Aquí se puede visualizar los "ALTs" de las imágenes no encontradas con textos "[r]", "[r2]" y "[r3]".

Hasta aquí parte de la experiencia, ahora a encontrar el bug y actualizar el proyecto ;-)

Actualización: al final era un error en la vista, la imagen apuntaba a un directorio que difería con el real por un carácter en mayúsculas, y en Win no distingue y funciona igual, pero en GNU/Linux al ser "sensible a mayúsculas / minúsculas" no encontraba el directorio y no mostraba la imagen.

PD: como siempre gracias GatorV por todas las manos que me das cuando pierdo la paciencia ;-)

"AJAX Libraries API", aparentemente es más útil de lo que parece

Bueno, leyendo luego el artículo de unijimpe y posteriormente el video explicativo de Google veo que tiene un poco más de ventajas de las que creía, aunque igual no lo veo exageradamente útil ;-).

De todas formas es interesante probarlo y sacar nuestras propias conclusiones... por lo pronto me permite eliminar del repositorio del proyecto copias de los frameworks javascripts y solo invocarlas remotamente. Si mañana necesito actualizar alguna, solo es cambiar en el cabezal el número de versión para que lo traiga de la API de Google, sin necesidad de copiar todos los fuentes y volver a hacer un commit a nuestro proyecto.

¿Alguien le encuentra más utilidad práctica a esta API?

SURFORCE-CMS ahora usa "AJAX Libraries API"

Bueno, en sí no es mucho logro y tampoco es un gran avance (tampoco le había encontrado verdadera utilidad la primera vez que leí sobre su existencia), pero a grandes rasgos evita que tengamos instalado en nuestra sistema alguno de los tantos frameworks javascripts y directamente invocarlos/incluirlos desde Google.

En nuestro caso teníamos físicamente instalado en nuestro svn a prototype, scriptaculous, jquery, jquery.ui y recientemente mootools. Ahora, con esta API de Google eliminé del proyecto estos fuentes y simplemente hago:


1  <script src="http://www.google.com/jsapi"></script>
2  <script>
3    // Load jQuery
4    google.load("jquery", "1");
5  </script>



Por lo que incluye remotamente la versión "1" del framework "jquery".

Al momento soporta los siguientes frameworks:

* jQuery
* prototype
* script.aculo.us
* MooTools
* dojo

En nuestro contexto particular, para incluir ahora scriptaculous (que necesita de prototype antes) sería algo por el estilo (usando vistas y una inclusión "selectiva"):

1  <script src="http://www.google.com/jsapi"></script>
2  
3  <?php if( $this->scriptJs == 'prototype' ) :?>
4  
     <script> google.load("prototype", "1.6");</script>
5  <?php endif; ?>
6  

7  <?php if( $this->scriptJs == 'scriptaculous' ) :?>
8  
     <script>google.load("prototype", "1.6");</script>
9       <script>google.load("scriptaculous", "1.8.1");</script>
10  <?php endif; ?>



No es la gran revelación, pero prefiero que los proyectos no tengan "versionados" software de terceros y solo el código propio, ya que luego la actualización individual de los mismos se hace compleja (como sucedería con Zend Framework).

Nota: obviamente que si la API de Google es inaccesible, nuestra aplicación también. Pero bueno, en este contexto particular puede ser útil no tenerlas (más si estamos haciendo pruebas y aprendiendo) y tal vez en otro tipo de proyecto no lo usaría.

¿Ustedes qué opinan? ¿le ven utilidad?

Entradas populares