Friday, May 15, 2009

Me voy

Asi es, me voy, es un poco cansado estar al tanto de escribir o no en este espacio,
el cual creo yo necesitaba hace mucho una renovación,

asi que, aprovechando la idea de "un nuevo ciclo"
dejaré este blog que nadie lee.

Estaré posteando "temporalmente" en geeks.ms
Estaré escribiendo algunas notas en twitter (por cierto, la noticia del VS2008 Beta 1 salió primero en mi twt :P)

Saludos y Mucha Suerte.
PD: Supongo que en algun momento de mi vida compraré un dominio, creare un grupo, tocaré en público...

Friday, April 17, 2009

Movimientos Agiles

Si bien es cierto no recuerdo ya cuando fue la primera vez que lei o fui a una charla de MSF, cuantas veces he conversado al respecto y –lo mas importante- cuantas veces he realizado trabajos basandome tanto en MSF como en MSF for Agile. Debo admitir que me había centrado en ciertas tendencias, dejando de lado revisar frameworks como el presentado por SCRUM o elementos que pueden resultar cotidianos (pero a la vez delicados), como lo es aplicar GTD correctamente.

Pero desde el año pasado, conversando con Gustavo y Raúl, sea por separado y muchas veces en conjunto debido al trabajo o cosas que salen en el camino, es que noté que cantidad de las cosas que recomendaban yo las asumia o mias, o que habia aprendido en el camino o que simplemente “asi debía ser”

Entonces, si muchas de mis preocupaciones ya estaban siendo cubiertas, me dije “por qué no?”, asi que conversando un poco mas con ellos, investigando algunas cosas, preguntándoles o muchas otras entrando como “observador” a las interacciones del Scrum Master, el Product Owner con el Team Project. Asi es, practicamente me escondia para que no me vean, aunque muchas veces me decian “no te metas, Gallina” siento que aprendi bastante, o bueno, al menos una base para seguir leyendo.

Complementando a esto, casi convencido por los agiles como les digo a Raul y Gustavo, es que decidí asistir a una reunion de la comunidad Agile Perú, aunque seguimos en formacion y siento que debemos reunirns y compartir mas, creo que vamos avanzando.
Es asi que mañana haremos nuestra primera charla, en la cual hablaremos de conceptos principales como:
- Manifesto Agil
- Scrum, Scrum Master y Product Owner
- Gente y Colaboración
- Técnicas Agiles.

Claro, es nuestra primera charla, no expondré, quiza en otra oportunidad. Esta vez solo estuve haciendo algunas coordinaciones, de paso que recordaba mis tiempos en la UNI, averiguando sobre el local, proyector o buscando una que otra donacion que nunca esta de mas.

De todo esto solo puedo decir que si bien es cierto no me se el manifesto agil de memoria, puedo conversar al respecto, puesto ya lo conocia :P pero estoy viviendo y confirmando muchas teorias que tenia latentes.
Confirmando ademas –y esto lo pongo en otra linea por la importancia que es debida- la frase que dijo alguna vez un buen guru de GNU, barboncito:
“Si Linus cree que no debe documentarse nada, es porque Linus tiene la capacidad para comprender todo sin necesidad de un documento, pero nosotros no tenemos esa capacidad, es por ello que, documenta lo necesario, no todo”

Solo me queda mencionar que la agenda pueden encontrarla en esta direccion, la pagina de la comunidad es esta, y agradecer a Ronald Armas (Microsoft Peru) y a Cibertec por el apoyo brindado.

Y si me preguntan porque recien posteo esto, es que, lo estaba escribiendo cientos de veces en mi twitter!!

Monday, February 23, 2009

Usa esta tecnología, pero… por qué?

Hoy mientras conversaba con unos amigos me quedo la duda y a la vez molestia ante un sustento presentado.

”Es que es drag and drop, eso haría mas productivo el trabajo…”

Cuando pregunté si es que se habia hecho alguna comparativa, benchmarking, estudio o “algo” al respecto, para verificar tal productividad, me repetian una y otra vez eso del drag and drop.

Yo la verdad, no se que decir al respecto, pienso que es de muy poca seriedad alegar características que, es cierto, son muy bonitas e interesantes en primera instancia, pero a la larga lo facil, como que… sale caro, no?

En resumen, qué deberia tomarse como característica clave para estas alternativas?
Considero inicialmente:
- Facilidad de uso: es decir, una curva de aprendizaje apropiada
- Complejidad de posibles mantenimientos: que las modificaciones sean de bajo costo y no se necesite un gurú para resolver el problema.
- Estabilidad del producto: cuidado con aquellos en beta, alpha o la primera version “estable”
- Soporte de comunidades de desarrollo o proveedor: una comunidad activa implica que el producto va por buen camino.
- Papers desarrollados por otras entidades: si otros hablan, es por algo, no? (aun recuerdo cuando Oracle no tenia una seccion .net)
- Documentación OnLine/OffLine variada: Si hay libros y no son del tipo “for dummies”  o “… en 24 minutos”, pues es un indicador a considerar. 
- (Muy importante) Frameworks asociados?: es decir, si hay plataformas o mas de un framework que lo usa de manera “seria”, pues deberia considerarse.


Bueno, pero, deberia tomarse otro punto a considerar?

Sunday, February 08, 2009

Sobre los temas que me gustaria conversar (y que converso hasta en el almuerzo)

De por si son muchos, pero ultimamente estamos pensando en seguir una serie de sesiones al respecto,
Aqui los temas que, como dije, converso o quisiera conversar, incluso en la hora de almuerzo:

  • MSF Agile
  • Arquitectura Orientada a Servicios (desde POO)
  • Pruebas Unitarias en .net
  • TDD, como aplicarlo.
  • Visual Studio 2010
  • Practicas y Antipracticas en Toma de Requerimientos
  • Practicas y Antipracticas en Diseño de Software
  • Desarrollo .net usando Herramientas Gratuitas
  • Análisis y Métricas de Código
  • Profiling de Aplicaciones .net
  • Administración de Excepciones .net

Bueno, ahora me despido, pues, queda mucho por hacer y estoy mas que enfermo (maldita gripe, tos, todo)

Saludos[at]Cama

Wednesday, January 21, 2009

GOFx – Primeros pasos: Estandares de Programación


Vía twt publiqué algunas fuentes que podían servirles para definir sus estandares de programación, aquí pondré una que mencioné en el post anterior, pero antes de terminar esto la idea es que el equipo se sienta comodo con las reglas que tengan que cumplirse.

El problema en esto, es encontrar el punto clave en el que uno no esta presionando al equipo por cumplir las reglas y recomendaciones de codificación ni esta dejando de lado las convenciones que eliminan el riesgo al desorden, aunque si bien es cierto, existen herramientas como FxCop o el analizador que viene con VS2008 para sentirse uno presionado.

En fin, lo que pueden tomar como base para un desarrollo .net podría ser lo siguiente:
- Naming Guidelines, directo de MSDN. Vale la pena revisarlo.
- .Net Programming Standart Conventions. Una alternativa muy similar pero listado de manera mas resumida.

Para lo que respecta a base de datos, confío que puede servirles como base uno que encontré hace un tiempo vía .net a 2860m de altura:
- SQL Server Guidelines. muy recomendado mas aun si es desarrollado por un MVP.
- SQL Server Naming Conventions, un documento de 16 páginas que debe ser revisado!

Sin mas me despido, espero que les haya servido.
Saludos.

Actualizacion GOFx: Nuevos Lineamientos de Desarrollo

Asi es, aqui estamos por liberar una nueva versión del framework,
de por si tambien está incluido el bloque de reglas de programación (ojo, dije programación, no construcción), tanto en .net como en sql.

Para los que siguen mi twt (los cuales deben ser miles!!) habrán notado que mencioné que hoy se liberan tales documentos, la verdad quisiera hacer algo mas público, pero ya que estamos aquí, suelto la pregunta:

En que se basaron para el estandar de desarrollo que utilizan?
De por si es muy valido usar los lineamientos por Microsoft (como por ejemplo lo de esta dirección), pero tomaron otras fuentes? Por nuestra parte agregamos/quitamos/resumimos algunas secciones.

La verdad es que hasta el momento sigo encontrandome con personas que el estandar lo tienen en la cabeza (si, y nada mas que en ese lugar).
Algun comentario les pondré ni bien termine con todo el trabajo de por aquí.

Saludos.

Monday, December 22, 2008

El código que si debería preocuparte

Basándome en la premisa de "pensar que cosas hacer en vez de como hacerlas", es que debemos tener cuidado al momento de diseñar o presentar ciertas recomendaciones.

Dado que, de acuerdo a lo que debe hacerse, se plantea un esquema de construcción, y luego de priorizar dichas actividades uno debería tener ya en cuenta que las funcionalidades van por delante del código/librerías a construir/implementar. Y que, dicho sea de paso, las funcionalidades determinan los contratos "mínimo/suficientes" que deben considerarse para determinar el cumplimiento de los requerimientos.

Con estas funcionalidades transformadas en contratos es que se tienen que trabajar los conocidos casos de prueba (me parece es que David estaba hablando de pruebas en su ultimo post?) desde el inicio del proyecto, ya que a mi parecer, estos casos se van enriqueciendo con el pasar de los días. De ser asi, por que esperar hasta terminar el desarrollo para tener listo todo el set de pruebas?
Que si es posible lo contrario? creanme que he experimentado situaciones en las que no consideraban la construcción de casos de pruebas desde el inicio.

En si, las pruebas, independientemente de la manera en que sean ejecutadas (el cual es un tema largo de conversación) deben en primer lugar, enfocarse en los resultados y cumplimiento de estos contratos "mínimo/suficientes". Dado a que, en resumidas cuentas, nuestro trabajo es reconocido por si el producto funciona. Si no es asi, favor corrijanme si es que al usuario no todo le parece transparente.

He notado que en la mayoría de situaciones es menos probable encontrar la explotación y seguimiento de resultados de casos de prueba, puesto que, principalmente es el código que le preocupa a cada desarrollador.
Pero que sucede con el caso del resto de componentes? es decir:
- Librerías de la compañía (Librerias de uso comun, como acceso a datos o correo)
- Librerías especializadas-externas (Proveedoras de controles/componentes/etc.)
- Librerias Open Source

Lo que debe tomarse ya como cierto es que no tenemos que caer en el juego de "lo necesito, lo construyo". Dado a que, tiempo es dinero y ese dinero es el que estamos ahorrando para disminuir costos, a corto o largo plazo.

Considero que a pesar de ello debe tenerse bastante cuidado con las librerias con las que se decida trabajar. La importancia con la que se maneje tal situación determinará el cumplimiento del objetivo de "no reinventar la rueda"
Y porque digo esto?

***Caso: Librerias de la compañía
Creo que en cierto punto, casi todos hemos pasado por la situación de haber construido un componente que "a nuestro entender" puede convertirse en algo de uso común.
El problema viene cuando dicho componente/librería/control/piece of code, no está del todo documentado o peor aun, luego de algunas pruebas llegamos al punto de "ese caso no nos ha pasado, pero no debería caerse".
Esto en vez de aportar al proyecto puede convertirse en un cuello de botella.

Pues que solución?
Entre tantas, creo con un poco de Gestión de la Configuración y algo de compromiso de parte del Gestor o responsable para que al liberar versiones de componentes de construcción, estos se mantengan estables, documentados o en todo caso, autosostenibles que permitan el correcto uso de las funcionalidades que brindan.
Creo que tambien ayuda un poco menos de ego, no les parece?

***Caso: Librerías especializadas-externas
Este tema es mas que conversable, pues estamos hablando de pagar por librerías de uso comprobado.
El problema está en que muchas veces nos dejamos llevar por las propagandas o animaciones que podemos encontrar en la red. Creanme, que a veces es asi.
El caso es similar si es que hablamos de complejidad de uso, documentación, ejemplos y lo mas importante, costos de soporte. En algunas situaciones, este deja de ser gratuito (muchos de mis amigos me dicen que alli radica el negocio, o no?)

Pues que solución? Evaluacion directa de las alternativas de compra, asi como tambien la revisión de la actividad pública de los foros de usos de la librería y de la rapidez de respuesta y aportes brindados por el soporte de la empresa.
Como punto adicional, algo que debe considerarse en la evaluación, es la periodicidad de fixes/patchs liberados, la compatibilidad hacia atras, y ademas claro, de la caducidad del contrato.
En mi caso he pasado por estos procesos de evaluación. Sinceramente es algo tedioso, ya que no estamos hablando de un juguete para navidad, esto es algo serio!

***Caso: Librerías Open Source
Este aspecto es de por si delicado, ya que ademas de la estabilidad, documentación o ejemplos de uso, debemos considerar aspectos como el nivel de aporte brindado por la comunidad (se de un caso en que el proyecto fue cerrado porque el unico que desarrollaba era el dueño de la idea, asi que un día se cansó y dejó de hacerlo).
En si, los riesgos o problemas identificables en este aspecto son similares a los encontrados en el caso de las librerías especializadas, pero bajo la premisa que la empresa de terceros es ahora una comunidad abierta y algunas veces, volatil.

Pues que solución? En las evaluaciones debe considerarse el aporte de la comunidad en lo que desarrollos se trata, ademas de la periodicidad de releases y compatibilidad con nuestras plataformas de trabajo. 
Si hemos llegado aqui, debemos coincidir en un punto medio, ya que tampoco conviene estar actualizando constantemente las librerias.
Lo que no debe olvidarse de que las ideas Open Source no dejarán de ser buenas ideas, pero que muchas veces caemos en trabajos de entusiastas (esto claro, sin animo de ofender a nadie) que -muchas veces- cubren el trabajo bajo la idea de "primero que funcione luego ya veo".
Asi que, debemos atenernos al riesgo de encontrar disparidad de estándares, manejo de memoria, falta de ejemplos, etc.



En resumen.
De por si son demasiados los aspectos que debemos considerar en nuestras preocupaciones sobre que parte de código probar o no, pero muchas veces olvidamos darle cierta importancia a algunos empaquetados que "se supone" deberían funcionar correctamente.
Creanme, somos humanos, existe aún código por probar.

Nota: Les recomiendo el libro "Code Leader", al escribir este post recordé claramente algunas recomendaciones que pude resumir brevemente, creo que el capítulo se llamaba "Buy or not buy code".

Saludos[at]Cama

Friday, November 28, 2008

Elementos que no dejo de usar en la red.


No acostumbro tener demasiadas ventanas abiertas, pero gracias al Chrome y conversando con David, les comparto algunas herramientas web que uso ultimamente...
Esto claro, sin orden en particular.

- Google Reader: De todas formas, imprescindible... requiero leer entre lo básico del día, miscelánea, gurúes y demas temas que muchos dirían "y que significa esto?"

- Web de Noticias: BBC de Londres - El Comercio Perú, pues bien, trato de leer cosas variadas, intento si, seriamente no ubicarme en temas dolorosos (No a la Violencia)

- GMail: Correo que sin darme cuenta se volvió en mi cuenta personal!

- Google Analytics: No diariamente, pero si cada cierto tiempo.

- Google Alerts: La verdad es que, me entero de muy buenas cosas, y todo esto... sin esfuerzo alguno!

- Twitter: Bueno, este es un vicio que vale la pena tener en cuenta!


Como pueden notar, no son muchas las cosas que considero imprescindibles, pero entre los feeds y alerts que reviso, tengo muchísimo por revisar.

Lo preocupante es ver como cada día soy uno mas, un Google Fan Boy que sigue usando "productos beta", pero bueno, mientras no compren TwT seguiré tranquilo (asi que FaceBook, apurate con la compra)

Sin mas me despido, y ya saben... Jersson tambien tiene twitter.


Saludos[at]Cama

Sunday, November 16, 2008

Recuentos del PDC2008 - IV

Del último día solo puedo decirles
- "M" se vé muy bonito, Chris Anderson se lució en la presentación, pero siento que aun falta demasiado por recorrer (eso no quita que tenga el libro y lo haya revisado rapidamente durante todo todo el trayecto de regreso a Lima)

- F# es mas de lo que parece!, Luca Bolognese tuvo una de las mejores presentaciones que he visto en mucho tiempo. Les cuento que cuando terminó su sesión, pues salí en busca en cualquier cosa (Libro/Sticker/Mochila) que dijera F#. Lamentablemente ya casi todo estaba cerrado (incluso ya muchos se habian ido), asi que me senté en una escalera por fin, descansando de todos esos días.
Hasta que levanto la mirada y veo caminando a Edgar Sanchez, lo saludo, y comenzó la conversación (Diablos, debería grabar todo lo que comento, pregunto o respondo)

Que de que hablamos? pues desde mis posts hasta mis puntos de vista de todo tipo.
Creo que terminé aprendiendo mas de la cuenta, y bueno, luego de 4 días de reventadas de cerebro y mas de 6 horas de asesoría personalizada, pues uno como que termina contento, no?

Saludos[at]Cama

Sunday, November 09, 2008

Jersson tambien tiene twitter

hace un par de dias, ya que es mas rápido escribir una linea que tooodo un post (los que me conocen saben que demoro en demasía).
Aqui mi dirección,
http://twitter.com/Jersson
a ver que pasa

Saludos[at]Cama Prestada