SURFORCE-CMS: solicitud de colaboración para hacer testing y refactoring

El proyecto SURFORCE-CMS está en su primera versión "madura" por decirlo de alguna manera (¿1.0?), pero quedan algunos pendientes que me preocupan:

  • El primero, hacer refactoring del código que genera el menú, ya que actualmente es "estructurado" y con mucho "hardcode" (fue uno de los primeros códigos que se implementaron cuando empezamos con el CMS, cuando no teníamos nada de experiencia en Zend).

  • Segundo, hacer el testing de la aplicación en general, reportando bugs para que los solucionemos. Por ejemplo, un colega me reportó que al crear un sub-sitio / sección (ABM Sitios) si no le ingresa la "url home" del mismo (la página por defecto) el sitio no arranca y da un error.

Hay muchos detalles como estos que están para resolver, así como ver qué partes no se entienden o no están del todo correctas (tanto funcionales como internas del código) y mejorarlas.

Cada quien encuentre un bug iré autorizando los permisos para que puedan subir el código al svn y pasar a la fama como parte del proyecto (bueno, por lo menos aparecerán en el listado del proyecto en Google Code ;-)

Espero comentarios al respecto.

Artículo: "¿A qué huele tu código?"

Muy buen resumen hecho por Variable not found sobre el "code smell" o algo así "a cómo huele nuestro código" en el sentido de la calidad del mismo y cuales son "los olores" que pueden desprender que nos anticipan que algo está en gradual descomposición ;-).

Nota: para quién no lo sepa, cada vez que tocamos nuestro código por mantenimiento o nuevas funcionalidades existe una "degradación", muchas veces por que lo hacemos apurados (o nos apuran), no teniendo en cuenta el efecto en cadena que puede ir ocasionando.

En metodologías tipo "Programación Extrema" (XP) se considera fundamental que parte de cada ciclo de entrega de software exista *siempre* una etapa de refactoring para ir evitando estos "olores".

Si te interesan estos temas (que deberían ;-)) no dejes de consultar apuntes sobre principios de diseño o de patrones de diseño en este mismo blog.

Aún estamos lejos de Ruby On Rails... a pesar de Zend

Hace un par de años que escribí un artículo para una revista en donde documentaba mis primeras pruebas con Ruby On Rails, en concreto, la instalación y los primeros pasos. Posteriormente me ofrecieron hacer un artículo más profundo, pero la verdad que me quedé sin tiempo como para seguir investigando, ya que estaba más abocado a profundizar mis conocimientos en PHP (que nos falta mucho comparado con otras tecnologías).

Del poco tiempo que pude invertir puedo decir que me encontré que no es tan fácil como lo publicitan, no se hacen sitios tan fácilmente, o por lo menos, no es tan fácil aprender un nuevo lenguaje y un nuevo framework, ni tampoco es fácil cuando los requerimientos se complican (hay que evaluar los costos, todo tiene su costo).

Luego de pasar algunos años volví a hablar esta semana con algunos colegas sobre RoR y para dejarles un ejemplo bien gráfico les puse el video más famoso y marketinero que puede haber, al autor explicando cómo hacer un blog en 15 o menos minutos ;-)

La verdad que luego de no verlo por mucho tiempo me vuelvo a sentir tan sorprendido como la primera vez y ahora, luego de dos años y más experiencia acumulada en PHP + Zend, vuelvo a sacar la misma conclusión:

"Aún estamos lejos de Ruby On Rails" ;-)

Ya que, aunque Zend es la respuesta a la aparición de RoR, y hemos dado muy buenos pasos "estructurales", aún estamos lejos de la productividad que se ven en esos videos. Zend apunta a que tengamos los famosos "scaffolding" y hacer rápidamente ABMs (que tanto tiempo nos consumen).


Hay que destacar que los videos también pueden ser engañosos, ya que puedo entrenarme por una semana, usar el lenguaje que más domino, preparo un desarrollo en concreto (como un Blog) y luego puedo hacerlo y grabarlo de corrido y parecerá que con PHP + Zend todo es "soplar y hacer botellas".

Pero igual, a pesar de todo, aún nos faltan algunas cosas que RoR tiene y que necesitamos cuanto antes.

Así que sigamos adelante :-)

Empresariales: "Despidos en Zend ¿posible venta de la empresa?"


Me hago eco de la noticia comentada en Vivaphp:

"Zend Technologies, "la Compañía de PHP", despidió al 25% de su equipo de Investigación y Desarrollo (por lo menos 10 personas) y a otros a lo largo y ancho de la empresa, aparentemente, en un intento de recortar gastos. Aunque desde Zend declinaron cualquier comentario al respecto, el sitio TechCrunch cree que esta acción podría deberse a que la empresa israelí está ordenándose y haciéndose más atractiva para una potencial venta.

En el 2006, Oracle quiso comprar Zend por una cifra entre U$S 100 y 200 Millones, y quizás todavía pueda estar interesada. Otros probables compradores podrían ser IBM, que ya es un socio estratégico de Zend y hasta la mismísima Microsoft (!)."


Esto no significa necesariamente que le esté yendo mal a la empresa Zend, puede significar un crecimiento de la misma si esta es adquirida por una empresa mayor (pero por favor, que no sea Microsoft! ;-)).

Encuesta: "¿me volví monotemático?"

A veces pasa que un "blog técnico" toma una "dirección técnica" porque su autor orientó sus esfuerzos hacia un objetivo concreto, como en mi caso, ultimamente hacia Zend Framework y proyectos relacionados (bajo el nombre de "surforce").

Muchas veces esto segmenta demasiado a los lectores, algunos pueden estar de acuerdo, otros no, por consiguiente se crea un ambiente de inconformidad con la temática tratada.

Me gustaría entonces saber qué opinan al respecto, por eso he habilitado una encuesta en el cuadro superior derecho y de paso agregué algunos temas como opciones. También pueden sugerir en los comentarios de este post (pero agradecería que igual votaran como tema "otros", así hacemos un seguimiento "gráfico").

Estadísticas de PHPSenior - Abril 2008

La verdad que no sigo mucho las estadísticas más que para tener una idea del perfil de los lectores y de donde me referencian (así poder a su vez comentar en sus sitios).


Lo que me sorprende en lo personal es cómo va pasando el tiempo y mi país de origen (Uruguay) va quedando cada vez más fuera de la estadística, hasta casi desaparecer ;-)

Si a alguien le interesan estos datos, aquí se los comparto.

"¿La empresa cuenta con framework propio?"

Esta pregunta me la he hecho mentalmente todas las veces que alguien me respondió "¿qué framework usan para desarrollar en tú empresa?" y no hay mejor resumen de lo que pienso en la siguiente respuesta del post "Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software":

"Si por cualquier razón la respuesta es "tenemos un framework propio", mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas "porque Spring o JSF no se ajustan a los requisitos de la empresa".

El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda. De aceptar esto, tocará trabajar con tecnologías probablemente obsoletas, tocará corregir bugs que no estarían ahí de utilizar algo probado, o tocará "mejorar" el framework con cosas que ya están implementadas en otras librerías. Un framework propio, puede ser resultado de una mala elección, o quizás de una elección forzada debido a que el producto se creó hace muchos años.

La respuesta ideal dependerá de lo que quiere hacer el desarrollador o del lenguaje, pero a cualquiera que se mantenga un poco al día le será fácil detectar nombres clave. En Java, Spring, Hibernate, JSF, WebWork, Seam, o incluso EJBs serían respuestas válidas. Struts, mmmmm, ok, todavía hay mucho Struts por ahí y siempre será mejor que un framework web propio. En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente."


Sin palabras, 100% de acuerdo.

Si desarrollas PHP, no me vuelvas a decir "no, en la empresa usamos un framework propio
" ;-)))

PD: fuera de broma, antes también era "purista" y quería hacer "todo yo", pero luego te das cuenta que estás perdiendo tiempo en poder realmente resolver problemas importantes y desarrollar o terminar de desarrollar sistemas, dejar funcionando verdaderos proyectos. Los usuarios, tus usuarios, no verán realmente qué framework usas, pero sí, que tu aplicación funcione, por lo cual, apóyate en herramientas hechas y probadas.

¡Nueva versión de surforce-cms!

El proyecto surforce-cms fue uno de los primeros que inicié para empezar a aprender el uso de Zend Framework en situaciones reales, y de paso, compartir información con otros colegas que querían particiar en su desarrollo al más clásico estilo "software libre" (todos salimos beneficiados).

Con el tiempo han surgido nuevas necesidades de "orden" para poder iniciar nuevos proyectos a partir de la experiencia acumulada, por lo que aparecieron surforce-base, surforce-modules y surforce-library. El paso siguiente es "migrar" los proyectos más antiguos a esta nueva estructura, así poder fácilmente alimentarse con el reuso de módulos y de la librería de surforce.

Bien, todo esto lleva trabajo y tiempo ;-), pero por lo menos ahora surforce-cms está mucho más claro y ordenado como para poder entenderlo y/o basarse en él para crear un propio sitio que requiera estas funcionalidades (en sí este no es un producto para usuarios finales, pero sí es muy útil para desarrolladores con intención de dar sus primeros pasos en Zend).

Copio los comentarios que agregué en los commits del repositorio:

"Nueva versión que hace un salto importante hacia la estructura planteada en surforce-base:

- uso de controllers genéricos
- Zend_Layout

Reestructura funcional

- Se terminan de mover casi todos los admins a un módulo "admin", simplificando los controllers

- Se agrega la funcionalidad de "sitios" o subsitios, también se puede usar como "secciones". Todo el cms discrimina según el sitio/sección, es decir, hay noticias para el sitio1 y sitio2, indistintamente.

Nota:
- Se incluye la librería surforce-library porque sufrió cambios para este proyecto, una vez que se actualiza con el svn original, será borrada de este repo."

El paso siguiente es terminar de actualizar desde surforce-cms la librería surforce-library y los módulos a surforce-modules, para finalmente reordenar en módulos con todo su MVC dentro.

Aún quedan detalles por revisar y corregir, pero creo que es un buen "proyecto ejemplo" para hacer pruebas.

Ya actualicé el sitio de pruebas que está en http://cms.surforce.com y pueden ingresar con el usuario "admin" y clave "admin" ;-)

Nota: de la versión anterior a esta hubieron demasiados cambios estructurales, por consiguiente borré los fuentes y volví a subirlos... no sé si les funcionará un update sobre una versión vieja (aunque en teoría sí), y a su vez hubieron cambios en la base de datos, por consiguiente hay que reconstruirla del dump que se encuentra en el directorio "sql".

PD: no te olvides visitar el wiki de surforce, que ahí están documentados muchos tips sobre los sistemas y sobre cómo instalarlos.

No eres un desarrollador Senior si no sabes lo que son las SPL ;-)

Hace más de un dos años, haciendo una consulta a mi colega mexicano Christopher Valderrama (alias GatorV), en el intercambio me dice "¿y por qué no usás las SPL?" (¿?). Atónito, me pregunté "¿será alguna libería para instalar?" ;-), pero no, ocultas casi en el manual estaban las "Standard PHP Library", con muy poca documentación.

Desde ahí es que empecé a usar el DirectoryIterator para recorrer fácilmente una estructura de directorios de forma recursiva con solo:

1  
<?php
2  
foreach (
3       new 
RecursiveIteratorIterator(
4        new 
RecursiveDirectoryIterator(
5        
DATA,
6        
RecursiveDirectoryIterator::KEY_AS_PATHNAME),
7       
RecursiveIteratorIterator::CHILD_FIRST
8       
) as $directory => $info){
9  
10       if (
$this->isFileDat($info)) {
11            
$this->procesarDir($directory);
12       }
13  }
14  
?>



Parece algo complejo, pero probando este código e imprimiendo los valores verás como puedes recorrer su contenido.

Todo esto viene al caso del artículo "5 funcionalidades de PHP que no se puede ignorar", donde entre ellas se habla de la "SPL".

Indudablemente hay mucho para aprender, pero está todo en los manuales. Si te crees "Senior" (no me cuento, me considero eterno alumno), no lo creas hasta por lo menos haber usado alguna vez estas 5 funcionalidades. ;-)

Entradas populares