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.

| View | Upload your own

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

• presentación original
  

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.

Sugerencia: no te presentes a este aviso de trabajo (Binbit / Ex-Easylabs)

Lamentablemente tuve la mala experiencia de trabajar unos meses en Binbit (que por un par de años usó en Uruguay el nombre de Easylabs). No voy a dar muchos detalles, pero con los casi 100 empleados que trabajaron y que ahora no están (la mayoría se fueron el año pasado) hay argumentos de sobra para no recomendarlos (más siendo un país tan chico).

Te copio el aviso para que no te olvides -y no importa en qué país estés- no sugiero que te presentes.

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.

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:

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:

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:


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