FireNes

Seguramente conoces, VirtualNes, un sitio que te permite jugar en el navegador con los videojuegos que los administradores del sito poseen fisicamente.

Pero si no tuvieras que entrar a este situo para buscar lo que te interesa... y como todo en mozilla se arregla con Pluggins he aqui FireNes

Una vez descargado e instalado te dara una barra, como el del historial de navegación, donde se encuentran los juegos disponibles.

No eres avido de la Nes... bueno talves encuentres algo que te ajuste aqui

Cuanta verdad u_u

Los estudiosos de la calidad han estado rompiendose el coco para tratar de definir la calidad del Software. Sus esfuerzos han incluido medir la cantidad la cantidad de errores por cada ciento de lineas de código, documentación interna y externa de codigó, programación en parejas y otras metodologías cuando lo correcto debio ser lo más obvio Wtf's x minuto.



cortesia de osnew.com

Wii 3D

Sacado de las páginas de NopuedoCreer (link al lado ->) este proyecto para la wii (y esta en C#; tendre que darle una mirada °¬°).




El autor

Sudoku y programación

-¿Quién no se a puesto a resolver Sudokus?
-¿De qué me hablas? ¿Qué es un Sudoku?

El sudoku es un juego sencillo (and Hard as Hell!!) que puede entretenerte y despertar tu mente en esas horas de trabajo libres que uno llega a tener.

Dentro de programación, asi como el Gato (no el Herces, el 3 en raya pues) y el buscaminas son retos interesantes para el para el estudiante de programación; ya sea para crear ó resolver alguno. ¿Con que interes? bueno, cuando uno anda entrado en recursividad ó metodos de busqueda ó una aplicación a lo que se expone en clase el desarrollo de estos juegos requiere un poco de(busqueda en google y) devanación de sesos para los estudiantes.

Justo, en cristalab su usuario "Teseo" acaba de proponer un algoritmo para Generación y Resolución de Sudokus; algo interesante desde el punto de vista matemático y de programación

Headers intercambiables

A lo mejor soy yo con mi falta de conocimiento/practica; pero bueno espero irlo puliendo.

Bueno al menos ya tengo una idea de que hacerle.

Por ahora, delen F5 a su navegador si la suerte los acompaña veran otra imagen como encabezado (si no, puede que el javascript este bloqueado)

Aumentado el tiempo de carga

O lo que es lo mismo; agregando nuevamente el radioblog ^_^
Esta vez no son canciones que haya subido, sino que ahora tengo la posibilidad de crear Playlist con las canciones de otros internautas.

Se agregan entre otras cosas, canciones brutalmente viejas que en su vida habrán oido como perdoname de Batman(TM) y Ronin (El duo dinamico), algunas que seguro abran escuchado y una seleccion de musica acida-psicodelica.

Cambiare el Header para reducirle peso y aumentar velocidad, pero de momento disfruten

Ahora recuerdo (Me)

Por que no tenia un convertidor de video en win me.

Mis esfuerzos de colorear en Paint..

Adquiriendo un poco de inspiracion y viendo que el cayo es más importante que la herramienta Me he dedicado a la divertida tarea de colorear una imagen

Imagen en cuestion

Sin embargo he tomado algunos consejos de la gente conocedora de esto y otro más

Obviamente no tengo la misma herramienta que ellos pero obteniendo el concepto basico y con el conocimiento del manejo de imagenes en C# se consigen efectos similares.

Como no he querido intentarlo primero con la imagen más grande he decidi probar los conceptos en algo más pequeño.

1.-Clarificar la imagen

Para definir la tonalidad de los colores que conformarán la imagen y que sea más facil agregarlos¿Y como hago eso en Paint?, No es posible..así que use lo más cercano limpieza de imagenes que tengo: La barra de Imagen de office (Power Point para no tener mayor problema), con la cual podre clarificar modificando brillo y contraste.

2.-Remarcar más las lineas de la figura.

También conocido como Lineart, es remargar contornos y lineas para que la imagen no se vea borrosa y sea más facil aplicar los colores.

Un lineart.. obviamente no lo he hecho yo

3.-Aplicación de fondos

Recomendación de aplicar los fondos antes de colorear la imagen ya que resulta más facil arreglar el fondo que la imagen.
Yo prefiero hacerlo como un paso intermedio en el coloreo.

Fondo tomado de otra Imagen

4.-Aplicando colores.

Usar las areas ya limpias y de un color uniforme en la imagen para aplicar layouts o capas de colores.¿Capas?, Si como si cortaras un pliego de color de la medida exacta que necesitas y lo colocarlo como si rompecabezas se trataze
Obviamente esta tarea se simplifica dependiendo de la clarificación que hayas hecho (especialmente en paint donde los pixeles tienen que ser exactos al que intentas rellenar y normalmente tienes una gran cantidad de tonalidades siendo que de lejos se ve bien)

5.-No olvides los contrastes.
En este caso las sombras, oye no te mataste haciendo el Lineart y la clarificación para olvidarte de los claros obscuros

En la imagen a colorear resulto un poco más dificil los pasos ya que Power point no limitaba las tonalidades como yo queria haci que aplicando un poco de C# tenemos a un igualador de tonos.

public void EscalarGris(Bitmap bmImagen)
{int j,i;
unsafe //Porque es posible que explote
{
//se genera otra zona a modificar (x,y,ancho,largo,como se lera y los colores usados)
bmdDatos=bmImagen.LockBits (new Rectangle (0, 0 ,500 , 750 ), ImageLockMode.ReadWrite, PixelFormat.Format24bppRgb );

paso = bmdDatos.Stride ; //Para recorrer el arreglo donde se carga la imagen
linea = bmdDatos.Scan0 ; //Donde se tiene que apuntar para leer la imagen
offset=paso - (bmdDatos.Width *3); //Para evitar diferencias entre el tamaño de la fila y el numero de bytes en la misma.

byte * bByteArray = ( byte *)( void *) linea ;
for (j=0;j<750;j++) i="0;i<500;i++){">valor = (int)((70 * bByteArray [ 2 ] + 150 * bByteArray [ 1 ] + 29*bByteArray [ 0 ])>>8) %65536

if (valor<255>=210)
{
bByteArray [ 0 ] = ( byte )( 0 ); //Azul
bByteArray [ 1 ] = ( byte )( 0 ); //Verde
bByteArray [ 2 ] = ( byte )( 0 ); //Rojo
}
if (valor<210>&& valor>= 150)
{
bByteArray [ 0 ] = ( byte )( 100); //Azul
bByteArray [ 1 ] = ( byte )( 100); //Verde
bByteArray [ 2 ] = ( byte )( 100); //Rojo
}
if (valor<150>&& valor>= 60)
{
bByteArray [ 0 ] = ( byte )( 155); //Azul
bByteArray [ 1 ] = ( byte )( 155); //Verde
bByteArray [ 2 ] = ( byte )( 155); //Rojo
}
if (valor<60>&& valor>= 0)
{
bByteArray [ 0 ] = ( byte )( 255); //Azul
bByteArray [ 1 ] = ( byte )( 255); //Verde
bByteArray [ 2 ] = ( byte )( 255); //Rojo
}

bByteArray += 3;
}

bByteArray += offset ;
}

bmImagen.UnlockBits (bmdDatos);
}
}

Y como funciona bueno..una imagen es un array de bits en pares de tres (Rojo, verde y azul) más datos de la misma imagen la cual al aplicar la formula valor = (int)((70 * bByteArray [ 2 ] + 150 * bByteArray [ 1 ] + 29*bByteArray [ 0 ])>>8) %65536 obtenemos una escala de grises con valores de 0 - 255 (blanco-negro)
El arreglo se mueve de izq a derecha y de arriba a abajo.

Dependiendo del valor que obtengas solamente debes determinar que rangos deben volverse de determinado color

Oye -se escucha entre el publico- No era más facil bajar un editor decente de internet
En efecto, sin embargo, el instinto de magiver actuo en mi, además usar 700 Mb en mi disco para cambiar imagenes los tonos de una imagen que ya esta en gris me ha parecido excesivo.

Bueno el resultado me lo da en negativo pero es algo que paint puede manejar sin problemas.

Colorear y lineart lo hago al paso ya que no tengo ni una idea de como debería verse un cabello negro tirando a azul purpura con una gran fuente de luz por detras

Progreso hasta ahora.

Final sin fondo

Criticas, Sugerencias y link a un programa liviano de edición son recibidos

Scrum (Estilos de programación)

He agregado descripción al principio para evitar que pensasen que habla de comida europea (struddent ó como sea que se escriba). Por cierto es Copy-Paste de un correo.

Agile = More Work

Agil.

Que bonito suena. Sólo de escuchar esa palabra siente uno la suave brisa en el rostro y el radiante sol bronceando nuestra piel al mismo tiempo que el canto de los pajaritos nos anuncian la llegada de la libertad.

"ah!!, que a todo dar.. nada de documentación, nada de UML o diseño, ya no haríamos planes, no hacer estimación!...sin juntas de avance, directo a programar!... hay que adoptar eso en la empresa!!"

Sabemos que ni de chiste nuestros clientes ó directores nos dejarían trabajar de esa forma. Pero lo que nos intriga es que hemos escuchado que existen equipos de desarrollo que trabajan así. ¡Suertudos!. Sin UML, sin diagramas de casos de uso, piñas coladas junto al teclado, sandalias y pantaloncillos cortos, sin el líder de proyecto encima con su fastidioso '¿como vamos?' cada día. Llegar a trabajar a las 11 y salir a las 4. Después de todo no hay deadline. Las cosas saldrán cuando tengan que salir, que no presionen.

El problema, por supuesto, es que todas esas son nociones totalmente equivocadas de lo que es trabajar siguiendo una disciplina ágil.

Cualquiera que crea que el desarrollo ágil es más conveniente para los programadores que para los managers, esta un poco equivocado. Mucha gente que practica este tipo de disciplinas han descubierto que:

es mucho mas arduo el trabajo diario para los programadores cuando sigues una disciplina ágil

y que, por el contrario, las ventajas que ganan los clientes y stakeholders son enormes. Como lo dice Tim Ottinger de Object Mentor:

I remember when I first started reading about eXtreme Programming. The theory then was that it was going to make programmers happy, but that management would never go for it. Now we find that the argument is that it's great for managements, but that it is harder for programmers? Why the 180-degree turn? Have we sold it more successfully to managers than to programmers?

¿Sorprendente?

En IT Conversations hay una sesión muy interesante con Ken Schwaber (creador de Scrum) en donde explica la razón de este fenómeno.

Ken describe cómo el ejecutar un proyecto con Scrum requiere completa entrega de cada uno de los desarrolladores en cada uno de los días del proyecto. Llevar Scrum es bastante más difícil e intenso que hacer software 'de la manera clásica'. Requiere un compromiso especial y total de cada uno de los integrantes del equipo.

Por lo mismo, una de las principales dificultades para adoptar Scrum, ó cualquier otra disciplina ágil, es que no todo mundo está dispuesto asumir ese tipo de compromiso. Todos seguramente conocemos algún developer que suele pasar días haciéndo como que trabaja y luego poner pretextos para justificar que no ha avanzado. Nuestra cultura ha permitido que ese tipo de personas puedan pasar años y años en un puesto de desarrollo sin mucha dificultad. En particular, escuché de un equipo que después de adoptar Scrum, instituyeron el 'Wally Award', en honor del personaje de Dilbert, premio que es asignado por todo el equipo al mas flojo de los desarrolladores después de la junta scrum diaria. Esa es presión que no todo mundo soporta.

En un equipo que sigue un modelo ágil todos están expuestos permanentemente a una visibilidad mucho mas grande. Las cosas son mas 'transparentes'. El avance (o la falta de) es mas evidente.

"No es cierto, en mi empresa el líder de proyecto checa diario los avances con cada uno. No se necesita Scrum para eso"

Ok. Hay una enorme diferencia entre tener a un project manager revisando el avance todos los días y llevar una disciplina como Scrum. De hecho, cualquiera que conozca Scrum sabe que la manera de ejecutar la planeación y revisión de avances es casi el 90% de lo que la 'metodología' te especifica.

Como lo describe Ken Schwaber, la forma de trabajar de Scrum tiene como objetivo eliminar tres grandes errores de la disciplina 'tradicional' de administración de proyectos de software:

1. Asignar trabajo en forma de tareas es mala idea

El project managemente 'tradicional' consiste en asignar tareas a los desarrolladores, muchas veces una larga secuencia de ellas, y en ir revisando que las ejecuten en el tiempo y secuencia establecidos por el plan.

Mala idea

Por mas empeño que le ponga el project manager a especificar "cada una de las tareas necesarias", siempre ocurre, tarde o temprano, que el programador se va a encontrar con que faltan y sobran tareas.

¿Cuantas veces no nos han asignado una serie de tareas que luce mas o menos así?:

• Tarea T00341: 2 horas, Elaborar diseño de clases de negocio de caso de uso de cargo a cuenta
• Tarea T00342: 1 hora, Construir alta de registro de caso de uso de cargo a cuenta
• Tarea T00343: 2 horas, Construir eliminación de registro de de caso de uso de cargo a cuenta
• Tarea T00344: 2 horas, Construir busqueda de registro de de caso de uso de cargo a cuenta
• Tarea T00345: 1 hora, Construir modificación de registro de de caso de uso de cargo a cuenta
• Tarea T00346: 1 hora, Construir componente de interfaz de usuario de caso de uso de cargo a cuenta
• Tarea T00347: 2 horas, Construir elemento de menu de caso de uso de cargo a cuenta
• Tarea T00348: 4 horas, Pruebas del componente de caso de uso de cargo a cuenta

ARGGHHH!! además de que simplemente mirar el plan de trabajo hace mas daño a los ojos que el salir a ver el sol directamente por un par de minutos, en cuanto el programador descubre que para hacer el cargo a una cuenta se necesita, no se, digamos, un método que sabe redondear los montos de acuerdo a reglas del negocio complejas y que nadie conoce, entonces surge desde las mas profundas entrañas del infierno un mounstro por todos temido conocido por los eruditos en temas macabros como 'la tarea no planeada'.

Este engendro de satanás, la 'tarea no planeada', representa con su malevola existencia un retraso al plan de trabajo que desestabiliza todo el proyecto y que causa miradas de odio contra el programador que la descubrió por 'poner trabas' al avance. En el caso de que el valiente y temerario project manager se decida a enfrentarla, la 'tarea no planeada' le abriá nuevamente aquella úlcera que creía olvidada por el simple hecho de obligarlo a abrir de nuevo el archivo de Microsoft Project que le llevó 4 noches enteras ajustar a la fecha de entrega prometida y que ahora tendrá que modificar con el mismo cuidado (posiblemente con y los mismos resultados) que implicaría retirar el 3 de diamantes de la base de un castillo hecho con naipes.

En la mayoría de los casos, sin embargo, la 'tarea no planeada' es ignorada por todos con la esperanza de que, empujada por el rechazo e indiferencia, vuelva despúes de un rato a arrastrarse de vuelta hacia las entrañas del averno, dejando tranquilos al equipo y a su plan de trabajo, que después de todo ya había sido 'bendecido' por 'el ser supremo', y eso es signo de perfección.

Además de la infame 'tarea no planeada', el programador se va a encontrar como muchas tareas que si fuéron planeadas, pero que son tareas inútiles, duplicadas y sin sentido. Pero, ah!, cuidado con que caiga en la casi herética desobediencia de no reportar avances sobre ellas por que todos sabemos lo que puede pasar si hacemos la observación de que 'esa tarea no aplica' (para el que no esté acostumbrado a la jerga del profesional de sistemas, el término 'esa tarea no aplica' es en muchos lugares el término técnico para 'yo soy un holgazán que no quiero trabajar y el project manager es un imbecil y su virilidad y ética profesional son de bastante dudosa naturaleza').

Scrum, por el contrario, está diseñado a partir de un pequeño conjunto de aventuradas premisas (que tal vez en algún futuro algún grupo de iluminados científicos podrán comprobar o refutar):

• Que desarrollar software es un poquito más complejo que poner ladrillos en una construcción.
• Que los programadores tienen habilidades de análisis y solución de problemas un poco mas elevadas que las de un obrero de línea de ensamblaje de una fábrica.
• Que un equipo de desarrollo está formado por profesionales (aqui es desgraciadamente donde luego se viene todo abajo, pero eso es otro tema).
• Que los profesionales de cualquier ramo son los más indicados para determinar cómo hacer su trabajo para llegar a los resultados .

Obviamente lo de 'premisas aventuradas' es sarcasmo. En fin, el punto es que:

La asignación de trabajo basada en tareas no funciona.

Es como ir con el mecánico a que repare tu auto y en vez de pedirle que 'cambie el aceite', decirle 'mira, primero levantas el auto con el gato hidráulico, luego tienes que usar una llave inglesa para quitar la tuerca del depósito, luego vas por una cubeta y dejas que salga el aceite que actualmente está en el motor, etc. etc.'.

Suena ridículo, pero si sabemos que es estúpido querer dar a cualquier profesional (incluso a un mecánico de autos, que se pudiera calificar como un oficio no profesional) una lista detallada de tareas que le digan cómo hacer su trabajo ¿por que demonios queremos que eso suceda en el desarrollo de software?

El más indicado para determinar que tareas realizar en una actividad compleja es el experto. El profesional. Sobre todo porque en cualquier actividad compleja (creo que es evidente que el desarrollo de software es una de las tareas mas complejas que existen) hay incertidumbre. El experto es quién mejor puede decidir cuáles son las tareas necesarias cuando se encuentra con un problema durante la ejecución.

En vez de usar 'tareas', Scrum asigna trabajo en forma de elementos que representan entregables con valor funcional para el cliente. Por ejemplo, en vez de la lista de tareas detalladas, tendríamos algo como:

"Un comercio puede hacer un cargo a la cuenta del cliente a través del sistema"

El equipo tendrá que decidir si puede o no estimar esa funcionalidad (tal vez es de muy alto nivel y se necesita descomponer en fragmentos de funcionalidad mas pequeños para poder estimarla), decidir si es posible terminarla para la próxima iteración, investigar los detalles de cómo debe funcionar, organizarse para trabajar en ella y asegurarse de que funciona correctamente. El equipo tiene que determinar cómo y cuándo ejecutar cada una de estas actividades. Todo como profesionales que saben entregar resultados y lograr objetivos de beneficio para el cliente.

Por eso trabajar al estilo 'Agile' significa más trabajo para el desarrollador, pues esto impone un grado de responsabilidad mayor sobre todos los integrantes del equipo. Nadie puede cómodamente sentarse en su cubículo el día entero y limitarse a cumpilr una tras otra con las tareas asignadas por su project manager.

El segundo error que Scrum busca eliminar es:

2. Revisar el avance de cada programador por un supervisor y de forma aislada es mala idea

En un projecto 'tradicional' de desarrollo de software, cada programador ya tiene una lista de tareas asignada. En el caso típico de revisión de avances, tenemos el siguiente escenario entre el project manager (PM) y el desarrollador (DEV):

El PM se acerca sigilosamente al programador con una impresión del archivo de Project en la mano.

PM: Que onda, ¿cómo vamos con lo de cargo a cuentas?

El DEV siente el frio correr por su espalda y piensa para si mismo mientras sigue tecleando simulando estar muy concentrado para contestar:

"vamos?? me suena a muchos!! como voy, querras decir, maldito! ¿a ver, pues enseñame tú que has hecho, digo, además de este adefesio de plan de trabajo?!"

pero finalmente contesta:

DEV: "ehh.. ahh.. lo de cargo a cuentas... ehh.. si.., ya prácticamente está listo. ya nomas faltan unas cosillas"

DEV: (terminarlo y que funcione), piensa.

PM: Acuerdate que de acuerdo al plan eso tenía que estar para ayer. Nos estamos retrasando.

DEV: Ehh... ahh.. eh.. si. Es que tuve que hacer la parte del guardado de la configuración.

PM: Hmmm.. Ok.

DEV: ...

PM: Oye, ¿Configuración para qué??

DEV: Pues para lo del combito del catalogo de cuentas.

PM: Hmmm.. ok.. si, ya entendí.. Oye, pero si eso ya estaba, no?, es la tarea T004355, aqui lo tengo en el plan como terminado.

DEV: Pero es que el componente que había lee la configuración de una base de datos, yo tuve que hacer un componente que guardara la configuración en un XML pues del lado del cliente no hay base de datos.

PM: Pero eso lo tenía que haber hecho el que hizo el componente de configuración. Se supone que la tarea del componente de configuración ya esta 100% terminada.

DEV: Es que le pregunté si ya lo había hecho, pero me dijo que no sabía que tenía que haber soporte para XML en el componente de configuración.

PM: Bueno, ¿pero por que te tomó tanto tiempo si ya casi estaba?. ¿Nada mas necesitabas hacer copy-paste del código del otro componente, no?

DEV: ¿copy-paste de ASP a C++ ?

PM: Pues si, no?

DEV: no.

PM: Ok. Hmm.. Hijole.., es que esto 'ya nos esta pegando en los tiempos'

DEV: piensa: (pues si, y? ...que quieres que yo haga?)

PM: En que te puedo echar la mano? Pasame el código para ver en que te puedo ayudar.

DEV: piensa: (Ni lo intentes, desgraciado. Alejate de mi código)

DEV: No, gracias, ahorita en nada, ya casi está.

PM: Orale. Ahi cualquier cosa me dices. ¿Si crees poder empezar hoy con la tarea T0043829 ? Esa tenía que estar para hoy. Es que si no si 'se nos mueve' todo el plan.

DEV: Ok... si.. Deja veo. Yo creo que si, esto ya casi queda.

PM: Sale. No se te olvide reportar tus horas.

Este escenario muestra los problemas típicos de este tipo de seguimiento al avance:

• Falta de comunicación entre el equipo. Pueden pasar semanas enteras sin que un programador se entere de lo que están haciendo los demás.
• Falta de flexibilidad para resolver problemas conforme se van descubriendo.
• Falta de conocimiento de quién elabora el plan de trabajo acerca de cómo deben hacerse las cosas (puede no ser el caso general, pero es frecuente).

En Scrum, el avance no lo evalúa el project manager. Sino todo el equipo de desarrollo. Todos juntos. Todos los días.

Es mas. En Scrum el project management lo lleva el equipo de desarrollo.

El rol de Scrum Master (lo mas parecido a un project manager que tiene Scrum) se encarga de facilitar al equipo de desarrollo las condiciones propicias para que puedan trabajar. Pero no lleva la administración del proyecto como tradicionalmente se conoce.

La forma en que el avance se planea y se evalúa (sprint planning, daily scrum meetings, sprint review) es simple, pero no es sencilla. Es decir, aunque las reglas son pocas y simples, se requiere de mucha participación e interés de cada uno de los miembros del equipo para hacerlo bien.

¿La ventaja? el equipo es quién decide qué se debe hacer y cómo. Y cuándo cambiar esa decisión.

No 'alguien' desde 'arriba'.

Por último, pero a mi parecer el error mas importante que Scrum busca eliminar:

3. Que la secuencia de tareas no refleje las prioridades del negocio es mala idea

Tradicionalmente, es común que las tareas de un 'plan de trabajo' (entiéndase diargrama de Gantt de Microsoft Project) se acomodan de acuerdo a las dependencias entre componentes de infraestructura del producto, y no necesariamente de acuerdo a la prioridad de la funcionalidad del negocio.

Esta claro que si uno pone el cuidado suficiente, se puede lograr un Gantt que tenga las tareas prioritarias para el negocio al inicio. Sin embargo inevitablemente el pensar en 'tareas' llevan al equipo a pensar en desarrollo de componentes primero y funcionalidad en segundo término. Por ejemplo, es típico que la primer tarea de construcción en un proyecto tenga que ver con algo relacionado al 'framework de acceso a datos' o 'framework de aplicación'. Después de todo, los demás componentes dependen de esas piezas, no?

Pues si, totalmente cierto. Pero ese es uno de los motivos por el cual 3 meses ya entrados en el proyecto todavía no tengamos nada que mostrarle al cliente. Y seamos sinceros, de todos modos siempre tenemos que regresar a hacer 'ajustes' al 'framework' una vez que iniciamos la construcción de componentes 'funcionales', pues es muy dificil predecir exactamente cómo quieres que se comporte tu framework si no sabes aún como son los componentes que lo van a utilizar.

¿Quiere esto decir que Scrum te indica que hagas primero las 'capas de arriba' y luego 'las de abajo'?

Claro que no. Scrum no te dice eso. Sería como si tu fueras un mecánico y Scrum te llevara su auto a que le cambies el aceite y te quisiera dar instrucciones detalladas de cómo acerlo.

Scrum sabe que eres un profesional y que sabes que necesitas hacer para entregar la unidad de trabajo asignada, que es un fragmento de funcionalidad útil para el cliente. Si eso significa que harás primero 'las capas de arriba' para luego ver como haces 'las capas de abajo', adelante. Si eso significa que vas a ir armando tu framework poco a poco al mismo tiempo que tus 'capas de arriba', adelante. Si quieres terminar totalmente el framework primero, adelante y suerte al negociar tus primeras iteraciones con el cliente en donde no vas a tener nada que mostrarle.

Y esta es la tercer razón por la que el trabajo en Scrum es mas dificil. El compromiso es entregar funcionalidad útil. No cantidades de líneas de código de infraestructura, que por si solas, no sirven para nada relevante.

Conclusión

¿Quieres trabajar usando una disciplina ágil como Scrum?

Entonces prepárate para trabajar más. No más tiempo. Sino con mayor intensidad. Más involucrado en el proyecto y sus metas, con más entrega, con mas responsabilidades. Preparate para trabajar duro.

¿Le quita esto el atractivo a las disciplinas ágiles? Claro que no.

Yo creo que es preferible estar en un equipo de desarrollo que se dedique a trabajar al 100% durante 8 horas todos los días y tener metas alcanzables, claras, compartidas, realistas, pensadas para lograr rápidamente beneficios para el cliente y que exigen de tu creatividad como profesional, que tener que trabajar 14 horas todos los días en una serie fija de tareas, concretas pero muchas veces mal planeadas, que no 'encajan', que te exigen muchos teclazos en vez de mucho talento como profesional del desarrollo de software.

Disclaimer

Como todas las herramientas, estoy totalmente conciente de que Scrum no es aplicable a cualquier situación (proyectos de outsorcing remoto/offshoring son especialmente dificiles de llevar con Scrum). Sin embargo lo interesante es que mucha gente piensa que disciplinas como Scrum sólo funcionan en proyectos 'sencillos'. Se cree que para proyectos 'complejos' tienes que empezar a usar técnicas mas 'tradicionales'.

Eso es totalmente falso. Al contrario. Si tu proyecto es realmente sencillo, tan sencillo que puedes preveer con anticipación exactamente como va a ocurrir todo, puedes contratar 'coders' y hacerlos seguir instrucciones precisas. En ese caso sigue usando tu archivo de Microsoft Project. Pero espero que tu proyecto sea realmente sencillo.

Blog Reborn

Select one blog non-update from your count, the blog is update wiht this post xD

Es bello ver cuando tu usuario se da cuenta que lo que pidio es más grande de lo que pensaba mostrandole lo que es tener que hacer Diseño De Sistemas (el problema es que se da cuenta cuando llevas 2 meses en algo que se planeo para 3 semanas :P)

Un poco más de post, aquí una desaventuranza del webmaster en cristalab.
Nota: agrego intervenciones en brochetes

Este webmaster se disculpa de antemano por el lenguaje soez que a continuación será expresado en estas cortas palabras. Pero a la mierda, yo hablo como se me de la gana en situaciones como esta, que alguna ventaja ha de tener pagar el puto hosting. Amen. [Eso]

El martes pasado a las 06:30am salía mi vuelo. Tenía un viaje de negocios a Medellín/Colombia en el que la misión era supervisar el montaje de un stand que mi agencia le vendió a una empresa de la que no hablaré, pero que diré que está dirigida por Yakuzas. Dejo como ejercicio al lector averiguar que empresa es. [Sony es un gran candidato xD]

El lunes anterior tuve un trabajo que no pude entregar y por el que trasnoché, llegando a no dormir nada y a no terminar el trabajo [ Como suele pasar ]. Desesperado, arreglé lo que pude para que medio funcionara, lo envié a mi otro cliente, me bañé y me fui al aeropuerto porque ya eran las 5:30am.[Para entonces estaria lejos del otro cliente]

El vuelo de mierda salió a las 8:20am por un “problema meteorológico”. No solo eso, sino que el vuelo aterrizo en Rionegro, una ciudad que queda a una hora de Medellín por carretera.
A las 10:30am, llevado, con sueño y ganas de matar y beber sangre, me dirigí a las oficinas de carga pesada de mercancía a ver si habían llegado las cajas y demás paquetes del stand. Todo parecía en orden excepto que las cajas eran inmensas, la estructura metálica venía ARMADA y su tamaño era tan masivo que tuvimos que pedir un camión para cargarlo todo.

El camión no llegó.

Afortunadamente, según el folleto que me dieron, el centro de convenciones era a una cuadra de la agencia de carga, por lo que monté todo en dos carritos de acarreo de mercancía que me prestaron en la oficina de envíos y anduve tal cual reciclador por las calles con mis cajas.
La dirección del folleto estaba mal. El evento era en la plaza de exposiciones, un centro inmenso a diez kilómetros. Hay que ser hijo de puta para, en estas condiciones, con sueño, cansancio de viaje y una tonelada dividida en carritos, escribir mal la dirección en el folleto.

¿Ya les conté que NO tenía hotel y que al mismo tiempo cargaba con mi maleta de viaje?

El hecho es que llegué al medio día al centro de convenciones ese. Contratamos a una empresa de montaje de eventos para que armara el stand, así que descargué las cajas y demás, la estructura inmensa, etc. Salí a buscar a la gente de logística, ellos me acercaron hacía el supervisor de los que montan los stands, hablé con él y me dijo que no tenía ningún contrato conmigo, que estaban todos sus “muchachos” muy ocupados y que no iba a montar mi stand.

WHAT THE FUCK!?

Busqué otro puto carrito de reciclador, monté en 4 viajes cada caja por partes y lleve todas las cajas de mierda al stand de 3x3. El sueño que tenía era indescriptible, de haber estado en mi casa ya me habría rendido y caído dormido sobre mi suave colchón (Disclaimer: Mi colchón no es suave). No tenía herramientas, no tenía ni siquiera un bisturí para romper las bandas de seguridad que le ponen en los aviones a este tipo de cajas. Mencioné siete veces a la madre del que se negó a montar todo y me puse, con un palito, a torcer los seguros para romper las cajas.
¿Han ustedes enviado una tonelada de carga delicada por avión? Es decir, una estructura completa desarmada, que armada debe verse hermosa, dividida en cajas, embalada por gente mal pagada que trabajan de 4am a 6am. Para resumirles esta historia, unas cajas de luz (Cubos de madera y acrílico con un pendón en vinilo que tiene un banner publicitario e iluminación interna. Como los del metro y eso) se rasparon en todos los bordes, haciendo que estas se vieran horrendas y que mi negocio se fuera a aquel lugar que comparte Satán y la mierda.

Zen.

Conseguí que dos “muchachos” de los que montan stands me ayudaran con el mió por 30 dólares. No sin que ellos repitieran cada 30 segundos como, si el supervisor los veía, los despediría. Conocí todo tipo de insultos y maldiciones autóctonas paisas que me sirvieron mucho ese día. Dos horas después, hasta ahora terminábamos de desembalar las cajas y medio montar los cubos de luz. La alfombra especial del stand exigía ser pegada con pegamento de caucho. Le di dinero al muchacho #1 para que lo fuera a comprar mientras nosotros seguíamos armando todo. Sacamos los 24 tubos de una estructura que permite colocar una pancarta de 3 metros de ancho en la pared. El muchacho #2 vio el plano de montaje de esa cosa, dijo que ya volvía con herramienta adecuada y no volvió. Esperé una hora, ninguno de los dos regresó
Las 3:30pm, con un sueño inconcebible, la boca seca, la lengua ardiéndome por la falta de hidratación, sin haber comido nada desde las 5am, sin haber dormido nada, sudando por el clima de Medellín y la ausencia total de aire acondicionado, amarrando la estructura de mierda con las malditas cuerdas de seguridad que envolvían el embalaje de las cajas. No quiero ver la cara del cliente cuando desarme el stand y vea que por detrás sus pancartas estaban tensionadas por una estructura sostenida por cuerdas con la marca de la aerolínea.

El diseñador industrial (Z <3) color="#3366ff">[ O_o ], comí un sándwich de 5 dólares, una malteada con muuucho azúcar para recuperar energías, hice el checkout del hotel y ya eran las 6:10pm. Sonreí al recordar que por lo menos mi vuelo era en clase ejecutiva y descansaría como me merecía.

El vuelo, el vuelo...

El avión salía a las 7pm. El aeropuerto está a una hora y cuarto del hotel por carretera.
Salí del hotel, tomé un taxi intermunicipal, le pedí que se teletransportara y corrió a 110Km/h por una carretera que permitía un máximo de 60 [ Lo normal, ustedes saben ]. Le pagué, entré al aeropuerto, hablé con la persona del check-in y me dijo que el avión acababa de despegar mientras señalaba al mismo por la ventana corriendo por la pista. Juro por el honor de ésta web que si no fuera por la policía le habría partido la cara a la empleada. Era completamente imposible que todo esto me pasara, algo hice, algo malo (¿Yo? ¿Malo?) en éste universo para que todo conspirara en mi contra. ¿Brujería? ¿Shamanismo? ¿Mal de ojo? ¿Jigoku Shoujo?
Pague otros putos 100 dólares en otra aerolínea que tenía vuelos más tarde para Bogotá, esperé hasta las 8:30pm (Hora del nuevo vuelo) y a las 8pm, la voz gigante [ no Dios, la de los anuncios ] dijo que el vuelo venía con un retraso desde Bogotá por las reputas condiciones meteorológicas. Pero esto es el puto trópico ¿Qué mierda de condiciones meteorológicas?

A las 9pm me sentí un héroe al sentarme en la silla de un avión que olía raro (Avianca, clase turista económica), donde sólo me dieron un jugo de mora y donde dormir era imposible con 3 malditos gringos que hablaban y se reían en un lenguaje que para mi, a esa hora, en mi estado mental, era ininteligible. Sospecho que estaban ebrios. [ Noooooo, Gringos de vacaciones y chupando imposible *sarcasmo ]

Así termina esta historia, rezando porque el panel no se caiga mientras escribo estas líneas, al calor de mi hogar, pensando en jamás, jamás, vender de nuevo otro stand.