Virtual Mirror

Antes de comenzar: Hace mucho que no escribía nada de nada, y se que no me extrañaron para que se hacen :P, pero he vuelto y ahora me dispongo a escribir cosas más técnicas, creo que dejaré de lado el tema que llevaba acerca de eXtreme Programming pero bueno si alguien quiere que le siga pues sólo dígalo. Ahora a lo que nos concierne.

Actualmente estoy estudiando la universidad y en las materias se presenta uno que otro proyecto cada cuatro meses. Hasta ahora (transcurridos 5 tetramestres) no he hecho nada de lo que me sienta orgulloso*,en parte porque el tiempo está muy limitado, vaya que hacer proyecto importante en menos de cuatro meses como que no va.

Pero ahora me he reunido con muy buenos compañeros para trabajar en un proyecto que promete ser al menos presentado en la exposición de proyectos de la escuela, su nombre: Virtual Mirror.

¿Qué es Virtual Mirror?

Pues es un entorno virtual donde diferentes avatares interactúan, para que quede claro es como un Second Life pero en extremo sencillo. Es fácil pensar que es un juego en tercera dimensión pero preferimos darle un enfoque distinto, la descripción que me gusta manejar es la siguiente:

Es una herramienta de comunicación masiva que ocurre en un entorno virtual para crear atracción a la aplicación y familiaridad con situaciones reales, que ofrece un método interactivo para cumplir ciertos objetivos relacionados entre la comnicación de entidades y personas.

Así se oye muy bonito, además da un énfasis correcto al objetivo de la aplicación que es permitir comunicación y no el jugar.

Por razones del destino el lenguaje es Java, lo sé lo sé va a explotar la máquina virtual si hacemos un entorno 3D, pero no necesariamente. José de Jesús que es el encargado de hacer lo gráfico está constantemente buscando técnicas, tecnologías y herramientas para aumentar el desempeño de la aplicación y sin perder de vista el crear un entorno lo más real posible, muy acabado y pulido.

Para los gráficos utilizaremos VRML, un estándar que la verdad yo no había escuchado hasta hace poco pero según entiendo el W3C es el que lo auspicia, así que basado en mi fe ciega a W3C ¡adelante!.

Ejemplo VRML

Además de su trabajo Rogelio se encarga de las redes y Edgar de las interfaces gráficas, por mi parte estaré del lado del servidor de bases de datos y de vez en cuando iré a ver los clientes para ponerles un poco de XML ahí.

Escribiré de mi trabajo más adelante por el momento sólo quería escribir un poco, que ya me hacia falta.

*El sitio Web que hice con mi Perlita fue un gran orgullo, pero no cuenta porque no es proyecto.

Aquí y en China

Actualizado, solidario, humano, positivo y accesible son algunos de los valores que mi universidad fomenta entre “la comunidad universitaria”. Aunque puede ser que los encargados de los servidores no lo sepan y por eso hallan bloqueado mi blog junto con todo wordpress para no batallar.

Como se ha dado el caso de censura en China contra algunos dominios, en mi propia escuela me ha pasado. Nisiquiera es un blog con un afán de atacar a la universidad o sus interéses, no es un blog donde se hable de algo que en la escuela esté prohibido, si no todo lo contrario: se tratan temas enfocados a la informática, principalmente a la ingeniería de software.

Pero claro deben estar muy ocupados para tan siquiera averiguar de qué diablos se trata lo que bloquean, creo que la razón es que logueaba en la escuela para checar mis visitas al blog y estar un poco al pendiente. Pero a esta gente no le importó y prefirió, no sólo bloquearme a mi, si no a WordPress completo.

Esto pasó la semana pasada y haré algo al respecto mañana mismo para ver cómo se compone la situación, que aunque, admito, no es un blog que se consulte mucho, el bloqueo afectó a muchos más blogs que no tienen la culpa.

Historias de Usuario

Recordemos siempre que cuando en este blog se habla acerca de ingeniería de software nos enfocamos en la metodología ligera extreme programming (XP).

En el post pasado comenté acerca de los roles en un equipo de desarrollo y esta vez nos toca echar a andar el proyecto. En las metodologías clásicas de desarrollo había 4 etapas principales (las que me enseñaron en la prepa):

Generalmente la etapa de análisis comprende mucho papeleo, cosas que a veces no se les ve importancia. Digo esto desde el punto de vista de un estudiante, como yo, o un desarrollador no tan formal cuyo mayor interés es sacar versiones de su aplicación, como yo.

Sin embargo la etapa de análisis es impresindible para el desarrollo de un sistema, en esta etapa es donde se obtienen los requisitos que necesita realmente el cliente o usuario final. eXtreme Programming propone una manera menos formal y más rápida de recabar esta información directamente del cliente y de una forma más natural para él.

La técnica es recolectar “historias de usuario”, pero qué son las historias de usuario.

Las historias de usuario son pequeñas sentencias, lo recomendado son 3 renglones, en un lenguaje común que describe una funcionalidad que el cliente desea para el sistema. Obviamente las historias de usuario deben escribirse por éstos mismos, los usuarios no están limitados a pensar en cómo será la interfaz, o cómo quiere que se haga, el usuario sólo escribe lo que él quiere que el programa haga y listo.

Son parecidos a los casos de uso de UML, pero no son exactamente lo mismo. Además de expresar funcionalidades las historias de usuario son apreciadas por dar al desarrollo un método de prueba. En XP la calidad es fácil de expresar: funciona o no funciona. Basándonos en la historia de usuario original y comprobando el sistema podemos ver si fue cubierta o no.

Las historias de usuario también nos dan una idea de qué tan largo será el proceso antes de hacer un release, antes de esto las historias de usuario deben analizarse varias veces antes de aceptar su implementación.

Hay que remarcar para que quede claro que las historias de usuario se basan en lo que el cliente o usuario desea, sin dar detalles técnicos ni de tecnología.

Al tener las historias de usuario recolectadas procederemos a trabajar con ellas en equipo, es recomendable que las historias de usuario SEAN ESCRITAS POR USUARIOS y yo recomiendo que en tarjetas que sean manejables, como para barajearlas sobre una mesa.

El inicio del proceso de desarrollo de software

Actualmente estoy trabajando en un proyecto para una aplicación que tiene como objetivo crear sitios web de una manera muy sencilla y principalmente enfocado a cierto mercado, después hablaré más detalladamente sobre eso.

En este momento lo que nos compete es el proceso del desarrollo para un buen software. El primer paso fue elegir la metodología de desarrollo que ibamos a usar, yo elegí la eXtreme Programming porque es la que más se acomoda a mis necesidades. Pero eso no implica que pueda hacer algunos cambios en la forma de trabajar que sugiera XP.

En primer lugar traté de darle un enfoque algo más ordenado, lo primero que hice fue ver la especialidad de cada uno de los miembros de mi equipo y asigné roles a cada uno. Esto no es con el espíritu de causar diferencias entre el equipo, sino para saber a quien acudir cuando se presenta un problema. Yo elegí los siguientes roles basándome en las sugerencias de otra metodología.

• Líder de Proyecto. El líder de proyecto es aquél que dirige el desarrollo hacia el lugar correcto, conoce muy bien el objetivo del software y sabe a donde y a donde no se quiere llegar.
• Administrador de Desarrollo. Básicamente se encarga del lado creativo del desarrollo, ayuda a los demás a resolver problemas con el lenguaje de programación, los ayuda a que utilizen el lenguaje de la mejor manera. En mi caso es importante que el administrador de desarrollo haga su trabajo ya que el lenguaje es nuevo para todos los del equipo.
• Administrador de Calidad. En la metodología eXtreme Programming es muy importante probar el software, a cada momento, de forma unitaria y ya todo integrado. XP propone probar siempre los módulos recién escritos para que la difícil etapa de pruebas presente en otras metodologías sea muchísimo más ligera. El administrador de calidad se encarga de ver que las pruebas indicadas son siempre satisfechas.
• Administrador de Soporte. El rol que desempeña el administrador de soporte es el de conseguir y asesorar al equipo sobre la mejor herramienta para cumplir una necesidad que se presente a lo largo del proceso de desarrollo. El administrador de soporte debe conocer bien las características del resto de las herramientas que se utilizan para desarrollar el software para que puedan coexistir sin problemas, además debe buscar aquellas que mejor cumplan las necesidades que busca el equipo de desarrollo.
• Administrador de Planeación. Él se encarga de administrar todo tipo de recursos presentes en el proceso de desarrollo, tiempo, dinero, personas. Se encarga de establecer fecha y hora de las reuniones así como promover el trabajo arduo en cada uno de los integrantes para cumplir las metas establecidas.

Las responsabilidades de cada uno de los miembros del equipo les fueron comunicadas via e-mail. Cada uno de los miembros debe cumplir con sus responsabilidades lo mejor que pueda para que el equipo se beneficie.

Iron Chef Jabalies - La Serie

Así es arrancaron los preparativos para esta nueva serie que será transmitida por todos los canales de YouTube de los relacionados, actualmente estamos consiguiendo fondos para comprar los ingredientes y estamos consiguiendo al staff.

La mecánica está más o menos definida: el anfitrión decidirá el ingrediente secreto de la competencia (aún no sabemos si será al azar) , sabiendo esto los contendientes irán a Soriana Santa Rosa a comprar las cosas que necesitan para sus platillos. Todo el recorrido por la tienda será grabado y habrá comentarios por parte del anfitrión y los contendientes.

Una vez que se tengan los ingredientes (que corren por cuenta del contendiente) se procederá a su elaboración en la cocina de alguno de los implicados. Al parecer cada quien tendrá su turno para preparar la comida, o en dado caso los contendientes compartirán espacio en la cocina.

Al final los jueces probarán los platillos y decidirán según criterios establecidos, (probablemente los mismos que en Iron Chef America), el ganador de la competencia recibirá el título de Iron Chef.

Por el momento sólo está confirmado el primer encuentro: el Chef Demon y su servidor.

Esperamos que esta serie se pueda realizar para que la disfruten desde sus casas. Esperen más noticias acerca del progreso de los preparativos.

eXtreme Programming

Como ya se comentó en el post anterior XP es una metodología ligera que se enfoca en integrar periodicamente todo el sistema y probar los módulos unitariamente. XP será la técnica que utilizaremos para desarrollar el proyecto Prometeo (información en futuros posts).

Este diagrama muestra una metodología básica para seguir la XP. El ciclo que se forma con las líneas continuas son iteraciones y cada figura representa una etapa del desarrollo.

Historias de usuario es el primer paso al comenzar un desarrollo y es cuando se piensa, o mejor aún, se entrevista a un cliente final del sistema lo que desea que haga el sistema.

Las historias de usuario se escriben con un lenguaje no técnico y deben ser frases concretas. Las historias de usuario deben reflejar lo que el cliente desea, no lo que alguno de los miembros del equipo considera adecuado incluir.

Cuando tengamos plasmadas las HU elegimos que historias agregar a la release que se aproxima y convertimos éstas últimas en tareas.

Esto sería planeación, dividir las tareas para que se cumplan en cierto tiempo y entregar el release completo. En XP las cosas funcionan o no, no hay 80% de satisfacción jamás.

El diseño es similar al de metodologías tradicionales, debemos plantear la forma en el que se cumplirán con las tareas que nos propusimos terminar. Hacer digramas de flujo, casos de uso, clases etc. Es muy importante considerar el uso de alguna herramienta como UML para estandarizar el diseño y que pueda ser leido por cualquiera del equipo.

Hay que tener en cuenta que el diseño en XP debe ser sencillo, para que sea entendible en cualquier momento y que permita mejoras continuas en el diseño original.

El desarrollo, contempla la etapa de codificación donde se debe tener énfasis en escribir código entendible y bien estructurado. Un punto muy importante en el desarrollo es la importancia que se le da a las pruebas continuas en los módulos y las integraciones continuas de todo el sistema.

Por último se hace un release con las tareas completas.

Hablaré posteriormente sobre cada etapa segúnb se vaya presentando, esto sólo fue una introducción.

Proceso de desarrollo de software

Cuando comenzamos la ingeniería de software lo primero que hay que ver es el método que seguiremos para llevar a cabo nuestro proyecto. Los métodos, lamentable o afortunadamente, no llegan a ser la panacea para aquellos que necesitan perfección en sus proyectos.

Se debe elegir de entre las opciones que contamos la que más se acomode a nuestras necesidades. Los métodos ya han sido probados y hasta están documentados, mencionaré algunos.

Team Software Process

El objetivo de esta metodología es el de proveer un marco para el uso de útiles métodos de ingeniería para el desarrollo de software, es un proceso iterativo que define roles, actividades, fases y ciclos durante el desarrollo. Se divide esencialmente en 8 etapas:

• Lanzamiento
• Estrategia
• Planeación
• Requerimientos
• Diseño
• Implementación
• Pruebas y documentación
• PostMortem

Estas etapas se repiten numerosamente y es lo que se denomina un ciclo. En cada ciclo se asigna cierto tiempo a cada etapa, mientras se va iterando el tiempo asignado a ciertas etapas va cambiando, por ejemplo en iteraciones posteriores se necesitará mucho menos tiempo para la planeación y requerimientos que en las primeras.

Un poquito más

 Rational Unified Process

Este provee una aproximación disciplinada a la asignación de tareas y responsabilidades en una organización de desarrollo de software. Su meta es asegurar la producción de software de alta calidad que cumpla con tiempo y costo de la mejor manera.

Se divide en cuatro etapas.

• Concepción. Es como planear la viabilidad del proyecto
• Elaboración. Proveer una línea base para el desarrollo del sistema
• Contrucción. Completar el desarrollo del sistema de acuerdo a la base
• Transición. Asegurar que el software será disponible para usuarios finales

En el RUP la calidad se mide por diversos factores:

• Código ejecutable instalable
• Artefactos no ejecutables instalables
• Artefactos no ejecutables y no instalables

  eXtreme Programming

De mis favoritas, es una metodología ligera generalmente utilizada en desarrollos de software libre, equipos pequeños y descentralizados.

Los fundamentos:

• Escribir unidades de prueba antes de programar y mantener las pruebas accesibles en todo momento
• Integrar el sistema continuamente
• Programar en pares (lo que no ve uno lo ve el otro)
• Iniciar el proyecto de manera sencilla y evolucionar
• Realizar entregas (releases) periodicamente

XP valora la comunicación, simplicidad, realimentación y disposición del equipo.

Referencia y otra

He leido que en España se usa mucho una llama V3 pero por la universidad no tuve tiempo de documentarme. Posteriormente propondré una metodología para trabajar con un proyecto y así ir publicando acerca de su realización.

Ingeniería de Software (IS)

Wikipedia dice:

La Ingeniería de software designa el conjunto de técnicas destinadas a la producción de un programa de computadora, más allá de la sola actividad de programación. Forman parte de esta disciplina las ciencias computacionales y el manejo de proyectos, entre otros campos, propios de la rama más genérica denominada Ingeniería informática.

Wikipedia es sabia y raramente se equivoca (y cuando se equivoca se corrige), pero en palabras un poco más faciles de digerir ¿qué diablos es la Ingeniería de Software?.

Primero debo decir que estoy estudiando una ingeniería en informática y que parte fundamental de mi preparación es que sepa detalladamente lo que es y lo que no la IS, pero Oh Dios! mi universidad se centra más en certificarnos y no en prepararnos en eso (pero eso es para otro post).

Bueno primero definamos qué es ingeniería:

Ingeniería es el estudio y aplicación, por especialistas, de las diversas ramas de la tecnología (RAE).

Hasta el momento estamos bien, los ingenieros de software toman aplican y estudian la informática para hacer de este un mundo mejor.

La IS es entonces aquella ingeniería que busca desarrollar software, uno de sus principales objetivos es crear métodos que sean comprobables y repetibles para crear exitosamente productos software.

Pero la IS sigue gateando y hasta la fecha no se ha encontrado método infalible que puede contra los enemigos de su aplicación. En primer lugar estamos tratando con algo abstracto, practicamente imposible de medir, gestionar, manipular y predecir su comportamiento: el software.

Otro aspecto que debe cubrirse es el tiempo. El tiempo en la producción de software es uno de los principales puntos a tomar en cuenta, se debe gestionar correctamente el tiempo con el que contamos.

Además se deben administrar correctamente los demás recursos con los que contamos: personas, herramientas, dinero!. Para planear un proyecto de software tenemos que ver todos estos recursos y manejarlos de la mejor manera.

“Un ingeniero no busca una solución, sino la mejor solución” [MC Ostos].

Pues hasta aquí ya da miedito empezar a crear software, yo como muchos egresados de técnicos informáticos no imaginarían que el crear software era tanta cosa. ¿Para qué complicarse la vida con tanto embrollo?

Eso a veces nisiquiera es comprendido por los mismos postulantes a ingenieros, mucho papeleo, mucho rollo, si lo más importante es programar. Uno de los principales errores en la IS, la codificación apenas si ocupa el 20% del desarrollo del proyecto.

Los métodos de IS contemplan una estructura similar a la siguiente:

1. Análisis
2. Diseño
3. Codificación
4. Pruebas

De las cuales escribiré más adelante, y de las que considero al diseño como la más importante. Pero seguir esta estructura o alguna que proponga algún método de IS es muy importante para el proyecto.

Por más tedioso que parezca esto nos librará de muchos problemas y nos dará un producto software con mejor calidad.

Bueno con esto doy acabada la introducción a lo que será una gran entrega de posts dedicados a la IS, una vez que tenemos los papeles en la mesa hablaremos sobre algunos métodos de IS populares, lo que persiguen, sus etapas etc.

Si Microsoft compra Yahoo!

Mucho se ha escuchado de la oferta que hace Microsoft a Yahoo! “para formar una misma empresa”, como dicen en Redmon, después de tantas propuestas de unir fuerzas por parte de Microsoft el debilitado Yahoo! recibe una carta de Ballmer planteando el escenario actual y cómo el “vender Yahoo a Microsoft es la mejor opción”.

A lo largo de los meses las empresas van y vienen, es mejor comprar una pequeña empresa con un buen proyecto que después competir contra ellos, pero pocas son las veces que vemos que una empresa grande quiera absorber a otro relativamente importante. ¿Pero cuál será el escenario para los usuarios de GNU/Linux si la venta llega a realizarse?

El enfoque del negocio es distinto

Resumiendo Microsoft=Escritorio, Yahoo!=Web. El fuerte de los chicos de Ballmer es realizar aplicaciones para el escritorio y los muchachos de Yang prefieren trabajar en la web.

Este punto trae a la mente diversas cosas, yo creo que aquí está la razón principal de la compra: Microsoft necesita hacerse fuerte en la web para pelear con el monstruo, el señor, el dios “Google”. Microsoft necesitaría mucho tiempo para que sus servicios Live puedan alcanzar el poderío de Google, en cambio subirse en hombros de Yahoo! resultaría más fácil, más rentable.

Desde el inicio de los tiempos Microsoft se ha dedicado a combatir por el dominio de la web pero siempre ha fracasado, excepto en algunas cosas como el actual cada vez menor dominio de IE y su MSN Messenger. Como la presencia de Microsoft en la web no es del todo fabulosa, su negocio en este campo no es mucho.

Un empujonsito

Introducir tecnología de Microsoft en servicios de Yahoo! es la gran oportunidad de Microsoft para ganar terreno en la web, territorio fuertemente dominado. Pero aquí surge otra cosa, muchos servicios Yahoo! se basan en software libre y open source, “¿qué haremos con ellos señor Ballmer?”, ¿reescribirlos?, ¿remplazarlos?, ¿botarlos?…si es así, dónde quedará lo bueno de comprar Yahoo! si sus ya consolidados servicios se hacen simplemente al lado.

Apuesto que lo que se prentende sacar de Yahoo! es una base para comenzar la dura batalla que le espera a MS contra Google, lo ha intentado con sus propios servicios pero simplemente no pegan. Yahoo! es la milicia perfecta, que con un poco de entrenamiento podrán librar la batalla, cuenta con varios y muy buenos servicios. Personalmente yo sólo uso Flickr pero sus servicios son aceptados por mucha gente.

Invasión

¿Y qué pasará con los servicios repetidos? Talvez tengamos el nuevo “My Flickr Live” o “Answers Live”, servicios que me causan temor al pensar que tan compatibles serán con mi explorador no IE. Es lógico que Microsoft aprovechará su presencia en el escritorio para promover el uso de los servicios que puede adquirir, sus actualizaciones en línea son la herramienta perfecta para introducir el mal a la computadora ¡¡Y el antivirus no las detecta!!. Las actualizaciones son la entrada para parches de inseguridad, para el detector de piratería, el silverlight y muchas cosas que el usuario ni siquiera desea instalar.

No dudo que Silverlight asome la nariz por todos lados donde antes dijera Yahoo! y eso es una noticia de pensarse. Moonlight trata de brindar soporte para SilverLight en plataformas GNU/Linux pero asuntos de patentes lo limitan a dar un soporte total, el video al estilo flash sigue siendo un problema pues no es completamente libre, aunque ciertamente prefiero que adobe tenga el dominio a que MS sea el bueno ahí.

Siguiendo con Yahoo! y software libre, las últimas tácticas salvavidas de Yahoo! incluían el apoyo a proyectos de SL, muy atinado, así los programadores se acercan a ellos y desarrollan el proyecto. Ahora si Microsoft toma el mando eso irremediablemente acabará, ningún lado ni Microsoft ni programadores libres quisieran tener contacto entre ellos.

Conclusiones

Que Dios, los santos, o algún desplome de Wall Street nos ayude para que MS no compre Y! nos librariamos de incompatibilidad, prácticas monopólicas, la pérdida de servicios muy buenos, una competencia limitada sólo a dos (MS y Google), el hecho que MS tenga más dinero etc etc.

Pero ya dije si MS lo compra, borraré mi Flickr y mis ID Y!.

Un día con PHP5

Después de los estragos carnavalero decidí darme a la tarea de avanzar con mi proyecto para la materia de base de datos que llevo en la universidad, nombre clave ‘Mochomo’.

El sistema es de los clásicos puntos de venta, no hay mejor sistema para practicar el manejo de base de datos. La cosa es que decidí hacerlo en PHP por la compatibilidad con MySQL, también decidí hacerlo al estilo POO, para agarrar práctica y porque ciertamente me gusta más.

Hasta ahora no había avanzado mucho por asuntos personales, pero ya me pondré a hacerlo bien por lo que me aventé una estudiada a las nuevas características de PHP5. Con lo primero que me encuentro es que ahora MySQL y PHP no son tan amigos como siempre fueron, por problemas de licencia ahora hay que usar un API externo para acceder a una base de datos MySQL, lo que la convierte en una más del montón.

Me reventé todo lo de clases porque para PHP5 fue reescrito, no hallé mayor problema, de todos modos no sabía cómo usar los objetos en PHP4 xD. Practicamente fue todo lo que ha cambiado, espero.

Así que para este sistema de punto de ventas le echaré ganas, será mi práctica con PHP y además ya se lo prometí al demon para su taller. Pero el chiste de este post es dejar estos enlaces a los manuales y referencias que me sirvieron, espero los chequen y se olviden de ese Visual Basic que los trae mal xD.

El oficial

Desarrollo Web, PHP5

PHP4 en Desarrollo Web

Manual imprescindible en sabuesoweb (por cierto tiene el mismo tema que mi blog)

Pear, pa los flojos como yo

Arre pues qué más quieren?