Trabajar varios programadores mismo proyecto
Rubén Pais
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4937 (20100311) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Jose Murillo Fernández
http://es.wikipedia.org/wiki/SVN
--
Has recibido este mensaje porque estás suscrito al grupo "madeinflex" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a madei...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a madeinflex+...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/madeinflex?hl=es.
--
¿Qué es un amigo? Es un único alma que vive en dos cuerpos (Aristóteles).
easo...@gmail.com
Sent from my BlackBerry® wireless device
Julián Diaz
--
"No es más rico quien más tiene, sino quien menos necesita"
[ Anónimo ]
xumerio
servicio por si es de verdad un monserga instalarlo
http://github.com/
Saludos
Xavi Beumala
Si alguien está muy interesado y quiere esperar que me mande un mail directamente.
Saludos
Xavi
Rubén Pais
Rubén Pais
Rubén Pais
Francisco Rodríguez
Un abrazo.
El 12/03/10, Xavi Beumala <xbeu...@adobe.com> escribió:
--
Enviado desde mi dispositivo móvil
Francisco Rodríguez Cala
Victor Azuara
Rubén Pais
Julián Diaz
Hola Rubén, primero aclaro lo de por que a mi modo de
ver trabajar con frameworks y con controladores de versiones es como mezclar
peras con manzanas, son conceptos diferentes.
Vamos por partes:
Swiz: es un framework que sirve para hacer "inversión de control".
Que es esto? la idea se basa en que una clase no tiene porque tener la
responsabilidad de crear (hacer new) sus colaboradores. Para que me sirve? es
simple, cada vez que codificamos una clase y en su constructor le creamos
instancias de otros objetos, decimos que le estamos "inyectando
dependencias" ya que para crear instancias seguramente le tendremos que
setear algunos atributos también. El código pierde genericidad. Por el
contrario esta responsabilidad de crear instancias se la delegamos a un tercero
(eventualmente Swiz), eso lo hace mediante getters y setters (públicos claro)
en la clase q usará estas instancias. Que tiene de bueno delegar la creación de
los objetos? que la clase q los contiene no tiene ni idea a que le está
enviando mensajes, el solo envía y mientras los objetos receptores entiendan
estos mensajes no existirá problemas. Swiz es a Flex, lo que es Spring a Java.
En Spring La configuración de los objetos q se inyectan y a quien se inyecta,
está guardada en un archivo xml llamado application context. Todo esto es muy
útil ya que si quiero hacer objetos "mock" para probar test de unidad
por ejemplo, solo debo cambiar el application context "de verdad" por
este de pruebas y listo. No toco una línea de código por el lado de la aplicación.
Hay una linda explicación con ejemplo en el blog de Martín Bove, miembro de la
lista http://www.martinbove.com.ar/2010/02/swiz-framework-brutalmente-simple/
. Otro tema importante es que se suele confundir muy frecuentemente la inversión
de control (ioc) con la inyección de dependencias (iod) aquí en este articulo
de fowler nos podemos sacar algunas dudas http://go2.wordpress.com/?id=725X1342&site=neelzone.wordpress.com&url=http%3A%2F%2Fwww.martinfowler.com%2Farticles%2Finjection.html
Mate: Además de ser una excelente bebida aquí en mi país, es un
framework MVC para flex. Lo que tiene de genial esto es que podemos mantener
claramente separadas en nuestra aplicación las lógicas de lo que sucede en la
vista y lo que sucede en el modelo de la aplicación propiamente dicha. Esto es
muy útil en los siguientes casos:
- frecuente o futuro cambio de vista, ya sea por parte propia o de terceros
- código limpio! es más fácil encontrar errores si tenemos la aplicación
dividida. Nuestros ojos sufrirán menos (y nuestro cerebro también)
- así como se puede cambiar la vista, también se puede cambiar el modelo fácilmente.
Esto no es frecuente pero es posible.
Otra cosa que ofrece mate es tener bien centralizado u ordenado el manejo de
eventos que sucede a lo largo de la aplicación.
Hasta aquí vimos como de manera "objetosa" podemos dar soluciones
simples y hacer frente a cambios grandes sin rompernos tanto la cabeza. Veamos
que tiene que ver esto con SVN o GIT.
SVN: Subversión es un sistema controlador de versiones de código, llego
con la idea de reemplazar al popular CVS y creo (al menos yo) que lo ha
logrado. Muchas veces en nuestra evolución como programadores, comenzamos
creando copias del código que hasta su momento "estaba bien" y en la
primera de cambio, cuando codificábamos algo erróneo, volvíamos a trabajar con
la carpeta que tenía lo mejor hasta el momento. Esto no está mal pero a la
larga se puede volver caótico:
- comenzamos con dos carpetas, la del código actual y la que tiene el código
"bueno".
- mas adelante ya no nos conformamos con dos, y terminamos haciendo una copia
más en el pendrive por las dudas.
- al final de la semana tenemos 4 o 5 versiones de esas carpetas entre
escritorio, pendrive, cd y el entorno de desarrollo.
- cuando queremos saber cual es la mejor versión terminamos mirando la fecha de
todas las carpetas y nos quedamos con la última.
- se agregan al proyecto 2 programadores más.... listo perdimos con nuestro
sistema de versiones.
Subversión viene al rescate y en lugar de crear copias de carpetas
"commiteamos" el archivo de la clase que cambiamos. Al mismo tiempo
podemos bajarnos los cambios que otros desarrolladores hicieron en clases en la
que no estamos trabajando. No se preocupen que en caso de "desempate"
ya que ambos pudimos haber estado tocando un mismo código, existe la
posibilidad de decidir que versión queda o mejor aún, podemos llegar a mergear
trozos de código de la misma clase.
Una de las ganancias de SVN frente a CVS, que en vez de enviar todo el archivo
entero al servidor, envía solo los cambios ganando tiempo y ancho de banda. No
me voy a poner a contar todas las ventajas de este sistema, pero voy a destacar
la posibilidad de crear "tags", esto lo que hace es guardar la mejor
versión TOTAL del proyecto. Esta opción se utiliza cuando va a haber un cambio
radicalmente grande en toda la aplicación, no solo en algunas clases, por
ejemplo incluir swiz o mate ;)
Otra opción para destacar es la posibilidad de crear "branchs", esto
significa crear un cause en el proyecto, que dos equipos de desarrollo continúen
con "su" versión de la aplicación pero con la posibilidad en el
futuro de volver a unificar (que lio) todo a una aplicación nuevamente. Esto es
muy normal en los proyectos por ejemplo de sourceforge donde diferentes equipos
alrededor del mundo trabajan en una misma aplicación popular.
GIT: Todo muy lindo con SVN pero de la teoría a la práctica hay un
trecho. En muy frecuentes ocasiones me encontré que el servidor svn se había
"tarado" y ni hablar con el versionado de binarios (los archivos de
texto son correctamente tratados mientras q por ejemplo, los .fla que a veces subíamos
o bien no eran visto como cambios, o bien ni siquiera dejaba commitearlos). También
tiene problemas para versionar códigos remotos, a veces para el equipo de
desarrollo q está en otra ciudad era un parto trabajar con svn, la
transferencia no terminaba mas! Linus torvalds y la gran comunidad linuxera que
se la pasaba emparchando kernels se dieron cuenta de todo esto, y comenzaron a
usar un controlador de versiones más inteligente llamado BitKeeper. La
diferencia substancial con svn es que este controlador era remoto. Un día
BitKeeper se volvió pago, y ahí se complico todo. Con esta idea nace GIT, esta
orientado a ser un controlador de versiones distribuido y entre sus ventajas
están:
-fuerte soporte al desarrollo no lineal, se puede hacer branching,
merging e incluye herramientas visuales para recorrer el historial de
manera manera no lineal.
- trabaja de manera distribuida. En realidad cada usuario tiene una versión
local del repositorio, y cada cambio es copiado entre repositorios. Estos
cambios son importados como branches adicionales, y pueden ser mergeados al
repo local.
- el manejo de grandes proyectos es manejado de manera muy eficiente.
No estoy diciendo que GIT sea el mejor sistema de versiones, pero es hoy por
hoy para tenerlo en cuenta, y más en estos tiempos de "remoticidad"
que hacen muy normal tener un equipo distribuido x todo el mundo. Para un mejor
vistazo leer http://en.wikipedia.org/wiki/Git_%28software%29
Conclusión: Si bien es cierto que el uso de frameworks que corten en
"trozos" a la aplicación favorece que muchas manos trabajen al mismo
tiempo en un proyecto, es sumamente desaconsejado. Primero porque los patrones
de diseño no se crearon con ese fin y segundo porque en las manos equivocadas
puede crear más problemas que soluciones. El uso de MVC tiene un
fundamento más especial y no se debe sobre explotar a la aplicación "por
que si". Para esto existen herramientas como SVN, GIT y hasta el viejo CVS
puede servir dependiendo del caso.
J.
pd: palabras más palabras menos se puede haber deslizado algún error, invito a todo aquel q los detecte a corregirlo.