November 22nd, 2011 Category: Ambiente de Desarrollo cloud Open source Programacion
3 Comments »
Seguramente les paso muchas veces que tuvieron que heredar algun desarrollo ya empezado, y tenian que perder mucho tiempo leyendo codigo y usando la aplicacion para entender como funcionaba y sin embargo siempre encontraban algo nuevo. Que genial seria poder leer la documentacion de como esta diseñado un software y poder entender, alcance, features, bugs, puntos de entrada, tecnlogias usadas, etc. Lamentablemente esto casi nunca pasa, y tenemos que hacerlo de la forma dificil y lenta. Pero nosotros podemos cambiar eso, e implementar politicas de documentacion para nuestros proyectos.
En estos sistemas podemos agregar documentos, screenshot, imagenes, especificaciones de instalacion, configuracion, librerias a usar, detalle de servidores, listado de grupos de desarrollo (en el caso que sean varios grupos), etc. Todo lo que puede servir para que una persona nueva en el grupo o alguien que herede nuestro codigo pueda entender como funciona leyendo la documentacion del desarrollo.
Como formato ideal de documentacion para este tipo de cosas, me parece que gana el estilo wiki. No solo tenemos wikimedia, sino que tambien contamos con Trac, Confluence, PbWorks, y muchos mas. Pero obviamente si les resulta comodo usar google docs, o archivos con formato Word o Excel tambien es valido, pero por experiencia siempre terminamos teniendo carpetas inecesarias con un monton de archivos que no sabemos de que hablan, y capaz que ya perdieron vigencia.
Aca les voy a contar de algunos proyectos interesantes que pueden usar para sus proyectos.
Mediawiki.
El mismo codigo que se usa para la wikipedia esta disponible para que nosotros podamos instalarlo internamente en nuestro servidor con nuestros documentos privados, funciona de la misma forma que la wikipedia y se puede descargar de http://www.mediawiki.org/wiki/Download/es, dentro de nuestro ambiente lo podemos configurar como una pagina comun y corriente.
Mediawiki es un producto open source. Y no hay que pagar por usarlo
Confluence
Esta es otra alternativa a mediawiki que se presume mas completa y facil de integrar con otras herramientas como Jira.
http://www.atlassian.com/software/confluence/overview
Lamentablemente este servicio es pago. Pueden usar los servidores de atlassian.com o pueden usarlos dentro de su ambiente. Cualquiera de las dos es viable, el producto es muy bueno a pesar de su precio.
Trac

Durante mucho tiempo use Trac, no solo por la wiki, tambien por su integracion con el repositorio de svn, la verdad es que hoy no me resulta comodo, hay muchas alternativas, y esta paso a ser de mis ultimas elecciones. Trac esta desarrollado en python, y tiene plugin para integrarlo con git y creo que tambien con mercurial y bazaar. Es open source y gratuita.
http://pbworks.com/
Basecamp

http://basecamphq.com

Red Mine
Me olvidaba de una de las mejores alternativas opensource, RedMine. Desarrollado en Ruby on Rails, es una excelente alternativa a Jira + Confluence, un producto super completo y libre.
Conclusion
Hay otras soluciones, pagas y gratuitas para documentar nuestros desarrollos. Estas son con las que trabaje, en el proximo articulo vamos a tratar de elegir que software de control de versiones usar, y cual elegir entre tantas opciones nuevas.
No solo es importante configurar un ambiente sino tambien usarlo. Si implementamos algun sistema para documentar y no lo usamos no tiene sentido, es una buena costumbre documentar el codigo, y es algo vital para el futuro inmediato.
November 14th, 2011 Category: Curso Zend Framework
31 Comments »
En el video de hoy voy a mostrarles como hacer un join con otras tablas, en nuestro caso tenemos la tabla posts, y la tabla categories, vamos a tratar de crear posts que tengan una categoria asociada y mostrar los post a partir de la categoria por la que filtramos.
Para esto vamos a usar un Join para mostrar los nombres de las categorias a las que esta asociada una noticia, y un helper de la vista para mostrar el listado de categorias dentro de nuestro layout.
Aca les dejo el video
Como material extra pueden leer Zend_Db_Select aca van encontrar todo lo referente a armar querys con Zend Framework
November 3rd, 2011 Category: php5 Programacion
No Comments »
Como nos dice nuestro maestro Martin Fowler, este patron se utiliza para reducir el numero de lladas a un objeto pasando como parametro un objeto que contenga todos los datos necesarios.
Estoy haciendo un mini proyecto, que pronto subire a github para compartir con ustedes (una vez que termine la documentacion
), en el cual necesito recibir una cantidad de datos, y para evitar que me pasen muchos parametros, opte por recibir un json, con todos los datos. Ahora el problema es que en ese json la persona que usa el servicio puede mandar parametros de mas, o de menos.
Ahora, para que esto sea algo ordenado, cree un Data Transfer Object, con las propiedades que necesito recibir en el json que me envian como parametro.
El servicio que recibe el json, va a instanciar este Data Transfer Object, y despues vamos a pasarle al modelo al metodo save el objeto completo.
Un paso previo deberia ser validar que los datos que recibo via Json sean correctos una vez que lo paso al DTO.
Supongamos que nuestra funcion encola mails a enviar.
Nuestro DTO sera el siguiente
class Application_Model_Mail_DTO
{
public $from;
public $to;
public $cc;
public $bcc;
public $subject;
public $replyTo;
public $htmlBody;
public $textBody;
public $templateParams;
public $htmlTemplate;
public $textTemplate;
}
El metodo que recibe el JSON, seria el sigueinte.
...
public function enqueue($data)
{
$data = Zend_Json::decode($data);
$dto = new Application_Model_Mail_DTO();
$dto->from = $data[‘from’];
$dto->to = $data[‘to’];
// … asi sucesivamente hasta cargar todas las propiedades
$model = new Application_Model_Mail();
$model->save( $dto );
}
Ok, esto es bastante tedioso y termina generando un codigo muy largo para algo que podemos resolver en pocas lineas usando SPL.
Las SPL son librerias de PHP compuestas de algunas interfaces y clases, para resolver algunos problemas como el que tenemos en este caso.
Para este caso yo voy a usar ArrayIterator que convierte mi objeto ( DTO ), y lo convierte en iterable. Ademas me va a proporcionar de un metodo vital en este proceso.
Ahora voy a extender mi DTO de ArrayIterator. Y ademas voy a agrgar un hack en el __construct, para que cuando reciba un array, solo guarde los valores que existen como propiedad dentro de mi DTO. La clase quedaria asi.
class Application_Model_Mail_VO extends ArrayIterator
{
public $from;
public $to;
public $cc;
public $bcc;
public $subject;
public $replyTo;
public $htmlBody;
public $textBody;
public $templateParams;
public $htmlTemplate;
public $textTemplate;
public function __construct( $array )
{
foreach($array as $key=> $value ) {
if(property_exists('Application_Model_Mail_VO' , $key )) {
$this->{$key} = $value;
}
}
}
}
Una vez agregado esto, ahora vamos a ver como quedaria nuestro metodo queue con esta modificacion.
...
public function enqueue($data)
{
$data = Zend_Json::decode($data);
$vo = new Application_Model_Mail_DTO( $data );
$model = new Application_Model_Mail();
$model->save( $dto );
}
Se daran cuenta que quedo mucho mas simplificado el codigo y mientras mas simple mas facil de leer.
Ahora como quedaria nuestro modelo, que recibe este DTO y lo guarda, en mi ejemplo yo uso MongoDb para no tener que mostrarle el schemea de la Base de Datos, y los metodos inserts de MySql.
class Application_Model_Mails
{
private $_collection;
// Insancio la clase Mongo que contiene la conexion, y le digo cual es la coleccion donde voy a guardar los datos.
public function __construct()
{
$db = new Mongo();
$this->_collection = $db->mailer->spooler;
}
public function save( Application_Model_Mail_DTO $properties )
{
return $this->_collection->insert( $properties->getArrayCopy() );
}
}
Como se ve en el ejemplo, validamos que el parametro que recibe save(), sea una instancia de Application_Model_Mail_DTO, si esto es asi vamos a insertar los parametros que devuelve el metodo getArrayCopy(), que es parte de ArrayIterator, el cual devuelve un array con las propiedades de nuestro Application_Model_Mail_DTO.
Un paso previo, y que no contemple en este ejemplo es validar que los datos que se reciben esten completos y sean validos, tengan en cuenta siempre validar y filtrar los datos que se reciben.





