Podcast: Cuando los programadores quieren dejar de programar

Que tal amigos, les dejo aquí el primer podcast que hice con mis amigos @gustavo_veliz y @elfederiko, se tituló “Cuando los programadores quieren dejar de programar” y fue el inicio de un proyecto denominado nadaenserio, que buenos tiempos!

Definitivamente considero que fue un buen proyecto pero eventos como falta de tiempo y pérdida de mi laptop con todas las grabaciones y algunas ediciones por terminar, culminaron el camino 🙂

Sin más, los dejo con esta grabación, con casi 3 años de edad y algunos errores de grabado y/o edición, pero bueno, creo que algunos fundamentos siguen latentes.

[audio:02.NadaEnSerioBeta1.mp3|titles=Cuando los programadores quieren dejar de programar|artists=Jersson.net]

Me despido a la espera de sus comentarios, y bueno, esten atentos!
@Jersson

Comentarios: Podcasts en camino!

Hola amigos, como les había comentado en el post anterior, me encuentro todavía configurando el nuevo blog pero para no impacientarme decidía ir haciendo algunas pruebas, aqui un mensaje 🙂
[audio:01.Demo002.mp3]
En breve publicaré el podcast muy comentado en su momento Open-mouthed smile quizá los que todavía sigan el blog lo recuerden, al menos el título o la intro… “Cuando los programadores no quieren programar”, en el próximo post.

Saludos
@Jersson

Comentarios: La botella del build

En la empresa tenemos como una de las reglas principales, ir mejorando en base a experiencias y recomendaciones brindadas por el equipo de trabajo.
Muchas de estas recomendaciones nos han servido para mejorar y/u ordenar nuestra forma de trabajo y por qué no? mejorar tambien nosotros como profesionales.

Hace un tiempo conversando con el bueno de @phpleo llegamos a la conclusión de lo bueno que sería tener una botella para controlar los builds.

image
[Fuente Imagen: Pensamientos Agiles]


Para resumir el asunto, mantener una botella de builds implica que luego de que el equipo de desarrollo define reglas de la compilacion del producto, se establezca una multa simbólica si un miembro del equipo empieza a “romper el build”, claro… juntar estas multas implica que luego de tener un buen número de monedas se puedan comprar hamburguesas para todos! O lo que se decida cuando se tenga la botella llena 🙂

En nuestro caso al comenzar con la botella se tuvo como única regla ser cautelosos al integrar todos los proyectos que maneja la solución.

El proyecto lo trabajamos bajo Visual Studio 2010 y Team Foundation Server 2010 con su respectivo controlador de código y versiones, pero como algunos no tenian experiencia en el caso, se tuvo la consideración correspondiente para luego de algunos traspies comenzar con el experimento.

Debo confesar que creo que por mas buena que sea la herramienta o en este caso, el controlador de código fuente, los errores humanos nunca dejarán de existir.
Es por ello que no pasó mucho tiempo sin que la botella se mantenga vacia, hubo un error de integración de proyectos que generó un inconveniente con el resto del equipo, ustedes me deben comprender, demoras, molestías y bueno, retrabajo.

Por suerte, esos momentos no han sido muchos, pero los hemos celebrado en equipo con incluso un aplauso generalizado cuando (oh sorpresa!) @phpleo tuvo que colocar la respectiva multa en la botella de los lamentos 🙂

Desde esa fecha los errores de integración se han detenido, la botella del build ha dejado de llenarse y bueno, los muchachos (incluyéndome) estamos ansiosos por tener ya un fondo que nos permita comprar algo para un refrigerio, pero como el build se mantiene estable, el día de hoy decidimos ampliar las reglas y consideramos aspectos como por ejemplo:
Incumplimiento de reglas básicas de programación, por ejemplo aspectos que pueden resultar simples como la nomenclatura misma de un archivo, clase o método.

No documentar objetos de uso general, puesto que, como internamente manejamos una wiki (gracias claro al Team Foundation :D), tenemos un espacio para aquellos objetos de uso general, como mensajería, métodos, helpers o incluso librerías que si no se cuenta con documentación centralizada, pues tendremos problemas de comunicacion y/o de repreguntas cada vez que se quiera usar algo del repositorio común.

Les muestro un ejemplo de lo que bosquejamos en la pizarra
image

Cómo experiencia general debo compartir:
El orden y la comunicación del equipo ha incrementado considerablemente.
– En la oficina seguimos muchas prácticas (ágiles y no ágiles) y a la vez tenemos mucho por mejorar.
– Los muchachos (incluyéndome) tenemos más cuidado al subir nuestro código al repositorio pues a pesar de tener buenas herramientas y reglas de control, los errores humanos existen y bueno las monedas no nos caen del cielo!

Un Abrazo
@Jersson

The Old JersSoft

Ayer por la tarde, el bueno de Jonathan Aldave mencionó algo que me llamó mucho la atención:

image
Es interesante pero no recordaba esos posts!!! hace mucho que habia dejado de ver el blog. Vamos, que por algo se llamaba el blog viejo, no? =D

En fin, luego de nostalgia y demás cosas, he decidido considerar algunos posts en el nuevo blog, tal como ha pasado con “Cómo nace un paradigma?” espero tomar algunos posts, actualizarlos y bueno, compartir esas ideas locas que tenía por esas épocas, no?
La dirección y nombre del blog viejo es: The Old JersSoft
El cual pueden ubicar en la columna izquierda de este blog =)

image

Bueno, ya es mucha propaganda, no? =D
Sin más me despido.

Saludos y Gracias
@Jersson

Cómo nace un paradigma?

Cada cierto tiempo termino una conversación comentando entre dientes "saquemos ese paradigma de la mente…"

Pero exactamente que es un paradigma?
Es acaso una regla o una manera de pensar que nos encaja a un contexto, el cual, muchas veces nos obliga a responder de la “mejor manera”?

Cómo saberlo? a veces lo relacionan hasta con leyendas, formas de vida, métodos que nadie puede cambiar, pues así están y así funcionan.

Esas ultimas palabras suenan conocidas?

Pues bien, aquí un documento que recibí hace mucho tiempo.
Espero les sirva.

Saludos

@Jersson
Fuente: Cómo nace un paradigma?

Express: Ya casi listo el IIS Express!!

Hace unas horas revisando las noticias me dí con un sorpresa que vale la pena compartir.
Como habrán notado en el título, MS está próximo a lanzar un producto denominado IIS Express, el cual, por decirlo de manera simple, es la versión gratuita del ya conocido Internet Information Services, es decir, el servidor web nativo de MS, que tiene soporte nativo a la plataforma .NET

Ahora, hasta la fecha han habido soluciones disponibles, como en su momento (hace ya muchos años) lo fue el Cassini Web Server, o el servicio integrado con Visual Studio 2005 en adelante.
Pero honestamente, de contar con un ambiente que tenga IIS disponible, lo usaría en vez del servidor que viene con el VS. Esto por qué? 
Aquí, hay muchos pros y contras, pero me quedo con la respuesta mas simple:
Nivel de integración, ya que, a pesar de algunos privilegios necesarios, IIS como tal, trae las características que veremos en nuestro web server… pues es lo que tendremos en servidor! un IIS! =D
Mientras que por otro lado, a pesar de usarlo muchas veces,al VS Web Server, lo veo como un “mientras no tenemos IIS…”
webserver1
Y bueno… según comprendo, la idea del IIS Express es darnos un alcance mas cercano a un IIS 7.x disponible incluso para entornos XP, sin perder claro, el nivel de integración esperado con nuestro Visual Studio 2010.

Claro, aun estamos cerca de una versión Beta, con algunas configuraciones que posiblemente se hagan vía línea de comandos, pero bueno solo nos queda esperar y sacar nuestras propias conclusiones.
webserver2
Las imágenes las saqué de la única (supongo, hasta la fecha) fuente disponible, El post del gran Scott Guthrie, en el cual podrán encontrar más detalle =)

Saludos
@Jersson

La diferencia entre el QUE y el COMO

Este es un tema de conversación muy recurrente cuando nos reunimos y hablamos de la importacia de tomar requerimientos.

A veces, cuando converso con algunos amigos, ellos comentan lo aburrido que notaron al usuario que estaban entrevistando. 
Ante esto siempre surge mi duda: 
Qué tal la primera vez que se reunieron, de qué tipo eran tus preguntas, qué tanto ahondaste?
Quizá demasiado, no?

Entrevista 
Generalmente, lo que sucede es que posiblemente hayamos pecado de entusiastas, y de esa forma, a pesar que sabemos que no cubriremos lo necesario en una entrevista, queremos seguir preguntando al usuario detalles que de primera mano no vienen al asunto.

Debemos recordar siempre, que para el usuario es mas importante que uno comprenda y comparta las necesidades básicas que deben cumplirse.
Es cierto, estas necesidades son lo que conocemos los requerimientos principales, funcionales del sistema.

Algunos recomiendan tener menos detalle, llamándoles "Requerimientos Macro" o simplemente "Características" (algo asi como matricular, vender, comprar, grabar). Pero la verdad es que, en ocasiones (por no decir, todas) esto logra que confundamos los verdaderos objetivos de cada requerimiento.
Asi que personalmente hablando lo recomendable es comenzar a comprender, o al menos tomar en cuenta aquello QUE debe cumplir el proyecto, es decir el QUE del proyecto.
 
En este punto, el problema que surge es que mientras mas vamos comprendiendo aquellas cosas QUE deben hacerse en nuestro proyecto, nacen interrogantes algo tentadoras, que posiblemente, logren desviarnos del objetivo.
Asi es, mientras vamos avanzando vemos como van naciendo las dudas, cómo es que vamos hacer esas cosas?. Y que tal si preguntamos un poco mas, funcionalmente cómo se haría?

ERROR! eso nos desenfocaría demasiado del problema, en estos casos, el COMO cambia la dirección del problema, y mientras mas vamos ahondado en como cubrir tal interrogante, mas vamos perdiendo la hilación y el objetivo de las primeras reuniones.

requerimiento 
En otras ocasiones he notado problemas y estancamientos entre equipos que quieren definir sus contratos (programáticamente hablando, cómo se comunicarán y usaran sus librerias), ya que ademas de pensar en los parámetros a intercambiar, hay integrantes del equipo que comienzan a hurgar en COMO hacer el método del otro, cuando el objetivo de algunas tareas es tan solo, la definición del objeto!!, el QUE del objeto, no el COMO cumplir con ciertas actividades.

Es gracioso, pero, la frase clave siempre termina siendo "No Desenfoques, estamos averiguando el QUE, luego veremos el COMO", o simplemente "NO Desenfoques!!!"

Ahora, como es que vamos convirtiendo el QUE en muchos COMOs? pues iterando. o no?

Saludos
@Jersson
PD: Esta es una versión editada y mejorada de un post mío publicado hace mucho tiempo. Esto a raíz de un nuevo tema de conversación que será comentado mas adelante.