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".



19 comentarios:

Acido 69 dijo...

hola.
creo que las razones que expresas tienen demasiado peso, y lógica, como para no tenerlas en cuenta.

por otro lado, también creo que eso de inventar un framework nuevo es algo poco útil. Y de seguro que la gente lo hace con las mejores intenciones y con mucho trabajo. pero seamos realistas, no puedes competir con otros que tienen un ejercito de programadores detrás.

creo que esa gente, y nosotros, se vería mejor recompensada aportando cosas nuevas zend_framework(por poner un ejemplo)

proclamo dijo...

Hola, yo soy un semi-colaborador del proyecto Kumbia.

La filosofía base de Kumbia fue lo que me atrajo al proyecto. Me refiero al hecho de que con Kumbia sólo hay que configurar un fichero .ini para la conexión de la DB y poco más y ya puedes ponerte a trabajar. De los otros frameworks php conocidos, el que más se parece a kumbia es Code Igniter. Sin embargo en este también hay que reescribir algunas líneas de código que se repiten en todas las aplicaciones que construyas. En eso gana Kumbia.

Sin embargo, hablando con el desarrollador principal que hay ahora, ya le comenté muchos de los fallos que has descrito. De hecho, debería reescribirse por completo el framework, y aportar cosas nuevas que no aporten los demás. Eso es demasiado trabajo para el escaso apoyo que existe. Por desgracia, la comunidad hispana parece más preocupada por aprovechar que por aportar, y yo no me veo con fuerzas como para afrontar todo ese trabajo entre dos personas.

El único punto que te voy a rebatir es sobre el tema de los tags de apertura y cierre de php en las vistas... todos los frameworks usan la forma abreviada!!!

Creo que el asunto no trata sobre si reinventar o no la rueda, sino en aportar algo nuevo y distinto. Creo que antes de afrontar la construcción de un framework habría que estudiar si existen otros modelos de desarrollo que se adapten mejor a eso que llaman web 2.0 . Para aplicaciones tipo web 1.0 el MVC va muy bien, pero ahora, en mi caso, ya no quiero tener que cambiar de página para ver lo que he editado en un formulario, quiero ver el cambio al instante reflejado en la misma página, que la comunicación entre cliente y servidor sea más fluida. Eso por ahora cuesta mucho trabajo de paso de variables incluso en los frameworks más conocidos.

El otro día descubrí los ezComponents ¿alguien ha trabajado con ellos?¿qué tal?

alejolp dijo...

FLAME WAAAAAAAARRRR

Un poco de humildad del lado de la gente del Framework Kumbia no seria malo.

Los puntos que se marcaron no son defectos ni errores, no hay bugs ni defectos de seguridad que impidan su correcto uso.

La idea es mejorar la prolijidad y lograr de Kumbia un buen framework. Nadie le está cascoteando el rancho a nadie. Una buena critica nunca biene mal, mas aun de gente con experiencia.

Saludos.

Emilio Silveira dijo...

Hola, soy un colaborador activo desde el 2007 del proyecto Kumbia y aqui mi opinion al respecto.

Primero vamos a puntualizar algunos detalles que me parece a Enrique se le han escapado debido a la revisión rápida tal como comenta en el título del post.

Algo que hay que considerar es que Kumbia es un proyecto que es relativamente nuevo, a esto me refiero a que si observan con detalle el copyright data del año 2005.

Recapitulando un poco, para el 2005 ya existían varios frameworks para PHP, sin embargo el Zend Framework, mediante el cual se toma la iniciativa para estandarizar la notación de POO en PHP, data de aproximadamente del mismo año en que se inicio el proyecto Kumbia.

En consideración a esto se observa que no existia un estandar defacto en el mundo PHP, podria ser smallcase o camelcase, por lo tanto en el proyecto Kumbia se opto por la notación smallcase siguiendo un estandar de codificación existente y asimismo el estandar de notación en las funciones de PHP.

Por otro lado ya estamos en el 2008 y camelcase es el estandar en PHP5 para POO. Pero sucede que la migración no se puede llevar de buenas a primeras, existe una comunidad acostumbrada a la comodidad que aporta smallcase (yo me incluyo), asimismo por razones de soporte hacia atras no es factible ni conveniente efectuar ese cambio en la versión 0.5.

Ya en la 0.5 se incluyen nuevos paradigmas, resulta mas conveniente depurar el codigo existente y permitirle a la comunidad conocer y relacionarse con los nuevos paradigmas implementados, para luego poder efectuar un proceso de refactorización del codigo, lo cual seria muy conveniente para la version 0.6.

Con respecto a la codificación de caracteres, Kumbia en la version 0.5, en el archivo config.ini permite especificar la codificacion de caracteres de la aplicacion, por defecto hasta los momentos esta en ISO-8859-1, para el lanzamiento de la version estable se procurara cambiarla a UTF-8, ademas con motivo de poder cambiar de codificaciones sin problemas Kumbia implementa un componente Filter, el cual permite utilizar htmlspecialchars, htmlentities, etc, de tal manera que funcionan de manera transparente a la codificación de caracteres que utilices. Dicho de manera sencilla si cambias la codificación estos se adaptan solos sin tocar una linea de codigo.

Lo otro que comenta Enrique acerca de los Frameworks caseros y el tiempo que uno invierte corrigiendo los Bugs, es totalmente cierto, lo digo a que de este mal adolecian las primeras versiones de Kumbia, principalmente en los helpers, sin embargo poco a poco con algunos aportes que hemos efectuado los desarrolladores, en la version 0.5 se han corregido la mayoria, principalmente los helpers los cuales practicamente todos fueron reescritos.

Por otro lado gracias por el cumplido (lo de mentes privilegiadas, :) ).

Son verdaderamente interesantes las observaciones de Enrique, procuraran ser implementadas de la manera mas conveniente.

Asimismo coincido con Alejo, esto no puede ser convertido en un flame, sin embargo para tratar de manera adecuada las observaciones de Enrique deben enforcarse en un marco histórico.

Espero Enrique continue revisando el codigo de Kumbia, sus comentarios seran escuchados y de ser posible un aporte de codigo no vendria mal :), mientras mas estemos en esto sera mejor.

Este comentario fue bastante largo, pero creo que condenso la mayoria de las inquietudes que pueden presentarse.

Saludos

Enrique Place dijo...

Estimado Acido 69:
> hola.
> creo que las razones que expresas
> tienen demasiado peso, y lógica, como
> para no tenerlas en cuenta.

Creo que solo basta con mirar un poco a los costados y ver qué suceden en tecnologías más maduras que la nuestra.

> por otro lado, también creo que eso
> de inventar un framework nuevo es
> algo poco útil.

Eso es lo que hablamos con otros colegas, famosos ellos de hacer sus propios frameworks ;-), que hace por lo menos un año han desistido de construir el propio para tomar Zend y construir arriba de él, creando un nuevo framework de más alto nivel.

> Y de seguro que la
> gente lo hace con las mejores
> intenciones y con mucho trabajo.

Nadie lo duda, pero es una batalla perdida desde los inicios.

> pero seamos realistas, no puedes
> competir con otros que tienen un
> ejercito de programadores detrás.

Lamentablemente es imposible.

> creo que esa gente, y nosotros,
> se vería mejor recompensada aportando cosas
> nuevas zend_framework(por poner un ejemplo)

Partir de él para construir componentes de más alto nivel, o directamente compartir experiencias y conocimientos en el uso de aplicaciones reales.

Enrique Place dijo...

Estimado Proclamo:

> Hola, yo soy un semi-colaborador
> del proyecto Kumbia.

¿Lo de semi es porque eres el tercero de los 3 que colaboran? ;-)

> La filosofía base de Kumbia
> fue lo que me atrajo al proyecto.
> Me refiero al hecho de que con
> Kumbia sólo hay que configurar
> un fichero .ini para la conexión
> de la DB y poco más y ya
> puedes ponerte a trabajar.

Bueno, pero así funciona Zend y así están todos los proyectos de SURFORCE.

> De los otros frameworks php conocidos,
> el que más se parece a kumbia es Code Igniter.
> Sin embargo en este también hay que reescribir
> algunas líneas de código que se repiten en todas
> las aplicaciones que construyas. En eso gana Kumbia.

No tengo elementos para afirmarlo ni desmentirlo, solo la opinión personal al ver el código fuente.

> Sin embargo, hablando con el
> desarrollador principal que hay
> ahora, ya le comenté muchos
> de los fallos que has descrito.

Bueno, me alegro que sea así, lamentablemente tampoco es nuevo y este tema ya se lo habíamos comentado al autor hace casi dos años atrás, por esa razón me sorprende que no haya cambiando aún.

> De hecho, debería reescribirse
> por completo el framework,
> y aportar cosas nuevas
> que no aporten los demás.

¿Pero para eso volvemos al principio, para qué hacer de cero algo que ya está hecho y probado en otros frameworks? ¿solo para decir que lo hicimos nosotros?

> Eso es demasiado trabajo
> para el escaso apoyo que
> existe.

Eso pasa en todos los proyectos libres, no puedes esperar a que del exterior colaboren mágicamente, tienes que liderar y si los desarrolladores encuentran interés, vendrán e irán esporádicamente.

> Por desgracia, la comunidad
> hispana parece más
> preocupada por aprovechar
> que por aportar, y yo no
> me veo con fuerzas como
> para afrontar todo ese
> trabajo entre dos personas.

Tal vez es momento de repensar la estrategia, tal vez haciendo algo de más alto nivel o más concreto (un aplicativo) pueda interesar más y encontrar más colaboradores.

> El único punto que te voy
> a rebatir es sobre el tema
> de los tags de apertura
> y cierre de php en las
> vistas... todos los
> frameworks usan la
> forma abreviada!!!

¡Y si un millón de moscas comen caca, entonces comamos caca! ;-)

Está mal igual, y así lo dice el manual. No te preocupes, igual he visto código en los manuales oficiales de Zend y algunos colaboradores cometen a veces el mismo error.

> Creo que el asunto
> no trata sobre si
> reinventar o no la
> rueda, sino en
> aportar algo nuevo
> y distinto.

Es la misma idea, si no aportas algo nuevo, vuelves a crear algo que existe.

> Creo que antes
> de afrontar la construcción
> de un framework habría que
> estudiar si existen otros
> modelos de desarrollo que
> se adapten mejor a eso
> que llaman web 2.0 .
> Para aplicaciones tipo web
> 1.0 el MVC va muy bien,
> pero ahora, en mi caso,
> ya no quiero tener que
> cambiar de página para
> ver lo que he editado en
> un formulario, quiero ver
> el cambio al instante reflejado
> en la misma página, que la
> comunicación entre cliente
> y servidor sea más fluida.
> Eso por ahora cuesta
> mucho trabajo de paso
> de variables incluso
> en los frameworks más conocidos.

Justamente en eso se está trabajando en Zend.

> El otro día descubrí
> los ezComponents
> ¿alguien ha trabajado
> con ellos?¿qué tal?

Si mal no recuerdo, en su momento lo probé, y estaba hecho en PHP4.

Tal vez un camino sea tener componentes como tiene ez en Zend.

Enrique Place dijo...

Estimado Alejo:

> FLAME WAAAAAAAARRRR

No tanto ;-)

> Un poco de humildad del
> lado de la gente del Framework
> Kumbia no seria malo.

Estoy de acuerdo, ya estuve leyendo la respuesta del autor y me quedo con la misma opinión.

> Los puntos que se marcaron no
> son defectos ni errores, no hay
> bugs ni defectos de seguridad
> que impidan su correcto uso.

No sé tampoco, no me puse a revisar eso y tampoco creo que sea el más indicado para hacerlo.

> La idea es mejorar la
> prolijidad y lograr de Kumbia
> un buen framework. Nadie le
> está cascoteando el rancho a
> nadie.

Totalmente de acuerdo.


> Una buena critica nunca biene
> mal, mas aun de gente con
> experiencia.

No soy un "gurú consumado" (ni "consumido"), es mi opinión personal de lo que veo.

Enrique Place dijo...

Estimado emilio.rst:

> Hola, soy un colaborador
> activo desde el 2007 del
> proyecto Kumbia y aqui mi
> opinion al respecto.

Bienvenida siempre ;-)

> Primero vamos a puntualizar
> algunos detalles que me parece a
> Enrique se le han escapado
> debido a la revisión rápida tal
> como comenta en el título del
> post.

Si, obvio, veamos entonces... ;-)

> Algo que hay que considerar
> es que Kumbia es un proyecto que
> es relativamente nuevo, a esto
> me refiero a que si observan con
> detalle el copyright data del
> año 2005.

No tanto, 4 años casi, pero lo malo de lo que hablo son elementos básicos, nunca me puse a criticar si funciona o no, si es seguro o no, simplemente de conceptos y criterios "base".

> Recapitulando un poco, para
> el 2005 ya existían varios
> frameworks para PHP, sin embargo
> el Zend Framework, mediante el
> cual se toma la iniciativa para
> estandarizar la notación de POO
> en PHP, data de aproximadamente
> del mismo año en que se inicio
> el proyecto Kumbia.

No es del todo correcto, de todas formas tampoco es excusa si Zend no está sirviendo de referencia para Kumbia. Tardíamente la gente de Zend tomó el "estándar de facto" de la mayoría de los lenguajes POO (por no decir todos).

Por consiguiente, es de mucho antes que existe la nomenclatura "camelcase".

> En consideración a esto se
> observa que no existia un
> estandar defacto en el mundo
> PHP, podria ser smallcase o
> camelcase, por lo tanto en el
> proyecto Kumbia se opto por la
> notación smallcase siguiendo un
> estandar de codificación
> existente y asimismo el estandar
> de notación en las funciones de
> PHP.

Estoy de acuerdo, la falta de estándares claros y de los que había no seguían los de facto, hacen que se generen estas situaciones.

No lo veo como un error grave de Kumbia, lo veo como una sugerencia para mejorar y estandarízar una codificación que deberían tener todos los proyectos de PHP (evitar tener un estándar propio).

> Por otro lado ya estamos en el
> 2008 y camelcase es el estandar
> en PHP5 para POO. Pero sucede
> que la migración no se puede
> llevar de buenas a primeras,
> existe una comunidad
> acostumbrada a la comodidad que
> aporta smallcase (yo me
> incluyo), asimismo por razones
> de soporte hacia atras no es
> factible ni conveniente efectuar
> ese cambio en la versión 0.5.

De acuerdo que tiene costos, pero a la corta o a la larga traerá beneficios... como poder obtener ayuda de desarrolladores de otras plataformas acostumbrados al estándar de facto.

> Ya en la 0.5 se incluyen
> nuevos paradigmas, resulta mas
> conveniente depurar el codigo
> existente y permitirle a la
> comunidad conocer y relacionarse
> con los nuevos paradigmas
> implementados, para luego poder
> efectuar un proceso de
> refactorización del codigo, lo
> cual seria muy conveniente para
> la version 0.6.

O hasta cuestionarse la existencia de "otro" framework, tal vez se podría rever la filosofía y el contenido del framework.

> Con respecto a la
> codificación de caracteres,
> Kumbia en la version 0.5, en el
> archivo config.ini permite
> especificar la codificacion de
> caracteres de la aplicacion, por
> defecto hasta los momentos esta
> en ISO-8859-1, para el
> lanzamiento de la version
> estable se procurara cambiarla a
> UTF-8, ademas con motivo de
> poder cambiar de codificaciones
> sin problemas Kumbia implementa
> un componente Filter, el cual
> permite utilizar
> htmlspecialchars, htmlentities,
> etc, de tal manera que funcionan
> de manera transparente a la
> codificación de caracteres que
> utilices. Dicho de manera
> sencilla si cambias la
> codificación estos se adaptan
> solos sin tocar una linea de
> codigo.

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".

> Lo otro que comenta Enrique
> acerca de los Frameworks caseros
> y el tiempo que uno invierte
> corrigiendo los Bugs, es
> totalmente cierto, lo digo a que
> de este mal adolecian las
> primeras versiones de Kumbia,
> principalmente en los helpers,
> sin embargo poco a poco con
> algunos aportes que hemos
> efectuado los desarrolladores,
> en la version 0.5 se han
> corregido la mayoria,
> principalmente los helpers los
> cuales practicamente todos
> fueron reescritos.

Lamentablemente van a seguir perdiendo la batalla.

> Por otro lado gracias por el
> cumplido (lo de mentes
> privilegiadas, :) ).

Esteeee... eh?! ;-)

> Son verdaderamente
> interesantes las observaciones
> de Enrique, procuraran ser
> implementadas de la manera mas
> conveniente.

Son detalles, tampoco es para volverse locos... pero lo de los atributos públicos si me preocupa ;-)

> Asimismo coincido con Alejo,
> esto no puede ser convertido en
> un flame, sin embargo para
> tratar de manera adecuada las
> observaciones de Enrique deben
> enforcarse en un marco histórico.

Ya di mi opinión y creo que no se justifica, pero se comprende. El tema ahora es mirar para adelante.

> Espero Enrique continue
> revisando el codigo de Kumbia,
> sus comentarios seran escuchados
> y de ser posible un aporte de
> codigo no vendria mal :),
> mientras mas estemos en esto
> sera mejor.

No gracias, ya hice mi aporte ;-), además, estoy convencido que reinventar otro framework php lo único que hará es hacerme perder tiempo, cuando hay tanto nuevo por hacer y puedo apoyarme en estructuras existentes sin que eso afecte mi ego ;-)

> Este comentario fue bastante
> largo, pero creo que condenso la
> mayoria de las inquietudes que
> pueden presentarse.

Como siempre, bienvenido, gracias por el aporte ;-)

erodriguez dijo...

Sr Enrique, para empezar me gustaria preguntarle, ¿El hecho de que existan software para inventarios (por nombrar un tipo) no le permitirian crear uno nuevo con sus propias fortalezas sobre los demas?, es por ello que no estoy muy de acuerdo con su comentario de la reinvencion de la rueda, es decir, que si siquiere reinventar la rueda es porque la que existe no esta cubriendo las necesidades de quien lo quiera hacer, es por ello no es que defienda a los creadores de kumbia, pero en el caso de que ellos esten creando este framework sin importar en gran medida los que existen, es por que esos en este momento no se adaptan o no cubren en su totalidad lo que ellos desean.
Quisiera hacerle otra pregunta, no sin antes aclararle que no soy un programador asi que digamos que bueno que es, hago lo que esta a mi alcance, ¿Cuantos framework conoce usted que tengan su documentacion en español?, los varios que que conozco o de los que he escuchado tienen gran parte de su documentacion ademas de los temas mas importantes en ingles, para no decir que a los hispanos nos olvidan al momento de crear la documentacion, hasta diria que ni siquiera pensaran en nuestra existencia,.
Estoy de acuerdo en que se deben hacer cambios, pero como dijo emilio, eso no se puede hacer de la noche a la mañana, se deben tener medidas para que el cambio sea paulatino.
La opiniones para mejorar nunca estan demas pero su post en gran parte parece como que si nos estuviera vendiendo Zend, sin hacer ninguna mala alucion a ello, pero pareciera una excelente publicidad de su parte, esta demas decirle que la documentacion que he visto de Zend esta en ingles, privelegiado usted que domina el lenguaje, a los que solo lo machucamos como decimos en mi pais nos parece buscar mejor alternativas en nuestro idioma y Kumbia es una excelente.
No hay que negarse a ayudar, nunca se sabe cuando se necesitara de los demas, asi que si algo no le gusta del framework no esta demas su colaboracion, porque como se dice por aca nunca digas de esta agua no bebere.

Enrique Place dijo...

Estimado Alumno:

> Sr Enrique, para empezar me
> gustaria preguntarle, ¿El hecho
> de que existan software para
> inventarios (por nombrar un
> tipo) no le permitirian crear
> uno nuevo con sus propias
> fortalezas sobre los demas?,

Si, obviamente, pero aquí estamos hablando de frameworks, de "herramientas" para construir aplicaciones.

De la misma forma que han nacido innumerables distribuciones de Linux (que todas se parecen), han nacido innumerables frameworks para PHP.

Pero de todas formas, mi crítica no inicia por la discusión de "existencia o no" del framework, simplemente leyendo el código y que oportunamente fue solicitado por el mismo autor.

> es por ello que no estoy muy de
> acuerdo con su comentario de la
> reinvencion de la rueda, es
> decir, que si siquiere
> reinventar la rueda es porque la
> que existe no esta cubriendo las
> necesidades de quien lo quiera
> hacer,

En la mayoría de los casos se reinventa innecesariamente, es la excusa fácil a no haber profundizado en las opciones existentes o directamente, por un tema de "ego" ("es mi [distribución/framework/producto/etc]").


> es por ello no es que defienda a
> los creadores de kumbia, pero en
> el caso de que ellos esten
> creando este framework sin
> importar en gran medida los que
> existen, es por que esos en este > momento no se adaptan o no
> cubren en su totalidad lo que
> ellos desean.

¿Que desean? ¿Hacer otro MVC? No he visto grandes novedades.

Los objetos fueron creados para eso, para poder facilitar el reuso. ¿Qué sentido tiene rehacer cuando se puede reusar?

> Quisiera hacerle otra
> pregunta, no sin antes aclararle
> que no soy un programador asi
> que digamos que bueno que es,
> hago lo que esta a mi alcance,
> ¿Cuantos framework conoce usted
> que tengan su documentacion en
> español?,

No es el punto, la discusión inicia por otro lado, mis críticas van directamente sobre el código, no es el "review" de un producto.

No sé siquiera si el framework funciona y si cumple lo que hacen los screencasts, analicé el código desde el punto de vista de la POO.

> los varios que que conozco o de
> los que he escuchado tienen gran
> parte de su documentacion ademas
> de los temas mas importantes en
> ingles, para no decir que a los
> hispanos nos olvidan al momento
> de crear la documentacion, hasta
> diria que ni siquiera pensaran
> en nuestra existencia,.

No es tan así, Zend tiene abiertos varios proyectos para traducir en cada idioma el manual por parte de los usuarios.

En el caso del castellano, el proyecto se a dormido en la burocracia y no avanzó por los mismos usuarios, no por Zend.

Ahí puedes participar.

> Estoy de acuerdo en que se
> deben hacer cambios, pero como
> dijo emilio, eso no se puede
> hacer de la noche a la mañana,
> se deben tener medidas para que
> el cambio sea paulatino.

Estoy de acuerdo, nunca dije lo contrario.

> La opiniones para mejorar
> nunca estan demas pero su post
> en gran parte parece como que si
> nos estuviera vendiendo Zend,
> sin hacer ninguna mala alucion

Es mi opción personal, así lo aclaro, pero tampoco idolatro un producto o empresa.

Pero me parece bastante razonable seguir el "framework oficial" de PHP.

El otro punto fuerte es que Zend es un "framework de bajo nivel" y permite construir a partir de él, sin tener que estar atado a una filosofía ni una forma de trabajo muy estricta, algo que no sucede con muchos frameworks.

> pero pareciera una
> excelente publicidad de su
> parte, esta demas decirle que la
> documentacion que he visto de
> Zend esta en ingles,
> privelegiado usted que domina el
> lenguaje, a los que solo lo
> machucamos como decimos en mi
> pais nos parece buscar mejor
> alternativas en nuestro idioma y
> Kumbia es una excelente.

No domino el inglés, hago lo que puedo, lo que dudo, consulto a traductores, y sigo adelante, no dejo que eso me detenga con el afán de aprender.

Es un texto técnico, en un inglés técnico, no es una novela, es bastante entendible.

> No hay que negarse a ayudar,
> nunca se sabe cuando se
> necesitara de los demas, asi que
> si algo no le gusta del
> framework no esta demas su
> colaboracion, porque como se
> dice por aca nunca digas de esta
> agua no bebere.

Estoy de acuerdo, de ahí que escribí el post con la crítica que me había solicitado hace tiempo el autor y hasta sirvió para darle un poco más de publicidad al proyecto.

No es tan grave como parece sentirlo el autor.

Unknown dijo...

Bueno,

comentar que actualmente los colaboradores principales somos:

- Emilio.rst
- Deivinson Tejeda
- César Caballero ( aka Phillipo )

Hay algunos semi-colaboradores como bien ha dicho Proclamo ( que lo es )

De kumbia, seamos sinceros, lo que a mi me intereso fue que la comunidad que trabaja en el es hispana, no anglosajona, con lo cual no te ves forzado a usar dicho idioma.

Aqui se comenta mucho a diestro y siniestro sobre otros frameworks, y vale, no somos la Ferrari, Porsche o Masseratti de la industria, pero tampoco somos la SEAT.

Lo que dice proclamo tb es cierto, somos 3 colaboradores, de los cuales dos se dedican al tema desarrollo, yo por mi parte intento llevar el tema de la web y documentacion.

Como dije en el blog de kumbia, en respuesta a tu post, el tema marqueting es para atraer a más desarrolladores a la comunidad.

Emilio Silveira dijo...

Hola Enrique

Entiendo a lo que refieres con la codificación es necesario adoptar la codificación de caracteres UTF-8 en los archivos del proyecto, sin embargo creo que hasta la salida de PHP6 esto no se puede realizar adecuadamente, ya que aun el soporte a UTF-8 no esta completo, por ejemplo si intentas invocar la funcion session_start en un archivo codificado con UTF-8, PHP5 lanza un error, lo peor es que en los tickets, la gente de Zend indica que esto no es Bug, practicamente te dicen que uses ISO-8859-1 para ese caso. Tal como indicas en anteriores comentarios, en PHP6 eso debe estar mas que resuelto :) .

No habia considerado lo de la codificacion de una manera tan integral. Gracias por la aclaratoria, me abriste los ojos al respecto.

Volviendo a lo de smallcase, Kumbia tomo como referencia, a python y ruby, los cuales siguen este estandar, y como todos conocemos en ese tiempo Zend no habia marcado la pauta. De cualquier forma me parece mas conveniente hacer una encuesta en la comunidad y ver que les pareceria para v0.6, cambiar a camelcase.

Bueno esto es cuestion de gustos, tanto como los flames de usar tabs o usar espacios. Todos conocemos que los tabs aportan flexibilidad y los espacios aportan portabilidad, incluso lei un articulo donde recomiendan utilizar ambos, se llama algo asi como la conclusion a la guerra de tabs y spaces :)

Y citandote de manera jocosa, ojo no lo tomes a mal es solo para que se vea que lo de smallcase y camelcase es solo cuestion de preferencias "¡Y si un millón de moscas comen caca, entonces comamos caca! ;-)". Solo por el hecho de que camelcase sea popular no quiere decir que uno debe elegirlo como borrego. Pero como te comente anteriormente me parece mejor consultarlo con la comunidad, hay que ser democraticos ;)

Por cierto algo que me extraña mucho es que Zend, a pesar de que en las funciones utilizan smallcase, en POO utilizan camelcase, solo debido a su popularidad, en vez de conservar la integridad de codificación que venian llevando, si conoces otra razon que los llevo a tomar esta determinación, por favor ilustrame ;) .

En lo que te apoyo absolutamente es en lo que indicas de atributos y metodos, publicos y privados, PHP dispone de este recurso y es mejor valorarlo y aprovecharlo.

Y bueno, con respecto a lo de reinventar la rueda, Kumbia se fundamenta mucho en reutilizar librerias ya existentes, te por seguro que para cuando se inicio, si Zend Framework hubiese estado listo, Andres no se hubiese molestado en programar el FrontController y las capas de abstracción para la BD. Seamos sinceros a todos nos gusta programar, pero también nos gusta mas poder reutilizar codigo ;)

Es bueno este tipo de debates ;)

Saludos.

CaChi dijo...

Hola Enrique,
Bueno yo creo que tu eres un amante formidable de Zend y me parece que tu quieres escuchar algo como "Zend es mejor que Kumbia" bueno eso es para ti! espero que algun tengas tiempo para que de verdad hagas pruebas al framework y no esto que solo viste un solo archivo y sacaste conclusiones a "vuelo de pajaro" de verdad si me preguntas a mi algo de Zend te digo honestamente que me parece "cochino" disculpame si esto te hace sentir mal, como te llamo tanto la atencion el marketing de kumbia revisate la implementacion del filter de kumbia y luego lo comparas con el de Zend :D esto por poner un ejemplo sencillo, tu me diras si quieres hacer de la programación un dolor de cabeza, hasta donde yo se uno debe programar de lunes a viernes y los fines de semana para la playa y kumbia me ayuda a esto y no es facilismo sino "Que Programar debería ser mas fácil"

Enrique Place dijo...

Estimado Phillipo:
> De kumbia, seamos sinceros,
> lo que a mi me intereso fue que
> la comunidad que trabaja en el
> es hispana, no anglosajona, con
> lo cual no te ves forzado a
> usar dicho idioma.

Mmmm... las razones -en mi opinión- no son las mejores, perfectamente estás dando lugar a que "vamos a reinventar la rueda, ya que las existentes no hablan nuestro idioma".

> Aqui se comenta mucho a
> diestro y siniestro sobre otros
> frameworks, y vale, no somos la
> Ferrari, Porsche o Masseratti
> de la industria, pero tampoco
> somos la SEAT.

Por lo pronto sí mientras mantengan errores conceptuales elementales.

> Como dije en el blog de
> kumbia, en respuesta a tu post,
> el tema marqueting es para
> atraer a más desarrolladores a
> la comunidad.

Bien, pero el "márketing engañoso" es muy perjudicial. Conviene que antes de salir a promocionar algo que no cumple lo que dice, que por lo menos se revise y solucione primero esos puntos.

Enrique Place dijo...

Estimado Emilio.rst:

> Entiendo a lo que refieres
> con la codificación es necesario
> adoptar la codificación de
> caracteres UTF-8 en los archivos
> del proyecto, sin embargo creo
> que hasta la salida de PHP6 esto
> no se puede realizar
> adecuadamente, ya que aun el
> soporte a UTF-8 no esta
> completo,

Falso, la mayoría de los proyectos usan UTF-8, es más, creo que ustedes son de los pocos que usan ISO ;-)

Fuera de que sea un proyecto PHP o no, todos los desarrollos y herramientas deben usar en la actualidad UTF y más si son web.

Linux, si mal no recuerdo, hace como 10 o más años que migró a UTF (y la primer distro fue Red Hat).

Este tema no es nuevo ni reciente, busquen información al respecto.

> por ejemplo si intentas invocar
> la funcion session_start en un
> archivo codificado con UTF-8,
> PHP5 lanza un error,

Falso, no sé que están haciendo, pero esa operación es completamente trivial.

> lo peor es
> que en los tickets, la gente de
> Zend indica que esto no es Bug,
> practicamente te dicen que uses
> ISO-8859-1 para ese caso.

Envíame un link a esa información, ya que lo que comentas es algo muy habitual hacer y no presenta problemas.

> No habia considerado lo de la
> codificacion de una manera tan
> integral. Gracias por la
> aclaratoria, me abriste los ojos
> al respecto.

Es un tema que he visto que la mayoría de los desarrolladores PHP no tiene claro, pero es simplemente un tema de orden. Si usas una codificación, todo tu sistema debe usar el mismo tipo, si en algún lado cambia, se romperá el juego de caracteres.

> Volviendo a lo de smallcase,
> Kumbia tomo como referencia, a
> Python y ruby, los cuales siguen
> este estandar, y como todos
> conocemos en ese tiempo Zend no
> habia marcado la pauta.

La pauta que toma Zend (empresa) es a partir de las tecnologías más usadas: Java y .Net (dentro del último estamos hablando de muchos lenguajes).

Python y Ruby no pueden ser considerados estándar.

Es como si argumentara que uso la "nomenclatura X" porque el lenguaje Ada lo usa.

> De cualquier forma me parece mas
> conveniente hacer una encuesta
> en la comunidad y ver que les
> pareceria para v0.6, cambiar a
> camelcase.

Deberían encuestar cuando hacer el cambio, pero no si hacerlo o no.

El lenguaje que ustedes usan es PHP y el estandar de facto para la codificación POO es "camelcase" (aclaro: no es así para lo estructurado, que sigue siendo "smallcase").

> Bueno esto es cuestion de
> gustos,

No sé a que le llamas "gustos" cuando hay estándares en la vuelta que te lo definen.

> "¡Y si un millón de moscas comen
> caca, entonces comamos caca!
> ;-)". Solo por el hecho de que
> camelcase sea popular no quiere
> decir que uno debe elegirlo como
> borrego. Pero como te comente
> anteriormente me parece mejor
> consultarlo con la comunidad,
> hay que ser democraticos ;)

Creo que distorsionas los dichos a tu mejor conveniencia ;-). La estandarización tiene un fin y beneficios claros, si tú me dijeras que cambiaron a "smallcase" por alguna razón entendible, pero hasta lo que veo ahora solo fue una decisión "muy tomada de los pelos", no aportó nada al proyecto, es más, lo perjudica.

> Por cierto algo que me
> extraña mucho es que Zend, a
> pesar de que en las funciones
> utilizan smallcase, en POO
> utilizan camelcase, solo debido
> a su popularidad, en vez de
> conservar la integridad de
> codificación que venian
> llevando, si conoces otra razon
> que los llevo a tomar esta
> determinación, por favor
> ilustrame ;) .

Justamente te lo aclaré en un punto anterior, el "smallcase" se use en la programación estructurada (y lo puedes seguir usando) y "camelcase" si estás usando POO.

Como generalmente en nuestro mundo PHP aún siguen usando ambas (programación estructurada con uso de objetos), deberías ver cosas como (aunque en la realidad hay de todos los colores):

$usuarios_array = Usuarios::getAll();

Esto sería si el retorno es un array, por lo que para ser coherentes no debería ser así:

$usuariosArray = Usuarios::getAll();

Solo se podría hacer así si el retorno es un objeto, ya que presta a confusiones.

El "híbrido" y la confusión se inicia porque PHP nace como estructurado y todas sus funciones son así, estructuradas. Mi solución a este problema sería que el lenguaje contara con "clases wrappers" que definan "clases base" y que cada método "escondan" la función "estructurada".

Por ejemplo, en vez de:

$cadena_en_mayusculas = strtoupper( $nombre );

Debería ser:

$cadena_en_mayusculas = $nombre->toUpper();

Como también:

$cadena_en_mayusculas = String::toUpper( $nombre );

Cuando tienes que buscar algo relacionado con "string", solo deberás buscar dentro de la clase.

> En lo que te apoyo
> absolutamente es en lo que
> indicas de atributos y metodos,
> publicos y privados, PHP dispone
> de este recurso y es mejor
> valorarlo y aprovecharlo.

No me quedó claro qué intentaste decir, pero por las dudas lo aclaro, "los atributos públicos están prohibidos"... no tiene discusión ;-)

Lo de los métodos públicos / privados, ahí depende del diseño, pero no es bueno si una clases tiene absolutamente todos los métodos públicos, generalmente se comete el error de dejar todos disponible al exterior y no ocultar acciones que son internas al objeto (pero para eso hay que hacer un análisis más profundo).

> Y bueno, con respecto a lo
> de reinventar la rueda, Kumbia
> se fundamenta mucho en
> reutilizar librerias ya
> existentes, te por seguro que
> para cuando se inicio, si Zend
> Framework hubiese estado listo,
> Andres no se hubiese molestado
> en programar el FrontController
> y las capas de abstracción para
> la BD. Seamos sinceros a todos
> nos gusta programar, pero
> también nos gusta mas poder
> reutilizar codigo ;)

No creo, actualmente y tomando en cuenta sus últimas respuestas, lo veo todo como un tema de ego.

> Es bueno este tipo de debates ;)

Mientras se pueda intercambiar con altura, bienvenidos ;-)

Enrique Place dijo...

Estimado Deivinson Tejeda:

> Bueno yo creo que tu eres un
> amante formidable de Zend y me
> parece que tu quieres escuchar
> algo como "Zend es mejor que
> Kumbia" bueno eso es para ti!

Si eso entendiste, es que estás razonando mal.

> espero que algun tengas tiempo
> para que de verdad hagas pruebas
> al framework y no esto que solo
> viste un solo archivo y sacaste
> conclusiones a "vuelo de pajaro"

Mirá, tengo buena vista y todo lo que dije es fácilmente comprobable... es más, los desarrolladores y el autor lo confirman (no están de acuerdo con mi opinión, pero reconocen su existencia).

> de verdad si me preguntas a mi
> algo de Zend te digo
> honestamente que me parece
> "cochino" disculpame si esto te
> hace sentir mal,

Para nada, cada uno opta por lo que quiere.

> como te llamo
> tanto la atencion el marketing
> de kumbia

No, me llama la atención el marketing engañoso.

> revisate la
> implementacion del filter de
> kumbia y luego lo comparas con
> el de Zend :D

No es el punto, relee los post y como se origina la crítica al framework.

> esto por poner un ejemplo
> sencillo, tu me diras si quieres
> hacer de la programación un
> dolor de cabeza, hasta donde yo
> se uno debe programar de lunes a
> viernes y los fines de semana
> para la playa y kumbia me ayuda
> a esto y no es facilismo sino
> "Que Programar debería ser mas
> fácil"

Bien por ti, pero veo que no eres objetivo, por lo que opinas en base a sentimientos y no cuestiones técnicas.

Las cuestiones técnicas ya las afirmé y tienen peso, lo que tu afirmas no tiene asidero técnico.

La diferencia es que tú solo defiendes Kumbia, y yo ni defiendo Zend ni ataco a Kumbia, me solicitaron una crítica técnica y técnicamente le están errando en esos puntos (que no son mi opinión personal, son criterios muy generales) y corregirlos les traería beneficios para ellos mismos.

Que no los solucionen ya son de su entera responsabilidad.

Emilio Silveira dijo...

Hola, ahorita es que he tenido chance de leer tu respuesta, a lo que me refiero a los metodos de accesos como un recurso en PHP, es que por ejemplo en Python atributos y metodos son publicos y queda a criterio del programador hacer las cosas correctamente, sin embargo PHP nos ofrece decirle a otros que utilicen nuestras librerias, "no toques eso" o "solo ustedes pueden tocarlo" por asi decirlo.

Algo que me gusta mucho de Ruby a este respecto, es que desde afuera de la clase no puedes acceder a los atributos directamente, es decir la clase es la unica que puede acceder directamente a sus atributos con el "@" y se llaman atributos de instancia, y si otra entidad externa quiere acceder al atributo, bueno ajuro debe utilizar un accesor :)

Creo que se toman bastante en serio lo que comentas de los "atributos publicos estan prohibidos".


Lo otro que me comentas, de que Ruby y Python no son estandar, bueno tampoco Java y .NET son estandar, los estandares son Camelcase, Smallcase, etc, etc, y los lenguajes siguen los estandares.

Por otro lado, ya estamos solucionando diversos problemas que nos comentaste, la clase Kumbia a cambiado bastante gracias al trabajo de Deivinson y pienso que a lo que Deivinson se refiere es a que Kumbia ofrece una manera agradable y sencilla de trabajar, lamentablemente el codigo aun no es estandar pero es algo que iremos solucionando.

Y tienes razon, cada lenguaje sigue estandares, es mucho mejor trabajar con los estandares determinados para cada lenguaje, menos mal Zend se ha puesto las pilas al respecto.

Con respecto a lo de la codificacion UTF-8, revisando mejor me di cuenta que era un problema con el caracter BOM.

Se prevee una total estandarizacion del codigo para la version 0.6 de Kumbia, seria interesante en lo que este listo el release 0.5 de Kumbia le echaras un ojo y nos dijeras tu opinion desde el punto de vista de funcionalidad.

Y siguiendo con el asunto de la rueda ;) yo soy uno de los que no me hubiese molestado en reinventarla, a veces me dan mis toques de locura de hacer mis propias librerias por motivos educativos claro, pero mientras pueda ahorrarme lineas de codigo, bienvenido sea :)

Creo que no se me escapa nada, por cierto excelente presentacion colocaste en el blog, en lo que consigas otra no dudes en colocarla, esta muy interesante.

Saludos.

Emilio Silveira dijo...
Este comentario ha sido eliminado por el autor.
Emilio Silveira dijo...

Disculpa, se llaman es variables de instancia ;), no atributos de instancia.

Saludos

Entradas populares